Using TRB145 as ModbusTCP/RTU GW (modbustcp_over_serial). It seems, that the timeout to close the connection is too short, because the response from RS485 may arrive later than TRB145 expects. And why to close the connection after all, can it be kept open?
See the log below, reading unit 11 registers 19…20 (using a pymodbus based tool):
read(11,19,2)
2025-01-24 09:23:50,552 - SEND: 00 20 00 00 00 06 0B 03 00 13 00 02
Holding register read exception: Modbus Error: [Connection] ModbusTcpClient(10.203.0.18:502): Connection unexpectedly closed 0.267093 seconds into read of 8 bytes without response from unit before it closed connection
read(11,19,2)
2025-01-24 09:23:59,231 - SEND: 00 21 00 00 00 06 0B 03 00 13 00 02
Holding register read exception: Modbus Error: [Connection] ModbusTcpClient(10.203.0.18:502): Connection unexpectedly closed 0.264148 seconds into read of 8 bytes without response from unit before it closed connection
additional information: the latest FW 07.12 is not any better.
RTU slave is always answering, I can see it on TX/RX leds on the slave device. Also, there are no problems at all if I communicate with the slave via USB/RS485 cable.
also CRC control disabling has no effect.
the latest fw has timeout parameter, tried 5 and 10 s there, no diff.
It seems to me there is some dependency on query/answer content, bc some of the registers are easier to read than the others. see below polling reg 13 vs reg 15.
read(11,13,2)
[0, 0]
read(11,13,2)
[0, 0]
read(11,13,2)
[0, 0]
read(11,15,2)
ERROR:controller.comm_modbus:Error: Modbus Error: [Input/Output] Modbus Error: [Invalid Message] No response received, expected at least 8 bytes (0 received)
read(11,15,2)
ERROR:controller.comm_modbus:Error: Modbus Error: [Input/Output] No Response received from the remote unit/Unable to decode response
read(11,15,2)
ERROR:controller.comm_modbus:Error: Modbus Error: [Input/Output] No Response received from the remote unit/Unable to decode response
One additional bit of information, perhaps important. Accessing TRB145 with ModbusTCP queries over OpenVPN, TRB is the client. Exactly the same way of access was used with RUT955, which behaved flawlessly.
looked at the line voltages with scope and it is clear, that the host is responding, but the response is mostly ignored by TRB145.
but could it be there is something wrong with the RS485/422 line driver of TRB145? the line voltages during query are different and spikey compared to the much nicer response. the lines is connected as instructed, 1-2 B, 3 GND, 4-5 A. no full duplex in setup.
there was no problem at all with RUT955, but I cannot take line voltages image from that any more.
looked also at the RX pin of the driver chip inside TRB145. looks like it gets some data on query using fc 03 from slave 11 (0Bh). but other than the few first bytes seem corrupt, as the CRC (2 last bytes) is invalid.
the slave has resistors connected to the line, as it should: 120 Ohm between A-B, 1.8k from A to 5V, 1.8k from B to 0V.
Hi Marija,
this problem cannot be related to the software version - it’s clearly a hardware design issue. If the data frame is arriving invalid from the receiver chip in TRB145, then there is no way it can be fixed later in the software.
And this is not a single device hardware problem - have tested 3 different devices. They behaved similarly. Currently I have no TRB145 at hand any more to test, but Teltonika is welcome to provide me one for free for further testing. But surely you have a scope in your company and can compare signal patterns from the different routers RS485 lines yourself. This way you can also verify if they depend on sw version or not - I believe not.
BTW, the second query-response above should have been labeled as line B.
