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
