Hey guys! I’m running into a weird problem with Modbus TCP.
The hardware is a Red Lion unit that’s configured using Crimson 3.1, and the Network protocol is set for Modbus TCP to transfer values to ignition.
I believe the issue is with the designer client trying to subscribe to the tag. But it also gets weirder because the values I’m having issues with are floats (mapped as holding register floats in ignition, but as 32 Bit Enron Values in Red Lion). The integers work great and are subscribable, but with the floats I’m able to poll them from the OPC Quick Client and get exactly what I’m expecting, but if I attempt to subscribe in the quick client it goes to 0. Which I figured after reading some of Kevin & Phil’s Modbus Magic Tips, that creating a new tag group that is polling instead of subscribed would fix, but it still returns 0. I assumed Enron would work because I’m getting the correct values in the quick client, but do I have to map the 16 bits individually to the registers?
It’s a lot and very convoluted so if I missed anything, please let me know.
Hey Phil! Yes, it’s IEEE 754 standard float, but it seems like Red Lion has some built in mechanism to get 32 bits through a single 16 bit register. I’m not entirely familiar with it, but here’s the link I found the information from - it may make more sense to you than it did me.
As far as more details, here’s what I can think of that is relevant, please let me know what else would be useful.
I’ve tried adding tags both by configuring tag addresses in the gateway and verified with the gateway quick opc client, a single read works but subscribing does not. When I bring in the tags via browsing, it returns 0 (expected is 10.23), and when I assign it to the OPC Read tag group (the only setting I changed was to set data mode to polled), it still returns 0, which is curious. I’m wondering if I’m not missing something in the OPC Read tag group settings.
The other method I’ve tried is creating a new OPC Tag, giving it the address of [DeviceName]1.HRF601 and trying it with both default and OPC Read tag group (same settings from above). This also returns 0.
I’m stuck for the time being, so any ideas are welcome!
I wasn’t able to get the 32 bits through the single register using your driver either, although there’s a solid chance it was user error. I plan on doing some more testing later, but for the time being it doesn’t seem like what Red Lion calls “Enron Values” are compatible with Ignition.
However, for anyone who comes across this in the future, I was able to resolve the problem by using the normal holding register and using data type “Word as Long” (Crimson 3.1). Word order has to be reversed in Ignition, but other than that it works like a dream. Phil, I have no question that your driver is more than capable of also getting the float values this way.
Also, thank you so much for your time! You were spot on and I was able to diagnose the issue after some light reading on wireshark. I’ll be going through with your Advanced Modbus Driver and updating this thread with that information as well since someone (probably me) will need more advanced features to work with floats at some point in the future.
Mmm, I should have clued in on the Enron thing faster. “Enron Modbus” is a Modbus bastardization/variant where, among other things, they decided that registers 5001 to 5999 are 32-bit integers and 7001 to 7999 are 32-bit floats.
This is obviously incompatible with any standard Modbus implementation, where a register at any offset is expected to be 16-bit.
Interesting. My driver can do that with system.opc.rawModbus, where a user can construct any arbitrary payload and expected response size required. Not supported in any other way. Let me think about this…
I think something you may have overlooked on your Red Lion documentation is that the Enron Modbus is only used when the Red Lion is running as a master (issuing the commands to something). When Ignition is connection to the system, the Red Lion is acting as a slave . In the documentation (https://support.redlion.net/hc/en-us/articles/360021391791-Modbus-Primer#:~:text=As%20a%20Slave%20Red%20Lion%20only), you will notice that for slave mode, it only supports the 2 register option, which is compliant with the typical modbus protocol, and always uses holding registers in this case.
I also would point out that if you are sending floats (or reading from a device that has floats), I’d recommend on the Red Lion configuration you choose Word as Real instead of Word as Long as it might treat this differently. Shouldn’t matter as both are 32 bits, but if the Red Lion has a local display for troubleshooting (software), it will show incorrect values.
