Data acquisition with control references

I'm a new LabView user and I would like to acquire data in a subVI and display that data in the main VI. I think that I need to use control references and refnums, but I just haven't been able to figure it out. I would GREATLY appreciate any help I could get.
Thank you!

From your description I would guess that the "subVI" has a loop in it that repeatedly reads the FP hardware, and the indicator is inside the loop. Right?
The thing to do is move a lot of the logic in the subVI up to the Main VI--or add the Main's added logic to the subVI, whichever is easier. In the first case, the subVI would go away, in the second, the subVI would become the Main VI.
If you're confused, post your code in V6.0 format and I'll show you what I mean.
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

Similar Messages

Data-acquisition with NI 6036E DAQ card & GPIB using an external trigger

Hi all,
I hope somebody could give me some help with the following and answer some questions:
Simple system description:
Labview 6.1
PCI-GPIB card
6036E DAQ card
In my system, I am using an external analog trigger signal (A) for continuous data-acquisition. Characteristics of the analog trigger signal (A) are: ~40 Hz, signal height +1.48V, triggered by rising edge (the analog trigger signal (A) could be changed to a TTL signal). Each data-acquisition is done within ~1.0 ms after the rising edge of the trigger pulse. The timing of the data-acquisition and analyzing procedure is controlled by execution in a sequence structure placed in a loop.
Now, I connected a power meter to the system, to measure the laser power during the data-acquisition. The power meter has two options to provide the laser power data:
a) via analog signal output (voltage corresponds to laser power in watts)
b) via GPIB (direct output reading of laser power in watts).
Problem:
During a certain point in my data-acquisition sequence structure (defined by a frame), I want to use the next occuring analog trigger signal (A) to acquire 1 value from the power meter.
How do I do this in Labview programming for the following two situations?
a) If I connect the analog output from the power meter to an analog input channel of the 6036E DAQ card. The analog trigger (A) would be connected to a second analog input channel (In case the analog trigger signal (A) is changed to a TTL signal it would be connected to the PFI0/Trig input pin on the DAQ card).
b) If I use the GPIB connection of the power meter. The analog trigger (A) would be connected to a second analog input channel (In case the analog trigger signal (A) is changed to a TTL signal it would be connected to the PFI0/Trig input pin on the DAQ card).
An other possibility would be to trigger the power meter directly, so it outputs constantly power meter values at ~40 Hz. How could I than acquire 1 power meter value (at a certain time im my sequence structure) via analog input at DAQ card or GPIB?
Additional questions:
How do I configure the PFI0/Trig pin on the 6036E DAQ board individually as an INPUT?
How do I use an analog trigger signal (A) as counting signal for a loop, or as an activation signal for a sequence structure which includes GPIB commands?
It would be very nice if somebody could give me some help.
Kind regards,
beam

Hi beam,
I just want to verify that I understand your situation correctly:
An external trigger signal (A) is wired to one of your input channels (e.g. CH0) to trigger data acquisition of a second channel (e.g. CH1). Your power meter is connected to an analog input channel, which you would like to trigger with a certain rising edge at some of your sequence structure.
Problem:
During a certain point in my data-acquisition sequence structure (defined by a frame), I want to use the next occuring analog trigger signal (A) to acquire 1 value from the power meter.
How do I do this in Labview programming for the following two situations?
a) If I connect the analog output from the power meter to an analog input channel of the 6036E DAQ card. The analog trigger (A) would be connected to a second analog input channel (In case the analog trigger signal (A) is changed to a TTL signal it would be connected to the PFI0/Trig input pin on the DAQ card).
If a task has been configured to acquire signal from one analog channel, it's not possible to run a second analog input task or to add a second channel on the fly. You had mentioned that it's possible to read from the instrument through GPIB. Is it possible to perform a software trigger such that at a certain frame of your structure, when the trigger signal A reaches voltage "x", a GPIB command is written to your power meter to query a measurement reading?
Additional questions:
How do I configure the PFI0/Trig pin on the 6036E DAQ board individually as an INPUT?
You do not need to explicitly configure the PFI0 line as an input. If you want to use it as an input such that it acts as an analog trigger, simply wire the trigger signal to this pin. When configuring the trigger in your software, specify PFI0 as the trigger source.
How do I use an analog trigger signal (A) as counting signal for a loop, or as an activation signal for a sequence structure which includes GPIB commands?
You can try using the Limit VI to find out when the trigger signal reaches a certain level, and count how many times this level is reached. Similarly, you can use this as the condition to execute GPIB commands.
Hope this helps,
Lesley

Data acquisition with daq card 6533

Hi all,
i need to develop a c++ (visual studio .net, no measurement studio)
program that performs data acquisition at a sampling rate of 10Khz
using a windows xp laptop and the daq6533 card.
The program must sample 8 digital signals. Each signal has a limited
time duration, say a few seconds, and acquisition should start on the
first rising edge of a signal, and terminate on user input. Browsing
through the code provided with the driver, i found the examples in the
cdio folder. It seems to me they almost do what i actually need.
Unfortunately, many of the functions used there are not supported by
the 6533 card, in particular the GPCTR_* family. I've read somewhere
else that this card does not have an hardware counter, is that exact?
I'm a beginner in this field, so i don't know what are possible alternative solution to my problem (if any).
Thanks for any help.
walter

Thanks for your reply.
I don't know actually whether i need to use counter-related functions. My problem is the following:
I need to sample 8 digital signals with a frequency of 10khz. Every signal have a duration of a few seconds in time, and they come from sensors attached to a train's railway. Acquisition begins on the first rising edge of a signal (which coincide with the passage of the train), and end with user input (which should be after the train has passed).
It would be of great help if you can point me to a relevant example, or give me some basic guidelines on our to proceed. If you need more information, please just ask.
thank you very much.
walter

Data acquisition with highly accurate GPS time stamping (hh:mm:ss:sss UT)

A research group has developed a data acquisition system dedicated to daily observations of solar phenomena at radio waves using high time resolution (5-100 ms).
First, the analog signal from the antenna (1000-2500 MHz) is sent to a spectrum analyzer (HP8559-A). After that, the analog signal is digitized during 5 minutes in a NI USB-6009 device connected to the PC, before to be stored in a file. By that time, other acquisition data cycle is restarted and so on up to the end of day.
However, we need timestamp (UTC) the solar data at the beginning and end of each sample of 5 milliseconds, during all acquisition process, in order to have the UTC time information of recorded solar events. So, a time resolution of at least 1 ms is required.
A software permit us to read recorded data and visualize corresponding spectra during last 5 minutes. However, we need UTC time information in the format hh:mm:ss.sss UT. Then, UTC millisecond is important for us, but not available yet.
To solve this problem, we are searching for a high accuracy timing GPS receiver (on the order of microseconds or nanoseconds), with at least three significant digits of precision (UT time in milliseconds) and which give us the UTC signal at least each 5 milliseconds or even better (1 ms). However, most GPS receivers only outputs 1 PPS (Pulse Per Second = 1000 millisecond).
Then, we are open to a better addressing on how to solve this problem !!
We know that GPS time synchronization with PXI-6608 can be used to precisely timestamp data acquisition, but we have to solve this problem with a lower cost. Also, we require a PCI interfacing instead of PXI.
Do we have to use a timer card? How do we use a timer, GPS and USB-6009 to timestamp data acquisition? Does the NI PCI-6602 solve the problem?
Obs:
The data acquisition software was developed in C++ Builder to run on a PC (Pentium III 2 GHz) under Windows XP environment. We used the NI-DAQmxBase driver to sample the signal from the NI USB-6009.
We are sure your expertise can help us on this matter.
Regards,

I better explain my problem in the thread How to timestamp continuous analog data acquisition using USB-6009 and GPS timing board?
We are considering to use the PCI-1588 or a GPS timing board (low-profile slot too), but I´m not sure that the USB-6009 can be used to solve the problem.
How to syncronize the data acquisition and timestamps using USB-6009 and PCI-1588 with external GPS?
In other thread I would appreciate any suggestions for GPS timing board and PCI-1588 too.
Regards,
Lilian

Why ACK should be deasserted sometimes during the data acquisition with PCI-DIO-32HS burst mode handshaking?

My peripheral device sends 32-bit data to the DIO board serially with PCLK 6MHz, about 300,000 times totally. The phenomenan like I mentioned in the summary above happens, and it causes some data missings.
Though I know ACK is not always asserted as somewhere in the NI database says, I want to know why it happens. if I can. I wonder if it is just inevitable or not.
Do I only have to add some buffer memories to my device and make it watch on the ACK changing? Or, is there any other good way to avoid this problem?

Hi,
Burst mode handshaking protocol needs to conditions to be meet before data can be transfered. The PCI-DIO-32HS need to be ready to transfer data and the external device needs to be ready to transfer data.
The ACK line tells the external device when the PCI-DIO-32HS is ready and the REQ line tells the PCI-DIO-32HS when the external device is ready. When both are ready data should be transfered. This is the nature of Handshaking, guarenteed data transfer (when both devices are ready), but not at a guarenteed rate. Handshaking means that the two devices communicate with each other to determine when to transfer data.
The PCI-DIO-32HS ACK line is toggling low because the PCI-DIO-32HS is busy catching up with the given transfer and is not ready to receive m
ore data at this time. The ACK line is not something you can control, it is controlled by the PCI-DIO-32HS.
Your application may be better suited for use with Pattern I/O if you are not using the handshaking lines, ACK and REQ, to control the flow of data. Pattern I/O does not use handshaking lines and clocks data in on every rising edge of the clock. You may receive an error if your system can not keep up with the transfer rate.

Data acquisition with time stamp

Hi I'm using NI DAQ 6211 to acquire acceration, strain and temperature from a VI. I have made several modifications and my last two vis are attached. I need to get 1000 data points from a encoder and sampling the period is by far the best way to get acceleration considering my hardware.
Is there a way to ensure that all three variables are synchronised within a timestamp without the vi slowing down?
Sincerely
Ahmad
Attachments:
test_6.vi ‏57 KB
test_5.vi ‏50 KB

The problem lies in synchronising the acceleration with the load and temperature. For acceleration I'm getting a period from a counter with Implicit values (i.e. without specifying timing). I have set the number of samples to acquire to 1000 points and this task does not require sample timing. Post processing the period data in matlab gives me the acceleration.
Now my vi uses a Sample Clock with set number of samples being acquired for the load and temperature. This means that a set number of samples for load and temperature can be acquired and this time may not be enough to acquire the acceleration points; hence they cannot be mapped in time.
The period is implicit and I can't find a way to synchronise with the load and temperature that are acquired at a fixed sample rate. The bottle neck in this problem is to get the acceleration (period recorded) in sync with the load and temperature. If this can be done without any compromise to the speed of the vi then this problem is resolved.
I have attached the vis which will show the development to overcome this problem.
Sincerely
Ahmad
Attachments:
test_1.vi ‏50 KB
test_2.vi ‏49 KB
test_7.vi ‏49 KB

Data acquisition with tktds2xx.llb

Hello,
I use the "TKTDS2XX Read Waveform to Array.vi" from tktds2xx.llb to get data out of my Tektronix TDS 220 over the serial interface. When I made a measurement (trigger modus normal) I always get only the data up to the trigger point and afterwards I have to switch the oscilloscope off/on. Without making a measurement I can read all 2500 points (default setting).
Any suggestions?
Andreas

There is no easy to put a 2D array into a 2D array. We can only replace a subarray into a larger dimension array.
A For loop is the best way to handle it. For loops are very efficeint at handling arrays.
The attached VI (7.1) shows how to process multiple 2D arrays into a larger 2D array. There might be a slightly easier way, but I couldn't think of anything quick.
What it does is breaks the DAQ array down into single elements and then using 'Replace Array Subset', puts them in the initialized array one at time. I added some timing code at teh end to see how fast is runs the "Replacing". Average time on my P4 1.8GHz with 512Ram is 4ms. This was acquiring 1000 samples on 10 channels.
Ed
Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
Attachments:
Replace 2D Array.vi ‏3968 KB

Problem with data acquisition and motion control

I have PCI-6024E and PCI-7342 cards on a single PC. Servo motion control works fine when it goes alone or is accompanied by one point data acquisition in a while loop, but when I start data acquisition with specified sample rate, the motor moves with breaks.
Does anybody know what is the problem? Is it possible to fix it?

How are you performing your motion? Is it a position move or a velocity move? How are your triggering the data acquisition? Using breakpoints on the 7342? If so, are you using single breakpoints or modulo? How are you configuring the data acquisition rate? Are you triggering just the start to the acquisition and the unsing the daq scan clock or are you using the motion controller to send the scan clock itself?

Control references vs. global variables

I guess my question centers on the appropriate application of control references.
I am writing a complex program that has a state machine at the top level, and, for one frame of the state machine, a while loop containing a couple subVIs, each of which contains many subVIs. The lower-level subVIs are affected by buttons on the top-level VI. Information from the lower-level VIs must be shown on the top-level front panel within the loop. My question is: what is the best way to do this?
(I have a previous version of the program that I wrote that keeps just about everything on the top level so that I can update the front panel, but this is not at all modular.
In addition, I considered breaking things up into more than on
e front panel, but this doesn't seem to be a good option for this section of this program.)
Last week I read about control references, and decided that this could be the way to deal with this issue. I have not worked with them before, so I want to know: Are control references an appropriate solution for this issue? Is it good programming practice to use them, especially to update data on charts and graphs? How do they compare programming-wise and efficiency-wise to global variables?
Global variables are another solution, I think, but I would have way too many variables to update. I think the advantage with global variables is that one could just insert a global variable in a subVI and not have to wire it up through the different subVI levels, which one would have to do (I think) with control references.
Can you offer any advice?
Thanks!

Paul,
The actual implementation of the solution is up to you. This is indeed a complex question.
I would offer the following advice:
On globals:
Try to avoid them. I try to restrict the use of globals to unidirectional. If you have ever dealt with a race condition, you will know why. Mistakes are often made with globals, and they are quite apt to become the biggest source of bugs in a program, especially in one as large and/or complex as your appears to be. If you must use globals, try using a shift register, or LabVIEW 2 style global instead. Basically, you use an unitialized shift register with two (or more) cases: Read and Write. This prevents race conditions, but only if the VI is non reentrant. However, implementation is still difficult.
Control References:
I also have read and heard about control references. I have had much use for them, for controlling the appearance of controls and indicators (and decoratiopns too, I guess...). However, I would caution you on using them to pass data around. This violates dataflow in a big way, as you are passing around pointers, instead of data. I believe this is difficult to implement, and even more difficult to keep straight. I personally recommend using them only for attributes of FP components, not for passing data.
So, what do I believe is the most elegant solution? I think a data server is your best bet. This is close to a LabVIEW 2 style global, but a little more active. Simply write all of your data into a subVI in any manner, a queue, a FIFO, LIFO, etc. Then, retrieve the data as desired. Buffering, queuing, etc are all handled by the data storage and retrieval subVI. It becomes sort of a small active database. The two sides (storage and retrieval) are independent of each other, and the code is all handled in the function. A basic version is a LIFO, Last In First Out, wherein the data is overwritten constantly. The data is then read by the reading VI, the front panel VI in your case, at any time, and the data is always the latest. You can add complexity as you need, such as making it a FIFO. This is done by simply writing the data to an array, then reading back the oldest value (by reversing the array and reading index 0.)
I believe this is an elegant solution to your problem. It does maintain dataflow, except that time is taken out of the equation, depending on how you look at it. It simplifies your program because you only need to do three things. Write the data handler, then drop in the function into the VI that writes, and the one that reads. It is also flexible in handling the data.
Good luck, and let us all know how you do.

Getting timestamp for analog acquisition with NI6110.

When I use the AI Read VI to get a waveform containing a sequence of scans, the waveform has a timestamp that presumably represents the absolute time of acquisition of the first scan as measured using the system clock. (I can't find any documentation on this, by the way. Where is this documented?) I notice that the AI Read VI can alternatively be used to return a "binary" array of measurements. For various reasons, I prefer to use this form of the AI Read VI, but I'd also like to get the timestamp that would be included in waveform returned by the waveform version. However, I don't want to call the AI Read VI twice, one time to get the binary array and a second time to get the whole waveform just so that I can g
et the timestamp. Is there a way to get this timestamp without getting the whole waveform?
Thanks,
Neal.

Thanks for replying.
I'm performing digitally triggered, buffered data acquisition with my 6110E, with the possibility of pretrigger sampling. The data I'm acquiring may extend several second before and after the trigger. Furthermore, my application may call the AI READ VI at some unpredictable time several seconds after data acquisition is complete. I'm assuming that the timestamp that would be returned as part of the waveform by the AI READ VI (whose exact nature appears to be undocumented) is calculated from the system clock at the time at which the digital trigger occurs, and wouldn't depend on when the AI READ VI was called. The article you referenced doesn't tell me how to do what I want. I want to get EXACTLY the timestamp that the AI READ
VI would include with waveform data, were it asked to return waveform data, but I want to use it to only return binary data. To the best of my understanding, the method described by the article for a obtaining a timestamp when binary data is retrieved provides no guarantee that the timestamp obtained will be the same one that would be returned as part of a waveform by the AI READ VI. Indeed, using the "Get Date/Time In Seconds" VI would seem, under the circumstances in which I would use it, to produce a timestamp that differs unpredictably from the time of the trigger by seconds.
Thanks,
Neal.

Can you use a control reference for a graph with two channels of data?

when i try to wire a 2-D array of data to the value property of a graph(strict control reference), it shows a conflict. The value data type only shows up as accepting a 1-D array input. I want to use control references to pass the chart data to my main vi. Will I have to change the waveform graph control reference into an array control reference to make this work?? This would require adding a while loop in the main vi to read the array data and update the graph data??

> when i try to wire a 2-D array of data to the value property of a
> graph(strict control reference), it shows a conflict. The value data
> type only shows up as accepting a 1-D array input. I want to use
> control references to pass the chart data to my main vi. Will I have
> to change the waveform graph control reference into an array control
> reference to make this work?? This would require adding a while loop
> in the main vi to read the array data and update the graph data??
I think the problem is that your waveform graph is set to take one type,
a 1D array of doubles, and you are wiring a different type. While
charts adapt to type when the data is wired to their terminal, they do
not adapt to data wired to their value property. If you change the
datatype of the graph from its terminal, then you should see the value
property change type also and you are set.
Greg McKaskle

Continuous data acquisition using NiDAQmx with a start and a stop trigger

I'm sorry if this has been answered many times before, I can't quite seem to find the answer I'm looking for.
I am using LabWindows CVI version 7 and NiDAQmx with a PCI6023E.
I wish to acquire data continuously using an external clock as a timebase - I am happy with this.
I wish the acquisition to start when an external signal (say on PFI7) goes high. I am also happy with this.
What I also need is for the acquisition to stop when the signal on PFI7 goes low, or possibly when a signal on say PFI8 goes high. I'm not too concerned about which approach to use.
How do I stop the acquisition with an external signal?
Thanks in advance,
Crispie

I don't have CVI installed, but I've attached screen shots of a LabVIEW program that I believe accomplishes what you are trying to do. Translating it to the C API should be straight forward. I'll try to explain what the program is doing since it's using some of the more advanced features of the driver. Also, the DAQ device you are using doesn't support a true "stop" trigger so I'm using a reference trigger to get as close to the desired functionality as possible.
First, the program configures a finite acquisition that uses both a start trigger and a reference trigger. The acquisition is using an external sample clock and will acquire 4 samples (2 pre-trigger samples and 2 post-trigger samples). Four may seem like an odd number here, but it allows us to emulate the functionality of a stop trigger as close as possible. Given this configuration, you must acquire at least 2 samples before the "stop" trigger is recognized, and you must acquire 2 more samples after the "stop" trigger is recognized. Hopefully this restriction is acceptable. You can always discard the last two data points after the stop trigger if they're not of interest, but you're stuck always acquiring at least two points between when the start and stop triggers are recognized.
The program also overrides the default buffer size and read position. By default, the DAQmx driver will pick a buffer size exactly big enough to fit the pre-trigger and post-trigger data (4 samples in this case) and will begin reading data from the start of the pre-trigger data. Explicitly allocating a larger buffer will allow your acquisition to execute without receiving buffer overflow errors, and changing the default read position will allow you to read all of the data between the start and stop triggers as it is acquired and not just the pre-trigger and post-trigger data.
Finally, the while loop takes care of reading the data. In this case, the loop continues to read data until the task is done and there are no longer samples available for reading from the buffer. The number of samples read per iteration is the lesser of the user specified amount or the number of samples available for reading from the buffer.
I hope this helps. Good luck.
Attachments:
Stop_Trigger1.JPG ‏40 KB
Stop_Trigger2.JPG ‏43 KB

PC reboots during Labview controlled data acquisition

Hi,
I'm using LabView to control the acquisition of a large number of gamma spectra and whenever the system gets to the ~700th data acquisition the PC reboots itself. There is no sign that the Labview software has crashed, the PC just goes dead and reboots. This problem only happens when using LabView. After a data acquisition a data file is saved to the hard drive, the files are only 12KB in size and I have 1GB of RAM, so I don't think it's a memory problem.
Would appreciate any help!
Thanks

hi there
Are there any entries in the system events list (assuming MS Win) or in some application logs?
You said "This problem only happens when using LabView". Does this mean you can acquire data without problems when using another language than LabVIEW? if possible I'd try to create a basic app in some other language to check if the problems depend on the hardware or on the application.
Can you provide some information about your platform and post some code (pls. don't forget required additional files lile driver DLLs etc.)
Best regards
chris
CL(A)Dly bending G-Force with LabVIEW
famous last words: "oh my god, it is full of stars!"

Top level application structure with parallel data acquisition

Hey all LabVIEW-forum members!
I have some experience programing LabVIEW, but mostly concerning smaller for the simplest form of data acquisition. Now I need to develop a larger application that might be continuously run for several weeksin a row and for that reason I woiuld like to make sure the application structure is stable! I turn to you in hope of some input regarding the most suitable approach to my problem or some pointing in a good direction.
-The project involves making hardware communication with a few different hardware interfaces, such as GPIB and NI’s DAQ-card (analog and digital reads/writes on PCI-6221).
-Save acquired data to disk.
-The communication and data save are based on condition of elapsed time (for example there could be a need to make parallel analog measurements med DAQ-card every 5th minute but GPIB-measurements every 30th second).
-At the mean time I would have to regularly the status of the test object and update the user interface. (However, while in test the user won’t be allowed to interact with the application other than to monitor the UI or pause the test).
The project isn’t really time critical (in case I need to make one type of data-acquisition while another one is already initiated, they can be carried out in sequence).
I’ve started with programmatically control the user interface by using the “Top Level Application Using Events”-template and produced code that will let the user set up a new test or load an existing test. All the data concerning the status and configuration of the test I’ve saved in two clusters that can be passed along to different events.
I’ve reserved one subdiagram in the event structure for the actual execution of the test. It is the structure of this subdiagram I am a bit confused about…
Could I use another while-loop/event-structure inside this subdiagram and use user-registered events for the different data acquisition? Or is there some type of state-machine that is better suited to monitor time elapsed and can make a transition to a suitable state when it’s time to make any of the hardware measurement required? It would be nice to avoid using polling loops but maybe that is best way to go?
I’ve checked the “Continuously Generate Occurrences.vi”-example and that might be a way to go? What seems to be good with this approach is that I could let the different parallel hardware acquisitions actually be parallel, right?
I am really confused right now, hope someone has some helpful inputs!
Regards
Oscar

This post here can be proved as a great starting point for your application.
I am not allergic to Kudos, in fact I love Kudos.
Make your LabVIEW experience more CONVENIENT.

Data acquisition loop with queue

What I would like to do is have a data acquisition loop that samples a load cell at 500Hz and have another loop that runs much slower to run a state machine and display some data in real time. The reason I want to sample the load cell so fast is to filter out some noise. Making producer/consumer loops with a queue kind of makes sense but I don't really care about all of the samples, I just want to be able to read a real time filtered signal at certain times. I looked at having just two parallel loops, one to acquire the data and the other to run a test and retrieve a real-time signal when I want but not sure how to pass data between the loops without using a queue. You can do it with local variables but you are at risk of a race condition. I hope this make sense. I am sure this is a simple problem I just don't know what direction to go. Thanks

Good Evening secr1973,
It sounds like you are on the right track. You already know about the producer/consumer architecture; this is almost always the first step to the separation that I think you are after.
The step that I think you are missing is a Case Structure around the enqueue element VI. You likely have some event or specific pattern that you are looking for in the input signal. You can have the output from this algorithm (likely a boolean) determine which case of the Case Structure to execute (Case 1: enqueue the element or Case 2: Do not enqueue the element).
This, of course, leads to processing being done in the producer loop, which is quite the opposite of what you are trying to accomplish with the producer/consumer architecture. You will have to decide if your processing is very simple or more complicated.
If it is easy/fast, you can likely get away with doing this processing in the producer loop. My guess is that your program falls under the category of do-it-all-in-the-producer loop because you are only acquiring at 500 Hz.
If the application requires faster acquisition rates or if the logic is going to require some processing, you may want to implement a double layer producer/consumer architecture. In this setup, you would pass all of the data from the DAQ producer to a second loop (using queue #1) that determines what to do with the data (to enqueue or not to enqueue...) and, if appropriate, write to a queue (queue #2) that the third loop can read. The third loop would be where your state machine executes.
If you have a quad core machine, each of these steps will execute on its own core. If not, you will have a little more thread swapping; not a huge concern in most cases. Here, we get into the art of programming more than the science.
In any event, I think you will be OK with a little processing for the enqueue or not algorithm in the producer loop.
Regards,
Charlie Piazza
Staff Product Support Engineer, RF
National Instruments

Data acquisition with control references

Similar Messages

Maybe you are looking for