I am attempting to output a pulse train N times, then have a user defined wait, then output N pulses again, with this repeating until the user stops. I am trying to do this on two separate physical channels (PFI10 and PFI11). In the attached VI, I have connected the wait through the error handle, however I have also tried using a flat sequence structure to control the task and attempt to force to wait. The problem is, the path with the finite samples is only executing once and the path with the continuous samples is not waiting. Therefore the wait is never working. I realise there are multiple posts on the forum with others trying to do this, however I was not able to solve my problem reading those.
I am using LabView 19 and the hardware I am using is a PXIe-6361 connected to a BNC-2110
Despite using NI Multifunction devices for years, I'd mostly done analog stuff (A/D, primarily) and used the Timing units only for clocking my A/D. I had no idea how Counter/Timers worked, and managed to make a mess of it until a colleague clued me in. I still don't understand it well enough to explain it, but I can tell you the Main Principle (which my Counter/Timer Mentor taught me): to create a Digital Pulse Train, you must use Counter/Timers in pairs, with one of them acting as a "trigger" to delay the first edge of the Pulse, and the other as the "Pulse Generator", timing how long the Pulse is "on" (or "off", depending on whether you start Low or High). So if you have 4 Counter/Timers, you want to use ctr0/ctr1 (with the two associated PFI lines) for what I called "Trigger" and "Pulse" times, and ctr2/ctr3 for the other Pulse. As I recall, once I started the DAQmx sequence going, I simply "counted" (in a While or For loop) the pulses until I got the number I wanted.
We've since moved on to doing this with RIO devices, and six months ago, I started looking at FPGAs. Wow, how arcane and almost archaic! But also how much simpler and more direct, once you get over the shock of doing everything at such a low level. For digital timing, FPGA has a lot going for itself ...
Your description of what you want and the code you posted do not really reside in the same neighborhood.
1. To output N pulses, you simply configure DAQmx Timing for Finite Sampling, N samples, and "Implicit" timing. Then wait for the task to run to completion (DAQmx Wait Until Done.) There's no need to keep writing pulse parameters every 5 msec in a loop!
2. In fact, such attempts to rewrite are probably producing an error, but your code pays no attention to any such errors.
3. You have one task configured for Finite Sampling, the other for Continuous. Finite makes more sense if you have a specific # of pulses you want to generate.
4. I see no sign of any code related to a user-defined delay after generating N pulses.
Here's a quick look at what your loop might look like for 1 of your pulse trains:
Thanks Kevin for your help!! I have changed my block diagram based on your suggestions and have attached my VI. I have a wait time being implemented now but it is not as specified. When specifying 10 ms it is waiting 12 ms. Then I specified 8 ms and it is waiting 11.6 ms. I then specified 5 ms and it waited 7.6 ms. Then I specified 7 ms and it waited 9.6 ms. It also appears as though the wait timing is different at different parts of the pulse train. I have attached an image of the oscilloscope measuring 8 ms and 8.6 ms at different areas of the train when I input a 6 ms delay. any help on the timing is appreciated!
which number of pulses and which wait interval are we talking about?
From your images both requirements seem to be rather low, so have you tried to use a simple digital output with a predefined boolean waveform? This way you can easily generate the number of pulses with an arbitrary length of "no pulse" interval…
There are several ways to do this with precise hardware timing (most of which would require you to know *all* the user-specified delays ahead of time), and one semi-advanced technique that can reduce the overhead in your present software-timed approach (though it can't guarantee *consistency*, which is limited by Windows).
So what are your timing requirements? What kind of pulse rates, how many pulses, how long are the user dwells, how precise and consistent must they be? Etc. Remember, requirements are the *must*-haves, without which your app cannot be successful. You can also identify some further "wishlist" preferences.
Strict timing requirements will end up pointing to a hardware-based solution, but I'm not sure yet whether you *need* tighter timing or merely *want* it.
Another important piece of information is to describe the behavior of the system when the user changes the delay time. If you're doing 10 pulses then 20 ms, and want to switch to 10 pulses then 15 ms, can the system simply stop generating pulses for 100 ms or so, then start back doing it again with the 10/15 timing? Or does it need to be 10 pulses exactly, then 20 ms exactly, then 10 pulses exactly, then 15 ms exactly... until the user changes it again?