Setting DAQmx Tasks up in project instead of NI Max

[id]

I am writing a labview application to be installed on a PC as an executable file with the Labview Engine.  I can put my DAQmx tasks in my project or NI Max.  If I put them in my project and I build my application, do I lose the ability to change the IO settings in NI Max independent of my application?

What is the best way to mechanize this with all the features of things like DAQmx tasks being created in my project rather than NI MAX? 

[Bob_Schor]

I'm not certain, but I suspect that the Task constants that you wire to a DAQmx function, whether they come from MAX or from the Project, will remain "constant" when built into an Executable.  What I would be tempted to try is to use the Task and wire it to the appropriate Property Nodes to programmatically change the (hopefully few) parameters that might need to vary.  

As for MAX vs Project for setting the Tasks, my preference is for Project.  I'm not sure that there are compelling reasons for one over the other, but Project feels more "natural" to me.  Maybe someone else will respond with a strong reason for one choice or the other ...

BS

[keroba]

Hi there,

As Bob says, the best way to do this is to create a DAQmx task using the DAQmx VIs, in that way you always is going be capable to change the channels settings using controls in the front panel of your application.

Here is a link with more information about it :

http://www.ni.com/product-documentation/5434/en/

Regards

[JÞB]

---

@id wrote:

I am writing a labview application to be installed on a PC as an executable file with the Labview Engine.  I can put my DAQmx tasks in my project or NI Max.  If I put them in my project and I build my application, do I lose the ability to change the IO settings in NI Max independent of my application?

What is the best way to mechanize this with all the features of things like DAQmx tasks being created in my project rather than NI MAX? 

---

First. Yes persaisting the DAQmx features to the project removes them from MAX.  You will not be able to run them or modifiy them from MAX but only within the Project Context.

This is not always BAD.  For instance, no one can "Fat Finger" your configuration or install another Task with the same name that uses different settings.  Using the Project provides a context boundary wheras MAX is universally accessable.

Using the Project to store "Tasks, Scales, etc" DOES NOT remove the ability to modify them though.  Tasks stored in projects built into an EXEs wind up deployed as a text file in the exes support directory (Exe\Support\NI DAQ\<Something.txt>  This is a human readable configuration file that has the tasks settings in it.  If you need to change a setting (like increase a sample rate or change a physical channel) you can edit the file and the exe will use the new settings.

This is not always GOOD For instance, if the test system suffers a fault, MAX cannot selectively control the IO channels for troubleshooting.

Knowing the pros and cons of each method will help you work within your team to develop the best approach for your needs.  I've recommended each approach to various clients.  (And been right both ways!) 

What I've never recommended is creating tasks programatically.  However, I can see some use cases where hiding the configuration from everyone (on a removed BD) might be desired in a highly regulated enviornment where a possible change to a Task Property Could change code validation and the ECO process requires removing any possible "Hidden" access to the config files (Although a hash on the EXE folder could be used to disable testing)

[natasftw]

Creating a task programmatically doesn't equate to hiding the configurations on a removed Block Diagram.  I generally create tasks programmatically.  If I want something to be able to be modified, I just pop a control on the Front Panel and it's easy for the user to change what's meant to be changed.  This is no more of an abstraction than "hiding" the configuration in a text file that most users will never take a look at.

[Dennis_Knutson]

I've generally created the talks programmatically as well. Partly because most of my applications are used for production testing and you don't want the possibility of a user changing anything except what you specifically provide. Partly because it's what I'm comfortable with having started doing data acquisition long before tasks could be created externally. Partly because it's irritating to me to go back and forth between MAX and LabVIEW. Partly because when I first used DAQmx, all of the examples did it programmatically (and still do) and I saw no benefit in doing new code any differently.

It's also like to mention that I find it extremely irritating when someone posts a data acquisition question and the setup is done in MAX or the project. It makes it harder to help when all that is posted is the VI.

[JÞB]

---

@Dennis_Knutson wrote:

It's also like to mention that I find it extremely irritating when someone posts a data acquisition question and the setup is done in MAX or the project. It makes it harder to help when all that is posted is the VI.

---

Agreed.  For those posts I would generally ask the poster to "Generate Code... Configuration and example" off the right click to expose the properties.  Easy enough to work around

[nimic]

to throw in my two pennies worth of opinion:

If you need to recalibrate any inputs, in-LabVIEW task definition can make changing of scales rather cumbersome. Whereas, if tasks are defined in MAX, calibration can be run and tested individually.

Michael