Issues with Channel Wires on Larger Projects

[Bob_Schor]

I've been developing a mid-sized Project containing about 250 VIs and about 70 TypeDefs, all organized in a single LabVIEW Project.  There is a Main VI that does all of the Data Acquisition and Control, three Support Routines that create and manage some of the Configuration Files, and some Test Routines for trying out particular algorithms.

When running, the Main routine "spawns" (Start Asynchronous Call) up to 24 "Clones" that consist of four parallel loops -- a "Station" that communicates with the Main routine, a Balance routine that acquires data from a Balance using a VISA protocol at 10 weighing/sec, a Camera routine that acquires video images at 30 frames/second, and a Video routine that creates AVIs from the video images when the Balance signals "something happened".

All of the parallel loops are tied together and controlled using Asynchronous Channel Wires.  There are two Event Messengers, 11 Messengers, one Stream, and one Tag (if my count is accurate).

The code is being developed in LabVIEW 2016 (32-bit) on three PCs -- one Windows 7 Pro (64-bit) and two Windows 10 Enterprise (64-bit, Creator).  The code is maintained on Subversion, and I do an Update before starting work.

To facilitate development and find errors quickly when I make changes to, say, a TypeDef, I've created several "Tree" VIs that allow me to quickly load into memory sections of my Project, e.g. all of the Balance VIs, or all of the Support VIs.  Last night, I committed what I hoped was a near-final version of the code from my Laptop Windows 10 machine, verifying that there were no Broken Arrows in any of the VIs in the Project.

This morning, I updated the code on my desktop Windows 10 machine, which hadn't "seen" any code development on this Project for a few weeks.  In particular, there had been changes made to several of the TypeDefs underlying some of the Channel Wires used in the Project.  Thus it was no big surprise when multiple VIs showed broken arrows, and missing Channel dependencies, when the Project was opened and the VIs were loaded.

Channel Wires have a peculiarity that the LabVIEW code that supports their features lives neither in the Project nor in vi.lib, but rather in the User's LabVIEW Data Folder in a folder called ChannelInstances that is a sub-Folder of ExtraVILib.  When a Channel Wire is first encountered in Development, "magic happens" and the appropriate support code is created and place in this Folder.  A consequence of this is that springing a "change" to a Channel (for example, by doing an SVN Update of LabVIEW code) can lead to "lost" Channel support routines and broken wires.

The solution is normally simple -- simply close LabVIEW, delete the ChannelInstances folder, reopen the Project, reload the VIs, and wait while LabVIEW rebuilds the Channels.

But today, this didn't happen.  Instead, after several rounds of "Compiling ..." notifications, LabVIEW "got stuck" -- the spinning "Wait, I'm busy ..." signal appeared (for > 1 minute), and when I tried to close LabVIEW, red X's appeared on the Close button, a few seconds went by, and I got the message "LabVIEW appears to not be responding ..."  I chose to close LabVIEW and try again.

So that's the problem.  I tried multiple times to fix this by closing LabVIEW, deleting ChannelInstances, and restarting, largely getting the same result.  Any suggestions?

Bob Schor

[Bob_Schor · Accepted solution]

Well, I think I finally fixed it.  I'll tell you how in just a minute, but first want to lay out a few points:

• I'm a huge fan of Channel Wires.  This reasonably-big Project uses a lot of them, and it has simplified Development and improved the "logic" and "explainability" of my code tremendously.
• Most of the time, Channel Wires "just work".  A few times, particularly when moving between Projects where I might have a Messenger Channel named "Message" that has one Cluster as its TypeDef, and a different Project with a Messenger Channel based on a different TypeDef, I've encountered the broken-arrow/missing Channel problem when opening the VI (but never the "infinite wait"), but it was always fixed by deleting ChannelInstances and allowing LabVIEW to rebuild the Channels.

To review -- I have a 270-VI Project involving a lot of Channel Wires that I had committed to Subversion from my Laptop Windows 10/LabVIEW 2016 system, wanting to test it on my desktop Windows 10/LabVIEW 2016 system this morning.  I updated the code, but could not successfully open it in LabVIEW 2016 without a lot of errors, problems with the Channel Wires, and (in some instances) LabVIEW becoming un-responsive.

Here, I was working with (what I think was) a fairly old version of a mid-sized Project (and a given set of ChannelInstances) and a significantly-changed new version, with several of the TypeDefs defining the Channels now different.  Indeed, I also was instances of Case Statements that were based on Enum definitions (one Case for each Enum value) have a combination of "Missing Case Elements" and "Duplicate Case Elements" as the Case Labels got all messed up.  I fixed these "by hand".

To fix the problem of not being able to load all of the VIs in the Project without having LabVIEW go into a "stuck waiting" state while deciding if/how to build new Channel Definitions, I tried loading smaller sub-Trees, say, all of the Balance routines, then all the Camera routines, etc. instead of saying "Load everything all at once" (which is what I was doing on my Laptop last night, and had always worked).

I should mention that my Tree structure has some small Trees (like Balance and Camera that have only the Balance and the Camera routines, respectively, installed), a slightly larger Station Tree that has the Station code, which includes the Balance, Camera, and Video loops, so I put the Balance, Camera, and Video Trees inside the Station Tree, and the Main Tree, which includes the Main routines, the Support Tree (consisting of the independent routines that handle such things as the stand-alone Configuration File routines), and a Test Tree which has some Test routines.  The goal is to be able to load this Main Tree, but that was definitely failing.

So I started backwards, loading Video, Balance, Camera, then Station.  So far, so good.  But then loading either Support or Test would cause a hang.  So stop (and handle "LabVIEW 2016 is not responding ...", close LabVIEW, delete ChannelInstances, and try again.

Loading Test first showed the error in one routine where a Case Statement got screwed up (mentioned above).  Fixed that, but still got stuck.  Another restart.

Eventually, working from the Bottom up, I got all of the Trees, including the Main Tree (done last), to load.  One final test, trying to load the Main Tree first (as had worked last night on my Laptop), now works.

I'm definitely not going to give up on Channel Wires.  I have not had a chance to test whether LabVIEW 2017 behaves any better than LabVIEW 2016 in this regard, as I have had difficulties installing it on my Windows 10 systems (I tried installing it on my Laptop, and it blew both LabVIEW 2016 and LabVIEW 2017 away -- it took about a week to get a working system back).  For now, I'm concentrating on getting this Project fully tested and deployed ...

So the "fix" for cranky Channel Wires is as follows:

• Don't be afraid to delete the ChannelInstances folder in the ExtraVILib folder in your LabVIEW Data Directory.  You will lose all of your Channel Definitions and assorted support code, but when you load your Project, they should be rebuilt.
• It does appear to matter in what order LabVIEW encounters Channels (as judging by my experience that loading Trees in different orders can fail, or can work).
• Once Channel definitions for a Project have been realized, they are likely to remain stable unless you make significant changes to the definitions associated with the Channels in the Project.

Bob Schor

[Blokk]

Thanks for the tip that deleting the ChannelInstances folder, can help reviving broken Channels. Most often I see problems when I modify the typedef cluster used for a channel. I wonder if the underlying Channel creation/modification will be improved in future LV version...I still see some problems using LV 2017. But I am also a fan of channels. I will be more if some of these programmatic issues get fixed. And some of the annoying but more cosmetic behaviours, like channel wire appearance through structures, alignment bugs, etc...

[Bob_Schor]

Brief (?? am I ever "brief"??) followup --

Now at work, Windows 7 Pro (x64), 32-bit LabVIEW 2016 (same LabVIEW as home machines).  Did a Subversion Update, tried to load main Tree (which contains all the sub-Trees), again got "Endless Spinning Wheel".  Closed "unresponsive" LabVIEW, reopened Project, started loading Trees from the bottom up.  Got everything loaded except Tests, which hung the system.  Restarted, loaded Test first, then the other "bottom" Trees, finally the top Tree (which had all its sub-Trees already in memory).  Worked fine.  Restarted LabVIEW, and can now load the top Tree without hanging, i.e. the Channel definitions are now sufficiently "OK" that whatever was causing the hangup is gone.

Bob Schor

[Blokk]

Bob, after the Subversion update, and before trying to load your project trees, did you delete the content of the ChannelInstances folder?

[Bob_Schor]

---

@Blokk wrote:

Bob, after the Subversion update, and before trying to load your project trees, did you delete the content of the ChannelInstances folder?

Yes, since I knew (from last night at home) that I was going to have trouble ...

BS

[RVallieu]

I just ran into this issue.  I cautiously utilized 2 channel wires in a small project for a customer.  One channel was a Message channel with Cluster of Enum and Variant, the other Channel was a Stream of Double - just used to update a chart with the latest logged data on the UI.

When I had them download the code from our server and then tried to open a clean install on the clients PC I ran into this issue with the Cluster Channel Wire not being able to reconstitute itself.  I didn't come across this thread until after I solved the issue.

The first time LabVIEW jusy hung - I killed the process and on the next open just told it to Ignore All - and by hand rebuilt the Channel Writer and Channel Reader.

Next time I encounter this I will see if there is a folder to delete in ExtraVILib - not sure if it was there originally as this was a new instance of the code, and a fresh install of LV2016 on the customer PC.

[Ben]

Nice collection of badges you have there!

Spoiler

Why don't I see one for you CLED ?

Spoiler

Reminds me of when I was a cub scout the merits badges went down the tail of my shirt.

Ben

Spoiler

FYI:

Ryan is another Senior Architect at DSA but he is the one with the CLED!

[RVallieu]

[Continued OT]

"Why don't I see one for you CLED?"

It is there.  It is the badge right next to Architect.  I already brought this up to NI (as have others) that the Embedded Badge is too similar to the CLAD Developer Badge.

See my post: http://forums.ni.com/t5/Certification/NI-Acclaim-Badges-CLD-and-CLED-too-similar/td-p/3643473

My badges are also live links to the Acclaim website and if you click the 2nd badge it takes you to my verfied CLED page on Acclaim.

[JÞB]

For Ben

CLD is orange with a "+" glyph Yellow on Black

CLED is orange with a "+" glyph Black on Yellow

Both have the word "Developer" in Black

Ryan is sporting right- you just need a better field guide to observe them in the wild.