how to pass Sequence Context to .Net Ref control in LabView

[LabCat]

Greetings:

I'm trying to call a VI from TestStand which contains a .Net constructor node for an object that takes the sequenceContext in it's constructor.  The problem I have is I don't know how to pass the reference to the sequence context to LabView.

If I use the TestStand Sequence Context (legacy) control, this is an activex  reference ... not a dot net object.

If I place the .Net Sequence Context control on the front panel, TestStand won't let me pass "ThisContext" to it. [Expected Object Reference, found Container. [Error Code: -17313]]

Your advice would be appreciated!

Thanks,

Tom MacLean

[LabCat]

Still haven't found the answer, though I think I'm getting closer...

I have tried passing from TS to LV ThisContext.AsPropertyObject into a .Net PropertyObject reference control, and cast it to the more specific class SequenceContext .... except when I probe it at run time, I'm getting a null reference passed in (LV is not receiving a valid reference).

Sigh.

[LabCat]

I'm starting to suspect I'm up against the .Net AppDomain issue ... LV's domain is different from TestStand's and thus a reference from one is not recognized in the other.

I now wonder if there is a way to use the Activex reference to the SequenceContext in a CSharp environment.

-tom

[Snowman 6008]

LabCat,

I'm currious as to why you're passing a SequenceContext to a LabVIEW VI and then to a .NET assembly? What is this all trying to achieve, and is there anyway to break it into two steps? There may not be a way to convert the LabVIEW object to an appropriate .NET object. Is there anyway you can get around having to call this assembly in your LabVIEW code module? We generally recommend making your steps as modular as possible, meaning they can be re-used in different sequences as well as outside of TestStand. Are you using this sequence context to modify something using the TestStand API? If so, I try to keep all TestStand manipulation out of code modules if at all possible to make my VI's as modular as possible, and keeping the majority of my TestStand manipulation inside of TestStand. 

[LabCat]

The reason is that I'm creating a support library to be used by two groups, one using .Net, the other using LabView.  I'm hoping to write a single DLL that can be used in both environments, rather than create a DLL for the .Net user group and a LV implementation for the other group (and possibly have different behaviour (and/or bugs) in each implementation).

Cheers,

Tom m.

[Snowman 6008]

LabCat,

After looking into this, it is not possible to send the SequenceContext as a .NET Object parameter to LabVIEW. This is because TestStand and LabVIEW use different AppDomains and .NET Objects cannot be shared across separate AppDomains. To get around this you can either split up your code so that you are calling the .NET assembly directly from TestStand or it may be possible to use .NET Remoting to access the .NET Object from different AppDomains. For more information check out .NET Remoting.

I would suggest going with the first option. So instead of one LabVIEW VI with a .NET dll in it, create one LabVIEW VI that passes information back to TestStand, then the next step you can call your DLL directly from TestStand and pass in the data you got from LabVIEW, and finally you can call another LabVIEW VI after the DLL to process any values coming from the assembly.

[LabCat]

Thanks Richards.  Unfortunately, that doesn't really address the need.  The support library I'm writing needs to get information while the VI is running.  I'm pretty sure I can write it in pure LV, but the fact I have to maintain the library in two languages is not desireable.

I'm no expert in C# or ActiveX ... but  in my mind, it ought to be possible to operate on the Activex automation reference in CSharp.

I wasn't too keen on the .Net remoting because of some security issues.  .Net WCF might have done the trick, but the complexity was starting to get out of hand.

Cheers,

Tom M.

[Manooch_H]

Hi Tom,

Unfortunately LabVIEW's built in To .NET Object.vi does not accept ActiveX references and cannot be used for this use case.

I've attached an example using TestStand 4.1 and LabVIEW 8.5 to convert the ActiveX Sequence Context reference to a .NET reference. Please note that this conversion is not trivial. The AXtoNET Reference.vi calls the ConvertPtrtoInt.dll using a Call Library Function node and a relative path, so it is crucial that the AXtoNET Reference.vi and the ConvertPtrtoInt.dll are in the same directory.

Please take a look at the Test ActiveX to NET Reference.vi for an example of using the AXtoNET Reference.vi within a LabVIEW code module called from TestStand. You can even run the Test Reference Passing.seq file to see the entire example in action. All of the source files for this example are included.

Please respond to this thread if you have any further questions regarding this use case or the attached example.

[LabCat]

Thanks.  I will check this out.

Regards,

Tom M.