Resonant scanning system with PCI6115

[MathiD]

Dear all,

I have a scanning system using PCI6115 (10MS/s/Ch) and I am acquiring 4 AI from 4 detectors simultaneously.

We have a resonant scanner with a scan frequency of 2.56 KHz and it gives a TTL pulse for each scan cycle. 

I acquire 500 samples for each pulse and hence my resulting image should be 500*256 or 500*512 (if I use both sides of the scan).

My slow scanning speed is 10 Hz and hence I should get 500*512 images with 10 frames per second. 

I used Labview AI finite samples and built around producer-consumer loops for storage and display.

Although my code is working, it doesn't look like my imaging rate is 10 fps. 

I have attached my code to this post and there is some obvious thing which I am overlooking. Can you give me pointers to debug and solve this issue?

thanks and regards,

Mathi

[Kevin_Price]

I'm normally on LV2016 but had a quick look in a buggy virtual machine before it crashed my system.  From memory:

1. You're using Finite Sampling.  I suspect you should be using Continuous, but don't know your system well enough to be sure. 

2. You have a strange task Start/Stop construct with Start outside the loop and Stop inside.  Repetitive Finite tasks sometimes have both Start and Stop inside the loop (in which case, look into the DAQmx State model and consider doing a "commit" before the loop).  Continuous tasks almost always Start before the loop and Stop after it.

3. You haven't wired the # samples to read inside the loop.  The default value used is -1.  In a Finite task, that means read the entire buffer one time all at once and wait for them to accumulate if necessary.  In a Continuous task, it means read whatever quantity of fresh samples are available right now with no waiting.

4. Your producer loop with the DAQmx Read is also sending data to front panel indicators.  Don't.  Simply enqueue your data and do nothing else with it in the producer.  Do all the processing, displaying, and logging in your consumer.

5. You have 2 consumer loops, both Dequeueing from the same queue.  This is definitely a wrong construct.  Let your processing loop be the only consumer of the DAQ data.  Then make another queue where you re-enqueue that same data from inside the processing loop and let the logging loop dequeue from this 2nd queue.

6. I don't remember if you set up hardware triggering or re-triggering for your AI task.  You need it.  If your board doesn't support hardware re-triggering natively, there's a way to fake it.

7. Once you deal with all this stuff, you should be (probably) in Continuous sampling mode.  The producer loop should request 500*256 samples each iteration, immediately enqueue them, and the DAQ data wire should go *no other place*.  This way you split your continuous data into chunks where each chunk is one image.  At the other end, the dequeue will pull the data out in these same-size one image chunks.

Yeah, it's a lot of things but hey, you asked...

-Kevin P

[MathiD]

Hi Kevin

Thank you for your reply. It was really helpful. I made changes to my code and I have a (almost) working version. The data acquisition works as expected. However the image update rate in the consumer loop is super slow. 

I only read data in producer loop during optical alignment. I requeue data for storing as suggested.

-Mathi

[Kevin_Price]

Given the default values for the front panel controls, here's what I see:

1. Each rising edge on "/Dev3/PFI0" triggers a 500-pulse finite pulse train from your counter.  These pulses occur at 2.5 MHz, so it'll take about 200 microsec to produce all 500.

2. Earlier in the thread you mentioned a scan freq of 2.56 kHz which must be the rate of these triggering pulses.  So you retrigger once every ~391 microsec and generate 200 microsec worth of pulses.  So far so good.

3. These pulses are used as an AI sample clock.  Fine.

4. Inside your producer loop, you only read 500 samples per iteration.  Given the pulse rate and trigger rate, that means you're trying to iterate the producer loop at the trigger rate of 2.56 kHz.  Thus, I'm not surprised that you can't update multiple intensity graphs at such a rate.

5. I *think* you should be reading 500*256 = 128000 samples per iteration.  That's 256 triggers worth of samples at 500 samples per trigger.  With a trigger rate of 2560 Hz, that should get you back to a 10 Hz producer loop rate.

    *THIS* looks to me like the main issue.

6.  The consumer loop won't be able to run any faster (on average) than the 10 Hz at which the producer loop feeds it data via queue.

7.  At 10 Hz update rate, the processing and intensity chart updates are much more likely to keep up.

-Kevin P