Is it possible to wait on a queue and on a notifier at the same time?

[Mark_Yedinak]

You can code your event loop to only queue the value of the slider when it has settled. Essentially you are coding a debounce. This might get tied in with the timeout event case. to work properly. It isn't that difficlut to compare the time on events so you effectively filter them.

[JÞB]

What the example doesn't do is prevent multiple silder commands in the queue.  This mod handles that.  the 0,Default case is error pass through.  Don't forget the SRs in case the queue is empty, they preserve error and queue information.

[AStankov]

---

@crossrulz wrote:

The idea here is to send the set value (from the slider) through the notifier and send the command through the queue.  When the consumer loop gets the command, it will read the notifier for the latest data point and go to work.  Now if the user changes a bunch of stuff while a "long" acquisistion is happening, the notifier will keep being overwritten; it will only keep the last commanded value.  The queue will get multiple commands, but only the last value will be worked on due to the notifier.  The remaining commands will check the notifier, see that there's no new data, and skip to the next command.

---

Now I understand. This sounds nice and I will try it. One problem I can think of is when during a long acquisition the user sets the slider to lets say 5, then clicks start acquisition and then sets the slider to 10. Then the started acquisition will start with 10, not with 5, i.e. the order of events is not retained. I have to check again if this a problem. On the other hand disabling some buttons to prevent such things is probably not a good idea for short-lasting continuous acquisitions. Actually queueing up commands is nice but seems to lead to serious problems if they need longer to be executed.

[AStankov]

---

@Mark_Yedinak wrote:

You can code your event loop to only queue the value of the slider when it has settled. Essentially you are coding a debounce. This might get tied in with the timeout event case. to work properly. It isn't that difficlut to compare the time on events so you effectively filter them.

---

I had actually tried this already, but this does not prevent the user from setting the slider to 5, wait for a second, set it to 10, wait for a second and finally set it to 0. All values will be applied one by one on the hardware if the currently running acq lasts longer.

[AStankov]

---

@JÞB wrote:

What the example doesn't do is prevent multiple silder commands in the queue.  This mod handles that.

---

Jeff, thank you for the code. This looks more time consuming but will ensure, that only one slider element is kept.

[JÞB]

---

@AStankov wrote:

---

@JÞB wrote:

What the example doesn't do is prevent multiple silder commands in the queue.  This mod handles that.

---

Jeff, thank you for the code. This looks more time consuming but will ensure, that only one slider element is kept.

---

Give Tim the big assist on that!  The actual operations are relatively painless with a modern CPU especially in a loop reacting to user input speeds (we are pretty slow aren't we?.)  Note that the presidence of the slider command is preserved we just update the notifiers data if slider command is alreay in the queue.  Pretty slick huh?

[AStankov]

---

@JÞB wrote:

Give Tim the big assist on that!  The actual operations are relatively painless with a modern CPU especially in a loop reacting to user input speeds (we are pretty slow aren't we?.)  Note that the presidence of the slider command is preserved we just update the notifiers data if slider command is alreay in the queue.  Pretty slick huh?

---

Thanks Tim (I think this must be crossrulz :-))! I am just curious if using a queue and a notifier has any advantages here, or could I use a functional global var instead of the notifier as well? Polling the notifier or the FGV after the dequeue should be the same IMHO 🙂

[JÞB]

---

@AStankov wrote:

---

@JÞB wrote:

Give Tim the big assist on that!  The actual operations are relatively painless with a modern CPU especially in a loop reacting to user input speeds (we are pretty slow aren't we?.)  Note that the presidence of the slider command is preserved we just update the notifiers data if slider command is alreay in the queue.  Pretty slick huh?

---

Thanks Tim (I think this must be crossrulz :-))! I am just curious if using a queue and a notifier has any advantages here, or could I use a functional global var instead of the notifier as well? Polling the notifier or the FGV after the dequeue should be the same IMHO 🙂

---

Good question!  FGV vs Notifier as offered.  To the best of my knowledge the syncronization primitives are slightly higher in performance than a subiv call. So the performance would depend on the sparseness of the queue.  if there are normally few or no elements enqueued the solution offered would be better, if there are a great many elements in the queue two calls to a fgv (and an alternate slider command filter, such as a dedicated single element queue) could be slightly better.  Again, this problem is user interface so CPU optomization is not really the largest problem.  Getting the users desired actions to execute is the goal. 

And yes Tim is Crossrulz, sorry for any confussion.  I tend to refer to my fellow LabVIEW Champions familiarlly out of respect. Just a minor point of forum ettiquette that is probably not written anywhere and I made up in my own head- no worries.

[crossrulz]

---

@AStankov wrote:

I am just curious if using a queue and a notifier has any advantages here, or could I use a functional global var instead of the notifier as well? Polling the notifier or the FGV after the dequeue should be the same IMHO 🙂

---

There's a big difference.  With using the construct I showed, the notifier has a timeout to let you know that the value hasn't been updated.  I wouldn't bother flushing the queue and re-enqueuing (sp?) everything.  The notifier keeps the latest value.  If the value hasn't been updated, skip the action.  It is also a lot easier to code.

[AStankov]

---

@JÞB wrote:

Good question!  FGV vs Notifier as offered.  To the best of my knowledge the syncronization primitives are slightly higher in performance than a subiv call. So the performance would depend on the sparseness of the queue.  if there are normally few or no elements enqueued the solution offered would be better, if there are a great many elements in the queue two calls to a fgv (and an alternate slider command filter, such as a dedicated single element queue) could be slightly better.  Again, this problem is user interface so CPU optomization is not really the largest problem.  Getting the users desired actions to execute is the goal. 

And yes Tim is Crossrulz, sorry for any confussion.  I tend to refer to my fellow LabVIEW Champions familiarlly out of respect. Just a minor point of forum ettiquette that is probably not written anywhere and I made up in my own head- no worries.

---

Jeff, thank you for the clarifications. I am still thinking if I really need the notifier. If I use a queue that transports messages + data and if I have to dequeue all elements anyway (I think you are actually doing this by calling the flush), I could probably just replace a dequeued "slider" message with my updated "slider" message and get rid of the notifier. All other messages will be just reenqueued. If no "slider" message is found, I will simply enqueue my latest "slider" message at the end. I thought that dequeueing and reenqueueing the complete queue would not be very efficient but his is probably no big problem.