Channel wires broken when updating from 2018 to 2019

[thols]

I am stuck trying to upgrade to LV 2019 regarding channel wires. At this point, I almost thought I fixed it but end up crashing LV constantly. I will explain the issues I have had and what I have tried to do to work around them. It would be interesting to know if others have similar issues or ideas how to fix it.

I just installed LV2019 and rebooted PC. "Wohoo, LV 2019 is out, YES! (I thought...)". But when loading my project with about 20 channel wires of different types, many of them were broken and some VIs which contains them showed "failed to compile".

Some channel wire VIs were also broken (Messenger-...Wrap and Unwrap). These have a class as message type.

I tried restarting LabVIEW and loading smaller parts of the code but the issue remained.

I searched and found that one trick was to delete the \ExtraVILib\ChannelInstances folder. I did, but the result was the same. I also see now (not sure if it was from the start) that a few endpoints are missing and replaced with the question-mark VI symbol. Another trick would have been to copy the \ExtraVILib\ChannelInstances folder from LV2018 and recompile, but I'm not sure that is such a good idea so I didn't do it.

I tried recreating the channel writers and readers, but some data types (e.g. a simple error cluster) just creates a channel endpoint of numeric type (default template?). It creates Stream and Tag correctly but not Messenger.

So I tried restarting LabVIEW to just create a VI to recreate the error cluster endpoint. When LabVIEW unloads the VIs, a dialog shows "compiling" on a number of files (happens every time now). After the fresh restart, I could create an error cluster Message writer. But I also have to recreate the Channel indicator as the types don't match. And when I restart LabVIEW and reload the project, the error cluster writer is broken again. So I deleted \ExtraVILib\ChannelInstances again with the intention to one by one recreate the faulty channel endpoints.

(An observation when at this point open a VI with nothing but a typeDef in it is that the dialog that displays that a channel wire is being created for first use displays. The class that the VI is in has a channel wire though, so I guess that is why.)

If I load the project and remove the question-mark VIs and try to recreate the missing channel endpoint, LabVIEW shows a message "LabVIEW could not create the requested channel endpoint. Template: Messenger, Error code: 1051". Another time it showed the same message but error 43!

At this point when I shut down LabVIEW I get an crash report (attached). It is full of Channel wire errors. Opening and closing the project without messing with the channel wires works with no crash report (although the recompile dialog is still there).

I guessed I had to gather the channel data types to manually recreate and start a simple VI and recreate them from there. I did a few and got tired, since I had to make sure not to load anything that would load the incorrect channel wires at which time I would get the dialog that LabVIEW cannot recreate the endpoint. So I ended up reinstalling LabVIEW and rebooted between un-/install and after.

After restart, I opened the code part by part. The channel wire with the error cluster worked. The second searches for <extravilib:\ChannelInstances\Messenger-class'Messages.lvlib-Messages'\Element.ctl> and then pops "LabVIEW: (Hex 0x4A) Memory or data structure corrupt. The file 'Element.ctl' could not be loaded". And If I try to recreate a channel from a typedef I get error 1051 again.

I ended up removing all channel endpoints that were broken, deleted the\ExtraVILib\ChannelInstances folder, deleted all controls and indicators connected to endpoints, and recreated that code step by step. I finished a very small VI with only two channels. But when I "save all" it crashed. If I create a new project and add the class the VI is in, LV crashes too. The class is pretty small, error free, resaved in LV2019. I tried mass compiling: crash. I tried forced recompile: crash.

Any ideas?

[oscarfonseca]

Hello thols,

Thanks for sharing this experience with the community. I can definitely see how this behavior can be frustrating (especially since your project is based in this functionality!). Do you know if this has happened with more than one computer?

Given the different errors and steps you have already gone through, I recommend opening a support Service Request with our team, so we can further troubleshoot and investigate with you.

Thanks,

[Bob_Schor]

Sorry, I haven't completed the installation of LabVIEW 2019.  I use a lot of Channel Wires (I just gave a presentation of a routine that can have >100 of them running at the same time, quite nicely).  I hope to complete the installation shortly (though I'm currently "again on-the-road" so it may take a few days), and I'll certainly try them out.

Can you attach any "code that fails"?

Bob Schor

[Bob_Schor]

So the Good News is that I finally got LabVIEW 2019 installed.  I'm going to post separately some problems I had with the Installation (and the Fix, which was to update NIPM, the first step in the Installation, then once the Install crashed, open the updated NIPM, install the updates first, then continue with the rest of the installation.

I opened my "large Channel Wire application" (it contains >10 different Messenger Channels, two Streams, and a Tag channel) and it loaded successfully (I had to load it "in pieces" -- it is large enough that when generating Channels for the first time, it can sometimes "hang", with the fix being to load a few routines at a time, starting with some of the lower-level routines first).  I can't actually "test" this code, as it's a large DAQ application that runs up to 24 simultaneous "Stations" that consist of a VISA device sending readings at 10 Hz and a Video camera with a 30 fps feed, but at least there are no errors in opening the code and generating the Channels.

Bob Schor

[oscarfonseca]

So, we're still seeing The Hang with the large project, Bob? I'm sad to hear that!

[Bob_Schor]

Oscar,

     Not to worry!  It may be a "one-time glitch", as this was one of the first things I tried on my newly-installed LabVIEW 2019.  I just tried to replicate the "hang" by first deleting the ChannelWires folder in the LabVIEW 2019 Folder holding ExtraVILib, loading the Top Level VI, then loading the entire "Tree" (which forces every VI in the Project into memory).  No problem.  Repeat -- delete ChannelWires folder, and start by loading the entire Tree -- again, no problem.  So it might have been a "first attempt" thing (some code getting "compiled on first use" and hanging the system, who knows?), but seems to be OK now.

Bob Schor

[thols]

Update:
I was just about to open a service request so I decided to thoroughly go through everything again.
In short: I noticed I had issues in LV2018 too (occasional crashes and exe-file that complained about "could not load front panel" on completely unrelated VIs). It turned out that both my LV2018 installation AND my VIs with channel wires had become corrupt (opening on clean VM with LV2018 did not work, reinstalling did not work). I finally fixed it by removing every trace of channel wires and then opened the code in LV2019 and remade the channel wires from scratch. And now all is OK! My concern is: what made the installation and VIs become corrupt? I cannot think of anything else than the channel wires. But since I ended up in LV2019, I hope my concerns will not become reality. I will take the advice I usually give to others and set up a continuous build VM to make sure nothing is broken or that I know exactly when it happens.

I was about tho give a more detailed procedure of what I did, for reference, but as I go through my notes now, I see that they are a bit ambiguous, and after the weekend, my memory is cleared. So I will leave it at that and be happy that it works now and that I can use LV2019. Crossing my fingers that I do not run into any more unpleasant surprises.

Bob, I think I saw that you were giving a presentation at NIWeek about channel wires. I couldn't make it but would love to see it. Will it be available online perhaps?

[thols]

So, I opened my code in a clean LV2019 VM to be able to get my continuous build machine running.

When I open the code, LV searches for <resource>:\Channels\Undefined\Instantiate.vi in Undefined.lvlib. I could not find such a VI on disk, so I let LabVIEW continue to load the code. When loaded, lots of channel related VIs are broken, and I can see that only the "Messenger-class'Messages.lvlib-Messages'"-related VIs are created in the ChannelInstances folder.

When I did not post my detailed procedure in my last post, I was unsure of how I got LV2019 started. My notes said I copied the LV2018 ChannelInstances folder, but I had no note of if I first tried to open LV without doing so first. I now remember I did and can confirm that the same happens on the VM with a fresh LV2019, and that copying the ChannelInstances folder from the working PC makes it work.

I will open a service request. I don't want to rely on copying the ChannelInstances folder. That doesn't feel stable.

[oscarfonseca]

Thanks for the updates, Bob and Thols!

Thols, I agree opening a Service Request is a good next step. The support team will likely need a small reproducing case to test it in-house. It doesn't sound right that LabVIEW is not being able to regenerate your channels in a fresh installation of the software. I wonder if this is happening with a specific type of channel? Feel free to refer to this post when speaking with the team.

Thanks,

[thols]

I now have a very minimal code that can easily be recreated from scratch and get issues with loading channels on another PC. The behavior can be reproduced by NI and CAR 738559 is filed.

I have attached the code if anyone wants to see. What I did was to create a class, add the controls to the ctl of the class. I then created a VI in the class and in that created a channel writer of messenger type from the ctl of the class and created an indicator from that and connected to the conPane. When I load this code on another LV2019 (a LV2019 VM with the ExtraViLib\ChannelInstances-folder deleted), I can load the project. But if I close it and open it again, LV will search for “element.ctl” and as it won’t find it, the writer endpoint VI will not have the class type as data but a numeric (default type?) and not be executable.

This is not exactly what happens when I load my real project, since I cannot load it even the first time, but the end result is the same. I have practically used the exact same principle as the example “Measure and Log.lvproj”, which also uses a class containing the same data as channel type.

I have found out one more thing. It was not my LV installation that was corrupt as I wrote in the forum post, it was the runtime of LV2019 (which was installed with LV2019) that tried to run a 2018 exe but failed. It actually fails for all installed exes on my dev-PC with both LV2018 and 2019 installed. For these exe’s, I had set the “allow future versions of the LabVIEW Runtime to run this
application”, but that apparently was a bad idea. This is not an issue for me as I will just not use that feature again.