trigger incremented AO

[Subwavelength]

Hello,

I am looking for a way to trigger/synchronize a raster scan to a digital/HW trigger as it looks like I need more accuracy then software based timing can provide. Specifically, unlike the XY/raster scans/voltage ramps/ I have seen in the forums and examples,  I would like to step each point of the X ramp, and step the Y ramp at the apex and at the bottom of each ramp; I would like to be able to control the timing of the steps as this be a "dwell time" at which I will capture an image using the same trigger.   

I thought this approach (https://forums.ni.com/t5/Example-Code/Generating-Steps-Incrementing-Analog-Signal-with-Digital-Trigg...)  looked promising, but currently I only have a USB 6211 available, and it appears that I will not be able to test or even step through it all the way.   I was hoping for any suggestions or points to the correct direction for this project.  

Thanks in advance,

SW

[Kevin_Price]

First let me suggest that you try to think of the timing signal as a "clock" rather than a "trigger".  With NI's DAQ devices, triggers are things that happen once during an acquisition or generation task whereas clocks are the things that drive sample timing.  It's just gonna be easier if you're careful to adjust your terminology to match the way DAQmx works.

I have a question or two about the needs of your clock signal that you show as variable in the range of 50 - 1000 microsec.   And are you expecting or wanting the timing to be variable within one test run, or constant for a given run but variable across separate runs?   Also, do you intend to be in control of the timing of this clock, or is it some external signal you need to react to?

Otherwise, I'm not seeing what makes this app very different from several threads I've been in about raster scanning.   Best case scenario is that this can be done with a 2-channel AO task (for X and Y) with no need for a counter task.

-Kevin P

[Subwavelength]

Hi Kevin,

Thank you very much for the fast reply.  The clock will be constant for the run - but be available to the user as a variable.  I am open to making my own clock  (e.g. variable timing source)    

I am interested, and encouraged to hear that you do not see it as that much different and I have seen in other posts your admonishments about triggering vs.  clock synchronization - guess I didn't learn well tho.  I guess being far from expert at LabVIEW,  my fundamental lack of understanding is how to make each ramp step increment  on the clock pulse.   I can easily see that putting the second slower ramp in an outer loop such that when the first ramp reaches the requisite "N" steps, the slower ramp increments a step.  What I think I have seen in the forums are the entire ramps generated in a loop and stored in a buffer, but then timed to the device through a while loop with a "ms delay icon"  and the SW generated delay accuracy which  worries me as my camera shutter will be open for 15 to 50 micro seconds.  

I also often see the entire "ramp" generated  from min to max without clearly defined steps e.g. (https://forums.ni.com/t5/Example-Code/Generate-2D-Raster-Pattern-in-LabVIEW/ta-p/3503399); specifically, in the photo attached this not the behavior I would want if I put in these settings.  The Y parameter and graph make sense to me but unless mistaken the X "steps" are entire ramps in my terminology not steps- and the caveats w/r to timing etc above still apply.     Perhaps I am missing the forest for the trees? 

Cheers,

SW

[Kevin_Price]

I kinda do think you might be missing the forest for the trees.

I'm not sure exactly what you have in mind when you say you want "steps" rather than a "ramp".   Your pic in the original post sure looked ramp-like to me.

And either way, I think you'll find that the DAQmx task part of this app is pretty simple.  The problem to be solved is to generate arrays of values which, when graphed, produce the exact shapes you're trying to produce.   Whether it's a traditional "ramp" or some other slightly different thing you call "steps", either way you can represent that shape with values over time.  And once you can define your values over time, it's pretty straightforward to get an AO task to generate them with precise timing.

I made a very simple starter utility in this thread over here.  It'll generate a very simple dual-ramping pattern for each of the 2 AO channels one might control in a raster scanning app.  The 2D array of these values would be ready to write to an AO task where they can be generated with precise timing.  I've attached an updated version of it below (# samples for each "ramp" changed to controls instead of constants and given smaller default values.)

If this doesn't address your question, try rewording to help me better understand where you're stuck.

-Kevin P

[Subwavelength]

Hi Kevin,

Thank you for all efforts on my behalf - this is greatly appreciated.  You are entirely correct that I have been missing the forest for the trees.   It was not until I wrote the data to a file and looked at it in Excel that I realized that I simply misinterpreted what I saw on the LV graphs.  Needless to say I have wasted a lot of my time and some of yours on this.  

I would still appreciate some insight into how to control the timing of each increment. I have read through the NI tutorial NI-DAQmx Data Acquisition Triggering Techniques but it is not clear to me whether this would be a pause trigger or other.  

SW

 

[BertMcMahan]

To rephrase what Kevin mentioned earlier, each new sample is generated on the AO pin on the rising edge* of the Sample Clock. The Sample Clock is the thing that will synchronize all of your external stuff, hence Kevin's comment that you might want to reframe your ideas- you want to export your sample clock to be used as a trigger for something else.

*By default. You can switch to the falling edge of the sample clock if you want. It might be beneficial to, say, increment your AO on the rising edge of the sample clock then trigger your camera on the falling edge of your sample clock. Note that the sample clock will probably not be a perfect 50/50 duty cycle pulse if you export it, so don't count on the falling edges being exactly 1/2 period apart unless you can verify it and make sure. I *think* exported sample clock pulses are the width of your base clock from which the sample clock derives.

[Subwavelength]

Thank you -  that is helpful input.  I think at this point I just need to work through some VI's and watch what happens on the oscilloscope.  I will study the  Sample Timing Clock again tool again and see if I can put your input in context.  The input on the timing and rising and fall edge is very helpful - my hope is to use the "frequency generator" and divisor as my clock.