Synchronizing counter output of two devices

[vivid_student]

Dear NI community,

I use a NI USB-6211 and a NI PCIe-6321 with a BNC-2110 and Labview running on Windows 11.

I need to perform fluorescence imaging experiments: a camera acquire frames under alternating LED illumination ; and across this alternation a stimulus happen at a given time, and last for a certain time ; all of this represents an experimental trial. To achieve this goal I need to control 6 counters:

A) one to send triggers to the imaging camera

B) three to send triggers to LED for illumination

C) one to trigger the stimulus across trials

D) one to count the triggers sent to the camera in order to know the elapsed time

I use counters because an exact control of time is a necessity in my experiments. Indeed I can control the stimulus onset and duration with a counter delay, high and low times.

I use finite counter output generation.

It is important for me to dedicate one counter for camera triggers counting, because I will repeat experimental trials in for loops, and I want to know the inter-trial times.

I want to dedicate the two counters of NI USB-6211 for stimuli triggers and camera pulse counting.

I want to dedicate the four counters of NI PCIe-6321 for imaging triggers (camera and LED).

Therefore I need to synchronize the NI USB-6211 and NI PCIe-6321 respective counters.

Thanks to this tutorial I succeed to synchronize counters output on one device. To do so I use 'dev/freqout' as a trigger for the counters output.

My questions are the following:

- How can I synchronize counters from two DAQ devices (one PCIe and one USB device)?

- Is it possible to use an external time base for counter output ? Can I use the NI USB-6211 'dev/freqout' as a common time base for itself and the NI PCIe-6321, in order to feed their respective counter output ?

Please find enclosed my VI, it represents one experiment trial, that later I will put in for loops. I will add the counter input later.

I also added a drawing to illustrate what I want to achieve with the counters.

Thank you in advance for your help.

[Kevin_Price]

Big picture advice:  the USB-6211 has relatively limited capability and isn't well suited for the kind of project you seem to be describing.  I don't have a comprehensive understanding of your timing signal needs, but I expect it'd be well worth your while to use something like a PCIe-6612 dedicated Counter/Timer device or perhaps a 2nd X-series PCIe-63xx Multifunction device.  Either will have significantly better counters and DO capability.

It's also conceivable you can get everything done with only your existing PCIe-6321 by using a combo of counter outputs and DO.  All of the timing needs aren't utterly clear, but I didn't read anything in your description that would rule this out yet.

What kind of timing precision do you need for the signals you generate?  Would 10 microsec be good enough, for example?  

Based on your hand sketch, it looks like your 3 trials might be independent of one another.  Could you live with something on the order of a second of idle time between trials?

(FWIW, I'm just trying to get a feel for things here by suggesting some constraints that seem likely to make it more feasible to do this thing with just a PCIe-6321).

-Kevin P

[vivid_student]

Dear Kevin,

>>> What kind of timing precision do you need for the signals you generate? Would 10 microsec be good enough, for example? 

1) The most important aspect is the regularity of the camera and LED pulse trains: for my experiments it is very important that pulses in a train are spaced by identical time periods. Depending on the experiments the rate of camera trigger ranges from 60 to 1000Hz (and one third of this rate for the LED illuminations). I will also perform hour-long recordings, and if huge period variations occurs in the pulse train, they will accumulate and the last camera triggered frames will  be 'later' than expected. This is something I need to avoid.

2) I want a 'deterministic' system: before the trial starts I define time parameters for the stimulus (delay, onset, duration, end), and same for the imaging (delay, frequency, duty cycle, pulse number). For now the stimulus onset is in coincidence with a camera triggered frame, but later one I might explore a given time shift between them.

So basically to answer your question my time precision need would be under 10 microseconds. Because I would like the most precise alternative.

>>> It's also conceivable you can get everything done with only your existing PCIe-6321 by using a combo of counter outputs and DO.

From what I understand counter output produce digital pulse train that respect all my needs (deterministic and regular). I guess that you suggest to control the camera and the 3 LED with the four counters of PCIe-6321, and the stimulus with a PFI digital output.

If this is what you suggests, it is not appropriate for me to use while/for loops and wait (ms) vi to control the stimulus digital output. In this case the digital output would rely on software timing (from the windows computer), and therefore being sensitive to the computer resource availability. In fact while running an experiment trial the PC is processing the imaged frames, and this significantly affect the computer resource availability. Indeed my experiments need to be reproducible and that's why a counter is better to drive the stimulus to make it start at a precise time, as it is independently controlled by the DAQ hardware.

>>> Based on your hand sketch, it looks like your 3 trials might be independent of one another. Could you live with something on the order of a second of idle time between trials?

1) I have three types of stimulus. One type of stimulus within a trial is repeated N times with for loops, before moving to the next type of stimulus. So I will use a 'flat sequence structure', and within each frame a for loop will repeat the N trials of same type.

2) Yes, it is totally fine to have some idle time between every trials. I just need the elements of one trial (LED, camera, stimulus) to be 'perfectly' synchronized and 'deterministic'.

>>> Big picture advice: the USB-6211 has relatively limited capability and isn't well suited for the kind of project you seem to be describing.

I can accept the inferior performance of the counter of USB-6211 compared to PCIe-6321. I would still prefer USB-6211 counter output instead of PCIe-6321 digital output, as it is not sensitive to computer resource availability.

So to summarize I am constrained by 'exact' stimulus time onset and duration. From my knowledge I can satisfy it using counters for camera, LED and stimuli. I just need to synchronize the counter output from my two DAQ devices. Do you know how I could proceed so ?

Best,

[Kevin_Price]

X-series devices support buffered, hardware-clocked DIO which can be just as deterministic and repeatable as counter output.  The 6321 supports buffered, hardware-clocked DO at sample rates up to 1 MHz, giving you timing resolution as fine as 1 microsec if you need it.  It's true that counter output supports finer timing *resolution*, but the determinism and repeatability will be the same for DO because both would be driven by the device's internal 100 MHz timebase.

I would usually advocate for counter use over DO when possible, but not in your situation where it *ALSO* involves the need to sync up timebases between a PCIe bus device and a USB device.  It can be done of course, it's just that it makes for a more complicated and less reliable experimental setup due to the extra hardware and physical wiring connections needed.  Sync becomes much easier when all the signals originate from a single DAQ device like the 6321.

Looking back over the original post, I don't think you truly need 6 counters for this app and thus don't need to sync up 2 distinct devices.

To achieve this goal I need to control 6 counters:

A) one to send triggers to the imaging camera

B) three to send triggers to LED for illumination

C) one to trigger the stimulus across trials

D) one to count the triggers sent to the camera in order to know the elapsed time

A. This can probably be 1 counter OR 1 DO line

B. This can probably be 3 counters OR 3 DO lines

C. I'm unsure of how this timing fits in, but you might be able to use 1 software-timed DO line for this.   Else 1 counter OR 1 DO line.

D. Unsure what role elapsed time plays here.  Since you calculate and generate the timing signals in question, you would already know the time history of your signals in advance.  You could use 1 counter to count the camera trigger pulses, but there are alternative methods that wouldn't consume a counter.  (Example: run a dummy AO task generating 0V that uses the camera trigger pulses as a sample clock.  Query the DAQmx property for "Total Samples Generated" to get a cumulative count.)

So from where I sit, if you get *any* hardware-clocked DO involved here, you might want to generate *all* the A,B,C signals with a single DO task containing 5 DO lines.  This would let you plot the signals on a digital waveform graph where you could verify all the timing relationships before writing the data out to the DAQmx hardware tasks.   Food for thought.

-Kevin P

[vivid_student]

Thank you for your help Kevin !

>>> X-series devices support buffered, hardware-clocked DIO which can be just as deterministic and repeatable as counter output. 

This is perfect for me then, I didn't knew this was possible. Could you give me some hints on how to do such buffered hardware-clocked DIO ? Could you please recommend some forums posts or tutorials to do so ?

>>> D. Unsure what role elapsed time plays here. Since you calculate and generate the timing signals in question, you would already know the time history of your signals in advance. You could use 1 counter to count the camera trigger pulses, but there are alternative methods that wouldn't consume a counter. (Example: run a dummy AO task generating 0V that uses the camera trigger pulses as a sample clock. Query the DAQmx property for "Total Samples Generated" to get a cumulative count.)

I would use a counter to count the time period between the inter-trial intervals. As every trials are repeated with for loops, the inter-trial intervals are software timed, and I would like to know the exact time it lasted.

>>> I would usually advocate for counter use over DO when possible, but not in your situation where it *ALSO* involves the need to sync up timebases between a PCIe bus device and a USB device. It can be done of course, it's just that it makes for a more complicated and less reliable experimental setup due to the extra hardware and physical wiring connections needed.

I would still appreciate to know how I can synchronize timebases between a PCIe bus device and a USB device, this might be useful one day for me (even if complex and not 100% reliable).

[Kevin_Price · Accepted solution]

1. One of the shipping examples should be a decent starting point  (Help->Find Examples->Hardware->DAQmx->Dig Out->Finite Output).   

    To be honest, I think about DIO samples as arrays of digital states, either as booleans or bitwise integers.  I've never fully "gotten the hang of" the digital waveform type & functions that were introduced long after I'd gotten used to the more raw approach.  It's always seemed kind of opaque, though I typically *will* convert to a digital waveform for the sake of graphing b/c digital waveform graphs are pretty useful.

    I suspect it's my loss and that there are probably some useful digital waveform functions for generating the signal timing you want, I just can't point you toward anything specific.

2. Ok, a counter could be useful here if you really need a super-precise time measurement.  You might want to do this with a "2 Edge Separation" measurement.  You may need to consider carefully exactly which signals (and which polarity of those signals) you'd want to use to define the endpoints of this interval.

3. To sync across the two boards would require a combo of compatible physical wiring and task configuration on both devices.  You would for sure need to export a suitable timebase clock from one device to the other and then derive all the sample clocks for both devices from this shared timebase.  You might also need to export a suitable trigger signal, though if you generate the timebase clock with a counter task, you wouldn't need a separate trigger signal as long as your start sequence was correct.  (Start all dependent tasks first, then start the timebase clock task last.)

    To make it work you'll need to designate a PFI pin(s) to export your timing signal(s) out to on the first device and which PFI pin(s) to import your signal(s) from on the second device.  And you'll need the physical wiring to correspond to the task configuration you just did.  There are more opportunities for error with such an approach, which is a big part of the reason I recommended otherwise.

-Kevin P