Collaborative development, using channels

[marshaul]

Channels are incredibly useful, but also I find rather annoying when working collaboratively. As soon as a working VI is opened by another user on another machine, LabView starts complaining about the (what should be fully under-the-hood) support VIs for the channels. Since these are created automagically, they should be re-created automagically as well when needed. Instead, I get constant messages about "duplicate" VIs, and when I try to build I get failures like this:

A VI broke during the build process from being saved without a block diagram. Either open the build specification to include the block diagram of that VI or enable debugging to include the block diagrams of all VIs in the build. Report this error to National Instruments technical support.

C:\Users\myuser\Documents\LabVIEW Data\2016(32-bit)\ExtraVILib\ChannelInstances\Tag-dbl\Endpoint.vi

This isn't "my" VI, and it shouldn't be my job to fix it. How do you all deal with this mess?

[Bob_Schor]

Yep, you've hit on one of the "down-sides" of Channel Wires (I complained about this when they were introduced as a "hidden feature" in LabVIEW 2015).

"Magic" comes at a price.  In the case of Channels, NI chose to implement the (variable) features of each Channel in a "User-Global" fashion, that is, to have all of the Channels for a particular User stored in their "My Documents" within their LabVIEW Data Folder as an "Extra" VI.lib.  In particular, Channels are not "bound" to a Project, so if you use SubVersion or other forms of Version Control, each User will need, when they first open a Project with Channels, to re-generate their own set of Channel support code in their ExtraVILib.

Fortunately, there is a fix.  You notice that the Error message you are receiving references the My Documents folder of "myuser", and if you descend along the path, you come to the culprit ExtraVILib folder where all of the Channel definitions have been saved.  Simply go ahead and delete the ExtraVILib folder, thereby "erasing" the definitions of all of the Channels that "myuser" had referenced with LabVIEW 2016 (32-bit).  [If you are nervous about doing this, rename the Folder to "ExtraneousVILib" instead, allowing you to "go back" if necessary].  Now open your Project, and start loading VIs using Channels into memory -- as you do, LabVIEW will start re-creating the Channels, repopulating the ExtraVILib folder, but doing so in a way consistent with your code.

Bob Schor

[marshaul]

That works for now, but anyone else who comes across this thread should note that I had to regenerate the build specification as well. I can only assume that the existing build spec was referencing the old dependencies, perhaps not updating because the complete path was unchanged? 

In either event, if I attempted a build with the existing build specification, I would get either the same error as before (deleted the ExtraVILib dir. with the project closed), or new and unresolvable errors about how the VIs had changed and were probably corrupt (deleted the dir. with the project open). 

[oscarfonseca]

Marshaul, and Bob;

Thank you for your comments regarding this problem. I'm glad you were able to fix it. Please let us know if you find anything else that's not an expected behavior of the software, so we can address it too.

All the best,

[marshaul]

---

@oscarfonseca wrote:

Marshaul, and Bob;

Thank you for your comments regarding this problem. I'm glad you were able to fix it. Please let us know if you find anything else that's not an expected behavior of the software, so we can address it too.

All the best,

---

Are there plans to clean this up a bit? I recently recommend channel wires to a coworker, sort of in passing, who immediately decided that they were a "much better solution" than what he had been doing (which is of course why I brought it up). But then, after the fact, I remembered all this, and it occurs to me that I will likely be hesitant to recommend this otherwise excellent feature to coworkers in the future, most especially when collaboration is likely. 

[Bob_Schor]

For what it is worth, when Channels were released in LabVIEW 2015 as a "hidden" feature, I was one of the ones "let in" on the secret, and started using (and probably abusing) them every chance I got.

I discovered the problem we are addressing when I used channels with the same name but different "definitions" in different Projects.  I was totally used to the "observation" that with LabVIEW Project, there was no problem having, say, "TYPE Message.ctl" being defined one way in Project A, and another way in Project B (two different implementations, saved within the Project), and assumed that the code that was built for implementing Channel Wires was similarly done the same way, but "behind the scenes" in an auxiliary Folder within the Project.  Nope, they are "Global", saved in ExtraVILib.  I recall suggesting that a Project-based locale might be better, and would avoid these difficulties, but the Channel Developers (AQ + JK) seemed to have good reasons for implementing it as they did. 

I think I also suggested, at some point, there be a Project Command to "Clear all Channel Wires" to let the Developer "start Fresh" when Channel Wires seem to "break" (to avoid having to "know the messy details involving ExtraVILib, details which may change in future releases).  One of my more ambitious recent "Multi-Channel" undertakings required a little care when re-creating the constellation of Channels -- it worked much better creating them from the "bottom up" rather than "Top Down", i.e. opening lower level VIs using channels before opening the top-level VI (which pulls in its sub-VIs, which pull in their Channels and their sub-VIs, which pull in etc.).

Still, I love using them, and am beginning to "inflict" them on some of my mentees ...

Bob Schor

[Bob_Schor]

Oops, I regret to say that I just found an Implementation Bug in Channel Wires in LabVIEW 2017.  I regret not being able to find it earlier -- I'm an early (and very enthusiastic) adopter of Channel Wires, and have used them extensively in all my development since they were released in LabVIEW 2016.

When LabVIEW 2017 Beta was announced, I signed up, but could never get it to authenticate (despite numerous attempts and suggestions from NI Support) -- my intention was to run my code through the new release and verify that Channels still work for me.  Oh, well, so I waited until LabVIEW 2017 was released, and in June, tried to install it on my existing machines (a Windows 7 desktop, a Windows 10 desktop, and a Windows 10 laptop).  All versions of LabVIEW stopped working.  I was successful in uninstalling (all versions of) LabVIEW on my Windows 7 desktop, but attempts to remove LabVIEW from the two Windows 10 machines failed, forcing me to wipe the C: drive and rebuild both machines.  So I skipped LabVIEW 2017.

About a month ago, I got the LabVIEW 2017 SP1 kit, and tried again to install LabVIEW 2017, but this time on a stand-alone Windows 10 machine.  This time, it seemed to install.   So I tried my code, and it seemed to "break" Messenger Channels.  The routine I was testing was a 400-VI Project, with all kinds of complex routines, including asynchronous Clones bearing multiple Channel Wires.  When I tried making a small "demo" routine, the error "morphed" in form and appeared to be "different".  I submitted this to the Support Site, NI was able to verify that it was, indeed, a "new" bug, and filed a CAR for it.  I suspect that the same bug may be present in the LabVIEW 2018 beta, but if they fix it for LabVIEW 2017, they may be able to ensure that the "fix is in" for LabVIEW 2018 when it is released in June.

Bob Schor

[BoKnows]

As a quick addition to Bob's post, this is being tracked as CAR # 631422.

There's also a KB article to discuss it here: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019QNrSAM