Error reading data from a slave device during periodic polling via Modbus-TCP

[GrayyR]

Hi.

Error 56 occurs during periodic polling via Modbus-TCP: "The network operation exceeded the user-specified or system time limit". The next read operation causes another error - "The communication between the Modbus master and slave devices was interrupted. Check the connection status between the two devices". All of the following read operations cause the same error.

Traffic analysis using WireShark shows the following:
The application continues to poll the slave device, and the device continues to respond.

LabVIEW 20.0f1 (32 bit)

Question:
Why does an error occur if the device is responding? How to resolve the error and continue to receive data from the device?

Thank you.

[MaSta]

What about the 4 hour difference in the timestamps in LV and the Wireshark log?

[tst]

I don't have experience with those specific Modbus VIs, but it looks like the timeout is being set to 300 ms at the beginning of the code and indeed you don't see a response in the Wireshark log and you see a timeout error on the LV side.

For the subsequent errors you see, the error does tell you that there was a comm error and to check the comm between the devices. I'm guessing the library remembers that there was an error and expects you to handle the error yourself somehow (for instance, by closing and reopening the connection or maybe it has a VI for checking and clearing the error) and continues to output its own error even though the code went back to working.

As for the time difference, presumably either LV or the Wireshark log show the time in GMT.

[GrayyR]

---

@MaSta wrote:

What about the 4 hour difference in the timestamps in LV and the Wireshark log?

---

The reason is different time zone settings. The main thing is that mm:ss correlate in two sources.

[GrayyR]

---

@tst wrote:

I'm guessing the library remembers that there was an error and expects you to handle the error yourself somehow (for instance, by closing and reopening the connection or maybe it has a VI for checking and clearing the error) and continues to output its own error even though the code went back to working.

I expected a different reaction:
- A successful read operation clears the error.
I don't know how to remove the error without closing and opening a new connection.

[tst]

---

@GrayyR wrote:

---

@tst wrote:

I'm guessing the library remembers that there was an error and expects you to handle the error yourself somehow (for instance, by closing and reopening the connection or maybe it has a VI for checking and clearing the error) and continues to output its own error even though the code went back to working.

I expected a different reaction:
- A successful read operation clears the error.
I don't know how to remove the error without closing and opening a new connection.

---

A reasonable expectation, but I guess that's not the case. Like I said, I have no experience with this library, but I believe those are NI's Modbus VI for RT and the DSC module. It's possible that for something that runs in a real time target they wanted the user to more explicitly handle the error, although I'm not sure why that would help.

You could use other Modbus implementations for LV which don't behave like this. There are several.

[GrayyR]

You could use other Modbus implementations for LV which don't behave like this. There are several.

---

Thanks, I'll take a look at other implementations.
But my question remained unanswered. Maybe in the future someone will explain this problem.

[tst]

---

@GrayyR wrote:

But my question remained unanswered. Maybe in the future someone will explain this problem.

---

I would suggest trying to see if the VIs are open and if you can look at their code to see how it's implemented. Maybe there would be some comments there or looking at it would make it clearer. I would also suggest using the example finder to see if there are example which show how you're expected to handle this.

I agree that requiring you to close and reopen for every timeout error doesn't seem to make a lot of sense, but like I said, I'm not familiar with that library.