Move Trajectory planner from real time to non-real time

More
21 Jul 2022 06:41 - 23 Feb 2023 15:45 #247912 by troy

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!
Last edit: 23 Feb 2023 15:45 by troy.
The following user(s) said Thank You: silopolis

Please Log in or Create an account to join the conversation.

More
21 Jul 2022 06:47 - 23 Feb 2023 15:46 #247913 by troy

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

 

Last edit: 23 Feb 2023 15:46 by troy.

Please Log in or Create an account to join the conversation.

More
25 Jul 2022 10:54 #248240 by rmu
eoffsets = external offsets I think, something like torch height compensation calculated from actual measured arc voltage in real time.
The following user(s) said Thank You: tommylight

Please Log in or Create an account to join the conversation.

More
26 Jul 2022 15:30 #248339 by rellenberg
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.
The following user(s) said Thank You: Bari, arvidb, rmu, troy

Please Log in or Create an account to join the conversation.

More
26 Jul 2022 15:59 #248342 by arvidb
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?
The following user(s) said Thank You: troy

Please Log in or Create an account to join the conversation.

More
26 Jul 2022 17:30 #248354 by rellenberg
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.
The following user(s) said Thank You: arvidb

Please Log in or Create an account to join the conversation.

More
26 Jul 2022 19:00 #248359 by Todd Zuercher
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.
The following user(s) said Thank You: Bari, arvidb

Please Log in or Create an account to join the conversation.

More
03 Feb 2023 16:51 #263611 by troy

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.
The following user(s) said Thank You: Bari

Please Log in or Create an account to join the conversation.

More
03 Feb 2023 19:53 #263616 by andypugh
This sounds very interesting, I do hope that you can find a way to make it possible to merge into mainline LinuxCNC.
The following user(s) said Thank You: troy

Please Log in or Create an account to join the conversation.

More
06 Feb 2023 05:57 - 23 Feb 2023 15:47 #263794 by troy

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.
Last edit: 23 Feb 2023 15:47 by troy.

Please Log in or Create an account to join the conversation.

Time to create page: 0.137 seconds
Powered by Kunena Forum