From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Correct path to VI file that's inside a PPL

LV 2018 SP1, LV RT 2018

 

I've had trouble with this since moving from LV 2013 to LV 2018.

 

I need to get a reference to a (reentrant) VI that resides in a Packed Project Library (PPL) file (.lvlibp).

 

I need to run one or more instances of that VI, using the CALL BY REFERENCE (call and collect) method (dynamic loading).

 

In the real world, when I rebuild the PPL itself, the RT program would fail to find it.  Tinkering around would eventually lead to it being found, but I never found a definite fix.

 

Boiling that down leads to the behavior in the attached <JING>.  Here I have a constant path to a VI within the PPL, and I'm trying to open / close a ref to it.

It reliably throws an error 7 on EVERY OTHER run.  Not every run, mind you, but every second run.

 

There's nothing stored in this test VI that could cause that.

 

Any ideas why ?

 

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


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 1 of 16
(2,905 Views)

more info:

 

1... I need flags to be 0x140 for my situation, but changing them to 0x100,0x40, or 0x00 makes no difference for this test.  It still fails every OTHER time.

 

2... If I add a character to the path, to make it deliberately wrong, the error 7 occurs every time (as you might expect).

 

3... If flags = 0x140, and I disconnect the TypeDef to the VIT file, I get error 1592 every time (must have strict typedef for asynchronous call).  That's expected.

     If flags = 0, I can disconnect the TypeDef to the VIT file, and then it's back to error 7 every OTHER time.

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


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 2 of 16
(2,897 Views)

more info:

 

When quitting LabVIEW (to relaunch it), I got a notice that there were VIs still deployed on the target (which was unexpected).  Perhaps that has some bearing.

 

I killed those and tried again.  Now I get ERROR 53 ("Manager Call not supported"), whatever the heck that means.

 

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


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 3 of 16
(2,885 Views)

Ok I have one more guess.

Is it maybe cause by the *.llb inside your *.lvlibp?

0 Kudos
Message 4 of 16
(2,853 Views)

@aptivo wrote:

Ok I have one more guess.

Is it maybe cause by the *.llb inside your *.lvlibp?


No.  I don't use LLBs much anymore, so I took this opportunity to rework this PPL and eliminate the LLB.  

No change.  Still error 53.

 

Most mentions of error 53 talk about things unavailable on RT.  But what I'm doing is OPEN VI REFERENCE, which is allowed.

 

 

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


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 5 of 16
(2,847 Views)

If I take that little test VI (Open ref, close ref), point it to a copy of the PPL on the HOST PC, and run it on the HOST, I get ERROR 1059 (Unexpected File Type).

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


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 6 of 16
(2,843 Views)

Ok have you selected "Seperate compiled code from new project items" and applied it to all VIs. If not give it a try.

If nothing changes, try a mass-compile of all project items and have a look on the error messages. After mass-compiling rebuild the lvlibp and give it another try.

 

These are my last both ideas how to solve the problem.

0 Kudos
Message 7 of 16
(2,837 Views)

TOO WEIRD!

 

For what it is worth I will report that I ran into issues stating up an RT app after power fail on  PXI-8880.

 

I "ran it up the flag pole" and the ivory tower punted telling me it was the OS and not the NI environment.

 

I had to add a delay at the start of the application in order to be able to talk to more than one class of hardware (PXIe widget to talk to TEDS strain gages and USB-Widget).

 

The take away message is that RT is not completely initializing before the code starts.

 

If that does not help you out with your situation, it may help others.

 

Ben 

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

I added 5000 mSec wait before trying to open the reference - no change.

 

NEW INFO:  

 

If I run my main RT program, then stop it, and run this test (they're in the same project), I get

ERROR 7 on EVERY OTHER run, and no error on the others.  It alternates.  Reliably.

 

The main RT program does NOT try to load this particular PPL unless it is commanded to do so, and that's not happening now (no Windows Host program running).

 

If I CLOSE the main program (just close the main window, after stopping it), and then run this test, I get ONE run with no error, and then ERROR 53 every subsequent run.

 

SUMMARY:

 

1... I get ERROR 53 every run of the TEST program.

2... I run my main RT program (without Windows Host).

3... I stop my main RT program, but leave the main window open.

4... I run the test program above.  It complains about the SCAN ENGINE settings.  I seem to forget that.

5... I set the SCAN ENGINE to CONFIG mode using the UTILITIES: SYSTEM MANAGER

6... I run the test program above.

7... I get ERROR 7

8... I run the test program above.

9... I get NO ERROR

10... I run the test program above.

11... I get ERROR 7

12... I run the test program above.

13... I get NO ERROR     etc....

14... I close the main program's window (front panel)

15... I run the test program above.

16... I get ERROR 53

17... I run the test program above.

18... I get ERROR 53    etc.

19... GO TO 1

 

This is repeatable.

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


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 9 of 16
(2,824 Views)

@aptivo wrote:

Ok have you selected "Seperate compiled code from new project items" and applied it to all VIs. If not give it a try.


What a mess.  Doing that fails, because it tries to change the settings on about 400 other VIs which are in other PPLs, which can't be changed.  

 

Anyway, after changing the ones I could, there is no behavior difference.

 

 

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


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 10 of 16
(2,816 Views)