Triggered Pulse train generation 6602

[Irena]

Hi!

I need to generate two different pulse trains with same trigger from PCI6602 card with simultaneous rise first pulses.

The problem is, that both of trains begins from low part of period, and it's impossible to get two simultaneous rise slopes(of first pulses). Train of higher frequency begins few periods before second train pulse rises. Changing of polarity of signals doesn't help.

[Kevin_Price]

Irena,

Can you post your code?  Otherwise I can only take a few guesses.

1. I looked up a couple of similar threads you were in and it appears you're using traditional NI-DAQ.  So starting with the instant that the active trigger edge comes in, both pulse trains start.  When they start, they will be in idle state first (Low by default), then go to pulse state (High by default).  The time spent in each state depends on the freq and duty cycle.  At the very lowest level, you can specify 'Pulse Spec 1' and 'Pulse Spec 2' using "Counter Set Attribute.vi", corresponding to time in idle state and time in pulse state respectively.

So, what frequencies do you need to generate?  And are the duty cycles important?  If your external devices respond only to, say, rising edges then you should be able to get the two pulse train's first rising edges in sync.  You would just need to be sure that they are configured with the same value for 'Pulse Spec 1' (time in idle state).  At least one of the output pulse trains will have to be non-square.

2. Can you switch to DAQmx?  It provides one additional pulse property called "Initial Delay" which specifies a special value for time spent in idle state used only for the very first pulse.  Under DAQmx, you could make both pulse trains square but set their "Initial Delay" values to be equal in order to line up their first rising edges.

-Kevin P.

[Irena]

Thanks, Kevin.

The duty cycles and the Frequencies are important.

The slow train is used like gate for fast signal.

In the Calculate Pulse Specs for Phase Delay.vi you can see that duty cycle and frequency are used to calculate the pulse width and delay of a pulse.

New train always begins from "Delay" - and it's different for different frequencies- this is my problem. Is the idle time this very first delay or it is the time before frequency output? 

There are no examples for counter to DAQmx- and i can't use it.

Irena.

[Kevin_Price]

Irena,

First I want to make sure I'm completely understanding you.  You wrote:

The slow train is used like gate for fast signal

Do you mean that the fast signal is only created during the "high time" of the slow signal?  Are you configuring this on the 6602 or using an external AND gate (or similar)?  If you have this configured properly on the 6602, you shouldn't see any of the fast pulses until after the first rising edge of the slow pulse train (or possibly simultaneously as described below).

If both counters are started before the trigger signal arrives, they should both be sitting in their idle state (Low by default) until the trigger arrives.  Then the slow pulse train will remain in idle state until the 'delay' time elapses.  It will then transition to its pulse state (High by default).

Now I'm not 100% sure how the gating is accomplished for the fast pulse train.  The result is like a logical AND of the slow pulse train output with either (a) the fast pulse train's internal Output signal or (b) the fast pulse train's input timebase Source signal.  I think it's (a) but don't really know.  If so, then the fast pulse train also begins generating an internal pulse train after the trigger.  However, that pulse train only passes through to the terminal block output pin when the Gate signal (from the slow pulse train) is High.  In such a case, the specific freq & duty cycles of the two pulse trains determine what phase the fast signal is in when the slow signal goes High.  If the fast signal happens to be in its pulse phase, then the two rising edges should indeed be simultaneous, though the first fast pulse will likely be shorter than the rest.  If it happens to be in its delay phase, the the fast signal's rising edge should come slightly AFTER the slow signal's rising edge.

I don't understand why the fast signal's pulses would show up before the slow ones'.  Unless there's an unhandled error when trying to configure for both level-gating and triggered start.  I think that combo should be allowed, but have never personally tried it.

New train always begins from "Delay" - and it's different for different frequencies- this is my problem. Is the idle time this very first delay or it is the time before frequency output?

True, for a fixed duty cycle, both the delay and pulse times vary with frequency.  If you were free to vary the duty cycle, you could make either delay or pulse time be constant with varying frequencies.  But apparently that's not an option.

Under traditional NI-DAQ, the "idle time" is the time spent in idle state for each and every cycle of the pulse train.  Only DAQmx allows you to specify a different one-time "initial delay."

There are no examples for counter to DAQmx- and i can't use it.

DAQmx counter examples CAN be installed from the driver CD and more can be found here on ni.com.  What is the reason you can't use it?  Do you have existing code working under traditional NI-DAQ?  If so, is that code addressed to other boards?  Because it would be fine to keep using trad NI-DAQ for calls to other boards while switching exclusively to DAQmx for the 6602...

-Kevin P.

[Irena]

Hi, Kevin!

1.

The slow train is used like gate for fast signal- for external user's device.

2.Here  are the pictures showes output signals: what have to be and what I get from Counter.

3. Code of my application - 3 frequences output - two equal frequncy with phase shift (I have done with your help) and third - the higher freguency synchronous with the first signal (may be in asynchrouns mode too).

4. May be I have to use another counter mode, not Triggered Pulse Generation?

Thanks

[Kevin_Price]

Irena,

I first want to be sure I understand *exactly* what you need.  Some parts may not quite work out, but I'm hopeful we can at least get real close.

1. When I look at the timing diagram you labeled "what I need", I see that both the slow and fast signals start in High state at the exact instant of the trigger's rising edge.  Further, you show that the fast signal is an exact integer multiple of the slow signal, so every rising edge of the slow signal will occur during a rising edge of the fast one.  The "gating" you mentioned earlier in the thread is done by the external device, so your program always puts the pulse trains out to the output pins.  Is this right so far?

This may be either easy or impossible.  If you were to set both fast and slow pulse train polarities to have a High delay and Low pulse, you could almost duplicate the timing diagram.  The only exception is that both counters would already be in in idle (High) state while waiting for the trigger.  So neither one would show a rising edge at the instant of the trigger.  Everything after that could match up.

If you need to generate those initial edges, I'm afraid I don't know of a way to do it.  The counters' pulses always start with the idle state before the pulse state, and in triggered mode they wait for the trigger in idle state too.  The earliest edge you can make is by defining a pulse with a very short idle state (duty cycle >99%).  However, I understand that's not really an option.

2. Again, how exactly does the external device respond to your pulsetrains?  Since you referred to "gating", I would suppose that it responds to the state (High or Low) of the slow signal(s) and doesn't particularly care about edges.  But what about the fast signal?  Does it react to rising edges?  Rising and falling?  Or is it also sensitive only to state?  If it only responds to state, then the inverse polarity mentioned earlier should work.

3. Sorry to pester, but why is it that you can't use DAQmx?  It's "initial delay" feature could make the difference between whether you can make this app work or not...

4. I'll try to look at your code when I can -- my network PC isn't near a LV PC.

5. Where does the trigger signal come from?  Is there any possibility of taking in that "real" trigger and generating a delayed trigger that is used by the rest of the system?  That may open up some more options...

-Kevin P.

Just as a note: if the slow signal's period is always an integer multiple of the fast signal's period, then the slow one wouldn't need to be triggered.

[Irena]

Hi, Kevin!

I am sorry for disturbing you.

The only exception is that both counters would already be in in idle (High) state while waiting for the trigger -it may work, but changing ouput polarity changes state before trigger to high too.

About the Task: All of 3 signals are outputs to user's device ("black box") , no inputs.

 If the slow signal's period is always an integer multiple of the fast signal's period, I have to check with customer -I don't know now.

2. All what i know - both signals must to rise simultaneously.

5. Trigger is one of PFI outputs, changed by SW, works properly.

3. About use DAQmx - i am not shure, how i can revert my code - I'll try that. Can I mix DAQmx and Traditional in the one application?

Thanks a lot 

Irena

[Otis]

Hi Irena,

There appears to be some confusion.  You seem to want to have several pulse trains that are triggered and output the first pulse at the exact same moment.  It seems to be that there is some worry because it is believed that the first pulse occurs after the first low time.  That is not the case.

After the trigger there is the Initial Delay of the pulse train, then the High Time, Low Time, High Time, Low Time...etc.  Your first pulse will be synchronized so there is nothing to worry about.  Below you can see exactly how it looks:


This behavior is definitely present when using the DAQmx drivers.  If you are still having problems using the Traditional DAQ drivers, then you should upgrade to the latest version of DAQmx (currently DAQmx 8.0).

Regards,

Message Edited by Otis on 11-10-2005 11:37 AM