I am brand spanking new to ignition and I get to be the first in the company to start learning how to use it, so apologies in advance if I ask absurdly simple questions.
A little while spent searching this forum and the internet at large turned up nothing so I figure I would try asking this crowd.
I have several Omega temperature/ humidity controllers at my company with embedded Ethernet of the -EIT (iServer) variety.
(specifically CNiTH-i8DH33-5-EIT)
I can connect to these devices through a web browser and I can navigate to a page that shows live readings from the device (temp, %RH, Dew point)
For the life of me I cannot figure out how to bring these values into an OPC tag.
Contacting the device manufacturer has led to a stack of communication protocol manuals that I am presently working through - but I figured I would ask if anyone around here has had success with either the TCP Driver or Modbus RTU over TCP Driver for pulling values from these kinds of devices?
I have a sneaking suspicion that the answer is quite simple - I am just too new at this to pick up on it.
John, welcome to the Ignition Community, we’re glad you’re here!
I took a scan through a few of the manuals on this page, and it definitely looks like you can change the protocol selection from the default of TCP to Modbus TCP. I’d recommend this setup if possible (in contrast to the generic TCP driver where you have to essentially how it will read an ascii stream and parse it up). Hopefully the vendor was able to supply you with a modbus data map (that describes how the modbus registers associate with data in that device). The Modbus driver included with Ignition is pretty flexible–there is a wealth of information in the online Ignition docs for setting it up.
Btw, if you are able to scan in and upload (or link to) a modbus map for it, we could probably provide more specific guidance for how to layout the modbus addressing in the Ignition Modbus driver…
So here are links that are relavant to the device I am working with:
Here is a link to the communication manual specific to this family of embedded Ethernet devices (iSeries Monitor/Controller)
Here is a link to the communication manual for the temp humidity controller itself:
Finally a link to the iServer manual that covers details like wiring for RS 485 or RS 232 as well as the details of the iServer web interface
Getting right to modbus data mappings, from the iTH manual (second link) page 12 there is a bit that says that these devices operate using the RTU transmission mode -
So I would expect that means I should be using the modbus rtu over TCP driver.
Next i get details about how the message frames are constructed including details about CRC checking - I can only assume this is all handled under the hood of the RTU TCP driver.
Now the good stuff, page 15 has the modbus registers and the function codes supported - I expect to need the following:
01 SETPOINT 1
02 SETPOINT 2
27 RH% VALUE
28 TEMP. VALUE
29 DEWPOINT VALUE (edit - i actually don’t need this value at all since it can be calculated from the other two)
There are some other details in the manual about setting the device to modbus mode using the panel interface - going to give that a try and see what happens with these address mappings
Ok, so I get a connected status in the configuration section.
From the designer I have created an opc tag with the following path (where eip885b is the name of the device):
[eip885b]HR27
The tag is returning null and is alternating in Quality between Unknown and Not Connected.
Is there some detail in the advanced connection properties I need to change for this to work properly, or there is some detail in the device communication parameters I need to adjust on the panel of the device to make the connection work?
It looks like that Table 8.1 in that M5023n.pdf document shows the addresses in Hex. So that listing of 0x27 (hex) is actually 39 (decimal). If you are trying to read HR27 (which would be 0x1b (hex), that shows up as a N/A register in the table, so perhaps it is rejecting that request… Try HR39 and see if that works better.
FYI, in python you can do this to convert (you can do this in Script Console in the Designer as well):
Still bounces between not connected and Unknown for data quality.
Just for my own understanding, HR39 is the same as typing 40039 and should be a 16 bit holding register (read/write) - but when I look at the device manual the function code 03 is for holding register and 04 is for input register - I am getting a deliberately confusing vibe from these manuals…
I finally have a working set of connection parameters that lets me pull both the humidity and temperature values from the device directly into Ignition.
First, I needed to be using the Modbus TCP driver (Not Modbus RTU over TCP)
Second, I needed to limit the number of holding register requests to one.
Third, I needed to use zero based addressing not one based addressing (un-ticked a checkbox in the advanced connection properties)
Fourth, I needed to convert the hex address of 27 to decimal 39
Finally, I needed to provide a unit ID of 1 instead of the default zero.
Johnm,
I am working with some Omega devices as well.
I happened to ask the right question, of the right person, at the right time, and found out that the supplier has a new gateway\server coming out that is OPC-UA compliant. Plus the gateway has other comms options such as MQTT.
They allowed me to test the beta version of the software over this last month, and it now works seamlessly with Ignition (I am using the OPC-UA Server option). Here is a link to their new software. http://www.omega.com/pptst/OEG-SOFTWARE.html
Not sure if it will work with your devices or not but takes all the headache out of the situation.
Yes I contacted Omega directly and they were kind enough to provide me with a link to their new Omega Enterprise Gateway software.
I gave it a try but it turned out the the particular -iTH family of Omega controllers I have did not work exactly right - after installing and getting everything running the software would only pull %RH values and not Temperature values.
The people at Omega were very helpful and responsive - even sent me a few slightly altered .json configuration files to try out to get the thing to work properly.
For now the Modbus solution is working for the controllers I have. Later as we get more diverse Omega devices around our facilities the OEG OPC-UA server will certainly be the better way to go (as opposed to untangling the individual devices communication standards every time).
