Re : Re: Re : Re: Start a counter from a trigger

[c.r.]

Hello,
  I've a 6023E
I'd like to :
    1) detect a  trigger T1
          2) count N trigger T2
          3) generate a TTL (one pulse)
    loop to 1)

So, I'm looking for a way to run a counter on a front edge of a signal T1 (fast and slim)

Then, I've to count N front edge coming from T2 (very fast and slim)

generate a TTL signal on a DIO

reset the counter to zero

then loop

The best way to do that should be to arm a counter to a given value, and at each pulse T2 to decrement this counter. When it reaches 0, it generates a TTL signal, the counter is reinitialized to the good value and wait for T1
seems easy but...

[Kevin_Price]

I'm not so sure you can do it the way you described with your E-series board.  I have a different idea for you that I think should probably work.  I'll describe it as a DAQmx task under LabVIEW.

1. Configure your counter for Pulse Generation, setting Units=Ticks.  Use external signal T2 as your timebase.  Set your Low Time = N ticks and High Time = 2 ticks (the minimum possible).  Using the minimum High Time allows you to be ready for the next T1 trigger sooner.

2. Make sure you're configured to generate 1 single pulse.  In other words, do NOT make a call to DAQmx Timing, which would set it up for multiple output pulses. 

3. Configure T1 as your Start Trigger, then use a DAQmx Trigger Property node to set "Retriggerable=True."

4. Run the task.

Behavior: board receives T1 edge, counts N edges of T2 and makes a High output, counts 2 more edges of T2 and makes Low output, is now ready to repeat on the next T1 edge...

-Kevin P.

[c.r.]

Thanks a lot Kevin, it seems to be a very good solution.
Anyway, the top I generate is either at, let's say N=10 or N=15. I mean it is not stable.
I can modifie the frequency of the triggers, it's always the same "decalage", shift. I want to shift my trigger of 10 top and it's shifted sometimes 10 sometimes 15.
Note that between two T2 triggers (the faster one) I've only 88 microseconds, and 44 ms between two T1 triggers.

My program initiates the counter as you say to do.
Then I start the task.
Then I have an empty while loop.
Finaly, I release the task.

It's difficult to do easier...

Any idea will be welcome.

Thanks

Christophe

[Kevin_Price]

I can't think offhand what might cause the behavior you describe.  The task should operate purely in hardware with no CPU requirement, so even if your "empty" while loop is so empty that it spins at MHz rates and hogs the CPU, I wouldn't expect what you saw.  Still, it'd be a good practice to add one of the msec Wait functions to your loop, or perhaps even an event structure to handle a "Stop" button.

Also, how are you subsequently verifying that the shift is either N=10 or N=15?  I've had occasions where my I hunted for bugs in my data collection when the real problem was an error in my verification.  Can you post the code that's producing the unstable shift?  It may help eliminate suspects...  

-Kevin P.

[c.r.]

Kevin,
    at first, thanks for your advices.
I check the various signal with a classic osciloscope. I trig on T1, I visualize the T2 and the pulse I generate via LabView. In such way, I can see that my pulse occure in two different positions. I can count the T2 pulses on the scope screen. I note that the generated pulse is larger that the T2 triggers (about 2 pulses, which seems OK because I generate 2 ticks as you said).
I've said something wrong : the number of ticks between the 2 "stable" position varies among the velocity of the rotation. Its about 1,2ms.
I join my program at this message.
I've trie to put a delay in the loop, the result is the same. It's true that the delay I've trie was very short (about 10 ms) with the metronome icon (wait until next 10ms perhaps, I don't remember the name).

Christophe

Message Edité par c.r. le 10-25-2006 05:34 AM

[Kevin_Price]

I can't see any reason why your counter would sometimes count N=10 and other times N=15.  I would start by suspecting that the counter board always *thinks* it's counting N=10, but that sometimes for some reason, several of the T2 triggers don't activate the counter's TTL edge-driven inputs even though they're visible on a scope.

I'm not an EE whiz, but I know that for TTL compatibility the incoming T2 triggers should have very fast rise/fall times (sharp edges), and make transitions between legal digital levels.  If I didn't see clean square pulses going from <0.5 to >3.5 with sub-microsecond rise times, I'd look to clean up the signals with a Schmitt trigger.  Or two so as not to invert the signal.

-Kevin P.

[c.r.]

Just to say that, as Kevin said, the program, the method works fine. Now everythings seems to be OK. I'm not sure of the modification I've done on the signal but it works.
Nevertheless, I've some problems with short delay... doesn't matter.

perhaps the change of the type of trigger (rising-falling), I don't know...

btw : I've added a "wait until 100ms" in the while loop it's easier to "manage the run" and it doesn't change the performance (as Kevin said).

Thank's
Christophe