Rant: What are PLCs manufacturers thing?

[Peter Nachtwey]

While I am now retired, I still visit Delta a few times a week.
I saw an intern trying to write code to interface a Delta RMC motion controller with an ABB PLC using Modbud TCP. It wasn't working because the byte order was incorrect. The problem is that there is no specification for how 32 bit numbers should be transferred between devices. It seems that every one chooses what every byte order pleases them. A thousand curses on Modicon for not specifying a 32 bit standard/byte order.


Delta did what I think is obvious. I/we bought a Modicon PLC and figured out the byte order that a Modicon PLC requires to transfer 32 bit values. We think of this as being the unwritten specification for transferring 32 bit values. Delta motion controller have no problems communicating with Modican/Schnider PLCs.


However, many PLC manufacturers do what they want and still say they support Modicon/TCP when they can't really communicate with a Modicon PLC with 32 bit values.


So recently I went to Delta and I saw an intern ( noob of life ) trying to interface a Delta motion controller with an ABB controller. The noob was having no luck because the ABB PLC claimed to support Modbus/TCP but actually was not compatible at a 32 bit level. This is a HUGE problem. The noob, intern, was trying many things to make the communications work. I can see that it an wasted effort.


I do not like Modbus RTU or Modbus TCP/IP for many reason but mostly because of the specifications or people's unwillingness to support the specifications that do exits.


A thousand curses on them because they make our life much harder when our customers ask why it doesn't work.


Years ago I had the same rant with Siemens S7 plcs. Siemens finally fixed the problem with Profinet and the S7-1200 and S7-1500. However the S7-300s were always a pain to support. It wouldn't have been bad if the Siemens peoples could support them but they were always clueless or said it was a third party problem ( our problem ). Fortunately this problem has gone away.


However, now were are having problems with PLC companies that clam to support Modbus TCP/IP even though that can't communicate with a Modicon PLC using 32 bit values.

 

[drbitboy]

While I agree it is unconscionable to allow this situation in the first place, and even more so to be unwilling to fix it in the second, I can also see the silver linings: it does support an industry of people who understand my signature below; it both teaches interns to be more aware of their assumptions and earns them another thread in the tapestry of their careers.

It's sort of like the laws of thermodynamics: you can't get ahead; you can't break even; you can't get out of the game.

So while I have been in similarly frustrating situations, fully support the logic justifying this rant, and fervently hope there is some catharsis obtained therein, I also ask "What's the point? Because 'twas ever thus."

 

[modiconguy]

My fuel to this fire:

I've had a customer insist that there is no way to communicate with 32-bit numbers and that every number I put in the interface had to fit a single register.


I've used Schneider's own Vijeo Designer, which doesn't have a driver for communicating with their Modicon Modbus TCP PLCs, but includes a generic Modbus TCP driver that uses the "wrong" byte order by default!


Then of course there is the notation issue. Schneider uses the IEC %MW convention (for example, similar notation exists for coils and inputs), which needs an offset of 40001 to become a Modbus register, but of course that number increases to 400001 if you're on equipment that supports more registers.


I think we could teach a decent course on this protocol alone.

 

[cardosocea]

This reminds me of a little application I was doing as a hobby on an embedded processor using libmodbus and the utility functions they include like below:

modbus_get_float_abcd
modbus_get_float_badc
modbus_get_float_cdab
modbus_get_float_dcba

Really drove home how much of a mess it can be other than the typical 0 or 1 based addressing.

 

[harryting]

I'm always amazed how many devices today still use modbus and how they don't talk well to one another due to byte/word, 0/1, etc...

However, DNP put Modbus to shame on compatibility and not in a good way.

 

[Corsair]

Wait a minute!

Modbus is a 50-year old protocol that came into existence when some PLC stuff was still BCD. There was no PLC floating point, no PLC ASCII, no 32-bit integers, and sometimes not even negative numbers. They weren't even sure of what a communications protocol like that was supposed to do - hence all the bizarre Modicon-specific function codes that are published but should never be used.

Looking back with 20-20 hindsight the standards organization should have incorporated these things as they've come up. I agree that was a huge mistake. My personal standard is the same as mentioned - make sure that my default byte ordering matches a Modicon PLC and offer options for adjusting it as needed.

The problem here really isn't Modbus - the problem is that people are still using it. Don't complain about Modbus - switch to using something that is 40 years newer. Only then will we get over the endless confusion about register offsets, byte ordering, and so on. Ethernet/IP seems to have all that stuff well defined. Even the Modicon people are adopting it.

 

[Saffa]

I have to agree with Corsair... modbus is getting a bad rap here because people are trying to do stuff with it that it was never intended for.

Modicon also made it a non-proprietary protocol for open use... no control, no verification and approval process for compliance like OPC-UA or EIP etc.

And that is one of its strengths... its so lightweight you can implement the basics of it on a cheap micro for sending a few registers from a sensor, all the way up to a large PLC with several thousand registers being read every second.

And that has a downside, because everyone from the backyard tinkerer to the major automation company has their own implementation.

Swapping a few bytes isn't hard, and once you've figured it out for a device, you're golden. There are only 4 permutations for a 4 byte real.

Capable devices like Red Lion have an this easily selectable at the driver level.

 

[Toine]

You guys all make perfect sense, from different points of view. I understand Peter's frustration and have been through this myself a few times trying to connect to modbus devices from my PLC. It took some time to figure out the register addressing and offsets, as well as the byte order of sent and returned data.



The upside was that it raised a lot of awareness with me and on top of that it taught me a few tricks which are now good tools in my virtual tool bag. It helped troubleshooting and made me understand why protocol definitions deserve to be well and fully documented.

 

[danw]

Both the 1996 Modicon/Schneider Modbus spec, PI–MBUS–300, and the 2012 Modbus Application Protocol Specification V1.1b3, have the same definition for the response format for function code 03, Read Holding Registers, "The register data in the response message are packed as two bytes per register, with the binary contents right justified within each byte. For each register, the first byte contains the high order bits and the second contains the low order bits."

That byte order applies to only 2 of 4 IEEE formats. In the chart below, the FP_B and FPLB formats comply. I have rarely, if ever, encountered the other two IEEE formats.

Some freebie Windows Modbus Master apps only support one of the the two common FP formats, but the commercial masters nowadays seem to support a choice of the two for interpreting the received floating point data.

 

[Peter Nachtwey]

The problem here really isn't Modbus - the problem is that people are still using it.

Yes, but then they expect it to work between devices from different companies.

Don't complain about Modbus - switch to using something that is 40 years newer.

The problem is that people won't/don't and they still want support/help in making their connections work.

Only then will we get over the endless confusion about register offsets

The byte order for WORDSs is big endian. The word order for DWORDs little endian. If these rules are followed then devices can talk with a Modicon PLC. The problem is that many companies do what they want.

The timing for Modbus RTU is critical. Few companies support the timing specification.


On control.com it seems that every other post is about Modbus or Modbus TCP. Also, it should have been Modbus UDP not TCP. Some companies actually support a Modbus UPD.