Allow multiple. Independent timeouts in the event structure

[Mark_Yedinak]

It would be desirable if the event structure supported more than one timeout event. Ideally we could define multiple, independent timeout events. It could provide a fixed number (more than one) if this eases the implementation. Currently if you want multiple timeouts you end up with some type of state machine in the timeout event to control multiple events. Multiple timers would allow us to easily process different timeout events. Allow us to control them easily without special timeout management logic in the current single timeout event. Currently we can register/deregister user events. Let's extend this to timeouts as well.

[altenbach]

I am trying to figure out what the rules should be. I assume that execution of one of the timeout structures should not reset the timer of the other timeout events, else nothing would work right. So what exactly should reset the timeouts?

Following this thought, maybe a better idea would be to have "timed events" that execute on a fixed shedule, similar to this idea, also see my comment there).

[Mark_Yedinak]

In the simplest form I could envision the timer terminal being an array. Each element would designate the timeout value for the corresponding timer. Setting the value to -1 would disable that timer just like today. And yes, each timer would be completely independent of the others. Disabling one or changing it's timeout value would have no effect on the other timers. It certainly isn't a radical idea to envision different timeout events within a system. This would just give us a flexible means of implementing them. Otherwise we are stuck with the current method which requires code within the timeout to determine if a specific timeout has occurred.

I do realize you can achieve something similar using multiple event structures but I try to limit a VI to a single event structure. Upper level VIs could benefit from having multiple timers.

[AristosQueue (NI)]

Timeout events are not the same as periodic events. I think what the idea is asking for is a way to integrate this into a single structure:

[Mark_Yedinak]

Yes, you did capture my intent. It seems superfluous to have to have all of the parallel loops in order to get the periodic timer functionality. Perhaps the event structure can have the current timeout as is which is driven by inactivity and reset when any event occurs and then have a second set of timer events which fire as cyclic events.

[SteveChandler]

I am giving this kudos specifically for periodic events - events that fire at a specified interval regardless of front panel activity. They should not be called "timeouts" but "timers" or something similar.