[EDIT] The following was posted for LV 2016. This new channel template officially shipped with LabVIEW 2017. You only need to install the .vip if you are still using LV 2016.
Channels and event structures need to work better together. This is a new channel template to facilitate this.
This template will ship with LabVIEW 2017. I am making it available here for LabVIEW 2016 f1. You need the 2016 f1 patch for this template to work.
Step 1: Install the 2016 f1 patch
Step 2: Install the .vip attached to this post. This installs the new template.
Step 3: Open the shipping examples in the .zip file attached to this post.
Step 4: Take a look. I already have enough feedback to know this will definitely ship with LV 2017, but if you see any fine grain details that could use fixing, please let me know through comments here.
[EDIT] Version 126.96.36.199 fixed a bug. "last element?" is now false in event frame when aborted, consistent with the other channel templates.
I don't use a current version of LV, so no channels for me, and I can't inspect the code, but a couple of questions do come to mind from looking at the image:
AQ, usual question.... What patch level do I need for Mac OS X? Or linux?
I think the difference between Aborted and stop is that with abort, the last element is not valid and not processed.
This is very different in that the channel reader is outside the loop and only reads once to pass the User event reference. Then each subsequent channel write is merely a user event and not channel data transmission. The event itself passes all the data.
In this case the channel actually only transmits data once? Am I reading the example right?
This is a somewhat confusing mixture of event and channel data transmission.
I've just "played with" the new Event Messenger Channels, and before I "complain", I want to try to answer Tst's questions (this will serve as a "check" that I "get it" -- AQ can correct us both).
Here are my (extremely picky) Comments on the new Event Messenger Channel. I basically like it, but ...
I've just made my first "real" Event Messenger Channel, and it works like a charm.
I've been using Channels for all of my new development work. Several of my Projects use a Channel version of the Queued Message Handler (I call it a Channel Message Handler), with an Event Loop on top handling Front Panel button pushes and a State Machine / Channel Message Handler below.
One thing that spoiled the "clean design" was handling the Exit button. When Exit is pushed, the Event Loop's Value Change fires, I put an Exit Message on the Messenger Channel, and tell the Event Loop to stop running. The Message Handler sees the Exit Message, cleans up, and stops the Messenger loop. With both loops stopped, the program exits.
But what if there's an Error? The Messenger Loop also can process an Error Message, which outputs some text, then puts the Exit Message on the Messenger Channel so that we exit cleanly (all the ShutDown code is in the Exit state). But how to shut down the Event Loop? That wasn't pretty -- I did it by making the Exit button not a Latch when Released, but a Push Button, which worked, but was not (in my mind) ideal.
Enter the Event Messenger Channel. I created an Event Messenger Writer for my State Enum (of which Exit is a member) and place that in my Exit State. I also create a corresponding Event Messenger Reader which I position next to the Dynamic Event input terminal of my Event Loop. I wire the Exit state to the Writer's input, snake the Channel out the Message Handler and over to the Event Loop, and then add an Event Case for the new Channel Dynamic Event. A Nice Feature is that the Input Node is named NBState, which is the name of the TypeDef whose Enum is carried by the Channel. Now all I have to do is detect if Exit is on the Channel, and if so, exit the Event Loop.
That's not quite 1000 words, so here's a picture:
This is a reply to Sth's about the Channel Reader being outside the Event Loop, suggesting that the Channel passes Events and the Event Loop processes the data. He then ask if the Channel only transmits data once.
I've played with the Examples, and have made an Event Messenger myself, so here's my take on things. Yes, the Channel passes Events and the Event Loop processes the data. However, every Write to the Channel causes data to by put into the Event Loop's Queue (where it is handled just as in a more common Queue, in the order received.
Here's how I conceptualize this. The creation of the Channel Reader and wiring it to the Dynamic Event node both adds the <channel value>:User Event as a possible choice for the Event Structure, and also creates (behind the scenes) what used to be the User Event Queue. Calling the Channel Writer puts things onto this Queue, where they are transferred to the User Event Queue "in the order received" (I'm not sure these take place as separate steps, but it helps me to think about it in this way). I've done a little test routine that shows that you can have the Event Loop running before you put anything into the Event Messager Writer, just as you can have an Event Loop that process Button Pushes before you generate any User Events (in the non-Channel Dynamic Events).
Re 1: Same as other channels. "last element?" signals this is the last transmission. "abort" clears events already sent previously that haven't already been processed.
Re 2: Same as the other channels. [including LV 2015]
> Is there a clean way of ensuring registration before generation?
> Is this simply built into the channel?
> Presumably it can't be,
Upgrade and see. 🙂
The capitalization in all of this is correct for NI style guide. We capitalize function names and lower case parameter names. We capitalize type names and lowercase field names, including event data. We capitalize UI controls. So the Stop button is wired to the last element? terminal.
>Other Channels that have both Last Element? and Abort ... inputs and outputs keep them "separated".
I did not believe I had made any change vis-a-vis any other channel. I'll double check.
Argh. Yes, there's a difference of behavior there. Let me check with team... since it has shipped, the preponderance of opinion will almost certainly be to make this one match the existing.