FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

We are migrating to our new platform at https://community.teltonika.lt. Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
0 votes
502 views 11 comments
by anonymous

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 anonymous
Thank you for the reply. Yes, it is a custom application. The modbus master is not used.

Only after a complete device reboot or startup (when the application has just started) I just have to restart the application for it to function correctly. This is only the case with batch nr 13. And yes, I have tried FR TRB2_R_00.07.02 with similar results.

I also tweaked the timeout but without any possitive effect.

I will send you a PM with the troubleshoot file. Can you explain how to generate this file?

Thank you.
by

Sure,

Access the WebUI, go to System > Administration > Troubleshoot, click on download button nex to troubleshoot file.

Download it after the issue occurs in order to capture the events on logs.

Regards

by anonymous
I have a tar.gz troubleshooting file waiting to be sent. How can I send a PM through this forum?

Thank you.

Edit: Found it. I just sent a PM with the requested file.
by anonymous
AnthonyUE,

Did you find the chance to have a look at the troubleshooting file that was sent to you?

Thanks...
by
Hi,

I looked at your TS file and I don't see any modbus related settings nor Data to server/MQTT Gateway service configured.

What kind of modbus are you using, is it as Slave or Master RTU?

Can you elaborate more on your topology and services running for your application?

Regards
by anonymous
That's correct. The modbus to mqtt (and vice versa) is arranged by a custom application like mentioned before. I do not use any MQTT Gateway service or modbus service the platform provides. Because they do not fit the needs for our use case.

The only thing I use is the device /dev/rs485 (symlink to /dev/ttyUSB0) and I make sure it is not occupied by any other running daemon. The custom application acts as a modbus RTU master and communicates with a heatexchanger system (modbus RTU slave).

So I am guessing that the issue I am facing with has something to do with rs485 direction control not working properly the first time the rs485 device is up and running? I do not see any way to access this as I think it is controlled from a kernel module or maybe even completely by hardware. The latter would explain why we only have this issue with batch number 13. Maybe there is something different about batch 13 compared to previous batches hardware? You can see "evidence" of a custom application being present by looking at the kernel.log and search for the words "serial timeout".

Any more thoughts?

Thanks in advance.
by
Hi,

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

Anthony
by anonymous
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 anonymous
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 anonymous
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 anonymous
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.