NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

VI works in LV, but not in TS

Solved!
Go to solution

Hello everyone,
I'm Markus and I'm contacting you with a problem in Teststand,
which I hope you can help me with.

I have a VI for an oscilloscope measurement (Picoscope 2000) in my company for use in Teststand.
The VI runs satisfactorily in LV, even in "Repeat" mode.
The VI is prepared for Teststand and does not run standalone as a loop, but is only executed once.

If I now use the VI in Teststand, a run is executed without any problems.
After another call of the VI within the Teststand sequence, either an error message of the VI itself appears,
or LabView crashes in the background.
However, I cannot understand what the cause of this is.

Furthermore, I have taken over the project and had no previous contact with Labview or Teststand.
If it goes into too much detail, the knowledge I have acquired so far will no longer help me.

Do you have any suggestions on how I could solve this problem?
Enclosed is the VI used

Thanks in advance
Markus

I am using Teststand 2016 SP1 and Labview 2017 SP1, both 32bit version

 

Translated from German

 

0 Kudos
Message 1 of 15
(385 Views)

Your attachment of the VI did not work as a heads up.

0 Kudos
Message 2 of 15
(368 Views)

Oh, I'm sorry .
That probably didn't work via drag and drop.
Here is the VI

 

Regards

0 Kudos
Message 3 of 15
(362 Views)

Hey Markus,

 

could you please add some more information about the LabVIEW error that occurs? Lika screenshot or similar

 

Cheers

Oli

0 Kudos
Message 4 of 15
(334 Views)

Hello Oli,
attached, unfortunately in German 😞
Here is the translation:
Error 1097 at node for calling external libraries in ReleaseBuffer.vi->PicoReleaseMultiBuffers.vi->PicoCreatePicoMultiBuffers.vi->RMG_PicoScope2000_Aquire_Data_TESTSTAND_Namur.vi->RMG_PicoScope2000_Aquire_Data_TESTSTAND_Namur.vi.ProxyCaller

Possible causes:
LabVIEW: An exception error occurred in the external code called by the "Call external libraries" node. This exception may have caused errors in LabVIEW memory. Save all projects to a new location and restart LabVIEW.

 

Regards
Markus

0 Kudos
Message 5 of 15
(330 Views)

Markus -

You stated "If I now use the VI in Teststand, a run is executed without any problems.
After another call of the VI within the TestStand sequence, either an error message of the VI itself appears,
or LabView crashes in the background". Some questions that come to mind are:

  1. How are you calling the VI from the TestStand sequence, are you call the VI directly as a "loose" VI? One option might be to put the VI in a .lvlibp (packed library) and trying to call it that way to see if you get any better results.
  2. Can you clarify that you are running two full executions and the first works, but the seconds errors? If so depending on settings and all, the VI might be getting unloaded and the unload and reload of the VI is causing the issue. When you run in a LabVIEW application, the VI likely never gets unloaded.
Scott Richardson
0 Kudos
Message 6 of 15
(311 Views)

Hello Scott,
thanks for the feedback


  1. I call the VI as a "loose" VI.
    I will try the way you suggested and create the VI as a packed library.
    But first I have to read up on how this works.
    My knowledge of LV/TS is not that advanced.

  2. I have already set "Properties" => "Run Options" => "Unload Option" to "Unload after Step Executes".
    With the original default setting, an error occurred when repeating the entire test stand sequence.
    With this setting, at least the test stand sequence can be repeated several times.
    But not the VI itself.

Regards
Markus

Translated with DeepL.com (free version)

0 Kudos
Message 7 of 15
(290 Views)

Markus, if I correctly read your answer to (2), you potentially confirmed that TestStand unloading and then reloading the VI is helping trigger this issue.

 

Do you know how the VI talks to the hardware, i.e. is there a DLL it calls, or is it calling standard HW interfaces using LabVIEW based code? If a DLL, the DLL might not be handling being unloaded and reloaded in a process, and if so there are ways to force a DLL to not get unloaded within the TestStand process.

Scott Richardson
0 Kudos
Message 8 of 15
(276 Views)

Confirms my suspicion.... after having opened the VI without having the actual driver on my PC: 

there is an uninitialized Feedback Node on the toplevel VI. 

0 Kudos
Message 9 of 15
(270 Views)

@Oli_Wachno wrote:

there is an uninitialized Feedback Node on the toplevel VI. 


Where can I find this feedback node, and how can I tell that it has not been initialised?

 

Regards

Markus

0 Kudos
Message 10 of 15
(264 Views)