Preload: A Modest Proposal

User avatar
pjr
Posts: 692
Joined: 05 May 2015, 10:27
Location: Kamnik, Slovenia

Re: Preload: A Modest Proposal

Post by pjr »

Sorry, but way over my head again; will try to re-read a few times as something may sink in...

So I use Marlin (Prusa Edition). Marlin apparently treats movement and non-movement G-code commands differently.

Non-movement commands (Fan, Temp etc) are processed immediately - so there may be instances where the extruder heater is turned off several seconds before the print is complete. This can be overcome by using G4 P0 which causes the movement command buffer to empty before processing any more commands.

The movement commands are processed by the planner and placed in a buffer- I believe that up to 16 movements are buffered and processed in turn by the ISR. I don't know whether the 16 movements are G-code commands or steps as I haven't had a look at that part of the firmware (and I don't intend to).

Thanks again for your input. Now back to reading your post again.

Peter

EDIT: OK, I think I am starting to understand. And my conclusion from your post is that a slicer cannot implement a preload method which works in all cases and that Preload is best left to the firmware ("Linear/Pressure Advance").

EDIT2: the planner buffer has 1280 bytes available
Beefeater
Posts: 34
Joined: 17 Jul 2017, 22:54

Re: Preload: A Modest Proposal

Post by Beefeater »

Beefeater wrote:EDIT: OK, I think I am starting to understand. And my conclusion from your post is that a slicer cannot implement a preload method which works in all cases and that Preload is best left to the firmware ("Linear/Pressure Advance").
No, I actually very much want to see Preload implemented in Kisslicer. That's why I began this thread in the first place. It won't work well with what I called Type 1 firmware (the kind that builds its own ramps for each G1), but it will work with Types 2, 3, 4. I was only saying that there are still other issues that Preload will not and does not aim to resolve: Over-extrusion on short segments in Type 1 firmware, jerks in Types 3 and 4, and over-extrusion at sharp corners in all firmware types.

[As a general philosophical matter, I would argue for as many features as possible to be implemented in slicers rather than firmware. This allows more of us (even if, in some cases, not all of us) to enjoy them, and maybe write post-processors to adjust them. Slicers are easier to update as new ideas come along. Slicers have the time and computing power to plan ahead along the print path. The only exception is time-critical tasks where reading and interpreting G-code could be a bottleneck. Velocity ramps is one of those.]
Beefeater
Posts: 34
Joined: 17 Jul 2017, 22:54

Re: Preload: A Modest Proposal

Post by Beefeater »

pjr wrote:The movement commands are processed by the planner and placed in a buffer- I believe that up to 16 movements are buffered and processed in turn by the ISR. I don't know whether the 16 movements are G-code commands or steps as I haven't had a look at that part of the firmware (and I don't intend to).
What would be interesting to know is how the commands are read out of the buffer. Is the buffer only used for performance reasons, or does the firmware, when processing a G1 command, actually look at future G1 commands to decide whether a velocity ramp is needed? Or does it even construct ramps at all? In other words, is it Type 1, Type 2, Type 3, or Type 4?

As a matter of fact, if anyone reading this knows whether their firmware is Type 1, Type 2, Type 3, or Type 4, or some other type, holler it out. I think it would be helpful to know what's out there.
User avatar
pjr
Posts: 692
Joined: 05 May 2015, 10:27
Location: Kamnik, Slovenia

Re: Preload: A Modest Proposal

Post by pjr »

Beefeater wrote:[As a general philosophical matter, I would argue for as many features as possible to be implemented in slicers rather than firmware. This allows more of us (even if, in some cases, not all of us) to enjoy them, and maybe write post-processors to adjust them. Slicers are easier to update as new ideas come along. Slicers have the time and computing power to plan ahead along the print path. The only exception is time-critical tasks where reading and interpreting G-code could be a bottleneck. Velocity ramps is one of those.]
Yeah, I pretty much agree with all of that, especially with 8-bit controllers. My biggest issue with the Prusa Mk3.

But to do this properly, and "Linear Advance" feature in the firmware must be turned off and acceleration/jerk values set as high as possible to allow full slicer control, leaving the firmware to handle only G-code interpretation.

Peter

EDIT: KISS Preload is effective at the start and end of paths only; a path includes corners which requires the movement to slow down and this is left for the firmware to handle. The extrusion at corners of perimeters only appears to be slightly reduced, but the feed rate remains constant. Therefore increasing acceleration/jerk values would cause major printing issues unless KISS were able to handle this with G-code.
Beefeater
Posts: 34
Joined: 17 Jul 2017, 22:54

Re: Preload: A Modest Proposal

Post by Beefeater »

I think you need to determine whether your firmware generates acceleration/deceleration ramps at the beginning and end of each G1 ("Type 1"), or only at the beginning ("Type 4"), or only for some of the G1's ("Type 2"). If it's Type 1, then yes, set acceleration as high as possible or turn it off, this will effectively convert to Type 3. But if it's Type 2 or Type 4, then you can take advantage of the firmware's acceleration feature to soften the jerks and still have the curves and (a future version of) Preload work correctly.

(My BFB firmware builds ramps on each G1 (Type 1), but only if the velocity is greater than 12mm/s. So when I want extrusion to be accurate on a curve, I must keep velocity below 12mm/s. But that code was written in 2010. Surely the firmware developed today is smarter than this. Or maybe not.)
User avatar
pjr
Posts: 692
Joined: 05 May 2015, 10:27
Location: Kamnik, Slovenia

Re: Preload: A Modest Proposal

Post by pjr »

Beefeater wrote:I think you need to determine whether your firmware generates acceleration/deceleration ramps at the beginning and end of each G1 ("Type 1"), or only at the beginning ("Type 4"), or only for some of the G1's ("Type 2"). If it's Type 1, then yes, set acceleration as high as possible or turn it off, this will effectively convert to Type 3. But if it's Type 2 or Type 4, then you can take advantage of the firmware's acceleration feature to soften the jerks and still have the curves and (a future version of) Preload work correctly.

(My BFB firmware builds ramps on each G1 (Type 1), but only if the velocity is greater than 12mm/s. So when I want extrusion to be accurate on a curve, I must keep velocity below 12mm/s. But that code was written in 2010. Surely the firmware developed today is smarter than this. Or maybe not.)

Yeah, Marlin generates acceleration ramps at start and end of a path, subject to the Jerk value - which is your 12mm/s - slower than that value, it assumes the printer is capable of transitioning from one path to the next without stopping.

As I see it, either the slicer does it all or the firmware does it all. The situation where the slicer makes assumptions about the firmware capabilities end up with a bad result.

Recv: echo:Advanced variables: S=Min feedrate (mm/s), T=Min travel feedrate (mm/s), B=minimum segment time (ms), X=maximum XY jerk (mm/s), Z=maximum Z jerk (mm/s), E=maximum E jerk (mm/s)
Recv: echo: M205 S0.00 T0.00 B20000 X10.00 Y10.00 Z0.20 E2.50

Peter
Dreide
Posts: 66
Joined: 07 Nov 2014, 15:23

Re: Preload: A Modest Proposal

Post by Dreide »

I use Repetier firmware, which does acceleration/deceleration for each G1 command so that the print speed comes as close as possible to the specified F-speed without exceeding the F-speed or any jerk speeds at junctions or start or end points. Note that jerk basically refers to (Euclidean) deltas between line segment speeds, which means that acceleration up to speeds far beyond jerk speed is possible across line segments, even if the segments describe a curve. The G1 buffering in the path planner is both, providing enough commands for uninterrupted printing and looking ahead for speed planning. The buffer can hold 15 line segments at a time, and each time a new segment (G1 command) is added, the planner re-computes the speeds of possibly all line segments in the buffer so that speed is maximized but the printer can still come to a safe full stop if there were no more G1 commands coming in for a long time. So even if the next G1 command will get stuck for some reason, the printer won't lose steps. In addition, the planner slows down printing speed if the buffer seems to run low. I just had a quick look at Marlin, and it seems to work in a similar way.

IMHO, all the preload-handling should be left to the firmware, especially when the slicer would otherwise need to chop line segments into tiny pieces, thereby blowing up G-code files and possibly forcing the firmware's path planner to slow down or create sub-optimal speed profiles because it cannot look far enough ahead. At least with Repetier and Marlin, we have the ADVANCE feature instead, which is supposed to take care of preload, even though it might come with a few downsides. If I am not mistaken, ADVANCE works only within the given line segments, meaning ADVANCE does not add pure suck/prime segments. ADVANCE forces the extruder to run faster (during acceleration) or slower (during deceleration) than it normally would, which is all fine if jerk speed is 0. Theoretically though, with non-zero jerk speed, additional retraction and priming (without move) would be needed. For in-path junctions (and maybe also for the start point), the firmware can, and probably does, spread such additional E-stepping across subsequent line segments. For start and end positions, it is usually always the full jerk speed that becomes relevant for ADVANCE, which could be taken care of by explicit prime and suck commands before and after the path. AFAIK, this is not done by these firmware flavors yet. So, maybe, this is something the slicer could help out with, without affecting the firmware's path planning and without blowing up the G-code. The slicer knows about the extrusion volume already and would just need to know the jerk speeds and the ADVANCE factor in order to calculate the theoretical prime/suck (to be added to the user's prime/suck distances). BTW, all these parameters can be set via G-code, so the slicer could provide a convenient way for the user to actually control these parameters according to material or alike.
See also https://github.com/MarlinFirmware/Marli ... advance.md.

More in general, the idea of having a precise model that handles everything related to preload is appealing, even if the parameters have implications that are rather inscrutable. However, if the model is not quite right, which is not so unlikely given the complex nature of the matter and the vast variety of printers and materials to cover, I might be forced to compensate for the model's shortcomings by fiddling with parameters without really knowing what I have to do in order to get rid of a problem without creating new problems. In this case I'd rather have more but simpler parameters, or parameters which I have to adjust more often; parameters for which I have a better intuition about their effects and side-effects. For the time being, I stay away from v1.6, because I seem to be far better off with ADVANCE (my printer has a direct extruder). Since v1.6 does not allow for different prime/suck settings, I am stuck with v1.5, missing out on many other nice features :-(
Beefeater
Posts: 34
Joined: 17 Jul 2017, 22:54

Re: Preload: A Modest Proposal

Post by Beefeater »

Thank you Dreide for explaining Repetier and for including a link to Marln development. I had not been aware. It seems the physical model used in Marlin is exactly the same as in Kisslicer and as I used at the top of this thread. The difference is that Marlin only matches extruder velocity to head velocity, while Kisslicer simultaneously adjusts both. Consequently, Marlin fails when the head is accelerating too fast for the extruder to keep up.

To explain the issue in Marlin language: Suppose the head is cruising at velocity V1 and extrusion flow F1, then accelerates to V2 and F2, F1/V1=F2/V2. Denote by DT the time interval over which the acceleration occurs. In order to force filament through the nozzle at rate F, the solid rod must be compressed by the amount C*F. (The constant C is proportional to what Marlin calls "spring constant k" -- bad terminology, because a spring constant relates distance to force, not velocity, and is a large number for a stiff spring, whereas k is a large number for a soft spring.) Therefore the extruder must not only accelerate from F1 to F2, but also inject an additional distance on the E axis ("advance steps") DE=C*(F2-F1). Now the main problem is not how to distribute the advance steps DE over the time period DT. The problem is that when C is large (long Bowden tube / viscous filament / narrow nozzle), the extruder cannot deliver so many steps in so short a time.

I was hoping to avoid the slicer-vs-firmware debate, but this gives such a clear case in point that I cannot resist. As I had argued (see Fig. 5, earlier), an acceleration/deceleration slow enough for extrusion to keep up may take tens of millimeters. This means tens of G1 commands if printing a curve. Even the best firmware's look-ahead capability is not unlimited. With a weak CPU and real-time interrupts to deal with, there is only so much complexity it can handle. Secondly, over-extrusion at corners may be more acceptable in an infill (especially sparse infill) than in a perimeter loop. A slicer can use, or allow the firmware to use, a higher acceleration in infills (as high as the head can handle without losing steps), but force lower acceleration in perimeters as necessary for accurate extrusion. Firmware, on the other hand, has no idea whether it is printing a perimeter or an infill.
User avatar
pjr
Posts: 692
Joined: 05 May 2015, 10:27
Location: Kamnik, Slovenia

Re: Preload: A Modest Proposal

Post by pjr »

Prusa Edition Marlin now includes working "Linear Advance" as described here: http://marlinfw.org/docs/features/lin_advance.html

With the MMU, I have not as yet found a suitable "K" value.

Peter
inventabuild
Posts: 271
Joined: 09 Nov 2014, 23:03

Re: Preload: A Modest Proposal

Post by inventabuild »

What about the idea of slowing the print speed down at the end of a path to reduce stringing and oozing?
Making it adaptive would mean that very short paths (like gap fill) would always print at the low(est) end of the adaptive print speed; whereas long loops would print at the high end of the print speed all the way around until it started closing in on the end of the loop which is when it would start slowing down to reduce the pressure of the molten plastic in the nozzle.

Maybe combine w/ PreloadVE for some situations?

Or is PreloadVE already doing this?
Post Reply