Is there a way to schedule an event to occur in the future?

[magicbean]

I am looking for a generic way to schedule events which are triggered in the future (in LabVIEW without using DAQ).

I already have a way of scheduling future events but it uses a polling thread to keep an eye on the list of times and execute the events and maintain the list. To get higher time resolution it would have to run faster although most of the time there are no events in the queue.

(An 'event' in my queue is currently a cluster of a future time and a boolean control reference).

What I would like to do is queue events (could be user defined events) so that they can be posted at future times without a process having to poll for them.

If I make my polling event wait (e.g. using the ms Timer) then it can't wake up do deal with an event which was queued later but required to be posted sooner.

Any clues?

[M_Peeker]

---

magicbean wrote:

What I would like to do is queue events (could be user defined events) so that they can be posted at future times without a process having to poll for them.

If I make my polling event wait (e.g. using the ms Timer) then it can't wake up do deal with an event which was queued later but required to be posted sooner.

---

Off the top of my head, you could use a separate event to signal that a new event has been queued up, evaluate the queue of events at this time and recalculate the timeout before the next event is to be fired.

[KathrynB]

A user event in a timed loop? Although I guess that is a bit like the polling option you already have, or would just give you a periodic event, which isn't what you've asked for either.

If you've got a queue, then could you do something fancy with the timeout function of the dequeue element? So, set your timeout to your future time (this can be varied), then use the timeout Boolean to decide whether to use the output element of the queue or a default behaviour (your future item) - which would be only one case, although you could have a second queue for future items if you have more than one behaviour, or use a notifier here for different future items. This could get complicated to understand, but would avoid your polling, and would still ensure that any other queue functions are undertaken in the meantime.

[Yamaeda]

Via vi server yoi can start a vi which waits a set time and then fires the event, without interfering with the rest of the program.
/Y

[magicbean]

@M_Peeker: I get your point but this is almost what I do now. The problem is that I want to be able to add events to the queue dynamically. If the scheduling thread is now asleep because there was nothing for it to do for, say, 1000ms, how is it going to deal with newly queued event event that needs dealing with in 100ms?

[magicbean]

@KatherynB: As above, I thought of using the timeout but it doesn't cope with an event which is queued later but needs to be actioned sooner (as the thread is stuck waiting for a longer time already).

The only thought I have is forcing the scheduling queue to error by deleting the queue when I add an earlier event. Seems a bit clunky though and I haven't tried it to see if it could work.

[magicbean]

@Yamaeda: I'm not sure why this is any different. If the VI waits for the required time and then fires the event how does it cope with events queued later but requiring sooner action?

Oh, wait, I guess it might work if it's a re-entrant VI.....so that I get a new instance per event.....?

[M_Peeker]

---

@magicbean wrote:

@M_Peeker: I get your point but this is almost what I do now. The problem is that I want to be able to add events to the queue dynamically. If the scheduling thread is now asleep because there was nothing for it to do for, say, 1000ms, how is it going to deal with newly queued event event that needs dealing with in 100ms?

---

My idea is that you have some sort of schedule (array, queue or whatever) that contain the user events you want to fire and the times when you want to fire them. Whenever you add something to the list, you also fire an "schedule updated" user event.

Then you have your continuously running vi with an event structure with a timeout that is depending on the schedule, it is set to wait until the next event in the schedule is to happen. The timeout case then fires that scheduled event, takes it away from the schedule and recalculates the next timeout. This event structure also responds to the "schedule updated" user event, at which point the next timeout is recalculated.

Haven't tried it but I figure it should work.

[altenbach]

---

@magicbean wrote:

To get higher time resolution it would have to run faster although most of the time there are no events in the queue.

---

What time resolution do you want/need? Please be specific. (milliseconds, seconds, etc.)

---

@magicbean wrote:

If I make my polling event wait (e.g. using the ms Timer) then it can't wake up do deal with an event which was queued later but required to be posted sooner.

---

I think part of the confusion is your generic use of the word "event", while events have a very defined special meaning in LabVIEW. "Polling event" is a contradiction.

So, first of all, do you even use event structures? Can you show us some code? There is probably an easy solution.

For example you could look at the array of scheduled tasks and recalculate a new timeout value for an event structure whenever a new task is added or whenever a task has just executed. No polling needed. In the timeout event, determine which task is ready to execute and launch it. (e.g. via a queue or similar). 

[Intaris · Accepted solution]

Launch a reentrant clone "fire and forget" for each thing you want to time.  Then they will all count down independently of each other.