Occurrence - Revision history

AristosQueue at 15:37, 24 October 2011

2011-10-24T15:37:11Z

← Older revision		Revision as of 15:37, 24 October 2011
Line 1:		Line 1:
	There seem to be misconceptions about how exactly occurrences work and what exactly the "ignore previous" parameter on "Wait on Occurrence" (WoO) does. The following tries to explain, in a long and winded way, how they (functionally) behave:		There seem to be misconceptions about how exactly occurrences work and what exactly the "ignore previous" parameter on "Wait on Occurrence" (WoO) does. The following tries to explain, in a long and winded way, how they (functionally) behave:

	~~How Occurrences are "generated"~~: ~~When~~ a VI is ~~loaded (!) each "Generate Occurrence" function allocates exactly one unique~~ occurrence. ~~When~~ the ~~VI is running and this function is called it simply returns this one~~ occurrence ~~-- no matter how many times it is called (try putting one in~~ a ~~loop and examining its value using the probe~~, ~~it will always have~~ the ~~same number)~~. ~~If you stop~~ the ~~VI and run it again~~, ~~you will get~~ the ~~same value;~~ only ~~removing the VI from memory and loading~~ it ~~again will give you~~ a "~~fresh" value~~.		'''SHORT STORY:''' The following is the advice of LabVIEW's Chief Architect to use occurrences correctly:
			''First build a system which polls continuously for whatever it is the occurrence will signal. You need to be able to determine the state of things without an occurrence. This creates a correct, but inefficient busy waiting implementation. Once that works, add an occurrence to alleviate the inefficient waiting. Do '''not''' remove the actual polling. In other words, use the occurrence only to indicate that "it is probably a good time to check on that thing...".''
			[http://lavag.org/topic/14998-how-to-open-front-panel-after-n-milliseconds-unless-the-operation-is-done/page__view__findpost__p__90901 You can see an example of this usage in this LAVA post.]

	How ~~Wait On Occurrence (WoO) works: Each WoO functions~~ "~~remembers~~" ~~what occurence it last waited on and what time it continued (because the occurence fired or because of a timout).~~ When a VI is loaded (!) each ~~WoO is initialized with a non existing~~ occurrence. When ~~a WoO~~ is called and "~~ignore previous~~" ~~is FALSE there are four potential cases:~~		'''LONG STORY:''' How Occurrences are "generated": When a VI is loaded (!) each "Generate Occurrence" function allocates exactly one unique occurrence. When the VI is running and this function is called it simply returns this one occurrence -- no matter how many times it is called (try putting one in a loop and examining its value using the probe, it will always have the same number). If you stop the VI and run it again, you will get the same value; only removing the VI from memory and loading it again will give you a "fresh" value.

	The occurrence has never* been set -> in this case WoO waits		How Wait On Occurrence (WoO) works: Each WoO functions "remembers" what occurence it last waited on and what time it continued (because the occurence fired or because of a timout). When a VI is loaded (!) each WoO is initialized with a non existing occurrence. When a WoO is called and "ignore previous" is FALSE there are four potential cases:
	*The occurrence has been set since this WoO last executed -> WoO does not wait
	The occurrence has last been set before this WoO last executed and last time this WoO was called it waited on the same* occurrence -> WoO will wait		The occurrence has never* been set -> in this case WoO waits
			*The occurrence has been set since this WoO last executed -> WoO does not wait
			The occurrence has last been set before this WoO last executed and last time this WoO was called it waited on the same* occurrence -> WoO will wait
	The occurrence has last been set before this WoO last executed but last time this WoO was called it waited on a different* occurrence -> WoO will not wait!!!!		The occurrence has last been set before this WoO last executed but last time this WoO was called it waited on a different* occurrence -> WoO will not wait!!!!

	The first three cases are pretty clear, the last one may seem a bit strange. It will only arise if you have a WoO inside a loop (or inside a re-entrant VI in this loop) and it waits on different occurrences (out of an array, for example) or if it is inside a non re-entrant VI and the VI is called with different occurrences. These cases do generally not happen. The reason the WoO behaves this way is due to its implementation. Each occurrence "knows" the last time it has been fired, and each WoO remembers the occurrence it was last called with and what time it fired (or timed out). When WoO is called and "ignore previous" is FALSE, it will look at its input; if the input is the same as last time, it will look at the time of the last firing and wait depending on whether the time was later than last execution; if the input is not the same as last time, it will simply look at the time and wait depending on whether it has ever been fired.		The first three cases are pretty clear, the last one may seem a bit strange. It will only arise if you have a WoO inside a loop (or inside a re-entrant VI in this loop) and it waits on different occurrences (out of an array, for example) or if it is inside a non re-entrant VI and the VI is called with different occurrences. These cases do generally not happen. The reason the WoO behaves this way is due to its implementation. Each occurrence "knows" the last time it has been fired, and each WoO remembers the occurrence it was last called with and what time it fired (or timed out). When WoO is called and "ignore previous" is FALSE, it will look at its input; if the input is the same as last time, it will look at the time of the last firing and wait depending on whether the time was later than last execution; if the input is not the same as last time, it will simply look at the time and wait depending on whether it has ever been fired.

			A possible (implementation) problem: It appears that occurances are "remembering" that they have been set during previous invocations of the program. One would think that generating an occurance should create a clean "non-set" occurance. This problem can be illustrated in a program that has three parallel loops with an abortable wait in each using occurances. If the program is stopped with the stop button things are fine. But if one waits until one of the random stop conditions triggers the end of the loops (generated from the other loops), the next time the program is run, the loops will execute only once and not loop at all. (The random terminate condition in the actual program is an error occuring in some piece of equipment.) Either this is a bug, or we are completely wrong on the use of occurances. Our example here is using the occurances in the "do not clear previous" mode. We would think that we will not remember ccurances from previous runs of the program since a new clear occurance should be created with the generate occurance icon. In this instance we can not use the clear previous occurances mode since we need a single occurance to stop multiple parallel loops.

	~~A possible (implementation)~~ problem: ~~It appears that occurances are "remembering" that they have been~~ set ~~during previous invocations~~ of the ~~program. One would think that generating an occurance should create a clean "non-set" occurance. This problem can be illustrated in a program that has three parallel~~ loops ~~with an abortable wait in each using occurances. If the program is stopped with~~ the stop button ~~things are fine~~. ~~But if one waits until one of~~ the ~~random~~ stop ~~conditions triggers the end of~~ the ~~loops~~ (~~generated from the other loops~~), the next time the ~~program is run~~, the ~~loops~~ will ~~execute only once and~~ not ~~loop at all. (The random terminate condition in the actual program is an error occuring in some piece~~ of ~~equipment.) Either~~ this ~~is a bug, or we are completely wrong on the use of occurances. Our example here is using the occurances~~ in the "~~do not clear previous~~" ~~mode. We would think that we will not remember ccurances~~ from previous runs of the program since a new clear occurance should be created with the generate occurance icon. In this instance we can not use the clear previous occurances mode since we need a single occurance to stop multiple parallel loops.		The reason for the problem: The first time the occurrence is set because of an error, the loops terminate, but the "stop button" loop is still running. When you click on the stop button, the occurrence gets triggered again (unneccessarily) and the program stops. The next time the VI runs, the WoO will not wait because of this extra trigger; and since you'll trigger again in the "stop button" loop, the VI won't work until it's reloaded from disk.

	~~The reason for~~ the problem: ~~The first time the occurrence is set because~~ of ~~an error~~, the ~~loops terminate~~, ~~but the~~ "~~stop button~~" ~~loop is still running~~. ~~When~~ you ~~click on the stop button~~, the occurrence ~~gets triggered again (unneccessarily) and the program stops~~. ~~The next time the VI runs,~~ the WoO ~~will not wait because of this extra trigger; and since~~ you'~~ll trigger again in~~ the "~~stop~~ button" loop, the ~~VI won't work until it's reloaded from disk~~.		A solution to the problem: Due to this behavior of occurrences, it is clear that one cannot use the "timed out" flag to determine when the occurrence fired. You will have to maintain some global information about your state, let's say in a global boolean called "FINISHED". At the beginning of the program you would initialize it to false. If you have an error, set FINISHED to true, and then trigger the occurrence. After the WoO see if FINISHED is true (make sure you don't read the global until after WoO finished executing), if FINISHED is false continue with the loop. In the "Stop button" loop, also set FINISHED before you trigger the occurrence.

	A solution to the problem: Due to this behavior of occurrences, it is clear that one cannot use the "timed out" flag to determine when the occurrence fired. You will have to maintain some global information about your state, let's say in a global boolean called "FINISHED". At the beginning of the program you would initialize it to false. If you have an error, set FINISHED to true, ~~and then trigger the occurrence. After the WoO see~~ if ~~FINISHED is true (make sure~~ you don't ~~read the~~ global ~~until after WoO finished executing~~), ~~if FINISHED is false continue with~~ the ~~loop. In the "Stop button" loop, also set FINISHED before you trigger~~ the ~~occurrence~~.		BTW, if you don't like globals, you could use a VI with an [[Uninitialized shift register]] (LabVIEW 2 global), but the effect would be the same.

	~~BTW~~, if you ~~don't like globals~~, you ~~could~~ use ~~a VI with an [[Uninitialized shift register]] (LabVIEW 2 global)~~, ~~but the effect would be the same~~.		Comments: One may think that occurrences are quirky, a pain to use and that they should be avoided. One might be right! Occurrences are very low level and you often have to add functionality to them in order to use them effectively. In other words, they are not for the faint of heart. Anything implemented with occurences can be also implemented without them, but maybe not as efficently. What occurrences do is to allow you to program synchronization in a way that does not use polling, and is thus "cheaper" in processor time.

	~~Comments~~: ~~One may think that occurrences are quirky, a pain to~~ use ~~and that they should be avoided. One might be right! Occurrences are very low level and you often have to add functionality to them~~ in ~~order to use them effectively. In other words, they are not for~~ the ~~faint of heart. Anything implemented with~~ occurences can be also implemented without them, but maybe not as efficently. What occurrences do is to allow you to program synchronization in a way that does not use polling, and is thus "cheaper" in processor time.		''Note: National Instruments encuorages the use of Notifier operations functions in place of the occurences for most operations.''<br>

	~~''Note~~: ~~National Instruments encuorages the use of Notifier operations functions in place of the occurences for most operations.''<br>~~		[[Category:Synchronization]]

	[[Category:Synchronization]]		[[Category:Synchronization]]

Pbrooks100: added reference to NI suggested use of Notifier operations

2009-05-20T20:48:00Z

added reference to NI suggested use of Notifier operations

← Older revision		Revision as of 20:48, 20 May 2009
Line 21:		Line 21:

	Comments: One may think that occurrences are quirky, a pain to use and that they should be avoided. One might be right! Occurrences are very low level and you often have to add functionality to them in order to use them effectively. In other words, they are not for the faint of heart. Anything implemented with occurences can be also implemented without them, but maybe not as efficently. What occurrences do is to allow you to program synchronization in a way that does not use polling, and is thus "cheaper" in processor time.		Comments: One may think that occurrences are quirky, a pain to use and that they should be avoided. One might be right! Occurrences are very low level and you often have to add functionality to them in order to use them effectively. In other words, they are not for the faint of heart. Anything implemented with occurences can be also implemented without them, but maybe not as efficently. What occurrences do is to allow you to program synchronization in a way that does not use polling, and is thus "cheaper" in processor time.

			''Note: National Instruments encuorages the use of Notifier operations functions in place of the occurences for most operations.''<br>

	[[Category:Synchronization]]		[[Category:Synchronization]]

Mdwebster: Changed WoW to WoO in last sentence of third paragraph.

2009-05-20T15:23:16Z

Changed WoW to WoO in last sentence of third paragraph.

Michael_Aivaliotis at 10:11, 8 October 2007

2007-10-08T10:11:05Z

← Older revision		Revision as of 10:11, 8 October 2007
Line 24:		Line 24:
	Comments: One may think that occurrences are quirky, a pain to use and that they		Comments: One may think that occurrences are quirky, a pain to use and that they
	should be avoided. One might be right! Occurrences are very low level and you often have to add functionality to them in order to use them effectively. In other words, they are not for the faint of heart. Anything implemented with occurences can be also implemented without them, but maybe not as efficently. What occurrences do is to allow you to program synchronization in a way that does not use polling, and is thus "cheaper" in processor time.		should be avoided. One might be right! Occurrences are very low level and you often have to add functionality to them in order to use them effectively. In other words, they are not for the faint of heart. Anything implemented with occurences can be also implemented without them, but maybe not as efficently. What occurrences do is to allow you to program synchronization in a way that does not use polling, and is thus "cheaper" in processor time.

			[[category:synchronization]]

Dsaunders: Occurrences moved to Occurrence: singular

2007-05-09T22:18:33Z

Occurrences moved to Occurrence: singular

← Older revision	Revision as of 22:18, 9 May 2007
(No difference)

Jim kring: linkified uninitialized shift register

2007-04-07T15:34:17Z

linkified uninitialized shift register

← Older revision		Revision as of 15:34, 7 April 2007
Line 20:		Line 20:
	A solution to the problem: Due to this behavior of occurrences, it is clear that one cannot use the "timed out" flag to determine when the occurrence fired. You will have to maintain some global information about your state, let's say in a global boolean called "FINISHED". At the beginning of the program you would initialize it to false. If you have an error, set FINISHED to true, and then trigger the occurrence. After the WoO see if FINISHED is true (make sure you don't read the global until after WoO finished executing), if FINISHED is false continue with the loop. In the "Stop button" loop, also set FINISHED before you trigger the occurrence.		A solution to the problem: Due to this behavior of occurrences, it is clear that one cannot use the "timed out" flag to determine when the occurrence fired. You will have to maintain some global information about your state, let's say in a global boolean called "FINISHED". At the beginning of the program you would initialize it to false. If you have an error, set FINISHED to true, and then trigger the occurrence. After the WoO see if FINISHED is true (make sure you don't read the global until after WoO finished executing), if FINISHED is false continue with the loop. In the "Stop button" loop, also set FINISHED before you trigger the occurrence.

	BTW, if you don't like globals, you could use a VI with an uninitialized shift register (LabVIEW 2 global), but the effect would be the same.		BTW, if you don't like globals, you could use a VI with an [[uninitialized shift register]] (LabVIEW 2 global), but the effect would be the same.

	Comments: One may think that occurrences are quirky, a pain to use and that they		Comments: One may think that occurrences are quirky, a pain to use and that they
	should be avoided. One might be right! Occurrences are very low level and you often have to add functionality to them in order to use them effectively. In other words, they are not for the faint of heart. Anything implemented with occurences can be also implemented without them, but maybe not as efficently. What occurrences do is to allow you to program synchronization in a way that does not use polling, and is thus "cheaper" in processor time.		should be avoided. One might be right! Occurrences are very low level and you often have to add functionality to them in order to use them effectively. In other words, they are not for the faint of heart. Anything implemented with occurences can be also implemented without them, but maybe not as efficently. What occurrences do is to allow you to program synchronization in a way that does not use polling, and is thus "cheaper" in processor time.

MichaelAivaliotis: New page: There seem to be misconceptions about how exactly occurrences work and what exactly the "ignore previous" parameter on "Wait on Occurrence" (WoO) does. The following tries to explain, in a...

2007-03-17T22:37:45Z

New page: There seem to be misconceptions about how exactly occurrences work and what exactly the "ignore previous" parameter on "Wait on Occurrence" (WoO) does. The following tries to explain, in a...

New page

There seem to be misconceptions about how exactly occurrences work and what exactly the "ignore previous" parameter on "Wait on Occurrence" (WoO) does. The following tries to explain, in a long and winded way, how they (functionally) behave:

How Occurrences are "generated": When a VI is loaded (!) each "Generate Occurrence" function allocates exactly one unique occurrence. When the VI is running and this function is called it simply returns this one occurrence -- no matter how many times it is called (try putting one in a loop and examining its value using the probe, it will always have the same number). If you stop the VI and run it again, you will get the same value; only removing the VI from memory and loading it again will give you a "fresh" value.

How Wait On Occurrence (WoO) works: Each WoO functions "remembers" what occurence it last waited on and what time it continued (because the occurence fired or because of a timout). When a VI is loaded (!) each WoO is initialized with a non existing occurrence. When a WoW is called and "ignore previous" is FALSE there are
four potential cases:

*The occurrence has *never* been set -> in this case WoO waits
*The occurrence has been set since this WoO last executed -> WoO does not wait
*The occurrence has last been set before this WoO last executed and last time this WoO was called it waited on the *same* occurrence -> WoO will wait
*The occurrence has last been set before this WoO last executed but last time this WoO was called it waited on a *different* occurrence -> WoO will *not* wait!!!!

The first three cases are pretty clear, the last one may seem a bit strange. It will only arise if you have a WoO inside a loop (or inside a *re-entrant* VI in this loop) and it waits on *different* occurrences (out of an array, for example) or if it is inside a *non re-entrant* VI and the VI is called with different occurrences. These cases do generally not happen. The reason the WoO behaves this way is due to its implementation. Each
occurrence "knows" the last time it has been fired, and each WoO remembers the occurrence it was last called with and what time it fired (or timed out). When WoO is called and "ignore previous" is FALSE, it will look at its input; if the input is the same as last time, it will look at the time of the last firing and wait depending on whether the time was later than last execution; if the input is *not* the same as last time, it will simply look at the time and wait depending on whether it has *ever* been fired.

A possible (implementation) problem: It appears that occurances are "remembering" that they have been set during previous invocations of the program. One would think that generating an occurance should create a clean "non-set" occurance. This problem can be illustrated in a program that has three parallel loops with an abortable wait in each using occurances. If the program is stopped with the stop button things are fine. But if one waits until one of the random stop conditions triggers the end of the loops (generated from the other loops), the next time the program is run, the loops will execute only once and not loop at all. (The random terminate condition in the actual program is an error occuring in some piece of equipment.) Either this is a bug, or we are completely wrong on the use of occurances. Our example here is using the occurances in the "do not clear previous" mode. We would think that we will not remember ccurances from previous runs of the program since a new clear occurance should be created with the generate occurance icon. In this instance we can not use the clear previous occurances mode since we need a single occurance to stop multiple parallel loops.

The reason for the problem: The first time the occurrence is set because of an error, the loops terminate, but the "stop button" loop is still running. When you click on the stop button, the occurrence gets triggered again (unneccessarily) and the program stops. The next time the VI runs, the WoO will not wait because of this extra trigger; and since you'll trigger again in the "stop button" loop, the VI won't work until it's reloaded from disk.

A solution to the problem: Due to this behavior of occurrences, it is clear that one cannot use the "timed out" flag to determine when the occurrence fired. You will have to maintain some global information about your state, let's say in a global boolean called "FINISHED". At the beginning of the program you would initialize it to false. If you have an error, set FINISHED to true, and then trigger the occurrence. After the WoO see if FINISHED is true (make sure you don't read the global until *after* WoO finished executing), if FINISHED is false continue with the loop. In the "Stop button" loop, also set FINISHED before you trigger the occurrence.

BTW, if you don't like globals, you could use a VI with an uninitialized shift register (LabVIEW 2 global), but the effect would be the same.

Comments: One may think that occurrences are quirky, a pain to use and that they
should be avoided. One might be right! Occurrences are very low level and you often have to add functionality to them in order to use them effectively. In other words, they are not for the faint of heart. Anything implemented with occurences can be also implemented without them, but maybe not as efficently. What occurrences do is to allow you to program synchronization in a way that does not use polling, and is thus "cheaper" in processor time.

← Older revision		Revision as of 15:23, 20 May 2009
Line 1:		Line 1:
	There seem to be misconceptions about how exactly occurrences work and what exactly the "ignore previous" parameter on "Wait on Occurrence" (WoO) does. The following tries to explain, in a long and winded way, how they (functionally) behave:		There seem to be misconceptions about how exactly occurrences work and what exactly the "ignore previous" parameter on "Wait on Occurrence" (WoO) does. The following tries to explain, in a long and winded way, how they (functionally) behave:

	How Occurrences are "generated": When a VI is loaded (!) each "Generate Occurrence" function allocates exactly one unique occurrence. When the VI is running and this function is called it simply returns this one occurrence -- no matter how many times it is called (try putting one in a loop and examining its value using the probe, it will always have the same number). If you stop the VI and run it again, you will get the same value; only removing the VI from memory and loading it again will give you a "fresh" value.		How Occurrences are "generated": When a VI is loaded (!) each "Generate Occurrence" function allocates exactly one unique occurrence. When the VI is running and this function is called it simply returns this one occurrence -- no matter how many times it is called (try putting one in a loop and examining its value using the probe, it will always have the same number). If you stop the VI and run it again, you will get the same value; only removing the VI from memory and loading it again will give you a "fresh" value.

	How Wait On Occurrence (WoO) works: Each WoO functions "remembers" what occurence it last waited on and what time it continued (because the occurence fired or because of a timout). When a VI is loaded (!) each WoO is initialized with a non existing occurrence. When a ~~WoW~~ is called and "ignore previous" is FALSE there are		How Wait On Occurrence (WoO) works: Each WoO functions "remembers" what occurence it last waited on and what time it continued (because the occurence fired or because of a timout). When a VI is loaded (!) each WoO is initialized with a non existing occurrence. When a WoO is called and "ignore previous" is FALSE there are four potential cases:
	four potential cases:

	The occurrence has never* been set -> in this case WoO waits		The occurrence has never* been set -> in this case WoO waits
	*The occurrence has been set since this WoO last executed -> WoO does not wait		*The occurrence has been set since this WoO last executed -> WoO does not wait
	The occurrence has last been set before this WoO last executed and last time this WoO was called it waited on the same* occurrence -> WoO will wait		The occurrence has last been set before this WoO last executed and last time this WoO was called it waited on the same* occurrence -> WoO will wait
	The occurrence has last been set before this WoO last executed but last time this WoO was called it waited on a different* occurrence -> WoO will not wait!!!!		The occurrence has last been set before this WoO last executed but last time this WoO was called it waited on a different* occurrence -> WoO will not wait!!!!

	The first three cases are pretty clear, the last one may seem a bit strange. It will only arise if you have a WoO inside a loop (or inside a re-entrant VI in this loop) and it waits on different occurrences (out of an array, for example) or if it is inside a non re-entrant VI and the VI is called with different occurrences. These cases do generally not happen. The reason the WoO behaves this way is due to its implementation. Each		The first three cases are pretty clear, the last one may seem a bit strange. It will only arise if you have a WoO inside a loop (or inside a re-entrant VI in this loop) and it waits on different occurrences (out of an array, for example) or if it is inside a non re-entrant VI and the VI is called with different occurrences. These cases do generally not happen. The reason the WoO behaves this way is due to its implementation. Each occurrence "knows" the last time it has been fired, and each WoO remembers the occurrence it was last called with and what time it fired (or timed out). When WoO is called and "ignore previous" is FALSE, it will look at its input; if the input is the same as last time, it will look at the time of the last firing and wait depending on whether the time was later than last execution; if the input is not the same as last time, it will simply look at the time and wait depending on whether it has ever been fired.
	occurrence "knows" the last time it has been fired, and each WoO remembers the occurrence it was last called with and what time it fired (or timed out). When WoO is called and "ignore previous" is FALSE, it will look at its input; if the input is the same as last time, it will look at the time of the last firing and wait depending on whether the time was later than last execution; if the input is not the same as last time, it will simply look at the time and wait depending on whether it has ever been fired.

	A possible (implementation) problem: It appears that occurances are "remembering" that they have been set during previous invocations of the program. One would think that generating an occurance should create a clean "non-set" occurance. This problem can be illustrated in a program that has three parallel loops with an abortable wait in each using occurances. If the program is stopped with the stop button things are fine. But if one waits until one of the random stop conditions triggers the end of the loops (generated from the other loops), the next time the program is run, the loops will execute only once and not loop at all. (The random terminate condition in the actual program is an error occuring in some piece of equipment.) Either this is a bug, or we are completely wrong on the use of occurances. Our example here is using the occurances in the "do not clear previous" mode. We would think that we will not remember ccurances from previous runs of the program since a new clear occurance should be created with the generate occurance icon. In this instance we can not use the clear previous occurances mode since we need a single occurance to stop multiple parallel loops.		A possible (implementation) problem: It appears that occurances are "remembering" that they have been set during previous invocations of the program. One would think that generating an occurance should create a clean "non-set" occurance. This problem can be illustrated in a program that has three parallel loops with an abortable wait in each using occurances. If the program is stopped with the stop button things are fine. But if one waits until one of the random stop conditions triggers the end of the loops (generated from the other loops), the next time the program is run, the loops will execute only once and not loop at all. (The random terminate condition in the actual program is an error occuring in some piece of equipment.) Either this is a bug, or we are completely wrong on the use of occurances. Our example here is using the occurances in the "do not clear previous" mode. We would think that we will not remember ccurances from previous runs of the program since a new clear occurance should be created with the generate occurance icon. In this instance we can not use the clear previous occurances mode since we need a single occurance to stop multiple parallel loops.

	The reason for the problem: The first time the occurrence is set because of an error, the loops terminate, but the "stop button" loop is still running. When you click on the stop button, the occurrence gets triggered again (unneccessarily) and the program stops. The next time the VI runs, the WoO will not wait because of this extra trigger; and since you'll trigger again in the "stop button" loop, the VI won't work until it's reloaded from disk.		The reason for the problem: The first time the occurrence is set because of an error, the loops terminate, but the "stop button" loop is still running. When you click on the stop button, the occurrence gets triggered again (unneccessarily) and the program stops. The next time the VI runs, the WoO will not wait because of this extra trigger; and since you'll trigger again in the "stop button" loop, the VI won't work until it's reloaded from disk.

	A solution to the problem: Due to this behavior of occurrences, it is clear that one cannot use the "timed out" flag to determine when the occurrence fired. You will have to maintain some global information about your state, let's say in a global boolean called "FINISHED". At the beginning of the program you would initialize it to false. If you have an error, set FINISHED to true, and then trigger the occurrence. After the WoO see if FINISHED is true (make sure you don't read the global until after WoO finished executing), if FINISHED is false continue with the loop. In the "Stop button" loop, also set FINISHED before you trigger the occurrence.		A solution to the problem: Due to this behavior of occurrences, it is clear that one cannot use the "timed out" flag to determine when the occurrence fired. You will have to maintain some global information about your state, let's say in a global boolean called "FINISHED". At the beginning of the program you would initialize it to false. If you have an error, set FINISHED to true, and then trigger the occurrence. After the WoO see if FINISHED is true (make sure you don't read the global until after WoO finished executing), if FINISHED is false continue with the loop. In the "Stop button" loop, also set FINISHED before you trigger the occurrence.

	BTW, if you don't like globals, you could use a VI with an [[~~uninitialized~~ shift register]] (LabVIEW 2 global), but the effect would be the same.		BTW, if you don't like globals, you could use a VI with an [[Uninitialized shift register]] (LabVIEW 2 global), but the effect would be the same.

	Comments: One may think that occurrences are quirky, a pain to use and that they		Comments: One may think that occurrences are quirky, a pain to use and that they should be avoided. One might be right! Occurrences are very low level and you often have to add functionality to them in order to use them effectively. In other words, they are not for the faint of heart. Anything implemented with occurences can be also implemented without them, but maybe not as efficently. What occurrences do is to allow you to program synchronization in a way that does not use polling, and is thus "cheaper" in processor time.
	should be avoided. One might be right! Occurrences are very low level and you often have to add functionality to them in order to use them effectively. In other words, they are not for the faint of heart. Anything implemented with occurences can be also implemented without them, but maybe not as efficently. What occurrences do is to allow you to program synchronization in a way that does not use polling, and is thus "cheaper" in processor time.

	[[~~category~~:~~synchronization~~]]		[[Category:Synchronization]]