Move Trajectory planner from real time to non-real time

cmorley wrote:

How will you handle such things as override and spindle sync?
 

Hi cmorley,Thank you for your question.
I'll draw a block diagram later， hope you can give more suggestions！

skunkworks wrote:

and eoffsets..
Hi skunkworks, you mean tool offsets?

 

eoffsets = external offsets I think, something like torch height compensation calculated from actual measured arc voltage in real time.

Trajectory planning specifically (kinematics, blending, path smoothing) doesn't have to be in realtime, but there are a few reasons it was done that way:

1. Blending used to be done at runtime (before we added lookahead), so there wasn't really a need for complex lookahead / optimization. Trajectory "planning" was mostly just creating the motion structures (line, circle, tapping) and adding them to the queue.
2. Motion commands other than lines / arcs can affect future motions (blend mode, spindle sync), so they have to be executed in order. Many motion commands directly act on (realtime) motion state, so it made sense to handle incoming commands in the realtime side.
3. When we did add lookahead, it was easier to graft it on to the existing realtime TP (especially for me as a relative novice to LinuxCNC architecture).

I agree that it would definitely be better to have more planning in userspace (more consistent / faster servo updates, easier to do more complex planning). I've been thinking about how to do this in manageable steps

1. Treat "immediate" motion commands (pause, resume, config changes, etc.) the same as today (command handler in command.c)
2. For actual moves and move-related commands (blending, spindle-sync), create a queue for optimization / lookahead in the user half of the user-motion interface.
3. Add a motion command that pops an optimized move out of the user-space queue and sends it (fully-formed) to the motion command handler.
4. Move geometry processing out of realtime TP (tpAddLine, tpAddCircle, path blending) to this new layer.
5. (optional) move geometry processing out of emccanon if possible (circle / line math, naive CAM detection, etc.)

With a simple queue, some lookahead still has to be done in realtime with this arrangement (the TP has to be able to stop at the end of the last queued motion in case userspace stalls). A more sophisticated queue that allows shared access for both motion and userspace would make it possible to  move all of the lookahead calculations out of realtime.

Would it be acceptable to pre-calculate an exact path based on maximum feed override (and other settings), and then follow this at whatever feed is set at the moment? Rather than doing real time blending/lookahead.

To me having the freedom to override feed without changing the shape of the finished part might even be preferable to always having the tightest possible corners etc. This might also allow exact calculation of remaining machining time (though this is complicated by the fact that different parts of the path will have different maximum velocities, so it's not just a simple scaling).

One issue that would need to be handled is large files - the pre-calculation of the path would have to be done in a background thread. (But this must already be the case for the preview in e.g. Axis?)

Anyway, I'm mostly wondering what you guys think about this, is there some obvious dealbreaker with doing things this way?

That's more or less the approach the TP currently uses. Lookahead runs whenever a new G-code line is processed, and creates blends to fit the maximum velocity reachable with feed override. Lookahead establishes the limits, and the TP can run arbitrarily slower depending on feed override settings. You'd probably want a similar pattern when moving to userspace: do the hard work of finding the blend sizes and vel / accel limits in userspace, and the trajectory execution (that stays within those limits) in realtime.

A funny TP blending quirk I've noticed. If for example you have a machine config with a max feed rate of F200 and you load a g-code file with a programmed feed rate of F1000 the TP will calculate the blends for the F1000 feed rate even though the actual milling will only be at F200 because of the machine's config limit. Changing the g-code's programmed feed to the machine's F200 will result in much smaller blend radii (assuming no path tolerance) than the original F1000 even though the actual feed rates performed would be the same. In other words the TP does not account for a machine's velocity limitations in it's blend calculations.

troy wrote:

hi guys，
I wonder if it is possible for us to move the trajectory planner from real time to non real time.
1.TP is  a time-consuming part,It should not be too complex, otherwise it will affect the stability of real-time cycle；
2.we can not perform complex path smoothing algorithm,such as B-spline Compression smoothing (siemens fanuc),with current structure;

If we move TP to non real time module, we can do more complex smoothing calculation.

Has anyone tried this before?

Hi, guys
I've done my job !

After over 7 months design \ development \ debugging, it works well.
The trajectory planner module has been moved to non-realtime side, after the emctaskplan module.

I can finally do a mass of calculations in the trajectory planner without affecting the real-time performance of interpolation.

Here is a 5-axis  RTCP milling test vedio, the real-time interpolation cycle is 1ms,  the actual measured time period is about 600-800us.
multi-axis milling test - YouTube


Note: this project is cooperate with a company,  all the source code are in a server that can't access to the internet, so i can't push it to github.
I will post more details later.

rellenberg wrote:

Trajectory planning specifically (kinematics, blending, path smoothing) doesn't have to be in realtime, but there are a few reasons it was done that way:

1. Blending used to be done at runtime (before we added lookahead), so there wasn't really a need for complex lookahead / optimization. Trajectory "planning" was mostly just creating the motion structures (line, circle, tapping) and adding them to the queue.
2. Motion commands other than lines / arcs can affect future motions (blend mode, spindle sync), so they have to be executed in order. Many motion commands directly act on (realtime) motion state, so it made sense to handle incoming commands in the realtime side.
3. When we did add lookahead, it was easier to graft it on to the existing realtime TP (especially for me as a relative novice to LinuxCNC architecture).
   
   I agree that it would definitely be better to have more planning in userspace (more consistent / faster servo updates, easier to do more complex planning). I've been thinking about how to do this in manageable steps
   1. Treat "immediate" motion commands (pause, resume, config changes, etc.) the same as today (command handler in command.c)
   2. For actual moves and move-related commands (blending, spindle-sync), create a queue for optimization / lookahead in the user half of the user-motion interface.
   3. Add a motion command that pops an optimized move out of the user-space queue and sends it (fully-formed) to the motion command handler.
   4. Move geometry processing out of realtime TP (tpAddLine, tpAddCircle, path blending) to this new layer.
   5. (optional) move geometry processing out of emccanon if possible (circle / line math, naive CAM detection, etc.)
      
      With a simple queue, some lookahead still has to be done in realtime with this arrangement (the TP has to be able to stop at the end of the last queued motion in case userspace stalls). A more sophisticated queue that allows shared access for both motion and userspace would make it possible to  move all of the lookahead calculations out of realtime.

Hi Robert,
you are so right,  the steps you mentioned are almost the key point of the implementation.