Script the Regeneration of Channel Wire Instances

[paul_cardinale]

Is there a way to programmatically force the regeneration of channel wire instances?

(My deployer goes tilt when when it tries to deploy a project that has a missing channel wire dependency.)

[raphschru]

In the folder "LabVIEW 20XX\resource\ChannelSupport", there is the VI "Regenerate Channel Instance.vi", but I couldn't find how to use it.

You must give the channel instance names to regenerate, which I assume are the names of the generated channel folders in "LabVIEW Data\20XX(XX-bit)\ExtraVILib\ChannelInstances", and also a "Transmission Type", which I have no idea what it is...

[Bob_Schor]

A "trick" I was taught by my original LabVIEW "mentor" (LabVIEW 7.0, well before LabVIEW Project!) was to create a "VI Tree", sometimes called "The VI of Power" (you have to give it an Icon that starts out "Sub-VIs and TypeDefs" and ends "One VI to Rule Them All, One VI to Bind Them ...  In Austin, where NI Dwells").

This is simply a VI that has contains basically all of the other VIs and TypeDefs that you are using.  The idea is if you open this VI, it "forces" all of its "sub-VIs" (which are simply the VIs and TypeDefs you are using in your Project) into memory, which (in turn) instantiates the instances of their Channel Wire components in the appropriate ExtraVILib folder in <Your Profile>\LabVIEW Data.

I often have the opposite problem.  While developing, and running from the Development environment, every thing is good.  If I start with a "clean slate", opening a Project with lots of Channel Wires in the Top Level VI (and other supporting sub-VIs), and bring the Top Level VI into memory (it seems to "load itself" when I open the Project), I see LabVIEW busy compiling several of the Channel Instances I use.  If I "open the Tree" and force all of the VIs into memory (about 200, including TypeDefs), it does a bit more work, but then is quiet.  This particular Project uses a Channel Message Handler with several parallel side loops handling such things as communications from a RIO system connected by reciprocal Network Streams carrying Messages between Host and Remote (as well as Streams for Remote-to-Host data), WatchDog functions, etc.

But when I go to build it as an Executable (so I can deploy it to a PC with just the LabVIEW Run Time), I sometimes "choke" the Application Builder.  A "Fix" is often to just delete the Channel Instances folder inside My Documents\LabVIEW Data\2019(32-bit)\ExtraVILib and try again.  Or maybe reboot.  Or maybe mumble to myself for a few minutes ...

Bob Schor

[paul_cardinale]

---

@Bob_Schor wrote:

A "trick" I was taught by my original LabVIEW "mentor" (LabVIEW 7.0, well before LabVIEW Project!) was to create a "VI Tree", sometimes called "The VI of Power" (you have to give it an Icon that starts out "Sub-VIs and TypeDefs" and ends "One VI to Rule Them All, One VI to Bind Them ...  In Austin, where NI Dwells").

This is simply a VI that has contains basically all of the other VIs and TypeDefs that you are using.  The idea is if you open this VI, it "forces" all of its "sub-VIs" (which are simply the VIs and TypeDefs you are using in your Project) into memory, which (in turn) instantiates the instances of their Channel Wire components in the appropriate ExtraVILib folder in <Your Profile>\LabVIEW Data.

I often have the opposite problem.  While developing, and running from the Development environment, every thing is good.  If I start with a "clean slate", opening a Project with lots of Channel Wires in the Top Level VI (and other supporting sub-VIs), and bring the Top Level VI into memory (it seems to "load itself" when I open the Project), I see LabVIEW busy compiling several of the Channel Instances I use.  If I "open the Tree" and force all of the VIs into memory (about 200, including TypeDefs), it does a bit more work, but then is quiet.  This particular Project uses a Channel Message Handler with several parallel side loops handling such things as communications from a RIO system connected by reciprocal Network Streams carrying Messages between Host and Remote (as well as Streams for Remote-to-Host data), WatchDog functions, etc.

But when I go to build it as an Executable (so I can deploy it to a PC with just the LabVIEW Run Time), I sometimes "choke" the Application Builder.  A "Fix" is often to just delete the Channel Instances folder inside My Documents\LabVIEW Data\2019(32-bit)\ExtraVILib and try again.  Or maybe reboot.  Or maybe mumble to myself for a few minutes ...

Bob Schor

---

Hmm.  Maybe it was because the VI that was using a Channel Wire was a dependency of an Express VI.  Maybe Express VIs and Channel Wires don't play well together.  I'll have to do more digging.

[santo_13]

Sometimes, on certain computers when run using RTE in TestStand, channel wires appear broken but work just fine in the Development adapter. In this case, I would clear the channel wire VI location in documents and let it regenerate on that PC.