Run a subVI While ignoring all others

[Perl Peril]

Hi All,

  I'm working an application that reads data from a UDP Port, sends data to a TCP Port and transforms the recevied data a little bit.  The problem is that I receive very large amounts of data at the UDP port and if the user tries to change something on the front panel, I end of losing whole packets of data since my computer is thinking too hard.  Is there anyway to make it so that when a subVI runs, everything else is ignored?  I know that I could do it by changing my subVI to a subroutine, but you can't use asynchronous nodes in subroutines and UDP read is one.

  Does anyone have any suggestions?  I either need to replace the UDP somehow, or force labview to only execute one subVI.  I am using two while loops to control the flow in my program.  One to continually check for data at the UDP Port and one to see if the user wants to send a command.

  Thanks in advance for any help,

PP

[LV_Pro]

There are a few possibilities. One thing would be to move the time critical stuff into a sub-vi that isn't running in the UI thread. Another possibility is to use timed loops, with the critical one having a higher priority setting. Having an event structure that handles the front panel controls, with front panel locking when you are in a time critical communication might be yet another.

P.M.

[Perl Peril]

Hi P.M.

  Thanks for the quick reply.  I forgot to mention I am running Labview 6.1 and unfortunantely, it doesn't have timed loops.  I think it was introduced in LV7.  As for the event structure (which is how I am currently checking for user input), how could I use front panel locking to my advantage?  I'm still not very comfortable with event structures.  They seem so unelegent to me.  Oh well, , thanks for the help.  I'll see if I can get one of your suggestions to work for me.  Thanks,

PP

[LV_Pro]

Event structures may appear daunting at first, but they have made making user interfaces a lot easier. Rather than having to poll buttons and other controls to see if their value changed, then having the logic to cause your state machine to react to those changes an event structure encapsulates that functionality, plus a lot more that used to require a lot of inelegant code. I'm not sure how to implement one in your instance, but having a "timeout" frame (to which the event structure defaults after a given time if there are no other events) which would contain your communications code, and checking the "lock  front panel ..." for that event case might help. With a very simple event structured example I'm not seeing any increase in CPU when I click the control while the panel is locked, but it isn't a very complicated User Interface, nor is there much going on in the diagram.

P.M.

[tbob]

Instead of using a sub-vi to read the UDP, use one vi to both read the UDP and process the data.  This can be done with a producer-consumer architecture.  This involves two independant while loops and a queue.  In the first while loop, put your code to read the port, then queue the data.  This should run continuously so that no data is lost.  Put in a very small delay so that the CPU has time to do other stuff.  In the second loop, put in code to read the queue and then process the data, also with a small delay.  See attached example.

[mikeporter]

You might really want to reconsider your usage of UDP as it makes to guarantee about the delivery of datagrams. You can drop packets, get packets out of order, or even get duplicate packets.

Mike...

[Perl Peril]

  Thanks for the sugestion tbob, but I don't think it will work here.  I have data coming in from a scientific instrument in a large number of large blocks and the blocks must be processed all together. I can really think how to adjust your consumer producer to suit my needs but I'll keep trying.

  As for not using UDP, that is NOT an option since I have no control over how the instrument comunicates with me; I must adapt to it.

  As always, thanks for the help guys,

PP

[tbob]

When you say that the data comes in large blocks, what is the format?  Is it a contiguous string, a bunch of numbers?  How do you handle it now?  Do you put it into an array for processing?  You can adapt the producer-consumer to put any type of data on the queue.  If you block of data is made into an array, push the array onto the queue.  You just have to change the data type at the create queue function.  You can use clusters, strings, arrays, or any data type.  Just convert your large block into some type and push it on the queue.  Upon removing from the queue, you can process the data type any way you like.

[Perl Peril]

Hi tbob,

  Thanks for the suggestions.  I'm still trying to rework your idea to suit me.  For more information, you can see my previous thread at: http://forums.ni.com/ni/board/message?board.id=170&message.id=136197&view=by_threading&page=1, but to sum up, an instrument dumps large data blocks (about 16MB in size) to a UDP port, with about 250 being sent in rapid succession.  I need to capture all of these packets to preocess them all together.  There is a large break after the 250 packets in which to process the data.  Thanks to some Labview wizzes, I now how the data processing working fast enough, but I need to capture the data MUCH faster since I am currently losing packets if I ask my computer to do anything else while data is coming in.  Currently, all I do is use a for loop to build an array and then after all of the data has been entered, I concatenate the array into one string and I process it.  I will keep trying to adjust my processes to make them faster, but any suggestions would be appreciated,

PP

[tbob]

Would this work?