LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Problem communicating via Modbus TCP with Honeywell UDC3200

Hello:
 
I have to read the temperature of the Input 1 of this controllers. I've succesfully read the temperatures in the controllers. I'm using Modbus TCP/IP for the communication through the NI Modbus Library 1.1. I'm working on LabVIEW 8.5.1. However, sometimes when I open the connection, I get error 56 (timeout), despite that the controller responds to a ping. When I can initiate all the connections to the controllers, some hours after the monitoring has started, randomly, I get an error 66 (the connection was closed by the peer). This error interrupts the connection and the temperature readings stop. This is not acceptable.
 
Also, I've found out that if you don't request some data from the controllers in 5 seconds or more, also the error 66 appears. To solve this, I poll twice a second the controllers but the error 66 still shows up.
 
The controllers and the PC are interconnected via an Ethernet switch. The switch works well.
 
In brief, I can communicate with the controllers but the communication is not reliable. Sometimes when I start the communication I get an Error 56 and sometimes after the communication starts I get Error 66. It cannot be predicted when this will happen.
 
Why does the error 66 appears?
Has somebody communicated succesfully with this controllers?
 
I'd really appreciate your help, I'm running out of time.
 
Thanks in advance.
 
Robst.


Robst - CLD

Using LabVIEW since version 7.0


0 Kudos
Message 1 of 4
(4,133 Views)
 

hello Robst. This error 66 that appears in your screen might refer to a file initialization problem.

 

Also check if there is no other application that interferes with your communication port. Go to the menu tools >> options and check the VI Server configuration. About the succesful communication with the UDC3200,

Error 56 generates after transmision of information is faster than what the VI´s for TCP/IP can process. Depending on your program, you might want to check if the loop where time is critical sleeps after sending the information for enough time to let the communication VI to send all the information, or try sending fewer amounts of information in a period.

0 Kudos
Message 2 of 4
(4,108 Views)

Hello:

Thanks for answering Pedro. I've read the document you told me to, but it refers to problems with VI Server, the application is not using VI server, so I guess the problem comes from somewhere else. I still haven't figured out why this is happening.

About the Error 56, well, I'll try to slow down the communication, I'm not doing any delays after sending the information. I wasn't aware that I needed to do this.

Any other ideas?

Thanks in advance.

Robst.



Robst - CLD

Using LabVIEW since version 7.0


0 Kudos
Message 3 of 4
(4,105 Views)
Make sure your not trying to read a register that is one off.  ie modbus is zero based but some controllers are not.  Nobody says they have to follow the rules even though they claim it uses modbus.
 
Look at the register set from the manufacure and try reading a three register set target -1, target, target +1 and make sure they are what you expect to get in return from a read.
 
an easy area to confirm this is reading the device name, serial#, or date....
 
Hope this helps
Tim C.
1:30 Seconds ARRRGHHH!!!! I want my popcorn NOW! Isn't there anything faster than a microwave!
0 Kudos
Message 4 of 4
(4,096 Views)