LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

udp connection id issue

Greetings,

 

New to UDP protocol. Haven't had any problems until now. Using Labview 2011.

 

When I made a program that uses the OPEN, WRITE, READ, CLOSE UDP all in one VI the program works fine. It's only when I break the OPEN & WRITE into 1 vi (passing the connection ID out as an indicator) and READ & CLOSE UDP in another (importing the previously mentioned connection id). I receive an "error 54" that specifically states that my READ UDP.vi (RX_BREAKOUT_AND_SEARCH.vi) has an invalid input parameter,check file location, spelling, basically indicating the connection ID. I probed the connection ID input of the READ UDP. vi and it gave me a long (about 8-10 digits I'm guessing) numbers, atleast indicating it's populated.

 

Is there an isue with passing a udp connection between VI's?

 

I've attached 2 png's that should be self explanatory by their filenames & block diagrams.

 

I've been banging my head against the wall on this. I use wireshark, and there is definitely packets available to read, it's just something with this connection ID.

 

I have a virutal DHCP running which is assigning an ip address to my device I'm trying to read from (192.168.0.101) through a ethernet hub. My remote and local ports are 2005. I use the default timeout on the READ UDP of 25 seconds, but I do change max characters to 1500.

 

I use all the same settings in both examples. So why does outputing an active connection ID to a VI that READS & CLOSES generate a failure?

 

Thanks in advance for any help.

 

Best Regards,

 

Chazzzmd

 

 

0 Kudos
Message 1 of 2
(2,176 Views)

Is it possible that you accidentally have the value of the error in terminal, in RX_BREAKOUT_AND_SEARCH.vi, set to an error?  If so, you'll get an error every time.

 

Also, is there any possibility that "# Repetitions" is 0?  If so, that would cause problems.  You might want to convert the connection ID tunnels into a shift register to avoid this, although I'm guessing that this does not explain the problem since you say you are able to probe the value of the connection ID (it would most likely be 0 if you had # Repetitions set to 0).

0 Kudos
Message 2 of 2
(2,171 Views)