Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Controlling scanning mirrors

Hi all,

 

I have been writing a code to control the scanning rate of dual axis mirrors, using PCI-6731.  I wish to scan in the x-direction with a sawtooth function and in the y-direction with a stepwise function.  Each step (referred to as a B-scan) is composed of a number of x-direction points (called A-lines in my code); both of these parameters I set manually.  However, even though my code does work and is scanning, my problem is that I wish to obtain only a certain number of 'runs' of the entire scanning volume, i.e.. a C-scan is (# of A-lines)x(# of B-scans) - I want to be able to control how many times the C-scan area is scanned.

 

This may seem like a trivial error especially since I already have the code written, but it is very frustrating.  I have tried putting a 'for loop' to control the number of runs in the attached .vi file (originally a while loop initially). Please help!! Smiley Sad

 

Miika

0 Kudos
Message 1 of 4
(3,359 Views)

If you want precise control over the number of analog samples you generate, you should set up the task for Finite Sampling rather than Continuous.  Then you can define *exactly* how many samples to generate.    Once set for Finite Sampling, you probably have to explicitly configure the task to "Allow Regeneration" so you can regenerate the "C-scan" waveforms you've defined multiple times.

 

-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 2 of 4
(3,354 Views)

Kevin,

 

Thank you for your reply. 

 

I did as you suggested and have put the sampling mode for both my Implicit and Sample clock into Finite mode.  To the 'samples per channel mode' I wired the product of 'A-lines per B-scan' and 'B-scan positions per volume' (this correct?).  These samples would translate to the number of my desired positions which I wish to put my mirrors at.  I placed an indicator on the output of the DAQmx Write.vi to show me how many samples were successfully written.  This coincided with the anticipated product of A-lines and B-scans.

 

However, The mirrors do not seem to be scanning to the extent I saw when the code was running continuously Smiley Frustrated.  Is there a way to verify that these samples correspond to mirror positions?

 

Miika

0 Kudos
Message 3 of 4
(3,352 Views)

Hmmm.  I guess I'd be suspcious of the way you're defining your waveform.  Since you've verified that you correctly made the task generate exactly the # points you want to, my guess is that that you've defined waveforms with more samples than that #.  Now that you are doing finite sampling, the AO generation task stops before it can finish outputting the full waveform.

 

So I'd check the vi that defines your waveforms and verify that the # of samples it uses to define them is > the the A*B product you mention.  If so, then either:

a) change the # samples used to define your waveform to make it match the A*B pts you want to generate (per cycle)

b) change the # samples generated by your AO task to match the # of samples used to define your waveforms.

 

After this, you can do multiple cycles by generating an integer multiplier of that # pts and configuring a DAQmx property node in your AO task to allow regeneration.  I *think* it's a DAQmx Write property node, and it needs to be configured before starting the task.

 

Finally, it isn't clear to me why you're using the triggering counter at all.  Your sequencing simply triggers the AO task immediately anyway, which is not appreciably different than leaving the trigger right out of it.   (A lesser note is that the counter could just generate a single pulse rather than a pulse train.  You get this behavior by never calling DAQmx Timing.vi in the counter config chain.)   Note that this is just a general observation and probably has no particular effect on the issue at hand.

 

-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 4 of 4
(3,343 Views)