Low Speed for 3d Printing application

What I meant is: the blending creates a path that differs from the gcode (within a tolerance) right?
But if we blend points in a XYU space, when the u movement isn't actually happening, wouldn't this create artifacts or other issues in the printed part?

Good idea. I will totally try that.

Today i printed a model with a very low polygon count (a low poly pikachu), and it took about 5 - 6 hours, while cura considered that a 4.30 hour print. That's much closer than usual, so it's a matter of segments number.

One way to avoid the entire TP issue is to use velocity based extrusion.
For optimal operation, this probably requires delaying the motion in hal
before its feed to the joints so the extruder response over time can be
modelled and compensated

I believe that Machine kit has implemented a delay component that could
be used for delaying motion. If simple lookahead is not good enough, a
FIR filter could be used to process the velocity signal. All of this is pretty
slow so a servo thread loop time resolution should be fine.

PCW wrote:

One way to avoid the entire TP issue is to use velocity based extrusion.
For optimal operation, this probably requires delaying the motion in hal
before its feed to the joints so the extruder response over time can be
modelled and compensated

I believe that Machine kit has implemented a delay component that could
be used for delaying motion. If simple lookahead is not good enough, a
FIR filter could be used to process the velocity signal. All of this is pretty
slow so a servo thread loop time resolution should be fine.

How would this work? Do you need to make changes in the gcode to have velocity data or it can be done with the information already present in a normal slicer gcode?
Do you have any advice on where to start?

I used to think that, but i actually saw a few videos of people comparing real printing times with the estimated ones and with the latest version of cura they are pretty close.

While looking around for an idea i came across to this configuration :
github.com/dabit20/rpi_cnc

and guess what? he runs the machine with swapped A - Z axes.
I'll try to ask him if he did that to fix this exact problem

Muz94 wrote:

PCW wrote:

One way to avoid the entire TP issue is to use velocity based extrusion.
For optimal operation, this probably requires delaying the motion in hal
before its feed to the joints so the extruder response over time can be
modelled and compensated

I believe that Machine kit has implemented a delay component that could
be used for delaying motion. If simple lookahead is not good enough, a
FIR filter could be used to process the velocity signal. All of this is pretty
slow so a servo thread loop time resolution should be fine.

How would this work? Do you need to make changes in the gcode to have velocity data or it can be done with the information already present in a normal slicer gcode?
Do you have any advice on where to start?

In the very simplest case you would take motion.current-vel, scale it and feed it to the extruder stepgen velocity

Next would be to delay all motion joints with a delay component and feed the non-delayed velocity to the stepgen

Fancier would be to feed the non-delayed velocity to a filter that compensates for the time domain response
of the extruder