Arbitrary pulse train with fast-varying frequency and duty cycle

[ReklawLeinad]

Hello! I'm using a PCIe-6363 in order to control a system using a pulse train fed out through a digital output. The pulse train is about 2-minutes in duration, and we have managed to simplify it to frequency and duty cycle (f/DC) pairs that change once every 200ms. We have managed to get this working using a software-timed loop, shown below. There is a slight discontinuity when it updates because it has to finish the current pulse before switching the f/DC, but that's acceptable for our purposes. 

However, while this works in a vacuum, I don't think we can rely on this process being software-timed in the context of the larger code, which itself is quite complex. Ideally, we would use the counters on the PCIe card to control this change in frequency and duty cycle. One example in particular I was looking at is buffered pulse train generation. If I understand correctly, you send and array of f/DC pairs to the card and let it do its thing while the software can focus on other tasks. This is perfect in theory, but each f/DC pair seems to correspond only to a single pulse. If we were, for example, running at an average of 200Hz, we would have to feed 28,000 f/DC pairs into the card which I don't believe it is capable of, and is quite wasteful given that it would only actually change the f/DC every 200ms. 
Is there any more examples that you think would be suitable for this application? Is the card itself able to handle this, and how would be best to approach it?

[Kevin_Price · Accepted solution]

Two options:

1. Sample-clock based buffered pulse output.   You'll need to use a 2nd counter to generate a 5 Hz pulse train that your *main* counter will use as its sample clock.  I haven't tried this mode myself, so I'm unsure of the behavior when a sample clock arrives somewhere in the middle of a pulse (as it almost always will).  You probably also need to define pulses that are at least 2x the sample rate to make sure you generate at least one pulse from each element in your buffer of specs before advancing to the next one.

    You can test this out pretty easily with 2 of the shipping examples for counter output.

2. Continue with Implicit timing with a great big buffer full of all your pulses for 2 minutes.  DAQmx can *easily* handle a buffer of 28k pairs.  28M pairs would be fine for that matter, unless you had really badly fragmented memory usage.  (You write these pairs to a task buffer that lives on the PC.  In the background, DAQmx manages the process of delivering them down to the board as needed.  The board has its own smaller buffer, but that doesn't constrain the size of the task buffer you can define on the PC).

    You'll need more mods to the shipping example to try this out -- mainly to calculate all the pulse specs for the task buffer.

-Kevin P

[ReklawLeinad]

Hi Kevin,

Thanks for replying. I'll test the two options out and let you know if it works! I was under the impression that the buffer was stored on the DAQ card, but that seems easy enough to do if it's stored on the PC.

[ReklawLeinad]

Hi Kevin,

I ended up giving option 2 a whirl, and it worked perfectly. I don't know how I got confused about where the buffered data was stored, but thanks for clearing that up!