06-04-2011 04:46 PM
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.
06-06-2011 05:37 AM
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!
06-06-2011 10:17 AM
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
06-07-2011 03:27 AM
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.
06-07-2011 09:12 AM
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
06-09-2011 11:28 AM
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
06-10-2011 03:32 AM
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
06-15-2011 08:43 AM
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
06-15-2011 08:49 AM
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 :-)
09-20-2011 03:26 AM
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