TimeOut option for VI

[GriffinRU]

While in most cases it is possible to write a code with built-in timeouts, but there are cases when you do not have means to do that, so It would be nice to be able to specify how much time would you like to let particular VI (function) to have for execution.

Attached example has 1ms resolution and forced to use VI server calls to pass data to and from VI to make it work with STOP command.

Natively it can be done with much tighter resolution (us, or better) and without server calls.

P.S. Sorry for just PNG but Snippet for this VI was not capturing code correctly, Boolean property node end up losing its link...

[altenbach]

So you simply want to throw a wrench into the gears of the "time consuming code" via the stop primitive? That seems dangerous and unpredictable, especially if hardware is involved.

[GriffinRU]

Well, if setting timeout for getting data from point A (serial buffer, DAQ read - calls with builtin timeouts...) is throwing a wrench - than YES.

For hardware you have different tools, i.e. watchdog...

Attached example is a just a proof of concept, implementation can be done in much nicer fashion.

-Artur

[altenbach]

You need to create a link to the attachment in the body of your reply, it will not show otherwise.

[GriffinRU]

I was referring to original post, no new attachements in my reply to your first comment.

-Artur

[smercurio_fc]

I agree. I think stopping a VI like that is a BAD idea. Any sort of timeout should be setting an error condition. Even if you were to do that (and I'm not saying I'd support this idea if it got changed to this), what would you do if the VI has no error clusters?

In the end, I think the proper solution to this "issue" is to fix the code, not change the LabVIEW language by adding this capability, which is sure to cause more problems than it would fix.

[GriffinRU]

I am proposing to stop VI nicely not with what we have right now...

Example is not a solution - it is a proof of concept. Final implementation can be done with every bell and whistle.

If you do not have error clusters, or if you do not need to use timeout than do not use it or set to "-1" or something. How to handle timeout scenarios is up to programmer and I do not see any trouble here.

And it is not always possible to get proper solution, it is much better to plan what shortcomings to expect and program accordingly.

LabVIEW already has it, you can stop all running VI's on demand, so why not to tweak it and make it more usefull.

-Artur

[SteveChandler]

Even if there were a method to abort a vi without using the stop prim it could still be very bad. When the timeout happens there is really no way to know what state the vi is in. What if it were in the middle of writing to a file? There are functions with timeout where it makes sense to have that. But I can not see any reason for a vi to have a timeout. If it is taking too long then it should be optimized. If it is already optimized it should be allowed to finish. If it is hanging it should be debugged.

[GriffinRU]

Again, it should be used only when needed, not always, i.e. by default timeout disabled.

Maybe if you think about why some functions have timeouts (i.e. make sense for you) and expand this to what you can do with LabVIEW then maybe you re-consider...

-Artur

P.S. Sounds like I am fighting against LabVIEW fundamentals. With unique LabVIEW Run-time Engine there are lots of cool things we can do with LabVIEW routines which other programming languages do not have. Do not underestimate hidden potential in this function, is it dangerous? depends on implementation. Do you know in which state VI stopped, yes Run-Time Engine in-charge. You can implement alot as long as you can stop execution NICELY...

This is proven concept, with many hours of operation and was developed for executables, very surprising comments.

[SteveChandler]

Things with timeouts need timeouts. If you try to open communictions to something that is not responding you need to time out. If no user activity happens after a period of time you might want to do something. If nothing is placed in a queue after a certain time you might want to do something else.

But I just can't see myself calling a VI that I do not want it to complete. Maybe the VI has some of the things mentioned above.

I can think of a situation where this idea might be slightly useful. Maybe I want to poll something and if there is no activity after a particular time abort and return some default value. But that would be in the design of the VI.

[AristosQueue (NI)]

I'm both for and against this idea.

I have, for a long time, been experimenting with "safe Abort of running VIs." Essentially, creating some way to call the Abort method on a VI and guarantee the state of hardware or other system resources. So this idea of a timeout is appealing in that sense.

The idea I've been toying with goes something like this:

I call Run VI on a *pair* of VIs, where the second VI is supposed to run as soon as the first VI finishes. The first VI has an output that is some sort of state-machine-status enum, which the second VI takes as an input. The first VI either runs to completion or gets Aborted. Regardless, its outputs (whatever the most recent values written to its outputs happen to be) get returned. The second VI takes that enum as input. The second VI thus knows how far along the first VI got in its process, and so it knows what resources need to be cleaned up. The two VIs share enough other state data between them to get this right (like a global VI that stores all the refnums allocated by the first VI or something like that). 

I've sketched on this for a few years, and I can make something that is mostly viable, but it is a poor programmer experience -- there's a fairly heavy burden on the programmer to get this right. For example, we'd need some protected sections in the first VI during which the Abort signal is deferred, so that the VI could allocate a refnum and prevent being aborted until that refnum was actually placed in the shared state data. And this feature would change some of the rules of refnums -- any refnums allocated by the first VI shouldn't be disposed when the first VI gets aborted because the second VI may need to use those refnums as part of clean up -- such as sending some final ACK to a tcp connection, or writing a "that's all folks" message to a file refnum.

Providing a timeout on the Run method would be a trivial improvement. The hard part is figuring out how to cleanly allow the programmer to specify the kinds of cleanup work that needs to be done by the second VI.

I like the idea, but it isn't trivial at all, neither for us to implement nor -- as I currently think about it -- for you to use. But kudos anyway for thinking in this direction.