Simple Network Streams - Example VIs

[gary_janik]

In the example VI: Simple Network Streams - Host.vi the receive loop has a choice two timers: 10 and 20 milliseconds.  In addition the Read Single Element from Stream VI has a timeout of 100 milliseconds connected to it.

In Simple Network Streams - Target.vi the receive loop has no timer, but the Read Single Element from Stream VI has a timeout of 1000 milliseconds connected.

How can the target receive loop work without a timer?  What is the purpose of the 100 millisecond timeout of the Host receive loop if the loop has a timer of at most 10 milliseconds?  I have this example working on my cRIO-9030, but I don't understand it.  I think this gets down to my lack of understanding of the timeout function of reads and writes for streams and FIFOs.  Does the VI sleep until just before the timeout to check for data, or does it hog the processor the entire time looking for data?  It doesn't seem to be the latter since the processors on the target are only partially occupied in this example.

[Bob_Schor]

---

@gary_janik wrote:

In the example VI: Simple Network Streams - Host.vi the receive loop has a choice two timers: 10 and 20 milliseconds.  In addition the Read Single Element from Stream VI has a timeout of 100 milliseconds connected to it.

In Simple Network Streams - Target.vi the receive loop has no timer, but the Read Single Element from Stream VI has a timeout of 1000 milliseconds connected.

How can the target receive loop work without a timer?  What is the purpose of the 100 millisecond timeout of the Host receive loop if the loop has a timer of at most 10 milliseconds?  I have this example working on my cRIO-9030, but I don't understand it.  I think this gets down to my lack of understanding of the timeout function of reads and writes for streams and FIFOs.  Does the VI sleep until just before the timeout to check for data, or does it hog the processor the entire time looking for data?  It doesn't seem to be the latter since the processors on the target are only partially occupied in this example.

---

First of all, where is this example?  You didn't post the code, and I didn't find it in the LabVIEW Examples, so it's difficult to explain "invisible" code.

However, "sight-unseen", I may be able to explain some of your issues.  If you think about Network Streams as a Producer/Consumer pattern "across the network", the Consumer (the receive loop) might not need a timer, as it is being "driven" (and hence "timed") by the Producer sending data to it.  It probably should have a time-out just in case the Consumer just stops sending (say, it exits).

Functions such as dequeues and receives "block" and don't do anything if they have no input.  Recall that LabVIEW uses data flow, and can have multiple parallel processes (loops) running at the same time.  When a function blocks, the code section (let's call it a "loop") containing the function stops using CPU cycles, allowing the other parallel loops to use the time.  This lets processes run "at their own speed" as long as they are sufficiently "decoupled" by being placed in parallel loops.  When there is no data, the loop essentially "waits", and lets all the other loops use the time instead.

Bob Schor

[CoastalMaineBird]

In Simple Network Streams - Target.vi the receive loop has no timer, but the Read Single Element from Stream VI has a timeout of 1000 milliseconds connected.

How can the target receive loop work without a timer?  What is the purpose of the 100 millisecond timeout of the Host receive loop if the loop has a timer of at most 10 milliseconds? 

It can work without a timer because if it's actually running, it sits and waits for the other end to send data.,  It is the sending end which times things - the receiver just receives it when it's sent.

The purpose of the 1000 mSec timeout is to catch the case where the other end stops sending. If the other end stops sending, but keeps the connection alive, then there is no "error" but the timeout stops listening and gives you a chance to do other stuff, like check for the "STOP" button here.  

[CoastalMaineBird]

I didn't find it in the LabVIEW Examples,

[CoastalMaineBird]

Does the VI sleep until just before the timeout to check for data, or does it hog the processor the entire time looking for data?

Neither one.  It's all event-driven, even in the OS.

The thread (containing this READ function) will sleep (and NOT occupy the CPU) until EITHER of two things happens:

1... The data you requested arrives. The thread wakes up, reports no error, and there is your data.

2... The timeout expires.  The thread wakes up, reports a TIMEOUT, and you have NO data.

It's NOT like the cpu is busy with "do we have data yet?" "do we have data yet?" "do we have data yet?" "do we have data yet?"

And if the data comes in in 10 mSec, it's not going to wait for 1000 to give it to you.

[Bob_Schor]

Thanks!  I wasn't looking in LabVIEW 2014, where it is not only prominent in the directory hierarchy, but also shows up when you do a Search on Network Streams ...

I thought the example was quite well done, and represented some useful techniques and tips.

BS