conditional occurence wait

[Gabi1]

I tought this question fits better here than on the NI forum.

Lets say i have a situation with both a notifier and an occurence wait (or for that matter, two unrelated occurence wait).

I want my piece of software to perform if either one of them has returned a value. the only way i found to do it is to use the "wait on notification from multiple", but it doesnt always fits my needs (mainly because some software i have already has occurences...)

any idea?

[Kevin P]

I'd think there are 2 basic options:

1. Use a polling loop such that your "Wait" calls have a very short timeout. Then check the boolean "timeout" outputs to determine whether you've received an occurrence or notification. You'll burn a little extra CPU doing the polling, and your reaction time will be throttled a bit when one thing fires but the other has to wait for its timeout before you react.

2. Have the reaction code use its own private internal occurrence. Your main code waits for that private occurrence to be set. One bit of parallel code will wait for the external notification, then fire the private occurrence. Another bit of parallel code does the same with the external occurrence. Whichever external event happens first will allow you to react to the private occurrence.

-Kevin P.

[mross]

QUOTE(Gabi1 @ Sep 19 2007, 09:44 AM)

I tought this question fits better here than on the NI forum.

Lets say i have a situation with both a notifier and an occurence wait (or for that matter, two unrelated occurence wait).

I want my piece of software to perform if either one of them has returned a value. the only way i found to do it is to use the "wait on notification from multiple", but it doesnt always fits my needs (mainly because some software i have already has occurences...)

any idea?

Since you haven't shown your VI it is hard to say much.

I wonder why you have notifiers at all.

It is extremely easy to check two values inside a while loop, put the values in a shift register, next time the loop runs see if the new values are different, if one has changed (or by whatever logic you desire) then do some specific action pertinent to that logical conclusion.

I would say in general you do do not want to use notifiers if a more conventional method works.

Mike

[Gabi1]

QUOTE(Kevin P @ Sep 19 2007, 05:04 PM)

I'd think there are 2 basic options:1. Use a polling loop such that your "Wait" calls have a very short timeout. Then check the boolean "timeout" outputs to determine whether you've received an occurrence or notification. You'll burn a little extra CPU doing the polling, and your reaction time will be throttled a bit when one thing fires but the other has to wait for its timeout before you react.2. Have the reaction code use its own private internal occurrence. Your main code waits for that private occurrence to be set. One bit of parallel code will wait for the external notification, then fire the private occurrence. Another bit of parallel code does the same with the external occurrence. Whichever external event happens first will allow you to react to the private occurrence.-Kevin P.

i tried the polling option (was my first approach too), but did not like it at all, as it stalled the rest of the software. the whole idea of waiting on occurence is that there is no cpu overhead.for solution 2: do you mean an occurence that could be fed by two occurence generators? i am not following

QUOTE(mross @ Sep 19 2007, 05:12 PM)

Since you haven't shown your VI it is hard to say much.I wonder why you have notifiers at all. It is extremely easy to check two values inside a while loop, put the values in a shift register, next time the loop runs see if the new values are different, if one has changed (or by whatever logic you desire) then do some specific action pertinent to that logical conclusion. I would say in general you do do not want to use notifiers if a more conventional method works.Mike

we must be talking about something else. the idea of "wait on notification", or of occurence, is that the piece of software (the loop), is paused until released.

[ned]

QUOTE(Gabi1 @ Sep 19 2007, 09:44 AM)

Lets say i have a situation with both a notifier and an occurence wait (or for that matter, two unrelated occurence wait).

I want my piece of software to perform if either one of them has returned a value. the only way i found to do it is to use the "wait on notification from multiple", but it doesnt always fits my needs (mainly because some software i have already has occurences...)

any idea?

Is there any reason you must use an occurrence rather than a notifier? If not, then I'd suggest you use a single notifier, to which you can send a notification from multiple places. If the notifier might need to contain different data depending on the source of the notification, use a cluster, or use a variant with an attribute that indicates how the variant should be converted to to usable data.

[mross]

QUOTE(Gabi1 @ Sep 19 2007, 11:23 AM)

i tried the polling option (was my first approach too), but did not like it at all, as it stalled the rest of the software. the whole idea of waiting on occurence is that there is no cpu overhead.for solution 2: do you mean an occurence that could be fed by two occurence generators? i am not following

we must be talking about something else. the idea of "wait on notification", or of occurence, is that the piece of software (the loop), is paused until released.

Maybe your loop is paused, but I am talking about something different.

The loop I am suggesting continues looping constantly. The "pause" is due to the condition of the inputs. If neither input has changed since the last iteration, then a case structure inside the while loop chooses to do nothing, but when one of the inputs has changed then the case structure runs some other operation and is not "paused." The condition of no change runs a "do nothing" operation - same as pausing in terms of physical result, but the loop is running always.

There is no notification. The values are simply read in whatever manner that is done. If the values have changed a different procedure is run.

Why don't you show us your block diagram in an image or downlioad the VI so we can test it. It is not helpful to guess from the small amount of information you have given us.

Mike

[Gabi1]

thanks for your response.

my request has two main reasons:

1) mainly aestetical. i am looking for an equivalent function to "wait on notification from multiple", in situations i do not need to pass data, yet has to wait on one from multiple notifications.

2) added funtionality: the wait on notification release an error if one of the notifiers is released. by definition the occurences do not get released. that avoids getting an error and a "stop waiting".

[mross]

QUOTE(Gabi1 @ Sep 19 2007, 02:02 PM)

thanks for your response.

my request has two main reasons:

1) mainly aestetical. i am looking for an equivalent function to "wait on notification from multiple", in situations i do not need to pass data, yet has to wait on one from multiple notifications.

2) added funtionality: the wait on notification release an error if one of the notifiers is released. by definition the occurences do not get released. that avoids getting an error and a "stop waiting".

http://lavag.org/old_files/monthly_09_2007/post-9210-1190224724.png' target="_blank">

Just what to you mean "Pass" data? What is the data? What causes the data? Are you reading a digital line or something? What are the occurrences?

Scratch that.

What are you DOING? I am clueless what the function of this may be. If you are transparent with what you are trying to accomplish at a higher level, you may surprised what useful responses you may get.

[Gabi1]

well i'm using notifiers quite a bit .i just love notifiers and queues . there is something in the idea that you can put in, and retrive, data from somewhere in the computer universe, that just make me feel good.

anyway, i find notifiers extremely usefull in producer/consumer loops, or master slave configurations. however, i saw the other day on NI forum somebody trying to pause a DAQ loop, from an event structure. that made me wonder if i could pause the whole loop !, optimising CPU for other apps in the program, like analysis. so in the state machine loop, there would be a pause state, driven by one or several notifiers. as i said before, notifiers still have some disadvantages, when the sole purpose is to notify. the occurences are just better elements for that - in case one could have a function like "wait on multiple occurences".

[Kevin P]

QUOTE(Gabi1 @ Sep 19 2007, 11:23 AM)

1. i tried the polling option (was my first approach too), but did not like it at all, as it stalled the rest of the software. the whole idea of waiting on occurence is that there is no cpu overhead.for solution

Well, there's a tradeoff. I wasn't meaning you should poll as fast as possible with the timeout to 0. I was thinking of a timeout of anywhere from 5-50 msec, depending on the reaction time you need. A bit of a compromise but easy to implement.

QUOTE(Gabi1 @ Sep 19 2007, 11:23 AM)

2: do you mean an occurence that could be fed by two occurence generators? i am not following

Attached is a picture of what I *meant* to mean. As I threw it together, I realized that all the Wait and While Loop termination issues can get non-trivial pretty quickly. If you use a -1 timeout to "wait forever", you need to be sure to have a foolproof method to shut down those Wait primitives. This is easier with Notifiers which can be forcibly destroyed elsewhere in your app's shutdown code, forcing any pending Waits to return with an error. The external occurrence should probably be set here in this vi after completing the code you need to run.

You may also need to carefully consider the "ignore previous?" inputs, depending on the nature of your app. You can get stuck with some subtle race conditions when those are set "True." My typical solution to that is to wrap the Wait in a while loop and do special things on iteration 0 to deal with any old, "stale" occurrences / notifications. Usually this means a timeout of 0, ignore previous=False, and do nothing else until iteration 1.

Anyhow, given the alternative here, polling starts looking not so bad, eh?

-Kevin P.

[mross]

QUOTE(Gabi1 @ Sep 19 2007, 05:04 PM)

well i'm using notifiers quite a bit .i just love notifiers and queues . there is something in the idea that you can put in, and retrive, data from somewhere in the computer universe, that just make me feel good.

anyway, i find notifiers extremely usefull in producer/consumer loops, or master slave configurations. however, i saw the other day on NI forum somebody trying to pause a DAQ loop, from an event structure. that made me wonder if i could pause the whole loop !, optimising CPU for other apps in the program, like analysis. so in the state machine loop, there would be a pause state, driven by one or several notifiers. as i said before, notifiers still have some disadvantages, when the sole purpose is to notify. the occurences are just better elements for that - in case one could have a function like "wait on multiple occurences".

With producer consumer if you have a Pause case in the consumer loop, you can insert the queue call to that Pause case using an event driven producer loop. If you want the Pause case to be immediately the next operation, then use the Enqueue Element at Opposite End to run the Pause case as soon as the current operation is completed. If you put a while loop in the Pause case it can wait for a user input before releasing the consumer queue to perform the next queued function - whatever is appropriate to happen before the Pause is released.

This could be deterministic pausing only after allowing the Consumer to complete whatever it is doing and not stop at some random point during its progress. Depending on when the Pause issued, the various activities previously queued up might or might not need to run unimpeded. You could test for these in the Producer loop or in the Pause Case whichever is appropriate.

In your case where you wish only to give the CPU time to perform some other operation, the Pause function could be reading an LV2 global boolean until the interrupting operation sets that global to the "I have finished, proceed to the next operation" state. Since you were having trouble with unexpected behavior perhaps this method would be more dependable.

I still don't know why notifiers and occurrences are needed. I am probably being old fashioned. Liking them is not necessarily a great reason to use them.

Mike

[Aristos Queue]

The occurrences are *really* low level tools. The queues and notifiers are implemented using them. But the ability to do "wait on multiple" requires much more coordinated information than the occurrences have.

You mentioned that you use notifiers a lot, but not when you just need to signal because the notifiers transmit data and you don't have any data to transmit. In that case, consider just using notifiers of LVBoolean. The notifier will only allocate a single byte for its data, and you'll have the rest of the management structure for complexity of "wait on multiple".

[Rolf Kalbermatter]

QUOTE(Gabi1 @ Sep 19 2007, 04:04 PM)

well i'm using notifiers quite a bit .i just love notifiers and queues . there is something in the idea that you can put in, and retrive, data from somewhere in the computer universe, that just make me feel good.

anyway, i find notifiers extremely usefull in producer/consumer loops, or master slave configurations. however, i saw the other day on NI forum somebody trying to pause a DAQ loop, from an event structure. that made me wonder if i could pause the whole loop !, optimising CPU for other apps in the program, like analysis. so in the state machine loop, there would be a pause state, driven by one or several notifiers. as i said before, notifiers still have some disadvantages, when the sole purpose is to notify. the occurences are just better elements for that - in case one could have a function like "wait on multiple occurences".

As Aristos already mentioned the extra memory used for a skalar notifier won't really kill your memory at all. The occurrences on the other hand are not producer/consumer oriented and while multiple places can wait on the same occurrence their mechanisme is not in such a way that you could easily do the opposite at all.

On the other hand polling an occurrence with a small timeout, while not optimal, will not kill your CPU performance either.

Rolf Kalbermatter

[Gabi1]

Kevin, thansk for your implementation. yes it works this way, but given the complications, its attractivness is decreasing exponentially.

Mross, as you and Kevin says, polling will be easier in this case.

but all in all, my goal was to change notifiers to occurences. i guess i will stick with notifiers.

Aristos and Roflk: my main concern with the notifier, is just the fact that if one of the notifiers is released, the "wait on multiple" stop waiting and release an error (on top of the fact that graphically the occurence+ wire is a little more compact). but at this point you are right it doesnt worth reinventing the loop (hem.. the wheel) when one has notifiers so cool

Thanks everybody for your toughts and help !