LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Architecture Question / Chained Loops

Solved!
Go to solution

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.

 

 

 


 

 

 

0 Kudos
Message 1 of 25
(2,847 Views)

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

0 Kudos
Message 2 of 25
(2,841 Views)

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?

 

0 Kudos
Message 3 of 25
(2,838 Views)

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?

 

 

0 Kudos
Message 4 of 25
(2,835 Views)

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

0 Kudos
Message 5 of 25
(2,826 Views)

"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?

 

0 Kudos
Message 6 of 25
(2,823 Views)

I'm queuing acquired data by the way - to be logged in another loop (to not slow down DAQ of course).

 

 

0 Kudos
Message 7 of 25
(2,822 Views)

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

0 Kudos
Message 8 of 25
(2,818 Views)

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

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 9 of 25
(2,814 Views)

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

0 Kudos
Message 10 of 25
(2,805 Views)