FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

12688 questions

15067 answers

24145 comments

47111 members

0 votes
272 views 11 comments
by

We have an install base of more than 200 TRB255 devices in the field that are all configured to work as a Modbus RTU to MQTT gateway.

We used a custom made application to accomplish this. Uptil now this has been working fine.

But with batch nr 13 a strange thing is happening:

We have to restart the application on the TRB device in order to prevent time out messages from happening on the RS485 connection.

I searched this forum to find a similar issue. I found one but it had a "PM", so I could not see the solution that was presented there.

The firmware: 

TRB2_R_00.07.00 | 2021.07.16

Again, it looks like it is only happening on devices with batch nr 13.
I have also tried the latest FW version with similar results.
Please advise...
Thank you..

1 Answer

0 votes
by

Hi,

To better understand this issue:

Do you refer to your custom application or the modbus master the one that you restart?
Does it improve if you increase the timeout of the slave device configuration under modbus master?
Do you have to do recurring resets or just once?
Have you tried it on latest FW TRB2_R_00.07.02?

In case issue persists consider sending me a private message with a troubleshoot file generated just after the timeout issue occurs.

Regards
 

by
Hi,

Can you share with me the batch number of other TRB255s that doesn't have this issue?

Anthony
by
Hi Anthony,

We have devices with batch nr 7, 8, 10, 11 and 13.

Except for batch 13, they all work fine. Meaning modbus RTU communication using the trb's /dev/rs485 device works right after startup.

With batch 13, serial timeouts occur and we have to restart our application to get the TRB to communicate with the connected heat exchanger.
by
Hi Anthony,

I have just sent you a PM with a picture of two TRB255 pcb's. One from batch 11 and one from batch 13. Details are in the PM.
by
Hi Anthony,

Referring to the pictures i sent to you yesterday in a PM. Could the indicated hardware differences be the cause of the reported issue?

Thanks in advance for your reply.
by
From the hardware perspective, batch 13 used a different RS232 transceiver chip, however, I do not think that it might be a cause of your problem.