So, how do you find out what it is each time?
Can you set up the connection with a single tag reading only holding register 10427 per the screenshot of the documentation? I'm also curious if you use the modbus master simulator, can you read that register without sending the security code/password.
As per your screenshot, the passcode is hard coded at 500, which I would think means it shouldn't change unless there's some configuration in the device to essentially make it near impossible to connect by randomizing the code. I would understand changing it from default, but no reason it should be changing on its own.
I also suspect something else completely different going on here. I've had weird flaky issues in the past with a manufacturer actually sending out multiple devices with matching MAC addresses causing network packets to be sent to 2 different devices and causing headaches until it was discovered. You might also make sure there's no duplicate IPs on the network just to make sure you're not chasing the wrong problem. (Can you isolate this device to make sure there are no conflicts like either of these?)
1 Like
Sorry I was wrong about the password changing
I was wrong about the password changing on reboot. I have amended my post earlier. I have the device on a test bench in my office, so I don't believe that duplicate MAC addresses are the cause (I have seen manufactures do what you describe though). I have verified the IP address is the only one on my network by pinging it (It went through) and unplugging the Ethernet cable. Then the pings failed.
I can read register 10427 with my Modbus master simulator without writing the password.
I can not read it with the Ignition opcua tags.
Next logical step would then be to set up a single Ignition tag to read only that register, and see if the connection stays alive. Disable all the other tags. If the connection stays alive, then we can go from there. You might also try turning off Span Gaps in the modbus driver configuration. I've had other devices (Micro8xx in particular) that will cause issues if any optimization by the driver is trying to read nonexistent registers, and this usually fixes that issue.
no luck with spanning gaps off. I have checked the slave ID and it is correct. I moved it off 255 just in case it didn't like it and still no luck
Part of your problem is you have the Modbus address format wrong. You have an extra period/dot before the slave ID.
You have: [2DSLC].255.HR10427 and it should be [2DSLC]255.HR10427
Yep that was wrong. As well as I needed to turn on Zero based addressing, and turn off spanning gaps.
I am now getting data from the DSLC but it is behaving weird. I have a code level of 0 ie I have not login yet, but I can still see ALL the data from device. And when ever I disable the device and reenable it, I get the device disconnecting and reconnecting.
has anyone see this error before? I was under the impression that it was because of not having the correct code level to access a data point I was polling; but now that I can see the data with a code level of 0 (not login in) I am rethinking that.
I am still getting this error after I disable and enable the device in opcua devices.
"End of stream reached" means the other end cut Ignition off.
All, I would like to thank everyone for helping me with this issue. I have found the solution and will leave it here for future reference.
I found 3 issues that was stopping communication:
-
Flakey Network Port
I can not get consentient pings to one of the 3 network ports. (The one labeled "For ModBus TCP" infuriatingly enough) I switched to another port and will reach out to manufacture for more info. -
Does not like to use ModBus TCP Slave ID 1.
For some reason this manufactures ModBus TCP stack doesn't like to talk to ignition when I use slave Id 1 so I have changed it to 255. No reason for 255, just that it is a easy number to remember. -
Polling Rate. The main issue (I think). Apparently the 1 second default polling rate in Ignition is not fast enough. The device is closing the connection before any ModBus commands are sent. I set one tag to be in a faster polling tag group (500 ms and set it to Polling rather than subscribed) and that was enough to keep the connection alive.
On further experimenting, its not the time that the critical variable. Its setting the tag group to be polled or subscribed.