TestStand Error -17600 when using Basic Function Generator

[Taki1999]

This one is driving me nuts.

I have a pretty simple Step which calls a vi which contains the Basic Function Generator out of NI_MABase.lvlib.

Works fine when I run the Operator Interface under my account.

When I try and run using our generic operator account, I get a TestStand -17600, VI cannot be loaded.

Debugging this is a pain since the operator account doesn't have a LabVIEW license so I can't open the VI and figure out why TestStand might think it's broken.

I'm thinking it's something with file permissions or a dll not being visible to the generic account but I can't seem to pin it down.

Using TestStand 2010 SP1 and LabVIEW 2011.

Any ideas on how to debug this or isolate the problem?

[~jiggawax~]

What is your LabVIEW adapter set to?  If you don't have a LV license then you need to use the Run Time Engine.

Also, I'm not familiar with the Basic Function Generator.  Does it require a run time license?  Some of the LV packages do (e.g. GPS).

Regards,

[Taki1999]

I have my Adapter set to LabVIEW Run Time.

I switch it back and forth between Development and Run Time when I'm doing development. It's always in RunTime before I run the operator interface.

I don't think the Basic Function Generator requires a license. Maybe it does and maybe I have to rewrite it. Was hoping to avoid this.

Another curious bit, I replaced the calls to the basic function generator that I had placed from palette with direct calls into the masignal.llb. This got rid of my -17600 error but resulted in a -18001 error instead.

Seems I get different behavior whether the VI calls NI_MABase.lvlib:Basic Function Generator or masignal.llb:Basic Function Generator.

Unless there's a better idea by Monday, I'll just rewrite the function generator since it's pretty simple math. Just ticks me off that there is a perfectly good canned LabVIEW function that I have to throw away because TestStand can't seem to unwrap it properly.

[~jiggawax~]

I'm pretty sure it's not that TestStand can't unwrap it.  I bet it is related to linking.  Because you are running source code from TestStand the VIs need to be properly linked.  Try deploying it and running it.  Or doing a source build and trying it.  The other thing is that you need to be able to find the dependencies from the search directories.

Regards,

[Taki1999]

Good suggestions.

I'm pretty sure a deployment would work since I think I've deployed this system before.

Seems like a lot of effort to go through to get it to work though.

Was thinking about the search directory issue but the search directories should stay the same between my developer account and the generic user account.

My biggest problem is that I can't reproduce the problem on my developer account and I can't get enough information out of the generic account to fix the linking.

I really wish the TestStand error window would give me more useful information.

It also bugs me that I don't think this is the first time I've seen weirdness with TestStand linking items in vi.lib.

I'll try the deployment on Monday and see if things get better.

Thanks for the ideas. I'll let you know how it goes when I get back in the lab.

[Taki1999]

Hmm. . . Looks like I may have some other RunTime weirdness. I think I may have a LabVIEW2011 SP1 runtime instead of a LabVIEW2011 runtime. Might also try doing a LabVIEW repair/TestStand repair and pointing the adapter back to 2011 instead of letting it do autodetect.

[~jiggawax~]

As far as I understand the run time engine differences shouldn't be a problem betwen the SP1 and normal.  But I could be wrong.

I agree that it is a pain to rebuild to test.  However, think of it like an executable with just a stand alone LV app.  You can't test the exe without rebuilding.  The confusing part for most users is that with TestStand they are still VIs.  But deep down under the bowels of the TestStand Deployment Utility it is simply doing a source code distribution build with LabVIEW.  If you want to see the .lvproj it uses you can look in the %TEMP% folder.  It will have a weird name.  You can open it up and see what is getting deployed on the LabVIEW side.

Hope you get it figured out.   If I think of anything else I'll post it.

Regards,

[Taki1999]

Just a brief update since I got back in lab for a while.

My deployment initially failed due to conflicts of Clear Errors in vi.lib with Clear Errors in TestStand\SupportVIs.

I added a Project around the conflicting step and am going through the deployment now.

My deployment takes a couple of hours to build which is longer than I thought it used to take.

I really wish the Deployment Build screen had a better indication of what is was doing during that time.

Anyhow, I'll post back tomorrow when the build is done and deployed.

[Taki1999]

Looks like I have a couple of problems with my deployment.

My deployment pushes StationGlobals.ini and a custom Model.

When an admin uninstalls my TestStand Deployment using Windows Control Panel, the uninstaller kills StationGlobals and slags the TestStand system.

Doing a TestStand Repair now to try and recover and fix up the deployment.

Is there a way to deploy the StationGlobals in a manner that doesn't let the Uninstaller kill it? My typical method is just to add it to the workspace and set the install directory to go to the TestStand\Cfg directory.

[~jiggawax~]

One thing you could try is put the file in a temp folder and then have a custom command run as part of the installer.  The custom command could copy it over to the Cfg folder.  This way the installer doesn't know that it's a file it installed and won't uninstall it.

Regards,