[FR] Automatic Extrusion

Features
1

Few years i was working with Machinekit and did use their feature called “Velocity extrusion” - basically it’s a combination of “Presure Advance” + Automatic extrusion and i really like it because you can fully control extrusion without any calculations.
This feature allow me to do following fun advanced stuff:

  • Manually, in real time, draw with plastic just by specifying coordinates.
  • Create dynamic G-Code by using subroutines directly inside of machine.
  • Control amount of retraction/stringing during build process.
  • Easily do some test scenario without Slicer.
  • Work in 4 coordinates, xyz-cartesian + 1 rotational.
  • Get some performance boost because G0 move with Zhop can have greater corner velocity than G1
  • Utilize “Canned Cycle”, “Threading Cycle”
  • Work in different planes
  • Get fully portable G-Code independend from extruder

Automatic extrusion was working following way:
There was a clear separation of G0 and G1 codes
G0 was used just for movement, G1 was used only for extrusion moves,
but each G1 command didn’t have any E-steps (it contain only xyz or more axis coordinates), amount of plastic was calculated automatically base on previously defined output cross section which can be changed by G-Code.
For example if you wish to get 0.5mm wide extrusion on 0.3 Z height you would specify it directly 0.5*0.3=0.15 or set it via heigh and width separetly.
When system did extrusion move with G1 it was calculating E-steps automaticaly for required distance. There was a posibillity to add automatic retract/un-retract on each switch from extrusion to movent modes.

There is some plugins for Cura to to post-process usual g-code to this kind of code and i also build post-script for Fusion360, but it’s usual slices in 2D.

I already build this functionaliity in Klipper but it’s not cleanly isolated in separate module. So here i’m trying to collect some feedback how much people want this feature, if community have interest in this feature - i will refactor it and propose to push it to Klipper.

Thanks.

2

Sounds interesting.
You can still calibrate esteps and flow so that the system knows how much filament it can extrude under specific circumstances or not?

3

My current implementation takes everything from active Extruder.
Extruder already have everything what is required, you just need to activate function and specify output cross-section.

1 Like
4

Could you please post some “specific” links from Machinekit regarding the topic?

1 Like
5

They don’t exist, only some mentioning of it here: https://www.machinekit.io/docs/fdm/fdm-gcode/
M700, M701, M702, M710 codes

and here: https://www.machinekit.io/docs/fdm/fdm-ini/
VELOCITY_EXTRUSION_ENABLE

Short description of this feature you can find here:

Machinekit have just simple implementation, last link is presenting same function but with additional “presure advance” - which Klipper already have.

1 Like
6

Personally, I went with Klipper due to its strong focus on FDM printing quality and speed. Naturally I can see the benefits of Pressure Advance or Input Shaping etc.

Can you elaborate, what would be the “real world benefits” of this in the regular FDM workflow?

7

My current intention is to bring people closer to their machine and it’s possibilities, play with it, tweak it, invent new approaches, etc …
But currently everybody are locked behind a slicers and can’t play with their 3d printers. Why ? - just try to build manually some simple object without a slicer, immediately you will understand how hard is to do something in 4 dimensions (4-th is Extruder). Now try to add additional (4-th) axis to get 4D printing - without this feature you are doomed to wait another 20 years for slicers to implement it.

8

I just ask myself, why this principle did not establish and got forgotten over the years.

9

I know why, it was grbl (Marlin) and cheap microcontrollers, they just can’t do it with their small processing power, everything was pushed to slicers, and we stuck there from begining. Just think How long we did ask for G2 arc support in Marlin, then in slicers.

10

I’m not following you here and especially not on this arc argument.

In my opinion, arcs is one of the least understood, least needed and most overrated function ever.

Lets start with the obvious:

Most printer kinematics cannot follow a true arc since they work with discrete X and Y movements.
There are very few (one? → SCARA) kinematics that could even do a true rotation and, as far as I’m aware, they are today not smart enough to take advantage of.

Worst case workflow

The following workflow was true for a very long time (and essentially is still today):

  1. Design something in CAD (Side note: Most are not even aware that there are Class A Surfaces and that designing and manufacturing such is an art of its own)
  2. Export as STL → 1st approximation with the precision (chord height) of the respective design tool → 1st lossy operation
  3. Load in slicer → Approximated “chords” are approximated into arcs → 2nd lossy operation
  4. Print design → Arcs are again approximated into discrete X and Y movements → 3rd lossy operation

Now you probably argue, that modern slicers can load STEP / native CAD files directly.
I’m not aware what the slicer’s are actually doing under the hood: Do they really derive the arc from the CAD data or are they just following their regular faceting approach and then “arcify” it.
But fine, you might save one approximation. It does not make it much better.

Given 3D printing’s heritage to CNC, the process in both worlds are very much the same, even with today’s highly complex multi-axis CNCs. The only difference really is that the tool is not called slicer but CAM.

I believe that arcs have only been invented in CNC because it is a major pain in the back to code an arc manually out of normal Gcodes. For a long time and even today, manually programming a CNC is quite common.

The future

If it makes sense to break the concept of slicer and printer firmware, I do not know. Essentially, you would only move the slicer’s intelligence into the printer’s firmware, but you would still need some ways to control the process as the printer can hardly guess what you want.

Maybe there will be AI support. You only throw the model at it and it will automagically turn it into the best possible printed object.

Maybe there will be non-planar printing, which surely would be a big step forward. This concept would also have to be supported by appropriate software and hardware. Both would be a magnitude more complex compared to what we know today.

2 Likes
11

My complains about arc support was just an example how hard is to get something new from firmware and from slicers, it’s a nightmare. But just think - Arc support was there in CNC stack long before we took it, then we throw away bunch of things (including arc support) and use it for 3D printing - I know the reason why it was done this way, and it did have some positive effects, but now look at klipper - it exists because of those reasons (cheap and weak controllers just can’t do it).

  • Now lets look at slicers, they spend last 5 years mostly on “Advanced machine control” like extruder control, retraction, oozing, acceleration control, jerk control, coasting, bridge settings - that everything is there because of same reason (cheap and weak controllers just can’t do it)

  • Now look at 3D printers, it’s bean more than 20 years and still I can’t reliably tell those machines to
    go and put 1cm of plastic in that place then turn 160 degree and place another 1cm of plastic
    and they will do it properly regardless which speed I selected 5mm/s or 500mm/s and which characteristics that plastic have.

  • Now just imagine (15 year old or 40 year old) newbie who finally got access to 3D printer, and have an great idea to do something new and innovative. Now he is sitting in front of it and can’t do what he want because Slicers did not implement it and they are overcomplicated, G-Code become nightmare and 3D printer is not doing what is supposed to do.

So my points are following

  • Slicers should just slice and contain everything what is required for slicing
  • 3D printers should just Print and contain everything what is required for that
  • Firmware should make 3D printer to do exactly what was requested
  • Humans should be able to interact on any level without spending more that a day to get the knowledge, tools. And it should not be nightmare.
12

I would consider myself an advanced user but honestly, I never had the urge to tell my printer to place 1cm of plastic anywhere nor the urge to understand in the last detail why a slicer is doing this or that in this or that situation.

Proper 3D printing is quite complex and from the support activities here I know that most users even struggle with the most basic topics of their machines.

Digging into topics like:

  • Overhangs vs. printing speed
  • Internal bridging vs. infill
  • Support layers vs. infill
  • Length of segmentation
  • Line width vs. overlap
  • etc, etc

is honestly something I do not care about and where I expect the slicer to carefully and correctly decide the best strategy and there are just enough occasions where it does not.

Then there are countless topics where you as a human need to decide, which is the best strategy, given the geometry and intended use case:

  • Printing direction vs. intended load path in the final application
  • Overhangs vs. cooling vs. wall ordering vs. cosmetic appearance
  • Infill geometry and density vs. printing time vs. stress requirements
  • Number of walls / bottom layers / top lay vs. stress requirements
  • Choice of filament material and derived printer settings (in an ideal world the slicer should know this, but there are just too many different filaments where even a different color can make a noticeable difference)
  • etc, etc

While your statements are essentially correct, I think you are over-simplifying it a lot and the entire environment is far far away from this simplified view.

Also Klipper is at least following your “Firmware should make 3D printer to do exactly what was requested” requirement: Klipper is strictly following the instructions given in the gcode. There is no hidden optimization or second guessing and also Klipper’s design philosophy is targeted at avoiding potential ambiguity.

13

Yea, probably you are very advance User, but you didn’t work in R&D area and don’t know how hard is to do some simple stuff on bottom layer. This feature is just a small helping hand for R&D and troubleshooting.
Just as an example - one person did build solution to embed a coper wire to extrusion in controlled manner, and he did that because of this feature existed, it’s bean 9 years ago !

14

I’m not really sure where this statement comes from - in my experience, it’s generally quite easy to “do some simple stuff on bottom layer” but integrating new technology into an existing system is where the real work comes in.

You seem to take a very simplistic view of 3D printing and how it has evolved to this point - you apparently blame the resulting architecture/workflow on “cheap and weak controllers” but there are a lot more factors that have been involved.

IFF you are as well versed in R&D as you seem to think you are, you’d recognize that Fused Deposition Modeling Additive Manufacturing, “3D printing”, being discussed here could be optimistically rated at a Technology Readiness Level of 5 or 6:

image
image963×881 155 KB

This is actually a positive as the slicers and firmware that you bemoan are all open source and it is relatively easy to add features to them or to take the technology built into them and create something new that matches your vision. Similarly, the line between microcontrollers and systems on chip have evolved to the point where you could integrate a slicer into a 3D printer simplifying the workflow and adding whatever features you think would make for better quality printing.

If you don’t have the skills to do this yourself, then you must be able to make the case to people (as well as companies) to do the work and I don’t think you’ve articulated the advantages well enough here for people to see what would be gained by automatic/velocity extrusion.

When I read over this thread, on one hand you seem to be advocating to make 3D printing easier for Joe Public by giving them complete and dynamic control over their machines but to do that, it seems to me, they must have a very deep and detailed understanding of the materials and processes involved.

I get that this is a feature that you want but I don’t see this as being something that everyone, or even just advanced users, would want.

15

You are right. I’m definitively coming from the user perspective and I’m rather interested in real world results for the everyday use.

Of course, I do appreciate R&D work even without practical context as it often leads to great innovations with a practical use.

You might be interested in GitHub - FullControlXYZ/fullcontrol: Python version of FullControl for toolpath design (and more) - the readme below is best source of information
I did play around with it a bit to create dynamic test patterns and it is really powerful.

1 Like
16

TRL depend from point of view.
if you look at “FDM” or “3D printing” in general - it’s already at level 9
If you look at “FDM” or “3D Printing” from RepRap project point of view - it’s still on level 3

I came here with implemented feature, asked community if they want it or not.

  • if answer will be Yes - then I will spend my time to separate it as a module and will provide push request to Klipper and expect that maintainers should help me to fulfill all requirements and accept it.

  • if answer will be No - then fine, I will not bother anybody and will keep it for myself.

17

Well, this is up to Kevin as project maintainer.
From my perspective, I still have a hard time to understand of what your changes actually consists of.

For sure there is an interest to extend the CNC capabilities of Klipper and some of your initial points seem to point into such direction.

Changes that only have “R&D character” will likely be turned down due to concerns of code complexity, code maintenance burden and user facing complexity.
Then again, it might depend on how they are implemented, e.g. self-contained code.

Maybe you can elaborate more specifically, but OTOH I might simply lack the understanding.

18

Huh interesting…
That project which you did share “fullcontrol” is using same feature :smile: !
they totally get rid of E steps, they just enable or disable extrusion in different places to differentiate extrusion moves from usual moves, only as last step they define output height and width (a cross section) and library will generate G-code with E-steps. You can see that clearly in first 2 minutes of their “Quick start tutorial” video.

This feature is the same as in “fullcontrol”, when you enable it G0 and G1 will ignore any provided E-steps, G1 will automatically calculate extrusion length based on distance and requested cross-section and use it. Additionally there is few lines in SAVE and RESTORE G-code state and few lines in Firmware_retraction.
And of course you can enable/disable it in runtime.

If somebody want it in current crude state - it’s here: Implemented Velocity extrusion · Ga-Ol-St/klipper@5c93d97 · GitHub

19

It’s interesting that the same kind of control can be devised on two separate systems under two different names yet work the same exact same way.

I helped develop and implement a control method that does exactly what you’re talking about on a Siemens 840D CNC control. The machine has a pellet extruder on it and we measured the volumetric output for one rotation of the screw and then use that in our formula to calculate the desired cross-sectional area of the bead. The control method takes into account current path velocity to ensure that the calculated cross-sectional area of the bead always remains constant even during acceleration and deceleration.

The difference in bead quality is night and day between using the control method and not using it. When it is enabled the bead is extremely consistent along the entire path. Unlike when the control is off and the bead consistency varies due to acceleration and deceleration. Now that being said the smallest beads printed on this machine are usually 12mm wide the larger beads are 20mm wide. The difference would not be noticeable on a small printer that has a very small moment of inertia, thus eliminating the only major benefit of this type of control.

The biggest drawback of this control method is that it eliminates the ability to use a lot of the modern functionality in slicers. There is a constant battle between getting the results you want/expect and overriding the automatic extrusion. We also figured out that the output of the extruder is not even close to linear when compared to velocity. This means that you can’t just use a simple equation based on the volumetric output in direct correlation to the desired bead cross-sectional area.

I can’t really say much more due to NDAs, but I would much rather see Klipper support standard volumetric extrusion than add this type of automatic control. Using volumetric extrusion you would measure the amount of material that comes out of the nozzle per extruder step/rotation rather than the amount of filament traveled per extruder step/rotation. Volumetric extrusion would make it a heck of a lot easier to integrate pellet extruders or syringe-based extruders for things like silicone.

1 Like
20

Totally true, I did noticed that with “Velocity extrusion” I was able to get more predictable results than when was working with slicers control, and if you want to find answer why something behave not as you expected - good luck to analyze whole software stack (Slicer + Firmware).
That’s main reason to go closer to machine (Firmware), and when I`m spending my time on that - I don’t want to manage additional spreadsheets just to calculate extrusion, speeds, etc … - That’s machine Job to do that!

About material - YES, it’s behavior is totally non linear and very dependent from hardware and accel/decel or constant speed of processing - In Klipper I have hope for PresureAdvance - at least it’s implementing pre-charge and pre-release to some extends, but I didn’t analyze it yet, does it have some Non-Linear components of material or not, most probably not :frowning: , but that can be fixed in future :slight_smile: