DAQmx Digital Output Tasks and Channels

[TennesseePaul]

I'm writing an application which enables a user to open and close valves. There are, right now, about 20 different valves. I currently have unique tasks created for each valve wired to a channel in a 6516 board.

My question is about common or best practices. Is it best to have one task with all channels in it, then write an array of booleans to the task each time a valve is opened/closed? Or is it better to create individual tasks, assign one channel to each task, then DAQmx Write as called upon for that single task?

This arose out of creating the Event Case for the VI. The basic programming for each valve is the same>>DAQmx Write Digital Output 1 sample. But doing so 20 times makes for an annoying event case structure. I would like to simplify the code if possible but am uncertain as to the best method forward

[JoeLabVIEWEngineer]

From what you describe, your code is likely to change over time. I understand it will make your code looks long. But one task per channel is probably the way to go. Work hard in the beginning it will pay off later. Good luck.

[TennesseePaul]

I suppose then I should ask, when utilizing single boolean sample Digital Ouptut tasks, should I start all 20 tasks at VI startup, then call the DAQmx write on event change, or should I create task, start task, write, stop task, clear on event change?

[JoeLabVIEWEngineer]

It is also depends on how serious, and rigid your requirements are. If you do it in the Lab purpose only, and not time critical, I would open and close every single time. Because it is flexible, making change easy, especially you will change code 100 times in a day. You put open and read/write then close in a single vi. But if you got solid requirements, and change code less than once a week. Then you should open it in the beginning then terminate at the end. Hope this help. 

[Dennis_Knutson]

In my opinion, if you have a front panel array of Booleans and one write, that would be the most efficient and not subject to change. The idea of 20 separate tasks and 20 separate events just seems harder to maintain.

I would recomend that the event only does a DAQmx Write, meaning that the tasks are created at startup and closed when the stop event is run.

[TennesseePaul]

Thanks, jobLabVIEWEngineer. Your posts are helpful, but are largely voicing my thinking process on this matter.

This code will run in production, not in a lab with daily edits. Updates will be minimal to non-existant once deployed.

However, none of these valves for this device need the timing enhancements which come with moving the start/stop outside of the loop. Typically there must be a several second delay between changing valve states so the physical system can keep up (ie. turbo pumps, scroll pumps and gas glows cannot be triggered simultaneously).

[TennesseePaul]

Thank you for your response Dennis_Knutson.

My front panel does not have an array of booleans, but that is an interest thought.

Right now they are individual boolean controls which I was going to combine into an array and then send them to write.

I was thinking of creating one event case which referenced all the boolean controls, then building an array of the boolean values and sending it to the DAQmx write.

It would make for simpler code at start-up and for a smaller case structure, but then I have "automated" processses which trigger the valves to work in sequence, which would mean writing the values for all valves repeatedly. So part of the code gets simple, another part gains in complexity.

[TennesseePaul]

"Right now they are individual boolean controls which I was going to combine into an array and then send them to write."

I should say, individual controls of which I will take the values and build an array.

[JÞB]

---

@JoeLabVIEWEngineer wrote:

It is also depends on how serious, and rigid your requirements are. If you do it in the Lab purpose only, and not time critical, I would open and close every single time. Because it is flexible, making change easy, especially you will change code 100 times in a day. You put open and read/write then close in a single vi. But if you got solid requirements, and change code less than once a week. Then you should open it in the beginning then terminate at the end. Hope this help. 

---

Hi Joe

Open Task and Close Task really are meaningless terms.  You have a task or you have no task.  A Task may be "Created, Validated, Reserved, Comitted, Started, Stopped, Aborted and Destroyed"

see here for a real peek under the the hood

You get 4096 (at last count) Tasks for free, the next may cause an error.  The first time I encountered this error I realaized that Tasks need to be created once. Preferably during development.  You can edit them easilly with the DAQmx wizard in the IDE or even at run-time with p-nodes if properties need to be dynamically assigned.  

Create during development

Destroy never

Commit just before you need the resources, Unreserve when you are done so something else can get the resources.