UDP Read

[rohrdt]

I am developing an application that acquires sensor readings via UDP.

Due to the nature of UDP I am trying to develop extremely efficient code so I don't loose any packets.

In the following post,

http://forums.ni.com/ni/board/message?board.id=170&message.id=136685&query.id=207120#M136685

Altenbach mentioned that he did this by using two independent loops, one for reading the UDP port and

one for parsing the data.  He said he did this by using a "LV2 global style FIFO buffer".

Does anyone have a simple example of what this is.

I thought of using queues or a VI with un-initialized shift registers as a buffer.  At this point I would like several options

so I can see which solution requires less time to execute.

Thanks for any help. 

[James_R]

try looking at the queue examples or the master/slave and producer/consumer design patterns

here is an example of using queues with serial data in parallel loops

you can use the queue in two parallel loops in the same vi as shown above or use them in separate vi's.

To use them in separate VIs you still need to obtain the queue but as long as you give the queue a name that you created previously you can access the data.

One more tip is to make sure you make the "create if not found" input false on the queue's that you are proessing the data so you know when there is not a source queue and you can exit gracefully.

Message Edited by James R on 04-11-2007 05:07 PM

[smercurio_fc]

Actually a "LV2 global" is just a while loop with an uninitialized shift register, so you pretty much got it. As for the FIFO, my guess is that he was just using a queue, which you also mention, so you're right on the money.

Ben talks about "Action Engines", which are functional globals on steroids in this community nugget.

[rohrdt]

Thanks for both of the rapid responses above.

I will implement a VI with uninitialized shift registers and will try the queue example as well.

I will check which is more efficient.

Thanks again.

[altenbach]

Back in the old days, queues were too expensive for me because they carry a lot of extra baggage. (This was originally on a 133MHz Pentium 1 with 64MB of ram). Todays computers are orders of magnitude faster so these concerns are less of an issue. I actually had a built application of this running on a 33MHz 486SX laptop without loosing anything. 🙂

I don't have access to the code anymore, but the buffer was not really a FIFO but a "single IN, all OUT". It was designed as an "action engine" way before the term was coined. It had three actions:

1. Init: initializes a fixed size array (the desired buffer size) in a shift register. Input: size in # of array elements. This was called once before the main loop. The optimal size depended on the maximum rate of packets arriving and the speed of the read loop. I had it at about 1k tyically.
2. Write (default): Accepts a packet and writes it at the current index in the array and increments the index (also in a shift register) for the next packet. In the unlikley case thet the buffer was full, the input was dropped (never happened, though!)
3. Read: Reads the array subset from start=0, size=N and outputs it. Sets the current index back to zero.

The UDP read loop had an UDP read with infinite timeout, writing the data to the AE above. Nothing else really. The analysis part read the currently accumulated buffer data, analyzed it, retained the packets matching a desired pattern, and appended them to disk.

[ENSTB_Vivien]

Hello rohrdt,

I'm actually also working on a UDP VI to read out sensors. Is it possible to get in touch with you?

Thanks.

Regards

[rohrdt]

You can email me at rohrdt@onewest.net or use this forum.

[joe5213]

Hello, would it be possible for you to post your solution?

Thanks,

joe

[RavensFan]

Rohrdt hasn't been in the forums for nearly 4 years.  So I doubt he'll respond.  You also responded into another even older thread.

I recommend you start a new thread with your question.  First look in the example finder for UDP.  Then browse the forums searching on UDP and read the responses without replying into all the very old ones.

If you still have questions, then start a new thread with your question.  Be descriptive on what you are trying to do, what you have done so far, and where you are stuck.