generating new occurrences

[eenauk]

hi -

i am working on a sub-GUI (displays a tree control) that pops up from the click of a button on the main GUI. Each time it opens, the sub gui generates an occurrance, which it feeds into a sub-vi. This sub-vi continuoulsly runs a while loop containing an event structure that controls the tree. when the user clicks OK/Cancel in the sub-gui, this gui sets the occurrence so that the sub-vi stops and we return to the main GUI.

My problem: the sub-GUI generates the same occurrence on each new run (unless you recompile it). Also, when the sub-GUI is opened a second time, the occurrence still seems to be set so that it stops immediately. Note that i cannot set the "Wait On occurrence" vi to "ignore previous" since it needs to time out every 50ms and would therefore not catch most of the occurrences at all.

Q1: do you know how to generate new occurrences each time a vi runs?

Q2: do you know how to "clear" an occurrence?

thanks. michael.

PS i've attached a simplified version of the vis, but the llb still contains 84 or so vis.

[orko]

Q1: do you know how to generate new occurrences each time a vi runs?

Q2: do you know how to "clear" an occurrence?

thanks. michael.

PS i've attached a simplified version of the vis, but the llb still contains 84 or so vis.

Each time a generate occurance instance is called, it generates the same occurance (almost like a constant). You can create more than one occurance value only by placing another generate occurance on your diagram. From the online help (LV 7.1.1):

************************************************************************

Generate Occurrence Details

Ordinarily, only one Generate Occurrence node is wired to any set of Wait on Occurrence and Set Occurrence functions. You can wire a Generate Occurrence function to any number of Wait on Occurrence and Set Occurrence functions. You do not have to have the same number of Wait on Occurrence and Set Occurrence functions.

Unlike other Synchronization VIs, each Generate Occurrence function on a block diagram represents a single, unique occurrence. In this way, the Generate Occurrence function is similar to a constant. When a VI is running, every time a Generate Occurrence function executes, the node produces the same value. For example, if you place a Generate Occurrence function inside of a loop, the value produced by Generate Occurrence is the same for every iteration of the loop. If you place a Generate Occurrence function on the block diagram of a reentrant VI, Generate Occurrence produces a different value for each caller.

Note National Instruments encourages you to use the Notifier Operations functions in place of occurrences for most operations.

************************************************************************

Notice the note. I think you may want to look at using the notifier operations for your purpose.

HTH,

Joe (orko)

[jpdrolet]

hi -

i am working on a sub-GUI (displays a tree control) that pops up from the click of a button on the main GUI. Each time it opens, the sub gui generates an occurrance, which it feeds into a sub-vi. This sub-vi continuoulsly runs a while loop containing an event structure that controls the tree. when the user clicks OK/Cancel in the sub-gui, this gui sets the occurrence so that the sub-vi stops and we return to the main GUI.

My problem: the sub-GUI generates the same occurrence on each new run (unless you recompile it). Also, when the sub-GUI is opened a second time, the occurrence still seems to be set so that it stops immediately. Note that i cannot set the "Wait On occurrence" vi to "ignore previous" since it needs to time out every 50ms and would therefore not catch most of the occurrences at all.

Q1: do you know how to generate new occurrences each time a vi runs?

Q2: do you know how to "clear" an occurrence?

thanks. michael.

PS i've attached a simplified version of the vis, but the llb still contains 84 or so vis.

Use notifiers instead of occurences. There are nodes to create new and destroy them as needed. They work like occurences with data attached.

[Kevin P]

Q1: do you know how to generate new occurrences each time a vi runs?

Q2: do you know how to "clear" an occurrence?

A1: Already handled well by others -- would agree that Notifiers may be a better option.

A2: I've got some old library code based on occurrences that I haven't felt like changing and have had to deal with

similar persistence issues with occurrences. Here's what I've done:

Call "Wait on Occurrence" once with "ignore prev" set to F and with a minimal timeout like 1 msec. (I've actually

tested it some with 0 msec without seeing problems, but have felt safer using 1 msec). Any old stale occurrence

firings will result in a timeout=F output while clearing the occurrence. If timeout=T then all you've done is wasted

1 msec. You can then loop over your normal "Wait..." with ignore=F and a 50 msec timeout.

-Kevin P.

[AutoMeasure]

I used occurences a lot when they first came out (Labview 4?). At that time I found tricks that would stop them from exhibiting illogical behavior. For example, I found that I needed to put the Wait On Occurence in a loop and in the first call set 'ignore previous'=F with a short timeout, ignore the result, then set 'ignore previous'=T on subsequent calls. And the actual instance of the Wait On Occurence placed on the diagram made a difference. I couldn't use 2 separate Wait On Occurence functions placed in sequence -- I had to place just one instance and use a loop to call it twice. Weird!

With Labview 6, before we could generate Events programmatically, I used Notifiers quite a bit. In Labview 6.1, when you read a notifier message using Wait On Notification, the message was automatically removed from the notifier's memory, similarly to how Dequeue Element works. With Labview 7.0, my programs no longer worked right because now I had to call Cancel Notification before every Wait On Notification instead of just a single call to Wait On Notification.

When I reported that issue to NI, the answer I got back was to use the new programmatic Events and stop using notifiers. I think this is good advice for half the situations. Events have some unique behavior that doesn't fit every communication need, such as always queueing events even when the subVI isn't executing, and undefined behavior when two different subVI's Event structures are looking for the same event.