Delay when changing Counter Output Rate on the Fly

[Jan_Nielsen]

Hej, I have a cDAQ-9178 chassis with a 9472 output module, and LabView 8.2.

I want to generate a continuous pulse train, and change the low and high times on the fly. I do this with DAQmx, by waiting for co.RdyForNewVal to be true, and then change co.Pulse.LowTime (or .HighTime). I can read the .LowTime and .HighTime values and see, that they are updated when a pulse cycle (High+Low) has been completed. This is OK.

However I have the problem, that after eg. LowTime has been changed, the board will output some 2 or 3 pulse cycles with the old values. That is, the values are updated in the counter when the current cycle is completed, but after this the old values are used for 2-3 cycles, which gives a significant delay. Is there some kind of buffer that needs to be cleared, or does anyone know how I can ensure that the new values are used immediately ?

Thanks, Jan

[Kevin_Price]

This is a speculative answer because I have no specific experience with the 9472 or cDAQ.

With PCI boards, I know that I needed to be aware of a little quirk when changing pulse specs on the fly.  Pulses are speced with pairs of values, whether they be freq/duty cycle, or high time/low time.  It turns out that if you update those values via property node, only one of the pair causes a "commit" to occur.  (This may possibly have changed in a later version of DAQmx than about 8.3 or so -- I haven't investigated since then.)

One common usage for changing pulse specs on-the-fly is to generate a variable PWM signal.  Often, this entails generating a constant frequency with a variable duty cycle.  Unfortunately, changing only the duty cycle property didn't cause the change to "commit" to the hardware -- it only changed after re-writing the same constant value to the freq property.

So maybe, just maybe, LowTime also doesn't cause an immediate commit.  Try writing both HighTime *and* LowTime to see if you get a different behavior.

Another work around that was suggested was to change the specs using the DAQmx Write.vi rather than a property node.  My recollection is that my particular app didn't allow for this -- DAQmx Write produced errors while the property nodes functioned ok.

Final caveat: I was updating a fairly high freq pulse train and never investigated the immediacy of the update.  It seemed to be "visually instantaneous", but I couldn't vouch for any further detail than that.

-Kevin P

[Jan_Nielsen]

Hej Kevin and thanks for your inputs.

Unfortunately, the first idea of writing a pair (in this case: high/low) makes no difference. The values in the counter are updated by the end of the cycle, but the old values will be used for 2 or 3 cycles.

I don't understand how to use a DAQmx Write - of course I could control the output directly instead of using the counter, but this would put a heavy load on the processor, and be unstable. I need to produce pulses with a fixed high time of 5 ms and a variable low time in the range from 150 ms to a few seconds. So I very much prefer do let the cDAQ do the exact timing in the background. As far as I know, there is no way to address the HighTime / LowTime registers via DAQmx Write ?

[KyleBryson]

Hi Jan,

>  after eg. LowTime has been changed

> the old values are used for 2-3 cycles, which gives a significant delay

How are you measuring how long it takes to update?  At what point do you consider that the LowTime has changed?  The USB bus and the software driver have some latency that will cause some delay in the update.

Regards,

Kyle

[Jan_Nielsen]

Hej,

it's easy to measure, the 9472 has green LEDs so I simply watch those. Remember that I work with low frequencies.

Besides watching the LEDs, I read the LowTime property so I can see when it is updated.

Note that the problem is NOT the delay before the property is changed, but the 2-3 cycles that are then output with the old values.

BR, Jan

[John_P1]

Hi Jan,

If the update to the counter output is coming from a software-defined input then there is not going to be a good way to immediately change the parameters (as has been said before, the bus and driver latency prevent the update from occurring immediately).  Out of curiosity, what are the frequencies of the pulses that you are outputting?  This behavior may or may not be expected depending on how long the update is taking.

I'm not sure if this will be helpful to your or not, but one thing to keep in mind is that the 9178 uses the STC 3 chip which provides for buffered counter outputs.  If you have a hardware-defined signal that you want to use to change the counter, you can get deterministic changes on the very next period of your counter output.  Page 56 of the 9178 Manual has information about Sample-Clocked Counter Output Tasks.  In this configuration, the external TTL signal can be used as a sample clock to change between counter output characteristics in a deterministic manner.  In this case, the array of counter output characteristics would be pre-written to the on-board FIFO of the 9178.

So to summarize, if you have a hardware signal that needs to change the output characteristics, you can use the new buffered counter functionality of the 9178.  If you need a user-generated button click (e.g.) to update the counter then there is not going to be a good way to change the frequencies immediately on-the-fly.

However, I would like to know more information about how you are updating the counter outputs and what frequency the counters are generating.  Depending on the rates, the latency sounds like it might be higher than expected and will require some investigation on our part.

Best Regards,