Modbus RTU over ethernet data loss

D

Thread Starter

Dan

Hi all,

I'm using Qt framework to encapsulate the Modbus RTU request over TCP/IP, which goes to the TCP-to-serial converter, then goes to the slave device.

The response I get is incomplete data. It seems loss. I have set various timeout of the TCP-to-serial converter for buffering the response from the slave device, but the data response is still loss. How do I handle this problem?

Thanks,
Dan
 
If try you read N bytes from TCP/IP you might get less bytes because TCP/IP is stream oriented. If you want to read exactly N bytes you must do a loop until you have got the complete block of data.

From the modbus header you will exactly know how much bytes must be read.

You must also do such a loop when writing.

Here you can find our modbus implementation:
<pre>
http://pvbrowser.org/pvbrowser/sf/manual/rllib/html/classrlModbus.html
</pre>
 
D
Hello!

We are having the same problem. We have a RTU device connected to a serial/ethernet converter. We are using Modbus RTU to communicate. Sometimes when reading one register at a time, we dont receive the correct information, the expected modbus frame, sometimes, most of the time we do. But, this problem is Always happening when reading a specific register which returns a large amount of bytes (240 to be exact). In this case, only the 40 or 60 first bytes are correct and the rest is not. We have validated that the response contains 240 bytes, no more, no less, but for some reason those last bytes are not what we expect.

Do you have any suggestion?. Could it be data loss? I am not sure, as we are receiving the correct number of bytes we were expecting. Could it be related to syncronic reading? Should it be asyncronic?.

Thanks,
Dona Rosado
 
Hello,

I would expect it more as a coding problem on the receiver. Depending on the TCP/IP code; the code might be what is called non-blocking and the code is getting multiple callbacks for when new data arrives. Example, the code is expecting 255 bytes. First callback has 125 bytes, second callback has 125 bytes and the finally callback has 5 bytes. TCP/IP can break up the data into chunks. Always in the correct order. The receiver code is expecting all bytes in one callback. That would be an error.

If the TCP/IP code is blocking then normally it has at least two parameters. #1 number of bytes to read. #2 Timeout to wait for bytes.

Wrong #1, obvious failure, wrong #2 the timeout value needs to be increased.

More troubleshooting data would be needed to offer other causes.

Good luck,

Mark
http://www.peakhmi.com/
 
D
Hello Mark,

Yes, I got your point. It seems we are asking and expecting N bytes and assuming that all of them come in a single response. In this case, asynchronic Reading could work? or how can I wait for all the bytes, just counting the number of bytes that I received en each response?. In the other hand, when we asked we receive the number of bytes that we were expecting, so that is why we think we have all the data, but when analizing its content we saw most of the bytes are not correct. The question here is why even I receive the number of bytes expected they are not correct?. I know problem is in the Reading side, but I dont know what could not be working. I have increased the timeout as well, but problem persists.

Just to explain what I have connected. I have a Floboss F407 connected to a Lantronix serial/ethernet converter, connected to a laptop (ethernet port). I have my own driver running modbus rtu. I have checked the frames I use to ask and they are correct but sometimes frames I received are not.

BR,
Dona
 
Hello,

Depending on the RTU driver some drivers are time based. The original MODBUS specification was time based for end of frame. That will not work with TCP/IP.

If your driver is the master sending the request then you know how many bytes to expect the slave to return.

If your driver is the slave, after the first 5 bytes you can determine how many bytes are to arrive except if an error is returned.

If it is an error response then it is 9 bytes. (Those byte counts are from memory, could be wrong, I would need to look up the specification.)

>?. In the other hand, when we asked we receive the number of bytes that we were expecting, so that is why we think we have all the data, but when analizing its content we saw most of the bytes are not correct.

>"Floboss F407"

#1 That sounds like an overflow or circular buffer that is not maintained correctly.

#2 Are you sure this is regular MODBUS and not Enron MODBUS? Or some other MODBUS flavor?

I have seen the two (regular MODBUS and Enron MODBUS) mixed in "flow" devices before and it can be confusing reading the correct registers if regular MODBUS only.

Rereading you original post, it sounds like #2.

>Sometimes when reading one register at a time, we dont receive the correct information, the expected modbus frame, sometimes, most of the time we do.

Does that mean the frame is correct, including the CRC, and the data is wrong? That points to #2.

>But, this problem is Always happening when reading a specific register which returns a large amount of bytes (240 to be exact).

A single register does not contain 240 bytes in regular MODBUS. A MODBUS variant might send 240 bytes when a single register is read, but not regular MODBUS.

Good luck,

Mark
http://www.peakhmi.com/
 
D
Hello Mark,

Yesterday we did a lot of tests and we found out that, We need to do various request until we get the expected CRC from the response. Then, this frame is correct and contain exactly what we need.

Our problem here is CRC16 generation. We discovered that when requesting one specific register or two or a few, our app generates the correct CRC16 but when requesting a huge amount of bytes (240 to be exact)the CRC16 generated is not correct, so even response is correct and has the correct CRC, we are not able to collect the data, as both CRC16 are not the same.

As you mentioned, Reading a specific register is MODBUS and Reading historical register is MODBUS ENRON, and this is the case, because we are trying to read historic registers related to alarms/events and daily/hourly data.

Our question now is, is it different to generate CRC16 for MODBUS than generating for MODBUS ENRON?.

Best Regards,
Dona
 
Hello,

> Our question now is, is it different to generate CRC16 for
> MODBUS than generating for MODBUS ENRON?.

Yes the CRC calculation is the same for MODBUS and ENRON MODBUS, IIRC.

We have a free ENRON TCP/IP slave simulator, if needed.
PeakHMI has Enron drivers and you can use the demo installer for testing, if needed.

Good luck,
Mark
http://www.peakhmi.com/
 
C
Sounds like a speed problem. Works fine most of the time, but once in a while the receiving end gets busy and a buffer fills or something like that.

If it's at all convenient, I'd try a baud rate faster and one slower and see what happens. Some of the converters I've seen are a bit naive about the real world. And you can try hooking directly to the RTU if you have that capability and see who's lying. But it's strange that you wouldn't get checksum errors if what was received wasn't what was sent. In fact, you might look into that. Unless the converter completely strips and rebuilds the message with a new checksum, I'd suspect the RTU actually sends garbage once in a while. If the Ethernet part uses TCP/IP you have a reliable protocol with a checksum. Errors should be detected.

Regards
cww
 
Top