External trigger sync in conjunction with nearest pulse of fixed frequency device..

[cshl]

I am writing an application that performs a raster scan. One axis of the scanner runs at a fixed frequency. I am using a 5105 high speed digitizer to acquire the data. The slow axis of the scanner is controlled by a servo with an analog input. I will probably use an M-series board for the analog control, but may also go with a 6713 (output only) or some other board. The fixed frequency scanner provides a line clock, which I would like to use to drive the 5105. Additionally, the analog board will need to be synchronized into this. The whole system should be able to accept a trigger from external devices, such that it begins scanning at the next line clock edge.

I'm not entirely sure what the best way to do this would be. The external trigger from other devices will be of an indeterminate pulse width, so I can't simply use it as a gate for the line clock. I am reluctant to do it in software (ie via change detection on a digital line) because I want it to be reliably started at the next clock pulse. I have considered things like a counter/timer with a pause trigger, but that could lead to drift between the control board and fixed frequency scanner. It just seems more complex than I think it should be, and it feels like I'm missing a simple way to do this.

Any suggestions?

[John_P1]

Hi chsl,

It sounds like the scanner might just be running continuously and you only want to trigger an acquisition at certain times.  If this is the case, you can use a Start Trigger with the 5105:

Is the AO Card running continuously or is it also triggered?

I'm not 100% sure on which parts of this application need to come from our hardware and which are already coming from the scanner and other external sources.  If the scanner is running continuously on one axis, wouldn't you want the AO card to output continuously as well on the other axis? 

If possible, could you post a timing diagram of what you need to do to help clarify.

Best Regards,

John

Message Edited by John P on 12-15-2009 05:51 PM

[cshl]

Thanks for replying.

I want something that behaves like a start trigger, that's where the external trigger from other devices comes in. Once that signal is recieved, the analog output should begin on the next line clock pulse, and should stay synchronized to the line clock. One axis of scanning is running continuously, in addition to being at a fixed frequency. I can't just use a start trigger, because there are essentially two trigger inputs (the "external" trigger and the line clock), which may not overlap in time. It's almost as if the external trigger will "arm" things and the next line clock will function as the start trigger.

The round-up of signals includes the line clock, which is from a third party device. A TTL trigger (most likely a rising edge) needs to be accepted to kick things off (from outside of the system this will appear to behave like a start trigger, and from inside it will be an "arm"). Then there's the outbound analog signal to the scanner's servo. Any other signals generated/recieved are entirely optional, and will be whatever it takes to get the NI hardware behaving as desired.

The scanning will stop and start at all sorts of intervals, under control of higher level software and direct user control. The duration of the scanning will vary considerably, and for longer timescales clock drift can become an issue. When not scanning, the fixed frequency axis of the scanner will keep running, but the other axis will be stopped.

If the "external trigger" signal was to behave like a pause trigger or had a width large enough to do a digital pattern trigger, this would make this easy. As it stands, the fact that it's a pulse is what's making this complicated for me.

Does that clear it up a bit? Do you have any ideas?

I am using NIDAQmx and NI-Scope to program this, by the way.

[John_P1]

Hi cshl,

I believe the following should be what you need:

Use the external trigger as the Start Trigger for both your AO and your Scope devices.

Use the external line clock as the Sample Clock for each of these devices.

This would arm each device when you send the trigger signal, and the AO updates would occur on the line clock edges (can be configured to be rising or falling).  Do you want to take a single sample off of each line clock pulse?  If so just use this as the sample clock for the Scope (assuming the clock is running continuously--the 5105 uses pipelining to achieve higher rates so it requires a continuous sample clock once armed).

 
Best Regards,

John

[cshl]

Interesting suggestion.

I wanted to use the pixel clock as a sample clock for the 5105, but that won't work because the pixel clock varies from around 3Mhz to 12Mhz. We went through this with NI engineers, and there are no boards that can take a sample clock that varies so much. Instead, I am using the line clock as a trigger to acquire ~7500 samples, which I then organize into pixels (with a varying number of samples per pixel) in software. I don't expect there to be much clock drift on the order of a single line, so this approach is fine. But, over many lines, there will be drift, so it needs to get synchronized.

As for the analog output, there are two ways to look at it. One is to put out one sample per line, and the other is to run it in a much smoother sawtooth. I had been leaning towards the latter. I think if I went with your approach, it might work reasonably well. Although, it would be nice to have the slow scanner step during the turn around of the fast scanner, so that the motion (and settling) is masked out in the samples we discard. I might be able to do that with a signal available on the servo.

The only sticking point is the 5105 still needing two triggers. I could maybe get around this by putting out another signal from the other board to be used as the trigger for the 5105. I don't know how to do that exactly, because I would only get one sample per line clock, and I would need two samples in order to generate an edge. Could a counter/timer solve this?

[John_P1 · Accepted solution]

Hi cshl,

Good to know--the 5105 has a duty cycle tolerance of 45-55% (mentioned in the specs page), so this is why you can't change the clock rate from 3 to 12 MHz on-the-fly (although if you made small incremental updates over time this would be possible in theory).

With the extra information in mind, you might want to try the following on the 5105:

Use the external trigger as a start (acquisition arm) trigger.

Use the line clock as a reference trigger (with a reference position of 0 so that the ~7500 samples are post-trigger).

The problem with this is that you will need to re-trigger on each line--the 5105 has a 2.4 us re-arm time (also mentioned in the specs page).  If this is unacceptable, another way I can think of is to use an external reference clock to PLL the Scope's internal clocks to.  If you can provide a stable, 50 ppm accuracy clock that is synchronized with your scanner to the Scope, then this would solve the problem of drift over time without having to re-trigger on every line (just acquire data continuously).  The frequency of this clock must be between 1 MHz and 20 MHz in 1 MHz steps.

We don't have any board that can take in a varying external clock up to 12 MHz (on-the-fly), but if you wanted to compromise a bit the 6115 can sample up to 10 MHz and does not have the 45-55% duty cycle requirement so this might be worth looking into.

As far as AO goes, I'm assuming the line clock is asserted after the fast scanner has completed its turnaround (ideally you'd want to update the AO during the turnaround).  If you have a signal from the scanner that you can use instead then this would likely be easiest.  If not, our M series and X series devices (but not the 67xx AO Series) offer reference clock functionality so if you go with the reference clock idea mentioned above it may be easiest to just PLL all of the clocks together.  Are these boards in a PXI chassis or are they PCI form factor?

I'm not sure what you mean by the sticking point regarding the need for two triggers.  I think the idea is we use the external trigger to arm the 5105, and the line clock to trigger each record.  However, if you do need to generate a double-pulse based off of your line clock then you can use counters to do this (our counters are retriggerable with rearm times in the ns range).

Best Regards,

John

[cshl]

I think that's it, thank you.

We went through the options for the variability in the pixel clock with someone from NI quite a while ago, and we looked at other vendors as well, and nothing exists that has that kind of duty cycle tolerance. So, just running it by its own clock (at 60MHz) with a new trigger every line is fine. The 6115 isn't acceptable because the pixel clock goes over 10MHz during a portion of the scan, and that's not something that can be adjusted (physically it needs to be 12MHz to evenly divide the sweep).

I like the idea of the start trigger and reference trigger. That's very much along the lines of what I wanted, and what I meant by two triggers. I had only been considering the start trigger on the digitizer. This way seems simple. Getting a clock and arranging a PLL adds complexity. The re-arm time should be acceptable. It works out to about 3.8% of a single sweep. Although that does cut things a little closer than I'd like, it should be acceptable. I won't know until I have it up and running if that really eats into the image, because I need to see how the distortion from the turn around on the scanner actually affects the image to know exactly how many samples to discard. Even if it reduces the field of view a little it will be okay.

To be precise, there is no "line clock" on the servo, there are a pair of signals that occur on a per line basis, of which I intended to treat one as a line clock. The manufacturer intends them to be used as masks for when to acquire data, but that assumes you use their pixel clock and only acquire data on one sweep (and ignore the return sweep). They are tied to the tuning of the servo, and I believe one could be used to get an edge to clock the AO, while the other will work as the reference trigger for the high speed digitizer. This might require a little fiddling with some pots on the servo, and I don't know exactly how far I can push them around. However I think it will be workable.

I suppose I could also try a reference trigger with the AO, where it puts out a number of samples, the last of which falls during (or just prior to) the turn around. In fact, I still may need to run the AO continuously, because the step response time of the slow axis may not be fast enough.

All of this is running on PCI/PCIe hardware, although sometimes a USB flavor of M-series board might get used.

Are there any other catches I should be aware of?

It sounds like this is the right solution to me. Thanks.

[John_P1]

Glad to help,

It sounds like you're good on the Scope aspect--a couple caveats with Analog Output options:

Technically, there is no reference trigger for AO (reference means there is a possibility of pre-trigger samples which doesn't make sense for an output task).  Instead you just use what is called a "Start Trigger" in DAQmx.

AO tasks are only inherently retriggerable on our X Series DAQ devices (PCIe only -- numbered 63xx).  The rearm time will be on the order of a few ns (based on the timebase).

If you want to use an E/M/AO Series board, you can use the counters to generate a Retriggerable Finite Pulse Train to be used as the AO Sample clock (Counter Outputs are retriggerable on these boards).  This would give the same behavior as the X Series board but requires the use of both counters to generate the finite pulse train.

Since you just want to update the AO statically after a pre-determined amount of time after the trigger, you could get by with generating a single pulse a certain amount of time (Initial Delay parameter) after the trigger occurs.  This would only use a single counter.

Since all of this is taking place in hardware it shouldn't matter if you are using USB or PCI--if you choose to restart the AO task rather than implement the retriggerable workaround for your M Series boards it will likely take longer on the USB version due to bus latency.  I highly recommend either using an X Series board (with retriggerable AO) or using the counters of our earlier boards to implement a "retriggerable" solution (if you need the counters for other tasks we might be able to find another workaround).

Best Regards,

John