Buffered DO Question - when to update...

[Jed_Davidow]

Hi all,

I haven't done any buffered DO on a multifunction card with DAQmx (I think I did some A LONG TIME AGO on traditional DAQ).

I have to generate a set of 4 PWM signals, controlling phase, DC, etc.  Kinda like a set of stepper control signals, but just different enough that I can't actually use a stepper driver.

In general, I will be generating a pattern and then repeating that pattern constantly, either for a number of data points or indefinitely.

Every so often, I will need to change the pattern on user demand, but when I do there will be one "frame" of buffer sent with the transition data, and then I will be sending a different, but repeated pattern constantly.

So let's say I have 10K point "patterns" defined...

AAAAAAAAAABCCCCCCCDAAAAAAAAAABCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCDAA

1) Would I need to constantly regenerate and feed the buffer with those repeating patterns?

2) Is there some way to have the card repeatedly write the last patter?  Say I define the buffer as 20k points, and tell it that if there is no new buffer, just repeat the last 10k points of the buffer?  Sort of a self-feed of that last 10k?  And then when I send new data, it finishes buffering out the current 10k buffer before it moves on to the new data?

Thanks!

[Kevin_Price]

I've been meaning to test this kind of thing out myself for a while now.  My expectation has long been that if you allow regeneration then the task doesn't want you to break in and write new data to the buffer.  If you don't allow regeneration, but want to repeat a pattern for a long time, you'd have to keep re-feeding it chunks of that same pattern over and over and over.

So I just tried out some fairly simple tests by modifying a shipping example for continuous DO and running it on a X-series board (that can make its own sample clock for DIO).

To be honest, I haven't yet made sense of some of what I've observed.  Thus far, I haven't found a reasonable way to:

1. generally allow repeated regeneration without re-feeding the buffer

2. but then also briefly break in to feed new data for a while

3. and when I stop feeding data, have the task revert to regenerating whatever new data occupied the buffer when I stopped feeding it.

I haven't worked at it real hard or real systematically and I'm wrapping up for the night.  Signs aren't encouraging though.

-Kevin P

P.S.  Hmmm, some of the problem is that I'm testing with a very small buffer and slow sample rate.  My device seems to want to accept Writes as fast as I can iterate until the *onboard* buffer gets filled.  Some of the stuff I found inexplicable might be explic'ed by this double-buffering.

   I'd like to experiment in a mode where the onboard memory usage was 1:1 with the task buffer, but I haven't found a way to configure that.  And it's getting to be a long day....

-Kevin P