07-02-2012 02:42 PM
When I run GenericImportExport.seq, the call to DB_PLImpotExportProperties brings up the Import/Export dialog. When I copy that step into my existing sequence, the error "Unknown variable or property name. (Error = -17306)" is thrown. I can see no difference between the two. They also appear to be running in the same environment.
Any suggestions?
Solved! Go to Solution.
07-04-2012 03:34 AM
Copy the local variables from GenericImportExport.seq to the local variables of your sequence.
This should resolve the issue.
07-06-2012 01:41 PM
Oops, unfortunately I already went in a different direction before I saw this post, and deleted my example. I'm pretty sure I copied the locals that were being explicitly used. I am a little concerned that this implies that the local variables are somehow changed by the DLL call without being explicitly passed. Is that correct?
07-06-2012 03:12 PM
So this was bothering me enough that I went back and recreated the problem. I cannot even call the entire sequence without getting this error.
I added a step to my test sequence that makes a call to the sequence GenericImportExport.seq in a separate file (where it was installed). Right-clicking on the the step and selecting "Run Selected Steps" causes the subject error.
I CAN use the tool menu "Import/Export properties..." or open the sequence itself and run ImportExport without a problem.
07-09-2012 12:25 AM
I understand your problem.
The import/Export utility is to download the propertly files during offline\static mode.
For dynamic or runtime loading use the property loader step type.
07-09-2012 12:54 AM
Further to the post :
The DLL is not able to find some variable and thus errors out.You can check the code at :
C:\Program Files (x86)\National Instruments\TestStand 2010 SP1\Components\StepTypes\Database
However you can copy the step itself into your sequence ( rather than calling the sequence) and its variables.
This will work.The DLL uses the Teststand local variables.
07-09-2012 08:40 AM
Okay, that did work.
I think it's unconventional to have a dll make use of variables outside itself - it's not an effective use of data hiding for sure. Dll methods should not make any assumptions about the caller.
But at least the problem is explained now.
Thanks!