As you know in Modbus protocol if the ID, Function code, and length (no of registers polled) are same, data can be overlapped for two queries if the polling time is very fast as there is no other checking like address etc.

My application is polling the third party data (modbus based) on RS485. If I am polling data of same ID, same function code (Holding register 03), and no of registers (1), then data of two or more windows are getting overlapped. If I restart the application everything works fine for sometime. Then again this happens. Because of this SCADA is updated with wrong data.

Has anyone faced such issue?
What is the solution of this?

Please let me know.

Regards,
Anshuman

 

Hello,

Yes, this is a known issue with MODBUS.

I had a slave device once that on occasion would take a very long time to answer a read request. My program would timeout and send the slave another read request that happened to be a different set of holding registers but, the count value was the same. The slave would then answer the first request and toss the second request.

The only two solutions I found, mix up the reads so two adjacent reads did not have the same response profile and to lengthen the timeout value.

As the first line says, it is a short coming of the MODBUS protocol.

Good luck,

Mark
http://peakhmi.com/

 

It sounds like you have a synchronization issue, which can occur if you have a "dead" response already sitting in the RX buffer of the master before you even send the next request. This can occur if the master's timeout time is set too short. In other words, after a request the master believes no response is coming from the slave and so moves on to the next request, but in the meantime the slave actually does respond and this "old" response is now believed to be the response to the next request. From that point on, everything can be "off by 1" because the master will make a request, then check the RX buffer: usually it will have to wait until the slave actually responds, but now there is always a response sitting there (from the previous request).

Increase the timeout time to account for slow slaves, but more importantly the master should always flush the RX buffer when it starts to send a new request.

Darrin

 

This is a common issue in "packet switched" radio systems, because the radios do retries (etc), they can return old stale responses after your master has gone forward.

The ONLY fix (besides an artificially slow poll rate) is to make sure all of your requests are a different COUNT. So if you poll 3 registers with 3 different offset in the same slave, you will need to either poll them as 1, 2 and 3 registers respectively, or alternative between polling 1 & 2 registers. You just ignore the excess data received and use the 1 register you desire.

As long as your master code is smart enough detect the mismatch (so "I polled for 2 regs, but only see 2 bytes in response ... so discard"), then you will rapidly resync with only a few lost messages.