Howto implement timeout

[WG-]

Ok I have the following problem...

I have multiple VI's. Most of these VI's contain a loop which can theoratically loop a infinit amount of time. Some VI's which can run infinitly call VI's which can run infinitly. Now my problem is how do I timeout them. 

I got a few solutions but none that I like. 

Currently I have the following (not wanted implementation). Each VI has a timeout input. Then inside the VI I check if the VI has timed out. Now this implementation is flawed because of the following. I have A.vi and B.vi. A.vi calls B.vi. A.vi and B.vi have a input timeout. I wire the timeout of A.vi to B.vi. Now the flaw in my current design is that the timeout is sort of relative. Before B.vi is called in A.vi already some time has passed. Thus when B.vi is called in A.vi with that timeout it is possible that while B.vi is running A.vi would have timeout... but this does not happen because B.vi is still running with the same timeout of A, hence gets extended, because the timeout is added with the time when the VI is called and then compared when running. I attachted a sample VI of my current implementation. 

Now I want to be able to have a more abstract method. Something like a VI which holds the timeout. I was thinking of a functional global... however this would conflict when two VI's are running with different timeouts which both call that VI when they run in parallel. 

Hopefully someone has a clever idea/solution.

[egraham]

It sounds like you're just trying to implement a couple of timers. In that case, try the elapsed time VI. You can set a timeout, reset it, and mutiple of these timers can run in parallel within the same loop without preventing other code in main loop from executing. Hope this helps.

Eric

[WG-]

Eric I know how a timer works, no offence ;). But my problem is more of a architectural problem. Please check the 2 example VI's, which simulates the problem. 

I try to describe it more precisly...

A.vi is called with a timeout of 100 ms. A.vi runs (example, can differ) 50 ms before calling B.vi. B.vi is called with a timeout of 100 ms (timeout of A is wired to timeout of B). B.vi then takes 75 ms to end. 50 ms + 75 ms = 125 ms. 125 ms > 100 ms thus A.vi should have already timed out 25 ms before.... However due to the fact that B is running it can't timeout yet. 

Now I could solve this by easily checking the time before B.vi is called and set the timeout of B.vi accordingly...

A.vi is called with a timeout of 100 ms. A.vi runs (example, can differ) 50 ms before calling B.vi. B.vi is called with a timeout of 50 ms (timeout of A - the time that passed before calling B). B.vi then takes 75 ms to end, however it times out at 50 ms... then accordingly A.vi times out.

This method is however in my opinion not pratical since I will need to check the time of numerous VI's before calling them... So I want a more abstract functionality where each VI can call a method R and it tells them simply if the call has been timed out.

[Alhern]

Hi Wouter G!

From what I understand your main concern is that the caller VI's might not time out when you expect them to when you nest VI calls. More than a timeout problem this is a design problem because  when you keep nesting loop VI calls there's no way around the fact that the caller VI's will keep taking longer to execute.

If A.vi calls B.vi, and you expect B.vi to be done in 100 ms it's naturally impossible for A.vi to be done in 100 ms as well if B.vi times out. You can use the timed elapsed in B output and add it to the time elapsed in A to compare it with the timeout instead. However if B does time out A will still take a bit longer to time out.

I would recommend you to just make each caller VI's timeout about twice as large as the VI's it calls, so you can reliably tell when the process will time out. If that isn't an acceptable behavior for your application could you explain what your requirements are, and why aren't they met?

Another approach would be to change the design where you essentially have a lot of nested execution loops, but again I need some more information about your particular application.

Regards.

[nathand]

If your current approach is as simple as the demo VIs you attached, you may very rarely run into a problem when the Tick Counter rolls over, giving you a much longer timeout than you expect.  (Of course, loops with no wait are also a problem).

Sounds like what you want is to change your timeout inputs to "Timeout At" inputs, so that it times out at a given time.  Instead of comparing with the Tick Count, compare with Get Date/Time in Seconds (this also solves the rollover problem).  Then you can pass the same Timeout At value from A directly into B.  Alternatively, add the Timeout At input instead of replacing the Timeout, and set the initial value to NaN.  Check if the input is NaN - if so, get the current time in seconds, add the timeout value, and use that as the new Timeout At; otherwise, just use the Timeout At value that was passed in.

[aeastet]

I would say that your best bet is to make these vi's single exicution. Have time or counts be an input that is passed through everytime it exicutes. That way you are always looking at time. This would also keep you from getting stuck in the while loops inside these vi's

[aeastet]

Here is a VI that shows you what I am talking about. The reset stays on from the first VI so I am working on that. But this shoudl give you an Idea of how to get this done.

[aeastet]

OK I think this one does what you are looking to do.

[WG-]

If A.vi calls B.vi, and you expect B.vi to be done in 100 ms it's naturally impossible for A.vi to be done in 100 ms as well if B.vi times out. You can use the timed elapsed in B output and add it to the time elapsed in A to compare it with the timeout instead. However if B does time out A will still take a bit longer to time out.

Hmmm wel that would not be possible of course because what when B will execute infinitly...

If your current approach is as simple as the demo VIs you attached, you may very rarely run into a problem when the Tick Counter rolls over, giving you a much longer timeout than you expect.  (Of course, loops with no wait are also a problem).

Sounds like what you want is to change your timeout inputs to "Timeout At" inputs, so that it times out at a given time.  Instead of comparing with the Tick Count, compare with Get Date/Time in Seconds (this also solves the rollover problem).  Then you can pass the same Timeout At value from A directly into B.  Alternatively, add the Timeout At input instead of replacing the Timeout, and set the initial value to NaN.  Check if the input is NaN - if so, get the current time in seconds, add the timeout value, and use that as the new Timeout At; otherwise, just use the Timeout At value that was passed in.

Yes I actually came up with this solution also "Timeout At" idea. But I don't really like it, I was hoping for a more abstract/generic method. Where I could just use the tickcount. 

The real issue lies in fact with the problem that I can't determine which VI's are going to be called and because they can be executed in parallel. If I could do this I could just create a notifier for that set of VI's which need a timeout check.

[nathand]

---

@WouterG wrote:

Yes I actually came up with this solution also "Timeout At" idea. But I don't really like it, I was hoping for a more abstract/generic method. Where I could just use the tickcount. 

The real issue lies in fact with the problem that I can't determine which VI's are going to be called and because they can be executed in parallel. If I could do this I could just create a notifier for that set of VI's which need a timeout check.

---

Well, you can use TickCount instead of Get Date/Time, as long as you're careful about the rollover problem. 

Do you mean, you want to have a notifier time out at the appropriate time if it hasn't received a notification?  You can combine this approach with a notifier timeout.  Wrap "Wait on Notification" in a VI that accepts a "Timeout At" input, subtract the current time (or TickCount - subtraction will work properly through rollover of unsigned values) from the Timeout At value, and feed that to the notifier.