Digital I/O

cancel
Showing results for 
Search instead for 
Did you mean: 

100kHz Variable Digital Output Pulse Train

Solved!
Go to solution
Highlighted

I have to output what amounts to a Finite Non-Repeating (Variable) Digital Output Pulse with 61 Million points at 100kHz. I imagine I can't use the Finite Samples timing method but rather have to use Continuous Timing and constantly read the data from a file and update the output buffer with DAQ Write.  Unfortunately I don't have any physical hardware at this point and am using simulated DAQ (through max) to experiment to see if any approach is viable. 

 

Digital Output Example.png

 

 

I was thinking of continuously reading the pulse train from a file and writing it to a Digital Output task 10k - points every 100ms to update the DAQ output on the fly (as shown in the attached VI).   This seems to work in the simulated device, but then I noticed the onboard digital output buffers of most of NI hardware are only around 2047 samples making me wonder if I can even send 10k+ points at a time to the hardware without data loss.

 

My questions at this point are:

Is this viable approach? or will the small (2047) output buffer mean that I will have to update much faster eg ~ every 20ms (prob not possible on windows)?

Should I consider using a counter output where I continuously write high/low times since I have a relatively small number of transitions in each 100ms chunk?

 

 

0 Kudos
Message 1 of 9
(268 Views)
Highlighted

What device(s) are available for you to use?  If you haven't selected DAQ hardware yet, I'd recommend you look into a desktop (or PXI) X-series MIO board -- they provide a lot of capability and flexibility.

 

I don't know the entire pattern you need to generate, but from the limited info shown:

 

1. You could *very likely* generate this pattern using a Counter output task, specifically a buffered finite pulse train.  You only have to define the times when the rising and falling edges occur, so that'd only be 24 samples in the 0.1 second screenshot you showed, rather than the 10000 samples you'd need with a Digital output task.  (X-series were the first to support buffered pulse train output.)

 

2. If the bursts of pulses repeat at fixed time intervals, you might also be able to do this by pairing up 2 counter tasks.  One would be a retriggerable finite pulse train, where each trigger makes it fire off the 6-pulse burst that appeared twice in your screenshot.  (This would not need to be a buffered pulse train, so older DAQ devices might still support this method.)  The other task would be a pulse train that acts as the triggering signal for the first task.

 

 

-Kevin P

0 Kudos
Message 2 of 9
(249 Views)
Highlighted

We can purchase a new device but I'd prefer to limit it to X series USB devices or lower.  Don't want to tumble down the PXI cha$$is rabbit hole.  You asked about the entire pattern...the example .bin file has about half of the pattern I need to output (posting limits prevented me from uploading the full file).

 

I like the approach of (1) you mentioned. I tinkered with that in simulation but didn't get a very good feeling when I tried finite because the task seemed to end ~ 1secs no matter what high time and low time values I loaded into the buffer ....maybe that's just a result of using the simulated DAQ driver.  Will buffering still be an issue for the finite task if I need to run pulse data for 60s or so (24 samples x 10 = 240 samples / sec or 60*240 = 14400 samples > 2047 buffer size?  Could a continuous counter output work.

 

2) unfortunately the bursts are not repeated at fixed intervals but shift in time (we're gating a laser pulse to simulate movement / changing TOF)

 

Do you think the digital continuous buffered read from file approach I attached is not viable though?

 

Thanks for the quick response

0 Kudos
Message 3 of 9
(237 Views)
Highlighted
Solution
Accepted by bean123

1. First, be sure you understand that there are a few performance compromises you'll get with a USB device compared with a desktop board.  You can do a lot with the USB version and many people will never really run into the limitations, but they *do* exist.

   The most common limitations are typically about either bandwidth or latency.   USB simply isn't capable of delivering as many MB/sec as a PCIe card.  But it *can* deliver enough for the needs of most users & apps.

   Latency is a fuzzier issue, but in general I'd say that if you're looking to generate output immediately in response to inputs, USB will limit how your "immediateness" both in terms of speed and consistency.

   (I wouldn't suggest PXI unless that was the platform you were already working with.  It's great functionally, but can be tough on the budget.)

 

2. Buffers get misunderstood quite a bit.  The 2047 sample buffer size you're talking about is in the hardware of the board, sometimes referred to as the onboard FIFO.  DAQmx will *also* make a task buffer using your PC's system RAM.  And then the DAQmx driver does a very good job of moving data between the PC's task buffer and the devices hardware FIFO.

   When you call DAQmx Write, you're literally writing to the task buffer, and it can be big - 10's of MB easily, even 100's of MB can be possible.  DAQmx will then work to move that data in bits and pieces across your bus connection (PCIe, USB, LAN, PXI, whatever) to keep the board's hardware FIFO from running empty.

   Take this as background before the next section.

 

3. I think you *can* expect to be able to accomplish this with your original DO task at 100 kHz sample rate.  And since you already have your pattern defined in a file in terms that translate easily to DO, you may as well stick with your original DO approach until or unless you run into a roadblock.

   A counter-based approach requires many fewer samples, and allows finer timing resolution for where you place your pulse edges.  Worth knowing about for possible future mods, but probably not immediately necessary.

 

 

-Kevin P

Message 4 of 9
(223 Views)
Highlighted

Thanks for the detailed response....particularly about the DAQmx buffers.  I couldn't find detail like that anywhere on the NI website or LabVIEW help (might be looking in the wrong places). 

I think I will probably migrate my solution to CTR output approach you mentioned in item 3.  That seems like the best thing to do to reduce the size/freq of updating the buffers and CPU/USB load.  A few more questions regarding the CTR output approach:

 

  1. Can I just front load the entire high/low array (if it exceeds 2047 pts) into a DAQ write of a finite sample CO Pulse Generation task prior to the DAQ Start and just monitor the task done in a loop to see when its finished?  Based on your descriptions of the buffers/buffered pulse train it seems like it may be possible with the X-series USB or PXI cards.
  2. Does the finite sample CO Pulse Time Gen approach in 1 require a DAQ card with buffered pulse train (X-series) like the Digital Output task discussed in the earlier posts or can I use a lower grade DAQ card since it uses a counter (vs DO task)?
  3. If I need to use a continuous sample mode (vs finite) bc 1 or 2 won't work for 60 secs of data, I have the same question re whether I could just use a lower level DAQ card and update the high/low times on the fly based on your desc of the DAQmx software buffering.

I'll try to throw together 2 code examples for finite and continuous sample modes and post them when I get a chance.

Thanks again.

0 Kudos
Message 5 of 9
(194 Views)
Highlighted

Responses inline in red.

  1. Can I just front load the entire high/low array (if it exceeds 2047 pts) into a DAQ write of a finite sample CO Pulse Generation task prior to the DAQ Start and just monitor the task done in a loop to see when its finished?  Based on your descriptions of the buffers/buffered pulse train it seems like it may be possible with the X-series USB or PXI cards.  Yes.  The task buffer can be much bigger than the board's hardware buffer.  You can write your entire waveform / pattern to it all it once and then let the DAQmx driver work behind the scenes to keep delivering your data to the board.
  2. Does the finite sample CO Pulse Time Gen approach in 1 require a DAQ card with buffered pulse train (X-series) like the Digital Output task discussed in the earlier posts or can I use a lower grade DAQ card since it uses a counter (vs DO task)?  Buffered pulse train generation requires the STC3 timing chip which was introduced with the X-series boards.  Older and lower-grade boards won't support it.  (Many older and lower grade boards might also not support the DO approach.)
  3. If I need to use a continuous sample mode (vs finite) bc 1 or 2 won't work for 60 secs of data, I have the same question re whether I could just use a lower level DAQ card and update the high/low times on the fly based on your desc of the DAQmx software buffering.  In general it depends.  For your particular case, based on your screenshots, I doubt it.   NI's counters have long supported the possibility of changing pulse parameters on  the fly.  However, it's based on a software call, so you can't make it happen with hardware-timing precision.  You can't really control exactly how many pulses you get at each frequency, or exactly when the change-over occurs.   That's what made buffered pulse train generation such a sought-after feature by yours truly almost 20 years ago, back in the days of the legacy driver.

 

-Kevin P

 

0 Kudos
Message 6 of 9
(192 Views)
Highlighted

Thank you.  I've attached a rough VI based (hacked off of example code) and i converted my digital data to a high low time array.  I have about 72,000 high low transitions or 600+secs of time (order of magnitude higher than I originally thought 🙄). 

 

Do you see any issue with the code or array size if I use an X-series daq device?

 

0 Kudos
Message 7 of 9
(172 Views)
Highlighted

Nothing much jumps out except you probably need to wire up the 'samples per channel' input for DAQmx Timing.  It should be the size of your pulse data array.

 

Since you're doing Finite sampling and writing all the data at once, you probably don't need to explicitly disable regeneration, though it also probably won't be a problem.

 

Otherwise I'd expect it to work, and it does at least run without error on a simulated X-series device.  That's a good sign that there aren't major discrepancies between what you're attempting and what the device is capable of doing.

 

 

-Kevin P

0 Kudos
Message 8 of 9
(160 Views)
Highlighted

I ran the code on real hardware attached to a scope and it appears to work.  Still need to validate the pulses are the right timing but it seems functional at this point.

0 Kudos
Message 9 of 9
(107 Views)