Jump to content

How can I show some message when UDP Open is timeout?


Recommended Posts

Hi all,

I just started using labview. I am working on UDP communication.

I have some question. How can I pop up some dialog to show the user when the "udp open block" is timeout? (in the picture show 5000ms) For example if the udp cannot open in 5000ms, the labview will show "cannot connect" dialog box to the user.

 

 

 

I tried checking from the error out node (yellow line) by cluster. it has shown no error (error code=0) even the udp was time out. I dont know how to do next so. How to get the error code from the block?

 

please help thank you in advance.

 

 

post-15170-0-73062200-1371031613.png

Link to comment
Why are you certain that there was a timeout at UDP Open? If there is no error on the error wire, then the function most likely did not time out. What is the actual problem you're seeing?

 

Thanks ned,

 

Well, I want to pop up some message when my VI cannot connect to the server.

I noticed that when if the VI could not reach to the server, the udp open will timeout. ( I knew because my connected button lag for input timeout 5000ms if it cannot connect)  but I don't know why the error out wire doesn't give me any error output. maybe I do something misunderstand about error handler. any example vi about that?

 

I think it will be the simplest way to check the connection if I can get this error out.

 

thank you.

Link to comment
Thanks ned,

 

Well, I want to pop up some message when my VI cannot connect to the server.

I noticed that when if the VI could not reach to the server, the udp open will timeout. ( I knew because my connected button lag for input timeout 5000ms if it cannot connect)  but I don't know why the error out wire doesn't give me any error output. maybe I do something misunderstand about error handler. any example vi about that?

 

I think it will be the simplest way to check the connection if I can get this error out.

 

thank you.

 

Rule 36 & 38

 

You have a timeout of 5000ms in two locations, so it's not definite that the open is failing from that. But if you follow rule #36 and #38, you will have a better idea what is happening and you can show the error with the Simple Error Handler at the end..

Edited by ShaunR
Link to comment
Well, I want to pop up some message when my VI cannot connect to the server.

I noticed that when if the VI could not reach to the server, the udp open will timeout.

Hi Ned,

 

I'm not sure you know exactly what's going on here... UDP is a connectionless protocol, "UDP open" will never connect to the server. What I think it does it tries to bind a local UDP port. This is the port that will be used as "source port" in "UDP write".

Maybe the timeout happens because it is unable to bind that port.

 

My question is, do you need to bind a specific local port?

The way you have written the application, it will send a datagram from source port 5000, to destination port 5000. You could just as easily leave the source port to be assigned randomly, especially since you do not expect top receive a response.

 

Br, Mike

  • Like 1
Link to comment

No, UDP is really just packets flying through the network without any state being maintained in the network stack on both sides (you can do that then in your application ;) ). Therefore I don't understand the point in Open and Close VIs for UDP (but it would be logical to do all the necessary socket stuff in there).

 

I would try with netcat on the very machine where this program should run if I can open a UDP connection to the remote party you set in the VI to verify it is not a network problem, then I would remove the UDP Write and just see if Open and Close work and if nothing works I'd try with sending data via UDP between two LV programs sitting on the same box.

Link to comment
Grrrr. UDP is driving me crazy today.

 

I have a cRIO which I can communicate just fine with (LAN connected).

 

I can transmit UDP from the cRIO to itself, and from the PC also to itself, but I just cannot get any UDP datagrams to be seen by either end of the system (i.e. PC --> cIRO and vice versa).

 

Wireshark tells me the packets transmitted by the cRIO are reaching the PC, just LabVIEW returns nothing from the UDP read function.

 

:angry: 

 

The only think I can think of is something is throwing a wobbly due to the the multiple NICs in my PC. I have tried to force the UDP Open on the receiving end to use the NIC of the ethernet connection that I know I am using.

 

ARG! I think its the windows firewall!

 

Silly question that has to be asked. Have you checked the firewall?

Link to comment
This is driving me even more bananas!

 

I have the cRIO spitting out UDP packets every 100 ms, which I can successfully read on the PC using a simple Python script.

 

The picture attached is my attempt in LabVIEW. It successfully reads the first item, then the iteration count only increments something like every 9 seconds and the received data is incrementing correctly, but way way too slowly. In the LabVIEW IDE it basically locks everything up, and in an executable it doesnt freeze anything but still behaves strangely.

 

Strange indeed.

 

EDIT: figured it out, it was the IP-->String that I added during debugging the firewall issue that causes the slowdown. Removed that and viola! Working as expected. Time to go to bed...

 

The IP to string defaults to looking up the domain name (which the cRIO probably doesn't have). You are probably seeing the domain lookup timeout. Set the "dot notation" to true and it should be OK. 

  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.