Low Speed for 3d Printing application

I am starting to wonder if an alternative interpreter would be part of the solution. That could accept the printer M-codes and use E for extruder like they seem to.

But that wouldn't actually solve the path blending or preview problems.

I am slightly surprised that XYU doesn't help. I think that the preview is generated by this file:
github.com/LinuxCNC/linuxcnc/blob/master...hon/rs274/glcanon.py

Sorry, I meant the file where the blending takes place.

Well, i gave a look to the TP source to see in it was possible to just swap the two axes in some way, but it turns out that all the blending mechanism has been implemented with the restriction to the XYZ coordinates in mind, so i wouldn't even know where to start to touch something (especially because i really don't know at all the theroy behind spherical arc interpolation).

I guess that i'll have to just swap the axes in the code, and maybe put my hands in the gui to try to hide it. (I at least have to fix the preview, but i really don't like the idea of working with swapped controls, origin table etc).

Any news about that experimental branch with arc interpolation on uvw?

Can you make a custom panel with jog buttons reassigned?

Yes, probably. But doing only that makes it even worse as the jog buttons would be swapped but other elements (dro, preset table etc) wouldn't.
If i swap Z and U i have to stick with that and consider my vertical axis as U to have the GUI and the program coherent, i would only need to fix (or remove, sadly) the preview.

I think that making page-up / page-down jog U raher than X is possibly as easy as changing a line in axis.py

github.com/LinuxCNC/linuxcnc/blob/master...cripts/axis.py#L3652

And you can probably do this in a way that won't break on update, too, with a .axisrc file:

forum.linuxcnc.org/21-axis/29735-axis-modifications

Just got an idea.
X Y Z --> U V W.
To fix the preview i have to use W instead of U. if i set geometry to XYW the W axis actually moves along Z, so at least that is fixed.
I'll have to follow that route for now, as after spending another day studying the TP code still dind't bring any result.

Just an info: do you know if someone is actually going to introduce arc blending on all 9 axes in the near future?
If you have any news about that let me know.

For now thank you for your great help

Hi Andy, Is this the current solution to using LinuxCNC on 3D printers so that the TP doesn't revert to a 1 line look-ahead and the extruder axis becomes part of the TP arc blending algorithm? Or has something changed regarding this sine 2019?

I don't know if anything has changed, but I suspect not. (So much changed between 2.7 and 2.8 that I am not aware of all of it)

There is an interpreter out there that blends in all 9 axes, but I think that only PathPilot has it at the moment. (Possibly Machinekit too)

I haven't got as far as trying to find the patches to see if they merge with LinuxCNC at all.

Ok, thx. I've been testing LinuxCNC/Remora on my ender3 configured XYZA and have been having a tough time with following errors and jerky motion on the A axis/extruder. Scott A found this thread this morning and it seems to explain things.