I don't trust the software you're using to snoop on this port any more than I trust Ignition's driver right now.
ok Fair enough, installing module as we speak.
Hmm, I just found something suspicious in our driver...
You said this was RS485, right?
Yup
Let me build a version that just sets this true and see if that actually means anything. We switched to a new serial library in 8.x and the old one didn't have a configuration option like this, so the driver never had a corresponding setting...
Will this show up under the device if i filter it that way on the logs?
No, doesn't have a device name associated with it. The diagnostic key is the port name I think. You can find the logger by its name under the log levels button on the log page.
Ok, this one sets that RS485 flag (and has the extra TRACE logging in SerialIODelegate)
Now getting this on the Status of my modbus devices?
Mmm... module must have failed to load or something? Send logs?
Hmm, maybe. No error on install, though. If you restart Ignition do those devices still have N/A status?
They are showing connected as expected after Restart.
Logs and Notepad headed your way.
Okay, one more: Dropbox - Modbus Driver v2-module.modl - Simplify your life
When a bad response comes back the driver doesn't read enough bytes, the CRC check fails, and the remaining bytes end up in the buffer still, then the next response piles on.
The problem is you're still going to see CRC check fails and subsequent reconnects, because this device is legit sending bad responses, and you can see them in both the serial logs and in Ignition.
First one here:
received data: [ 03 3A ]
received data: [ 01 ]
received data: [ 00 ]
received data: [ 07 ]
2022-11-15 14:30:09:055 drivers-modbusrtudriver-Gewiss_RCBOs-1 Received message: [ 03 3A 01 00 07 ]
The 03 3A bytes should have come after the subsequent 01 byte. The serial monitor sees the same thing, and logs it in this message:
103882: MODBUS Request (packet size: 125, data size: 121) 2022-11-15 22:30:19.0800704 +0.0000016
Mode: RTU
Address: 000003 (Slave)
Function: 000058 ()
Unknown Function!
CRC: 29776 (WRONG)
03 3A is slave id 3, function 58. Then it gets all mixed up as well.
This module should at least reconnect when this happens and get back into a good state until the next time bad data is received... but you'll still have comm quality blips while this is happening.
But these two are 10 seconds apart?
Is it certain ignition is not sending this message?
This error above is not showing up very frequently in the logs?
It doesn't show up every time we are getting the checksum error?
The serial software must be deciding its a response or a request based on its structure??
I'm not sure what it's doing exactly or why that timestamp is 10s off, but it can't be a coincidence that it sees the exact same out of order bytes we do. Must be related somehow. We're certainly not sending those bytes though.
It almost seems like it dumps that malformed response to its logs after the next request has been sent out and it still hasn't processed the previous response successfully.
102402: MODBUS Request (packet size: 8, data size: 4) 2022-11-15 22:30:09.0479776 +0.0000128
Mode: RTU
Address: 000001 (Slave)
Function: 000003 (Read Holding Registers)
� Starting Address = 5
� Quantity Of Registers = 5-33 (29)
CRC: 38338 (OK)
103142: MODBUS Request (packet size: 8, data size: 4) 2022-11-15 22:30:19.0576016 +0.0000144
Mode: RTU
Address: 000001 (Slave)
Function: 000003 (Read Holding Registers)
� Starting Address = 5
� Quantity Of Registers = 5-33 (29)
CRC: 38338 (OK)
103882: MODBUS Request (packet size: 125, data size: 121) 2022-11-15 22:30:19.0800704 +0.0000016
Mode: RTU
Address: 000003 (Slave)
Function: 000058 ()
Unknown Function!
CRC: 29776 (WRONG)
This is why it would be better to see the raw tx/recv bytes rather than another software interpretation of it.
Modbus RTU in software is actually relatively complicated because the dingbats who specified it all those years ago decided to use a period of silence on the line to indicate the end of a frame, rather than fence characters or a length prefix, and it's all but impossible to faithfully implement the spec in anything but a microcontroller with tight control over the serial IO.
Software implementations are all some kind of heuristic or state machine that can get into weird states when the data doesn't come in as expected 
Negotiable. I haven't tailored this module for Edge before.
Not by you, it’s a licensing parameter enforced by the OPC UA module.
1 Like
Thought so, but wasn't sure. I knew that it could vary, though. (:
1 Like