Channel Wires (Old Dog, New Tricks)

[CoastalMaineBird]

LV2018 SP1

I'm an old hand at LabVIEW but new at Channel Wires.

I'm looking at the MESSENGER EVENT flavor, as it seems closest to what I need.

Somebody please tell me that it's not as dumb as I imagine.

Looking at this diagram, I have questions:

This was created using a simple cluster of ENUM + STR, then creating a Channel Writer.

LV created a LVLIB with the name of every element in the ENUM.

1...  That ENUM is not a TypeDef now.  Does anything change if it is a TypeDef?

2... If I add "Thursday" to that enum (TypeDef or not), does it have to re-create the library and all the handling VIs ?

3... If it creates a new LVLIB, does the old one stay around clogging up my disk?

4... If I create a new CHANNEL WRITER with a given enum, and later create a new CHANNEL WRITER with the same enum, does it create a separate LVLIB, or re-use the old one?

5... If I want to use a CHANNEL WRITER with something that I already have defined, do I have to search thru the list of LVLIBs to find the right name?

6... I have an enum with 70+ values, or a cluster with 100 items. Is it really going to create a library with a long name to cover all that?

7... Will it create a file name that is too long for the file system to handle?

8... How do I create a channel mechanism for a custom data type, that I can use in multiple PPLs (multiple projects) ?

9... It looks like  (in the code above) that any time I WRITE to the channel, it does that PROBE LOOKUP logic.  The HELP file for that function is missing, but table lookup is not something I want to do every time, for performance reasons.  Is there an option to prevent it?  I can remove it manually, but if it's re-created often, that's a PITA.

10... Any GOTCHAS in using channels...

--- in RT code?

--- in dynamically-loaded VIs?

--- in subVIs, passing thru terminals?

[CoastalMaineBird]

OK, no takers.

My own experiments show that if the type was sufficiently stable, it might work really well, but there are caveats otherwise.

If anyone cares, here are the answers I found:

1...  That ENUM is not a TypeDef now.  Does anything change if it is a TypeDef?

--- Yes.  The name of the LVLIB it creates becomes the name of the TypeDefed CONTROL, i.e.,

c(t'MyLibrary.lbvlib - My Control.ctl',Str).lvlib

rather than the list of enum items.

2... If I add "Thursday" to that enum (TypeDef or not), does it have to re-create the library and all the handling VIs ?

--- If it's NOT a TYPEDEF - Yes, if you want it to work properly.  It WILL NOT BREAK, but it will fail to work - if you send a THURSDAY value, it will come out as WEDNESDAY.

To FIX it, you have to tell the channel WRITER to ADAPT to ELEMENT TYPE and any ENDPOINTS to ADAPT TO CHANNEL TYPE.  that's ugly.

--- If it's a TYPEDEF - No.  the whole mechanism adapts to the new type, which is a relief.

3... If it creates a new LVLIB, does the old one stay around clogging up my disk?

--- Yes.  It's not going to clean up after me.

4... If I create a new CHANNEL WRITER with a given enum, and later create a new CHANNEL WRITER with the same enum, does it create a separate LVLIB, or re-use the old one?

--- If it's a TypeDef, then it re-uses the LVLIB code it's already generated.  I didn't test it, but I suspect it encodes the Type Descriptor of the message element into a file name and looks for that in the cache, so, being a TypeDef wouldn't matter for that.

5... If I want to use a CHANNEL WRITER with something that I already have defined, do I have to search thru the list of LVLIBs to find the right name?

No.  If you CREATE CHANNEL WRITER from the terminal of the thing, then LV will search thru the list for a match, and create one if necessary.

6... I have an enum with 70+ values, or a cluster with 100 items. Is it really going to create a library with a long name to cover all that?

--- For the ENUM, if it's NOT in a TypeDef, then YES, it will create a long, long, long name for the LVLIB file.   I didn't test it, but I suspect the same is true for a populous cluster.

For a TYPEDEF, the name is only as long as the LVLIB + CONTROL name of the TypeDef itself.

7... Will it create a file name that is too long for the file system to handle?

--- Yes.  You get a warning about the name that is too long and a recommendation to put it into a TypeDef.

8... How do I create a channel mechanism for a custom data type, that I can use in multiple PPLs (multiple projects) ?

--- Unanswered as of yet.

9... It looks like  (in the code above) that any time I WRITE to the channel, it does that PROBE LOOKUP logic.  The HELP file for that function is missing, but table lookup is not something I want to do every time, for performance reasons.  Is there an option to prevent it?  I can remove it manually, but if it's re-created often, that's a PITA.

--- Unanswered as of yet.

10... Any GOTCHAS in using channels...

--- in RT code?

--- in dynamically-loaded VIs?

--- in subVIs, passing thru terminals?

--- Unanswered as of yet.

[Bob_Schor · Accepted solution]

Hi, Steve.  I'm a big fan of what I call the "Flexi-graph", whose methods I learned from your blog.  I'm also a big fan of Channel Wires, having used them for nine months before they were "officially" released in LabVIEW 2016 (I use them a lot).  I'll try to answer most of your questions, and will try to be "accurate".

1. Channel Wires are generated based on the input that is used when they are generated.  You certainly can generate a Channel Wire for a "constant" Enum.  If you create a TypeDef for the Enum, the original Channel Wire Writer will accept the TypeDef'ed Enum input, but you'll have a coercion dot, and what you'll get out of the Reader will be of type "Generic Enum", i.e. a U16, as opposed to the TypeDef you defined. 
2. Yes, it does, but it takes seconds (like maybe 2, at most).  What will happen is the code will "break" (as it should every time you change an Enum where the values matter, like wiring it to a Case Statement), but if you right-click the Writer and go to the "Replace" dropdown, you can choose "channel endpoint" and it will do it for you.
3. It depends.  If you change a type-def'ed Enum and update it as explained in #2, it "edits" it and there's no added "orphan" files.  If you take an un-typedef-enum and create a type-def'ed one (like described in Answer 1), you'll have two .lvlibs.  I've not (yet) worried about them "clogging up my disk" -- they stay "out of sight" in their own space in LabVIEW Data, and you can always delete them all and re-create them when necessary (if you've got a lot in your Project, it may take all of 10 seconds ...).
4. It uses the same LVLib.
5. The "name" is based on the Type (and TypeDef) of the wire you use to Create Writer (or Reader).
6. The name of the Library will be as long as if the Enum had 1 value (just don't make the name of the Enum have 70 characters).
7. Almost surely not.  It is a few directory-levels down from My Documents, with file and folder names of maybe 30 characters.  Of course if you define a TypeDef of 180 characters, all bets are off ...
8. Create the Custom Data Type, make a TypeDef for it (mainly for your own sanity), and you are done!  Channel Wires and their definition are on a User basis (as they are stored in your LabVIEW Data folder), not on a Project basis.  This can lead to "clashes" if you use the same Type name with different definitions in different Projects.  The solution to this is either to make the names of the TypeDefs unique to the Project or to regenerate the Channels for the Project as needed (see Answer 2).
9. Don't understand Question 9.  I also don't see any Channel Wires in your picture (oh, how I hate pictures of VIs, vastly preferring, and sometimes, I regret, rudely preferring) the VIs, themselves).
10. Yep, there are Gotchas.  I'll list a few, feel free to respond if you find more.
    1. You cannot pass a Channel Wire through a Structure, be it a Loop, Case, or a VI, itself.  There is an easy way to get around this -- simply "break" the Channel someplace, create a Writer/Reader pair, and wire them together.
    2. You can't pass a Channel Wire into an Asynchronous Clone.  If you need to do this (and I did!), I've got a Work-Around (and talked about it, among other things, in my NIWeek talk last week).
    3. It has been known to happen that loading a large Project with lots of Channel Wires can appear to (and actually can) "hang".  Two solutions -- first, stop LabVIEW and reload the Project, which should continue where it left off, and (I hope) finish.  Otherwise, delete all the Channel Wires (as I describe below) and try reloading the Project.  If it still hangs, open the Project and open the low-level VIs before opening the Top-Level ones, encouraging an "orderly loading".

As you've probably discovered, Channel Wire libraries are created when the Channels are defined in your LabVIEW Data folder.  The top-level folder will have a name of the form "20xx(yy-bit)", under which will be a folder "ExtraVILib", under which will be the folder "ChannelInstances".  To get rid of Channel Instances, delete the appropriate ChannelInstances folder.

Good luck.  I've not had (serious) problems, and when I did, they were definitely my own fault.

Bob "Channel Wire" Schor

P.S. -- sorry for the slow response -- I'm still on vacation and away from my desk ...

[CoastalMaineBird]

Thanks, C.W. for that detailed answer.  TypeDefs solve a bunch of the problems I had imagined.

Just for the record, your answer #7 is not correct.  It WILL attempt to make a file name that is too long, and complain when you try.  If the ENUM is not TYPEDEFed, and has 70+ items in it, then it tries to list them all as part of the file name, and chokes on the result.  

Question 9 is not my code - it's about the VI generated when you create a CHANNEL WRITER. It's the ))Channel.vi in the folder created when you do that.  It's also in the built-in types, if they have a )Channel.vi.  It seems odd to burden every single Channel Write with that overhead.  I was hoping there was an option somewhere to declare NO PROBES.

I built a round trip loop with a CYCLE (!) where one loop sent a message asking for a version number, and another loop responded with a version number, and the first loop responded to that message on the same channel.  That's the kind of thing I need to do, but on a bigger scope. The round trip time was about 50 uSec.  Not sure if that's a problem for me.

I think I do need to work with Asynch Clones.  I'm thinking of a host containing 4+ subPanels, into which is inserted a User Interface.vi from class A, or a User Interface VI from class B, etc.  Each one has to be launched and forgotten, and I communicate via queues (or now Channels).

I'd be interested to hear the problems you faced in that area and the steps to overcome them.

[CoastalMaineBird]

Here's another problem I found.

I deliver my project as a ZIPPed copy of my source folder.  My customer compiles it as needed, for his own targets. 

Having the CHANNEL INSTANCES in the LabVIEW DATA folder adds another step to that.

If I move the instance folder to next-door to the LVPROJ file, then the project opens and finds it automatically, which is good.

But the code is now broken:  

Not sure why, except it has to be related to the path having changed.

I can move it back and the code is not broken anymore.

[cbutcher]

I'll just add a brief-ish comment on the PPLs and path lengths parts.

When I was trying out Channels for my RT application, I found the file name became too long, and the exe failed to compile. To avoid this problem, I moved the library out of dependencies and into my project, where I could then in the Build Specifications rename it in the compiled version. This allowed me to compile the RT application. You might manage to use this paragraph as a starting point to help you avoid long names elsewhere (but I don't know for sure).

Regarding PPLs, I expect (untested) that you could do the same - you need a build specification for a lvlib that is in a project somewhere. You can then replace that lvlib with the built PPL in other projects. Since the lvlib is stored in LabVIEW Data, you can use that as the source for a new project and build from there (and then replace in your "real" project).

Given what I might describe as inflexibility with Channel Wires, you might find this PPL would need recompiling more than you would like (i.e. every time you change anything). That may or may not be worth it for you - I like some of the features of Channel Wires, but have typically stuck with Queues in most of my cases.

[Bob_Schor]

If you send LabVIEW code involving Channel Wires to a Customer as source (i.e. the LabVIEW Project and its files), do not send the ChannelInstances folder.

Let's assume your code is in LabVIEW 2018 -- you've developed it, tested it, and it works.  You now want to compress the folder holding the Project and send the resulting .zip file to your Customer, who will unzip it, and open the Project with his/her copy of LabVIEW 2018 (with, of course, all the appropriate Toolboxes, Modules, and LabVIEW ToolsNetwork "extras" in place, e.g. OpenG).

When your Customer opens the Project and loads any VI that involves a Channel, LabVIEW 2018 will "see" the Channel and will attempt to create the appropriate ChannelInstances code via LabVIEW Scripting in the user's My Documents/LabVIEW Data/2018 (32-bit)/ExtraVILib/ChannelInstances.  That's how it is supposed to work.

Had you built an Executable, you would not have needed to specify the location of the Channel Wire "support code" -- LabVIEW would have found it and built it into the Executable.

Bob Schor

[Bob_Schor]

@cbutcher:

     I've not done any LabVIEW RT projects with Channel Wires, so am not familiar with the problems you describe.  I've also not used PPLs.  Looks like there may be some "corner cases" involving My Favorite LabVIEW Feature with which I am not familiar ...

Bob Schor

[BertMcMahan]

I hope this doesn't sidetrack the thread too much, but I think it's at least somewhat topical. I'm in the same boat as OP, having done LabVIEW for years but never used Channel Wires.

@Bob and @OP, could you give a brief rundown of what Channel Wires bring to the table over standard Queue/User Events/etc? The official NI documentation makes it seem like they're just slightly simplified Queues, which doesn't seem like it'd warrant a description of "Favorite LabVIEW feature" 🙂 It would be nice to hear it from an actual user rather than the "sales pitch" version I keep finding online.

[Kevin_Price]

Brief chiming in as another long-time LV'er who hasn't ventured into Channel Wires.

At the 2018 NI Week, hints were dropped that Channel Wires were being positioned as an increasingly universal syntax that "might" be extended to support messaging between parallel loops, processes, or PC's pretty seamlessly without requiring the LV programmer to deal with the mucky low-level details (Event registrations, TCP connections, etc.). 

Intriguing concept, but I'm a little leery of things that are defined partly by the code I write and partly by some auto-scripting stuff that gets generated and tucked away somewhere automatically.  I occasionally read about errors or corruptions caused by this split between code-I-control and code-I-don't-control-but-depend-on, and have been choosing to be a late adopter sometime down the road a little further.

-Kevin P