Bad_CommunicationError: A low level communication error occurred.
8.1.21
Hi folks,
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.
I don't believe so.
Any time I would have needed multiple masters before I would have always put in a TCP gateway and hit its from whatever server needed to poll from.
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.
Still a mystery. Without the actual logs I can't confirm if you're just seeing logs from other Modbus devices or there's just some bug causing that.
I'm talking about using something like this, which just analyzes traffic on an already open port. Unfortunately this particular software does not support RS485 in the free version.
What software? Running on the same server or a different machine? Are you certain it checks the CRC? Is it requesting the same registers as Ignition?
So that log is filtered for the Device name so they are all coming from that particular device connection.
The 3rd party software I am using is below.
You can see on its features on right hand side that it does offer Reverse CRC.
Is this the same as what you are asking when you say "checks the CRC"?
Yes I am requesting the same registers.
I am only polling 6 registers.
Ranging from HR6 - HR34
I have Span gaps enabled, I have tried previously to drop the Max number of holding regs per request but does not change to outcome.
The register HR34 is 1 registers I want to write to, however because of my lack of experience with how this behaves, I has disabled this tag to remove it from the question for now.
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.
From the logs it just looks like there's something wrong with your device. Looking at where (one of) the first CRC mismatch occurs, you see this request:
Starting at the byte count this is a bogus response. A register response should never indicate an odd number of bytes, and we requested 24 registers.
I don't know if something is wrong with the device itself or at the serial layer, but the driver appears to be doing the best it can with the bad data being returned.
