access c# variable from labview and teststand

[Risotto]

Hi,

I have a variable "arr" (array of double) which is declare as static in an object of a C#-dll.

I whant to write in this variable from Labview and  then read the result in Teststand (not at the same time, but during the execution of a sequence). I know there is other possibility to communicate between LabVIEW and Teststand, but I really need to have it work like I described.

Now my problem:

1. If I create an instance of the object -  where "arr" is declared - in Labview and return the reference to teststand, I get an error in Teststand (empty object)

2. If I create an instance of this object in Teststand and sent the reference to Labview, then Labview can't use this reference to call methods of the object.

I tried to use only static functions, so  that I don't need to create an instance of the object. But when I fill my variable in Labview with data, I get only an empty array in Teststand.

Please help!!!!

Risotto

[Lycangeek]

I'm afraid that you can't share .NET references between TestStand and LabVIEW. The reason is that each application creates its own AppDomain (the .NET "process within a process") and thus they live in different worlds.

[Risotto]

Yes,
This is what I was afraid of....

But do you know if there is a possibility to access a .NET object created in Teststand upon the SequenceContext in C# (or C++)? So I could create a reference to a .NET object in Teststand, pass the sequence context and the lookup string of the variable containing the reference to LabVIEW which call my C#-Funktion. "Arrived" in my C#-fuction, may be it is possible to retreive upon the reference the instance of the .NET object I need?

Regards,
Risotto

[Lycangeek]

Well, we are into the realm of what should be possible - not something that I have tried (at least with LV and TestStand)

.NET Remoting is not just for communicating between processes, but also between AppDomains. You could create a remoting object from within your C# code in TestStand and then access it from LabVIEW (using System.Activator.CreateInstance()). That would be the only way for a call from LabVIEW to go into the right instance of the object.

As far as design, your remoting object does not need to be the same one as the one in the sequence context - the remoting object could be a singleton for all of TestStand, and each sequence registers itself with it. That might reduce the complexity of the design. Of course, you'll need to ensure that you unregister when the sequence context is done otherwise you'll have a memory leak.

The other thing to keep in mind is that any class that is sent back and forth (data) must be serializable - including any exceptions you may want to throw.

If you've never done it, it seems like a lot of work, but it's actually pretty easy to get the basics working. I'd recommend doing a simple hello world .NET remoting example between two processes - there are tons of examples out on the internet. Mapping it to this case should be straightforward.

[Risotto]

Well!

I am not a experimented programmer, but I tried to use .NET Remote as you tell.

I  wrote an "Hello World"-example, which works.

I have now a class (SampleObject) which I load with RemoteConfiguration.RegisterWellKnownService in a dummy server (SampleServer).

Then I wrote a remote client (SampleClient) which access my remote object upon the server. But I was not successfull to use Activor.CreateInstance in the remote client I wrote (I only get a new instance of my class and not the remote object). If I use Activator.GetObject, I access upon the server to the remote object. But it is slow...

How would you use CreateInstance to access to the remote object and don't get a new instance?

Code for the server:
// Create an instance of a channel
TcpChannel channel = new TcpChannel(8080);
ChannelServices.RegisterChannel(channel);

// Register as an available service with the name HelloWorld
RemotingConfiguration.RegisterWellKnownServiceType(typeof(SampleObject), "Connection", WellKnownObjectMode.Singleton);

System.Console.WriteLine("Press the enter key to exit...");
System.Console.ReadLine();

Code for the client:
// Create a channel for communicating w/ the remote object
// Notice no port is specified on the client
TcpChannel chan = new TcpChannel();
ChannelServices.RegisterChannel(chan);

// Create an instance of the remote object
SampleObject obj = (SampleObject) Activator.GetObject(typeof(CodeGuru.Remoting.SampleObject),"tcp://localhost:8080/Connection" );

// Use the objectif( obj.Equals(null) ) {
System.Console.WriteLine("Error: unable to locate server");
} else {
Console.WriteLine(obj.HelloWorld());
Console.WriteLine(d);
}
Console.In.ReadLine()

[Lycangeek]

My bad - comes from talking off the cuff. You do use GetObject - so that's fine.

Yes, it's much slower than calling the object directly, but you'll find it's faster in the LV+TS case because you're just crossing AppDomains, not processes. Still slower, but hopefully you won't find it a problem. Either way, do also make sure to set the Lease timeout for your remote object. Default is after 5 minutes of inactivity the license is destroyed (see InitializeLifetimeService and ILease). Search the web also, lots of examples on how to deal with this.

[Risotto]

Hi Brian,

I have now found a solution to my problem:

I wrote in .NET Remote a server which create an instance of the remote object containing my data. Then, this object is register with  RemotingServices.Marshal. It allow me to have an instance of the remote object . Then I create a server object in LabVIEW and may save may data directly in the instance. With Teststand, I can then with a client access with .NET Remoting to the remote object. It is may be tricky, but it works.

I put an example here so may be it can help somebody else....

Thank you for your help!

Risotto.

[Lycangeek]

Excellent. Thanks for posting the example for others.

Speaking of posting, if you ever have a moment, could you post it up on http://community.ni.com/. That is a new site for user examples that we've created - gives you full control and you retain the rights to the code.