Notification and parallel sub vi's question

[struggler]

Hi All,

Could someone please explain why the three sub vi's are running in parallel
in the "Sub Vi Notification" example that ships with Labview. I must be
missing something fundamental. I am aware (and have used) VI server calls
to call vi's that I wish to have running in parallel, but was of the
(obviously flawed) understanding the if a top level vi called a sub level
vi, its operation was suspended until the sub vi finished executing. So for
the notification example I would have expected to see the first sub vi be
called and then just sit there waiting for a notification from the now
halted top level vi. Why are the three sub vi's running in parallel?

I am trying to program a simple alarm detection syst
em, where if an alarm is
detected, it calls a sub vi that throws up a dialogue box window with the
alarm details. The idea is to keep this alarm detector running behind the
scenes, while the PC is running other tasks (eg running a GPS based
plotter/charter program) and only display the alarm window when an alarm is
detected. However I also want to keep the detection of the alarms running
(ie the top vi) since i am also doing datalogging of a heap of parameters,
(done in the top vi) and this stops when the alarm dialogue box sub vi is
called, until the alarm dialogue box is displaced by pressing the OK button.

Thanks
John

[alkazaa]

Hi John,

John schrieb:

> Hi All,
>
> Could someone please explain why the three sub vi's are running in parallel
> in the "Sub Vi Notification" example that ships with Labview. I must be
> missing something fundamental. I am aware (and have used) VI server calls
> to call vi's that I wish to have running in parallel, but was of the
> (obviously flawed) understanding the if a top level vi called a sub level
> vi, its operation was suspended until the sub vi finished executing.

This is not true, if the top level VI doesn't get any data out of the called VI.

There is no data dependency in the calls to the three subVIs in this sense.
The only dependency here is that the top VI will not stop until all of the three

subVIs have stopped. In the example this is achieved by killing the 'Notifier'
object
in the top VI. This gives an error in the 'Wait on Notitification call' in the
subVI
which stops when this error occurs.

It would be different if the calls were made within the while loop, of course.
In that case the loop would stop since proceeding to the next loop iteration
only
would take place when all three calls were finished (which can't happen since
the
notifier is killed outside the loop)

So the sequence of events in the example is:
1) top VI starts
2) top VI launches sub 1, 2 and 3 and enters main loop
(actually these 4 events happen quasi-simultaneously. In the example the
programmer doesn't even know what happens first. It's o.k. in the example
but may be disastrous in other cases. Be aware of this (consistent in
dataflow
paradigm) behaviour when modifying the example for your own purposes)
3) all 4 VIs run and do what they are supposed to
4) user presses stop button on top VI, which terminates it's while loop
5) top VI kills notifier object but keeps running since it's subs are still
'alive'
6) sub 1,2 3 get errors from the wait on notification call (since notifier has
ceased
away). They leave their while loops and terminate. (Again it's not defined
in
which sequence sub 1,2 and 3 will stop)
7) top VI terminates when all three subs have stopped.


> So for
> the notification example I would have expected to see the first sub vi be
> called and then just sit there waiting for a notification from the now
> halted top level vi. Why are the three sub vi's running in parallel?
>
> I am trying to program a simple alarm detection system, where if an alarm is
> detected, it calls a sub vi that throws up a dialogue box window with the
> alarm details. The idea is to keep this alarm detector running behind the
> scenes, while the PC is running other tasks (eg running a GPS based
> plotter/charter program) and only display the alarm window when an alarm is
> detected. However I also want to keep the detection of the alarms running
> (ie the top vi) since i am also doing datalogging of a heap of parameters,
> (done in the top vi) and this stops when the alarm dialogue box sub vi is
> called, until the alarm dialogue box is displaced by pressing the OK button.
>

I think you should have three tasks running in parallel:
- the datalogger (what you call top VI)
- the alarm logger
- the user dialog notification
They would be spawned by a main VI whose purpose is to spawn the subVIs,
to catch any other (possible) user events and to do a clean-up when the program
ends.

>
> Thanks
> John

Regards


Franz

[struggler]

Thanks Franz,

This has been bothering me for some time; I had no idea it was just a data
dependency issue.

I also like your ideas for spawning the parallel vi and am looking into
implementing them.

Thanks again

John


Franz Josef Ahlers wrote in message
news:38CF74DC.23394600@ptb.de...
> Hi John,
>
> John schrieb:
>
> > Hi All,
> >
> > Could someone please explain why the three sub vi's are running in
parallel
> > in the "Sub Vi Notification" example that ships with Labview. I must be
> > missing something fundamental. I am aware (and have used) VI server
calls
> > to call vi's that I wish to have running in parallel, but was of the
> > (obviously flawed) understanding the if a top level vi called a sub
level
> > vi, its operation was suspended until the sub vi finished executing.
>
> This is not true, if the top level VI doesn't get any data out of the
called VI.
>
> There is no data dependency in the calls to the three subVIs in this
sense.
> The only dependency here is that the top VI will not stop until all of the
three
>
> subVIs have stopped. In the example this is achieved by killing the
'Notifier'
> object
> in the top VI. This gives an error in the 'Wait on Notitification call' in
the
> subVI
> which stops when this error occurs.
>
> It would be different if the calls were made within the while loop, of
course.
> In that case the loop would stop since proceeding to the next loop
iteration
> only
> would take place when all three calls were finished (which can't happen
since
> the
> notifier is killed outside the loop)
>
> So the sequence of events in the example is:
> 1) top VI starts
> 2) top VI launches sub 1, 2 and 3 and enters main loop
> (actually these 4 events happen quasi-simultaneously. In the example
the
> programmer doesn't even know what happens first. It's o.k. in the
example
> but may be disastrous in other cases. Be aware of this (consistent in
> dataflow
> paradigm) behaviour when modifying the example for your own purposes)
> 3) all 4 VIs run and do what they are supposed to
> 4) user presses stop button on top VI, which terminates it's while loop
> 5) top VI kills notifier object but keeps running since it's subs are
still
> 'alive'
> 6) sub 1,2 3 get errors from the wait on notification call (since notifier
has
> ceased
> away). They leave their while loops and terminate. (Again it's not
defined
> in
> which sequence sub 1,2 and 3 will stop)
> 7) top VI terminates when all three subs have stopped.
>
>
> > So for
> > the notification example I would have expected to see the first sub vi
be
> > called and then just sit there waiting for a notification from the now
> > halted top level vi. Why are the three sub vi's running in parallel?
> >
> > I am trying to program a simple alarm detection system, where if an
alarm is
> > detected, it calls a sub vi that throws up a dialogue box window with
the
> > alarm details. The idea is to keep this alarm detector running behind
the
> > scenes, while the PC is running other tasks (eg running a GPS based
> > plotter/charter program) and only display the alarm window when an alarm
is
> > detected. However I also want to keep the detection of the alarms
running
> > (ie the top vi) since i am also doing datalogging of a heap of
parameters,
> > (done in the top vi) and this stops when the alarm dialogue box sub vi
is
> > called, until the alarm dialogue box is displaced by pressing the OK
button.
> >
>
> I think you should have three tasks running in parallel:
> - the datalogger (what you call top VI)
> - the alarm logger
> - the user dialog notification
> They would be spawned by a main VI whose purpose is to spawn the subVIs,
> to catch any other (possible) user events and to do a clean-up when the
program
> ends.
>
> >
> > Thanks
> > John
>
> Regards
>
>
> Franz
>