modbus the open protocol

I am finally lucky enough to work w/ an actual high level programmer.
I can follow a tag from the pnp junction up to an hmi.
He knows the other side.
He often jokes that together, we actually make a good programmer.

He is starting to dive into the home made hmi aspect and data collection.

I'm explaining everything I know about modbus tcp to him.

I have to hold laughter back when I state things like: It's an open protocol.

Then he asks why 4X:12,289 equates to %MW1 or 40001 or 40002 et al.
It's just a serial modbus msg wrapped in a packet in a pocket in a socket....

LOL.

Make sure they know that the numbering system of the data and addressing models are inconsistent, arbitrary, opaque, ridiculous, poorly-designed, etc. E.g. the prefix (4 in 40001) of the model address is only a loosely-held convention that has nothing whatsoever to do with the function code e.g. function code 3 reads holding registers 4xxxxx and function code 4 reads input registers 3xxxxx.

The main tricks to getting it to work are

• deducing the data and wire addressing models for each party, client and server, and
• never assuming there is any kind of a standard for anything except the bits on the wire.

In light if that second point, it might be worth the effort to put a USB-serial port (or a TCP server on port 502) on a laptop and write a simple Python script to accept a client request; once they see the bits and bytes, the light should come on and the rest is bookkeeping.

As much as mock Modbus, the website at modbus.org and the protocol specification documents are pretty good.
_

Ooh. Don’t forget to mention that the data might be big endian, little endian. And… sometimes those may have their nibbles swapped “twisted”

ndzied1 said:

Ooh. Don’t forget to mention that the data might be big endian, little endian. And… sometimes those may have their nibbles swapped “twisted”

Click to expand...

I hate Modbus for that reason. It is a pain to support. On top of what Norm mentioned there is also the timing issue. Very few can accurate measure 1.5 or 3.5 character times as mentioned in the specifications.

Our tech support gets calls from time to time because a Modbus master cannot talk to our motion controller but it is ALWAYS the Modbus master's fault. We have Modicon PLCs here that we can test our software against. We have NO problems transferring data between our controller and a Modicon PLC. Even 32 bit data transfers without problems.

In short we consider being able to communicate with a Modicon PLC as the standard.

ndzied1 said:

Ooh. Don’t forget to mention that the data might be big endian, little endian. And… sometimes those may have their nibbles swapped “twisted”

Click to expand...

I assume this may have just been a joke, but if there is really a modbus device that swaps nibbles (4-bits), I would like to know it!

Actually not Nibbles, my mistake, Twisted is Bytes within words.

The attached image comes from the Galileo Communications Manual. Galileo is an HMI software from Eaton (originally from Moeller).

I have also found that while "station/node number" doesn't technically mean anything with Modbus/TCP some slaves will only respond if the requests include the right station number. Thankfully it has almost always been station 1 (as opposed to station 0)

Modicon PLCs use little endian twisted for transferring 32 bit values. Words are transferred high by first but DWORDS are transferred LOW WORD first.

Anyone can see there are too many ways to get this wrong.

ndzied1 said:

Actually not Nibbles, my mistake, Twisted is Bytes within words.

Click to expand...

This reminds me of a C modbus library I once used that covered it with the following functions:

modbus_get_float_abcd(3)
modbus_set_float_abcd(3)
modbus_get_float_badc(3)
modbus_set_float_badc(3)
modbus_get_float_cdab(3)
modbus_set_float_cdab(3)
modbus_get_float_dcba(3)
modbus_set_float_dcba(3)

https://libmodbus.org/docs/v3.1.7/

Meh. It's bookkeeping; having to diagnose any given implementation of the protocol may be annoying, but it's not difficult.

I'm in over my head...

Modbus just transfers raw memory from one device to another. If one device has big-endian words and the other has little-endian words, someone has to swap the words. Modbus is simple and efficient. The problem is not that is too complicated, but rather, it too simple to use directly between unlike devices. Some extra processing on one end is often required.

My pet peeve with Modbus is not the protocol, but the documentation that is often supplied with the supporting devices. All I want to see is a clearly organized memory map and how to set up the communication parameters (baud rate, IP addr, etc). There is no need to reproduce the entire Modbus protocol guide for every new Modbus device. That is well documented elsewhere.

I have written code to communicate with Modbus devices in VB, C++ and lately for Android.

It is a simple protocol, a good exercise to learn industrial protocols at a basic level.

I recommend going directly to Modbus/TCP, programming for serial port has little future. With TCP you also learn an interesting topic which is socket programming.

Endianness can vary both at the 16-bit word level and at the byte level.

A good Modbus client should allow you to choose the endianness of both words and bytes, the latter if you want to read/write character strings or individual bytes

kirkc said:

there is no need to reproduce the entire modbus protocol guide for every new modbus device. That is well documented elsewhere.

Click to expand...

+1!!!!!!
_

lfe said:

I recommend going directly to Modbus/TCP, programming for serial port has little future. With TCP you also learn an interesting topic which is socket programming.

Click to expand...

Yes

Endianness can vary both at the 16-bit word level and at the byte level.

Click to expand...

Yes, but it shouldn't. If you can't communicate with a Modicon PLC using 32 bit values, you are doing it wrong.

A good Modbus client should allow you to choose the endianness of both words and bytes, the latter if you want to read/write character strings or individual bytes

Click to expand...

I had this discussion with then SST. Unless the master allows a different endianness for each device the network will fail


Profibus had a standard which is big endian. I told SST to only support big endian and eventually they did. A thousand curses to Horner. Both Horner and Delta used x86 processors, which are little endian processors. However, we swapped the bytes around whereas Horner didn't. We would get tech support calls saying we were at fault. However, we were Profibus certified and Horner wasn't at the time.


You guys can believe how much time we have wasted on tech support because the bigger company does what it wants and not follow the standards whereas we pay to get certified for following the standards.


I AM VERY BITTER.

Modbus Register Maps

Modbus register maps are the armpit of all technical documentation. The issues with +- one register in the addresses and byte ordering have already been mentioned. But that is only the beginning of the definition problem.

Supported function codes need to be listed.

Data encodings need to be clearly explained. I ran into one case where negative integers used bit 15 for a simple sign bit instead of doing true binary twos complement. Bad firmware followed with poor documentation.

Implied decimal points on integers, read and write lengths, socket count limits, pipelining, and update timing issues all need to be addressed. I don't know if I've ever seen a register map that I really liked.

- - - -

On the firmware side:

I don't care what the spec says - if there is a 'hole' in the map where a register is not used and a long read crosses over the hole the server should stuff it with zeros instead of sending an exception.

Horrible arrangements of register maps frequently are the result of their being defined by computer IT people. I'd rather try to get a duck to moo like a cow than get an IT guy to define Modbus exchanges.

- - - -

On the end-user side:

Don't try to do Modbus work without first studying the protocol. It's not too complex and you'll have a lot less trouble if you do your homework first. And a lot less questions on the forums.

- - - -

I don't hate Modus. I use if for a lot of things and it works very well if properly applied. Don't expect a 50-year old Model T to run like a 2-year old Corvette. Run the car that you can afford that does what you need it to do.