NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Trouble re-using steps of a sequence (making .NET calls)

I am having trouble getting a sequence to work when I re-use the steps inside a sequence multiple times. I am a pretty experienced user of TestStand, but this is really bizarre and I cannot figure out what the problem is.

 

I will try and explain the problem using an example sequence file, but you will not be able to run it because the steps in the file call a .NET assembly which is proprietary software at Cummins.

 

In the sequence My_Connect, it can be seen that an object of a .NET class is being created and then the reference to the created object is being used to call a certain method of the class (Connect). If I execute the My_Connect sequence, since I am calling the Connect method TWO times, I see the expected behavior on our application.

 

However, if I make the RunMode of the last two steps (basically the second connect steps) as “Skip”, and then call My_Connect from the sequence Call My_Connect two times, the behavior of the My_Connect sequence is different in this case. Should it not be the same as before? All I have done differently is that I have re-used the same steps of the sequence (the first two) rather then executing multiple copies of the steps.

 

The only thing that explains the reason why in the second case I do not get the desired behavior is: For some reason, in the second call to the sequence My_Connect, a new object is not being created and the call to the Connect is operation on the first object that was crated during the first call. I have no idea why this would happen, but it sure seems like this is what is happening. Everytime I run this in debug mode to make sure that the .NET methods are not throwing an exception.

 

At one point, I was thinking that its possible that there might be a bug in the Connect method of our application which is causing this. However, I replicated this same stuff in a VB script and it worked from there.

 

Any help will be greatly appreciated..

0 Kudos
Message 1 of 12
(4,253 Views)
I forgot to attach the file with the last post, here it is..
 
Anuj
0 Kudos
Message 2 of 12
(4,247 Views)
Not sure if this is the cause of your problem or not, but one thing odd I noticed about the sequence is that you are using the following as your object reference expression:

Evaluate("Locals.CUTY_Ref")

Really you should just be using your ref obj variable directly (as shown below) instead:

Locals.CUTY_Ref

-Doug
0 Kudos
Message 3 of 12
(4,224 Views)
Doug,
 
Thanks for pointing this out. I tried without the Evaluate and it does not change anything as expected. The reason why I had an 'Evaluate' in there is because in my actual code, I was dynamically generating the name of the local variable to be used as the object reference.
0 Kudos
Message 4 of 12
(4,216 Views)
What exactly is the difference in behavior you are seeing?

You should be able to verify inside of your method whether or not a .NET object is the same object by using the visual studio debugger. If you attach for debugging to the teststand process from visual studio, you can set a breakpoint in your code module, create a watch expression for the "this" variable, and right-click to create a unqiue id for it in the visual studio watch window once you hit the breakpoint. Doing this you should be able to see if you get the same id for all of your calls or not. Please let us know what you are seeing.

Also, have you tried inserting an expression step before your create that assigns the Nothing keyword to the local variable to ensure it doesn't contain a reference?

Locals.CUTY_Ref = Nothing.

-Doug
0 Kudos
Message 5 of 12
(4,213 Views)
Just want to add that there is a potential behavioral difference given your sequences in the two cases:

1) In the both creates in the sequence case: The second object is created before the first object's reference is released
2) In the create by two sequence calls case: The second object is created AFTER the first object's reference is released

Whether or not this matters is heavily dependent on what your class does and how exactly the .net adapter is managing these references. Once you narrow down what the difference in behavior is, it should be easier to tell if this is the reason or not.

-Doug
0 Kudos
Message 6 of 12
(4,210 Views)

Doug,

The difference in behavior I am referring to is the behavior of the application I am interfacing to. Everytime a Connect method is called with a new object reference, I am supposed to see a new "Client" pop up in the application monitor. This is the desirable behavior, so at the end of two calls (with unique objects), I see two clients in the application monitor. When I call the sequence multiple times from Call My_Connect, during the first call, a Client is connection is opened, however, during the second Connect call, a new Client is NOT opened, so I end up with only one client.

In my initial work, I was actually using different variables (and that too StationGlobals) for storing the references of individual calls. And I was ensuring that each call was using the right variable it was supposed to use. To simplify things, I had gone to the use of a local variable. However, the difference that you've pointed out does make sense and could be the problem. But the fact that it did not work when I was using completely differnet StationGlobal variables for each connection tells me that this is not the root cause of the problem.

I've not been releasing any references after opening them up. The reason is, once the reference is created, I want it to remain open for further use of other methods.The refernece is released when someone calls the "Disconnect" method. Because, I want the reference to remain open and live for further use, that is why I was using a StationGlobal variable for it (because StationGlobal values hold after the sequence execution)

I think my last resort at this point, as you suggested, is to debug into our application code and find out if TestStand is sending unique references for the successive calls as it is supposed to or not. Unfortunately, I don't own that application and only interface to it. I also don't have visual studio .NET installed on that machine where I do this testing. So, it may take me some time to get to that point (getting together with the application owners and finding another test machine). Before I go to this extent, I might explore some alternative approaches.

I will keep you updated on my progress.

0 Kudos
Message 7 of 12
(4,202 Views)
In looking at your module specification more carefully I think I see what the problem is. You have the creation setting "Use Step Load/Unload Options to Specify Object Creation Time and Lifetime" checked. To get the behavior you want you need to uncheck this setting on your steps that create your objects and instead hold your references to them in separate variables (globals if needed) as long as you want to keep the objects around.

Hope this helps.
-Doug


Message Edited by dug9000 on 12-10-2007 03:08 PM
0 Kudos
Message 8 of 12
(4,199 Views)

Hmm...I never paid attention to this option..

Sounds like you are fairly confident that this is what my problem is. I will get to try this later tonight and will let you what I find out...(can't wait..:)

 

0 Kudos
Message 9 of 12
(4,193 Views)
Hey Anuj,
   I looked through your example sequence file, and I noticed that the first three steps in the My_Connect sequence use Remote Scripting version 1.0.2231.6621, but the last call uses Remote Scripting version 1.0.2813.17152.  Could this be your issue?  The second object is created with one version and the "connect" method is called with another version.  I hope this helps.
Best Regards,
Software Engineer
Jett R
0 Kudos
Message 10 of 12
(4,191 Views)