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!
This site uses cookies to offer you a better browsing experience. Learn more about our privacy statement and cookie policy.