NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Passing .NET object reference from TestStand Sequence to a LabView VI, called in the same sequence

Solved!
Go to solution

Usually I reloade the VI, which I have changed and it goes well. In this case, when I have created a .NET objet in a VI and have a reference to this object as an output connector, the reload procedure doesn't work and the Teststand shows me the same error (connectors don't correspond to parameters) again. I haven't mentioned before what version of LabView and Test stand I use: these are 2009 for the Labview and 4.2.1 for Test Stand. this is a base line. I have installed Test stand 2010 at the local computer and test some sequences with it. The behaviour of teststnd 2010 is different fron Test stand 4.2.1. I'll try to load a VI with .NET reference in the Test Stand 2010, we'll see if it works.

0 Kudos
Message 11 of 29
(2,563 Views)

Hi!

I have tried to load the VI, which uses .NET reference as input (or output) in the TestStand 2010 and it went well. Further I tried under TestStand 2010 to create a .NET object reference within a LabView VI and saved it as an output value in a Test Stand Variable. Then I passed it to another VI call under Teststand. It worked also well - at least I have seen a proper result at least once.

Your advice works, though I have still problems with loading a .NET object (Error 7 as a run time error ). But it may be an error of an Assemby. Besides the Test Stand needs every time I start a sequence the reloading of VIs thoght I save a sequence before running. In any case your advice is a method which can be used, thank you!

0 Kudos
Message 12 of 29
(2,554 Views)

Is doesn't need reloading the vi prototype every time you start a sequence, only when you change the vi prototype. When you change VI prototypes you should use the "update vi calls" tool. You should never have to do it again unless you change the prototype of the vi again.

 

Glad you got it working in TestStand 2010. Not sure what the issue is with the older versions. If you'd like for us to look into it, please let us know.

 

-Doug

0 Kudos
Message 13 of 29
(2,551 Views)

I have to correct myself by the statement, that "only test stand 2010 makes it possible to load a VI with .NET references as in-or-output". Obviously it is a particular problem on a particular machine. I have tried to load the sequence with TestStand 4.2.1 on another machine and it worked well. But this was a Window - 7 machine : the sequence was loadede but didn't work due to problems existing by using Windows-7 and .NET. Could you please  explain me or send me a link with an explanation how to avoid problems with .NET under Windows-7? Maybe the answer is "to avoid using .NET", but it were very unpleasant for us to loose the whole work.

0 Kudos
Message 14 of 29
(2,539 Views)

Hi, Doug,

I've just found out why did I have problems on some machines to load in the Teststand 4.2.1 VIs with .NET object references as in- or- outputs: it is simply that the Test Stand on these machines works with LabView RunTime Engine (2009) and not in with a Development Environment which was default by Test stand 2010. This fact corresponds to your explanation, that LabView can keep the own .NET object reference and pass it to LabView applications. That means that either I have to use "Development Environment" or rebuild the assembly, have I understood it correctly? In this case the second way may become inevitable for us, because we use by default RunTime Engine.

Best regards

0 Kudos
Message 15 of 29
(2,537 Views)

Pericles,

 

This is a known issue with labview, where it will work in development environment but when targeting the RTE it asks you to update over and over. It has been passed over to our R&D Department. That being said, we were still able to run our test successfuly, despite the warnings. Can you confirm that your sequence still operates?

 

Regards,

 

Kyle Mozdzyn

Applications Engineering

National Instruments

Regards,

Kyle M.
Applications Engineering
National Instruments
0 Kudos
Message 16 of 29
(2,493 Views)

Kyle,

it works as following in a RunTime Engine Environment:

- I load a VI with (.NET ) references as in-or-output

- Test Stand will upload it again and again without any success

- I start the sequence inspite of that and it works 

 

BUT all input parameters of my VI are DISABLED and GREYED, I can't edit no input parameter at all , not a simple number. It is very uncoveniet, because during the test I will modify input parameters of this VI (not a reference to .NET but some other things,rather primitive)

 

It looks like the test stand "sees" such VI as an external application (*.exe), without a possibility to pass any parameters.

The question with RunTime Environment is very importat for us, because it is a baseline. Otherwise we have to install

LabView on all mashines.

I think that this item should be passed to NI, because it takes place by TestStand 4.2.1 AND even by the newest version TestStand 2010.

Regards and thanks for your answer

0 Kudos
Message 17 of 29
(2,484 Views)

Hello pericles,

 

the only "workaround" that I see would be to configure the input parameters of your VI action step with expressions that incorporate variables for each desired parameter (switch to the LabVIEW Dev. Environment adaptor for this). You could then use an action or expression step inserted before your VI call to set the variables to the test values during development.

 

Best regards,

Sebastian 

Message 18 of 29
(2,447 Views)

I agree with you and maybe will do it like this, though it is an additional work due to the amout of test cases/steps. I have also sent a request directly to NI referring to this general item - different behavior of Test Stand with RTE and development environment and expect their answer.

Thank you for your reply and possibly it is a solution for Today :-)Smiley Happy 

0 Kudos
Message 19 of 29
(2,445 Views)

Hi!

Some months ago I put this (s. above) question in this forum and get a good solution for passing .NET object reference from a LabView VI to LabView VI within a test sequence in the TestStand. The .NET assembly I used is not in a GAC, therefore it was placed in the directory, where LabView.exe is situated.

It worked well for TestStand 2010 under LabView Development Environment (LV 2009 or 2010) under Windows XP.

Now I moved the same sequence on a computer with Windows7. To port a sequence I used Test Stand Deployment Tool, which collected all necessary subsequences ans VIs used in a test sequence. The sequence doesn't work. I had to reload manually all VIs, which contain any reference to .NET, they appeared correctly in SeqEdit and looked as "executable". The sequence doesn't work anyway, it breaks by the first call of the VI, which loads the .NET assembly. Taking in account the VI searching path I put NET assembly (the DLL) in the c:\programs(x86)\NationalInstruments\LabView2010\resource. I'm not authorized to put it into ..\LabView2010\ directly. But after I did it  the VI itself works properly, which shows that LabView can load and open the .NET assembly. In spite of this,  the attempt to use the same VI in the test sequence terminates allways with the error message: "LabView 10.0f2 Development System doesn't work any more"(s. print screen). After closing error message window follows RunTime error -18001 - an error occurred accessing the LabView Active X automation server. 

To finalize my long message:

1) under Win7, TestStand2010 is able to use NET assembly within the test sequence as a sequnce step.

2) The LabView 2010 is able to start a VI,which loads a NET assembly and uses properties and methods.

3) It is not possible to call the same Vi as a step in a test sequence, allthough it worked well under Windows XP. The same test sequence of the same TestStand version is used, the only difference is the operation system and the fact, the the NET assembly is not in the directory where labView.exe is situated but in its default search path.

Please, give me an idea, what can I do to make it work under Windows7.

Best regards

0 Kudos
Message 20 of 29
(2,323 Views)