LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

subvi abort

Hi,

I have a main vi that loops continiously. Depending on choosen menu items there is a subvi called which executes a sequence and than returns to the main vi.
I'd like to have the possibility to abort the subvi inside the sequence as well and to return to the running main vi. So I tried a parallel looping subvi that checks for pressing the abort button of the other subvi. In that case I invoke the method to abort the first subvi (via a global vi reference). That doesn't work. The error 1000 occurs (LabVIEW: The VI is not in a state compatible with this operation.).
That happens independently if the abort subvi loops parallel to the other subvi (called from main vi) or if it is called in the subvi itself.
Is there any setting to avoid that?
0 Kudos
Message 1 of 11
(4,540 Views)
Hi, the problem that your 2 sub-vi's both are loaded statically to memory. In this case one can't abort another. You have run one of these sub-vi's dinamically.
0 Kudos
Message 2 of 11
(4,540 Views)
Thanks. That way the calling main vi is still running when both subvi's are finished.
But the error 1000 still occurs and the abort function doesn't work.
Any idea?
0 Kudos
Message 3 of 11
(4,540 Views)
Hi, look at attached example. Hope that will help you.
0 Kudos
Message 4 of 11
(4,540 Views)
🙂
That work's fine! Thank you again.

I tried some modifications now. Ofcause I'm going to use subvi's with terminals. So it would be easier to use the call by reference node to start it dynamically.
But that doesn't work because the subvi is aborted and so the main vi hangs up due to the omitted return of the subvi.
Using the methode run to invoke the subvi means that I have to set all control values via invoke nodes as well. Is that right or do you see any other solution?

An other thing is that I'm not sure if it matters for later calls of the subvi when it was aborted (unknown state). What do you think about that?

Is there an other possibility to abort the running subvi a "nicer" way? (Exept I could use a case structure enclosi
ng every sequence step.)

Bye,
Alexandra
0 Kudos
Message 5 of 11
(4,540 Views)
....
> Is there an other possibility to abort the running subvi a "nicer"
> way? (Exept I could use a case structure enclosing every sequence
> step.)
>

Aborting portions of your VI will always lead to difficulties one way or
the other. You need to make your computations stoppable, by having them
pay attention to a global or an occurrence or an event.

You might want to use something similar to error I/O so that downstream
subVIs get called anyway and they just finish as soon as possible, doing
no work if the abort error is set.

Greg McKaskle
0 Kudos
Message 6 of 11
(4,540 Views)
If you will use state machine you can stop subVI easily. Look modified example.
0 Kudos
Message 7 of 11
(4,540 Views)
Generally, using the abort method is not "nice", imho. This can have undesirable consequences if it leaves references open, for example. Your main VI could do something else like set an occurance,global variable, semaphore, notifier, or other synchronization function that is monitored in your subVI. Add the synchronization function to your subVI and monitor it in any while loop that you might need to terminate early. That way you can take the clean up actions you need to do. There's a couple shipping examples that you might want to look at. One is Semaphore with SbuVIs.vi and the other is Notifier BASICS Part 2.vi.
0 Kudos
Message 8 of 11
(4,540 Views)
Thanks to all!

I think I'll use the state machine with queues.
Thats really cool!

To Nadav Chernin:
Is that the way you normally program sequences?
Do you think it's more efficient than the case structure in every sequence step?
0 Kudos
Message 9 of 11
(4,540 Views)
I don't use sequences with more than 1 frame because:
1) Is not flexible (you haven't posibility to change the flow).
2) data transfer between frames is without shift registers
3) very hard to understand the program
0 Kudos
Message 10 of 11
(4,540 Views)