Cyclic event for event structure ... a kind of timeout but cyclic !

[manu.NET]

Hello,

It should be nice to add such a kind of "Cyclic event" in an event structure.

For the moment, the event structure only has a timeout which occurs after a certain amount of time ... only if no other event has occurs !

There is a problem when the timeout time is longer than the time between two events. => Then the timeout never occurs !

So it should be nice to add an input to the event structure, in order to add on ore more cyclic events.

So a Timer event could occurs in a cyclic way without having to build cyclic event generator !

(The implementation of this cyclic event should be aware to not fill the event queues.)

The cyclic event could be configured the same way a the timeout, with a special input of the event structure.

(One input per cyclic event generator / timer)

A kind of DotNet Timer component, dropped on a wondows form.

I have already created my own cyclic event generator ... but i think that this need could be usefull for all Labview users.

Manu.net

[AristosQueue (NI)]

This is very similar to the earlier idea for merging the Timed Loop and the Event Structure.

Problem: How do you handle when the time needed to handle any single event (including the cyclic time event) is longer than the cycle time?

[kegghead]

I've implemented a few of these on my own, usually along the lines of rather than timing out after 50 ms(for example), I want my structure to timeout every multiple of 50 ms (similar to the wait for next ms multiple primitive). Works wonderfully for updating UI animations etc.

The point of this wouldn't be to ensure you catch an event every X ms, so having an event that runs longer than the cycle time shouldn't be a problem.

[manu.NET]

Hello,

To avoid the problem of "cyclic event treatment over time" the cyclic event re-throw should be handled as DotNet timers.

The next cyclic event is only thrown at the end of the "cyclic event treatment".

(The time needed to treat the event should be substract from the cyclic delay)  

So the event will be cyclic with a non deterministic delay, but with no risk to fill the event queue.

With DotNet timers you can also modify the delay at run time, also stop, re start the cyclic event generator.

I have already done something similar in my own code ... but it think it would be better and powerfuller if made by NI.

Manu.net

[donkdonk]

>>Problem: How do you handle when the time needed to handle any single event (including the cyclic time event) is longer than the cycle time?

When you create a cyclic user event (which can be done wtih current versions of LabVIEW), how is the event handled when any single event is longer than the cyclic user event? 

I realize it now comes closer to the idea  merging the Timed Loop and the Event Structure which I think you should not do. I agree that loops and event structures should be separate things, however if one sees the timeout terminal, one wonders if it cannot be (optionally) made cyclic.

But I must admit I don't know what pitfalls there may be..

Would it be possible to have a terminal in the timeout/cyclic event "finished  late" and just wait for the next cycle?

[altenbach]

I would love to have a timeout event with "regularity", i.e. it should wake up at regular intervals and not be reset by other events.

Here is an old example (from the end of this old discussion) that roughly demonstrates the functionality i would like to have.

[altenbach]

> I would love to have a timeout event with "regularity", i.e. it should wake up at regular intervals and not be reset by other events.

Here is a more updated version that is more modular. 

[wiebe@CARYA]

I have demon\actor based solution (encapsulated in a class) that triggers user events at given interval (for a given nr. of iterations). Benefit is you can start as many as you like.

This fits my other event based solutions, like file\directory watcher, that triggers a user event when a file or directory is changes (using .NET).

This doesn't address the cycle time problem: if the cycle time is to small, I made a bad program.