Multiple DC Outputs from PXIe-6739

[Overthere]

Hello - 

I have a large test stand used for R&D and DVT. The core of the system is an NI PXI chassis with a dozen or so NI cards of various types. I'm working on an upgrade for the system architecture and capabilities, and I've added several amplifiers to the system which each have 10-15 control lines. These are all 2-5V DC lines which draw <5mA. Excepting a few, they will generally be turned on and left on for months at a time.

When I asked our NI rep what I could use to power all of these control lines, he recommended the PXIe-6739. So, fast-forward to today, I now have this card loaded in the system, and I'm struggling to get it to behave as I would like. My experience in DC from NI hardware is generally with SMU/PSU units with DCPower where the behavior I want is extremely straightforward.

Our test code is in LabView under TestStand/TSM. I have the DAQmx LV drivers installed and the instrument set up in NI MAX. Using the test panel in MAX, I seem to be able to turn on an output to a DC voltage, but it's very awkward.

It seems that I need to create a task for each of the 64 physical output pins with a predefined voltage. Although this is very cumbersome, it's probably workable... However, there are four AO pins that I need to be able to vary continuously. Not a sinusoidal/AC variation, but a constant updating of the DC voltage in response to other conditions.

Is this possible with this card/software setup, or did I end up with completely the wrong device for this application?

Thanks very much for your time and help!

[crossrulz]

---

@Overthere wrote:

It seems that I need to create a task for each of the 64 physical output pins with a predefined voltage. Although this is very cumbersome, it's probably workable... 

---

If you have a bunch that are constant, you could create a single task with all of the constant voltages.  You the use DAQmx Write to set all of their voltages at the same time.  You then have the variable outputs in their own tasks and just write when you need to.

[Overthere]

Thanks for the reply. I had some trouble creating a task which referenced multiple physical pins - that kept throwing an error in LabView telling me that a task could only have a single physical channel associated with it. I didn't pursue that too far, so maybe there's a way around that one.

As for using tasks for the individual pins that I need to vary... is it possible to create a task which allows the DC voltage I want to set to be passed as an argument? It doesn't seem like a very efficient approach to create a task for "Set ao0 to 0.273V" and then another task for "Set ao0 to 0.0274V" and so on.

Is there maybe some examples or documentation you'd be able to point me toward that gets at this situation? I didn't have much luck searching but I suspect it's out there somewhere.

Thanks again.

[crossrulz]

---

@Overthere wrote:

As for using tasks for the individual pins that I need to vary... is it possible to create a task which allows the DC voltage I want to set to be passed as an argument? It doesn't seem like a very efficient approach to create a task for "Set ao0 to 0.273V" and then another task for "Set ao0 to 0.0274V" and so on.

---

What I do for similar situations is store the tasks in an Action Engine.  If using LabVIEW 2019, store the tasks in a map so you can perform a lookup based on a string (name).  So when you need to update a value, you call the Write action by supplying the name and the value to write.

[Overthere]

The AE concept looks very similar to the way that I generally implement similar solutions as well, so that's probably good news.

That said, I'm still a bit lost. Are you saying that I would indeed need to create tasks for every possible voltage I might ever want to apply, and then it's just a matter of invoking the correct task? It sure seems like there would be a more straightforward way to say "Set ao0 to 2.0V" that doesn't involve creating a task beforehand and writing a bunch of wrapper code around the task to make it easily callable in LabView. I need these voltages to be continuously variable down to millivolts over a >3V range, so that is a LOT of tasks to create and manage. If I really do have to create thousands of individual tasks, is there an automated way to do that?

And unfortunately I'm stuck at LV2016 for corporate reasons.

Thanks again!

[crossrulz · Accepted solution]

---

@Overthere wrote:

If I really do have to create thousands of individual tasks, is there an automated way to do that?

---

Thousands?  I thought you only had something like 64 channels.  You are not creating a new task each time you have to update the output.  You create a task at the beginning of your program and then use that task to update the output voltage throughout the program.  Do make sure to clear the task at the end of the program.

[Overthere]

Eureka! This is the bit I was missing: that I can dynamically edit a task at runtime in LabView. I had been manually creating test tasks via MAX/test panel and then hadn't been able to figure out how to alter them in LV (I missed the VIs and then was trying to use property nodes and couldn't find a way to get there.) But with your help I knew what I was looking for had to be there and eventually found it.

Is this the right sequence of commands? This does seem to work, and obviously I'll wrap it up in some more abstraction for real use, but I just want to make sure I'm not missing something that will be a gotcha later.

Thanks again, I really appreciate the kick(s) in the right direction.

[Kevin_Price]

You've pretty much got it.  Let me show you an alternative below the way I'd do it and comment on the differences.  You might also want to look at the shipping examples (Help->Find Examples...).

1. I rarely call "DAQmx Create Task" at the beginning because I don't generally need to name my tasks.  It's optional and doesn't hurt if you want to leave it.

2. I demonstrated how to create 1 AO task that includes 4 AO channels (note the colon-based range syntax ao0:3).  You can easily select multiple channels if you click the drop-down arrow, then pick Browse...

3. I call DAQmx Start explicitly rather than use auto-start.  Sometimes it doesn't matter and auto-start can be a useful shortcut.  My habit is to stick with explicit control because there are times it allows more efficient operations.  The reason why relates to the DAQmx Task State Model, which is too much to get into right here.

4. Because I'm demonstrating a multi-channel task, when I write new voltage values I need to write them as an array with one element per channel.  They'll all update at once.   It would be typical if this call to DAQmx Write were the only DAQmx call you put in your main loop.  Everything else would happen before or after the loop.

5. Because I expect to update the voltage values, I want to keep the task running throughout my app.  I don't call "Wait Until Done" because I'm not going to react to this so-called done-ness.  (And for this kind of software-timed on-demand output task, the notion of "done" probably isn't going to be useful.  Not sure I've ever explored it.)

6.  At the tail end of things, I typically call DAQmx Stop explicitly before calling DAQmx Clear.  It often isn't necessary, more of a habit that I consider good practice.  (Also, certain kinds of task manipulations have me calling Stop and Start multiple times within an app, but calling Clear only once.  I've gotten used to thinking of them distinctly and calling Stop explicitly even when I might not need to.)

-Kevin P

[Overthere]

Hi Kevin - 

Thanks for the detailed breakdown. A few followup questions on this, if I may:

1. If I wanted to access this same channel or set of channels multiple times over a long running program, is there any disadvantage to using disposable, virtual/unnamed tasks as you've done here, as opposed to creating a task at the start and retaining a reference to it throughout? Essentially I'm wondering if I can just create a SubVI which is a self-contained version of what you're showing there which doesn't require me to carry references to the channels or tasks throughout the main program and can instead just be executed in a standalone way that cleans up after itself.

2. When calling start in this way - before defining the voltage you want to set - what state is the output in between the task start and the voltage setting? I'd like to just go measure this myself with a breakpoint but unfortunately my lab access is extremely limited with the current global situation and I can't get in again soon.

3. My thought with Wait Until Done was that it would hold up execution on that thread until the voltage had been confirmed set or settled by some internal mechanism. I need to ensure that my voltage is set before I take a follow-up measurement with another instrument. I can always just do this by polling the output or (yuck) by using a delay if there isn't a more direct approach.

4. What state is the output left in after calling Task Stop? Does it stay at the last setting, or return to zero, or get disconnected? This reflects back on question 1, since if stopping or cleaning up the task drops the voltage, then I obviously can't just dispose of tasks immediately after setting the voltage! Again, wish I could just go measure this one myself, but I cannot.

Thank you!

-OT

[crossrulz]

Analog outputs will remain at their last written value.  So you will want to explicitly set it to 0V before clearing the task.