Bad_CommunicationError: A low level communication error occurred.
Having a comms issue with a particular RS485 device.
I am fairly certain this is not an end device issue as if i use a 3rd party software, hitting the device at 1 second rate, I am getting 0 comms drop offs.
However today, when investigating the issue i get the above error on the tag, and the logs are showing some checksum errors at times too.
Architecture is an Onlogic IPC with ignition edge installed.
We have 5 device connections utilised.
We have a modbus 485 device connection to com port 1 of IPC.
Slave address 1 with no other slaves on daisy chain.
I was seeing alot of comms issues last week until i changed the tag group data mode to polled, i got 0 comms drop offs in over 1 week.
IPC was shut down, and has been power back up today and we now have the problem occurring again.
The Bad_CommunicationError quality/status is because of the checksum failures. The timestamp you're seeing is the null/0 value for an OPC UA timestamp.
Other than checking that your serial settings are correct I'm not sure what else you can do besides find some kind of serial port sniffer or tap and look at the serial traffic as a sanity check.
edit: you might try turning of the "reconnect after consecutive timeouts" setting as well. If nothing else this will clean up the logs a little, but I'm also seeing a bug where a checksum mismatch response doesn't reset the counter that counts timed out requests, so eventually what looks like just one request timing out could cause a reconnect, which causes all outstanding requests to fail.
Well I'm not sure what you're asking about then. If you have multiple masters on this line then it's not surprising you get inconsistent results. If you don't, then I don't know what you were referencing.
I think there is some confusion on the original ask.
Let me see can I explain.
I do not have multiple masters.
You suggested using a sniffer, which I thought would not work with RS485 RTU only allowing 1 master.
You also suggested turning off Reconnect after 3 Consecutive timeouts.
I replied saying it was already turned off and that raised another question, why is the device connection showing disconnected in the logs.
I highlighted I don't think this is field related because if I use a 3rd party software instead (Not in parallel because this is the same as 2 masters and does not work) of ignition, I am not getting any errors.
Have you tried to access the requested registers with tools like QModMaster in order to ensure that Modbus RTU connectivity is working properly. Of course you need to temporarily disable Ignition as it's acting as RTU Master in the 485 serial chain.
Set the log level for the logger you find searching "ReadHoldingRegistersRequest" to TRACE and let's see if the request/response bytes are making sense.
Not that this is necessarily an issue, but you're actually polling more registers than you think in this configuration. It's going to ask for 28 registers starting at offset 6 (5, really, at the protocol layer, unless you have zero-baed addressing on). This is because span gaps is on. If you turned it off then you'd have more requests for less registers in each request.
Ok, I have turned off Span Gaps and it actually makes the problem worse.
Now i seem to be getting vlaues back on HR6 mush more consistantly than the rest. However, it does still drop off in data quality so doesn't seem to have fixed anything.