Dear all,
I would like to add software interrupts (and corresponding handlers) to an Orocos (rtt 1.10) state machine.
I will give a very concrete example:
Let's say I am in a state that executes a sequence of motion commands.
*****************************************
---
do nAxesGeneratorPos.moveTo(<desired position1>, <time1>)
do nAxesGeneratorPos.moveTo(<desired position2>, <time2>)
do nAxesGeneratorPos.moveTo(<desired position3>, <time3>)
...
do nAxesGeneratorPos.moveTo(<desired positionn>, <timen>)
---
*****************************************
Note that moveTo is a command (synchronous, you only return to the state machine processor once it is completed). nAxesGeneratorPos is a component you can find inside OCL, if you want to have all details.
Now I would like to have the state machine and the robot motion interrupted immediately when some event occurs at ANY time while I am in this state. (that is: I do not want to wait until the command that is currently being executed finishes). In the physical world this could be triggered by for example a force that exceeds a threshold, a button that is pressed by a person, or a switch that is hit by an object on a conveyer belt.
I found an old discussion on this topic on http://www.orocos.org/node/861, but I didn't see any 'clean' way of implementing it (that is: without modifying the moveTo command itself or manually adding a lot of extra code to the state machine for each command that makes it hard to read). Furthermore the interrupt should work during all commands I am using in the state; the moveTo command of the nAxesGeneratorPos is just one particular example.
I would imagine it to work in its basic form like this:
*****************************************
---
interrupt(<name>)
{
<event> and <handler>
}
---
---
interrupt(<name>, on)
nAxesGeneratorPos.moveTo(<desired position1>, <time1>)
nAxesGeneratorPos.moveTo(<desired position2>, <time2>)
nAxesGeneratorPos.moveTo(<desired position3>, <time3>)
...
nAxesGeneratorPos.moveTo(<desired positionn>, <timen>)
interrupt(<name>, off)
---
*****************************************
Is this possible? Maybe I am just not searching for the correct keywords... Did anyone do this before, and if so could you point me to the correct documentation page, and an implementation example?
Thanks,
Wilm
interrupts in a state machine
On Sat, Aug 7, 2010 at 1:06 PM, Wilm Decré <Wilm [dot] Decre [..] ...> wrote:
> Dear all,
>
> I would like to add software interrupts (and corresponding handlers) to an Orocos (rtt 1.10) state machine.
>
> I will give a very concrete example:
>
> Let's say I am in a state that executes a sequence of motion commands.
>
> *****************************************
> ---
> do nAxesGeneratorPos.moveTo(<desired position1>, <time1>)
> do nAxesGeneratorPos.moveTo(<desired position2>, <time2>)
> do nAxesGeneratorPos.moveTo(<desired position3>, <time3>)
> ...
> do nAxesGeneratorPos.moveTo(<desired positionn>, <timen>)
> ---
> *****************************************
>
> Note that moveTo is a command (synchronous, you only return to the state machine processor once it is completed). nAxesGeneratorPos is a component you can find inside OCL, if you want to have all details.
>
> Now I would like to have the state machine and the robot motion interrupted immediately when some event occurs at ANY time while I am in this state. (that is: I do not want to wait until the command that is currently being executed finishes). In the physical world this could be triggered by for example a force that exceeds a threshold, a button that is pressed by a person, or a switch that is hit by an object on a conveyer belt.
You're mixing 'computation' with 'coordination' here. In other words,
your motion path is a functional-thing, the decision to interrupt the
motion path and take proper actions is an
orchestration/coordination/supervision/whatever-you-call-it-thing.
Leave your moveTo sequence as is and install a proper (ie additional)
decisional state machine that stops the nAxesGeneratorPos and the
motion path state machine / program. You are clearly having a
supervision problem. Solve it at a higher level, with the help of the
functional components available (they need to support supervisional
intervention, for example, being allowed to be stopped or reset). So
you will likely need to modify nAxesGeneratorPos a bit too.
It's extremely clear to me, but I wonder is it to you too or does this
sound still too high-level ?
Peter
--
Orocos-Users mailing list
Orocos-Users [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
interrupts in a state machine
> -----Original Message-----
> From: Peter Soetens [mailto:peter [..] ...]
> Sent: Saturday, August 07, 2010 11:59 PM
> To: Wilm Decré
> Cc: orocos-users [..] ...
> Subject: Re: [Orocos-users] interrupts in a state machine
>
> On Sat, Aug 7, 2010 at 1:06 PM, Wilm Decré
> <Wilm [dot] Decre [..] ...> wrote:
> > Dear all,
> >
> > I would like to add software interrupts (and corresponding handlers)
> to an Orocos (rtt 1.10) state machine.
> >
> > I will give a very concrete example:
> >
> > Let's say I am in a state that executes a sequence of motion
> commands.
> >
> > *****************************************
> > ---
> > do nAxesGeneratorPos.moveTo(<desired position1>, <time1>)
> > do nAxesGeneratorPos.moveTo(<desired position2>, <time2>)
> > do nAxesGeneratorPos.moveTo(<desired position3>, <time3>)
> > ...
> > do nAxesGeneratorPos.moveTo(<desired positionn>, <timen>)
> > ---
> > *****************************************
> >
> > Note that moveTo is a command (synchronous, you only return to the
> state machine processor once it is completed). nAxesGeneratorPos is a
> component you can find inside OCL, if you want to have all details.
> >
> > Now I would like to have the state machine and the robot motion
> interrupted immediately when some event occurs at ANY time while I am
> in this state. (that is: I do not want to wait until the command that
> is currently being executed finishes). In the physical world this could
> be triggered by for example a force that exceeds a threshold, a button
> that is pressed by a person, or a switch that is hit by an object on a
> conveyer belt.
>
> You're mixing 'computation' with 'coordination' here. In other words,
> your motion path is a functional-thing, the decision to interrupt the
> motion path and take proper actions is an
> orchestration/coordination/supervision/whatever-you-call-it-thing.
>
> Leave your moveTo sequence as is and install a proper (ie additional)
> decisional state machine that stops the nAxesGeneratorPos and the
> motion path state machine / program. You are clearly having a
> supervision problem. Solve it at a higher level, with the help of the
> functional components available (they need to support supervisional
> intervention, for example, being allowed to be stopped or reset). So
> you will likely need to modify nAxesGeneratorPos a bit too.
>
> It's extremely clear to me, but I wonder is it to you too or does this
> sound still too high-level ?
>
> Peter
Thanks Herman and Peter.
I don't really think this is mixing 'computation' and 'coordination': the state machine containing the moveTo sequence is also a coordinating entity.
It consists of a number of states, of which one is the 'MoveAroundState' that _coordinates_ these motions: it says: move to a certain position. When that is finished successfully, move to a second position etc. The computation of the motion itself is done inside the nAxesGeneratorPos component, not on the state machine level.
I think however it is a problem of _multi-level_ coordination. If I understand correctly, the idea is to run several (in this case: 2) state machines in parallel.
For the concrete example:
State machine 1: includes the 'MoveAroundState' (and possibly also other states) that includes the sequence of motion commands given above.
State machine 2: includes the events and handlers that occur asynchronously (the button pressing, switch hitting et cetera).
Both state machines are activated. When an event occurs, state machine 2 stops (pauzes) both state machine 1 and nAxesGeneratorPos in an appropriate way, does some other actions, and then (for example) starts (continues) nAxesGeneratorPos and state machine 1 again.
The reason why I putted the interrupt on/off statements is that interrupts can be defined globally (for example events for safety reasons), but they can also be valid only in a certain state, or even in only part of a state. If we want to distribute this over different state machines it requires some overhead code since you would then always have to check in state machine 2 where you are in state machine 1.
Other related issues are: 1. defining priorities of interrupts (to be able to choose whether the event handler of event A can be interrupted by event B or not) and 2. queuing interrupts.
Wilm
--
Orocos-Users mailing list
Orocos-Users [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
interrupts in a state machine
On Aug 8, 2010, at 08:06 , Wilm Decré wrote:
>> -----Original Message-----
>> From: Peter Soetens [mailto:peter [..] ...]
>> Sent: Saturday, August 07, 2010 11:59 PM
>> To: Wilm Decré
>> Cc: orocos-users [..] ...
>> Subject: Re: [Orocos-users] interrupts in a state machine
>>
>> On Sat, Aug 7, 2010 at 1:06 PM, Wilm Decré
>> <Wilm [dot] Decre [..] ...> wrote:
>>> Dear all,
>>>
>>> I would like to add software interrupts (and corresponding handlers)
>> to an Orocos (rtt 1.10) state machine.
>>>
>>> I will give a very concrete example:
>>>
>>> Let's say I am in a state that executes a sequence of motion
>> commands.
>>>
>>> *****************************************
>>> ---
>>> do nAxesGeneratorPos.moveTo(<desired position1>, <time1>)
>>> do nAxesGeneratorPos.moveTo(<desired position2>, <time2>)
>>> do nAxesGeneratorPos.moveTo(<desired position3>, <time3>)
>>> ...
>>> do nAxesGeneratorPos.moveTo(<desired positionn>, <timen>)
>>> ---
>>> *****************************************
>>>
>>> Note that moveTo is a command (synchronous, you only return to the
>> state machine processor once it is completed). nAxesGeneratorPos is a
>> component you can find inside OCL, if you want to have all details.
>>>
>>> Now I would like to have the state machine and the robot motion
>> interrupted immediately when some event occurs at ANY time while I am
>> in this state. (that is: I do not want to wait until the command that
>> is currently being executed finishes). In the physical world this could
>> be triggered by for example a force that exceeds a threshold, a button
>> that is pressed by a person, or a switch that is hit by an object on a
>> conveyer belt.
>>
>> You're mixing 'computation' with 'coordination' here. In other words,
>> your motion path is a functional-thing, the decision to interrupt the
>> motion path and take proper actions is an
>> orchestration/coordination/supervision/whatever-you-call-it-thing.
>>
>> Leave your moveTo sequence as is and install a proper (ie additional)
>> decisional state machine that stops the nAxesGeneratorPos and the
>> motion path state machine / program. You are clearly having a
>> supervision problem. Solve it at a higher level, with the help of the
>> functional components available (they need to support supervisional
>> intervention, for example, being allowed to be stopped or reset). So
>> you will likely need to modify nAxesGeneratorPos a bit too.
>>
>> It's extremely clear to me, but I wonder is it to you too or does this
>> sound still too high-level ?
>>
>> Peter
>
> Thanks Herman and Peter.
>
> I don't really think this is mixing 'computation' and 'coordination': the state machine containing the moveTo sequence is also a coordinating entity.
> It consists of a number of states, of which one is the 'MoveAroundState' that _coordinates_ these motions: it says: move to a certain position. When that is finished successfully, move to a second position etc. The computation of the motion itself is done inside the nAxesGeneratorPos component, not on the state machine level.
>
> I think however it is a problem of _multi-level_ coordination. If I understand correctly, the idea is to run several (in this case: 2) state machines in parallel.
>
> For the concrete example:
>
> State machine 1: includes the 'MoveAroundState' (and possibly also other states) that includes the sequence of motion commands given above.
>
> State machine 2: includes the events and handlers that occur asynchronously (the button pressing, switch hitting et cetera).
>
> Both state machines are activated. When an event occurs, state machine 2 stops (pauzes) both state machine 1 and nAxesGeneratorPos in an appropriate way, does some other actions, and then (for example) starts (continues) nAxesGeneratorPos and state machine 1 again.
>
> The reason why I putted the interrupt on/off statements is that interrupts can be defined globally (for example events for safety reasons), but they can also be valid only in a certain state, or even in only part of a state. If we want to distribute this over different state machines it requires some overhead code since you would then always have to check in state machine 2 where you are in state machine 1.
>
> Other related issues are: 1. defining priorities of interrupts (to be able to choose whether the event handler of event A can be interrupted by event B or not) and 2. queuing interrupts.
Sounds to me like you can do some of this with the existing functionality, but that you will need to introduce some transitionary sub-states. If state XYZ has some interruptible and some non-interruptible portions, model them as sub-states in which some of these sub-states can respond to the interrupting events, and some of the sub-states can't. We've had to do things like this to get complete system state mechanics to work with Orocos good (but not yet great) state machine implementations.
HTH
S
interrupts in a state machine
On Sun, 8 Aug 2010, Wilm Decré wrote:
>> -----Original Message-----
>> From: Peter Soetens [mailto:peter [..] ...]
>> Sent: Saturday, August 07, 2010 11:59 PM
>> To: Wilm Decré
>> Cc: orocos-users [..] ...
>> Subject: Re: [Orocos-users] interrupts in a state machine
>>
>> On Sat, Aug 7, 2010 at 1:06 PM, Wilm Decré
>> <Wilm [dot] Decre [..] ...> wrote:
>>> Dear all,
>>>
>>> I would like to add software interrupts (and corresponding handlers)
>> to an Orocos (rtt 1.10) state machine.
>>>
>>> I will give a very concrete example:
>>>
>>> Let's say I am in a state that executes a sequence of motion
>> commands.
>>>
>>> *****************************************
>>> ---
>>> do nAxesGeneratorPos.moveTo(<desired position1>, <time1>)
>>> do nAxesGeneratorPos.moveTo(<desired position2>, <time2>)
>>> do nAxesGeneratorPos.moveTo(<desired position3>, <time3>)
>>> ...
>>> do nAxesGeneratorPos.moveTo(<desired positionn>, <timen>)
>>> ---
>>> *****************************************
>>>
>>> Note that moveTo is a command (synchronous, you only return to the
>> state machine processor once it is completed). nAxesGeneratorPos is a
>> component you can find inside OCL, if you want to have all details.
>>>
>>> Now I would like to have the state machine and the robot motion
>> interrupted immediately when some event occurs at ANY time while I am
>> in this state. (that is: I do not want to wait until the command that
>> is currently being executed finishes). In the physical world this could
>> be triggered by for example a force that exceeds a threshold, a button
>> that is pressed by a person, or a switch that is hit by an object on a
>> conveyer belt.
>>
>> You're mixing 'computation' with 'coordination' here. In other words,
>> your motion path is a functional-thing, the decision to interrupt the
>> motion path and take proper actions is an
>> orchestration/coordination/supervision/whatever-you-call-it-thing.
>>
>> Leave your moveTo sequence as is and install a proper (ie additional)
>> decisional state machine that stops the nAxesGeneratorPos and the
>> motion path state machine / program. You are clearly having a
>> supervision problem. Solve it at a higher level, with the help of the
>> functional components available (they need to support supervisional
>> intervention, for example, being allowed to be stopped or reset). So
>> you will likely need to modify nAxesGeneratorPos a bit too.
>>
>> It's extremely clear to me, but I wonder is it to you too or does this
>> sound still too high-level ?
>>
>> Peter
>
> Thanks Herman and Peter.
>
> I don't really think this is mixing 'computation' and 'coordination': the state machine containing the moveTo sequence is also a coordinating entity.
> It consists of a number of states, of which one is the 'MoveAroundState' that _coordinates_ these motions: it says: move to a certain position. When that is finished successfully, move to a second position etc. The computation of the motion itself is done inside the nAxesGeneratorPos component, not on the state machine level.
>
> I think however it is a problem of _multi-level_ coordination. If I understand correctly, the idea is to run several (in this case: 2) state machines in parallel.
>
> For the concrete example:
>
> State machine 1: includes the 'MoveAroundState' (and possibly also other states) that includes the sequence of motion commands given above.
>
> State machine 2: includes the events and handlers that occur asynchronously (the button pressing, switch hitting et cetera).
>
> Both state machines are activated. When an event occurs, state machine 2 stops (pauzes) both state machine 1 and nAxesGeneratorPos in an appropriate way, does some other actions, and then (for example) starts (continues) nAxesGeneratorPos and state machine 1 again.
>
> The reason why I putted the interrupt on/off statements is that interrupts can be defined globally (for example events for safety reasons), but they can also be valid only in a certain state, or even in only part of a state. If we want to distribute this over different state machines it requires some overhead code since you would then always have to check in state machine 2 where you are in state machine 1.
>
> Other related issues are: 1. defining priorities of interrupts (to be able to choose whether the event handler of event A can be interrupted by event B or not) and 2. queuing interrupts.
You are experiencing all the problems related to the non-perfect support of
hierarchical state machines in Orocos... (Markus is working on improving
this situation, but don't hold your breath...)
Short answers:
- yes, when running multiple state machines, each of them should (possibly)
react to all events
- no, state machine 2 should never check in which state state machine 1 is
- events = interrupts
- priorities and queueing are _policies_ of event handling; should be
configurable, but, preferably, should not make any difference _if_ you
have made a good state machine...
Lessons to be learned: (i) Coordination is tough, (ii) making components
that can be well coordinated is even tougher. Many of the current Orocos
components are not well designed, from a Coordination point of view, since
they are not pre-emptible...
Herman
interrupts in a state machine
On Aug 8, 2010, at 08:29 , Herman Bruyninckx wrote:
> On Sun, 8 Aug 2010, Wilm Decré wrote:
>
>>> -----Original Message-----
>>> From: Peter Soetens [mailto:peter [..] ...]
>>> Sent: Saturday, August 07, 2010 11:59 PM
>>> To: Wilm Decré
>>> Cc: orocos-users [..] ...
>>> Subject: Re: [Orocos-users] interrupts in a state machine
>>>
>>> On Sat, Aug 7, 2010 at 1:06 PM, Wilm Decré
>>> <Wilm [dot] Decre [..] ...> wrote:
>>>> Dear all,
>>>>
>>>> I would like to add software interrupts (and corresponding handlers)
>>> to an Orocos (rtt 1.10) state machine.
>>>>
>>>> I will give a very concrete example:
>>>>
>>>> Let's say I am in a state that executes a sequence of motion
>>> commands.
>>>>
>>>> *****************************************
>>>> ---
>>>> do nAxesGeneratorPos.moveTo(<desired position1>, <time1>)
>>>> do nAxesGeneratorPos.moveTo(<desired position2>, <time2>)
>>>> do nAxesGeneratorPos.moveTo(<desired position3>, <time3>)
>>>> ...
>>>> do nAxesGeneratorPos.moveTo(<desired positionn>, <timen>)
>>>> ---
>>>> *****************************************
>>>>
>>>> Note that moveTo is a command (synchronous, you only return to the
>>> state machine processor once it is completed). nAxesGeneratorPos is a
>>> component you can find inside OCL, if you want to have all details.
>>>>
>>>> Now I would like to have the state machine and the robot motion
>>> interrupted immediately when some event occurs at ANY time while I am
>>> in this state. (that is: I do not want to wait until the command that
>>> is currently being executed finishes). In the physical world this could
>>> be triggered by for example a force that exceeds a threshold, a button
>>> that is pressed by a person, or a switch that is hit by an object on a
>>> conveyer belt.
>>>
>>> You're mixing 'computation' with 'coordination' here. In other words,
>>> your motion path is a functional-thing, the decision to interrupt the
>>> motion path and take proper actions is an
>>> orchestration/coordination/supervision/whatever-you-call-it-thing.
>>>
>>> Leave your moveTo sequence as is and install a proper (ie additional)
>>> decisional state machine that stops the nAxesGeneratorPos and the
>>> motion path state machine / program. You are clearly having a
>>> supervision problem. Solve it at a higher level, with the help of the
>>> functional components available (they need to support supervisional
>>> intervention, for example, being allowed to be stopped or reset). So
>>> you will likely need to modify nAxesGeneratorPos a bit too.
>>>
>>> It's extremely clear to me, but I wonder is it to you too or does this
>>> sound still too high-level ?
>>>
>>> Peter
>>
>> Thanks Herman and Peter.
>>
>> I don't really think this is mixing 'computation' and 'coordination': the state machine containing the moveTo sequence is also a coordinating entity.
>> It consists of a number of states, of which one is the 'MoveAroundState' that _coordinates_ these motions: it says: move to a certain position. When that is finished successfully, move to a second position etc. The computation of the motion itself is done inside the nAxesGeneratorPos component, not on the state machine level.
>>
>> I think however it is a problem of _multi-level_ coordination. If I understand correctly, the idea is to run several (in this case: 2) state machines in parallel.
>>
>> For the concrete example:
>>
>> State machine 1: includes the 'MoveAroundState' (and possibly also other states) that includes the sequence of motion commands given above.
>>
>> State machine 2: includes the events and handlers that occur asynchronously (the button pressing, switch hitting et cetera).
>>
>> Both state machines are activated. When an event occurs, state machine 2 stops (pauzes) both state machine 1 and nAxesGeneratorPos in an appropriate way, does some other actions, and then (for example) starts (continues) nAxesGeneratorPos and state machine 1 again.
>>
>> The reason why I putted the interrupt on/off statements is that interrupts can be defined globally (for example events for safety reasons), but they can also be valid only in a certain state, or even in only part of a state. If we want to distribute this over different state machines it requires some overhead code since you would then always have to check in state machine 2 where you are in state machine 1.
>>
>> Other related issues are: 1. defining priorities of interrupts (to be able to choose whether the event handler of event A can be interrupted by event B or not) and 2. queuing interrupts.
>
> You are experiencing all the problems related to the non-perfect support of
> hierarchical state machines in Orocos... (Markus is working on improving
> this situation, but don't hold your breath...)
>
> Short answers:
> - yes, when running multiple state machines, each of them should (possibly)
> react to all events
Maybe, depends on the context of the situation. Some of our components have multiple state machines that are very close to truly orthogonal, and each sub machine responds to a different set of events. YMMV.
> - no, state machine 2 should never check in which state state machine 1 is
+1 (at least in an ideal world)
> - events = interrupts
+1
> - priorities and queueing are _policies_ of event handling; should be
> configurable, but, preferably, should not make any difference _if_ you
> have made a good state machine...
>
> Lessons to be learned: (i) Coordination is tough, (ii) making components
> that can be well coordinated is even tougher. Many of the current Orocos
> components are not well designed, from a Coordination point of view, since
> they are not pre-emptible...
+1, but as noted, this can be very difficult.
S
interrupts in a state machine
On Sunday 08 August 2010 14:29:26 Herman Bruyninckx wrote:
> On Sun, 8 Aug 2010, Wilm Decré wrote:
...
> > The reason why I putted the interrupt on/off statements is that
> > interrupts can be defined globally (for example events for safety
> > reasons), but they can also be valid only in a certain state, or even in
> > only part of a state. If we want to distribute this over different state
> > machines it requires some overhead code since you would then always have
> > to check in state machine 2 where you are in state machine 1.
> >
> > Other related issues are: 1. defining priorities of interrupts (to be
> > able to choose whether the event handler of event A can be interrupted by
> > event B or not) and 2. queuing interrupts.
>
> You are experiencing all the problems related to the non-perfect support of
> hierarchical state machines in Orocos...
I think so too. You'll have to work around it...
Peter
interrupts in a state machine
On Sat, 7 Aug 2010, Wilm Decré wrote:
> Dear all,
>
> I would like to add software interrupts (and corresponding handlers) to an Orocos (rtt 1.10) state machine.
>
> I will give a very concrete example:
>
> Let's say I am in a state that executes a sequence of motion commands.
>
> *****************************************
> ---
> do nAxesGeneratorPos.moveTo(<desired position1>, <time1>)
> do nAxesGeneratorPos.moveTo(<desired position2>, <time2>)
> do nAxesGeneratorPos.moveTo(<desired position3>, <time3>)
> ...
> do nAxesGeneratorPos.moveTo(<desired positionn>, <timen>)
> ---
> *****************************************
>
> Note that moveTo is a command (synchronous, you only return to the state
> machine processor once it is completed).
This is wrong... Any state in a state machine should _only_ have
interruptable activities! By definition: a state machine must be able to
transition to another state when one of the events come in to which it is
registered. In your case, it can only react to the "command finished"
event.
> nAxesGeneratorPos is a component
> you can find inside OCL, if you want to have all details.
>
> Now I would like to have the state machine and the robot motion
> interrupted immediately when some event occurs at ANY time while I am in
> this state. (that is: I do not want to wait until the command that is
> currently being executed finishes). In the physical world this could be
> triggered by for example a force that exceeds a threshold, a button that
> is pressed by a person, or a switch that is hit by an object on a
> conveyer belt.
>
> I found an old discussion on this topic on
> http://www.orocos.org/node/861, but I didn't see any 'clean' way of
> implementing it (that is: without modifying the moveTo command itself or
> manually adding a lot of extra code to the state machine for each command
> that makes it hard to read). Furthermore the interrupt should work during
> all commands I am using in the state; the moveTo command of the
> nAxesGeneratorPos is just one particular example.
>
> I would imagine it to work in its basic form like this:
>
> *****************************************
> ---
> interrupt(<name>)
> {
> <event> and <handler>
> }
> ---
> ---
> interrupt(<name>, on)
>
> nAxesGeneratorPos.moveTo(<desired position1>, <time1>)
> nAxesGeneratorPos.moveTo(<desired position2>, <time2>)
> nAxesGeneratorPos.moveTo(<desired position3>, <time3>)
> ...
> nAxesGeneratorPos.moveTo(<desired positionn>, <timen>)
>
> interrupt(<name>, off)
> ---
> *****************************************
>
> Is this possible? Maybe I am just not searching for the correct
> keywords... Did anyone do this before, and if so could you point me to
> the correct documentation page, and an implementation example?
Your solution suggests to do the right thing, which is: to change the
moveTo command so that it becomes preemtible! The "interrupt(<name>, on)"
and "interrupt(<name>, off)" are superfluous tags in a state machine since
it is the _default_ behaviour, since the state machine should _always_
react to registered events!
So, in summary: don't use blocking calls in a state machine! It's wrong by
definition. (I hope everyone reads this summary more than twice...)
In your particular case (which is indeed very common in robotics
applications), the solution is the following:
- your state machine does not _call_ "moveTo", but has a data port
connection (or, in 2.0 speak, a motion "service") to a trajectory
generator component
- you use that data port to send (in a non-blocking way) a motion request
to the generator component
- the generator component starts doing its motion generation, also in a
non-blocking way, meaning that it also has its own state machine that can
be interrupted by an event.
- your state machine is waiting for (i) an event from the generator to
continue, _and_ (ii) the interrupt event. It reacts to both events in a
different way, in general.
Herman