Data Register Skew Problem
Offset by one register per increasing modbus RS-485 address value
Eurotherm 2404 Modbus RTU via Modbus TCP bridge
|Eurotherm||Eurotherm|~ RS-485 ~~~ |Moxa |~~~~~~|Modbus-TCP ||__2404 __|
|2404_|~|Ignition||Bridge |
Overview -
I am having some difficulty communicating with a string of very old (read ancient) Eurotherm 2404 Modbus-RTU (aka Jbus) serial devices connected with a two wire RS-485 master slave network thru a Moxa MGate MB3480 using the Ignition Modbus-TCP Driver v2 2.6.1 (b386) with Ignition Version 7.6.1 (b2278)
(BTW - Thank You for the suggestion to use Moxa bridges on another forum topic, very fast and very easy to set up and use)
I have also tried this using either of the Ignition Modbus-RTU over TCP and Modbus-TCP drivers with a DigiOne IAP configured as a multiple master RS-232 to RS-485 serial/ethernet bridge and gotten the same result described further below.
I have read the Inductive Automation Ignition Forum “Topic: Help setting up Eurotherm 2404 to Integrate to Ignition” and the Eurotherm SERIES 2000 COMMUNICATION HANDBOOK I have attempted this using the example .csv parameters provided from the link in the previous forum post.
What Does Work -
I also have a legacy data connection working. A DigiOne IAP used as a Modbus-RTU serial master to Modbus-TCP bridge that is successfully converting the old RS-485 Modbus serial master connection collecting data on a PC running SpecView version 2+ and connecting it to the new Modbus-TCP ethernet slave data connection from the Moxa MB3480. To keep the old data collection system working, while I build the new remote store and forward historian with Ignition. All of the old SpecView data comes out correctly in the right places after having gone through the SpecView modbus serial master to ethernet DigiOne bridge conversion and ethernet slave to serial Moxa bridge conversion.
The Problem -
Whenever I create OPC tags and connect them to SQL tags there is a skewed modbus register offset that seems dependent upon the device modbus address. For instance when I talk to a device with modbus address 9, the data registers are all offset by one place compared to the data from the device with modbus address 8. The data registers in each of the next devices are skewed one more place further in each subsequent device. This makes it very difficult to see the process value in the first register (register 1 in modbus or register 0 in jbus terms.)
Example-
For instance (these are not the actual register data, just some example numbers from memory to help convey the concept)
[code]MBus-Addr 8 9 10
E8_4001 0 E9_4001 100 E10_4001 30
E8_4002 100 E9_4002 30 E10_4002 1400
E8_4003 30 E9_4003 1400 E10_4003 9999
E8_4004 1400 E9_4004 9999 E10_4004 1550
E8_4005 9999 E9_4005 1550 E10_4005 0
E8_4006 1550 E9_4006 0 E10_4006 32767[/code]
I have tried starting with E8_4000 or even E8_3990 or E8_0001 and still see skewed data from the wrong data registers.
???
Have I missed something here or is there an issue with the Ignition driver and ancient modbus/jbus devices? Do I need to write my own TCP driver or pay for a third party OPC translation device like Kepware or Matrikon? I haven’t even begun to try to talk to the bitwise devices that are defined as Kevotherm devices in SpecView. I hope to get most of my process status bits from the AllenBradley SLC 5/04 PLCs already connected though 1761-NET-ENIs, since I can not find any references to a Kevotherm device anywhere.
The only thing I can think is to try the Ignition Modbus RTU over TCP driver again, but that didn’t seem to work using the DigiOne IAP as a multiple serial/ethernet master bridge that way either.
Please help save me from having to break out the serial protocol analyzer and write my own driver. Like when I had to write serial communication scripts in ladder logic to talk to a Prosoft module. That was two weeks of fun there alright, but this has been a few weeks of fun too.
Thanks!
S