We have a new program were we are getting bad values on MODBUS tags for both coils and holding registers. We have no issues with reading input registers. We’re comparing the project to one we had in 7.0 which had no issues. Tags are set for R/W and Read Only is set to False for the OPC Connection. Any suggestions for further troubleshooting?
Look for log entries for the particular device(s).
I’m getting the following.
ReadHoldingRegistersRequest 09Mar2022 11:15:04 Received response with ExceptionCode: 0x02 (IllegalDataAddress).
If I change [ModbusTCP]HRF01 to [ModbusTCP]IRF01 and try to read an input register, the tag works. I can confirm that both exist in the PLC.
That message is only possible if the PLC actively rejected that address. (Either of the two addresses that comprise a float.) Look closer at the PLC.
Also, its important to understand that Input registers occupy an entirely different memory location than holding registers. By changing HRF to IRF you are accessing something entirely different.
Understood. I’ve confirmed it’s not the PLC because I can access the holding register 40001 using modpoll
modpoll -m tcp -t 4:float -r 1 -c 1 172.16.0.3
It’s the only holding register.
I’m also able to access the coils using modpoll but not ignition.
Use Wireshark to spot the configuration differences.
For example Modpoll defaults to slave/unit 1 by default, Ignition defaults to 0.
This is one of the few spots where I think the Ignition default is wrong. Slave address "0" is defined to be the broadcast address. My alternate implementation defaults to address 1.
Actually for Modbus TCP (as opposed to serial) you've got it wrong.
The "Modbus Messaging Implementation Guide" recommends using 0xFF or 0x00 for Modbus TCP, both accepted as a "non-significant" value that can be used for direct communication with the device.
Hmmm. Found it. Interesting. I have to admit I find that segment of the implementation guide to be less than satisfying. Particularly the statement: “On TCP/IP, the MODBUS server is addressed using its IP address; therefore, the MODBUS Unit Identifier is useless. The value 0xFF has to be used.” This statement comes right after describing how the unit identifier could/would be used in a bridge device.
I think I’ll stick to a default “1”.
What does Ignition default to for Modbus RTU and Modbus RTU over TCP drivers?
Zero still because those came later and were derived from the TCP driver, and because the unit/slave is specified in the address and the address parser is entirely unaware of what driver variation it's parsing for.
mine, too. (:
I also wanted my Server implementation to provide a consistent view of multiple units worth of data regardless which transport is used (including simultaneous access by divergent transports).
Wireshark indeed shows unit 1 for Modpoll and 0 for Ignition.
In lieu of using [ModbusTCP]C04, I had to use [ModbusTCP]1.C04. Is there a way to do this globally instead of tag by tag?
No.
Switch drivers.
{ / Shameless self-promotion. }
1 Like
lol, do tell. Something must have changed in Ignition because I’m using the same PLCs (Micro850) and I didn’t have to add the “1.” in 7.9. I also still don’t understand why Ignition doesn’t communicate to the native tags in these PLCs when every other SCADA or HMI that I’ve used does.
The Micro8xx family doesn't follow Rockwell's published data access manual's rules, and includes pure CIP data types not supported by other Logix processors. Ignition's driver pretty strictly follows the rules.
I'm working on a client driver in my Ethernet/IP module that handles generic CIP data access and unbrowsed symbolic tag access. Hit a roadblock, so alpha will be in April.
Awesome. I saw that Kepserver may be able to be used so I was going to possibly give that a try.
Yeah, Kepware has a Micro850-specific driver.
It’s still vaguely on our roadmap (or more like my wishlist) but because you can currently get connected via Modbus it just keeps getting de-prioritized for other drivers and projects.