@T3P3Tony PS, though: this blog series is awesome! I hope those involved can pick it back up sooner than later. What a cliffhanger!
Posts made by Kiolia
-
RE: Pressure Advance smooth time
-
RE: Pressure Advance smooth time
@T3P3Tony I'm glad to hear the work is/has been happening, either way! I could type all day about this, but I'm pulling my own topic off into the weeds. Ahem: Extrusion and Extruders are complex, and I think RRF would benefit from more levers to pull for tuning them
-
RE: Pressure Advance smooth time
@T3P3Tony That looks like some meaty reading and I'm excited to look through it! Thanks!
This is a sidebar, but on a skim, I don't see any obvious mentions of physical effects besides filament spring factor -- which is fine, of course, especially in a "Part 1: Theory" -- but I do think that a full examination of long bowden behavior and corrections would benefit from also considering overall path friction and the spring behavior of PTFE (which, afaik, has anisotropic stretch/return rates?). I have seen great improvements in print crispness and reductions in tuned PA values (by 20+%) by controlling the PTFE stretch with aramid sheathing anchored to the fittings and lightly preloaded. Path friction, meanwhile, scales with bowden length and (since PA also scales with path length) it presents a nonlinear punishment factor on the extruder -- not only must it move faster for higher PA, it must fight even more resistance to do so!
-
RE: Pressure Advance smooth time
@gloomyandy I do wonder about the Klipper implementation and how it may slide the start of pressure build forward. Physically, there must be some delay between the start of an E move and extrusion actually starting, so presumably if smoothing is correct this would be right. However, that gap would be disconnected from the smoothing time required solely for the extruder's sake. If klipper users are complaining about accuracy issues with high smooth time, perhaps that is partly because of moving that buildup too early?
-- And this toward what I mentioned before about smoothing time papering over extrusion system inadequacies: if you have to set a high smooth time because you're trying to run bowden PA with a 4:1 Mobius (for example), the smooth time isn't helping your extrusion quality, it's compensating for that poor stepper trying to deliver 4x the E demand. That's why I think it's worth being critical of complaints about smooth time in Klipper from users who may not be setting themselves up for success from the hardware perspective. It's still a fudge factor (probably), but outcomes depend a lot on how much you're trying to fudge
-
RE: Pressure Advance smooth time
@deckingman All of this is based on my printing and extruder development experience (hopefully a dev weighs in eventually; I'd like "real" answers to your questions, too): yes, the M566 jerk config is respected and defines the functional speed/acceleration cap for printing moves in RRF. If you cap E jerk too low for your combination of print accel and PA, RRF caps print accel; if you set E jerk too high, the extruder skips. M201 accel limits for E do not seem to play a major role in PA performance, at least in that setting a low E jerk and high E accel does not appear to resolve the "pick speed cap or skips" conundrum, and DC has posted someplace here about how you should actually not set E accel too high (the limit being factored from the jerk and PA settings).
From this I deduce that RRF is commanding instant or near-instant E demands for PA, because otherwise E acceleration would be a more meaningful term. I also worked to this conclusion from another direction in tuning a bowden extruder design, in that I could tune retractions to skip or not skip based on E speed + E accel config limits, but E jerk settings could be anything within reason and cause no issues until moving to actual print testing with PA enabled.
The Klipper implementation of PA does not (to my understanding, but I'm not an expert) cap print moves based on the E limits, so there is at least that difference. I don't understand how it gets away with doing this, and maybe it doesn't actually get away with it.
-
RE: Pressure Advance smooth time
@Kiolia A few additional points that may be worth making towards this conversation re: what the ask is and is not:
-
PA smoothing may not address any root source of extrusion inaccuracy. My take is that it's a more of a "compromise slider" for extrusion accuracy vs extent of the usable acceleration envelope.
-
PA smoothing can (and often does, by all appearances, in the klipper community) compensate for inadequate extrusion system hardware. By the same token, however, it may obscure those inadequacies and make it harder to identify poorly spec'd extruders and related issues (friction, bowden stretch, etc.) as root causes of extrusion performance problems.
-
Hypothesis: Ultimately, PA smoothing might be called a bandaid fix for the fact that the instantaneous E demands derive from instantaneous acceleration changes. It might be more accurate printing-wise to eliminate those at the source by allowing a smoothing factor on acceleration changes instead. However, I'm pretty sure that easing on acceleration is a darkly nontrivial kettle of fish, and I'd rather ask for a bandaid than a low-level rework of the whole motion control scheme.
-
-
RE: Pressure Advance smooth time
@gloomyandy Thanks for those links! I do have the general sense that smoothing might cause PA to become progressively less accurate as smooth time increases -- i.e., that RRF's 0 smooth time might be "ideal" -- and those discussions seem to align with that generally. (My own experiments with bowden suggest that most people using it don't realize how steep the extruder demands are, smoothing or no smoothing, and don't realize how bad fittings and unsupported PTFE are for stretch -- I would not take any data re: bowdens to try chasing issues with PA unless all fitting and PTFE stretch have been mechanically eliminated on the test rig, e.g., with aramid sheathing (which works extremely well).)
In any case, even if no smoothing were proven to be the "ideal" case, I believe it's fair to say it's not mechanically realistic, and that adding a smoothing parameter would still (in that case) be a highly useful tool for tuning extrusion. I believe most people would prefer "printing fast might cause slight blobbing to be tuned out" vs the current "printing fast might be impossible because the stepper will overheat/skip/underextrude if config has uncapped the E limits enough for the PA demands"
I understand that implementation is probably nontrivial, especially re: IS interactions ...
-
RE: Pressure Advance smooth time
@Kiolia For some additional
pleadingbackground on why PA smoothing would be an impactful addition to RRF, I'd like to commend this video from Eddie The Engineer, which has been around for a while but only just came to my attention. The linked timestamp 13:37 is where he starts into the specific issue of extreme E stepper acceleration demands from unsmoothed PA, but I'd suggest backing to 11:00 (if not the beginning) for context. https://youtu.be/rj8VOEHXXII?si=Bb2XWAm71EXZqfDv&t=817 -
Pressure Advance smooth time
This may already be on the RRF development radar, but I'd like to request that Pressure Advance be extended with the option of a smoothing factor like Klipper's pa smooth time that takes the edge off extrusion rate slams under accel/decel.
So far as I can tell, RRF PA commands instant E feedrate changes that can be quite large, and speed caps printing if E jerk can't meet those. However, E jerk is very hardware-intensive with gear reductions involved, and that makes it quite challenging to spec a workable extruder for high accel on any length of bowden.
(For context, I have been working on a couple of extruder designs for short, medium, and long bowdens on my 6WD delta (Duet 3 6HC + 3HC toolboard), and generally finding good success with getting high extrusion quality and reasonable PA values, but the E jerk demands just get untenable with PA enabled into 5 figure accel ranges. Given that I've hit the same wall with every commercial extruder I've run before now in bowden configuration, I'm coming to the conclusion that this is not a fully hardware-solvable challenge and hoping RRF can gain more levers to pull so printing accel doesn't have to be capped by E jerk limits.)
-
RE: M584 doesn't allow multiple steppers on the same E axis?
@Phaedrux Thank you for the reply. As long as it works, I suppose that's all right! And it does. Whew! I went through a lot of effort and couldn't figure out where all the power was going. Dragging along an idle stepper explains a lot. It's more than 3x faster now
-
M584 doesn't allow multiple steppers on the same E axis?
I'm working on a two-stepper extruder (yes, it's extreme, yes, that's the point, and yes, it works) and I just realized after some struggles that only one of the steppers is being driven while the other sits idle. They are connected to separate drivers on a 3HC toolboard. I'm concerned that the M584 command is interpreting my attempt to assign two steppers to one E axis as instead creating two separate extruders. Here's the relevant part of my config:
; Drives M569 P0.0 S1 ; physical drive 0.0 goes forwards M569 P0.1 S1 ; physical drive 0.1 goes forwards M569 P0.2 S1 ; physical drive 0.2 goes forwards M569 P0.3 S1 ; physical drive 0.3 goes forwards ; Z upper M569 P0.4 S1 ; physical drive 0.4 goes forwards ; Y upper M569 P0.5 S1 ; physical drive 0.5 goes forwards ; X upper ; M569 P1.0 S1 ; physical drive 1.0 goes forwards (LGX) (remapped from 3 to make wiring easier)(moved to toolboard 0) M569 P1.1 S0 ; physical drive 1.1 goes backwards (BoomBox A) M569 P1.2 S0 ; physical drive 1.2 goes backwards (BoomBox B) M584 X0.0:0.5 Y0.1:0.4 Z0.2:0.3 E1.1:1.2 ; set drive mapping
It does print as-is but -- as you might imagine -- the performance is somewhat limited without both motors running.
Is there a way to do what I'm trying to do without resorting to a workaround like setting this up as two mixing extruders running at 100%?
EDIT: A mixing setup does work to drive both steppers.
-
RE: M592 - Non-Linear Extrusion Comp - Cant get it to work...
@FurbyDealer27 said in M592 - Non-Linear Extrusion Comp - Cant get it to work...:
Fantastic question. I am using CNCKitchen's Blob Test.
I had to modify an excel sheet i found online to make it work for a delta printer
Would you be willing to share the modified sheet, or just explain what needed to be changed? I run a delta and this is testing I need to do (EDIT: actually, scratch that, I figured out quickly what needs modding and I'm already done. It didn't have a round bed mode, mainly.)
-
Can Input Shaper Plugin frequency display range be adjusted?
I'm using the 3.4.1-b1 Input Shaping plugin, and I can't find a way to view frequencies > 100 hz in the graph. An older version (I don't recall which) went higher by default, and offered an "extended" view as well. I'm very interested in understanding the higher-frequency responses on my machine. Is there a way to do this in the new version? If not, if there's a feature request list for it, I'll toodle thataway if someone could point me to it
-
RE: Clarification on RRF M201+M203+M566 behavior for Deltas
@dc42 Okay, thanks! I do think the docs could be clearer about that, although in fairness it's a nonissue for most motion systems. Appreciate the help!
-
RE: Clarification on RRF M201+M203+M566 behavior for Deltas
@o_lampe Z is also a delta's effectively heaviest direction (which goes doubly for mine because it's got a flying extruder gantry that barely moves in XY), and I don't want to Z-hop (or jog) at 200k+ mm/s^2 during speed testing, at least if I can help it.
I just want to understand if the limits are imposed by direction or by motor axis and by motor or effector motion. If they are per-motor and by-motor, I think that would be best case, but this isn't detailed in the documentation and I'd like to know so I can set the limits appropriately.
-
Clarification on RRF M201+M203+M566 behavior for Deltas
This is actually two questions, I think. I run a fairly zippy delta and I'm a bit unsure about the best way to set M201 / M203 / M566, because either these make no concessions for delta kinematics or the documentation is incomplete. (For context, I'd like to be able to set lower vertical move limits in the firmware vs the horizontal motion limits.) Hopefully this isn't a crazy can of worms.
First question: for deltas, do these 3 commands set the max accel / speed / jerk per physical axis (i.e., per stepper on a typical 3-stepper linear delta) or per cardinal direction?
Second question: for deltas, do these 3 commands set these limits based on the commanded effector motions (constant throughout the build volume), or the stepper/carriage motions required to achieve said motions (continuously variable throughout the build volume)?
Thanks in advance!
Also, I don't think I want to get into a discussion on how these should work for deltas, and maybe this is already a discussion I've missed, but I do think it'd be great to be able to configure limits that would prevent hitting step loss conditions at the outer print volume boundaries (where some steppers may have to outrun the head speed) without artificially limiting performance in the middle (where steppers may underrun head speed significantly).
-
RE: homedelta ignores configured homed height?
@alankilian Turns out it wasn't the homedelta at all, but thanks for checking this out and comparing against your config. Did you see benefits on your delta in going from V2.X to V3.X firmware? I've been through the release notes and didn't see anything that jumped out at me as a gotta-have, but release notes don't always tell the whole story!
-
RE: homedelta ignores configured homed height?
@phaedrux Nailed it! Switching X1 Y1 Z1 to X2 Y2 Z2 in config.g was indeed the fix. Homing behavior is now exactly as expected. Thank you SO MUCH for the quick resolution, that's an end to a very long headache for me!
-
homedelta ignores configured homed height?
So I've been running my Duet2 Wifi (FW v2.04 from Nov 2019) for close to 18 months now and beating my head against this problem on and off all along. Printer is a Kossel delta, and basically, when I use the home command, the printer already has to be homed for it to work correctly. Generally, I have to home the printer, cycle power to reset the Z height to the configured value, and home it again to get the correct height homed. I don't use a bed sensor, so it has to be correct right out of the home operation. When it's correct, everything works great, but otherwise ... PORBLEMS. This wasn't such a big deal before I changed to 0.9 steppers with lower detent torque, but now it's getting to be a pain.
Anyway, what happens is that if the printer is homed, all works correctly, but if the head is anywhere else in the build volume on power-up, the homing operation acts like wherever it started was the configured height set by M665, and then it runs up to the endstops and adds that distance on top of the M665 height. So if the configured height is (say) 200 and it homes from Z100 after power-up, it's going to home and then display the Z as 300. Needless to say, trying to print from there would be bad times.
What I want is for the homing operation to reset the Z height to the M665 height set in config.g. That's how it worked in Marlin on my previous control board. I just want to be able to home and re-home to my known correct height without a power cycle (and losing holding torque, thus risking the head moving and throwing it off again) between homes. I just can't for the life of me figure out how to do it. Adding M665 with just the H value to homedelta.g gives me a homing error, and per the reprap documentation you can't use M208 to set axis maxima on a delta because ???? ...
Anyway, help would be greatly appreciated! My homedelta and config file contents are below. To my knowledge there is nothing in my config override and (again) there's no bed leveling or Z probing going on. I do note that I might have used the configurator for the wrong version (2.03 is in the header), but again, everything but this seems to work fine. I've got the final centering move commented out in the homedelta because it just throws errors about not being able to get there.
Thanks!
; homedelta.g
; called to home all towers on a delta printer
;
; generated by RepRapFirmware Configuration Tool v2.1.2 on Fri Nov 22 2019 00:41:16 GMT-0500 (Eastern Standard Time)
; Updated by JP 11.23.19 to fix it.
; Upped the down move to 10mm to give more space for bearings to stabilize -- 4.15.21 JP
G91 ; relative positioningG1 H1 X400 Y400 Z400 F2500 ; move all towers to the high end stopping at the endstops (first pass)
G1 H2 X-10 Y-10 Z-10 F1800 ; go down a few mm
G1 H1 X15 Y15 Z15 F360 ; move all towers up once more (second pass)
G1 H2 X-5 Y-5 Z-5 F1000 ; move down a few mm so that the nozzle can be centred;G90 ; absolute positioning
;G1 X0 Y0 F1000 ; move X+Y to the centre; Configuration file for Duet WiFi (firmware version 2.03)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool v2.1.2 on Fri Nov 22 2019 00:41:16 GMT-0500 (Eastern Standard Time)
; Updated by JP 11.23.19 -- Added PID tunes 3.6.21 - Updated PID tune for V6 and increased height
; 3.18.21 - Updated height for rebrace and slightly reduced E speed/accel - JP; General preferences
G90 ; send absolute coordinates...
M83 ; ...but relative extruder moves
M550 P"Kossel" ; set printer name
M665 R129.72 L295.36 B115 H224.9 ; Set delta radius, diagonal rod length, printable radius and homed height ; WAS L291.75 before cal [3.21.21 NOTE: this gives perfect flatness @ R127.25 but prints 1+% oversize] - 3.21.21 NOTE: WAS R127.25 but cal showed this printing sig convex; up'd to R128.22 which may still be slightly convex but with error < .025mm center-to-edge and likely better; 4.9.21 added 1.5 from R for new crgs; 4.15.21 upped height from 224.2 to .9 for new build
M666 X0 Y0 Z0 ; put your endstop adjustments here, or let auto calibration find them; Network
M552 S1 ; enable network
M586 P0 S1 ; enable HTTP
M586 P1 S0 ; disable FTP
M586 P2 S0 ; disable Telnet; Drives
M569 P0 S1 ; physical drive 0 goes forwards
M569 P1 S1 ; physical drive 1 goes forwards
M569 P2 S1 ; physical drive 2 goes forwards
M569 P3 S0 ; physical drive 3 goes backwards
M584 X0 Y1 Z2 E3 ; set drive mapping
M350 X16 Y16 Z16 E32 I1 ; configure microstepping with interpolation ; E WAS 16, changed to 32 in hopes this disables X16 interpolation - 4.6.21
M92 X200.00 Y200.00 Z200.00 E1818.00 ; set steps per mm ; E WAS 2727.00 before belt drive - 9.29.20 ; E WAS 909 at 16 microstepping; XYZ WERE 80 at 1.8+20T - 4.8.21
M566 X2400.00 Y2400.00 Z2400.00 E72.00 ; set maximum instantaneous speed changes (mm/min) ; E WAS 36 before belt drive - 9.29.20 ; upped motors to 2400 (40mm/s jerk) and dropped extruder to 72 from 108 as test - 4.7.21
M203 X36000.00 Y36000.00 Z36000.00 E6800.00 ; set maximum speeds (mm/min) ; E WAS 2400 before belt drive - 9.29.20 - Dropped to 6800 from 7200 3.18.21
M201 X9000.00 Y9000.00 Z9000.00 E330.00 ; set accelerations (mm/s^2) ; E WAS 120 before belt drive - 9.29.20 - dropped to 330 from 360 3.18.21 ; raised XYZ from 9k to 18k - 4.7.21; - and returned to 9k 4.16.21
M906 X1500 Y1500 Z1500 E750 I35 ; set motor currents (mA) and motor idle factor in per cent ; E WAS E900 before belt to pancake - 4.6.21 ; XYZ were 1200 before setup for 0.9s - 4.8.21 XYZ were 1000 and E was 550, but seems low (moire) - 4.16.21
M84 S60 ; Set idle timeout; Axis Limits
M208 Z0 S1 ; set minimum Z; Endstops
M574 X1 Y1 Z1 S1 ; set active high endstops; Z-Probe
M558 P0 H5 F120 T6000 ; disable Z probe but set dive height, probe speed and travel speed
M557 R85 S20 ; define mesh grid; Heaters
M307 H0 B0 S1.00 ; disable bang-bang mode for the bed heater and set PWM limit
M305 P0 T100000 B4138 R4700 ; set thermistor + ADC parameters for heater 0
M143 H0 S120 ; set temperature limit for heater 0 to 120C
M305 P1 T100000 B4138 R4700 ; set thermistor + ADC parameters for heater 1
M143 H1 S285 ; set temperature limit for heater 1 to 285CM307 H1 A388.8 C163.6 D9.3 V11.8 ; Tuned PID for hot end, from 3.6.21 tuning
M307 H0 A164.7 C945.5 D1.9 V11.7 B0 ; Tuned PID for bed, from 11.23.19 tuning; Fans
M106 P0 S0 I0 F25000 H-1 ; set fan 0 value, PWM signal inversion and frequency. Thermostatic control is turned off ; Raised default 500hz to 31.5khz on PWM - 4.6.21; trying 25k since booster won't start at 31.5 - JP 4.15.21
M106 P1 S1 I0 F500 H1 T45 ; set fan 1 value, PWM signal inversion and frequency. Thermostatic control is turned on; Tools
M563 P0 D0 H1 F0 ; define tool 0
G10 P0 X0 Y0 Z0 ; set tool 0 axis offsets
G10 P0 R0 S0 ; set initial tool 0 active and standby temperatures to 0C; Custom settings are not defined