08-24-2022 10:40 AM
I have a number of LabVIEW Projects that make heavy use of Asynchronous Channel Wires (a.k.a. "Channel Wires"). Everything is generally fine until I try to build an Executable, which can cause a failure with error messages such as this:
- Messenger2-t'TYPE UI Message.ctl'.lvlib:Messenger2Data.lvclass:ShowData.vi:
Could not determine data types of all wires in this VI.
I can "fix" this, usually, by deleting the "helper" Controls, VIs, Classes and Libraries that my LabVIEW Project "constructs" behind the scenes when I open the Project and load code that creates the Channel Wires, and running the Build again. The figure, below, shows the location of the Folder, called "Channel Instances", that LabVIEW constructs when it encounters Channel Wire code, and uses subsequently when the User actually runs the VIs and utilizes the Channel Wires.
As you can see, there is a folder inside "LabVIEW Data" called "2019(32-bit)". This corresponds nicely to the version of LabVIEW that I have on this machine and used to develop and test the code. When multiple versions of LabVIEW are installed, there are, naturally, multiple "Version(Bits)" folders, placed in LabVIEW data.
The key "repair" step is to force LabVIEW to re-create all of the Channel Instances, the "LabVIEW Helper code" that makes the Channel Wires "do their magic". Simply delete the folder "ChannelInstances" inside "ExtraVILib" inside the appropriate "Version{Bits}" folder inside LabVIEW Data.
Simple. Just write a Pre-Build Action that locates the appropriate Channel Instances folder, delete it, and let the Build proceed.
Oops -- this doesn't work reliably, probably for the same reason that manipulating the Version Number of the Build "before the Build" doesn't work (see this so-far-ignored Idea Exchange, where "Bob from NI" explains that "Pre-Build Action" doesn't mean... .
So I tried another way -- use functions that NI does provide to let me "have my cake and eat it, too", namely run some LabVIEW code to delete the ChannelInstances folder, then run some LabVIEW code to do my Build.
Ah! But what if I have multiple versions of LabVIEW on this PC, and I want to build "using the current version of LabVIEW I'm now running"? Simple, just use the VI (or procedure) that tells you the Version (e.g. "2019") and "Bittedness" (e.g. "(32-bit)". [How this changes with LabVIEW 2022 Q3, I'm not sure ...]. But I'm not aware of such a VI (or procedure) to follow!
Ideally, I'd take my LabVIEW 2019(32-bit) Project, move to a new PC running LabVIEW 2021 SP1 (maybe 2022 Q3, not sure that the Hardware Support is there yet), run my code that includes the "Get LabVIEW Version and Bits", locate the appropriate \LabVIEW Data\20xx(yy-bit)\ExtraVILib\ChannelInstances folder, and delete it programmatically, then build it programmatically.
So how do I determine (within a LabVIEW Project, which has the code I'm trying to build, and the tool to programmatically build it) the LabVIEW Version and Bittedness?
Bob Schor
Solved! Go to Solution.
08-24-2022 11:08 AM
08-24-2022 11:17 AM
08-24-2022 11:23 AM
08-24-2022 08:06 PM
Well, I was pretty sure "The Truth is Out There", and am grateful to my colleagues on the Forum for their rapid response (and a Kudo for Christian). Since I'm using this for my own code that uses Channel Wires (introduced widely in 2016), these methods should be good for at least a few years ...
Bob Schor