I'm developing a LabVIEW-RT project using a PXI platform (with timers, multifunction boards, and DIO) in LabVIEW 2012. I'm currently "getting into" the DAQmx part of the code, trying to keep it simple and functional.
I like the idea of defining a Task that encapsulates most of what I want to do. My question is, from the standpoint of my LabVIEW Project (here meaning "Project", the wrapper that holds and deploys my code to both the PC and the PXI), should I define my DAQmx Tasks in Project ("New DAQmx Task") or in MAX?
I just noticed that if I do define a task in MAX, say TIO_1KHz_Clock, I cannot define a task of the same name in Project (it says "There is already a task by that name", but I don't "see" the task in the Project Explorer -- maybe I just don't know where to look). So I see several possibilities --
1) Define the task in MAX, use the defined Task Name in Project. [Question -- can I find out, and "see", the defined Tasks in Project? Will the definitions continue to "hold" if I move the Project code to another PC that might not be connected to the PXI Target?].
2) Do not define the task in MAX, but do define it in the Project. This seems to me to be the more "portable" way to do things -- are there downsides I should consider?
3) Define the same tasks in MAX and Project. As noted above, this didn't seem to work when I tried it, but maybe I'm just not doing it correctly. If this could be done (or if the MAX Task definition could be "imported" into Project so it would persist and be "visible", maybe even "changable" in Project), this might be an optimal solution.
4) Define the same tasks with different names in MAX and Project. This strikes me as simply confusing.
I would appreciate thoughts by DAQmx Gurus on what they consider Best Practice.
I'm not a guru, but for applications where I'm going to deploy to another machine or person I always define my tasks within the project. This means that everything relating to the specific project is kept together which if you're working on multiple things at the same time makes updates a lot simpler.
The downside of this is that it removes the ability of the end-user to modify the tasks if for example a different sensor is use, but my experience is that this can be dangerous anyway - unless the user is used to MAX then unintentionally changing the functionality is only too easy (from bitter experience).
I found this old thread, because I have now same problem.
I'm developing with LabVIEW Real-Time System 2016 which is using "Phar Lap ETS".
I'm used to saved all tasks into Project for years - until now.
Today I switched to 2020 NI Linux Real-Time and my code do not longer work having Tasks in the Project.
Even if you use the DAQ Assistant (=working), but after Right-Klick and convert to DAQmx-Task it will not work any more:
Error -200428 occurred at Untitled.vi
Value passed to the Task/Channels In control is invalid.
The value must refer to a valid task or valid virtual channels.
I don't know the reason for not working, maybe because LinuxRT or LabVIEW2020.
Now I have to save my Real-Time DAQmx Tasks again in MAX.
Wow, that really is an old thread. I wonder what the Original Poster does now, almost a decade later ...
The answer is ... None of the above! At some point around the Original Post, I stumbled upon "Learn 10 Functions in NI-DAQmx and Handle 80 Percent of Your Data Acquisition Applications" (or something like that). I usually start with a sub-VI with the clever name "Find DAQ Device" that looks something like this:
Inside the For Loop, I can put a list of devices I hope to find, and (as the example illustrates) can even look for a device with a specific Serial Number, if necessary. What you do if there is "no such device" is up to you -- in the code here, I threw a 5001 User Error with the message "No Such Device".
Once you have a Task, the "10 Functions" article shows how you usually need only a few more functions (I used a Create Channel function to set up a pair of AI +/- 10V Voltage Channels and a Sample Clock function to take 10 Samples at 1 kHz continuously, Started the Task, then took data in a "Do Until I Tell You To Stop" loop.
That turned out to be (for me) the simplest, most robust, so-far-LV Version-independent way to get DAQmx up and running. It works on PCs, on PharLap systems, and on Linux-RT systems (hmm -- I might not be speaking from Personal Experience -- seems to me my recent foray in to LabVIEW RT used hardware with an FPGA onboard, so I wasn't really using DAQmx ...].