Consecutive Modbus Registers are Unique Float Values from Sensors

Ignition
1

The setup

  • [Server] ThermoFisher AutoPILOT Pro Multi-Run HCF setup as modbus RTU over RS232

  • Server → GE MDS 9810 spread spectrum radio remote → OTA → GE MDS 9810 spread spectrum radio master - Client

  • [Client] Ignition 8.1.4, Raspberry Pi 4 8GB, Latest Raspbian, Onboard Physical UART TTL → RS232 Serial [Updated from 8.1.3 to 8.1.4 since original post, changed from USB->Serial as well - no change, of course, just keeping fresh]

The config

  • Ignition Edge w/ Serial client & Modbus modules

  • Device [MoTex] - Modbus RTU over serial (/dev/ttyAMA0)

    • Span Gaps disabled
    • Zero based addressing enabled
    • Allow Read Multiple Registers Request disabled
    • Attempted change word order - different results, but not correct ones

  • OPC tag sample

    • [MoTex]7.IRF6201
    • [MoTex]7.IRF6202

[MoTex] = device
7 = modbus server address
IRF = Input Register Float
620* = Register

Modbus registers are 32bit(Flt) - ThermoFisher’s words

If I configure the Modbus RTU device in Ignition to allow reading multiple registers in one request, I get the full value of the 6201, in my case System Date written as a float representing MMDDYY (as in 040121 for April 21 2021).

However, 6202 is quite obviously only one half of the 32 bit float.

If I turn off reading multiple registers, and of course flood the interface → radio → network → server with single requests, all data comes back correct

Of course, I have to increase timeouts and tweak some settings to ensure that all 450-ish tags on each of the nine devices can be retrieved reliably (read slowly).

This is incredibly confusing to me as I would expect that ThermoFisher would have 6201-6202 assigned to just System Date. Thus when I make my calls, I could retrieve the values appropriately. Span Groups would be problematic - or not - but I don’t think that would matter overall or at least yet.

Have you seen this behavior in a server any other time? Or perhaps I am just completely missing something (most likely?).

My desire would be a successful read per server of all tags, or at least only four or five instead of 450ish.

Update: Still have not resolved the issue via ThermoFisher but did create a new set of custom registers in the 65000 range and set them to be 2-16bit(32Flt) rather than the default 32bit(Flt) that the other registers have. This changed the incremental registers to be written increasing by 2. Update soon on the troubleshooting to read them, and final resolution of identifying the default ThermoFisher setting as the root problem.

2

This simply isn’t supported by our driver because that’s not actually Modbus any more. If that’s really what’s going on there’s not going to be a reliable way to read these floats.

When you use the IRF syntax what the driver does is read 2 consecutive registers and combine them.

These addresses have overlapping registers:

    [MoTex]7.IRF6201
    [MoTex]7.IRF6202

The lower word of the first will be the same as the upper word of the second. The driver will read 3 registers from the device to accomplish this (6201, 6202, 6203).

In a device that actually supports Modbus and is defining a 32-bit float on top you’d typically address it like this:

    [MoTex]7.IRF6201
    [MoTex]7.IRF6203

requiring 4 16-bit registers in total.

3

That is exactly what I observe. Thank you for confirming. The ThermoFisher team is watching this closely as I have challenged them a bit on why things don’t seem to be quite right.

I can setup another custom range of “modbus registers” in their configuration and intentionally skipping the evens. What a pain, but it seems that would be the logical path forward and not be hung with making so many individual calls.

Any obvious flaws with that logic? I’m quite new to this and happy/eager to learn more.

4

That may work as long as they treat those registers as 16-bit values and not 32-bit values and you can ensure your float values get written across the 2 registers it requires.

1 Like
5

Thank you Kevin - I am scheduling time to get out to the field this weekend so I can test this out myself. I will ask the TermoFisher team to also confirm on their side, the tech team is pretty great to work with and are committed to seeing me successful

Quick aside, I acquired these as incumbent devices on a gathering system in February - no registration/no questions asked by ThermoFisher - lifetime support, period.

I will add any new learnings to this thread.

6

Let me know what you find. It may also be useful to get some Wireshark captures of the traffic for debugging purposes.

1 Like
7

slaps face Yep, not sure why I have not already done that very thing. I started in to this with the feeling of learning rocket surgery and abandoned the basics of troubleshooting. I can do that right away as I can manage the Ignition Edge host reliably, remotely.

One day I will be confident enough to write settings to the AutoPILOTs, but that isn’t today. Thanks again!