Broken Wire LabView 2020

[SunnyT]

Hello,

I have an issue with one of my VIs.  If I open it with Labview 2019, everything looks and runs ok, however if I open it with LV 2020, the wire is broken however it seems to be able to run fine.  I am not sure what's going on ... please help

LV 2019:

LV 2020:

Thank you.

[Bob_Schor]

Now, if we had two actual VIs, rather than "pictures" showing who-knows-what, we could (perhaps) do some tests and sleuthing and maybe figure this out.  Otherwise, I'd suggest opening the one with the broken wire in Microsoft Paint and fixing the image (this is not a serious solution to a LabVIEW problem, but to what you presented to us, an "Image" problem).

Please attach the two VIs so we have a chance of helping you by looking at and trying to understand the problem ourselves.

Bob Schor

[JÞB]

Show red X on broken wires! There is a default OPTION to do that.

The wire does not appear to be "broken" it looks "Maliable"

Very odd. We will need code!

Toss a probe on the maliable segment and show the probe watch window for us phone posters.

[altenbach]

So you are wiring an instrument handle to an integer input of some unrecognizable node using a highly decimated blurry picture that is less than 80 pixels high and you are expecting us to diagnose it???

All these coercion dots don't inspire my confidence, even if the wires are not broken.

What is that node? (call library? something else?). Is this part of a driver package that you updated? Are you sure it is the same? What happens if you press ctrl+b? Since the Vi is not broken, maybe it's just a cosmetic issue.

[Darren]

I have a memory of a LabVIEW 2020 bug where wires were drawn broken but were actually not broken, meaning the code would run fine. Assuming you're running LabVIEW 2020, I'd try installing the 2020 SP1 service pack to see if that fixes the issue.

[SunnyT]

Hi All,

Thanks for all the responses.  Sorry about the blurry pictures, I didn't realize until after I posted it.  I tried to edit the message after posting but it does not allow me to (now I know, you can only edit after posting within 20mins).  So I just waited to see if anyone has seen it and given me a quick answer instead of diagnosing it. 

Attached is the zipped folder that I have for the 3 items (a C dll, and 2 VIs).  If you open the "Abort" vi, you will see the issue.  I just found out that if after I opened it in labview 2020, save it (re-compile), then it will work the next time. However with 2019, I don't have to do it.  So the worst case is that I will save the .llb in 2020.

The reason I brought this up is that, we have a bunch of old llb libraries, they all work fine and look fine (no broken wires), we then upgraded a bunch of computers to LV 2020 and this issue starts to show up.  I did re-install labview 2020 and it still gives me the same problem.  I intend to try with LV 2020 SP1 but just want to make sure if there's any simple solution to this first before we have to go to 2020 SP1.

Thank you.

Rick.

[EWiebe]

This is really strange ...

It shows the standard run arrow:

Perhaps do it in this way:

I had a similar issue with standard DAQmx driver: The instrument handle input was not accepted in the c code node... although it was standard NI DAQmx code...

BR

EWiebe

[MichaelBalzer]

This is really curious. I'm seeing the same visually broken wire in LV2020, even after disconnecting / rewiring, and forcing a diagram recompile with ctrl+clicking the run arrow.

I thought I'd try wiring the reference to a U32 conversion, and then wiring the U32 to the CFLN to avoid the coercion dot, but that reference type can't be converted to U32. So the explicit cast to U32 is unsupported, but the implicit cast to U32 by the CLFN is supported. I'm guessing LabVIEW is getting confused here, and that's why the wire is partly broken.

Dropping an Always Copy node on the wire seems to fix things:

[rolfk]

---

@MichaelBalzer wrote:

This is really curious. I'm seeing the same visually broken wire in LV2020, even after disconnecting / rewiring, and forcing a diagram recompile with ctrl+clicking the run arrow.

I thought I'd try wiring the reference to a U32 conversion, and then wiring the U32 to the CFLN to avoid the coercion dot, but that reference type can't be converted to U32. So the explicit cast to U32 is unsupported, but the implicit cast to U32 by the CLFN is supported. I'm guessing LabVIEW is getting confused here, and that's why the wire is partly broken.

---

That is because what the Call Library Node does when you wire an instrument handle to a integer parameter is not a simple conversion but a rather specific process to extract the underlying session handle. LabVIEW refnums are all a small sugar layer around an object descriptor. Some refnums are itself just anonymous indices (greenish ones) others are named refnums which also have a name attribute. LabVIEW always uses the integer index itself, which it calls a magic cookie, except when a named refnum hasn't yet been used in which case it will let the underlying session manager (VISA for instrument handles, DAQmx for DAQ handles, etc.) create the actual session, wrap it in a magic cookie and then use that along for the rest of the time. So the instrument handle is a 32-bit integer indicating to LabVIEW what magic cookie object is referred too and that magic cookie is then queried by the Call Library Node parameter preparation for the underlying session handle.

Basically this is the function that LabVIEW calls at the red dot for this parameter. Yes it is a conversion function and it could theoretically have been added as special case to the To UInt32 conversion instead but that would certainly pain the purist among the LabVIEW developers. First and foremost, it makes the Numeric Conversion node asymmetrical, with one of them doing an extra operation that the others don't know about. It also complicates the numeric conversion coding in the LabVIEW source code.

If you used Adapt To Type for that parameter, LabVIEW would actually pass the MagicCookie (LVRefNum) refnum itself to the DLL, but since the according APIs to do anything with them aren't documented at all, this is just an academic exercise without any practical use.

[SunnyT]

Thank you all for the responses.  Again, the VI that I posted here was just one of the VIs from an LLB, and we have many of these LLBs from vendors.  The goal is not to modify any of these llb if it's possible because LV2019 works and looks fine. However, I should be now all set, I went back to one of the vendors' website and downloaded a new version of the LLB that has the VI that I posted here and it's fixed in this new version.

I am all set now. 

Thanks,