Work-Around for Possible Channel Wire Problem

[Bob_Schor]

I have been an enthusastic user of Channel Wires since their introduction as a "hidden feature" in LabVIEW 2015.  With their official release in LabVIEW 2016, I have used them in a number of projects.  One, a behavioral monitoring task, involved more than a dozen different Channel Wires, with multiple instances as the Project involved "spawning" (running via Start Asynchronous Call) Clone VIs (up to 24 sets of 4 Clones running as a unit).

I had some trouble installing LabVIEW 2017 on my machine, so until very recently, I had not ported this routine to LabVIEW 2017.  However, a colleague to whom I sent it to study reported that he had trouble opening it, and when he finally got it opened, there were "broken VIs" (in several of the Channel Support routines).   I "borrowed" a PC that had LabVIEW 2017 installed, verified the problem, and a few months ago submitted it to NI, where it is currently under study.

I've since successfully installed LabVIEW 2017 and LabVIEW 2018 in VMs.  In both machines, my Project does not load if you simply try to open the Top-Level VI -- it starts to load, starts compiling Channel routines, then simply stops, becoming unresponsive, and after 2-4 minutes, a Windows dialog box appears saying "LabVIEW has become unresponsive".  If you say "Stop", Windows closes LabVIEW and sends a report to Microsoft (of course).

In trying to understand this issue, I tried opening the Project and loading some lower-level code.  It loaded fine.  I loaded some Clones that used Channels.  They loaded fine.  I worked my way up until the only thing left to load was the Top-Level VI (mind you, there are about 300 VIs in this Project ...) -- it loaded fine.

I'm guessing that the problem here arises when multiple Requests-to-Compile occur when working with a VI that has several "layers" of nested sub-VIs.  What if you did the equivalence of a Mass Compile, but forced the order to be Deepest-first in the File/Folder Hierarchy?

I cheated slightly.  I have my Project arranged in Virtual (and corresponding Disk-based) Folders, with sub-VIs and Type Defs having their own folders, and with the Clone routines also having several "layers" (including their own sub-VI and TypeDef folders).

So I wrote a routine, "Safer Mass Compile", designed to be run from within the Project.  The "real work" is done by the routine "VIs by Depth", which finds all of the VIs in the Project folder and sorts them by the number of sub-Folders it takes to get to them.  Here they are (in LabVIEW 2016, the earliest Version that supported Channel Wires and where this routine might be needed):

Vis by DepthSafer Mass Compile

One Warning/Suggestion -- I normally have the option "Separate compiled code from new files" turned off, but I must have turned it on in my LabVIEW 2018 installation.  I've now turned it off again so that I don't have to worry about having to Safely Mass Compile every time I check out my Project.

Bob Schor

[Kyle97330]

Do you think a possible alternative would have been to copy the "Documents\LabVIEW Data\201X(32-bit)\ExtraVILib\ChannelInstances"?  Either from 2015 to 2017 and then mass compile it, or from your folder on the working 2017 PC to your colleague's 2017 PC (which wouldn't need compilation)?  Is this something you could test?

[Bob_Schor · Accepted solution]

The "solution" is in the original post.  I didn't describe two of the VIs -- Find Project Folder uses the assumption that it is included in the Project Folder and does a recursive search up its Folder Tree looking for a .lvproj File.  Relative Paths simply shortens the full path to the VIs by removing the path to the Project Folder.

Bob Schor

[Bob_Schor]

---

@Kyle97330 wrote:

Do you think a possible alternative would have been to copy the "Documents\LabVIEW Data\201X(32-bit)\ExtraVILib\ChannelInstances"?  Either from 2015 to 2017 and then mass compile it, or from your folder on the working 2017 PC to your colleague's 2017 PC (which wouldn't need compilation)?  Is this something you could test?

---

I didn't think of that.  For the same reason that I am hesitant to mess with vi.lib, I'm also hesitant to consider messing with ExtraVILib.  

I was about to say how easy it would be to test, but then I realized that the Test would probably fail!  Suppose I start from scratch with a fresh copy of the Project.  In my case, Subversion has the LabVIEW 2016 code, so if I open it in LabVIEW 2018, it needs to be compiled.  Let's consider three scenarios:

• Channel Instances is empty.  This is what I've been testing.  Also, if it is empty, there's nothing to Mass Compile.
• Channel Instances has a few of the Channels processed.  This is also part of the testing I've been doing.  I can start a Compile, see some of the Channels instantiated, then it freezes.  If I start it again, it might do a few more.  But the point is that until it is all done, all of the Channel code isn't present, so doing a Mass Compile wouldn't get everything.

However, being an Experimentalist, I'm going to do the following:

1. Go to LabVIEW 2018 and make sure I can load the entire Project.
2. Delete the entire Project, copy the LabVIEW 2016 Version (equivalent to Checking Out from Subversion).
3. Try to load the Main VI.
4. If it fails, 
   1. Do a Safer Mass Compile and verify that it still works.
   2. Do a Mass Compile of ChannelInstances.
   3. Delete the Project, copy from LabVIEW 2016, and try to load Main VI again.

I'll be back with the results of these tests.

Bob Schor

[Bob_Schor]

As one of my sons would say, "Ha, ha, ha!"  

I started in LabVIEW 2016.  Deleted ChannelInstances folder.  Opened Project, loaded Murine, the Top-Level VI, lots of Channels appeared (8, I think), VI loaded without error.  Full of confidence, I loaded the Murine "Tree" VI (which simply contains all of the VIs in the Project).  LabVIEW hangs (!), the problem that I saw with LabVIEW 2017 and 2018, but not (previously) with LabVIEW 2016!  This is weird ...

Start trying to do smaller loads.  Load Main, then load the Tree for a small set of VIs that analyze the data collected by Murine.  Another hang.  When I restart LabVIEW, I get the option to "Recover", and choose it.  Another Error message pops up saying there's been a problem with recovery, I should save files in LVAutoSave\Error and choose "Delete backup files".  I do.  Now I can't open the Project -- Windows tells me "You must have Read Permission to view the properties of this object".  When I try to change this, it denies me access, saying I don't have permission (though I'm an admin, and should be the owner of this file).

Time to reboot, wipe the folder, and do an Update from Subversion.  I'll be back (I hope) ...

Bob Schor

[Bob_Schor]

 Well, drat.  About five hours of work on this problem managed to vanish, probably because I took a break for dinner and/or forgot to save stuff.  It's been very strange.

For about two years, now, I've said that this Project (Murine) was loadable and able to be compiled in LabVIEW 2016, but not in LabVIEW 2017 or 2018.  Well, if I start with a newly-deleted ChannelInstances folder and try to open the Project in LabVIEW 2016, I also am having problems with LabVIEW "hanging".  At one point, I said "Oh, I'll just run my Safer Mass Compile routine", but that also didn't work.

What did work required some unusual steps.

• Start by not opening the Project file.
• Load the first of three Analysis VIs (not sure why these are problems ...)
• Load the Analysis Tree (VI containing all the Analysis VIs and sub-VIs).
• Load the Murine Tree (thereby loading all the VIs in the Project).  Note that all these Loads result in intact Run Arrows.
• Close LabVIEW, saving any VIs that need to be saved.
• Open the Project.  The Murine Tree can now be opened without problems.

I then opened the LabVIEW 2018 VM and tried doing similar steps, starting by not opening the Project.  Couldn't get it to work.  Tried copying the ChannelInstances Folder from LabVIEW 2016 and Mass Compiling it in LabVIEW 2018.  Got many (all?) "Bad VI" notifications.  What did work was opening the Project and running my Safer Mass Compile routine (which did not work in LabVIEW 2016).  Go Figure.

Sorry to go on like this -- I really like Channel Wires, find them very easy to use and very intuitive.  Not every Project is going to have so many at so many levels of hierarchy, and I'm certain the Channel Wire "team" will get this straightened out ...

Bob Schor