Trajectory Planner for 3D printing - A axis blending issues

It will be very useful if we will able to merge their TP.

In our case, as we print with the spiralize option, the trick of exchange the "A" axis with the "Z" axis will be useless as both of them are in every gcode lines.

Here I found a branch more updated from the Tormach engineer, but unfortunately I am still unable to try it.

github.com/robEllenberg/linuxcnc-mirror/...ure/uvw-blending-2.7

It seems that there are differences in the tp and in the motion path. I will continue to investigate.

While I wont argue a new fancy trajectory planner would be sweet, it seems like overkill for something thats more like a synchronized toolhead, than an axis of motion. I dont think marlin or klipper have a 4 axis planner, probably a 3+1 but Im not to good with computers so I dont know for sure. Klipper seems closest in concept to linuxcnc so ill use that for reference. It looks like the extruder has a separate kniematics config, and the action is happening in toolhead.py I am trying to determine if this is similar to what PCW is saying with velocity extrusion and filters

github.com/KevinOConnor/klipper/blob/master/klippy/toolhead.py
github.com/KevinOConnor/klipper/blob/mas...nematics/extruder.py

 

In our case, as we use a pellet extrusion with a large bead, we usually set the spiralize option in the slicing software: it means that X Y Z are moving together. For this reason, switching the Z and A axis will be useless.
The same for some fancy 45-degree prints.

The velocity extrusion with some filters works very well. The cons are that it requires coding to post-process the gcode outputted from slicing softwares. As different slicers are writing the gcode in different manners, I don't think is the right way because you will be slicer-dependent. 
Moreover to get the proper amount of extrusion it requires parameters as layer height and Nozzle diameter that are previously set in the slicer software. This software doesn't talk with linuxcnc and it generates human errors when the operator loads a gcode from time before and doesn't remember the slicing parameters. In synthesis, in my opinion, the velocity extrusion is a good workaround but it's not a final solution.

Could be possible to load two trajectory planners one for XYZ and one for the A axis?
The real problem in 3D printing with the actual Trajectory Planner is that is it optimized in the opposite way against necessity.
The aim should be to keep the extrusion more constant as possible acting as a constraint to the XYZ motion. If the objectives of the optimization strategy of the TP could be chosen, it will be amazing!
 

Did you try it using U, V, or W instead of A? (I think the new planner's look ahead might be extended to those axis in v2.8+, just not A,B,C.)

I know I helped with testing the experimental UVW branch and it was working there. But I never tested 2.8-pre after that branch was supposedly merged, to see if it worked there. And I have not taken the time to upgrade my machines beyond 2.7, because the work-arounds I'd already implemented there work well and my complex configs don't import easily into 2.8 without a lot of manual changes. Not to mention nessisary OS upgrades, have kind of dead ended me, until I put in a lot of time testing and experimenting. (These are factory production machines.) So the time required and time available has made the incentive for upgrading low for me. (if it ain't broke...)

AlessandroT wrote:

The velocity extrusion with some filters works very well. The cons are that it requires coding to post-process the gcode outputted from slicing softwares. As different slicers are writing the gcode in different manners, I don't think is the right way because you will be slicer-dependent. 
Moreover to get the proper amount of extrusion it requires parameters as layer height and Nozzle diameter that are previously set in the slicer software. This software doesn't talk with linuxcnc and it generates human errors when the operator loads a gcode from time before and doesn't remember the slicing parameters. In synthesis, in my opinion, the velocity extrusion is a good workaround but it's not a final solution.

 

You might be able to work around the need for a custom post processor, by building the nessisary post processing into a filter in Linuxcnc that automatically makes the nessisary changes to the files as they are loaded.  I do this on several machines to convert g-code that was made for a different machine compatible with another.

I thought I tested this and figured out it was not the case that the A axis dropped the TP to a 1 word buffer here(videos showing 1 word and 50 word buffers): forum.linuxcnc.org/38-general-linuxcnc-q...3-3d-printing#210835

Maybe arc_blend is quite different from what you are saying and seeing?

Hi Doggie,

I saw your video and checked your gcode. In your case ( in the second video) the arc_blend option is working because you didn't have the A axis coordinate inside the gcode. If you execute the same gcode with A axis, I suppose that your second video will be identical to the first one.

@Todd, thanks, I can understand the feeling and the scares to upgrade when the stuff are going well. Honestly, I didn't test to swap A axis with U, I only read that it didn't work in some posts. I will do my homework soon. I have some little hope because we are testing the linuxcnc 2.9, and maybe the U swapped tester was using the 2.7!

About the post process inside linuxcnc, I never used this workaround and I will investigate it, but as we are loading very large files and it takes a long time already to be charged, I suppose that this will require even more time.