Low Speed for 3d Printing application

Muz94 wrote: Ouch, any workaround?

If you could get the slicer to output arcs rather than small line segments then that would help a lot.
(I have checked, and it does not look like Cura can do this. As STL is a polygon mesh this makes some sense, there are no arcs in the input data, so they would have to be created by inference)

Using a coarser STL mesh ought to help. Can you try that and see if it does actually help?
I am not suggesting this as a solution, soley to see if our conjectures seem consistent with reality.

andypugh wrote:

Muz94 wrote: Ouch, any workaround?

If you could get the slicer to output arcs rather than small line segments then that would help a lot.
(I have checked, and it does not look like Cura can do this. As STL is a polygon mesh this makes some sense, there are no arcs in the input data, so they would have to be created by inference)

Using a coarser STL mesh ought to help. Can you try that and see if it does actually help?
I am not suggesting this as a solution, soley to see if our conjectures seem consistent with reality.

I can try, but I'm pretty sure that would help, unless cura breaks straight lines into small segments for no reason.
On the control side do you think that I could do something?
I don't think any slicer on the market at the moment could help with this problem

Some work was done, you could try compiling this experimental branch:

github.com/LinuxCNC/linuxcnc/commit/b6ac...e096d87c0322bc5280db

andypugh wrote: Some work was done, you could try compiling this experimental branch:

github.com/LinuxCNC/linuxcnc/commit/b6ac...e096d87c0322bc5280db

This sounds promising, is there any tutorial on how to compile linuxcnc? (especially from a branch).
I have a limited experience with github, but i never compiled a huge public project like this.

Do you think that this would solve the issue? I see that it changes the way the speed is calculated, but it looks like nothing has been touched regarding the interpolation / lookahead ecc.

linuxcnc.org/docs/master/html/code/building-linuxcnc.html

If the motion takes place in XYZ (only) the good tp should be used.
If you can switch U and Z that might just work. Then XY and extruder Z is then used in almost every motion, and occasional move in height which is now U. Just an idea to see if things improve.

Hakan wrote: If the motion takes place in XYZ (only) the good tp should be used.
If you can switch U and Z that might just work. Then XY and extruder Z is then used in almost every motion, and occasional move in height which is now U. Just an idea to see if things improve.

A cunning plan. I started thinking down that line, but gave up too early.

An input filter could easily swap U and Z in the code, then swap the wires in the machine.

andypugh wrote:

Hakan wrote: If the motion takes place in XYZ (only) the good tp should be used.
If you can switch U and Z that might just work. Then XY and extruder Z is then used in almost every motion, and occasional move in height which is now U. Just an idea to see if things improve.

A cunning plan. I started thinking down that line, but gave up too early.

An input filter could easily swap U and Z in the code, then swap the wires in the machine.

Wouldn't this mess up something?
I mean: this way the tp blends the movements in a XYU space, but the movement actually happens in XYZ, the U value isn't an actual coordinate in the 3d space.

I think the tp isn't aware of that. It just looks at speeds, distances and accelerations and tries to find a mathematically good path forward. It is probably best that it uses those values from the involved axis. Maybe it is just to switch the [AXIS_Z] with [AXIS_U] and [JOINT_2] with [JOINT_3] in the ini file. And no need to change hal file or wiring.

Muz94 wrote: Wouldn't this mess up something?
I mean: this way the tp blends the movements in a XYU space, but the movement actually happens in XYZ, the U value isn't an actual coordinate in the 3d space.

The TP is blending in XYZ, but Z is now the extruder. So the blending uses the new tp.

Once per layer there will be an old-blended U-axis (Z coordinate) move of the bed, but it doesn't matter if that is slow.