Trajectory Planner for 3D printing - A axis blending issues

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

 

There is a working printer i linked to using axis U (or A ) for Z, and Z axis for driving the extrude.
On FDM printers Z axis moves only on layer shift so not blending or anything required as all other motion is stopped while the Z is moving.

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.

@Todd
I run current master on everything and I'd really like to get to the bottom of this once and for all.
I know this may sound somewhat strange but how would I test this? Would I just use UVW instead of XYZ? Maybe I could use XYZUVW instead of XYZABC for my robot.

[edit]
or I guess the most logical would be to start with redefining the a-axis on my mill as u-axis.