Modbus TCP AOI for ControlLogix question

defcon.klaxon

Lifetime Supporting Member
Join Date
Feb 2015
Location
Far NorCal
Posts
616
Hi all,

I'm working on a wastewater plant where I have a ControlLogix PLC as the master PLC, alongside three packaged systems that are being provided by third parties. All three of the packed systems communicate via Modbus TCP. Unfortunately I was unaware of that during the design process, but luckily (I think) I came across the Modbus TCP AOI at Rockwell's website. I'm hoping someone has sufficient experience with it to help me out.

I've read through the guide and it seems pretty straightforward, but one thing I can't quite understand is how one would deal with integers and reals. When I check the Data tags, they're arrays of 1024 16 bit INTs for both Input and Holding registers. But if the data is a floating point, how is that handled?

For example, there are two ETMs for a pump; daily ETM is in holding register 40018 and total ETM is in holding register 40020. So I get how the transaction is set up, but when I go to the data in the tags, how do I "tell" the tags that the tag data spans two modbus holding registers? Let me know if my verbiage makes sense or if I need to clarify.

Is it as simple as using a COP function with the correct length?

Unfortunately the PLC is an hour round trip so it's not easy to test onsite because my budget is super tight, so I'm hoping to get this figured out before my next site visit.

Thanks for any help!
 
Last edited:
Not that I have any experience, but from what I have read, Modbus transfers always work on 16-bit boundaries.


So to get a (32-bit) real, the code should get the 16-bit INTs from the two adjacent addresses where the REAL is found on the packaged systems, and then use the COP instruction to copy (not MOVe) those bits into a REAL. There may be some byte order issues, but that is easy to figure out. If you have trouble, I suggest you also

  • COPy the two INTs to a 32-bit DINT
  • post what that DINT value is (in hex, preferably)
  • post what that REAL value *should* be
It is usually trivial to figure out what to do from there.



Cf.

 
In addition to the 16 bit register boundaries there is the usual big endian and little endian concerns like all modbus. There is no standard for data layout, it's the wild west and you have to use their protocol manual to decode it.

Getting a MODBUS analyzer is quite helpful in this regard.
 
Actually there is a version of Modbus called Enron/Daniels Modbus which was created to move "REAL" type of data. It uses 32 bit holding registers by way of a function code 16 with a size of 2 and a byte count of 4. It is a pain in the butt unless you know it very well.

With regards to the application, I'd look at deploying a gateway to bridge the EtherNet/IP to Modbus TCP. There are a variety of them out there but I like the Spectrum Controls Universal Gateway (for obvious reasons for some of you :whistle: )

As long as the Modbus TCP devices are Modbus Servers (slaves) it will be a very straight forward application which from what I understand can't be said about the Rockwell solution especially if you aren't well versed in Modbus.
 
I am very familiar with these AOIs.
Client AOI blindly brings data from Server to the client. It does the byte order management. But you may need to do 16-bit word order.
Specifically, in your case, it will be command 3, start 17, length 4
This will get two 32 bit values packed in four 16 bit registers (40018-40021). Then you need to figure byte order and possibly use SWPB to get it right.
 
Last edited:
Don't worry about byte swapping yet. My experience is the first thing to try is to simply COPy (not MOVe) the bits (2 INTs into one REAL) and see what you get. That will have one of two results:


1. If it works and you see a REAL value consistent with expectation (876.543furlongs/fortnight;)), then your heart must be pure, God bless you, you are done, Amen.

2. If it does not show a reasonable number (e.g. you get -1.234e+38), then there are only so many possibilities. Dump the INT values in hex, and find out what a reasonable expectation is for the REAL value corresponding to those INT values, post everything here and someone will tell you how to re-arrange the bytes.

In my experience, that process is usually much quicker than trying to figure out a priori what byte re-ordering is necessary from documentation, and a reasonable portion of the time it will require no re-ordering.
 
Last edited:
Of course, be aware that there is no such ting as "reals" in Modbus. You need to manipulate to map whatever you need to. Reals are definitely not adopted by most. Experiment and see if you can do memory mapping in appropriate order. Yes, it is a PITA.
 
With regards to the application, I'd look at deploying a gateway to bridge the EtherNet/IP to Modbus TCP. There are a variety of them out there but I like the Spectrum Controls Universal Gateway (for obvious reasons for some of you :whistle: )

I am VERY interested in that Spectrum Controls Universal Gateway, looks like a really cool solution. They will provide a demo unit for a 30 day demo, I ordered one today!

edit: just realized it only has a single ethernet port, but all my devices are on ethernet...damn.

especially if you aren't well versed in Modbus.

I actually am pretty well versed in Modbus from years of testing and really weird comms issues, so at least I have that going for me!
 
Last edited:
edit: just realized it only has a single ethernet port, but all my devices are on ethernet...damn.

Use a switch. You will want a switch anyway so you can configure it and connect it to at least one Ethernet device (at the same time). It will do multiple Ethernet protocols simultaneously (EtherNet/IP and Modbus TCP for example) as long as you have a switch in line. Don't use a hub (if you can even find one).
 

Similar Topics

Hello, I am trying the AOI provided by Rockwell to read Modbus TCP, the version is 2.04 The connection looks good to the modbus server. I...
Replies
4
Views
547
So I am working on a project and I am having problems trying to get this all to work. I had it working but lately I have been getting a fault on...
Replies
13
Views
4,727
Dear Forumers I'm developing an ESS project with Compact Logix L36ERM and using the MBTCP Client AOI from Rockwell. I'm using 4 AOI blocks for...
Replies
3
Views
1,270
Good Afternoon , I have a project coming up for a labeler and a CompactLogix PLC . The communication for this labeler is Modbus / TCP ...
Replies
1
Views
2,147
Hi all, I've been trying to get Modbus TCP to communicate (read only) with the Modbus TCP AOI that Rockwell provides, but I'm having issues and...
Replies
2
Views
2,096
Back
Top Bottom