16 Bit Modbus Point to High Byte Low Byte

[Bmorrison]

Trying to find away to extract the high byte and low byte of a 16 bit modbus register. The high byte contains a min value and the low byte contains seconds that a Lufkin sam POC has been in a current state. 

[BevanWeiss]

The Modbus protocols don't really recognise 'bytes'.  Only registers in this context.

So, in Geo SCADA Expert you will need to pull in the whole register.  Then you can either use a pair of calculation points (my recommendation) or some logic to split the register into the upper and lower byte.

You can do bitwise AND and a shift, or bitwise AND and division depending on how you want to roll.

It will 'cost' you three licenced points to get your two pieces of data... but that's not so bad.

There are other options, but I don't recommend them... e.g. you could have some digital points referencing the bits of the register.. I believe the Modbus driver allows up to 8 states for digital inputs, so that would 'consume' up to 3 bits per digital.  Then you'd again use a calculation point to combine them... go the first route I propose though.

[du5tin]

Have you tried using the Lufkin POC Modbus driver? It might have support for some of the more esoteric points that are contained in a single register like these two you are looking at. 

There is a lot of "noise" in Modbus spec in oil and gas. This is just one of many examples. The Modbus driver in Geo SCADA covers about 80-85% of the edge cases but is sorely lacking in support for these sorts of things. Its been a massive thorn in my side my whole career. "Can we poll this with Geo SCADA?" "Yes, but a, b, and c don't work. Or the data is garbled. Or we get too many false comm fail alarms." "okay, don't build it then. we'll leave it in a different system or not poll it at all, too hard."

Being able to select High word/low word swap, high byte/low byte swap, maybe reversing the bits altogether. Being able to adjust the polling "map" or "plan" for devices that have "missing" registers and refuse to respond when GS requests too many registers at once. Enter AutoSOL ACM or Kepware or another OPC driver just to handle the weirdness we can often see. 

[BevanWeiss]

Quite a lot of the issues stem from vendors badly implementing Modbus.

Things like bit swaps simply shouldn't happen, it's pretty well defined in the Modbus spec.

That should mean even byte swapping shouldn't be an issue.

However, because Modbus was register based, and didn't define the ordering of values > 16bits, then word swapping is an issue.  My recollection is that Geo SCADA Expert supports this (when you use a REAL / 32bit INT you can select high word / low word, or low word / high word).

I have run into issues with devices that don't support full length accesses however.  And I'm not sure I'd consider this a true breach of the Modbus spec.. I'm not sure of a good way for Geo SCADA Expert to handle that however.

I can't even recall what exception code is returned for such overlength accesses.. I suspect it's nothing useful, potentially like 'Invalid access' or such.

It would be nice to support an upper bound on the data transfer lengths requested / issued.  This would then ensure that I don't need to put dummy gaps in my Rockwell ControlLogix ENxT ModbusTCP registers to avoid consolidated accesses exceeding the reduced transfer limits.

I might raise a feature request for this...

[du5tin]

I totally agree! We see all kinds of poorly made devices and improper Modbus support. I know its not really a problem the dev team should solve in the driver but clients buy hundreds of these bad devices and then expect them to work like an app on their phone. Its quickly become on of my pet peeves. The worst devices are those with single or two register gaps in the map (i.e. 40001-40007 are populated, 40008-40009 are empty/null, 40010-40020 are populated) and don't respond with data or an error if a request comes in for those 'empty' registers. These devices just silently fail and its up to the programmer to figure out why its not working. I've had to work with so many of these... 

If any transmitter or device manufacturer reads this in the future... in your Modbus enabled device make all the registers read something (even zero), use the same bit order and word order as the standard specifies, make sure data is always one register per data point, don't be afraid to use coils for statuses (I dislike packed bits, particularly for control), and definitely make sure your device responds with an illegal address or some sort of error code if the request is not supported!

[BevanWeiss]

Haha... the problems with standards 😛  There's too many..

Both you and I differ in our recommendation to Device Vendors also 😛

I would have:

• Ensure all data is exposed in Holding Registers (even if a copy is also exposed as Coils / Contacts / Input Registers)
• Ensure your Modbus register mapping is contiguous (no gaps)
• If ModbusTCP, ignore the Unit ID (unless required, such as where multiple sub-units are meaningful, and can't be implemented as unique device IPs..)
• Ensure that you support all lengths of read / write transactions (i.e. support both single register, and full length=125 register reads, 123 register writes)

Some Modbus clients (like Schneider M580 DTMs) can ONLY access Holding Registers.. Coils / Contacts / Input Registers just don't exist for it... which makes it painful when things are only accessible in Coils / Contacts / Input Registers.