distributing daqmx tasks with program exe

[JÞB]

---

@mysticfree wrote:

Thanks, crossrulz.  I'm still waiting on my DVDs updates.

---

Apparently, you have to call NI and request sneakernet media these days.  They expect you to be happy with the web installer for updates.

I'm not happy with it.  Feel free to call NI and rant.

[JÞB]

---

@mysticfree wrote:

What is the "behind the scenes" interaction with NI-Max task and the device name in a program?  Does NI-Max act as a server?

---

Yes,  there are several services running that make the MAX stuff available via vi server.  Those that have dropped down that rabbit hole refer to MAX as "XML HELL"

[Ben]

---

@JÞB wrote:

...

NOW I'm going to do something that it is seldom advisable to do,  disagree with Ben.

(Don't try this at home, I am a trained professional with years of experience)

  ...

---

I do not think I expressed an opinion to disagree with. I was just answering the question posed. But I will share what I think as another thought on how to approach DAQmx.

I use that "generate config and example" approach any time I am faced with a new DAQ widget that I have not used previously. I used to dial "1-800-domyjob" "1-800-IEEE488" and get an AE to find me a working example but the "generate..." saves us all time and works in a Windows environment". Not so much for RT, and do not get me started with the lack of similar support for modular instruments.

But after I see the example code I will either re-write it or modify my DAQ Engine libraries to use what I learned. In the case of the former, I rewrite it because contractual obligation blah blah blah and being able to pass a code audit in the event it gets down to a money issue when the project runs long. Not often but I do handle a lot of "we don't know what we don't know yet" projects. In the case of the modified DAQ Engine, it has been growing and expanding for many years now.

The DAQ Engine is driven by a config file that dictates what sub-systems are active, how many of each type and the details of each task, sample rates, channel counts and names, scale factors, averaging etc. Since the DAQ Engine requirements can not be completely determined at development time, the task are all create from scratch. When it comes time to clone the application using the DAQ Engine, only needs to have a proper config file and DAQmx installed. The approach also makes it easy to ensure the config is in source code control AND allows me to flip-switch and run applications in simulate mode after there is a need to trouble shoot after the hardware has been delivered to the customer.I have lost track but there may be dozens of that DAQ Engine running.

The installer take care of making sure the support for the DAQmx devices is included.

Summarizing:

I will most often create tasks from scratch and configure them in code.

Ben

[JÞB]

---

@Ben wrote:

---

@JÞB wrote:

...

NOW I'm going to do something that it is seldom advisable to do,  disagree with Ben.

(Don't try this at home, I am a trained professional with years of experience)

  ...

---

I do not think I expressed an opinion to disagree with. I was just answering the question posed. But I will share what I think as another thought on how to approach DAQmx.

I use that "generate config and example" approach any time I am faced with ....

But after I see the example code I will either re-write it or modify .......

The installer take care of making sure the support for the DAQmx devices is included.

Summarizing:

I will most often create tasks from scratch and configure them in code.

Ben

---

OK, You probably caught me with one of Yair's complaints.   I was being less than clear.

I added that line to emphasis your thoughts.   Then wrote comparisons of three methods too make the point "Know your users!" And choose the best method for them.

You can't make code idiot proof!  However, if you listen to the user, you can make code userproof.