Execution system differs between VI properties and Execution Trace Toolkit

[Gael_Robin]

I have a time critical acquisition VI whose execution system is set to "E/S d'instruments" (instrument IO). When I dump the execution trace in the execution trace toolkit it appears as "LabVIEW Thread [Standard]". Moreover there is a second line with the same thread name. Is this just a confusing bug or does it reflect a possible conflict in my program ?

Thanks in advance.
Gael.

Additionnal information : I am working on FP-2015.

[Bob_Preis]

I tried several different scenarios and here's what I found.

1) If the top-level VI is assigned the execution system "same as caller", and it calls a subVI assigned to "Instr I/O", then the VIs will run in standard and instr I/O, respectively. This is correct behavior.

2) If the top-level VI is assigned to instr I/O and calls a subVI also set to instr I/O, both run in standard execution system. This appears to be a bug.

3) If the top-level VI is assigned to DAQ execution system and calls a subVI assigned to instr I/O execution system, the top-level VI runs in standard, and the subVI runs in instr I/O. The is incorrect behavior because the top-level VI should run in DAQ. This is probably related to #2.

I have attached the 3 sc
reenshots below showing the behavior.

Since the behavior appears to be related to the top-level VI's execution system in my test cases, I was curious if you're experiencing the same thing. In other words, is your time-critical VI, which is set to run in instr I/O, the top-level VI or called by a top-level VI set to run in instr I/O?

[Gael_Robin]

In my case the top-level VI is assigned the execution system "Same as caller" : it calls a couple of subVIs :
- the time critical VI (assigned to "instr I/O") which only calls Real Time VIs (RT-FIFO, RT-Leds, FP-Read, Wait until next ms),
- a storage management VI assigned to "other 1" execution system running at above normal priority ("priorité normale supérieure")

The storage management VI appears in the correct thread when examining the trace output, but the time critical one exhibits the described behaviour.

[Bob_Preis]

Gael,

I made my top-level VI run at normal priority in the "same as caller" execution system, and my subVI run at time critical priority in the "instr I/O" execution system. The trace (attached) showed correct behavior.

There are a few things to try. First make a backup of your application. Try removing the storage management subVI assigned to "other 1". You should now have a top-level VI running at normal priority in the same as caller exec system and a subVI running at time-critical in the instr I/O exec system (same as my setup).

If you still get the weird behavior, we might be able to isolate the behavior to a subVI you're calling inside the time-critical VI. Try removing one subVI at a time and collect a tra
ce each time.

Alternatively, you can start with my simply VIs and slowly add components from your application until you see the weird behavior.

I should remark that when you assign a VI to run at time-critical priority, that VI gets its own thread, even if the VI is set to run in the "same as caller" execution system. So even if your time-critical VI is not adhering to its assigned execution system, it's still running in its own time-critical priority thread (shown as red in the trace tool).