BUG: Creating a tag channel wire of a network stream read only reference, creates it write-only breking the diagram on LV 32-bit but not in 64-bit

[EMCCi]

As said in the title. If I:

1. Open LV 2018 32-bit and create a new VI
2. Place a "Create Network Stream Reader Endpoint" 
3. Right click on reader endpoint reference and create tag channel, it breaks the wire because it creates the channel wire for writer network stream. It doesn't matter if the tag channel wire itself its read or write, it will be wrong any way, but any other type of channel wire (stream, message...) will be ok.
4. If I repeat the same steps with LV 2018 64-bit it works properly. If then I open the VI edited with the 64b version with the 32b one, it will be break again.

Can you reproduce it? Any workaround/fix?

[Bob_Schor]

Well, I'm a Channel Wire enthusiast, and have been using them since LabVIEW 2015 (they were "openly" introduced in LabVIEW 2016).  There were a few bugs in the first few years, and I'm currently using LabVIEW 2019 and 2021, where Channel Wires appear to work pretty well in both LabVIEW (32-bit) and LabVIEW Real-Time (32-bit).  I haven't installed or tried 64-bit LabVIEW, as I haven't felt I had a need for it.

So, in LabVIEW 2019 (which I feel reasonably confident is pretty stable)(wow, that was a pretty waffle-y statement!), there's no problem creating a Tag Channel for a Network Stream Reader Endpoint.

So migrate to LabVIEW 2019, if you have it available.

Bob Schor

[EMCCi]

I got more info about this issue.

I've seen that the channel instances are saved under: "C:\Users\User\Documents\LabVIEW Data\2018(32-bit)\ExtraVILib\ChannelInstances\...", and that the network stream tag channel was saved under "Tag-ref(UserDefinedRefnumTag)" lib/folder. So I deleted it, and created a tag channel for a NS reader and it worked, so great, but then I created a tag channel for a NS writter and it failed because it created the wrong type again.

So when you create the first network stream reference channel, read or write, it creates it under Tag-ref(UserDefinedRefnumTag). When you then create another channel for the opposite reference, write or read, then it goes also to Tag-ref(UserDefinedRefnumTag) and uses the same channel, creating the wrong type, the one that was first created.

EDIT: no LV2019 available nor I don't think it's possible to buy a lifetime LV license anymore so...

[Bob_Schor]

It saddens me that when NI finds an "improvement" in a feature such as Asynchronous Channel Wire (LabVIEW 2019 definitely "fixed" a number of sneaky flaws in Messenger Channel Wires, including their inability to work in the Real-Time Environment, much to my dismay and chagrin when using LabVIEW 2018!), they should (and, who knows, maybe they have) include the fix in LabVIEW Updates.

Have you tried calling NI Support and asking if the "fixes to the problems with Asynchronous Channel Wires in LabVIEW 2018 that were remedied in LabVIEW 2019 ever made it to Patch/Update/SP1 release for LabVIEW 2018" ?  It is possible they will say "You are no longer under a Support contract, so we can't talk to you", but it certainly doesn't hurt to ask.

With the much-hated Subscription model for LabVIEW now in place, situations such as you describe will probably become more common.  Report your efforts to get support from NI back on this Post -- I'm certain that it will reach "sympathetic eyeballs" who may know the right people to contact.

One of my first major projects using the "new" Channel Wires (LabVIEW 2016) involved communicating with a dozen Asynchronous Clones (as in "Start Asynchronous Clone".  I was using what I named a "Channel Message Handler" design (NI now has a Example by that name that ships with LabVIEW) and wanted to use a Messenger Channel to let the "Master" communicate with the "Servants" (hmm, I'm probably going to get this wrong, as its been too many years since I looked at the code) -- anyway, the problem was I couldn't use a Messenger Channel with Start Asynchronous Clone, so I "cheated" and used a Queue.  So if the only place in your code where the Tag Channel Wire breaks is with one Network Steam reference, consider replacing it with a Notifier and see if it can substitute.

[I was going to say that I'm currently using Channel Wires and Network Streams "together", but, then again, I'm not using LabVIEW 2018, so never mind ...].

Bob Schor

[EMCCi · Accepted solution]

I don't think there is much to do with a company that's being run with the Boeing style, milk the cow until it doesn't stand up. There have been a lot of years to change this and it's only going worse.

I simply flat the NS ref to string and then inflate it back. Not beautiful but does the job.