Digi IAP communicating to Contrologix via Modbus TCP

Hi, to all.
I have a yokogawa controller YS-1700 which can communicate via Modbus/TCP. and I will be talking to a Contrologix PLC using a Digi IAP through the plant network. This is my first time using a digi and just don’t know how to start. I already have all the IP adresses to the Digi, Yokogawa controller and PLC, and I am able to ping them from my PC, but I need help to continue.


This document should help you get things set up: http://ftp1.digi.com/support/documentation/90000647_B.pdf


This document explains how the DCS acting as a Modbus/TCP master can poll a ControlLogix indirectly as-if it were a Modbus slave.

You’ll need to make slight modification to the ControlLogix program to enable “SLC5/PLC5/PCCC mapping”, which means link the old PLC idea of a file or table number (like B3 or N7) to the tagged (named) variables which exist within the ControlLogix. this is required to even enable a SLC5/05 or PLC5E to query the ControlLogix, so is not something just required for the Digi One IAP.

Thank you both for your info, I follow both of your advices, and now I am able to communicate with the controller, as far as reading the data, but I can not write to it, my message instruction errors every time, with an error that says “Illegal command from local processor”. I apperciate any help. Thanks again, Chava

Take a look at my web page here and obtain a “trace” of the IAP’s messages during both a read and a write:

Be aware that not all Modbus requests can be mapped to AB - for example Modbus allows me to write 3 bits starting with the 4th bit, whereas AB only allows writing full 16-bit words. There is no safe way to map these 2 without considerable effort or risk. Same is true of reads, but the DOIAP cheats a bit and just masks/shifts off the 13 extra bits returned by AB.

Also, ControlLogix is bit inconsistent in how it handles types. At times it is happy treating any tagged variable as bools or integer or floats; at other times it rejects an integer read of floats. This seems to have been getting more strict as the RSLogix5000 releases update.

So you will find reading/writing into ControlLogix tags which are 16-bit int arrays to be the most predictable. Always use Modbus 4x0000 style cmds to rd/write full words. Then use ControlLogix ladder or code to move data in/out of this 16-bit int array.

Lynn, I run an event trace like you sugested and the digi is getting the request from the PLC, but somewhere in the log says “Illegal Data Adress”, and I am not sure what address is talking about, because the register that i want to write to, is the correct one. If you have an e-mail address I could send you the log file so you can see it. Thaks for everything.

Sure - it is lynnl at digi dot com.

Unfortunately the AB PCCC list of meaningful error codes is worse than Modbus’s (both are too short). The only error the ControlLogix will return is STS=0x10, which means “format error”, which just means “I didn’t understand or like your request”. DOIAP maps this to “illegal data address” but that doesn’t mean it was an illegal data address - just that the CLgx didn’t like the PCCC request.

I suspect it is a typing issue - for example while CLgx may allow a PCCC integer read to a float tagged data object, it may NOT allow a PCCC integer write to the same float tagged data object. I wise this weren’t so complex … but it is at times :-\

What is your CLgx data type?

Sorry about the mis-spelled name.
The data type was integer, I changed to Double Integer and the message is fine, no errors, but NO data was written to the controller. The log on the Digi said that the write command was complete. There could be something on the controller not configured correctly. Once again thank you very much, I will keep on trying at least now I have my messages going through.

no, lynn is my name - not my email :slight_smile:

lynnl adds my first initial of last name

As we speak, Rockwell and Schneider-Electric are joing forces and officially defining a way for CIP Originators (ie; ControlLogix) to query Modbus slaves. This will even allow a Modbus device to participate in a producer/Consumer (I/o Messaging) system. So “soon” I’ll have a more formal, Ethernet/IP aware way to bridge Modbus and AB. No promise of when this hits the street or IAP firmware though.