I'd like to clear a few things up about how this works. First, running a VI with default step settings and running a VI with the step set to "Always run VI in LabVIEW Run-Time Engine" does exactly the same thing behind the scenes--both VIs execute in the same instance of the LabVIEW Run-TIme Engine. For this reason, the issue with loading "Always run VI in LV RTE" steps into the subpanel is not being caused by a separate instance of the RTE.
After looking at this for a while, we discovered that the issue is actually occurring because of this part of the UI subpanel loading code:
The VICallOptions value is used in a case selector, and the way the code is written, the VI is only loaded into the subpanel if this value is 1, which indicates that the step is configured so that the front panel is displayed when the step executes. However, this property is actually a bit mask of two properties; value 1 (01 in binary) is "show front panel" and value 2 (10 in binary) is "module is set to auto-detect version of LabVIEW RTE to use". If both of these properties are true, as is the case for a step with the front panel set to display and the "Always run VI in LabVIEW Run-Time Engine" option checked, the return value of this property will be 3 (11 in binary).
Therefore, the fix for this issue is to change the Case selector in the code so that it executes for values 1 and 3, as follows:
(This change is in the UIMessage callback in the UI subpanel example)
We'll make a note to update this online example with that change. I hope this clears things up, and let us know if you have any further questions about it.
Thanks for clearing that up.
I currently have the VICallOptions ANDed with 1 to mask the "show front panel" property, then the case statement looks for the 1. That ignores the "module is set to auto-detect version of LabVIEW RTE to use" flag, but are there any other flags that should be avoided by using your method?
I believe the VICallOptions only has the two flags we've talked about, as documented on this page. Your approach sounds like a good way to solve the problem, I'll keep that in mind when we update the example.
I'm posting this in here because the source of the problem is the SubPanel feature, but I think this might be a bug in TestStand overall, and please pardon the long post, I'm trying to explain how to get to the behavior I found.
So I'm trying to get VIs that run in the SequenceFileLoad callback to populate into the Subpanel, and I know that the UIMessageEvent that the labview callback is looking for is UI_Trace, which gets triggered when a new step is selected in the trace (or something like that). With that info, I went looking for how to turn on tracing for a single sequence (SequenceFileLoad).
I found the Run Option "Sequence Call Trace Setting" in the SequenceCall Step. This allows me to force tracing on for a single sequence. However, I found that this setting isn't that cut and dry. Here is what I wrote to test this:
Dummy Test.vi is just a for loop that counts up for a few seconds to show activity in the Subpanel, and all the VI call steps have Show VI Front Panel set to on.
Here is what I expected to happen:
First VI Call: VI Front panel popped out.
First SequenceCall: Both VI Front Panels in SubPanel
Second SequenceCall: Both VI Front Panels popped out
Second VI Call: VI Front Panel popped out.
Here is what actually happened:
First VI Call: VI Front panel popped out (as expected)
First SequenceCall: Both VI Front Panels in SubPanel (As expected)
Second SequenceCall: Both VI Front Panels in SubPanel (NOT As expected)
Second VI Call: VI Front Panel in Subpanel (Definitely NOT Expected)
I think what's happening here is that the Trace isn't being turned off properly when exiting the SequenceCall step.
On a side note, is there any way to turn on Tracing for a single sequence without making it a SequenceCall? I can take all the steps being called by SequenceFileLoad and put it in a subsequence to be called by SequenceFileLoad, but that seems like an unnecessary step.
Also, as a useful piece of info to duplicate the problem: Enable Tracing is turned on in Station Options, but none of it's sub-options are turned on.
You might be able to get the behavior you're looking for by using the following expression at the beginning of the SequenceFileLoad callback:
RunState.Execution.TracingDisabled = False
I am not aware of any issues with tracing not being turned off after a sequence call which enables it, but we can look into that to see if there are any issues there.
Unfortunately, setting RunState.Execution.TracingDisabled=False doesn't change the behavior. However, setting TracingDisabled=True does make them all pop-out, which means the setting does work.
As a side note: The property RunState.Tracing goes between True and False as one would expect:
First VI Call: True
First SequenceCall: True
Second SequenceCall: False
Second VI Call: True
Is it possible that the Trace is being altered, but the message isn't being sent?