LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Syncing digital output and counter output with external trigger

Solved!
Go to solution
Solution
Accepted by topic author Lostsignal

Sorry, my bad.  I got part way into the workaround and then kinda lost my train of thought, forgetting that DO can't be triggered.

 

Here's a correction, this time I'll leave explicit routing via RTSI out of it.

 

Configure AO to use the 400 kHz clock as both its start trigger and sample clock.  Because you'll be using DAQmx Timing, you'll also need to call DAQmx Write to write some 0V data to the buffer.  Still start the AO task *last*.

 

Configure DO to use the signal "/digitizer/ao/SampleClock" as its own sample clock.  Configure CO to use the signal "/digitizer/ao/Start Trigger" as its own start trigger.   Start these two tasks *first*.

 

Until you start the AO task, DO and CO are kinda stuck waiting, generating no output.  DO doesn't yet have a sample clock and CO hasn't yet been triggered.  When you *do* start the AO task and it receives the first 400 kHz pulse, both DO and CO will become unstuck in unison, during the same cycle of the 400 kHz clock.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy coming to an end (finally!). Permanent license pricing remains WIP. Tread carefully.
Message 11 of 17
(475 Views)

I rewired as you have suggested, I am facing two issues now

1) The Digital output now triggers, but I can't control the duration of the pulse(Like just one value is written)

2)Labview "sleeps" after a few min of running without sending an  error: The programs becomes unresponsive and we need to use task manager to quit the program.

I have attached the updated code for reference.

P.S. As  I am anyway using the analog out, can I use it instead to send LVTTL signal, other than slow switching speed, what are the other things to keep in mind.

Thanks once again.

 

 

0 Kudos
Message 12 of 17
(458 Views)

1. Sure you can control your pulse width.  You just need to define the # of consecutive samples for the digital output to be High.  However, I can't give specific advice about how to do that with digital waveforms.  I tend not to use them except for graph/chart displays.

 

2. It's a bit of a guess, but right now you're set to loop around and recreate tasks immediately after clearing them.  Prior discussion & experience suggest that it can be helpful to give DAQmx some breathing room around the buffer and resource management it does when clearing and creating tasks.  Some of the cleanup can continue to happen in the background after calling DAQmx Clear.

   As an experiment, put a 2 second delay before your initial sequence frame.  Be sure to wire an output from the delay to the frame boundary to enforce sequencing.   2 seconds should be way more than enough, this is just a very simple experiment to determine whether the rapid loop-around is the culprit.   If you find that it is, there will be better solutions.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy coming to an end (finally!). Permanent license pricing remains WIP. Tread carefully.
Message 13 of 17
(452 Views)

Thank you the insight, the timing was working well when I used the external signal as the source[400KHz clock], but I am unable to do the same while using  "/digitizer/ao/SampleClock".

I tried stopping the task after it starts and used the external clock[400KHz clock], but the delay was too long and I could't control it properly. I need to generate a pulse with 100 microsecond high time. I tried using wait till done API, and received warning about the task being completed while using the /ao/SampleClock.

Thanks again.

0 Kudos
Message 14 of 17
(425 Views)

Please post the most recent code and describe in detail:

- how you *want* it to behave

- what you have observed instead

- what kind of troubleshooting you've already done and the lessons you took away from

 

It's a little bit of a moving target when you describe various changes and different kinds of issues.  Specificity is going to be needed to figure this out.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy coming to an end (finally!). Permanent license pricing remains WIP. Tread carefully.
0 Kudos
Message 15 of 17
(420 Views)

Thanks Kevin P for your help and guidance for the problem. I tried a few troubleshooting and realised it was an issue with AO task not configured properly. I did not wait for the AO to complete the process but instead stopped out immediately after starting the output - making my DO not function properly. Fiddling with no of samples and adding a wait til done helped me solve the problem.

Just out of curiosity, what are other ways I can implement the same thing, ie, without using a AO and if I wanted the the whole process to start with an another external signal, lets say when a shutter is open how should I proceed.

Thanks.

0 Kudos
Message 16 of 17
(408 Views)

It seems to me that the AO task will continue to be necessary with your present device.  Your device's DO doesn't support start triggering and can't generate its own sample clock from an internal timebase.  It needs help to be able to sync up with the finite pulse train task and an AO task can provide that help.

 

You would use it in much the same way if you wanted to trigger off a "shutter open" signal.  The only difference is to let the AO task generate its own sample clock instead of using an external signal.  But the DO task would still use it the same way.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy coming to an end (finally!). Permanent license pricing remains WIP. Tread carefully.
0 Kudos
Message 17 of 17
(397 Views)