DAQmx Generate a modified TTL

[hlmax79]

Hi, I am trying to generate a continuous TTL triggered by a input TTL similar as in the figure:

 

with a PCIe 6321 and a BNC2110. The frequency of the input TTL is around 100KHz. Do you have a good way to approach this problem? One approach that I tried is to output an analog signal when the DAQ counter is odd (with a case structure of 1 if loop# mod 2) but there is a software lag time. I am thinking what I need to do is something along the line of this but I am not sure how to do it in parallel with the AO writing for every odd counter loop. I dont have access to a chassis unfortunately.

Thank you very much for your help.

[Ben]

Have you considered using the DIO lines?

Ben

[Kevin_Price]

That specific pattern is a kinda tricky one.  You're trying to match both rising and falling edges of the input signal for half the input pulses, and maintain low state for the other half.

I would normally approach these kinds of pulse and timing problems with a counter task, but I don't think that's gonna be possible here.  I think you'll need a moderately advanced approach using both DI and DO.

The DO part is easy enough.  You just need to do continuous regeneration of a repeating pattern.  1 sample in high state followed by 3 in low state.  The tricky part is making a sample clock that lines up with the input signal edges.

That's where DI comes in.  You'd need to set up a DI task that uses "change detection" for timing.  Make it sensitive to both rising and falling edges of the input signal.  (You won't need the DI data from this task but you may need to keep reading it to prevent a buffer overflow error.)

Finally, you'll link the timing together by configuring the DO task to use the DI task's "change detection event" as its sample clock.  The easiest way is to right-click the 'source' input terminal on DAQmx Timing for the DO task.  Create a constant (it'll be a DAQmx Terminal type of constant).  In the drop-down list of terminals, pick the one that looks like "/Dev1/ChangeDetectionEvent". 

Be sure you sequence your code to start the DO task before starting the DI task, and I think that's about it.  Note that this method will work even if the input pulses have variable timing.  It's all driven by the transitions, whenever they happen to occur.

-Kevin P

[hlmax79]

Hi Kevin P,

Thanks a lot for your helpful suggestion. I implemented them in the attached code adnd it looks like the synchronization works well (attached oscilloscope capture). However, I noticed the generated TTL will either be triggered on the rising or the falling of the input TTL (switch to the opposite edge) every time the code is run, how should I fix it to only trigger at rising edge?

Also, since the generated trigger depends on a set length and value now, I can't generate a TTL that skips more than 2 pulses, is there a good way to control the pulse spacing based on a set value of skip pulses?

Thanks a lot!

[Kevin_Price · Accepted solution]

To make sure you start your output on a rising edge of the input, a little more work is needed.   I've attached code that adds a counter task whose job is generate a single pulse 1 microsec after a falling edge of your input signal.  The change-detection DI task is configured to be triggered by this pulse.  Because it gets triggered just *after* a falling edge, the first change detection will occur on the next *rising* edge.

It's possible you could directly trigger the DI task from the falling edge, but I'm not 100% sure that the same falling edge wouldn't also generate a change detection event.  It seems like it *shouldn't* but I try to avoid these kind of signal-propagation-races.

As to your second question, I really don't understand it.  Let me reiterate a couple things and see if it helps.

    Right now, each change detection event from the DI task will cause the DO task to generate its next digital value.  Any transitions you define in the DO buffer will align with one of the transitions of the input signal.   The timing / spacing between these output pulses simply depends on the data you feed to the DO task.

Notes on attached code:

- added the counter task to help guarantee output starting on rising edge at input

- changed order for starting tasks.  The task that kicks everything off is the one that needs to start *last*.  It should have been the DI task previously.  Now it's the added counter task.  

- you'll need to do physical wiring to jumper the input signal over to a PFI pin.  As posted, the code is configured to expect it at PFI0.

- I didn't change the fact that you called DAQmx Read to get a digital waveform out from your *output* task.  That looked odd and suspicious to me, but I left it there.  I didn't test with real signals so don't know if it does anything useful, but at least it didn't cause a DAQmx error.

-Kevin P

[GerdW]

Hi hlmax,

I am trying to generate a continuous TTL triggered by a input TTL similar as in the figure

You might combine two simple TTL ICs, like a counter (7493) with an AND (7400 or 7408), to achieve the shown TTL output pulse…