Sequence Context Ref going bad

[EdDickens]

This may be a LabVIEW problem but since the issue is the Sequence Context ref going bad, I'm starating here.

I have a Step Type that calls a VI that in turn launches a VI dynamically. This VI is shown below. In this VI, the Sequence Context Ref is good as indicated by the Not a RefNum function.

The very start of the VI that the above calls is shown below. Here, the Sequence Context is bad as indicated by the Not a Ref function.

Right now the Sequence Context is not being accessed in the SubVI that it passes through, so the "StationGlobals" Property node generates the following error. 

"Error 1 occurred at Incorrect function in EDAT..."

This had been working for a while until I added the SubVI in the top VI that is receiving the "Status Text". As you see this VI does not use the Sequence Context.

Any ideas?

[EdDickens]

I forgot to mention that it does this on my development machine as well as 3 different customer machines.

This is LabVIEW and TestStand 2014 SP1 (32bit) on Windows 7 Pro (64bit)

[EdDickens]

I've distilled this down to the simplest form I can and still get the error. Below is the Caller and Callie. 

If I use a "Run VI Asynchronously" step type to call just the bottom code, it seems to work. Interestingly is that I originally went to using the "Start Asynchronous Call" function because the "Run VI Asynchronously" step was generating this exact issue and that was my workaround. 

The attachment contains the VI's and a sequence to run this in both modes. Are others seeing the same thing? Should I not be passing the Sequence Context through the "Start Asynchronous Call" function?

[EdDickens]

Here's another twist.

I opened the above VI's on the customers machine and see a Coercion dot on the Sequence Context terminal. All the Sequence Context controls are linked to the "LabVIEW Test - Sequence Context.ctl" Strict Type Def located in the 'vi.lib/addons/TestStand' directory.

And yes, I get the same error when it runs.

[Sil.VI]

Hi Ed,

I have downloaded and ran your sequence on my computer and as you mentioned I also get the coercion don at the input of the Start Asynchronous Call Node. However I also get the same Error 1 on the same direction that you said.

So currently after you added the Run VI Asynchronously step it is working fine for you but not ok on your client computer is this correct?

Also, I noticed that if you create the Test Dynamic VI on the computer where the sequence will run it deletes the coercion dot so my guess is that it could be related to the info it gets when you call the sequence context control

Below you can find some links with information that I hope you can find helpful 

http://zone.ni.com/reference/en-XX/help/370052H-01/tssuppref/infotopics/seq_con/ - Sequence Context

http://zone.ni.com/reference/en-XX/help/370052M-01/tsfundamentals/infotopics/seq_con/ 

http://zone.ni.com/reference/en-XX/help/370052M-01/tsfundamentals/infotopics/seq_con_ts_subproperty/ - Station Globals

[EdDickens]

I ended up opening up a Service Request and here's the explaination of what they think is happening and a work-around.

"I discussed the issue with R&D and have a possible solution:

When a sequence context is passed from TestStand to a VI, then from that VI to a subVI, the sequence context loses its data type because the calling VI is taken out of memory before the datatype passed to it from TestStand is passed to the Callie subVI. The fix is to cast the incoming sequence context in the first VI to a variant data type via the "To Variant" finction. Passing the sequence context through this function will provide the subVI the type information it needs to keep the sequence context valid.

Use the "Variant to Data" function to cast the Variant back to a Sequence Context reference. This will need a datatype, which can be acquired by dropping the "Automation Open" function, right-clicking the top-left terminal, and selecting "Select ActiveX Class" >> T S.SequenceContext. This will drop a T S.sequenceContext
refnum of sorts which can be wired to the type terminal of the Variant to Data function."

So far it seems to be working.