Motivation: Ideally, we would have LabVIEW VI's that didn't invoke these hokey dialog boxes just to get experimental parameters, and instead just read them from native LabVIEW UI elements.
What is the best way to feed experimental parameters into and read experimental data out of libec.dll?
Should we use "clusters"? Can we do this in a modular fashion with sub-VI's or something similar? The ideal solution would allow us to have something like one (sub?) VI per technique per instrument model (there are 102 models available online right now), without having to duplicate the (say) cluster code/wires 102 times. (Nobody wants to have to keep 102 VI's up to date!)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The goal **
- a single master input vi for all techniques (test.vi)
- 1 ctl for each technique (wrapped in a vi, with non-trivial logic to hide unused parameters)
It would have been nice to display the wrapper vi on the master as a subpanel, but it seems like you need to jump through a lot of hoops just to pull data out? This is largely cosmetic, and maybe somebody else can do this later... I'm more concerned about laying down the core infrastructure.
Also, I think that all "return type (Boolean)" types for Call Library nodes should be changed to unsigned char (was getting erroneous behavior in some testing with CHI_hasParameter())
In the end, a Tab Container turns out to meet our multi-model, multi-technique needs quite cleanly...
The attached is almost ready to plug into Chris Hibberd's setParameters and output apparatus, but I'd like to make sure that it works before checking into Subversion, at which point I'll have to do the data entry...
First of all, I greatly appreciate your work on making the LibEC SDK available. I am using C# to load functions from the LibEC.dll and it works well to run experiments. When I called the CHI_hasTechnique function it returns a number which changed everytime. How to tell whether the technique (given by an ID passing to the CHI_hasTechnique function) is supported? Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Motivation: Ideally, we would have LabVIEW VI's that didn't invoke these hokey dialog boxes just to get experimental parameters, and instead just read them from native LabVIEW UI elements.
What is the best way to feed experimental parameters into and read experimental data out of libec.dll?
Should we use "clusters"? Can we do this in a modular fashion with sub-VI's or something similar? The ideal solution would allow us to have something like one (sub?) VI per technique per instrument model (there are 102 models available online right now), without having to duplicate the (say) cluster code/wires 102 times. (Nobody wants to have to keep 102 VI's up to date!)
Chris Hibberd made a great start (see attached).
commandeering this thread for "half-assed commits" for the time being - before deciding how best to merge this stuff into the Subversion trunk
this "commit" hides controls based on whether they are supported in libec.dll (for instance, not all models support m_bAutoSens)
still have to figure something out for sensitivity, which is model-dependent but technique-independent, right?
Last edit: CH Instruments 2013-06-25
Slow but steady progress on the input side
The goal **
- a single master input vi for all techniques (test.vi)
- 1 ctl for each technique (wrapped in a vi, with non-trivial logic to hide unused parameters)
It would have been nice to display the wrapper vi on the master as a subpanel, but it seems like you need to jump through a lot of hoops just to pull data out? This is largely cosmetic, and maybe somebody else can do this later... I'm more concerned about laying down the core infrastructure.
Also, I think that all "return type (Boolean)" types for Call Library nodes should be changed to unsigned char (was getting erroneous behavior in some testing with CHI_hasParameter())
Last edit: CH Instruments 2013-06-28
In the end, a Tab Container turns out to meet our multi-model, multi-technique needs quite cleanly...
The attached is almost ready to plug into Chris Hibberd's setParameters and output apparatus, but I'd like to make sure that it works before checking into Subversion, at which point I'll have to do the data entry...
The attached seems to work! (currently CV only, and only for 12xxA/B and 6xxD/7xxD/9xxC)
Will check into Subversion tomorrow after some final testing, and then the multi-model data entry begins...
First of all, I greatly appreciate your work on making the LibEC SDK available. I am using C# to load functions from the LibEC.dll and it works well to run experiments. When I called the CHI_hasTechnique function it returns a number which changed everytime. How to tell whether the technique (given by an ID passing to the CHI_hasTechnique function) is supported? Thanks!