Bug: Channel wire namespace change does not update endpoint VIs

[thols]

Changing the namespace of a class does not update related channel wire endpoint VIs, causing load failure when opening on another LV install.

I moved my channel messaging class out of a lvlib since channel wire probes did not work in lvlib (another issue I will need to report about). This all seemed to work fine, even for executables. But when the class is opened on another LV install (e.g. other PC), the channel wires are not recreated and instead LV asks for the location of the channel instance VIs with the old namespace/path.

I have attached a minimal class and a method calling the Read.vi messenger endpoint. In the VI BD, the top Read.vi endpoint is the one that is still at the old namespace/path, and the bottom Read.vi is the endpoint created from my Message.lvclass after it is moved out of the lvlib (new namespace). If you open this VI, the old and incorrect Read.vi will not be found or recreated.

When opened with the LV install that contains the old namespaced endpoint VIs, both the old and new Read.vi will be loaded:

By changing namespace again by moving the class into another lvlib, I get yet another Read.vi, with the existing endpoints still using the old versions of the path to the VI. So I now have three versions of the same Read.vi with only one being correct. The ChannelInstances-folder now contains three folders and lvlibs for that class's channel VIs:

The VI I have attached already has one Read.vi that points to an incorrect path, but you can try the issue yourself if you just drag the Message.lvclass into another lvlib, and you will get another Read.vi for the new namespace.

The attached VI using Read.vi of the class after opened in other LV install (fresh Win10, fresh LV2020 SP1):

One more odd thing (bug) here is that the channel control graphics gets incorrect after I move the class into a lvlib if the control is shown. This does not happen if the icon is shown. To the left is what it looks like after the namespace change and to the right is what it looks like if I then select "show control":

I have tested in LV2021 too with the same results.

Also attached is a video of how it looks like when opening the attached VI. The lower Explorer window there shows that the new Read.vi is generated but the old is also searched for and cannot be found.

[billko]

This is the major reason why I won't convert to channels.

[thols]

It gets worse. If you at this point right-click the old incorrect wire and create an endpoint from there, you will get:

This is the same error I got for another channel wire issue.

And, the channel control type-def is broken, so I cannot keep it:

To fix it, you have to replace the old incorrect channel control with the new one. Since the TypeDef is not a ctl-file (at least not one I can see), you cannot search for them or do "find all instances" and replace all. You have to do it one by one. This is what I spent a half of yesterday doing for hundreds of controls in my project. Not cool!

Lesson 1: Do not change namespace, ever!

(I know Darren wrote something like that years ago, and not for channel wires, just in general for LabVIEW. I should have listened but everything looked cool, until I opened on another LV-install.

Lesson 2: Use a build server and automate builds. That would have caught this.

(apart from these bugs, channel wires are great)

[billko]

They're fragile.

[Bob_Schor]

A couple of observations:

• The Messenger Channel underwent a change in LabVIEW 2019 (a Messenger2 Channel appears at some point, a slightly different implementation, I understand).  This has caused me some problems, and led me to abandon Messenger Channels for LabVIEW RT code running on NI's Linux RT Engine.  I haven't checked in LabVIEW 2020, but LabVIEW 2021 has gone back to the "name" Messenger Channel (I suspect they are similar or the same as the LabVIEW 2019 Messenger2, which was the "improved" version).
• When using multiple Channel Wires, particularly when some "live" in code that is several levels "deep" (in the Call Chain) from the top, you can get into trouble when loading the Project, depending on the order that the VIs involving the Channel Wires get loaded.  What I found that works is to delete the ChannelInstances Folder (a sub-folder of the ExtraVILib folder in LabVIEW Data\<Version><Bit>, e.g. \2018(32-bit)), find a low-level VI that uses only one (or only a few) of your Channel Instances, and open them first, forcing the build of the Channel Wires "one-at-a-time".  Usually works for me, and I use a lot of Channel Wires ...

Bob Schor

[thols]

I finally took the time to report this (NI does not look at the annual bug thread according to the one I spoke to). It's CAR number is 2250275.

[GRCK5000]

What is the bitness of your operating system. What is your labview version? If your operating system (OS) is 32-bits and your labview code uses 64-bits, you may have this problem. 

[thols]

---

@GRCK5000 wrote:

What is the bitness of your operating system. What is your labview version? If your operating system (OS) is 32-bits and your labview code uses 64-bits, you may have this problem. 

---

Windows 64 bit (who are still using 32-bit nowadays...). I didn't know 64-bit LabVIEW was even executable on Win32.

[santo_13]

---

@GRCK5000 wrote:

What is the bitness of your operating system. What is your labview version? If your operating system (OS) is 32-bits and your labview code uses 64-bits, you may have this problem. 

---

AFAIK, you cannot run a 64-bit application on a 32-bit OS (not even remotely), but the vice versa is possible, you can run a 32-bit application on a 64-bit OS.

Please elaborate on how this may be technically possible.

[GRCK5000]

🤣