PCI-6602 Initial Delay

[_Bryan]

Hello,

Currently I use the code below to run the counters at a fixed frequency/duty cycle.  After the first counter fires the rest of the counters take their turn firing using the inital delay terminal on the create channel vi.  It works good and keeps them all from firing at once.

Now, I need to change the frequency/duty cycle once a second for 70 seconds (a table of 70 different points) and then repeat until I want to stop.  I am able to do that with no problems.

My problem is setting my initial delay every second based on my frequency to keep a nice ripple effect.  In order to set the initial delay I have to stop the task.  Is there another way to keep the counters evenly spaced out (a nice ripple) dependent on frequency without stopping the task?

[Kevin_Price]

First let's see whether there's a way to do this *without* stopping, reprogramming, and restarting the slave counters.

What characteristics of the pulse train are important to your app?  Is it only the relative timing of rising edges?  Or are the one/off durations of the pulse train also important?

How critical is the timing among pulse trains?  What are you testing/evaluating?

-Kevin P

[_Bryan]

We have a CNG injector durability test rig that this is running on currently.  We do not fire all of the injectors at the same time because it causes pressure drops in the system and spikes the power supply (current).  So by staggering the start of the pulse train it evens out the pressure drops and helps with current requirements on the power supply.

[Kevin_Price · Accepted solution]

I'm supposing that your need to stagger the "firing" of the injectors means that you're concerned with the timing of the pulses' active edges.  Whether they are active rising or falling may not be particularly relevant if we can simply make them very short duration.

1. I'd start by suggesting you figure out the max reasonable freq you'll ever need to accomodate, and then plan to stagger the firings across that same interval of time even when you operate at a slower freq.  This will simplify things considerably.

2. Configure all your slave counters to be retriggerable (as you're already doing), but REMOVE the call to DAQmx Timing.vi   They will all then be retriggerable single pulse generators.  Continue to have them triggered by CTR0, the master clock.

3. Program the slaves in terms of Low Time / High Time.  Assuming an idle state that's Low (the default if I recall correctly),  set each "initial delay" equal to that counters' unique "low time" and set the minimum "high time" your system can accomodate. 

   Note:  unless the behavior has changed in more recent versions of DAQmx, the "initial delay" value is used after the 1st trigger while the "low time" value is used for all subsequent triggers.  Don't ask *me* why, but NI folks have weighed in on this in prior threads, calling it "expected behavior".   Expected by exactly whom is what I wonder.  I've yet to see a single comment saying, "Yeah, great, that's just how I *wanted* it to behave."   ANYWAY...

4. Start all your slave counters before starting the master.

5. The freq of the master counter can be changed on-the-fly without stopping and reprogramming it.  All the slave counters will continue to fire one single pulse per active edge of the master.

6.*  Speculative idea, I haven't verified this.  You can *probably* update the low time / high time pairs of the slave counters on-the-fly as well.  If so, this will let you spread the "ripple" across more of the available interval when operating at lower speeds.  It sounds like your app can live with the possibility that these slave timing updates may not occur within the same master pulse cycle.

-Kevin P

[_Bryan]

Thanks for the options you listed.  I was just talking with my boss before this email and told him I would try the same as your #1 idea and just see how it works.  If it doesn't I will look into your other ideas.

Thanks again