LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Correct path to VI file that's inside a PPL

There are other similar "addon" VIs and this same sort of behavior applies to them as well.  It's not peculiar to this one.

 

The weird thing is, my system has a "signature" attached to each PPL file, so that the RT knows whether to use a local cached copy (if the signature matches the host), or request a download from the host (if it doesn't).

The ERROR 7 is (mis-) interpreted as a signature mismatch, so a new copy is downloaded and stashed.  That copy SOMETIMES works.  If it starts working, it'll stay working, until the next rebuild.

 

I believe that I am misinterpreting the error message.  Error 7 does NOT mean that the VI within the PPL is not found, but that something that the VI needs is not found.  It's unable to tell me what.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


LinkedIn

Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 11 of 16
(951 Views)

I reviewed a list of LV error codes and "53" as skipped. But it was in the middle of errors for "interoperability manager" messages.

 

IN this list of know issues there is a mention of a "error 53" from a merge with an XControl control with a SR#676013

 

You may want to contact NI about the SR number.

 

RT Execution Trace Toolkit may let you narrow down where the problems is located since you can repeat the error.

 

The Interperability manager seems to be related to things like add-ons talking to each other.

 

Not that I know what is going on...

 

Ben 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 12 of 16
(949 Views)

I reworked things so that the relative paths between PPLs on the host is identical to the relative paths on the RT (that was never a problem before).

Now the ERROR 53 is gone.  But I still have ERROR 7 / ERROR 0 alternating, regardless of whether the main RT program is open or not:

 

If I open/close the reference 10 times:

 

Err 7.PNG 

 

If that opens it NINE times, I'll get 0-7-0-7-0-7-0-7-0, then the NEXT run will start with the error first, 7-0-7-0....  That means there's something in the system that remembers that it's supposed to fail, or not.

 

Weird.

 

I suppose I could just keep trying to open it until it succeeds, but that's an ugly hack, if ever I saw one.

 

If I set the FLAGS to 0, no change.

 

If I disconnect the Type reference (flags = 0), no change.

 

NEW INFO:

 

If I change the Type Reference to point to some random other VI, I get ALTERNATING ERROR 1031 and ERROR 0.

1031 = connector type mismatch.

 

I'm not surprised by the mismatch error, but why does it SUCCEED every other time ?

 

 

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


LinkedIn

Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 13 of 16
(936 Views)

NEW INFO:

 

If I set the PATH to a VI (which doesn't match the TYPE ref)  that is outside of a PPL, then I get a CONSTANT error 1031 (connector pane mismatch).  That is reasonable.

 

If I change the TYPE ref to match that VI, then I get a CONSTANT error 0.  That is also reasonable.

 

So, then, why does being in a PPL matter (half the time) ?

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


LinkedIn

Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 14 of 16
(933 Views)

NEW INFO:

 

Making a new VI, putting it into a LVLIB, making a PPL from it, moving the PPL to RT, adjusting the path and TYPE ref to match, produces NO error.  No alternating, no error, no problem.

 

So... It's not the fact that it RESIDES in a PPL that is the issue, it has to be something that the VI loads.  And it can't tell me what.  And it's only there half the time.....

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


LinkedIn

Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 15 of 16
(925 Views)

So, I changed the code in my real RT app to try opening the reference once, and if an error occurred, try opening it again.

That seems to work.

Here is a debugging trail:

 

The first line (40.722) is turning the VI name and the PPL path into a path to the VI

The 2nd line (41.027) is where I try to open the reference.  Fail.

The 3rd line (41.133) is where I try AGAIN, and this time it succeeds.

 

Weird.

 

07:30:40.722 - ADDON: Looking for "RTAC Addon for Barometer.vi" in PPL "C:\MoSAIC\Addons\A55CF672 RTAC Addon for Barometer.lvlibp" and found it at "C:\MoSAIC\Addons\A55CF672 RTAC Addon for Barometer.lvlibp\MoSAIC Addons\MoSAIC Addon for Barometer\RTAC Addon for Barometer.vi" Error: 0
07:30:41.027 - ADDON: Trying to open "C:\MoSAIC\Addons\A55CF672 RTAC Addon for Barometer.lvlibp\MoSAIC Addons\MoSAIC Addon for Barometer\RTAC Addon for Barometer.vi" in PPL Error: 7
07:30:41.133 - ADDON: Trying to open "C:\MoSAIC\Addons\A55CF672 RTAC Addon for Barometer.lvlibp\MoSAIC Addons\MoSAIC Addon for Barometer\RTAC Addon for Barometer.vi" in PPL Error: 0
07:30:41.136 - Checked out OK. Trying to read prefs file at "C:\MoSAIC\Addons\RTAC Addon for Barometer Unit 1.addonSettings"
07:30:41.142 - ADDON: Started VI "RTAC Addon for Barometer" Unit 1 - Error code: 0
07:30:53.716 - RTAC Attach Addon

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


LinkedIn

Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 16 of 16
(907 Views)