channel wire implementation: file name collisions

[lebecker]

Since the channel function names are delineated only by channel/data type and representation, creation of repeat instances of the same variable type leads to either an error (1357,'file from that path already exists in memory'), or a momentary
glimpse of the desired function followed by its quick removal, I suppose indicating that the channel folder for that channel/data type has already been created. So how does the developer handle this?  With the read/write subVIs using the execution property 'shared clone reentrant execution', how do channels keep different variables using the same data/channel type separate, especially if used in other projects?

Thanks!

[Bob_Schor · Accepted solution]

I've been using Channel Wires heavily since they were first introduced in LabVIEW 2016.  Every LabVIEW Project I've done since their introduction includes dozens of Channel Wires.

I, too, have questioned saving all of the scripted support functions all together, outside the Project, in each LabVIEW User's Documentation Folder, but understand it as a compromise, particularly with respect to using Version Control Software to support LabVIEW development.  I rarely have had problems with file name collisions, but that may be because I tend to use Project-specific Type Defs for most of the variables I end up using with Channel Wires, so I rarely have such a collision.

You failed to attach the Project that is giving you trouble, so I cannot make specific suggestions that might mitigate the difficulties you are having.  I have encountered situations where Channel Wires are not allowed (such as across Start Asynchronous Call functions), and find having to "fall back" on Queues distressing.

For more specific advice, compress the folder holding your Project (you don't need to include the Channel Instances, as LabVIEW will re-create them for me) and attach it to your Reply, and I'll try to make more helpful suggestions.

Bob Schor

[lebecker]

Thanks Bob. I tried your suggestion of using type defs as the channel variables and they work as advertised...great tip! The code I was working on was a simple bench test VI examining tag behavior within a consumer/producer framework...nothing noteworthy,  as the posting shows. This tactic clears up the naming convention problem... thanks again!

lb 

[Bob_Schor]

For reasons I don't understand, the type of the Channel Wire was not evident on your VI (you only sent the VI -- it might have needed the TypeDefs).  However, I saw that you referred to a Tag Channel, and you mentioned Producer/Consumer and I see an Event Loop and a While Loop, which makes me think of a Message Handler.

I don't know how familiar you are with the traditional LabVIEW Synchronization paradigms, namely Notifiers, Occurances, and Queues.  Queues are traditionally used for Producer/Consumers, and the Channel Wire equivalent is the Stream Channel.  Notifiers (write once, read the last item many times) is similar to the Tag Channel.  For a Message Handler, I use the Messenger Channel Wire (indeed, almost every Project I've created in the last 5 years have had multiple Channel Message Handlers, all using Messenger Channel Wires).

Bob Schor

[lebecker]

Hi Bob,

Yes, I neglected to include the TypeDef files. My focus with this simple VI was twofold: to implement your solution for unique channel support VIs in the ChannelInstances folder, and to observe channel reader behavior (timeout settings) in the consumer loop. 

I have used all the techniques of inter-loop data transfer that you list in previous projects, and have recently added channels to that list. Do I infer correctly that you use messenger channels for all data types (not just text)? Also, in the happenstance of intermittent single point-to-point data transfer, messengers are your preferred mechanism? Thanks Bob,

lb

[Bob_Schor]

One-to-one Channels where you want all of the data -- Streams

One-to-Many or Many-to-one where you want the most recent data -- Tags.

One to Many or Many to One where you want all of the data -- Messenger

So for the CMH (Channel Messenger Handler), I use Messengers.  For Producer/Consumer, I use Streams.  For certain kinds of synchronization, I use Tags.  I occasionally use Event Messengers.  So far, I haven't used the other Channel Wires.  I don't use Abort or Schedule, just Vanilla (so far, as Vanilla works so well for what I'm doing).

Bob Schor