08-03-2012 02:45 PM - edited 08-03-2012 02:49 PM
Hey guys,
So I had a quick question about Producer/Consumer loops.
I have a DAQ loop that I am trying to control - i.e. when to acquire data or when to go to idle mode.
At one point in time I want to acquire data continously, while at another point in time, I want this to stop and go to idle mode.
I was wondering what the best way to do this.
My exterior loop should will send the acquir signal, and time period later (1 or 2 secondes) will send a stop signal, then again, another start signal.
1. Use a notifier that sends a Cluster Notification (Variant + Command) --> containing some parameters I need to acquire + the command "Acquire".
2. Grab this Notifier using the Wait on Notification Signal
--> This will enter the Acquire State
3. resend the same identical notification causing it to loop.
OR
1. Use a notifier that sends a Cluster Notification (Variant + Command) --> containing some parameters I need to acquire + the command "Acquire".
2. Watch the notifications with a get notifier status function. When the notifier status changes to Acquire it will always Acquire and when another notification is sent (Stop) then the state will change.
The second one seems like the obvious solution but I'm wondering if there are any caveats to it - i.e. race conditions/general warnings to not use the get notification function...
Am not too familiar with some of the weird case scenarios and I've already been screwed over by Notifications skipping certain commands before - it was annoying to fix haha
Or actually.. if you have any other suggestions on how to make this achitecture work, I'm all ears.
Solved! Go to Solution.
08-03-2012 02:53 PM
Do you reconfigure the acquisitions while idle? You mention "parameters."
If all the acquisitions are the same (excpet possibly for the number of samples), I would suggest running a continuous acquisition and simply discard the unwanted data.
Lynn
08-03-2012 02:57 PM
I don't get it. So, I run the acquisition for ever, no notifications, nothing nada.
And I only take the data I want?
What difference does that make? At the end of the day, I'll need a notifier to tell me when I want/Don't want data?
08-03-2012 03:00 PM - edited 08-03-2012 03:01 PM
While idle, I do not reconfigure anything, basically. There is another state called "Parameter Change" which is triggered by the UI via the same notification channel.
The overall process is the following: I have a motor, It is doing a raster scan. I have programmed a Raster Movement VI to send commands to my motor. While the motor is moving, I want to DAQ and log that data.
My raster movement VI sends a GO TO commands to my motor. When I reach a certain location (notification from an encoder), I want to stop the motor. While the motor is in motion, I want to acquire data. So I want to send a notification to both move the motor and begin DAQ.
After my raster scan, which is composed of a multitude of stop, move and acquire, stop, move and acquire, stop move and acquire, I want to log all the data I have just collected.
If I simply collect all the data, then I have data while I am stopped, which I will need to identify with some sort of other notification - which will probably end up in my logging loop instead of my DAQ loop. It works, but what's the difference?
08-03-2012 03:17 PM
I have been using the continuous collection and throw away unsed data method since LV version 1.2. Just use the signal which you use to generate the notification.
A simple state machine should be fine. When it is in the motor moving state, log data. When it is in most other states, discard data.
Lynn
08-03-2012 03:34 PM
"Just use the signal"
Alright , I see what you mean. So at the end of the day, I'm just sending a notification to another loop (not the DAQ one but the logging one) right?
08-03-2012 03:35 PM
I'm queuing acquired data by the way - to be logged in another loop (to not slow down DAQ of course).
08-03-2012 03:46 PM
Yes. In the Dequeue loop just discard or use the data. Make sure that you dequeue often enough that the queue does not grow. Otherwise you will get stale data when you are ready to log again. You can use the Get Queue Status funtion to monitor the number of elements in the queue to make sure it is not growing.
Lynn
08-03-2012 03:57 PM
I'd set up a queue between the data loop and the logging loop. The logging loop would be very simple -- it would just log whatever data it receives. The logic for deciding which data is supposed to be logged would belong to the data loop, which would then either enqueue it or discard it. I'm pretty sure that's what Lynn meant about throwing the data away.
Another thing I've done is to have a central data handling and dispatching loop. It receives DAQ data via Queue. It then decides whether to send it to a logging loop via a different Queue. I would often do some degree of data processing as well, and put the results in a Notifier which can be used for a live display and perhaps some process controls or safety monitoring.
-Kevin P
08-03-2012 04:39 PM
Where to make the decision and where to discard the data really comes down to how you have the program set up. Discarding at the DAQ loop makes sure that no excess or stale data is in the system. On the other hand, I have a system where the decision about what data to save is based on analysis of the data. In that system I need to do some processing on the data before deciding whether to keep it. Throwing it away at the DAQ loop is not an option. This is somewhat like Kevin's central data handling and dispatching loop.
In your case it appears that you have a simple command in what you called the exterior loop, so it may be appropriate to discard at the DAQ loop.
Thanks, Kevin, for pointing out these options.
Lynn