Hi,
In my case it is interesting to set an inhibit time on triggering of a non
periodic thread. An inhibit time is a time the thread has to wait between
two subsequent runs. For this purpose I have created an "InhibitTimeEvent".
We use this to protect us against "babbling idiots". I think this could be a
use full feature to put in RTT.
Butch.
Inhibit time for non periodic threads.
On Wed, 27 Jan 2010, Butch Slayer wrote:
> In my case it is interesting to set an inhibit time on triggering of a non periodic thread. An
> inhibit time is a time the thread has to wait between two subsequent runs. For this purpose I
> have created an "InhibitTimeEvent". We use this to protect us against "babbling idiots". I think
> this could be a use full feature to put in RTT.
>
The functionality is certainly useful! But wouldn't it be better to make
the timer infrastructure configurable with this option instead of
introducing a new event? Generally speaking (that is, for maximal
decoupling purposes) an event should never carry a name that says what the
event wants to realize (in _other_ components handling the event), but rather
what has happened (in the _firing_ component). Or maybe I misunderstand the
semantics of your InhibitTimeEvent?
Herman
Inhibit time for non periodic threads.
2010/1/27 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> The functionality is certainly useful! But wouldn't it be better to make
> the timer infrastructure configurable with this option instead of
> introducing a new event? Generally speaking (that is, for maximal
> decoupling purposes) an event should never carry a name that says what the
> event wants to realize (in _other_ components handling the event), but
> rather
> what has happened (in the _firing_ component). Or maybe I misunderstand
> the
> semantics of your InhibitTimeEvent?
>
> I'm not advocating the introduction of my InhibitTimeEvent. I made it
because I needed the functionality. I'd rather get rid of it because, as
you said it is not a very nice solution. And I think this inhibit time
should be in the NonPeriodicActivity/Thread. Of course other users have to
be interested too before this is made into a new feature.
Butch.
Inhibit time for non periodic threads.
On Wed, 27 Jan 2010, Butch Slayer wrote:
> 2010/1/27 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> The functionality is certainly useful! But wouldn't it be better to make
> the timer infrastructure configurable with this option instead of
> introducing a new event? Generally speaking (that is, for maximal
> decoupling purposes) an event should never carry a name that says what the
> event wants to realize (in _other_ components handling the event), but rather
> what has happened (in the _firing_ component). Or maybe I misunderstand the
> semantics of your InhibitTimeEvent?
>
> I'm not advocating the introduction of my InhibitTimeEvent. I made it because I needed the
> functionality. I'd rather get rid of it because, as you said it is not a very nice solution. And
> I think this inhibit time should be in the NonPeriodicActivity/Thread. Of course other users have
> to be interested too before this is made into a new feature.
>
Thanks for the clarification! I agree with you that this (and other)
timer-related configuration flexibilities would be a very relevant addition
to the RTT framework.
Another use case I am being confronted with more and more is that of
"virtual timing", in contexts where you have to integrate a multi-vendor,
multi-process simulation components, each running on their own "real time"
clocks... (The use case we are working on right now is to replace a real
robot system (LWR arm + visual servoing) with a virtual world in Blender,
and this replacement should work seemlessly (just by reconfiguring data
ports, and the platform properties, such as time)...
Herman