LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Dynamic Data Sorting from One Input Channel

Solved!
Go to solution

Hello,

I'm using Labview to manipulate a set of Galvo mirrors to rapidly position a laser beam across several discrete points of interest. My analog detector continuously reads the position data that is output to graph charts as seen in the attached photo at a rate of 1kHz. I've programmed the attached block where I can select up to 32 points via a matrix and a set of nested for loops is used to move the beam to each point, clear the chart history, record a snippet of data (decided by the dwell time parameter) from two waveform charts (off screen) to multiple spreadsheets and repeat for each point of interest.  Currently, I do not get the same number of data points written to each file despite the same dwell time. I suspect this is primarily due to the processing time it takes to open and close multiple spreadsheets increasing the predetermined record time. Any advice on how best to rewrite this so I get the same number of data points written into each file?

0 Kudos
Message 1 of 5
(2,655 Views)

Please include a Snippet of your code, or attach your VIs, so that we can better assist you. We are here to help, but won't spend all that extra time recreating your code from a picture. Also please include the code you mention that writes to the charts.

 

The bottom line is really that you shouldn't be pulling chart history in order to write to file. You can transfer the exact number of datapoints directly to the file IO part of your code and have it be controlled by number of datapoints, not by just waiting an arbitrary amount of time. I would suggest a Producer/Consumer architecture.

 

The Producer/Consumer architecture is based on a producer loop adding data to a queue and the consumer loop dequeueing the data. The process-intensive or time-hogging code goes in the consumer loop to free up the producer loop to run at the speed you need it to run.

For example, you have code that acquires data every 100ms and needs to write that data to file. It takes 50ms for the acquisition code to run and 80ms for the write-to-file code to run. Uh Oh! You're now taking 130ms per loop and your application is backing up. Now you move the write-to-file code to a consumer loop and enqueue data to it from your producer loop. Voila! Your 50ms code and 80ms code run in parallel and can both keep up with the 100ms period.

More information here.

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


0 Kudos
Message 2 of 5
(2,612 Views)

James,

Thank you for your quick response see attached snippet and subVI. I'll take a stab at incorporating Producer/Consumer architecture into the current VI and update so the data is collected directly from the NI-DAQ and stored into a 3D array. I agree that recording from the chart over arbitrary time frames isn't the best way to get reproducible sample numbers. In earlier iterations the previous developer queried the chart because it was necessary to have real-time monitoring in parallel, additionally the sampling time for one position was large (circa 15 seconds). Here, we seek to collect samples from multiple positions in parallel. Is it possible to collect a discrete number of samples while sampling continuously from the same channel of the NI-DAQ in another loop?

 

Thanks again.

Download All
0 Kudos
Message 3 of 5
(2,573 Views)
Solution
Accepted by topic author LabGuyA

What you want is a better transfer of data from your bottom (DAQ) loop to your top (File IO) loop. I would suggest you create a queue at the start of your application and then wirte the reference to both loops. This is how the example I linked to above works. Enqueue new data in the DAQ loop and dequeue that data in the File IO loop. This will group each set of datapoints together and you will never have a mismatch.

 

You can create some sort of memory (shift registers?) in the FileIO loop that stores your data until it's ready to dump it to file. You can also reset this memory when you want to start a new file, or something like that.

 

 

"Give me six hours to chop down a tree and I will spend the first four sharpening the axe."  - Abraham Lincoln

 

Here are some free training tools primarily focused on LabVIEW and NI hardware to help you.

NI Learning Center

NI Getting Started

-Hardware Basics

-MyRIO Project Essentials Guide (lots of good simple circuits with links to youtube demonstrations)

-LabVEW Basics

-DAQ Application Tutorials

-cRIO Developer's Guide 

Learn NI Training Resource Videos

6 Hour LabVIEW Introduction
Self Paced training for students
Self Paced training beginner to advanced, SSP Required

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


Message 4 of 5
(2,569 Views)

James,

Thanks so much for your advice. After taking some time to do some labview tutorials and research I've implemented your queuing suggestion into the attached code. Now my issue is with timing. I'm using a NI USB-6212 to raster a laser across a max of 32 points of interest in a single scan. For each point, I send an x,y set of output voltage values to the NI-DAQ, wait 300 uS and then record single samples from multiple voltage input channels on the NI-DAQ. I'm currently limited to sampling at an effective rate of 1 kHz because it takes about 1-2 mS for Labview to send one set of output voltages to the NI-DAQ (although the NI-DAQ can handle generation rates of up to 300 KS/s) What options would you suggest to improve my effective sampling rate (I'd like a rate of minimum 1kHz over 16 points if possible)? Also, any suggestions on cleaning up the code in general would be welcome.

 

Thanks in advance.

 

0 Kudos
Message 5 of 5
(2,491 Views)