How to use UDP

[dnorman]

Thanks for all the replies. Here is the VI with the sender. I apologize for all the bad coding that I'm sure it is riddled with. It performs how I want it to with the reciever I posted. My problem is why it doesn't work with my sub VI that has the same setup. I haven't been able to fix the errors you all have pointed out yet, but I thank you. I'm very ignorant on how to use LabVIEW. This is a rush job and I will get some training on it in the future.

Thanks,

dnorman

[altenbach]

Race conditions!

In both cases, "output(raw)" is written to a control (or local variable) in parallel of reading the same control. The reading probably occurs first, givin stale values. Same with the output# and C1..C3 indicators. You need to create a proper data dependency to avoid the race conditions. You have way too many local variables.

What is the purpose of the inner FOR loop of the TRUE case? Since it never does more than one iteration, it seems useless.

Again open the two UDP connections once before the loop, and not with every iteration.

Insatead of formatting the DBL into a string, typecast it into a string. Now you know to read exactly 8 bytes, which can be cast back to a DBL in the receiver.

[GregFreeman]

---

@altenbach wrote:

---

@for(imstuck) wrote:

You need to wire your refnum and error through the false case of the case structure. The way you have it set up now, it will "return default value" from the false case, so as soon as it enters the false case, you lose your refnum to the open connection.

---

Since he reads the connection with every iteration from the tunnel, the missing reference will only matter if the VI is stopped. However the while loop is hardwired, so "UDP close" is unreachable anyway. THe only way is to abort, which will close the connection anyway.

---

Whichever VI I looked at had an "ok" button wired up. I just made the assumption it was latch when pressed and that would be the cause of the problem. 

[GregFreeman]

---

@crossrulz wrote:

To add to what has been stated already.

Wire from left to right.  It makes the code a lot easier to read.

Do not use the Abort button to stop a VI.  Close it out properly.  In this case, add a stop button instead of the false constant to stop the loop and close out the connection.

Wire the references through the case structures.  You do not want to lose those.  Bad things will happen if you do.  I know from experience.

Here's a cleaned up version of your VI.

---

I know you know this crossrulz, but the OP may not so to the OP: make sure you have a "wait" function in your false case (or somewhere in your loop). since the timeout on the UDP read won't necessarily keep the loop from being greedy, because it isn't being called with each loop iteration.

[altenbach]

---

@for(imstuck) wrote:
Whichever VI I looked at had an "ok" button wired up. I just made the assumption it was latch when pressed and that would be the cause of the problem.

---

The first thing I checked was the mechanical action, and it was set to switch. 😉

[dnorman]

I've been trying to implement all of the suggestions you all have posted.Thank you all again.

I've found the source of my problems, but the reason behind it eludes me. For some reason the output from the UDP read won't update after the button that is connected to the case structure is pressed. Even if the button is turned back to false, the value is stuck at the last one recieved prior to the button being pressed. Why would this happen? It is the exact same setup, as far as I can tell, as the example one that I posted here, which works fine.

Also, shouldn't the LED be false when the button is false? Even after the Calibration button is changed from true to false the LED stays on. The button is set to switch when pressed if that makes a difference.

Thanks again,

dnorman

[nathand]

Please, upload your VIs (preferably in some version older than 2012) if you would like help.  It's impossible to tell what's going on from the very small screenshots you've attached, and it is very easy to attach VIs to a post.

Also, while I realize it's purely a style issue, if you'd followed the suggestions that people have made here you would have moved the UDP Open and UDP close to more normal locations (Open on the left, Close on the right) instead of stacking them on top of each other.

[altenbach]

---

dnorman wrote:

I've found the source of my problems, but the reason behind it eludes me. For some reason the output from the UDP read won't update after the button that is connected to the case structure is pressed.

---

After receiving one point, it will go back to the UDP read and wait for more data (your button is switch action!). This will block the case from completing and e.g. the LED won't update until the next iteration which will only happen after the timeout.

How often is new data supposed to be received?

You should take the UDP read outside the case structure and set the timeout to something smaller (e.g. 1 second). Look for timeout errors, and do nothing if an error occurs or process the received data if no error has occurred, for example.

What we can see looks still buggier than a formicarium. Why is there an event structure inside a case structure? Your small pictures really don't give enough information to troubleshoot the problem. Attach some real code instead.

[dnorman]

Sorry, this is my first time using LabVIEW and have been trying to learn as I've moved along and from the examples. My previous experience is in text based programming and only light on that. Most of my work is design engineering, not programming.

The data will be received every 250-500 ms.

I'm pretty sure the problem is coming from the event structure locking everything up. I put it in the case structure because I wan't it to be dependent on the case, but I have been reading and it seems this isn't the correct and dynamic events need to be used in this instance?

Here is the VI. I hope it doesn't give anyone a stroke from all the errors.

[nathand · Accepted solution]

You have a number of problems here.

An event structure, like every other structure in LabVIEW, does not exit until it has completed.  In the case of an event structure, "completed" means it received an event.  Since you don't have a timeout in the event structure, it will sit there and wait until one of the events that it handles occurs.  The while loop can't proceed until everything inside it completes.  While the event structure is sitting there waiting, the while loop isn't running and the UDP Read doesn't happen (more precisely, it happens once per loop iteration).

Your code looks like the typical example of a programmer moving from a text-based language to LabVIEW, but you did at least avoid abusing sequence structures.  However, you need to cut down on all the local variables and Strings property nodes.  You have a race condition: you're reading and writing the Strings property node inside the same structure.  You don't know which will happen first, which means the results may be unpredictable.  Much of the data that's in local variables should be in a shift register instead.