Missing Features in LCNC for FFF/FDM Printers
- cakeslob
- Offline
- Platinum Member
- Posts: 789
- Thank you received: 230
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?"
Please Log in or Create an account to join the conversation.
- cakeslob
- Offline
- Platinum Member
- Posts: 789
- Thank you received: 230
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
When ever I used to look up, "how to (so something cool) with 3d printer?"The next question is "What is to be gained by using LCNC?"
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.
Please Log in or Create an account to join the conversation.
- tommylight
- Offline
- Moderator
- Posts: 19409
- Thank you received: 6507
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.
Please Log in or Create an account to join the conversation.
- scotta
- Offline
- Platinum Member
- Posts: 886
- Thank you received: 463
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.
Please Log in or Create an account to join the conversation.
- mngr0
- Offline
- Junior Member
- Posts: 26
- Thank you received: 1
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.
Please Log in or Create an account to join the conversation.
- tommylight
- Offline
- Moderator
- Posts: 19409
- Thank you received: 6507
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!...... but a 3dprinter does not stress USB enough, to require such hardware.
USB does not have a "throughput" problem, it has a "latency" problem, and that is a big no no for machines.
Please Log in or Create an account to join the conversation.
- mngr0
- Offline
- Junior Member
- Posts: 26
- Thank you received: 1
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.
Please Log in or Create an account to join the conversation.
- EricKeller
- Offline
- Junior Member
- Posts: 27
- Thank you received: 3
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
Please Log in or Create an account to join the conversation.
- Roiki
- Offline
- Premium Member
- Posts: 116
- Thank you received: 19
Please Log in or Create an account to join the conversation.
- tommylight
- Offline
- Moderator
- Posts: 19409
- Thank you received: 6507
Pretty sure that could be done in LinuxCNC during printing.
Please Log in or Create an account to join the conversation.