LabView2016 - New streaming Funktions

[ReinhardG]

Hi,

In LabView 2016 exists these new streaming channels (look at the examples/channels folder).

I know there are a few new functions you can use if you are using these channels.

But there is, in my opinion, a big disadvantage: They are all much or less slower than the "old", equivalent funktions.

Even the "high speed stream" is slower than a "normal" queue, isn't it?

What do you think?

Reinhard

[daveTW]

How much data do you want to transfer?

At the developer days (in Berlin) they used the data value references to have incredibly high datarates between independent program parts. You can store your data in data value references and pass the reference via channel (or queue )

[ReinhardG]

I'm not writing a spezific programm at the moment. I just research the new funktions in LabView 2016.

I was just wondering about the bad speed performance.

For example: If you compare the new "tag-channel", with the old "local variable" and "frontpanel-object" connection.

Both have (quite) the same function and if I would need such a connection I would prefer the "old" version, because the write to and read from process is about 50 (!) times faster.

So I thought there must be an other BIG advantage I don't see, because if not they wouldn't have programmed it, doesn' they?

[Bob_Schor]

Sorry I don't have the time to write a longer report (I'm "leaving on a Jet Plane" in a few hours), but I am a wild enthusiast of Channels, and currently am using them in almost all of my serious Development work.

In the Bad Old Days, computers were slow, and squeezing the last bit of speed out of a loop so you could actually do something (or, if you have enough Gray Hair, or no hair at all, you may recall "trying to save one more memory location so you code would fit on the 128-byte memory page") was a challenge.  Programs were (necessarily) small (wow -- how could I ever use 4MB of memory?), so clarity wasn't so much of an issue.

Now, computers are fast, memory space is large, and code is spilling all over the place (you've not seen Spaghetti Code until you've looked at a LabVIEW VI that covers 10,000 x 10,000 pixels with a thousand wires of different colors and thicknesses criss-crossing on the screen).

LabVIEW Data Flow model gives rise to the possibility of parallel processing routines running asynchronously.  However, communication among asynchronous routines is something of a challenge, requiring routines from the Synchronization Palette (Queues, Notifiers, and even more obscure functions).

Enter the Asynchronous Channel Wire, a graphical extension to the LabVIEW graphical paradigm that transparently (I'm not sure if a pun is intended or not!) allows and demonstrates asynchronous communication patterns.

I just gave a 2-hour talk, "Introduction to LabVIEW", to a bunch of Engineering students where I discussed a Demo building a Touch Sensor out of a USB-6009 and 1 resistor (put the resistor across A/D Channel 0's terminals -- when you are indoors and touch one side of the resistor, you'll get a big increase in 60 Hz noise that you can use to signal Touch).  This Block Diagram, complete with Channels, was used to illustrate the higher-level Design patterns such as a State Machine and a Producer/Consumer pattern (same slide, different arrows).  This is my "go-to" Design Pattern that I call a "Channel Message Handler" -- it is the Queued Message Handler with Channels instead of Queues, and to my mind, is much clearer.

Channels are also much easier "at the edges".  When using Queues as Producer/Consumer "streams", I used to advocate exiting the two loops using the following logic:

• Producer "knows" it's time to exit.
• Producer sends a "Sentinel" (say, an empty array) to Consumer.
• Producer exits, leaving Queue intact.
• Consumer tests every Queue element, looking for Sentinel.  If no Sentinel is found, Consumer "consumes" the data.  Otherwise, the Consumer exits its While loop and then releases the Queue.

With Channels, additional logic is built into the Channel Writers and Readers to handle these "house-keeping" details for you.  For example, the Stream Writer has a "Last Element?" input that the Reader can query to know if it is time to exit.  It additionally has an "element valid?" input, also testable by the reader, so you can exactly mimic the logic I described above.

So I don't fret over speed (I've not, in fact, tested it), but rather on "Writing code that does what I want, not what I may have tried to say ...".

Bob Schor

[ReinhardG]

Hi,

Thank you joining the discussion.

Lets stay at your example: I think you could use a queue here as good as this "channel". And the code would be as clear. Yeah, right, when using a queue the releasing is a bit more complicate but not really a problem (just one more element in and specific "deinit_state" at the state machine and at bigger programms you nearly always need such a state.)

[RTSLVU]

Oh, I like the idea of streams. In my mind Queues, notifiers, references, and the like break LabVIEW's data flow paradigm so I still rarely use them.

I found the Channel Basics project by searching for examples, but where are these stream VI's on the palette?

[Bob_Schor]

When I first heard about Channels (as an unannounced, "hidden", feature of LabVIEW 2015), I, like you, was skeptical (the fact that the "alpha" channels were a little buggy was another issue ...).  In addition, the initial appearance of the Channels were nowhere near as attractive/intuitive as the LabVIEW 2016 (released) Version.

In my (limited) experience, I find that using Channels is much more intuitive, results in much neater Block Diagrams (I never did like Queue Wires running exclusively on the left side of my loops, and having to act as an "input" for a VI when the VI does an Enqueue (which, from the VI's point of view, is an "output" operation, you put something into the Queue).  It's especially true when dealing with colleagues who are "naive" to LabVIEW.

So I, personally, like it and use it (now) whereever Asynchronous Communication is desired.  It is a new paradigm, and can take some time (a day? a week? half-a-minute?) to get comfortable with it, but it works very well for me.

Bob Schor

[ReinhardG]

They aren't at a palette. You only can create them by right-clicking on a wire and choosing create/writing channel endpoint (I hope that is the correct translation; I'm using the german version).

[Bob_Schor]

---

@ReinhardG wrote:

They aren't at a palette. You only can create them by right-clicking on a wire and choosing create/writing channel endpoint (I hope that is the correct translation; I'm using the german version).

---

Yes, Channel Reader and Channel Writer.  When you create a Writer (which you tend to do first), you have a choice of what kind of writer you want -- a Stream (like a Queue, but designed for single Writer to single Reader), Message (multiple writers, the structure I used in my example), and others (see Examples).

Bob Schor

[Duffy2007]

Hello ReinhardG,

here are a very simple benchmark, which compares different transfer technologies.

Transfer Benchmark