Going by the screenshot -- I'm on LV2020 and can't open the code itself.
Overall things look pretty good, but I have a few comments and suggested changes.
1. Your 0 initial delay isn't actually possible. DAQmx will silently coerce that to be the smallest allowable pulse interval time of 2 timebase cycles (20 nanosec on your device). So you may need to bump the other ones by this amount to keep their relative timing.
2. You may also find that down at the nanosecond level, there are also signal propagation effects that will give you some uncertainty and error in this relative timing when you look carefully on a scope. Just so you know.
3. Most of my NI counter knowledge was learned "in the trenches" many years ago. Go back far enough and one could not create a single counter task with multiple channels of output. Go back a little less and you could configure them that way on *some* devices, but they would not start truly simultaneously. I simply don't know if that's changed in the meantime.
Fortunately, you've set up triggering which *can* start them in sync. But there's another change you'll need to assure that.
4. Start your multi-counter task *before* starting your AO task. That ensures that they're all armed and ready when the AO start trigger is asserted.
5. Since your AO task allows regeneration, there's no need to keep writing to the task inside the loop. Just write an integer # of full sine wave cycles to the task before you start it. Given your sample rate of 10 kHz and your desired sine wave frequency of 350 Hz, I'm fairly doubtful your Express VI is doing that.
I'd recommend an integer much greater than 1. The driver will be repeatedly delivering chunks of the data you wrote down to the board, and continually wrapping around and repeating the process. Making the buffer bigger allows the driver to deliver bigger chunks at a time, helping shield you against PC and OS timing uncertainties that may starve the driver of CPU temporarily. Offhand, I'd probably go big and write a full second worth of data to the task. That's likely overkill, but in the big scheme of things it's not much memory to sacrifice for the sake of much greater robustness.
There can also be an option to regenerate using *only* the device's onboard buffer. If you were to go this route, 1 full sine wave would be enough to write and the hardware would take over from there.
6. Once you eliminate the need to keep writing to the AO task inside the loop, all you're doing is waiting for a user-requested stop or a task error. You don't need 2 loops with 2 separate stop buttons, put 2 "task done" queries into 1 common loop with just 1 stop button.
7. There's no need to spin the query loop so fast with a 0 msec wait. I would typically go with 100-200 msec. (And in fact, I found sometime in the past that "task done" queries themselves can be surprisingly slow to execute, to the tune of 15+ msec. Dunno how universal that finding is.)
8. Don't stay blind to errors. At the end of your task chains, send the final error outs to a front panel indicator or an error dialog (or both).
-Kevin P
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
