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.

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.

I have heard similar stories many times in this forum, but I would like to give a deeper motivation on my defense of USB.

USB is a master-slave protocol, in which the host polls the devices. So no collisions nor congestions are possible.
The latency problem comes because you can never know how much time passes between the event and the communication with the host. Polling period is between 1 ms and 10 ms, which is clearly not human-visible (even though it can still do damages).
Dragging the tool despite repeated user action means that there is a problem in some buffer, that maybe does not consider event priorities (not a USB problem).

WHEN can latency be a problem? Well, only when a device has to say something to the host.
Maybe it needs to update the current position, maybe because a switch has been clicked.
3Dprinters usually have no position feedback, and the switches are for homing only (or slow events, like a filament sensor). While the motion planner is  working, it can take its feedback by itself, since it knows the commanded speed, and the previous position.

I 100% agree that a machine with many stepper drivers will NEVER be able to run on USB, there are plenty of low-latency multiple-devices protocols(EtherCAT, CANBUS, or the recent Time Sensitive Ethernet, just to name a few ), but... we are talking about a 3Dprinter... which will have at most a couple of devices on the bus, and no significant information that needs to travel from device to host.

There are lots of great usb solutions for 3d printers. I don't see LCNC joining the list. Never say never, I guess.

As far as the expense of mesa boards, you might want to look at Remora
forum.linuxcnc.org/18-computer/42276-rem...ller-via-spi?start=0

There pretty much no point in using lcnc when duet and klipper exist.