LabVIEW
more info about DAQmx Control Task
Solved!
Blokk a écrit :
Usually when I deal with some hardware using DAQmx driver, I just specify the channel, and I use the Create Virtual Channel VI to setup my task which I want to use.
Recently I was reading about the benefits using the MAX to pre-create some global (?) tasks (for example for a cDAQ with lots of modules and I/O channels), and using these tasks in a LabVIEW project. In this case I can just skip the "Create Virtual Channel.vi", and start with the measurement with a DAQmx "Start Task", and stopping it with a "Stop Task" VI, correct?
However in the above link, the "Control Task" VI was used (beside a Start Task), first with a "commit" parameter, and when closing the measurement, with a "unreserve" parameter (and no Stop Task vi was used).
I had a look at the Help for the "Control Task.vi", but the info there is not too detailed, where can I find a bit more details, or maybe someone could highlight the usage/benefits of this vi? The help sounds a bit "funny", like for the commit parameter: "Programs the hardware as much as possible according to the task configuration." 🙂
So what is the difference between using the "Control Task" in a code, and not using it (so when we only use the Start and Stop Task VIs)? Do not we get the same behaviour with the latter?
Thanks in advance!
Yes you can define a task in MAX that includes multiple modules and channels as long as they're all the same type of measurement. I do it all the time. The advantage is that you can easily modify and validate it without modifying the code. Note that we are using it in house, I'm not sure I would do it like this if it was for a customer application.
In most cases you don't need to perform explicit state transitions, The DAQmx Write VI, DAQmx Read VI will implicitely commit the task and will also start it if the Auto Start property is set to TRUE.
When you call the Start Task VI without using the Control Task VI the task will implicitely goes to all the states from unverified to running.
Lets take a look at the different state transitions:
Unverified to Verified: Timing, Triggering and channel properties are configured and validated
Verified to Reserved: The required ressources are acquired (clock, buffers, ..)
Reserved to Commited: The ressources are set
finally Commited to Running
When would you need to explicitely define the transitions?
When in an application users interactively configure tasks by setting channels, timing and triggering properties. When the application contain different tasks that uses the same ressources. If the application repeatedly start and stop a task commiting the task will set the ressources once, not everytime the task is started thus speeding up the process.
Hope this help clarify things a bit.
Ben64
Blokk a écrit :
About the global task configured from MAX: we do research, so I always develop only for our lab, we do not sell anything. However, I have some questions regarding to a Task configured and saved in MAX:
- So i have a task created in MAX, I guess this task will be only usable if I use it in a LV project on the same PC? What about if I need to move my application to another PC (but obviously containing the same cDAQ modules, etc, but maybe under different numbers....)
The task is also usable with a .exe. You can export MAX settings in a .nce file (File, export ...) and then import the settings on a new PC. If needed you can tweek the numbers.
- I like to create an EXE from my code and only run this EXE for our systems (not installer). Are there any tricks I have to keep in mind when I create an executable from a project containing a MAX task?
I can't think of anything special. Personally I prefer to load the task name from a config file, you can alternatively use a control on the front panel to select the task.
I have the feeling when we need total flexibility, the MAX route is not really handy, yes? I mean, if we want for example programmatically recognise all the NI hardware from our application, and create the tasks to ensure any physical changes at the PC side in the future will not impact our code?
I agree that you don't have as much flexibility, but for my applications most of the time MAX provides enough flexibility
But this scenario could be documented for future users in the lab I imagine, so what they have to do only, is to re-create the global task? What happens when we move the application as an EXE to another PC, and manually re-create the (hopefully totally the same) required global task with the same name what the EXE expects? Does it work this way?
Thanks for the very useful info!
edit: "Yes you can define a task in MAX that includes multiple modules and channels as long as they're all the same type of measurement. "
This is also a limitation compared to code based task creation, yes? I mean, using the DAQmx "Create Virtual Channel.vi", we can even combine for example analog inputs with thermocouple channels for example in a cDAQ chasses...
No this is not a limitation, thermocouple channels are analog inputs. If you can combine them in LabVIEW you can combine them in MAX.
edit2: I really miss some more "real-life demonstration" type docs from NI side! I could imagine some kind of case study examples where different NI hardware handling would be explained...Of course we can hunt together the mosaic pieces, but a more compact picture could help a lot for those who wanna learn faster 🙂
Ben64
