IEEE754 conversion - 32 bit - Modbus TCP

[ndzied1]

Hi There.

This topic came up recently at our place. One thing that can be helpful is this site that shows the hexadecimal representation for Floating Point or REAL numbers:
https://baseconvert.com/ieee-754-floating-point

Every PLC I Have come up against so far uses this IEEE-754 format for Floats or REALs.

I also made a CoDeSys simulation that tries to demonstrate what happens when you interpret the REAL value in the wrong way. Here is a video of me going through the simulation:

 

[Peter Nachtwey]

You can ignore most of @Peter Nachtwey's Myth of Modbus Mayhem.

You haven't been in situation where there are multiples Modbus devices on a RS-485 line and each device implements Modbus RTU differently. The same goes for Modbus TCP. This requires the master to have different ways of flipping the bytes and words around for each device. Yes, it can be done but it is a pain.

I have always been one for following standards or conventions. A thousand curses on Modicon for not defining 32 bit transfers. What I did is said that being able to send and receive 32 bit values with a Modicon PLC is the startard. Unfortunately, too many did their on things. What p!$$e$ me off is that the customers always assumed we were wrong. ABB p!$$e$ was a culprit. We are the mighty ABB and all you other fools are wrong.

I had the same problem with Profibus. All the data was sent with the high word and high byte first. I got into a p!$$ing contest with Horner. Their PLC was Intel or little endian. Our RMC100 was using a 80186 at and was also Intel based but at least we swapped words and bytes so we could become Profibus certified. I had to tell customers when they complained to us that our motion controllers didn't communicate that we follow standards. I know there is a Profibus certification. I think there was a Modbus TCP/IP certification too where we had to send a controller back to the Siemens or Modicon labs to get certified. Sometimes our programmer had to go back with the module.

Also, I know that Ethernet/IP and Profinet have "plug fests". This is were a lot of the vendors get together so test if each device can talked with all the other devices. Sometimes they can't even though all are certified. This happens when there are two different interpretations of the specification because something isn't defined very tightly. This usually results in the specifications being updated to close "Loop holes"

Drbitboy hasn't seen the chaos like I have.

Modbus/TCP should be augmented with a Modbus/UDP. Modbus/TCP or for passing data and Modbus/UDP is for passing I/O.

 

[drbitboy]

Drbitboy hasn't seen the chaos like I have.

Oh please. I have been in tech my whole life and I am almost as old as you; do you really think that is true? Or maybe I just have a different response to the chaos because I know where it comes from?

I worked in the broadcast industry controlling video and audio switchers and routers to PCs over serial and TCP/IP connections. I don't think I ever saw a protocol document without a "DRAFT" watermark. I built diagnostic tools and figured it out to get t'job done.

Byte order is a "problem" that will likely never go away, at least not in our lifetimes. I wrote a server to use RA, DEC, and magnitude to find stars in the 1.7Gstar catalog quickly using the R*tree feature of SQLite. The server code figures out whether the client request uses LSB or MSB, and returns data accordingly. Putting that single fix into the server saves all clients from having to deal with it.

Yes, I fully agree with Peter that standards intelligently defined and accurately followed make our lives easier and would be oh so nice if universal, so we could all hold hands and sing kumbayah.

But I live in the real world, would prefer to laugh than rant, and am more interested in getting t'job done than being right.

My original point for the OP was that at least with Modbus there are only a limited number of binary mistakes any implementation can make, so the problem is finite and solvable, and the diagnostics, to figure out what is actually going on, are trivial to create and implement. I.e. it's a tempest in a teapot.

P.S. my "real world" point of view aside, that is hilarious about Horner and Profibus byte order. Who would be too lazy or ignorant to not get the byte order right? And then publish it? Thanks Peter, that's my one good belly laugh for the day. You should write this stuff down and publish it.

 

[Ken Moore]

What is even worse, is when one vendor implements MODBUS TCP differently on different product lines. I once worked on a project, where they were bringing in all the switch gear information to a DCS. The Medium voltage gear, and the low voltage gear were not the same. One required a word swap, the other a byte swap. I had tested in our shop and got everything figured out on a low voltage model. Then on site commissioning found the differences in the two. The Vendor was EATON, and their excuse was two different voltages, two different development groups, two different standards.

 

[danw]

Different divisions, different implementations.


I had two Phoenix Contact products with Modbus RTU from two different divisions where each device had the polarity of its RS-485 driver lines (A/B or +/-) labelled the opposite of each other.

 

[Peter Nachtwey]

Oh please. I have been in tech my whole life and I am almost as old as you; do you really think that is true? Or maybe I just have a different response to the chaos because I know where it comes from?

You deal with one set of equipment. Now what do you do when you have 10K+ motion controllers out there?

Byte order is a "problem" that will likely never go away, at least not in our lifetimes.

We need more stillborn people like me that won't compromise and force others to adhere to the standard. Now that I am retired I don't care that much.

The server code figures out whether the client request uses LSB or MSB, and returns data accordingly. Putting that single fix into the server saves all clients from having to deal with it.

yes

But I live in the real world, would prefer to laugh than rant, and am more interested in getting t'job done than being right.

Yes, one job, not hundreds.

My original point for the OP was that at least with Modbus there are only a limited number of binary mistakes any implementation can make, so the problem is finite and solvable, and the diagnostics, to figure out what is actually going on, are trivial to create and implement. I.e. it's a tempest in a teapot.

The customer deals with it only once but there are 100s of customers that must waste their time dealing with it.

P.S. my "real world" point of view aside, that is hilarious about Horner and Profibus byte order. Who would be too lazy or ignorant to not get the byte order right? And then publish it? Thanks Peter, that's my one good belly laugh for the day. You should write this stuff down and publish it.

[/quote]
published here. I have lots of stories. I remember having conversation with SST about Profibus byte ordering. SST originally made their software so the byte order could be swapped but not on an individual device level. One time they had a customer that had different devices with big or little endian.


We spend money to get our products certified and even then got to the swap fests to ensure compatibility with other certified products so they can sing kum by yah together. we don't need others wasting our time or blaming us for their failures.


BTW, control.com gets lots of posts about Modbus RTU and Modbus/TCP. I have ranted about Modbus there too. When there are a lot of questions about something then there is something wrong.Examples are doing indirect addressing on the S7-300 and AB PID where many don't set the update rate correctly.

 

[OkiePC]

This where driver vendors need to take a page from Red Lion and allow byte swap and word swap at the driver level AND at the device level.

Hell even the endianness between a SLC and Micrologix is Backerdz when messaging floats using DF1!

 

[drbitboy]

You deal with one set of equipment. Now what do you do when you have 10K+ motion controllers out there?

But that is not OP's problem, is it?

Also, how many of those 10K+ actually have this problem? Isn't it only those purchased by customers unfortunate enough to buy non-standard devices to connect to them? If I work for that customer, then I solve it. If I am selling motion controllers then I tell the customer to get better devices.

If it's 10K+ motion controller purchased by a single customer at a single site, then I get or build protocol converters, and charge the customer through the nose for it.