Modbus TCP bugs after error 53

[ethibault123]

Hi,

I am using the modbus library developped by NI to communicate to a slave via modbus TCP. Basicly, what I do is I read around 15-20 registers continuously in a while loop. Everything works fine until an error 56 (e.g. a timeout) happens.

After that timeout, the software continue to communicate continously in the loop but, all the registers are wrongs and randoms. The reading is not going well at all, its like if everything go crazy and the software access wrong and ramdom registers each time the loop is executed, until I close the TCP connection and re-open it again using TCP CLOSE and OPEN CONNECTION VIs.

Am I missing anything? Is there any operation I should do after a TIMEOUT to continue running normally? If I compare with serial modbus RTU, a timeout results only in an empty reading and the following iteration, everthing is back to normal. Why TCP timeout is different?

Thank you

Eric 

[fromm8]

Hi Eric,

Which VI is showing the error 56 or 53? Is the TCP listen VI?

Regards

[ethibault123]

Its error 56... title is wrong...

The VI returning the error is the write or read on modbus TCP. Until now, the only solution I found is to reset the TCP connection (close it and reopen it again).

Eric

[Jesse_D]

Hi Eric, 

It sounds like there is a logic problem within the library, I would troubleshoot it like any other piece of code.

Why are you using the free modbus library? We have undertaken a re-write of that library that will be supported in the long term but are not maintaining the code on the white paper. Can you use the DSC module in the mean time? 

[ethibault123]

Jesse,

I use this library because it is the only one I found. If NI develloped a updated version of that library having better performance, I would be a buyer! Is it available already?

Please let me know about that updated library and let me know if you find anything about that bug I reported.

Thank you

Eric

[Jesse_D]

Hi Eric, 

It isn't released yet but we have hopes to get it out quickly. If you can, I would just make sure the modbus functionality of the DSC module works for you and use that. If not let me know and we can keep working on this bug. 

[ethibault123]

Hi Jesse,

I had quick look to the DSC module description and I am not sure how this can help me and how this could be related with my bug. Can you please explain to my why you recommend me to use this?

Thanks

Eric

[fromm8]

Hi Eric, let me point you to additional documentation about this module. You are going to find more information about the realtion between this module and Modbus.

Using Modbus I/O Servers (DSC Module or Real-Time Module)

Introduction to Modbus

How LabVIEW Uses I/O Servers

Finally, at the resources tab, you could find the help manual and the getting started manual.

NI LabVIEW Datalogging and Supervisory Control Module

Regards

[S1ack]

What is the timing of your while loop?

The timeout implies the slave cannot keep up.

How do you know the slave is not acting up?

I use this library all day every day to talk to multiple slaves from various vendors, and have never noticed such an issue. Then again, if I get any modbus error, timeout, invalid address, illegal function etc..I immediately hang up (close tcp) and re dial (open tcp). This is managed in a little 3 state Case structure.

The I/O server may work for your scenario - but I found the library much more flexible.