MAX tasks vs generated tasks - opinions

[BowenM]

So, traditionally I have always just programmatically generated the tasks based on the hardware and configured channels. I found it easier for my users (they only needed to learn my software instead of mine and NI MAX), and overall more generalized. I didn't need to worry if they swapped one card in or moved its position in the chassis. I could just detect what was available and build the task based on that.

However, I have started using Signal Express a bit more frequently and have been actually quite impressed with the NI MAX approach for acquisition and control. The interface is easy for calibrations, configuring, etc.  

So, my question to some of you "old guys" that have been coding in LV for 20 years...  two questions.

1) Which approach do you find easier and more useful to implement in your program?

2) Why do you think that way?

Thanks!

[crossrulz]

It completely depends on the situation.  A test system that will only ever run 1 task and it is completely dumb (data logging, display, minimal manipulation): make the tasks in MAX.  If I need a dynamic setup, make my own.  Mine tend to be made with ini files, but I think there are better solutions out there, just haven't had to time (or project) to play around with some of the ideas in my head.

MAX makes the tasks very easy to make.  They are very simple to export and import between machines.  But they are very static (don't like change).

Rolling your own takes some time.  But you can make the tasks dynamic and even detect which boards are where.  I've seen some very powerful iterations, but they become complex and often not easy to work with.

[JÞB]

---

@crossrulz wrote:

It completely depends on the situation.  A test system that will only ever run 1 task and it is completely dumb (data logging, display, minimal manipulation): make the tasks in MAX.  If I need a dynamic setup, make my own.  Mine tend to be made with ini files, but I think there are better solutions out there, just haven't had to time (or project) to play around with some of the ideas in my head.

MAX makes the tasks very easy to make.  They are very simple to export and import between machines.  But they are very static (don't like change).

Rolling your own takes some time.  But you can make the tasks dynamic and even detect which boards are where.  I've seen some very powerful iterations, but they become complex and often not easy to work with.

---

First I would disagree that any DAQmx task is resistant to change.  Stored in MAX they are valuable troubleshooting aids and can be easilly reconfigured without redeploying your application.  Maintaining configuration accross multiple machines can get tiresome and "High Mix" test stations can make storing DAQmx in MAX a large pain since you have inputs from multiple projects.

In those cases I Too use an *.ini file to maintain my project specific DAQmx config-  AUTOMATICALLY generated by the App Builder and called <MyApp>\Data\NI-DAQ.ini.  A nice place to human edit the tasks etc..  when say, a scale changes offset a bit between stations.  "Project stored stuff" is a great way to provide some context bounds for your Task.  All the advantages of being able to buld on the fly from file (since they ARE in an ini) and none of the hassle of re-inventing the wheel.

OK so you deploy source.  Edit the DAQmx stuff with the wizard and leave them in the project where they can't be called from somewhere else.

Don't worry too much Tim,  I'm sure all the time and effort you put into rolling your own was nearly as effective as the Out-of-the Box implementation!

[BowenM]

crossrulz,

Thanks for your response. A lot of those reasons are why I used to strictly build my own. Sometimes (rarely) if it was just a quick acquisition program I'd use a task, but only if it was a "once use" program to just grab some data.

As I looked more in to just using tasks, a lot of the arguments started to seem... weak. As I wrote more complex methods for programmatically setting up tasks in order to be dynamic, I quickly realized that I was just rewriting a worse version of NI MAX. My calibration utility was a little more difficult to use, and my configuration utility required a bit more knowledge about your hardware.

For tasks being less dynamic, it would be easy for a program to dynamically adapt to a selected task.  The "Configuration" would be simply setting up your acq / control channels inside of MAX, and then having your program rename all of your plots / indicators, etc to the MAX task names.

The biggest drawback I see right now you already mentioned: difficulty in exporting them between machines.

Jeff,

What about the cases where you want to allow your customer to use your program as more of a "general acquisition"?  Do you just let them create their own tasks inside of MAX?

Edit: Responded before I noticed Jeff post.

[crossrulz]

---

Jeff·Þ·Bohrer wrote:

Don't worry too much Tim,  I'm sure all the time and effort you put into rolling your own was nearly as effective as the Out-of-the Box implementation!

---

Actually, I put relatively little effort into my *.ini implemention and it was exactly what was needed for the situation I was in (single test rack needing to test 15 different modules, dynamically choosing which one to test, and TestStand was involved as well).  Though, those ini files had a lot more in them than simply DAQ (DIO, power supply setups, electronic load setups, etc.)

[JÞB]

Jeff,

What about the cases where you want to allow your customer to use your program as more of a "general acquisition"?  Do you just let them create their own tasks inside of MAX?

---

"General Acquisition"  Or "engineering bench" I assume, is a far cry from "Automated Test" where I have most of my development targets.  Yes most, not all.

The approaches I outlined work exceptionally well for those use cases.  After all you DO NOT want changes to the "Test" without some process change control.  On the Lab-side your bench is much more likely to be source code and a development enviorment.  I that case a "Project Template" for "Experiment" seems to me to be the best Idea with base DAQmx stuff in the project that can be modified to suit the experiment- Yup 1:1 correlation between *.lvproj and Experiment (You can always re-run with this method)   If your template is well thought out the user's need minimal training to prevent blowing up the project Some training and coaching will be required though! (Hint "Tag-Team" an experiment- or Jing it!)

[BowenM]

At the moment I am thinking general acquisition. No output at all.  

That having been said, we do have quite a few of automated test benches. In fact, I the program I basically tried to rewrite a poor version of task creation (which partially spawned this for me) was designed to be a simple generic program for automated benches - able to do general PID control for any number of analog or digital I/O.  I was very unhappy with my setup and calibration modules though and started looking for better solutions.

In the case of this program it isn't even being used in house, so the customer will need the ability to completely set up different and unique tasks. 

[natasftw]

SignalExpress makes me cry.  That's not exactly doing things in MAX, though.

[JÞB]

The DAQmx wizard is the DAQmx wizard!  really nothing to B*tch about!  it is helpful for creating and prototyping DAQmx'y "Things."

The question comes down to: How you use that tool and, where you stick the output it in your tool-box!  Yes I, have some preferances that work for my clients!  But, it really is a nice tool to learn about!

[BowenM]

---

@natasftw wrote:

SignalExpress makes me cry.  That's not exactly doing things in MAX, though.

---

Well, I mean... SignalExpress is really just an overlay to MAX that lets you dump data in to .tdms format.