Teststand labview .net error

[Jack-Rochester, NY]

Hi,

I have an issue of running test sequence calling different VIs that calls the same sub VI which is a wrapper around a .net dll.  The system we have is TestStand 2.0, Labview 7.0, and .Net 1.1.   I have used different loading and unload parameters for the test steps with "Non-Reentrant Calls" turned off.  The same error comes from the sub Vi that calls the .Net dll everytime, error 1172.  Is this a bug with teststand working with a common sub vi that calls the same .net dll?  Has anyone else encounter something similar to this?

Just to add, the individual VIs that uses the subVI calling the .net DLL will work fine when running from Labview but the issue is when ran within teststand.

Jack

Message Edited by Jack-Rochester, NY on 12-19-2005 08:47 AM

[Adam B.]

Jack,

There is a Knowledge Base Article that discusses error 1172 when calling .NET assemblies from LabVIEW.  Basically, prior to LabVIEW 8.0, LabVIEW needed to have the assembly in the same folder as the .VI or in your case the .DLL.  You may also want to look at this forum, which describes another problem causing the same error number.  Following these steps should work, but if you're still seeing the error, go ahead and paste the actual error message that you get so that we can look more into what might be causing this.  Thanks and have a good one.

[KenNG]

I have a related question.  I am using TestStand 2.0 to run Labview 7.1 vis which call a .NET assembly (DLL).  The system does seem to work if I put a copy of the .NET files in the folder of every top-level vi invoked by TestStand.  However there are 60 such vi's so I have 60 copies of the same dll.  This is clearly undesireable.  I tried using a short-cut instead of the actually DLL but that didn't seem to work.  Do I really have to have maintain 60 copies of the same file?

Also, the DLL is a low-level driver to a network analyzer with an ethernet interface.  The ethernet reference is stored as a static variable inside a class in the DLL.  Is this same variable shared among the various TestStand invocations of the top-level Labview vi's or is each invocation of the Labview vi by TestStand a different process which does not share any variables with other invocations?  Before putting the DLLs in each of the 60 folders, I had problems with 1172 errors.  At one time I thought I had problems talking to the logic analyzer because the DLL had not release the reference used by a previous TestStand invocation and could not get a new reference.  Creating a static variable in the driver seems to have fixed that issue.

A further complication is that TestStand is being driven by a Labview front-end.  Is the Labview front-end really the top-level vi whose folder should contain the DLL?  If so, is the above static variable then shared among all the vi's that TestStand invokes?

[Adam B.]

Hey Everyone,

I've responded to Ken individually through our support channels, but I wanted to make sure the answer also was received on the public forum.

The fact that the .NET Assembly has to be in the same folder as the LabVIEW VI is a bug that existed in LabVIEW versions 7.1 and earlier that has been fixed as of 8.0.  If you use 8.0, you won't have this issue.  Unfortunately, with 7.1 and earlier, it is necessary to have the assembly in the same folder as ANY VI that is trying to call into that assembly.  This would include code modules, sub-VIs from the code modules, and VI's from the Operator Interface that are calling into the assembly.  This is not an ideal situation, but workarounds include having all of your VI's in the same folder or upgrading to 8.0.

As far as the static variables are concerned, if you use the constructor node in each individual VI's, they will be in different processes and the static variables will not be shared.  However, if you pass the reference between the VI's then you should be able to keep the same instance of the Framework and will therefore have the same shared variables.

If anyone has any additional questions, please feel free to repost.  Thanks and have a good one.