Modbus Simulation Tag Errors

Ran into an error when setting up a Modbus device simulation, and would like to see if there's a good explanation for it. The sim is writing values to the holding registers, and Ignition tags are pointing to them via OPC Item Paths like so:

ns=1;s=[Modbus502]1.HR1
ns=1;s=[Modbus502]1.HR2
ns=1;s=[Modbus502]1.HR3

and so on.

I noticed that when scripting out the generation of the device connections and tags, if even one tag is created that tries to point to a register that does not exist, i.e. ns=1;s=[Modbus502]1.HR0, the entire set of OPC tags for that device faults and returns as bad. The device connection is still good, and the modbus sim is still generating as usual, but all tags stop reporting new values and have bad quality until the offending tag is removed and the otherwise good tags restarted. I've since adjusted the scripting for device and tag generation to avoid this problem, but would still like to know if this is something anybody else has come across and has an explanation for, in case something like this comes up in the future when setting up simulators like this.

That's how Modbus, and any other protocol addressing simple, linear memory layouts tends to work.

Your request for "HR1 through HR3" became "HR0 through HR3", and at the Modbus protocol layer, your whole request is now bad.

A more realistic example might be that you define HR10 in your simulation, create a new Ignition tag for it, but HR4 - HR9 still don't exist. Your request is now for HR1 - HR10, and an implementation that doesn't return a default value like 0 for registers that are undefined will now return an error for the whole request.

2 Likes

Interesting, thank you. Good to know for future sims that the whole block will need to be getting at minimum a default value if I still intend on wholesale scripting the tag generation.