Missing Features in LCNC for FFF/FDM Printers

Saw this in the mailing list, and thought, why not discuss this in this shiny new forum section instead? That way I dont need to shit up the mailing list by joining it.

What are the missing desired or required features in LCNC for
controlling FFF/FDM printers?

The next question is "What is to be gained by using LCNC?"

What are the missing desired or required features in LCNC for
controlling FFF/FDM printers?

Mostly, probably a centralized/standardized information base that is up to date, and ideally n00b friendly relative to linuxcnc. Machinekit seems like they focused more on 3d printing, so that could be a starting point.

The Extruder-disconnect it from determining motion planning, make it closer to what the spindle is. seems theres an issue with extruder as A axis and the trajectory planner . Im fairly sure klipper is doing a similar method to how velocity extrusion works as far as I understand. The extruder kinematics over on the klipper github, so math and stuff can probably be borrowed from that for fancier 3d printing stuff like pressure advance. So maybe a standardized/template configured in ini and remapped E code (or better yet, implemented at the top level like S codes, S0,S1,)

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

The next question is "What is to be gained by using LCNC?"

When ever I used to look up, "how to (so something cool) with 3d printer?"
The answer was always "you cant do that with (3d printer controller), but linuxcnc can."
Nothing else seems as capable as a linuxcnc/hostmot2 combo.

Nice, thank you.
I did not have time yet, i would like to test setting the spindle stepgen in velocity mode and wire the feedback directly in hal for no lag response then test how the velocity of the machine behaves.
Last time i tried that it did work but it would make motion very jerky.

Of the top of my head, and after many years of 3D printing with LinuxCNC:

1. 3D prints can be hundreds of thousands, even millions of lines of G code. LinuxCNC loads all of this at once. Parsing the G code in chunks would speed up the initial program load but would sacrifice the back plot.
2. True 50 segment look ahead for the extruder (4th) axis. Testing is not conclusive at the moment
3. "Pressure advance", but I'm working on that using external offsets as per my bed compensation component.
4. Use of custom M codes during motion can momentarily cause motion to cease. eg fan control. But changing to M67 here will be the simplest I think.
5. Following errors; an advantage of LinuxCNC is the motion monitoring with following errors being the downside when people don't setup their motion parameters correctly. The 3D printer firmware's don't care so people don't need to understand the motion configuration. 
6. Custom homing routines for multiple Z axes for example. Dual Z and Tripple Z axes are becoming more and more common for "auto leveling"

Advantages of using LinuxCNC for 3D printing:

1. True closed loop motion controller. I can run closed loop steppers.
2. Customisation and configurability using HAL and custom components.... anything can be possible!
3. Having a tool table, yes I measure the length of the extruder. The first layer is the most challenging in 3D printing.
4. Having the ability to use subroutines

LinuxCNC for 3D printing is not for the Noob just yet. HAL configuration is most peoples stumbling block. Now if someone developed a node based graphical HAL editor... this would really help as people can visualise the logic.

Stepper Drivers.
Mesa Drivers are way too expensive for a 3dprinter.
And using parport pins as step / dir is far too limiting.

Outgoing communication might go through parport, ethernet or USB, iI don't think this makes much of a difference.
Ethernet would be nice for deterministic communication and such, but a 3dprinter does not stress USB enough, to require such hardware.
Parport is fine, there are still new computer with it, but the temptation of a simple embedded platform is strong (I mean, raspberry). And those device will not have a parport.

Options that I can see:
- making a firmware that pretends to be a mesa driver, and make it run on some uC.
- try to reuse klipper firmware, but I have no idea of what this means from LCNC perspective.

---

Then, I report a configuration for machinekit with pressure advance
github.com/thecooltool/UNI-PRINT-3D
It makes use of this cura plugin, that creates gcode that requires given pressure, and do not try to calculate extruder movement (no need to reverse calculate the pressure on the printer)
groups.google.com/g/machinekit/c/NiW2eVeEpUE/m/FPa0_4azEAAJ
This is all kinda old, and I have not tried if this even still work.

I really like the idea of using the greater computational power to do things on the controller instead of in the slicer. But this is clearly not the direction in which the world is moving.

mngr0 wrote:

...... but a 3dprinter does not stress USB enough, to require such hardware.

Try telling that to someone who watched his hot end drag over an expensive build plate while he was frantically clicking on the "move Z up" button repeatedly!
USB does not have a "throughput" problem, it has a "latency" problem, and that is a big no no for machines.