Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

AO output limit, PCIe-6363, BNC-2110

Solved!
Go to solution

Hello.

 

We are running two galvo scanner on a PCIe-6363 board with an attached BNC-2110 on the two analog outputs AO0 and AO1.
I attached a simplified version of our program: testGalvosV1working.vi
The other two vi's (wavePosSub and waveNegSub) are two sub-vi's to create the triangular waveform.
Please see the front and block diagram:
front.pngblock.pngThe numeric inputs imageSizeX/Y are the desired image size, here 512x512px. The offset input gives the scanning range of the galvos: 1V input means a sweep range from -1 to 1V. The step size of the galvos will be 2V/512px. The input "timePerPixel" is the scanning speed: How many pixels are raster scanned per second.

 

The program works as follows: You click start and before something happens: 1000ms pass (it is just for testing purpose, not really necessary). Afterward, the GalvoX scans from left to right, at the end of the line, the GalvoY proceeds to the next line and GalvoX scans from right to left and so on until 512x512px are scanned. That can be seen in the graph: the white line is GalvoY and the red line is the altering GalvoX. (put something like 5000 into timePerPixel to follow the graph updating.) Both galvo scanner are initialized with one task writing to both AO outputs.

imagingTime(s) is the expected time the scanners need to scan one image. The "time passed (+1000ms)" is a tick count. The tick count and the imagingTime should ideally be the same (just the tick count is 1000ms longer because of the initially 1000ms wait). That is not very precise but a good indicator for comparison.
Also, I am aware that the flat sequence is not necessary and you folks at NI aren't the biggest fans of it Smiley Wink  The fastScannerFreq and scanSpeedTooHigh indicator show the scanning frequency of the GalvoX, which should not be higher as 1000Hz. If exceeded the program does not run.

 

However, why I post this here: I have a speed limit which I do not fully understand. If I put a time >125000 into the timePerPixel(px/s) box the scanning speed does NOT increase anymore. Meaning I can not write more than 125kHz to the outputs. This can be seen in the program because the indicator "timePassed" does not decrease further.
What I tested so far: If I remove one AO output (and change to only one physical channel) I can write data with 250kHz. Therefore, it must somehow be related to the amount of samples I can write? But shouldn't I be able to write faster? Where is this limit coming from?

Thanks for reading. And maybe you have a hint.

Download All
0 Kudos
Message 1 of 6
(4,498 Views)
Solution
Accepted by topic author ben3000

No definite direct answer, but a few thoughts & questions.

 

1. You should write AO data to your task *before* you start it, otherwise your task is likely to throw an error.

2. You could probably pre-write *all* the AO data before starting the task.  Then you could also configure your task for finite sampling.

3. The PCIe-6363 is rated for up to 2 MHz AO sample rate with 2 channels in the task.  This doesn't explain the apparent 250 kHz limit you describe, but I'm also not sure your method for measuring this limit is reliable.  Is it possible you're accidentally using a different board for the AO, maybe you've got 2 different boards installed?

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 2 of 6
(4,455 Views)
Solution
Accepted by topic author ben3000

Thanks again.

It is definitely a PCIe-6363 board with a BNC-2110.

I think I managed to solve it. Though I still do not really understand why the first attempt does not work.

However, see attached the block diagram and the *.vi. (for sure I could find a more elegant solution with the for-loops 🙂 )

blockDia.pngCompared to previous version where I was stuck with a maximum pixel per second rate of 125kHz for 2 galvo scanner, which allowed for a maximum imaging speed of an 512x512px image in 4 seconds, I can achieve now easily an image acquisition time of  < 1 seconds. (However, the galvos sweep range should not exceed ~1300Hz, otherwise they might get damaged).

Thanks!

0 Kudos
Message 3 of 6
(4,422 Views)

Hi,

I'm trying to use this approach to run a single galvo with my USB 6008, but I keep getting an error which says I should set timing "on demand" and I don't understand why. Also, if I set it on demand I still get an error, like:

DAQmx Timing (Sample Clock).vi:4730001<append>
<B>Property: </B>SampTimingType
<B>Requested Value: </B>Sample Clock
<B>Possible Values: </B>On Demand

<B>Task Name: </B>_unnamedTask<995E>

 

galvoVI.jpg

 

Whenever I try to use Daqmx, I keep getting the same error, no matter how I set things and I don't understand why. Some times I could manage to get it to work, but the VI sends values to the output extremely so. So slow that it takes about 3 seconds for the galvo to sweep from 0 to 5V.

Any tips would be very appreciated!

 

0 Kudos
Message 4 of 6
(2,134 Views)

The USB-6008 doesn't support the use of a sample clock for AO.   To achieve "on demand" timing, just delete the call to DAQmx Timing.  (You also won't need the subsequent timing property node to set "on demand" explicitly.)   And you'll further need to start the task before you can write to it which is just the opposite of hardware-clocked tasks.  And finally you'll have to write individual AO voltage values one at a time in a software loop.   Device specs claim a 150 Hz max.

 

There's a shipping example for On Demand AO you can use as a starting point.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 5 of 6
(2,130 Views)

Thank you very much for your answer, Kevin.

 

Last night I ended up managing an alternative way to overcome the issue. I'm now using my USB 6251 DAQ, which should have a lot better performances.

I'm now creating a waveform and changing its frequency will now change the frequency of the AO data.
I don't know if this is a smart thing to do, but it seems to work well and speed is now just limited by the galvos specs.
I think I can now use the dt of this waveform as the dt for integrating the signal from a PMT which will collect the light of the confocal microscope I'm building as the raster is scanning.

 

asdff.jpg

0 Kudos
Message 6 of 6
(2,119 Views)