LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

TCP connection error when sending MODBUS commands to WAGO 750-881 controller after 113655 bytes of data have been sent

Solved!
Go to solution

Hi all,

 

I am new to the world of labview and am attempting to build a VI which sends commands to a 750-881 WAGO controller at periodic intervals of 10ms. 

To set each of the DO's of the WAGO at once I therefore attempt to send the Modbus fc15 command every 10ms using the standard Labview TCP write module. 

 

When I run the VI it works for about a minute before I recieve an Error 56 message telling me the TCP connection has timed out. Thinking this strange, I decided to record the number of bytes sent via the TCP connection whilst running the program. In doing so I noticed that the connection broke after exactly 113655 Bytes of data had been sent each time. 

 

Thinking that I may have been sending too many messages I increased the While-loop delay from 10ms to 20, 100 and 200 ms but the error remained. I also tried playing with the TCP connection timeout and the TCP write timeout but neither of these had any effect on the problem. 

 

I cannot see why this error is occuring, as the program works perfectly up untill the 113655 Bytes mark. 

 

I have attached a screenshot of the basic VI (simply showing a MODBUS command being sent every second) and of a more advanced VI (where I am able to control each DO of the WAGO manually by setting a frequency at which the DO should switch between ON and OFF). 

 

If anybody has any ideas on where the problems lie, or what I could do to further debug the program this would be greatly appreciated. 

 

 

Download All
Message 1 of 7
(7,606 Views)

What happens if you add a TCP Read VI after the TCP Write (i.e. you wait for an answer from the controller) ?

 

Regards,

Marco

0 Kudos
Message 2 of 7
(7,547 Views)

Hello,

 

Is it always exactly 113655 bytes or rather somewhere around this amount of bytes?

What is the value of the "timeout" control you are using?

 

Aside from the test Marco asked can you try the following test:

 

Once you get the timeout error, can you then implement some error handling that performs this task:

- close the current connection

- reopen the connection

- resend the last image

 

I'm not proposing this as a permanent solution, but I am curious if this would work at your side.

Kind Regards,
Thierry C - CLA, CTA - Senior R&D Engineer (Former Support Engineer) - National Instruments
If someone helped you, let them know. Mark as solved and/or give a kudo. 😉
Message 3 of 7
(7,527 Views)

Hi ThiCop,

 

Yes the error occurs after exactly 113655 bytes every time. The timeout control I would like to use is 10ms, however even increasing this to 1s or 10s does not remove the error, which leads me to believe that this is not the issue (furthermore, not adding any delay to the while loop, thus letting it run at maximum speed, has shown that the TCP connection is able to send all 113655 bytes in under 3 seconds again pointing towards the timeout control not being the issue here). 

 

I attempted Marco's suggestion but an having difficulty translating the string returned into a readable string, (rightnow the response given is "      -#   +   ").

 

As to your second suggestion, I implemented something similar where I created a sub VI to build a TCP connection, send a message and then close the connection. I now build each message and then send the string to this subVI which successfully sends the command to my application. Whilst not being the most elegant method of solving the issue, it has resolved the timeout problem meaning I am able to send as many commands as I want. So in that sense the problem has been solved. 

 

If you still have tips on how to correctly read the TCP read output, I would however like to see if I could not get my first program to work as it is slightly more robust in terms of timing. 

 

 

0 Kudos
Message 4 of 7
(7,510 Views)
Solution
Accepted by topic author AvdLinden

@AvdLinden wrote:

Hi ThiCop,

 

Yes the error occurs after exactly 113655 bytes every time. The timeout control I would like to use is 10ms, however even increasing this to 1s or 10s does not remove the error, which leads me to believe that this is not the issue (furthermore, not adding any delay to the while loop, thus letting it run at maximum speed, has shown that the TCP connection is able to send all 113655 bytes in under 3 seconds again pointing towards the timeout control not being the issue here). 

 

I attempted Marco's suggestion but an having difficulty translating the string returned into a readable string, (rightnow the response given is "      -#   +   ").

 

As to your second suggestion, I implemented something similar where I created a sub VI to build a TCP connection, send a message and then close the connection. I now build each message and then send the string to this subVI which successfully sends the command to my application. Whilst not being the most elegant method of solving the issue, it has resolved the timeout problem meaning I am able to send as many commands as I want. So in that sense the problem has been solved. 

 

If you still have tips on how to correctly read the TCP read output, I would however like to see if I could not get my first program to work as it is slightly more robust in terms of timing. 

 

 


Modbus TCP RTU is a binary protocol, as you show in your Basic VI, where you format the data stream using byte values. So you have to interprete the returned answer accordingly with the Modbus RTU spec in hand. Now what is most likely happening is that the connection gets hung after a while since you do NOT read the data the device sends as response to your commands. The TCP/IP stack buffers those bytes and at some point the internal buffers overflow and the connection is blocked by the stack. So adding the TCP Read at strategic places (usually after each write) is the proper solution for this. Is there any reason that you didn't use the NI provided Modbus TCP library?

Rolf Kalbermatter
My Blog
Message 5 of 7
(7,499 Views)

Hey AvdLinden,

 

Please note that the simple test over here wasn't meant as a real work-around.

It doesn't fix the TCP/IP Stack buffer overflow, it would just make you ignore the problem (which is in general never a good idea).

You should perform these reads always after you writes.

 

Please also have a look at this page:
https://decibel.ni.com/content/docs/DOC-30140


Aside from the NILabs LabVIEW Modbus API it also mentions other options for Modbus communication in its "overview" section.

 

Kind Regards,
Thierry C - CLA, CTA - Senior R&D Engineer (Former Support Engineer) - National Instruments
If someone helped you, let them know. Mark as solved and/or give a kudo. 😉
Message 6 of 7
(7,492 Views)

Hi Rolf,

 

So I went back to my first program and thought I'd have a second look at the TCP read VI only now having viewed the Modbus commands, I saw that I would need to read out 12 bytes (In previous attempts I had followed examples online showing 512 bytes). Implementing this TCP read with 12 bytes solved the problem completely. All that remains is to translate these outputs into the Modbus format which shouldn't be too difficult. 

 

Thanks for the explanation on the TCP/IP buffers. 

 

 

0 Kudos
Message 7 of 7
(7,488 Views)