Asynchronous Call With Timeout

[Hooovahh]

Similar to an idea here:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Integrate-Asynchronous-Call-By-Reference-with-Event-St...

I want to have the ability to know when a VI is completed when it is called Asynchronously without having to wait for it to complete.  That idea was to allow to register for events.  I think the first step is simply to have a timeout control on the Wait On Asynchronous Call and an indicator that it did timeout.  If the function did timeout I would expect the data returned would be the default data for the data type that the VI would have returned.

[AristosQueue (NI)]

This idea was evaluated and rejected during the feature design. If you want feedback from your subVI while it is running, pass a user event refnum into your VI when making the Start ACBR call and fire that event refnum inside the subVI. Or use a notifier or queue or any other signaling mechanism. Such communications mechanisms include a timeout capability.

[Hooovahh]

Thanks AQ for the update.  Out of curiosity is there anything else you can say about why this idea was rejected?  Was it a feature too difficult to implement?  Without being definitive, do you believe we will ever see some kind of feature where we can know more about the status of a asynchronous call without having to build it into the VI being called?

Your suggestion with passing in a notifier/queue/user event is fine and how we are working around this at the moment.  Thanks.

[AristosQueue (NI)]

a) When you needed to wait for timeout, and your wait timed out, it was generally to go do something else and then come back to waiting. Well, that's a nasty polling loop. There's no reason to have such a polling loop if you just give the async VI an event that it can use to signal. You can just use an event structure to do the other tasks as they come in and/or use the timeout on the event structure itself if you really need to be polling something. Putting a timeout on the Wait For ACBR node itself just lead to bad architectures.

b) When you needed to wait for a timeout and it timed out and you *weren't* going to continue waiting on it -- i.e., you were abandoning the call entirely -- then you had to have some way to tell the subVI "stop what you're doing, I don't care anymore because you took too long." To establish that communications channel, you have to pass an input into the subVI anyway.

c) When we looked at those together, we thought about creating some sort of new communications API for talking to ACBR-called subVIs. Maybe a "send message" method on the VI itself, maybe registering the VI refnum for some sort of dynamic event. But we couldn't define the complete set of events that you might want to get from the subVI -- often the subVI would be firing some sort of progress event, which, obviously, would use user events. And using the same communications system for all interactions between async systems is STRONGLY ENCOURAGED (doing anything else leads to some very arcane code). So whatever you picked for that progress signal should be the same thing you use for the "I'm done" signal. In the end, it just didn't make sense for us to introduce any sort of new communications API just for ACBR-callled subVIs, especially given the powerful variety of events that we already have already today.

Often when LV doesn't have a particular feature it is because we just haven't added it yet. In this case, we actually consider it to be a bad feature to add.

[dgdgomez]

Link: Timeout for Wait On Asynchronous Call Dialog Box

[Hooovahh]

WAHHHH!  Yet another idea I posted on the idea exchange that I don't get credit for it being a feature in LabVIEW.  Thanks for linking to that I didn't realize that was a feature and I may look into incorporating that into my application.  Of course as AQ said a better design is to use a reference telling the VI to stop, but if that VI locks up I want this timeout to be able to not lock up any other VI waiting for it to stop.

[TomOrr0W]

NI's implementation of that feature is not very discoverable/debuggable - the only way to check if a non-default timeout was set on Wait for Asynchronous Call is to right-click on it.

[Hooovahh]

Yes the node doesn't have any visual identifier, it would be nice for some glyph next to the hour glass to indicate it has a timeout.  By the way I just tested and if it times out it does just return an error 123 Timeout Occurred which makes sense since there is no additional Timed out? output.

[_carl]

Wow, I would never have known that this feature now existed if I hadn't seen this -- it's certainly not easy to find unless you know about it.  The timeout behavior doesn't appear to be documented either.

Why not expose the timeout input as an optional terminal that defaults to -1?  That way developers could easily discover that the feature exists, and it's obvious when you're looking at code that it's set to a non-default value...

[Hooovahh]

Can someone at NI change the status of this idea to Completed?  All help links appear to be broken, but the new manual can be found here which mentions the timeout feature.