My three months worth of hard work but UDP issue

[KWaris]

Hello everybody.

I developed the code, took me three months and turned out its very good. Does the job and customer very pleased as long as I am the first one to come up and turn the computer on. This is because I know a little secret to make my executable work.

And that secret is to shut down the labview application, turn it back on, keep doing it until the computer establishes the communication based on UDP protocol with the instruments. This project is based on cRIO 9012 controller and 9112 FPGA chassis.

Computer IP address: 192.168.0.180

Instrument A IP: 192.168.0.175

Instrument B IP: 192.168.0.165

Instrument A: Port labview uses on windows to write to this instrument is 4243

Instrument B: Port labview uses on windows to write to this instrument is 4243

Both Instruments are similar and listen using only 4242. This is a single block diagram architecture based on many loops and hosted on windows target.( I do sometime thinks that if I had 9014 controller, I could have implemented the whole software on Real time controller but thats beyond the scope of this problem.)

I increased/varied the timeouts, made the while loops which deals with UDP communication during initialization iterate until communication is establish but to no avail.

The conclusion is the following statement

' Sometimes when the labview application runs, a communication port on windows operating system may locks up. The only way to release the port is by shutting down the application completely and restarting it again'.

I just dont want the end customer to start this mission critical application knowing that the instruments may not communicate on initialization and they may have to close the application few times before it starts kicking.

Please help.

These are famous error 56 and error 66 and I did everything for instance varying timeout values, waiting longer before quitting while loops but nothing worked. It could help if I just can programmatically determine if at a time windows port e.g 4243 is locked up?. If so, It will help further, if I could unlock the port?

I am just talking vaguely and have very limited knowledge on network communication especially when windows home operating system is involved. I am just slightly worried that the customer waited so long and the whole software application works a treat except that there may be some occasional communication problems on initialization.

Any comments will be very appreciated

Kind Regards

Austin

[ShaunR]

Are you trying to open the port on the LabVIEW side twice? You can only open a port once or, more specifically, you can only bind one socket. If you are trying to "multicast" then you must use a multicast address, however, you will still open only one socket.

[KWaris]

The initialization vi only calls UDP Open in the Initialize Case, then iterate to the next state where it writes a telegram to the instrument then iterate to the next state to read the response.

Its a while loop which iterates fifteen time unless the UDP read vi reads the data within the timeout period specified. It appears as if sometimes it reads this test telegram and sometimes the UDP read function fails to read it. As I have the error cluster wired up to all subvis, the subsequent code doesn't execute and the error flows through the error clusters.

One thing which is slightly out of the scope of this problem. I would appreciate if it could be commented as well. Why I dont see the Labview error dialog box in my executable but I see them while running the executable?

Thx

[asbo]

UDP is lossy, so what are the chances your infrastructure is dropping the packet somewhere? It may not necessarily be the software's fault. Diagnostically, you can use something like wireshark and netstat to make sure your traffic is going out and that nothing else has the port tied up at the wrong time.

[Yair]

Some comments:

1. I have no experience working with UDP, so what I'm saying applies to TCP. That may make it incorrect.
   
2. You said you use port 4243 to communicate with both instruments. That's what Shaun was talking about. I would suggest you look at that.
   
3. Windows can lock up an outgoing port for a while after it's used and released. Normally this isn't a problem because you let outbound ports be assigned automatically so you just get a new one if needed.
   
4. I once ran into a similar problem with TCP, where opening a connection works as long as there's a listener on the other side, even if the listener isn't waited on. I assume that UDP doesn't have this, but I thought I would bring it up. You can see more about this here.
   
5. It would probably help if you upload a simple example.
   

One thing which is slightly out of the scope of this problem. I would appreciate if it could be commented as well. Why I dont see the Labview error dialog box in my executable but I see them while running the executable?

I assume you mean it works in LV and not in the EXE. LV has a feature called automatic error handling which pops up an error dialog if you have an error on an unwired error terminal. This feature is always disabled in executables. You can do something similar by wiring the error into the general error handler VI, but usually you would want a more robust error handling mechanism.

[Mellroth]

...

Computer IP address: 192.168.0.180

Instrument A IP: 192.168.0.175

Instrument B IP: 192.168.0.165

Instrument A: Port labview uses on windows to write to this instrument is 4243

Instrument B: Port labview uses on windows to write to this instrument is 4243

Both Instruments are similar and listen using only 4242

...

Why not using an arbitrary port on the Windows side instead of setting a static port (4243)?

Normally when we use UDP we use the IP address and port returned from the UDP read to determine the destination for the command response. This way the sender IP and port can change without problem, e.g. if we have DHCP enabled.

Another comment is that we rarely use IP ports that are this low for our own applications, just to minimize the chance of collisions.

/J