Pulse train generation fails with certain values for "number of samples"

[eaolson]

I'm generating a retriggerable analog output signal, and so I'm using a counter as the sample clock (see: Retriggerable AI Using Retriggerable Counter). I am finding that, above a certain number of samples, and only for certain values of the number of samples, the counter task gives me error -200305, "Desired finite pulse train generation is not possibe." The error crops up only when actually starting the task.

The analog signal that I'm trying to generate will be about 800 kHz, so my counter is set to run at the same frequency. I find that the counter task works fine if the number of samples to generate is anywhere between zero and 671,088 samples. Setting the number of samples to 671,089 gives the error above, as does 671,090 samples and so on. However, using 671,096, the counter task works fine. After that, the counter seems to output fine only if the number of samples is divisible by 8.

The only thing I can think of is that (617088 samples) / (800000 Hz) = 0.839 s. At the internal clock rate of 20 MHz, 0.839 s is 2^24 samples, and it is a 24-bit counter on this hardware. So if it's this internal counter rolling over, that's fine and I can work around that. But if that's the case, what I don't understand is why increasing the number of samples in increments of 8 samples still works.

The hardware is a PXI-6733 board, running with LabView 7.1.1 and NI-DAQmx 8.1.

[Kevin_Price]

Internal count roll-over sure *sounds* like the most likely culprit.  My only guess about the multiples of 8 would be that DAQmx is getting smart behind your back. 

When requesting a duration that would take > 2^24 cycles of the 20 MHz timebase, perhaps it automatically chooses to use the 100 kHz timebase instead.  Then, it only allows durations that exactly fit into full periods of the 100 kHz timebase.  Since you're generating a 800 kHz pulsetrain, you get an exact fit only when the # samples is a multiple of 8.  Just a guess, but I've got myself mostly convinced.

If you really need >2^24 pulses, and have the # NOT be a multiple of 8, post back.  There *may* be some sneaky tricks if you do all your own manual counter configuration rather than leaving it up to DAQmx... 

-Kevin P.

[eaolson]

I considered the 100 kHz timebase idea, but that means that the board is outputting samples faster than the counter is updating. That doesn't seem to make sense.

It does seem to have something to do with the output frequency. Changing it from 800 kHz to 700 kHz means that the counter task will not start unless the number of samples is a multiple of 50. At 900 kHz, it has to be a multiple of 100.

[Kevin_Price]

Hmmm,  multiples of 50 & 100?  Now I'm puzzled again.

Here's how to make sense of the 100 kHz timebase idea though, even if it turns out not to be the right explanation.  For a retriggerable finite pulse train, you actually use a pair of counters.  If you were to program it manually, you could set your output counter to generate a continuous pulsetrain at 800 kHz using the internal 20 MHz timebase.  This output counter would also be configured to use the other counter's output as a digital level-based pause trigger.  So the 800 kHz pulsetrain is only output while the other counter's output is, say, high.

The other counter is configured for retriggerable pulse generation.  The pulse duration or high time should be set for (# pulses) / (800e3 pulses/sec).  This other counter can be configured to use the 100 kHz timebase, so its high time would then have to be an integer multiple of 10 usec.

So let's see...  An 800 kHz pulsetrain is possible with a 20 MHz timebase (exactly 25 cycles).  A 700 kHz (28 + 4/7 cycles) or 900 kHz (22 + 2/9 cycles) is not.  So when you request those other frequencies, you actually get a near approximation.  I dunno if DAQmx can be queried for the actual value correctly or not -- I recall an early version that reported back whatever freq you had asked for rather than what it actually used.  Queries based on ticks (rather than time or freq) did return what was actually used, as I recall.

Let's suppose a request for 700 kHz gets truncated to 28 cycles of the 20 MHz timebase making a 1.4 usec period.  Then 50 of those periods becomes 70 usec, which is evenly divisible by the 100 kHz timebase.  Bingo!  (Note: 70 is the least common multiple of 10 and 1.4)

Now suppose the request for 900 kHz turns into 22 cycles of the 20 MHz timebase, or a 1.1 usec period.  Now it takes 100 of those periods to get to 110 usec, which is also evenly divisible by the 100 kHz timebase.  Bingo again!  (Note: 110 is the lcm of 10 and 1.1).

Did you follow the method here?  It should help you figure out expected results for various output freqs and #'s of samples.

-Kevin P.

[eaolson]

Ah-ha! I guess I had implicitly assumed the two counters had to be using the same timebase. Every time I checked to see what timebase rate was being used (Channel Property Node) it came back with 20 MHz. There doesn't seem to be a way to query the timebase for the other counter.

So the first counter is counting the appropriate number ticks of the 20 MHz timebase (25, for 800 kHz) so that it counts at the specified rate. The second counter is gating the first counter. If the total duration of the counter output task is greater than 0.83 s (2^24 counts @ 20 MHz), the second counter will switch to the 100 kHz timebase. The counter task can not end mid-tick on the 100 kHz timebase.  So the task must have a number of samples such that the counter output, which is at a rate of 20 MHz/(some integer), and the 100 kHz timebase have an edge at the same time.


Things make so much more sense when you know what's going on.  Thanks.

[reddog]

Kevin and eaolson, you're exactly right in what's going on.  When the second counter used for gating the continuous pulse train needs to move to the 100 kHz timebase to satisfy the total time for the finite number of pulses, it requires that the period * the number of pulses falls on an exact interval of the 100 kHz timebase.  Actually, it may be a bit more complicated than that because of the initial delay, but you get the idea.  Anyway, I wanted to mention that if this is too much of a pain to deal with, you could try to use event counting on the second counter to gate the continuous pulse train counter.  I haven't actually implemented this, but in theory it seems like it should work.  The idea is similar to how things work now, but instead of using the internal timebase to generate the gating pulse, use the output of the other counter as your timebase.  Then configure the high ticks of the generated pulse to be the number of pulses you want to generate in the finite pulse train.  The pause trigger for the continuous pulse train then becomes the output of the gating counter.  You may have to play with the idle state of the gating counter and polarity of the pause trigger to get things to work exactly right, but this should allow you to generate 2^24 pulses at any arbitrary frequency.  Again, I haven't tried this in practice so you might run into something where this approach blows up, but on paper it sounds good.

[gpho]

Hi,

I'm encountering a similar error when trying to use a counter output. I'm fairly new to Labview and counter-timers, so hopefully someone can help explain this thread to me. For my application, I want to generate "packets" of pulses that constitute a pulse train, with a user-controlled "burst on" time, "burst off" time, and frequency. To do this, I placed the finite counter output code in a for loop, with the initial delay corresponding to the "burst off" time. The problem occurs when I try to use an initial delay of less than 0.839 seconds. Error -200305 comes up, "Desired finite pulse train generation is not possible," and after trying to understand this thread, I know it has something to do with the sampling rate.

What do I need to do to eliminate this error? I am using a SC-2345 board with a SCC-FT01 in the counter-timer port, with Labview 7.1 and NI-DAQmx. I have my two basic VIs attached, largely based off of the example VIs that came with my version of Labview.

Thanks for your help,
Gerald

[TheWoost]

Hi Gerald,

It looks like for certain values of the intitial delay the default timebase of the counter output is too high.  You can explicity set the timebase to use with the DAQmx Channel Property Node.  The specific property is in Counter Output>>General Properties>>Counter Timebase>>Source.  Upon selecting this property you can right click on it, select "Change All to Write", and then wire a constant into the input.  You might have to go down to the 100kHz timebase, and to access this in the constant you can right click on the constant and select "I/O Name Filtering".  In the Filter Names window that comes up make sure the box is selected for "Include Advanced Terminals":



Regards,
Andrew W
National Instruments

Message Edited by TheWoost on 05-17-2007 03:17 PM