Start a daqmx task multiple times

[Godeko]

Hello people!

In my project, Im using the 4 AO of the PCIe-6363 and the 2 AO of the USB-6002 to output 6 waveforms. To synchronize both DAQ-cards, the PCIe-6363 exports its start trigger to trigger the USB-6002. This works pretty fine and is shown in blockdiagram cut.png below. (The waveforms are rather difficult and the code very long. Thats why its not shown in the screenshot.)

Running the program leads to the calculation of the waveforms and then immediatly to their output.

Thats not what I want. I want the program to calculate the waveforms and output the waveforms once, whenever a button is pressed. This is where Im struggling with.

With a simple state machine around the 'Start Task'-daqmx I was able to control the start of the output, but just once (blockdiagram statemachine.png). A second press on the button after the first output doesnt start a second output.

Id be happy about any idea how to fix that.

Thank you!

[Kevin_Price]

First, you'd need the DAQmx Wait Until Done and DAQmx Stop functions *inside* the True case in your loop.   Second, it's important that the Boolean control has latching action so it automatically returns to its normal False state when it's read.

-Kevin P

[JÞB]

---

@Kevin_Price wrote:

First, you'd need the DAQmx Wait Until Done and DAQmx Stop functions *inside* the True case in your loop.   Second, it's important that the Boolean control has latching action so it automatically returns to its normal False state when it's read.

-Kevin P

---

Kevin...we had a thread some time ago that may be related.  I am not at a PC currently.   There may be an error where DAQmx Fails Silently to release a resource.

Would you mind digging through that for the OP?

[Kevin_Price]

I might try to look for that thread anyway but honestly, once you get a chance to look at the attachments, you'll see that this probably isn't a head-scratcher in need of a subtle solution.

-Kevin P

[Godeko]

---

@Kevin_Price wrote:

First, you'd need the DAQmx Wait Until Done and DAQmx Stop functions *inside* the True case in your loop.   Second, it's important that the Boolean control has latching action so it automatically returns to its normal False state when it's read.

-Kevin P

---

Thanks to all of you. I will try it in the lab on Monday.

Im still trying to understand the architecture of daqmx and would like to know, why 'Wait until done' and 'Stop' have to be within the case. Can you explain it me, please?

[Bob_Schor]

It would be so much easier for some of us (such as I) to help you if you attached your actual VI instead of a bunch of pictures of parts of VIs.  True, I might complain that the code is too "big" (doesn't fit on my laptop screen), I could at least inspect all of it, count edit it, could run it, could modify it, etc.

What you are proposing to do sounds simple.  Post your code so we can see where the problem lies.

Bob Schor

[cbutcher]

---

@Godeko wrote:

---

@Kevin_Price wrote:

First, you'd need the DAQmx Wait Until Done and DAQmx Stop functions *inside* the True case in your loop.   Second, it's important that the Boolean control has latching action so it automatically returns to its normal False state when it's read.

-Kevin P

---

Thanks to all of you. I will try it in the lab on Monday.

Im still trying to understand the architecture of daqmx and would like to know, why 'Wait until done' and 'Stop' have to be within the case. Can you explain it me, please?

---

As usual, Kevin_Price is right about all things DAQmx.

Some further steps that might help elucidate the problem could be:

• Add an error indicator inside your "state machine" to check any errors that occur on the second click
• Read about Retriggerable Tasks in NI-DAQmx
  • With regards to stopping and starting, check the available/supported devices carefully. Your 6363 is I think fine, but I doubt the 6002 is natively supported. Fortunately, the exported clock might get you around that problem if you allow regeneration (Analog Output Regeneration Modes in DAQ).
  • Edit: I wrote "the exported clock", but looking at your code I'm not sure that's what you're doing. Please see the 4th bullet point 🙂
• Consider how long it takes to "Start" a task. There are no other (visible) loop-rate limiting steps, so the loop will immediately go to the next iteration. What should happen if you click again before the tasks complete. Is there a VI/node that would allow you to slow the loop down until after the task finished writing?
• Upload the VI if you still have problems

[JÞB]

---

@Kevin_Price wrote:

I might try to look for that thread anyway but honestly, once you get a chance to look at the attachments, you'll see that this probably isn't a head-scratcher in need of a subtle solution.

-Kevin P

---

Quite Right!

Move the Write inside the True case.

You want to use a Finite Sample type of AO but that means, when you actually output the data the data is removed from the buffer inside the devices...Obvioulsy then, you need to put the data back into the buffer before you can generate the output again.

Also, The expert move here would be to DISABLE and Grey Out "Boolean" just before start task and use the "False" case to monitor if the Tasks are both complete (Use "Wait for Task To Complete.vis" with a realistic timeout like 200mSec ) and then re-enable the "Boolean" when the current generations are done. Bonus points if you realize that if the user clicks "Stop" the Tasks should be Aborted Immediately after the while loop.