Move Trajectory planner from real time to non-real time

arvidb wrote:

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?
 

Hi arvidb
yes,it is acceptable 

Todd wrote:

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.

Hi todd,
yes, in blendmath of linuxcnc, they follow a principle that the radius of the corner should be as small as possible. 

"In other words the TP does not account for a machine's velocity limitations in it's blend calculations."
I think TP done velocity/acceleration limitations in blend(parabolic) , using only half of the max vel/acc of each tc.  

andypugh wrote:

This sounds very interesting, I do hope that you can find a way to make it possible to merge into mainline LinuxCNC.
 

Hi andy,
There is some issue with youtube, so your comment  of this test video clip disappeared. 
yes, I do the blend between linear axis and rotary axis, otherwise, it will stop or decelerate frequently. 

This looks very promising!!  subscribed!

Lcvette wrote:

This looks very promising!!  subscribed!

I have verified that the solution is feasible.

This can be a development direction of linuxcnc in the future, I am very willing to participate in it, If the development thread starts.

it would seem the best way for that to happen would be to have a jumping off point.  it appears you have created that point with your work as seen by the results, it would likely be easiest to put it out for broader testing and contribution and once it seems to have been proven in a broader environment and any kinks ironed out, set it up as a pull request to Linuxcnc. I am certain that many of the people who use linuxcnc in a production environment would be thrilled to see a way to remove the jerk situation from their machines.  I for one can 100% say I would.  

Chris

and i am very keen also for any new trajectory control stuff!

i run big linuxcnc machines all day and currently they run a lot more roughly than with the original heidenhain controls and shake the machine way more

i would also love to do some testing for you if that would get this forward. my coding skills are currently only basic but i do a lot of linuxcnc retrofits in new zealand



regards

Andrew

Hi there,
Is any news on this topic or some kind of github code to try it?

Best