Queues and notifiers - please help?!

[Erik_1]

Can someone explain to me how to effectively utilize queues and notifiers? I understand the fundamental difference between the two but I am having a difficult time establishing when I should use one over the other or how to utilize both of them at the same time.

Essentially what I currently have is a master loop that contains (among other things) an event structure. The event structure contains controls which dictate when notifiers are sent and destroyed. The notifiers “turn on” other loops (all within the same sequence frame as the master loop). These other loops are used for various controls, data logging, etc. Within some of these “sub-loops” I would like to step through a sequence of events – this is where I’m having trouble.

Here is what I would like to happen: When the user clicks a certain button, a notifier is sent to sub-loop-A and it begins to run. The user then selects from a pull-down menu one of a few different options. Depending on the option selected, a specific set of events occur (whose progress is dictated by both user interaction (pressing buttons) and successful events (data being fed back). I would then like the sequence to “reset” and allow the user to select another option from the same menu – I don’t want to exit all the way back out to the main loop and force the user to re-select sub-loop-A again. However, if from the front panel the user selects sub-loop-B I would like sub-loop-A to exit and sub-loop-B to begin running. I have attached a sample of the basic layout I have so far (in LV 8.2) – I apologize in advance – I’m still learning labVIEW and I’m probably not going about this in the most efficient manner.

A couple other things to note – I’m trying avoid polling because speed is important. Also, the template I’ve attached is far from complete – it will require additional sub-loops and additional sequence loops (which I have been advised to use que-based state machines - which I'm also not familiar with).

Any assistance you guys can provide would be great – examples, web links, etc.

Thanks again!

-Erik

[becktho]

Hi Erik

Could you post it as LV8.0 as well?

Thomas

[mikeporter]

I see what you are trying to do, but you are pointed in a slightly wrong direction. What you need is an application that has exactly two loops - and no sequence structures. The way to insure sequential operation of things that need to be performed sequentially is dataflow. In other words, let the availability of data gate the execution of operations. This is a very different approach from more primitive programming languages like C++, but it is the way that LV works best.

The two loops are as follows:

• Loop one is the event-driven loop and its only job is to manage the user interface and control operation of the other loop through queues and user events.
• Loop two combines the functionality of the other three loops. It is responsible for performing the actual test and the utilizes the structure of the sequencer I referred you to. It performs the different actions by using a command that you pass to it in a queue to look up the list of plugins that need to be called to perform that task.
  

In general, use queues when you are passing a series of things that will be processed one after the other. Use user events (or notifiers) when you need something done NOW regardless of what else is happening - you can think of them sort of like software interrupts.

Mike...

PS: contact me back-channel when you have a chance...

[Erik_1]

Here is it in LV8.0. Thanks for all the help!

-Erik

[Erik_1]

Thanks again Mike - I sent you an email at mlportersr@embarqmail.com.

[Erik_1]

O.K. - I am still struggling with this. Disregard the last VI I posted - here is a much more compact and commented one (in V8.2 and V8.0). I have received some great feedback from you guys but I'm still not seeing how to lay this out properly - this VI obviously doesn't work but I think it should give you an idea of what I'm trying to do. Any assistance would be greatly appreciated - also, since I'm a beginner feel free to give me good habit/bad habit advice.

Thanks!

-Erik

[RavensFan]

In your second loop, you have two wait on notifiers in a row.  Is that what you want to do?  I believe it would wait at the first for a notification, get that, move to the second and wait there until another notification comes in.  Which won't happen unless the change control command value changes twice.  (Wait a minute, last minute observation.  Maybe that is happening since it is value change.  It will get a new value when pressed, and get another new value when the control is read and latches itself back.  Perhaps you would want to set it to Mouse Up instead of value change.  Or put the case structure in another case structure so it only executes when the value is true.)

Why are you using extended precision numbers for your notifiers?  It looks like a integer would be fine.  Probably not a huge difference in memory, but it is unusual to specifiy an extended precision representation.

In Send control command event, you have a case structure.  In each case you obtain a notifier for auto and manual, but you only send a notification on one.  Why obtain the other?

You may want to obtain your notifiers at the beginning of the program and pass them them to each loop and through each loop using shift registers.  I believe each time a notifier is obtained, it uses just a bit more memory.  If this is a long running programming, it may lead to memory leaks over time.

Just a few comments on what I observed.  Maybe some things don't apply because this is example code rather than your actual code.  Otherwise your code seems neat and orderly, and I don't see why this shouldn't work.

[RavensFan]

I do see a problem in the operation in that if I hit the stop button, the inner loop of auto starts running like crazy.  I think it is because if the wait for notifier returns an error due to it getting destroyed when the stop button is hit, it still sends out the notifier as the default, which starts the default case structure operating and thus its inner loops.  And they don't stop.

You should probably get the loops out of the default case.  Any case structure should have a default case that does nothing. 

A better practice would be in the stop button case, send out a notifier that is for a specific exit case that tells all outer loops to stop.  Then destroy the notifiers.

In your 4 loops, you have the stop button NOR'ed with the other condition rather than OR'd.  So if you say stop = true, the OR results in a True, but the negation turns that into False and the loop does not stop.  In the top button, you had the enum compared to exit, then that was NOT so the loop would stop immediately if the enum was anything but Exit.  Because the Boolean logic in these loops was convoluted, I think the loops weren't behaving the way they should.

I made some modifications to clean up the default case and the boolean stop loop logic in each of the loops.  See attached.

[Erik_1]

Thanks for all the great feedback. One of my questions was if this was an appropriate use of notifiers? For the past few hours I have been trying to figure out how to use queue's and only two while loops (like mikeporter suggested) but I just don't see it. It's painful to be a novice!

Thanks again!

-Erik

[RavensFan]

Yes, I think the is an ideal situation for using notifiers.

I decided to go one step further and clean up the code using only single obtain notifiers and passing the references around by wire.

Message Edited by Ravens Fan on 06-29-2007 12:14 AM