Channel wires broken when updating from 2018 to 2019

[donkdonk]

I recognize the broken channel wires, when using multiple PC's.

We have multiple PC's with the LabVIEW development environment in our lab. They all have access to the same network drive folder. We try to keep the NI software identical on all PC's. Because we are a research lab, where ideas may change with the hour, we run our software in the LabVIEW development environment.

The PC's are spread all over the lab and people grab one to control 'their' experiment. So one day, you use PC A for your project, next day it might be PC B.

This usually goes well, but channel wires tend to be broken too often for unknown reasons. I'd love to use them, but after several 'broken wires when opening my project', I gave up. Especially because less experienced users need to be able to run the LabVIEW code and 'ExtraViLib\ChannelInstances-folder delete' things, are no-go's.

Now, as I read this by thols [..] can easily be recreated from scratch and get issues with loading channels on another PC [..] I wonder if that's the culprit.

Unfortunately, I do not have the time/opportunity to recreate the issue (we use LabVIEW 2017 on windows 7 and are migrating to LabVIEW 2019 on windows 10). Furthermore, you guys seem much more experienced, both in using LabVIEW, but also in what happens 'below the surface' when channels are created.

[donkdonk]

I just replied, but somehow the reply disappeared

I recognize this: [..]  get issues with loading channels on another PC [..]

We have multiple PC's with LabVIEW 2017 in our lab and too often I get broken channel wires when loading a project. I'd love to use them, but I gave up.

It could be that I just ran the software from another PC than I previously developed it on. All PC's have access to the same network drive folder, and we just 'grab' a PC to do our experiments (always in the LabVIEW development environment).

[donkdonk]

>>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 just downloaded it and opened it in LabVIEW 2019. Not clear to me what I should do with it.

It seems to open just fine, except that Untitled 1.vi is broken when opened.

[Bob_Schor]

For what it is worth (about $0.02, plain), I've been chasing a very elusive Channel Wire problem that refuses to surface except buried deep in a project with multiple Messenger and other Channels.  I tend to use a Design Pattern similar to the QMH, except I use Messenger Channel Wires instead of Queues.  I define a standard "Message" type, a cluster consisting of an Enum (which I call "Message", and confess I think of as "State", though I "know" a CMH is not technically a State Machine) and a Variant (called "Data").  I have two VIs, "Send Message" and "Receive Message" that convert between Messenger Channel and Message Components.

Here, for example, is "Send B-Msg" -- it is called with B-State (the Enum) and optional Data (typically not used), bundles them together to make a B-Msg, then creates a Channel Writer and outputs it as a B-Msgr (B-Messenger).  "Receive B-Msg" does the inverse -- takes a Messenger, passes it through a Channel Reader and unbundles its output as B-State and Data.Send B-Msg

Now, I should mention that all of this happened with LabVIEW 2018 -- I was unable to build a working LabVIEW 2019 (except as the only version of LabVIEW on my PC, which didn't work for me as I had projects in LabVIEW 2016, 2017, and 2018, so 2019 was banished to a VM until NI R&D suggested a "trick" (and, I believe, filed a CAR) about this.  But I digress ...

What happened is that at random times, the Project that was previously working would get a Broken Arrow in Send Msg and/or Receive Msg.  The problem was in the conversion between the Message Cluster and the Messenger, i.e. "inside" the Reader or Writer.  Diving into the Writer, for example, shows the Message cluster going into a little VI called "Wrap", but Wrap was expected a U16, and it should have been expecting the Messenger Cluster.  Diving deeper, buried in the Messenger routine in ChannelInstances is a Wrapper Class, with a Wrapper Control.  But instead having an Element consisting of the Message Cluster, it has a nice, neat U16!  Needless to say, U16 is not equal to Cluster.

I tried, but failed, to "pin this down".  Right now, this problem has vanished (just as I was trying to make a simplified example to show send to NI), so I (temporarily) moved on.  Sigh.

Bob "Still Enthusiastic About Channel Wires, Especially When They Don't Break" Schor

[thols]

---

@donkdonk wrote:

...

I just downloaded it and opened it in LabVIEW 2019. Not clear to me what I should do with it.

It seems to open just fine, except that Untitled 1.vi is broken when opened.

---

I should have mentioned exactly what to expect when opening the project, especially since I no longer remember and have installed 2019 f2, which unfortunately doesn't mention anything about channel wire issues fixed. But, when I open the project now in an almost fresh VM with LV2019 f2, "Untitled 1.vi" is broken and the error list says "VI failed to compile". The weird thing is that if I force-compiled (CTRL+run arrow), the VI was executable (no broken arrow, I did not run the VI). But I had just yesterday been fiddling again with this old issue to see if I could describe some more of the issues I think I have encountered regarding this, so I had some channels already created. So I deleted the ChannelInstances-folder and opened the project again, and now the first time I get "VI failed to compile", and if I force-compile, I get this:

If I close and open the project or LV again, LV will search for this channel and ask me to find it:

[Bob_Schor]

Aha!  I've just looked at your simple example and it looks quite similar to the same issue that I saw, but could never develop a consistent "minimal example" that failed!  I do not have a lot of experience with LVOOP, and have not (yet) attempted to use Classes with Channel Wires, but here are some observations:

• If you open Untitled 1, you see a broken Wire between Class 1.lvclass and the Messenger Channel Writer, due to wire Source and Sink being different.
  • It is, of course, the goal of the Messenger Creator to match Source and Sink.  Source is a Class based on a Cluster of 3 elements, while Sink was an I16 called "element".
  • This is basically identical to my "broken wire" issues, which I mis-remembered as being a U32 -- this jogged my memory, and I think I also had an I16.  The broken wire is that the Messenger Writer's internal "element" definition is wrong, it should be the Class that is part of the Source.
• Now open the Messenger Write.vi (found in Messenger-class'Class 1'.lvlib).  Notice it shows an "element" control, an I16, wired into a Write with Abort function.  Open this and notice "element" goes into the Messenger's internal Wrapper.lvclass's "Wrap.vi".
  • Open Wrap.vi.  It attempt to wrap the I16 "element" into the Wrapper Class based on the correct Element (open Wrapper Class and see the element, the original "green" Class 1.lvclass).  On the Front Panel of Wrap, replace the (wrong) I16 element with Class 1.lvclass (rename it to "element", for consistency).  When you do this, the broken wire in Wrap goes away.  Wrap.vi now has a "green Class", Class 1 object, as the Input Control (be sure to reconnect it in the Front Panel Connector) and a Wrapper Object as the output.
  • "Walk" this manual correction of "element" backwards, starting with "Write with Abort.  Again, delete the "wrong" I16 element on the Front Panel and replace it with the Class 1 Object defined as the Private Data of this Messenger Channel.  Again, be sure to connect the replace Control to the 4-2-2-4 Connector.
  • Up one more level to put the correct Element (the Class 1 Object) on the Front Panel.
  • For completeness, you should also open Write Scheduled (which will also have the "wrong" element) and fix this, as well -- who needs broken arrows, even if you don't ever use this VI?
• At this point, Untitled 1 has no more Error!
• But Wait, There's More!!  While you are at it, look at Unwrap, which is also "broken, as its "element" is also the I16, which needs to be replaced with the Class 1 object, and the fix propagated up to Read with Abort, Read, and Read Scheduled.  

I'm sure that the Developers, faced with this really nice example of the "Channel Script Gone Wild", will be able to find and fix (and thus rehabilitate) my favorite LabVIEW Feature since 2016.

Bob Schor

[thols]

Bob, thanks for digging deeper. I had started doing that but since I had a simple case and a CAR for it, I didn’t care too much. But when you mentioned the U16, I was about to compose an answer to say that this was very similar. But first I wanted to try a thing out:

I had tried to follow the example "Channel Message Handler" but never got Ack to work. I saw that the example had the project's message class inherit from the "Channel Message" class, but had missed that it also casted the project's message when sending and receiving. So I replaced all my channel controls, indicators and endpoints to the base class’s type. Since the messaging will then be done with the base class type (although the actual data is of the sub-class), I had hopes that this might be a workaround for my initial problem.

When I made the switch to base class, Ack worked. And probing works (haven't tried a custom probe for the channel type yet, but at least there is no error). Before, when I had my class as channel data, I got an error when trying to probe (reported to NI).

But, opening on another PC still has the same issues. Not sure if the following is of interest. But since I refer to this thread in the CAR, and sent NI my complete project, and if someone else gets the same, I’ll add it. I get these issues:

When opening the main VI (as I mentioned earlier in the thread):

And some stream Read endpoints are missing (the question mark VI). If I try to create a Read endpoint from that channel I get:

The thing is, there’s no such files on disk. If I close/open LV again, I get the same thing.

Another annoying thing I found is that the typedef within a channel control cannot be opened with right-click >> show control >> right-click >> open typedef. from the channel wire control, like you can do from e.g. queue controls with typedef-data.

And I get “VI failed to compile” on some VIs. And if I force-compile that VI I get:

I also get some of these errors (similar that you can get when using classes and something else in the class is broken, so I’m guessing these errors will dissapear when the other stuff heals):

I also have one boolean tag, which creates an I16-element on the higher level VIs.

And I also have another issue, with VIMs (should perhaps open another thread or report to NI, but anyway, I get this on some (or all?) of my vims, which makes it even more tiresome to try and open the code on another PC. I get these errors on other projects to:

Its just too much right now with all these errors to try and manually rectify all the issues LV creates when opening on another PC. I will have to rely on the backup of my development-PCs ChannelInstances until (if?) NI fixes this.

And I still have to use this crazy workaround to create Ack endpoints. Although, in fact I realized I don’t need the ack endpoints in my case, since the read and write endpoints themselves can handle the Ack.

[donkdonk]

[..] the issues LV creates when opening on another PC [..]

Keeps triggering me, because that's exactly what we do in our lab. Even the very very basic channel wires (like a simple numeric tag type channel wire running from one while loop to another while loop) may be broken when opening the vi.

[kgriffi1]

My one thing to add is that you can easily corrupt this folder by copying, and pasting channel sources and syncs, and auto syncing to different data types.  Luckily I was playing in my own sand box and I didn't corrupt the working version.

I too have many Channels and when switching machines or even users on the same machine I have found that labview can not auto generate the channels in the correct "order?" to re-create this magic folder.  All my code is backed up, but this folder and it's location have not been because I didn't know it existed till recent.  Luckily I have access to a working version of this folder and if I copy and past it everything works correctly, but if it gets corrupted there seems to be no way to easily get it back.  As stated earlier by others I do not trust this "Very Unstable" auto generation and compilation done behind the scene and I think the only thing for me to do is to remove all the channel wires till this is fixed.  I'm happy to use channels again if this issue gets resolved.