1

We have hardware in the field which communicates at a variety of different baud rates using RS-485/Modbus RTU (1200, 9600, through to 115200).

The firmware running on our device has a small bug in it, where the Modbus RTU response delay was fixed and calculated based on running at the 115200 baud. The issue went unnoticed until recently one of our customers began using the 1200 baud rate. It appears the 115200 response delay was adequate for everything down to 9600.

At the 1200 baud rate though, the first byte of the response packet is being missed (I'm assuming due to the time to takes to switch over from sending to receive at the 1200 baud). If a large packet is being requested things are ok (because the time it takes the device to put the packet together makes up for the lack of delay) although most packets are being corrupted.

Upgrading the firmware on these devices already in the field to use the correct/longer response delay is not an option unfortunately. Does anyone have any ideas as to how we can retrieve the full packets at the 1200 baud? (with the incorrect response delay that is currently causing 1 byte to be missed)

The only idea I could come up with was requesting an excessive amount of registers from the software with each request to cause the delay to increase.

Belgin Fish
  • 19,187
  • 41
  • 102
  • 131
  • 1
    Presumably your *"hardware in the field"* are slave devices? The [Modbus spec](http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf) does not mention anything about a minimum *"response delay"*. Are you referring to the 3.5 character delay between valid RTU message frames? – sawdust Jun 27 '20 at 19:07

1 Answers1

1

If I understand your question correctly I had this same issue once.

I was called to troubleshoot a very unreliable Modbus link that was failing pretty frequently but for short periods of time, it was working normally.

After checking all other obvious parameters I hooked up my scope and this is what I saw: scope capture Modbus collision

As it turned out there was an issue with the firmware on the slave: it was firing its Modbus answer immediately after receiving the stop bit of the query. So part of the answer was transmitted before the master had time to free the bus (yellow arrow on the picture).

At the time we were not happy with the prospect of updating the firmware on the salve so we first explored other options. The best thing we came up with was a setting on the master (a PLC from Schneider Electric) that allowed to tweak the time the bus was asserted by the Master after its stop bit.

This is how it was defined in the manual:

PLC manual

I vaguely remember we were able to improve the situation but there was a watchdog triggering an alarm somewhere every time there was an error so this solution was not considered acceptable and we had to update the firmware.

Somehow related to your question, I once measured the time it takes to free the bus using hardware direction control versus a software solution. You can see some details here. If updating the firmware is a no-go for you I guess messing with the transceiver won't be an option either... At the end of this question I linked a circuit to toggle the direction control line of an RS485 link automatically. That might be a (admittedly terrible) solution if your Master is not able to toggle faster.

Marcos G.
  • 3,371
  • 2
  • 8
  • 16