Move Trajectory planner from real time to non-real time

none

none

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.

none

none