[Feature Request]: Add start conditions for a McePosTable entry

[yeu-rioual]

McePosTable version

0.2.0

Description of the new feature / enhancement

This is about adding a mechanism which prevents the motion of a PosTable entry to be executed until the configured start conditions for that entry are satisfied. So PosTable would schedule a standstill and only proceed after the start conditions are satisfied.

Ideally, if the conditions are already satisfied in-time, the robot should not have any short standstill, but smoothly continue its trajectory (blended motion).

Implementation

This mechanism only checks before starting the motion. Once the motion of an entry has started, the start conditions are disregarded. So it cannot be used for aborting an already started motion.

The used should be informed about the status of the missing start conditions.

Further specification in the pull request

Scenario when this would be used?

• Pick and place
  Robot needs to wait for authorisation to enter a station/area
• Checking for parts
  Robot needs to wait until all parts have been placed in e.g. a welding jig.

---

To keep the PR's small, this feature will be implemented in two steps:

• [x] 1) Implement the basic startConditions mechanism (this will always schedule a standstill)

  36

• [ ] 2) Add the functionality for startConditions with look ahead (to prevent a short standstill if conditions are satisfied in-time)

  37

[yeu-rioual]

About the InterlockFlags of McePosTableIO, should the robot stops on True or False ?

I figured that "True" = "Yes" = "I want interlock". So True should stop the robot. And a default False would allow the robot to move.

But we could also consider "True" = "the robot can move".

Which would be the most natural option ?

[yeu-rioual]

When runnig McePosTable step by step (nMode = 2), how should-we handle the bStep rising edge ?

Scenario 1:

• Wait for bStep
• If Interlock, then wait
• Resume trajectory

Scenario 2:

• If Interlock then wait
• Wait for Step
• Resume trajectory

Scenario 3:

• Wait for bStep
• If Interlock, then wait
• Wait for bStep
• Resume trajectory

[yeu-degroot]

About the InterlockFlags of McePosTableIO, should the robot stops on True or False ?

I figured that "True" = "Yes" = "I want interlock". So True should stop the robot. And a default False would allow the robot to move.

But we could also consider "True" = "the robot can move".

Which would be the most natural option ?

Perhaps we could consider the following naming, which might be less confusing than interlock:

• Io data type
  • input: add Array of n conditions
  • Output: add Array of n missingConditions
• PosTable entry data type
  • add Array of n startConditions