NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Unexpected behavior LV First call function in called VI.

Solved!
Go to solution

Please specify the following:

 

1) Version of TestStand you are using

2) Version of Labview you are using

3) Whether you are running VI's in the labview development environment or with the labview runtime engine.

 

Unless all 3 of the above are known it might be very hard to reproduce this problem.

 

Thanks,

-Doug

0 Kudos
Message 11 of 15
(2,048 Views)

Doug,

 

LV8.6

TS4.2

Dev env.

0 Kudos
Message 12 of 15
(2,038 Views)

Hi Sacha,

 

First two sequences you send works exactly as I described (unexpected behavior). The next two work as you described (demanded behavior).

 

Doug,

 

The problem appear on RTE and the Development environment as well.

 

My test sequence is attached.

 

However, after playing with this problem I've found out strange behavior:

 

I'm working using LV Development environment instead RTE. Let say I open TS, open my sequence file (KL_FC.seq) and I run the sequence first time. The sequence called like that returns expected behavior (PFFF). When I call the sequence second time (doesn't matter I close the file and open the file again or just run) the sequence returns unexpected behavior  (FFFF). However, when I close LV main window (getting started) and I execute my sequence again since then it WORKS AS EXPECTED! (PFFF).

 

When I close LV and TS the situation described above repeats.

 

Is it a bug?

0 Kudos
Message 13 of 15
(2,035 Views)
Solution
Accepted by topic author MimiKLM

Hi All,

 

Playing further with the problem I wanted to check how it is under RTE. Surprisingly, after changing LV server to utilise RTE my sequence works as expected.

 

And even more surprisingly, when I changed the LV server back to the DevEnvirnoment, the sequence suddenly started working as expected. And after that this behavior remains permanent.

 

I think this was the reason of the strange behavior. I still don't know why. I don't think I did something wrong by not to switch to and switch back from RTE server just after installing TS; I don't think so it is a requirement. It rather looks like a bug.

 

It would be nice if some one from NI could reproduce and confirm this case.

 

In my opinion the case is solved for me now.

0 Kudos
Message 14 of 15
(2,031 Views)

Sacha and MimiKLM -

 

One thing to keep in mind is that you have to not only be aware of the Load/Unload options of the specific step that is being executed, but you also have to be aware of any other steps in the sequence file that are calling the VI which might cause the VI to be loaded when execution begins (even if these steps are never executed).

 

For example, in the case of the sequence file that Sacha provided, it contains multiple sequences that have Pass/Fail steps that call the same VI. The steps in the SequenceDefaultLoad_Unload sequence have the default Load/Unload options (Preload when execution begins and Unload when sequence file is unloaded). Because of this, when you execute the SequenceUnloadAfterStep sequence that contains Pass/Fail steps that are configured to Load dynamically and Unload after step executes, the code modules in the SequenceDefaultLoad_Unload sequence are also loaded into memory and the VI is not unloaded because of the Unload Options for the steps in that sequence.

 

If you take Sacha's example sequence file and change the Load Option for all of the steps in the SequenceDefaultLoad_Unload sequence to Load dynamically, when you run the SequenceUnloadAfterStep sequence, every step will Pass.

 

Note that you will also need to be aware of this behavior if your sequence file contains SequenceCall steps that call sequences in other sequence files that also contain steps that call the same LabVIEW VI.

 

Hope this helps.

Manooch H.
National Instruments
0 Kudos
Message 15 of 15
(1,972 Views)