TCP open connection LabVIEW: Serial port parity error.

[Olli]

Hello, due to some network communication errors the error message "LabVIEW: Serial port parity error." The only possibility to reset the remote port or the TCP open function is exit LabVIEW and restart it. Isn't there a possibility to clear the communication port directly in LabVIEW? I made some similar experience with serial communication...unexpected break of the communication leads to a complete loss of the communication and needs a reboot of the system ;-( My LabVIEW Version is 8.5.1 Does anybody have an idea? Thanks and greetings! Olli

[Tim_W.]

Hi Olli,

Are there any error numbers that come associated with the parity error you're seeing? Also, would it be possible for you to post your code up here?

Tim W.

Applications Engineering

National Instruments

http://www.ni.com/support 

[smercurio_fc]

I'm not sure why you're referring to serial port errors if you're talking about TCP. If you're referring to error code 61, that code has 2 meanings:

LabVIEW:  Serial port parity error.
=========================
LabVIEW:  The system could not allocate the necessary memory.

Thus, it's either one or the other. Are you sure it's not the second meaning that applies here?

[Olli]

Hello, Thanks a lot for the answers. The code is very specific, because I poll 5 Keithley 2701E and 3 Fieldpoints. If the VI is running there are two errors after a probable loss of network connection: error code 1 from the "TCP write" vi and the error 61 "from the TCP read" vi. yes, the second part of the error message is "LabVIEW: The system could not allocate the necessary memory." The strange thing is, that the communication VIs are running continously since summer 2007. I try to solve the network interuption problem on the other side, but I would like to protect the data acquisition in future. My experience until now is, that if there is a problem with serial (and now with TCP) communication the only measure to reinitialise it is to close LabVIEW completely and to restart it again. Right now I can see, that a part of the communication problem is caused due to memory issues (second part of error 61), because the problem occured now and I can see 100% CPU usage. I was able to reduce this with running a specific VI again on a fieldpoint controller (FP2015). This is now the original configuration as it was before the network problem occured. After this the data acquisition is running as before without restarting LabVIEW. I will wait now to the next longer network interuption...I'm starting to get the idea, that after a long interuption the data volume from all Keithleys and FPs is to big which might cause some data collision... Thanks for the moment! Olli

[Olli]

Hello, I still wasn't able to solve the hardware (network) problem...so from time to time my network connection gets interrupted while I have open TCP IP communications in LabVIEW. Then the only solution then, close LabVIEW and restart the VI's. After that, the TCP IP VI work well again. My question is: Does anybody know another possibility to close a TCP connection properly or even shut it down, when this occurs? Within LabVIEW I did not find any solution yet. Greetings! Olli

[Mark_Yedinak]

If you are waiting on a read without a timeout there is no direct way to abort the read. You have two options. The first would be to set a timeout on the read and check for some maximum time that you have not received any messages. If you have surpassed the time close the connection and open a new one. The other alternative would be to use no timeout on the read but have a watchdog task that is monitoring for inactivity on the connection. Your read would have to update a time value indicating when the last message has been received. In the watchdog task you would close the connection if the idle time has been surpassed. That will cause your read to exit with an error. You could then open a new connection.

[Olli]

Hello Mark, thanks for the reply! I spent now a day on testing the timing issues with the TCP IP communication VIs. I ensured that the data transfer between the Keithleys and the PXI is done really sequentially with enough time to receive all data after each reading request. Only a trigger message is broadcasted simultaneously (almost) to all devices from one Fieldpoint controller...and here's is the cause of my problem. The fieldpoint controller is connected on another switch somewhere else in the backbone than the one the Keithleys and the PXI is connected. For overvoltage protection reasons there are optical transformers betweeen the switches and the wired network. And these transformers sometimes fail on operation. If that happens while the communication is ongoing between the Fieldpoint and the Keithleys, the only one communication port of the Keithleys is blocked. I can unblock it with opening another port, that is only suitable for this purpose...but if the communication remains interupted, then also this port seems to be blocked in LabVIEW....I get also the error 63 when I try to unblock it (open TCP, send command; close TCP). After I restart LabVIEW then everything works fine again. That's why I wanted to find a software solution first, which does the same but without restarting LabVIEW. Probably it will be the best if I can connect the Fieldpoint directly to the same switch on which the PXI and the Keithleys are attached. Greetings! Olli

[Olli]

...this time it is error 63, not the 61 anymore