Broken dependency issue when using same Channel library in different projects

[Quiztus2]

I am using the Message Queue.lvlib from the Create Project->CMH template in two different projects.

This leads to following, quite annoying error regularly.

Broken dependency: Messenger-t'Message Queue.lvlib-Message Cluster.ctl'.lvlib:))Channel.vi

After deleting: "Documents\LabVIEW Data\2023(64-bit)\ExtraVILib\ChannelInstances" the channels get regenerated
and the error often vanishes.

Since I find it really helpful to use the same library in more than one project I wonder how to get rid of these errors regularly.

Any suggestions?

[Bob_Schor]

I've been an enthusiast and heavy user of Asynchronous Channel Wires since they were a "hidden feature" in LabVIEW 2015, and believe I might be the first to start calling the Messenger Channel version of the Queued Message Handler design the Channel Message Handler (or CMH).

At the time that Channel Wires were being "tested", I raised the question why the decision was made to have all of the supporting code "shared" in \LabVIEW Data\ExtraVILib\ChannelInstances, instead of being part of the Project, and hence "name-spaced" with the Project (exactly the issue you are facing).  I more-or-less accepted the argument that the Channel Instances folder had code that was generated by LabVIEW scripting when the Channel Wires were encountered, and it "made more sense" to keep them together and "isolated" from the LabVIEW Project (much like the contents of user.lib and vi.lib are stored "outside the Project", the difference being that the .lib folders are "static", fixed when LabVIEW is installed, and not dependent on user-written code needing specific support routines created when a feature like a Channel Wire is defined and used).

But this means that the implementation of a Channel Wire is tied to the name of the Channel Wire, making it incumbent on the LabVIEW developer to have unique names for Channel Wires between LabVIEW Projects.  I once asked a developer who was explaining a QMH-based Project why he used LabVIEW Classes for the Queue elements, and he said it provided "name-spacing" between Projects.  I noticed that the LabVIEW 2019 examples of the Messenger Channel Wire also use a Class for the Message, but I'm not sure this provides "isolation" between two Projects with the same Class name, but different Class definitions (I haven't tried testing this, yet).

Of course, another "solution" that I have implemented is to write a little Utility that I call "Reset Channel Instances".  It finds (in the File Folder pointed to by the "Get System Directory" function with the argument "User Documents") the relevant "User Documents" and deletes the ChannelInstances folder for the particular version of LabVIEW you are using.  If you make this little Utility part of your Project, you can simply run it whenever you encounter (while already running LabVIEW) this situation.

Bob Schor 

[raphschru]

@Bob Any idea why it got implemented like that ?

Why not making native yellow functions that can adapt to any type like for Queues / Notifiers / User Events … ?

[Quiztus2]

I think this image concludes the issue pretty good. Be aware that those are project structures that are 100% copies of NI's CMH template. I simply added one VI to the second projects Message Queue.lvlib

[Bob_Schor]

I'm going to try to answer both responders here.

---

@raphschru wrote:

@Bob Any idea why it got implemented like that ?

Why not making native yellow functions that can adapt to any type like for Queues / Notifiers / User Events … ?

---

I'm unsure what @raphschru means by "native yellow functions", but I think the answer to "why it got implemented like that" is because (in my somewhat humble opinion) Asynchronous Channel Wires are so much more mnemonic, sensible, and "task-driven" than queues and notifiers, with left-to-right "data flow" of the data in the Channel Wire, additional sensible additions such as the sentinels built into the Stream Writers and Readers.  To provide this functionality, I gather, necessitated "building tailored implementation code based on the user's "data going into the wires" that were better 

I've been using my own version of the Channel Message Handler, but with an Enum in place of a String for the "Message", meaning every CMH (and I typically have 2-4 running simultaneously on my one-laptop-screen-sized "Main" block diagram) needs its own support functions to manage the Messenger Channels, which would (I can suppose) "clog up" a Project with code that needed to be saved with it (as opposed to be "sensed and (re-)generated, if need be, when loaded when the Project is opened by LabVIEW").

---

@Quiztus2 wrote:

I think this image concludes the issue pretty good. Be aware that those are project structures that are 100% copies of NI's CMH template. I simply added one VI to the second projects Message Queue.lvlib

---

One problem I have with the Templates provided by NI is "all the Bells and Whistles" that come along with a fairly simple concept, asynchronous transfer of data through channel wires according to particular "rules".  The CMH Template yields a very complex diagram, and if you "mess with it" by adding to the Class that governs the structure and behavior of the CMH, all bets are off if your modification will work without trouble.

Although I have limited experience with it, I would suggest @Quiztus2 consider the DQMH (Version 7.0 has recently been released, and it is supported by a growing consortium of DQMH users and developers).

Bob Schor

[raphschru]

---

@Bob_Schor wrote:

I'm going to try to answer both responders here.

---

@raphschru wrote:

@Bob Any idea why it got implemented like that ?

Why not making native yellow functions that can adapt to any type like for Queues / Notifiers / User Events … ?

---

I'm unsure what @raphschru means by "native yellow functions", but I think the answer to "why it got implemented like that" is because [...]

---

What I call "native yellow functions" are all the LabVIEW nodes that have no block diagram or front panel you can open, because they are likely implemented using native C/C++. Maybe there is a better name (LabVIEW primitives ?). The ones I am particularly interested in are the polymorphic ones, examples:

Can adapt to any array type

Can adapt to any queue type

Can adapt to any class

Can adapt to any strictly-typed VI reference type

All these nodes can adapt to some ranges of types without creating external LabVIEW code, and this is perfect ! So my question is, why a different implementation principle has been chosen for Channel Wires ?

[Bob_Schor]

Thank you, @raphschru, for your clear explanation.  [I think I would have called them "beige native functions"].

I'm unclear what goes on in creating the extended functionality of Channel Wires, but I know that it involves some moderately-heavy-duty LabVIEW Scripting at Development time to add the tailored behavior (such as "last element?" and "element valid?" for Stream Channel endpoints) that the various Channel Wires represent, in addition to narrowing (or "better specifying") the intended uses for the Channel Wires (the distinction between Streams, which carry data, and basically don't branch or join, and Messengers, which carry "signals", or "messages", and do branch and join).

I also appreciate the notion that the Channel Wires maintain the "left-to-right" flow of data within them -- I have a much easier time walking someone through a State Machine based on a Channel Message Handler (using my "simplified" version, as I think I "invented" the CMH before it appeared as Example code in LabVIEW) than a QMH designed based on what ships with LabVIEW.

Bob Schor

[Bob_Schor]

@Quiztus2:

     I might have a suggestion for why you are having problems using the Create Project>CMH template.  I use the Channel Message Handler in almost all of my "major" LabVIEW Projects, but they are sufficiently different that I've not (yet) run into "name-clashing" issues.

     I recently went to a Local User Group meeting where someone was explaining a (very) large Project that used the QMH template, modified to use LabVIEW Classes for the messages.  I asked why he use LVOOP here, but only for the Message Handler stuff, and he said he did it to gain the feature of "Name-spacing", associating the Classes with the Project.  I recently noticed that the shipping CMH models also are using Classes, so I decided to try it on my current Project (which, so far, has three simultaneous CMH loops, a Stream, and two Tag, all Class-based), and I'm not sure I notice a benefit (other than getting me more familiar with LVOOP).

     The problem, I believe, you are having is that LabVIEW is getting "confused" when trying to work with Message Queue.lvlib.  You have two such libraries, with exactly the same name, stored in the same place.  So when you try to use the "other library with the same name", it looks, says "Oh, the library is already here, I don't need to recreate it", and oops, its "members" are wrong (it does, or doesn't, have "Enqueue Messages").

The solution, I think, is simple.  In your Project, where you define the Messenger Class, give a unique name to the Class.  I also recommend that you open your Project and look at the Dependencies, which should show all of the ChannelInstances .lvlibs at the bottom of the list.  [To see the Dependencies, you might need to click on "Project" at the top of the Project View, and enable "Dependencies" under "Filter View"].

I just did this for my current Project.  It showed me the six Channel Wires I've created, four of them with Class names, one (a Tag) with a name of the TypeDef I used for the Cluster carried by the Tag, and one, a Tag carrying a Boolean, with the name "Tag-bool.lvlib".  That last worries me a little bit -- can I have two such Tags operating OK as long as they don't "talk to each other"?  I don't know, but will surely write a little VI to test this out!  Thanks for making me check this!

Bob Schor

[Bob_Schor]

Drat!  As a result of a question from @Quiztus2, I've examined a particular case of a Tag Channel Wire based on a Boolean variable.  The question is, given the "simplicity" of Booleans, can you have more than one Boolean Tag Channel Wire, say one carrying Button 1 to LED 1, and another carrying Button 2 to LED 2, in the same VI.

The "simple answer", I am sorry to say (at least for LabVIEW 2021), is No.  This surprises me, as I'm reasonably sure that Stream and Messenger Channel Wire do not have this "problem".  [How do you know, Bob?  Have you written another Test routine to check this?  Grrr, no, but I'll get right on it, as Channel Wires are my #1 favorite LabVIEW innovation since LabVIEW 2015 (where they were a "hidden feature").  Sigh.

Bob Schor

[Quiztus2]

I got the advice from NI Tech support not to use 2 Projects at the same time. I don't know what to say.