Advance apologies for things I may have missed while skimming quickly through the thread. I want to take a few steps back because if I understand your app's needs, this is going to be considerably harder than you may think.
My assumptions:
1. You are measuring the freq of an incoming ~400 Hz signal.
2. In response to the actual measured freq, you want to adjust the phase shift of 8 pulse trains, and you want to put that new shift into effect ASAP (within a cycle or two of the 400 Hz signal?).
3. You want to do this using DIO on the 6251.
4. All 8 of your output pulse trains should have a freq of ~400 Hz, a 95% duty cycle, and individually adjustable phase shift from the input.
Problems:
1. Timed DIO requires you to fill a buffer of data representing the pulse trains.
2. Each time you calc a new phase shift that requires a change to the DIO data, you'll need to write new data to the buffer. HOWEVER, it will not be generated until after all the old data has been generated.
3. So you're setting up a race where things are at cross purposes. To minimize delay, you'd like to write only a sample or two at a time into the buffer. However, that makes you *very* vulnerable to buffer underrun, a DAQmx error that will end your DIO generation task.
4. And this doesn't even approach the nightmare of trying to make the phase shifts of 8 DIO bits individually adjustable. There would be a *lot* of bookkeeping to manage to keep track of what the freq was on the last write, how much of each of the 8 pulses' cycles were written on the prev update, how much is left to write to finish their interrupted cycle (which will depend on both the prev and current freq measurements), etc. Yikes!
In short, the 6251 isn't particularly suitable for this job. I would give *very* serious consideration to a 6602 card with 8 on-board counters. If you can get one, here's some thoughts on how to proceed:
1. If possible, I'd try to do this by setting up the 8 outputs as retriggerable single pulses. Also, rather than 95% ON time, I'd make them have 5% ON time with their output polarity inverted.
2. After measuring the input freq (using a counter on the 6251), you can calculate the correct low time and high time for each of your 8 pulse tasks.
3. You'll need to query each task to see if it's ready to accept new pulse specs before trying to write them. Odds are, you'll find that you can change the pulse specs no more often than once every two cycles. That's because by the time you measure the freq of cycle N, you are actually already inside cycle N+1 and each pulse task has already been triggered to generate an inverted 5% ON pulse somewhere within cycle N+1. If you are allowed to write new specs to a given pulse task during cycle N+1, they won't be used until cycle N+2. When you are in cycle N+2, you'll have just measured the freq of cycle N+1. However, you won't be even be allowed to write new pulse specs until after the cycle N+2 pulse is generated. So you won't be allowed to write the new specs until cycle N+3 and they won't be used until cycle N+4.
-Kevin P
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
