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...

[tst]

AQ, why would you prefer that to actively writing explicit code inside the VI to handle the timeout case? Since the vast majority of VIs don't need it and the ones who do have custom behavior, that would seem to be easier to write and easier to follow.

[AristosQueue (NI)]

tst: You're right that most VIs don't need this. But if any higher level VI does need it then all the subVIs have to support it. This includes any pure functional math-type VIs. Here's an example...

Suppose I write a VI that acquires (from some source, maybe tcp, maybe some hardware) a stream of 1000000x1000000 matricies and I'm multiplying them together. It just loops, acquire one matrix, multiply it with the previous, and repeat.

How do I put a time out on this VI? I have to keep a running "how much time remains" count so I can pass that ever-smaller value into the TCP/HW acquisition nodes. For the math computation, I have to write code to put a "check if time has elapsed" after every single node in my diagram. The hardware acquisition is not the only long part of this VI -- the multiplication itself is long enough that it may need to be aborted. I cannot call the vi.lib version of Maxtrix Multiply because that subVI doesn't do periodic checks for time out, so I have to write my own version of that routine.

In other words, there's a lot of code that I have to write to support doing this, and I lose the ability to call any built-in operation that doesn't have its own timeout mechanism already.

On the other hand, if I can simply reach in from the outside and abort a VI, and then clean up the mess left behind such that the system is in a good state, then my block diagram for my function is actually readable, and I don't have to write custom "count down" code for every new VI that I write that needs this timeout functionality.

[SteveChandler]

AQ, that is some pretty advanced thinking. But what if you have to abort the"second" VI?

[AristosQueue (NI)]

That wouldn't be supported. It isn't a valid use case. That second VI is doing required clean up work; it shouldn't have any timeout limitations. 

Keep in mind -- this is to support timing out a first VI as part of a running application, NOT to support a user clicking the Abort button on the VI panel. That would still stop the whole application dead.

[altenbach]

Maybe we need a special timeout structure that has a timeout terminal. Inside we could do all these endless math operations. If the contents finish in time, we get the final results. If they take longer than the timeout, the structure would end and return either the best value found so far or some defaults.

This allows the definition of "timeout'able" code on a finer scale than an entire VI, and we still can add cleanup code after a timeout has happened.

(Of course this can already be done todays with a little bit of code)

In think the nonlinear fit has some internal stubs to allow termination based on elapsed time, but AFAIK they are currently not exposed to the user.

One problem is that things are now no longer predictable and the outcome could depend critically on computer speed and computer load. The code could also be stuck inside a dll, making interuption difficult.

[GriffinRU]

To: Aristos Queue

Thank you for understanding and bringing up an example.

As far as cleanup goes:

-for sequential data (like writing to files) use stacks or queues, do not stop VI but ignore it by reading VI state with predefined default value

-for non-sequential data (like display intermediate results) stop VI or use another clone, while tracking them (limit number of clones, like backlog in data acquisition...)

To: altenbach

"Maybe we need a special timeout structure that has a timeout terminal."

That's a cool option, I would like that with microsecond (us) timer...

-Artur

[rgvdh@rdf]

>"Maybe we need a special timeout structure that has a timeout terminal."

Maybe something like the timed sequence & times loop structures, only when a frame goes over deadline, instead of reporting that the frame finished late, it terminates all processes started within the frame and finishes on time with default outputs.

[AristosQueue (NI)]

> (Of course this can already be done todays with a little bit of code)

No. It can't. For most useful cases, it can be done, but it requires an extrordinary hurculean quantity of code, as I described earlier. Thank you for mentioning the DLL, which adds additional complexity to the problem.

> "Maybe we need a special timeout structure that has a timeout terminal."

Structure nodes and VIs are generally equivalent, from a language standpoint. We could have added a "For Loop VI", a VI that has an additional N terminal on its conpane and implicitly iterates its contents N times. Structures and VIs create the same synch point in the dataflow. It basically depends upon where we think users would expect to find the functionality (is this something that feels more like a config option for a function or is it something that feels like an additional function wrapping some other function) and how much "on the fly"-ness the feature needs (is this something that users would create a function to do from the outset of writing their code or is this something they might want to slap down around already existing code). But when initially discussing whether the feature is necessary or not and what use cases it should tackle, structrure vs VI is largely irrelevant.

That's the general reason for the choice. In this particular case,there are some additional considerations. I'd lean heavily toward it being a VI configuration if for no other reason than Abort is a well defined operation for a subVI hierarchy, not for a portion of a diagram and that portion's hierarchy. Especially as it would be hard for me to describe clearly to all users that refnums have a lifetime equivalent to their top-level VI OR to the first timeout structure somewhere in the call chain, and good luck finding that if any interim diagram is password protected. 🙂

[GriffinRU]

More or less cleaner version used in my projects.

In general I have two versions, with handshake (more complex, linked above) when you expecting return from VI and without when you just passing data.

Current version doesn't support runs with clones, but for most of you guys here adding such an option is not a big deal.

-Artur

[Darren]

Any idea that has received less than 5 kudos within 5 years after posting will be automatically declined.