[FR] Get Linear Advance + S_Curve completed and reliable

[MarkusThur]

Is your feature request related to a problem? Please describe.

This feature request, or better first Request for discussion, is related with the issue described in https://github.com/MarlinFirmware/Marlin/issues/14728 [BUG] Linear advance incompatible with S-Curve acceleration

If I see it right this issue is not solved, except by the sanity check that warns / throws a error if you enable LIN_ADVANCE and S_CURVE_ACCELERATION without marking you explicitly want it by activating EXPERIMENTAL_SCURVE at the same time. Where EXPERIMENTAL_SCURVE does not activate any special s-curve feature, just only marks that you definitely want it.

I use https://github.com/knutwurst/Marlin-2-0-x-Anycubic-i3-MEGA-S, which relies on Marlin 2.0.5.4 on a Anycubic Mega S. There Linear_Advance and S_Curve are activated by default and work very well. The described problems are not seen.

Problem observed is (that obviously) the time prediction is a mess, as triangular movement is exspected and S-Curve Movements are obviously slower.

But Linear_advance with a K factor of 0.51 works well with printing speed of 50 to 70 mm/s, as well as printing acceleration of 3200 mm/s^2 is possible without interfering with print or causing strange "sound" of the extruder. Starting with a print acceleration of 3600 mm/s^2 the print gets a little "dirty" as the break is to hard and causes vibration / resonance, but does not cause issues on the extruder.

Travel acceleration even up to 4500 mm/s^2 is possible, but 4000 mm/s^2 travels more nicely and vibration / resonance on brake is absorbed without hampering a print at travel speed of 120 mm/s. Faster travels are possible, but may end in step losses of the bed and / or imprecise positioning at end-position.

Are you looking for hardware support?

NO Nevertheless, related with statement above is following hardware: Anycubic Mega S with: Trigorilla 0.0.2 board, using a ATMEGA2560 TMC2208_standalone Steppers So obviously S_Curve + Lin_Advance is possible on a AVR Controller, or was possible till 2.0.5.4

Describe the feature you want

What I want to do / the feature to be requested is as follows.

1. Look into the issue, especially what may changed between there and now in S_CURVE and / or LINEAR_ADVANCE

2. Discuss potential solutions (independent if it works together or not, there is a issue in time prediction of the S_CURVE and therewith the point where LIN_ADVANCE has to start doing it's work)

3. Implement the solution

Additional context

From a first feeling, the main issue is the longer and "hard" to predict time an S_CURVE accelerated movement will need.

The S-curve accelerated movement takes a longer time, as the maximum acceleration of the S_CURVE is the same as the one of a "triangular" movement. In worst case, the S_Curve is not even able to reach max. speed and does not reach maximum acceleration, similar to the "normal" triangular movement, which at some point is not able to reach travel speed, before braking has to start. But this point is obvious earlier for S_Curved movements.

But for any S_Curve accelerated movement, there is a "corresponding" triangular movement, that has the "same" timing, e.g. a triangular acceleration from 0 to 50 mm/s with a acceleration of 2500 ,mm/s^2 obviously needs 0.02s to reach the max speed and will travel 0.5mm during that time. (exact half of what it would have been at full speed, or an unaccelerated movement with 25mm/s). An S_Curve accelerated movement with a max_acceleration of 2500 mm/s^2 will need a little longer due to the lower accel at the beginning and ending of the acceleration phase, For ease of explaination I use a Z_Curve with following parameter,

form 0 to 12.5 mm/s use 1250 mm/s^2 (accel/2) from 12.5 to 37.5 mm/s use 2500mm/s^2 (accel) from 37.5 to 50 mm/s use 1250 mm/s^2 (accel/2)

This way we will need 0.3s to reach travel speed. And the moving distance will be:

distance after each Phase of the Z:
s(0.01) = (0.5*1250*0.01*0.01+0+0)mm = 0,0625mm
s(0.02) = (0.5*2500*0.01*0.01 + 12.5*0.01 + 0.0625)mm = 0.3125mm
s(0.03) = (0.5*1250*0.01*0.01 + 37.5*0.01 + 0.3125)mm = 0,75mm

This exactly equals an unaccelerated movement with 25mm/s for 0.03 seconds. so this also shall equal a movement with a linear acceleration of:

(50mm/s)/0.03s = 1666.66mm/s²
s(0.03) = (0.5*1666.66*0.03*0.03)mm = 0.75mm

So the idea is, to either

• calculate the equivalent acceleration of the S_Curve and use it in Linear_advance or
• to calculate a S_Curve acceleration that is equivalent to the triangular acceleration imposed by the desired acceleration.

Advantage of solution one is, the set max_accel is not exceeded, disadvantage is, time prediction for the total print still stays a mess. Advantage of solution two is time prediction of the print does not need to know if it is S_Curved or not, disadvantage is the max Accel is exceeded by the "form factor" of the S_Curve. Solution two imposes, that the max_accel of printers, that already use S_Curve, would have to reduce their max_accel value, as it now would represents the "equivalent" acceleration instead of the real acceleration.

Both solutions could be implemented in a first approach, using the EXPERIMENTAL_SCURVE flag, which would give the flag a more "useful" meaning.

I am happy to hear your opinions on it.

[RipperDrone]

wow, wasn't aware that EXPERIMENTAL_S_CURVE was just a flag for the time being, never checked other occurrences of this flag in the code :-)

I'd go with option 2 - having a reasonably accurate print time prediction seems important to many users. On the other hand, redefining accel as effective accel seems a reasonable price to pay...

Curious to see what others are thinking...

PS: Yes, my Ender 3 V2 is acting up with weird sounds if I play around with K values in LIN_ADVANCE at high accelerations... (S_CURVE commented out)

[thinkyhead]

The feature is still experimental in the sense that this post represents one of the few confirmations we have that it is behaving okay and not causing strange issues. Any improvements to this feature to make it more robust will be much appreciated. It would be especially useful to put a scope on a variety of 8- and 32-bit boards to observe how XYZ and E behave together and to see the effects of various adjustments. The time I personally have for testing is limited, due to general management of the project, so any help in the area of testing and refinement of these kinds of details is also much appreciated.

[MarkusThur]

@thinkyhead Thank you for the answer. As I am in the lucky position to have a 8bit Trigorilla and a 32bit SKR Pro aviable and was going to test the behaviour of both with the same mechanics anyways, I will go on and and look deeper into it. @RipperDrone Let me think about it, cause from what you say the issue of "wired" sounds is maybe not related with the combo of S_Curve and Lin_advance, but in LIN_ADVANCE itself or maybe in "unsuitable" settings for the mechanics at all. Can u tell, where the strange noise comes from (Extruder-Stepper, X-Stepper, Y-Stepper, bearings, whatever)?

[RipperDrone]

@MarkusThur sure, sound is limited to extruder (Hemera direct drive). Comes from hard retraction moves. More pronounced at higher extruder accels or feed rates, looks like I have to stay below 25mm/s retract speed. NO noise at retraction = OFF. Therefore, I was assuming that IF accelerations in all axes are ramped over S-shaped curves, extruder / filament should 'see' lower effective accels / speeds and run more silently...

[MarkusThur]

@RipperDrone thank you for your input, this fits to what I am asuming, and will look for in the code. 25mm/s shouldn't be too much, especially as you shoudn't need much retraction on a Herma anyways, and with Lin_Advance the needed retraction of a direct extruder should go to nearly 0. On my bowden the needed retraction reduced from 6.5 to 7.5mm to 1 to 1.5mm, as Lin_Advance already reduces the pressure in the nozzle and relaxes the material in the bowden. On a direct drive the effect should be much higher, bringing the needed retraction close to zero.

So I suspect there is something going on, that leeds to multiple direction changes while advancing Linear and then retract, which should not be.

I'd like to see your settings (and the one the slicer may do) for Ejerk, and Eacceleration and the K value for linear advance. to exclude that wired settings cause it.

Normaly a retract should even be "easier" as the material already got "riffled" by the forward movement and the grip is better than the on "round material" and the "counterforce" is close to zero, as it does not need to push the material through a tight nozzle.

If you can, maybe a screen or copy of the printers answer to M503 could help us both. Does your printer retract smoothly for material changes? And how about the K-Value is it sufficient?

[RipperDrone]

@MarkusThur Thank you. Pls find my 503 gcode response as follows: M503.zip

It has to be noted that I tuned down accels and feedrates to suppress the annoying retract noises. Going back to higher values will trigger them again...

K=0.04 is very moderate, setting higher K values will ruin the K factor test print (no continuous line on accelerations and decelerations). xyz test cube still has overshoot corner edges, so seems printer needs higher K, however I cannot test since the retract issue spoils the prints when I try...

Printer loads and unloads filament smoothly, PTFE tube has no increased friction, gripping spring force set to "normal" in Hemera (flush to surface) but tried min to max as well.

Jerk is set to Marlin stds (8,8,.4,5). Tried higher and lower values as well...

[MarkusThur]

@RipperDrone I looked into it, on first view nothing directly strange. On second view I have some questions to your settings: The E feedrate is limited to 10mm/s, the Hemera should even run better than a Titan, so 45 - 50 should be doable. Your X,Y speed is pretty high, a normal setting, bur i think only deltas do reach that high speed without issues. Your Acceleration is aprox 1/10 of what I usually see, while your jerk is normal... This maybe part of causing noises, your extruder on a speedchange may just only jerk. (just a guess). And if you use cura, cura overwrites your settings for X and Y acceleration and that then may interfere with the max accel you did set for the extruder, And in the last sector i found Stepper current... Not sure which steppers u use, but If I am not mistaken, M906 is for TMC steppers, so TMC2208 and better in UART mode.... You may should check your motors, usual Nema17 motors have a rated current between 1A and 2A (some smallers and some high power with 2.8A exist). The original E3D hemera comes with a 1.33A rated Motor, so a setting up to that should be OK. Same counts for your other motors. Especially, I can't believe that your high speed and low accel does fit with your extra low current limits. And there I fear we come to the noise production on a retract.

[RipperDrone]

@MarkusThur Very interesting, you might be up something there... let me follow up:

• E feedrate had been set to 50mm/s default, but the clicking sound caused me to reduce it step by step, hitting a more silent range at this low a setting. Hemera is capable of up to 45mm/s for feed/retract speeds, their manual says.

• x, y speeds are as per Ender 3V2 defaults, however in Cura max speeds are reduced further: Anyway what would be a reasonable recommended range - I can try setting it in the firmware as default and/or saving lower values to EEPROM

• I am using SKR 2 E3 Mini with TMC2209 drivers in UART mode

• stepper current is set as per Hemera manual: 1.33A max amps, reduced by a safety factor of 10% and RMS'ed to get effective current. Therefore, 940mA is the correct setting. Other stock Ender 3 V2 steppers have been set to 800mA initially (as per Crerality MArlin profile), when stepper motors got quite hot I followed some guides recommending values around 540-650mA

• These are CURA printer tab settings, just for information:

In a nutshell, what you'd recommend trying out is 45mm/s E max feedrate and reduced xyz speeds (down to to which values) to rule out that the screachy-eachy noise has to do with accel settings? :-)

[MarkusThur]

@RipperDrone Then let's try following; Your calculation for the steppercurrent is right, if Irms is set in the register of the TMC 2209. Am not 100% sure, if it sets Irms or Imax in the internal registeres. But as I understood, this value is supposed to be the RMS value https://teemuatlut.github.io/TMCStepper/class_t_m_c_stepper.html

Concerning your other motors, if the original steppers were TMC2208 in UART mode, set to 800ms RMS by firmware 800ms should be fine also with the 2209. If they were in step/dir mode with a value of 800mV, then your calc to around 560 to 570mA RMS is right.

https://reprapworld.com/customer/service/technical_information/adjusting_stepper_driver_current_on_the_ender3_v2/ They recommend a voltage setting of 1.22V for Step/Dir from the original board. Which means 860 to 870mA RMS. So 800mA rMS for those motors shall be fine. A Temperature of the Motor of up to 60°C is also fine. (a little hotter still is doable) Simple rule for motors, if it's hot, but u can touch it, it's in the limits.

And now we come to difference between Cura setting and firmware: setting your firmware Cura
M203 E10.0 E40.0 M201 E1000.0 E2000.0

So cura tries and maybe even uses 4x the max speed, you limit in Firmware and 2x the accel you did set the firmware limit to => It's unsure, what will be done. I'd first of all recommend to have both same to make sure, it happens, what u think is happening.

I just came to another idea also, I will try to visualize it. In principle I have the feeling, with your settings, the printer never leaves the accel and decel phases.

As I am working on a way to easily visualize the movement in general in order to get a better idea on what happens.

[MarkusThur]

Got a visualisation for trapezoid accelerated movement. (on S_curved movement, I'm still working). https://www.desmos.com/calculator/isogmb9uzz?lang=de I did preset values from your screens.

a9999 = max x/y acceleration 500 mm/s^2 
v9999 = max spped 500 mm/s
s3 = distance we wanna move
j = X/Y jerk 8 mm/s
v00 = start and endspeed

This may help to figure out, what may cause the noise / supresses the noise in your extruder. with your current settings, you need: a 14mm movement to change from 50 to 100mm/s and back. Otherwise you do not leave accel / decel phase. to come to your print speed of 50 / 100 mm/s from a standing and come back to stand you need movement length of 5 / 20 milimeters. To reach your travelling speed, you need a 125mm move, so half your bed. With S_curve_Movement this even seem to be a longer way, but this is where I am looking into atm.

Am pretty sure that there something wired is going on in combination with linear advance, as we definitely run into limits.

[RipperDrone]

@MarkusThur Thank you so much for your time you are putting into this - even not being 100% sure yet whether I am facing a general S_Curve accel issue or mismatching parameters. Let's see, here is my follow-up:

• TMC RMS current setting: Pls refer this document, I think it's solid: https://e3d-online.zendesk.com/hc/en-us/articles/360016249057-Hemera-Current-Adjustment-PDF-
• other axes: I had them set to 800 stock, no change. They were in step/dir mode. Now set to UART/STEALTHCHOP mode:
• difference CURA vs firmware: I was under the impression that EEPROM values overwrite firmware fallbacks, and CURA for each print job overrules EEPROM. MAybe this assumption is wrong. Anyway, responding to your hint directly: I tried to set both firmware and Cura to same values, extruder speed was down to 10mm/s, so was accel. Then increased in CURA only, and speed/accel was actually increasing, up to a point when the weirdo screetchy noise was back. Hypothesis seems proven, CURA overrides firmware.
• hehe, keeping the printer busy accelerating and decelerating, never giving it a chance to settle on a constant speed - I like that image, maybe there's more to it :-)

[RipperDrone]

Thank you for the little trajectory/kinematics helper tool, gives valuable insights. Is this leading to an assumption that the printer NEEDS to move at constant speed over a certain distance to make screetching sounds disappear? If so - yes, S-curve should cure it as well since it chops off the abrupt change of sign in accel, doesn't it?

Or r u recommending I should try

• some less aggressive settings for speed OR
• more aggressive settings for accel in the first place?

Of course I'm after min printing time as an optimization goal like everybody else, and the current time/quality tradeoffs seems pretty much ok... would not want to see printing times skyrocket :-)

[MarkusThur]

@RipperDrone I tonight also had those wired sounds. And some more thoughts on it. And now I see you print, which is pretty nice.

What I had is, I generaly use arcWelder in order to reduce G-Code Size and find curves are a bit nicer with it, then if cura decides how to square a circle. But yesterday I printed something with a lot of different curves, leading to slow down due to calcs not fast enough and then I got first time strange noises from the extruder during those slowed down curves. Then I printed same thing without arcWelder post processing, Problem gone. Maybe you can do something similar to increase or decrease CPU load.

So whats suggestion: -On a potential issue in code, am working on it, especially from creating visualisations of what happens, I found out that I not only sometimes had a "thinking" mistake.

• CPU Overload obviously causes it. Reduced speed improves that, so you may want to deactivate Lin_Advance by K=0.00 and see where you end up with speed and acceleration (and if i makes a difference). @thinkyhead there will be a difference between 8-bit and 32-bit systems.
• I (you may also) will check if Junction derivation instead of classic jerk does a difference. I asume JD needs more calc, so the extruder may get worse
• And last thing (or better first) check the mechanics of the extruder, especially the bearings. You may have a look how they designed it, especially the way the use the IGUS bearing. If those are in good condition the hemera really should run well and much better and less noisy than the full metal Titan clone I use. If they have wear already and higher tolerance this also may cause noise and replacing them is "pretty" cheap. The most expensive on them is the handling and transportation to you :-)
• somewhere (i think its in the code comments) I found a suggestion to reduce communication speed on the USB connection in order to get more CPU capacity for calculations.

[RipperDrone]

@MarkusThur Exciting - never used ArcWelder but found somewhere that it is not recommended to use it along with LIN_ADVANCE due to some alias / interference effects. CPU load is something to look into, however with my 32bit board and not overly complicated contours I'm not sure this is the direction to chase suspects - wierd noise even happens on a simple xyz cube! Which rather leads me into a direction of incorrect handling of accels / decels in conjunction with extruder feed + particularly extruder retracts. I tried to simplify the model in Windows 10 3D Builder (e.g. from 10k splines to 700 splines for model approximation), but the issue persisted.

• deactivating LIN_ADVANCE by setting K factor to 0.00 is worth a try, I'll do
• using junction deviation instead of classic jerk I tried once, didn't really help - priner was acting up quite similarly for both settings
• I have taken the Hemera apart completely once the issue showed up first since I suspected a mechanical issue in the first place. Full metal dual gears and bearings were in pristine condition, couldn't see anything abnormal causing wiggle / noise
• USB connection speed change is a completely new thought. I did play around with buffer sizes for UART communication, Marlin baudrate for SKR is at 115k default.

Will do some further tryouts at different settings and report back if any new findings materialize :-)

[MarkusThur]

@RipperDrone Where we are at the beginning point. :-)Something strange / unexspected happens. But I think it's good to talk about it. And once I am prepared, with the thoughts on how it should be, I will look the code what it does.

So from my suggestions only one stays for you, a tryout with deactivated LIN_ADVANCE as the others you already did. And for me, I have to get my SKR Pro running to compare the behaviour of the STM32 to the ATMega.

(hope we don't bore all that that are notified on this, but I have the very hope, this will create the right idea.) As obviously, getting LIN_ADVANCE, S_CURVE_ACCEL and JUNCTION_DEVIATION to work at the same time is the right thing for optimum corners.

In order to have same understanding what those options do I summarize, what I understood, they should do:

LIN_ADVANCE:

Reduces / Increases the nozzlepressure on accelrations / decelerations, as this is not a simple linearity to the movement, because of compression / decompression of material. Therefor it predicts the needed additional movement of the Extruder by the K factor.

S_CURVE_ACCELERATION:

Does a S_Curved acceleration profile instead of the "simple" trapezoid. This gives a more smooth movement, but is more difficult to calculate and predict. It's "unknown" how exactly the S-Curve is formed, but this is readable from the code. S-curved acceleration is a typical technic to get better movement profiles for all kinds of electrical motors, as the "impossible" dirac impulse on the change of accel, is not only transformed by the characteristics of electronics and mechanics, but by reducing it. This shall and does reduce resonancy and swinging caused by it. There is no "user influencable" factor to influence how the curve is formed at the moment.

JUNCTION_DEVIATION:

Is a concept how to approach / calculate the cornering speed for different corner angles, especialy corners that are not nearly a straight or a nearly a return. In short, it calculates a "ideal line through" the corner, where the derivation between real corner and the shortcut is the factor to be set. It calculates the maximum doable speed on the curve, by assuming that max accel equals max lateral accel. But then does not drive this line that derives from the "real" corner, just uses the speed calculated for the shortcut as the speed at the corner point. This should lead to exactly classic jerk on 90° corners if settings for max accel and JD are choosen right. larger JD leads to faster corners, smaller JD to slower corners. larger accel leads to faster corners, lower accel to slower corners.

[RipperDrone]

@MarkusThur You seem to be as obsessed with optimizing things as I am :-)

Tried to set K factor to 0.0 (has been @0.04 only before), and printer got completely silent in retract moves, even at high extruder retract speeds of 40mm/s retract and 45mm/s re-feed. Print speed still @100mm/s x-y. Accels 500, 500, 100. Jerks 10, 10, 0.3, 5. Retract set to .4mm which was optimum acc retract tower test.

Results of xyz test cube quite good, need to reduce z offset a bit, first layer needs to be more dense. Main challenge is overshoot at cube edges at higher speeds, this is why I tried to get my head around LIN_ADVANCE. Didn't find an effective way of really un-bulging the edges. Maybe choosing super-low jerk values could be an option, but then printing times become very long.

Getting a good combined S-curve mode working along with LIN_ADVANCE would do the trick, I suppose. Any other thoughts?

[RipperDrone]

Tried another run with halved jerk values, looks exactly same. Taking edge un-bulging to next level will require LIN_ADVANCE (and S-Curve smoothing), I suppose...

[MarkusThur]

@RipperDrone I continued testing and calculations during the week. Yes, Lin_advance shall and does remove the overshot on edges. if you want to reduce without linear advance, the trick is a "higher" Jerk. Using JD instead of Classic jerk also may help a bit, but Lin_advance is the trick inavoid the overextrusion in the corners. Now what I found, I could also make my extruder doing "noise" by having fast "direction" changes short after each other. But it was not directly the extruder, it was the fillament that started to vibrate like a guitar string. So I got a idea and did some calcs on what should happen, still without checking the code if this really does happen. Before I explain it, the summary in order to not force everybody to read the details:

1. Lin_Advance may lead to a retract.
2. If you change directions fast, this has to lead to a vibration of the fillament and maybe even more parts.
3. especially on direct extruders the movement of fillament imposed by the release and recompression acording to LIN_ADV settings maybe that short, that it is shorter than the Gearbacklash of geared extruders like the Titan or the hemera. Doing forward and backward movement shorter than the gear backlash, especially if done in short after each other must lead to "strange" noise.
4. a way to reduce that is already implemented by setting the XY_FREQUENCY_LIMIT in configuration_adv.h https://hydraraptor.blogspot.com/2010/12/frequency-limit.html It is intended to adress something else, but as a side effect also limits the frequency of the extruder doing the decompression / recompression.

What you could check please is, if strange sounds also occur, if you use Linear_advance but do not use S_Curve_Acceleration. From what I suspect the sound also should be there, but not that loud hearable. This especially with short and fast infill moves. Please there try also much higher acceleration values, maybe not the 3200 i use, but 1800 should be fine

Now the calculations to that: Asuming linear_advance, 1.75mm fillament, 0.4mm nozzle and 0.2mm layer high, 0.4mm line width, trapezoid acceleration and a printing speed of 50mm/s. and we do it for a K-factor of 0.04 like you have on a direct drive and 0.51 like i have on a bowden. and we will do it for 3200mm/s^2 and 500mm/s^2. For ease of calc, we will asume XY jerk infinite close to 0 and Extruder allowed to jerk as it needs. :-). We will use 400 steps/mm for our extruders instead of the 384 it really needs, also for ease of calc. fillament_feedrate(printing_feedrate) = (p_FR*0.4*0.2)/((d/2)^2)*Pi) = 1.667 mm/s = 665.2 steps/s the time to decellerate to 0 is:

t=v/a
t=50/500=0.1s
t=50/3200=0.0156s

the distance during the decelleration is:

s=50/2*t
s=2.5mm
s=0.391mm

therewith the volumina to be printed is:

V=s*0.2*0.4
V=2.5*0.2*0,4=0.2mm^3
V=0.391*0.2*0.4=0.03128mm^2

this needs a fillament feed of

feed=V/((1,75/2)^2*pi)
feed=0.2/2.405=0.0831503376154mm=33.26Steps
feed=0.03128/2.405=0.013004712803mm=5.20 Steps

for the decompression the k value says, you have to substract following from the needed steps:

deduction=k(v1-v0)*steps/mm
deduction=0.04*(50)*400=2*400=800steps
deduction=0.51*(50)=25.5*400=10200steps

both values are bigger than the needed extrusion, so it has to come to a "retract" during the break. and a additional feed during the following acceleration e.g. on a 90° corner or a return move like during infill.

5 - 10200 steps are quite many, and much more than the gearbacklash of the extruder, the stepper (with 1/16 microstepping) 3200 steps are a full turn, so it will do aprox 3 full turns backwards, this is a lot of movement. 800 - 33.2 767 steps to turn backwards, what is obviously only aprox 1/4 turn backwards only. A quarter turn back and fort in 0.2 secs should not make strange noise... as you say. But with accel 3200 the extruder needs to do a quarter turn back and forth in 0.03seconds. there we most probably will and do hear the backlash of the gearing. And now we do this fast on a short infill reverse moves. It has to vibrate. So it also should happen on linear advance without S_Curve....

And so I am more close to what exactly I should look at. Most probably, the "retraction" will not be done, where the decel starts and then the needed value will be feeded nor it will retract and coast to the end i asume. The idea, I would have is to linear share the retract over the distance. So retract the 10215 steps over the 0.015s, repectively the 767 steps over the 0.1s. And most probably it uses the actual moving speed to determine the extruder speed. and there we come where this can or should crash with S_Curve... while with triangular movement it will reverse at a constant speed.7670 steps / second. having to yerks during it. with S_Curved accel the speed should change during it. Doing a high retract, while deceleration is low and nearly no retract while decelleration is high. This depends, how the linear advance exactly is calculated. Both are able to make the "sound" louder.

Thanks a lot, as I now get a idea where to search.

[MarkusThur]

@RipperDrone admentment from observing my printer, now knowing, what I wanna look for: Higher Jerk leads to less / no retract from Linear advance. Slower speed leads to less /no retract needed. obtuse angles, need less retract, acute angels need more retract. I can even see this if I observe the movement of the fillament, as I with k0.51 can see the 25,5mm of fillament moving. your 2mm are maybe not even seeable

[MarkusThur]

@RipperDrone @thinkyhead After I changed my bearings on the Extruder today as I wanted to test something, I was "able" to produce "strange" noises with it on retracts. Or more exactly on direction changes of the fillament, independent if they are from Lin_Advance, a planned retract or a fillament loading / unloading. But the retracts from Lin_Advance happen "most often" so it's free first point to recognize them. So what happened: I tried and was successful in making my idler arm more powerful and more precise in reducing its clearance at the joint. At same time I changed the bearings of the drive shaft as they already showed wear. This together now leads to some kind of a "spring load and sudden release" effect, especially if I grab the fillament more tense for more grip, making exactly that noise, which is in principle exspectable on sudden direction changes. So from what I have now, there is no issue between Lin_Advance and S_curve, but a issue Extruders may have with "retract" in general. This issue should be there always when there is a retract... What I will look for now is, why it is more obvious and from my feeling louder on a retract caused by the combo of Lin_Advance and S_curve, than on Lin_Advance only. And what exactly of my changes in the mechanics of the Extruder made my Extruder start making the noise. But I think I already know what it is, I reduced the clearance of the idler wheel to much, so it comes to a slip-stick effect loading the spring of the idler. And then when moving finally releasing it. Causing the sound. Alternatively I didn't align the wheels of the gear (titan and hemera are geared) properly / changed the alignment a bit and the teeth jump over. (also would produce that sound). I will report on that. But in general, from what I found till now, I don't see a issue in the combo of Lin_Advance and S_curve_acceleration... (except that "improper" mounted or designed Extruders don't like retracts). But that's not a issue from that combo of options, only that combo may make the weakness more visible / hearable. From printing results point of view, Lin_Advance + S_Curve_Accel definitely give the best and fastest corners I ever had and those even should get better with Junction_Derivation if used right.

[MarkusThur]

@RipperDrone UPDATE: Got rid of the noise again. The reason was definitely that the drive shaft (in your case you have drive shafts on both sides) was not able to perfectly follow the retract moves. As I reduced its clearance by the new bearings and closing the case too tight. So for your issue you should make sure that you mount in a way that your drive shafts can move freely.

[RipperDrone]

@MarkusThur That's a lot of new findings, my sincere admiration for your endurance to chase this noise :-) Seems you are homing in on mechanical gear / gap tolerance settings. I can only state that my Hemera was brand new when the noise started (from Day 1 already), and when I took it apart, I checked that the gears could move freely but were sitting snug without any wiggle. It could actually be some close combing of drive shafts (and filament), and I agree it is stronger when combined with LIN_ADVANCE, but also happens on retract only IF retracts are too big in distance and/or too fast for the given retract distance. I'm still not 100% sure we are talking the exact same noise on our printers... to me the Hemera retract sounds like it is jerking in the retract moves, maybe it's even in the re-feed part of the move where filament can not be molten/softened enough at high feed speeds, so it chokes from trying to push solid material through the nozzle. I tried raising temps by 20K, didn't help, though...

[RipperDrone]

@MarkusThur found this video - noise is not recorded well and not exactly with the screetchy undertone, but this is exactly what I observe as well. Just a little more screetchy the faster I go :-) Is this exactly what you can reproduce as well? https://www.youtube.com/watch?v=8YDNU6U_mHg&ab_channel=RonnyVed%C3%A5

Whereas this is NOT the noise we are focusing on: https://www.youtube.com/watch?v=1ki-FwlVs7k&ab_channel=RichardGoiser

[MarkusThur]

Yes and no... We are definitely not locking for that noise from the second video. That one obviously is jumping gear wheels and a issue of wear or bad assembly of the Extruder.

The noise I could produce was a little more obvious and a little more "spring like" but yes exactly that. The noise in the first video is maybe even inside or short outside the limits for a fast retract and unretract move like Lin_advance imposes in every corner that is faster than XY jerk. And it will sound even more wired if this let's call it "clong" occurs two times fast after each other while approaching and leaving the corner. And it is definitely a issue of the clearance of bearing and drive shaft. Look at the video, you hear it two times before and after each travel move. And with Lin Advance you will hear it on every corner that is approached faster than jerk. This is the idea of Lin_Advance. You may even hold the fillament with your fingers a bit, in order to feel it.. The sound in the video may even be not produced by the Extruder, but by the fillament spool as mine e.g. With that nearly 20mm coming back reverses also a bit and then unreverses

This shot is from the hemera video of E3d. You see the two shafts, the Igus bearing and the normal bearing on the other shaft. What I did when I got that nose on my titan clone, I replaced the normal bearings by igus ones and then locked the face plate too tight. (in case of the hemera the cooling plate). This disturbed the clearance and alignment of the shafts and wheels. They have to have a little but not too much clearance.. Also wear on ball bearings or even the igus one may produce the sound.. So what I would try in your place now, as you say, your bearings look OK, is closing the cooling plate tight, but not too tight. That at least helped me to get rid of the issue again

From my view, the hemera must be even more sensible to that issue, as it has two pairs of wheels and two drive shafts that have to align properly and work together while having the chance of being canted or locked.

[MarkusThur]

@RipperDrone What exactly i did, was loosening and retigthening the screws while I was printing something with lots of retract, but that will not work for you on a moving head :-). So you should try if you can produce the sound with a custom GCode file, doing retracts and unretracts and then loosening and retighten the screws of the cooler plate.

[RipperDrone]

@MarkusThur Hemera has a no-wiggle transition fit roller bearing for the shafts, therefore tolerances should be quite precise. Anyway it makes sense that I might be able to slightly adjust the gear meshing tolerance (center distance) by losening and retightening screws under some gear load. Not sure I'm up for this after having disassembled it and put everything back together only 2 weeks ago... for now I found an acceptable balance of low k factor (0.02) and some higher retract speeds / accels so the noise is at least softened somewhat. Print results are good enough, overshoot still occurring, I'l trim jerk (if classic_jerk) or junction deviation (otherwise) a little more and will then try to make my peace with the remaining noise. At least until some new feature involving an S-curved acceleration comes up - sacrificing a little printing time for smoother moves and longer lasting gearing. :-)

[MarkusThur]

@RipperDrone It's not that much work, as you do not even need to disassemble it. Just make the fillament move forward and backward some milimeters at your usual retract speed , then loosen the screws of the cooler plate and tighten them again, while observing the produced noise. This way I am able to produce / get rid of the noise.

[RipperDrone]

@MarkusThur You got me triggered - I disassembled the Hemera fan, opened the 2 bolts from the cooler side, initiated some feed/retract commands to extruder, and while retracting / under load tried to slowly fasten the 2 bolts step by step. Then did trials. Whole procedure done 2 times, but as soon as I start prints with speed / feed+retract on the aggressive side, ratchet sound is back. Losening and re-fastening the screws did NOT resolve it permanently.

I agree there's a pointer to the tolerances of the extruder being involved, anyway I tend to believe this can be smoothened out with linear advance and S-curve type accel mechanisms. Anyway, will be a delicate balance, to get everything tuned in well...

[RipperDrone]

@MarkusThur Did another 1o1 test: xy speed 120, filament accel 2000, retract .2 @40mm/s.

k = 0.02 --> silent k = 0.05 --> buzzing noise at rectract events

xyz cube corners are still bulging thus needs higher k value. Seems to lead to jerking/noise, though.

Bottom line: Definitely has to do with some stall condition of retraction/re-feed of filament.

[MarkusThur]

@RipperDrone

Ok, now it gets interesting... So on the one hand side we now know, that part of the noises is the extruder itself.

On the otherhand we see that length and kind of movement also influences the noise produced. K 0.05 just meand that the movement of fillamant is 2.5x more than with 0.02.

This is interesting, as I till now asumed, that shorter movements (your 0.02 vs my 0.51) contribute to noise. Your finding now say ok, a least at "short" movements longer moves contribute.

We definitely know, that the code as it is now, does what we exspect it to do, but may beave strange on the limits of the functions.

We see, that there is room for testing different approaches how to exactly form the S_Curve and how to sync the extruderm to those speed changes. (adressing that stall condition of the fillament.) I "fear" that a good acceleration profile for a extruder is a bit different from a good acceleration profile for the head / bed.

We also clearly see, that the construction and assembly of the extruder influences it's capability to follow the moves imposed by Lin_Advance properly.

[badbod]

Ender 3 V2, BMG, Bowden, stock nozzle kit. TMC RMS mA 600 all round. Dual Z stepper drivers/motors.

Lin_advance on, JD = 5.4, s-curve off, loud clunkety noises at random on retracts if retracts Accel over 700.
Seemed to be the filament being rammed into nozzle. Hotend got longer as heat block screws made their way out., and grub screw fell out of extruder inner gear (not the gear on the stepper). Got worse in spreadcycle. below retract A 700 reduced to consistent quiet tap sound. Nice squeal from BMG as Lin_Adv did it's thing, though that has now vanished (BMG run in?)

As above but disable JD Jerk 7, 7, 0.3, 5 Now can use retract A 800 before random loud sound. Guessing accel 800 is not being hit by Jerk? played up to 10 and down to 3 without any change though

disabled Adaptive step smoothing. hmm, much quieter, still pipes up at 800 A, but much quieter all round. disabled square wave stepping, that just removed a pattern I been getting, I thought it was belt rubbing somewhere, turns out to be this square wave causing a ribbed pattern on the prints. It changed sensorless homing quite a bit too. Didn't do anything for the noisy Lin_adv.

Looking at corners to get them sharp without ringing then Jerk and JD values cant be changed or no point printing.

retracts tested down to 1.5mm without affecting the retract A loud sound commencement value. TMC mA up and down, no change.

Retract speed mm/s tested 25 -80, 25 works best for me but no change noticed in noise. Print at 80mm/s or 20mm/s no change apart from walls quality goes off a bit ~50.

Generally I am happy with Jerk and stealthcop for now. and sticking to retract A max 800. retract length is 2.5mm and no stringing. if I up to 1000 A I can go down to 1.5mm retract but the noise,, aaarrggg NM.

Not tried, S-curve or, JD and playing with Jerk_e value. Cant edit jerk_e run time with JD so much more involved testing for that. (need to check that)

Due to 3:1 extruder I was wondering if it is massively missing steps at high A as it just cant keep up? but then how is it slamming the filament in to the nozzle, or is that just a sonic boom? Maybe it is the extruder making the noise, as the grub screw made it's way out then started slamming into nozzle? sounds the same after fixing it all up though so dunno.

Ill change to another, I got a few different not geared , try dual drive I think, open too so should be easier to see whats going on with it.

Ill follow with interest, and let you know if I find anything that might be interesting. Gonna play with CR-10 Smart now, see what limits that reaches before it all goes bang.

[MarkusThur]

I will read your report later.. But thanks for it. @badbod ... Am pretty sure you are at the "mechanical limits of your BMG, but will look at it closer later. In principle your extruder is fast enough, if it can accelerate 1/10 of the acceleration of your heads.

[badbod]

Can confirm, changed to dual drive non geared 1:1 and all noises went away. I don't intend on going over 1000 A on E , in fact for stringing 700 seems about right, slightly less for PETG, much above or below and stringing starts to appear. I get no stringing at all with retracts @2.5mm, 25mm/s, 700 Accel

tried with S-curve, but added bulging corners and no amount of jerk or accel whatever I tried seemed to affect it at all. Did cut down the vibration and was printing 80mm/s using gyroid infill real fast. Disabled due to bulging corners though.

Jerk all 10 at the mo, started to get an error on compile with bugfix if set less than 10 for DEFAULT_EJERK, however works fine and nice sharp corners.

Now if I can just get this PETG to stick to the bed on first layer,,,, T0:250C fan:0, bed:70C tried blue tape, pei plate and plain metal (wrong side of PEI plate) first layer is a pain. Should fan really be only 10% for entire print ? Any higher and it a nozzle ramming fest. Prints are fine @10% fan if I can get the #!#@$$! @#!##$ !@$#@# first layer to stick.

[MarkusThur]

@badbod, yes this mostly fits to what I already did see.... Bulging corners main or I even tend to say right "coutermeassure" is Linear_Advance. This reduces the pressure in the slower corner "exactly" the right amount, but needs the extruder in most cases to retract. being faster in the corners "higher jerk" improves corners also / reduces the need of retraction while keeping high print speed. But it is limited by the "jerkability" of the mechanics, which is influenced by the strength of the construction, the proper setup of it, the strength of the stepper motors and drivers, the material of the belts, the precission or impression of the bearings, the weight of bed and head, type and quality of the couplings and and and. The mechanical "resonancy" of the system in total. S_curve_acceleration is a way to accelerate and decelerate more smoothly, which can lead to a higher "jerkability" and also in more reliable fast acceleration as the a part of the mechanical and electrical "load" / disturbance a acceleration or deceleration causes is smoothed away by the profile and is not needed to be smoothed by the mechanical or electrical components of the system / is not converted in vibrations. But s_curve itself does not improve corners. (except by the less vibration aproaching / during / leaving it). Finally Junction derivation is a more smart way to determine the fastest possible corner speed in amore smart way than by just using accel / jerk to determine the needed speed change in a corner. with a correct set junktion derivation your print is faster at same quality as it would be with proper Jerk / acceleration settings in classic jerk. This all counts as I exerienced as long as your Controller chip is able to do the necessay calculations in time. With all this knowledge collected, I am atm in the process of reviewing the code if there is a aditional "unintended" interference between S_Curve and Lin_Advance... @badbod Am sure the "extruder" is capable to do even more, but the value you did choose here or observed to be good for stringing, fits inside the overall system.. On a 0.4mm nozzle with 0.2mm layer hight and 1.75mm fillament, the ratio between print speed and fillament feedrate is just 3.33% of the print speed. with a good reserve, for bigger nozzles and so on, it is absolutely enough if your extruder can go 1/10 of the feedrate, acceleration and jerk your head can go. for loading, unloading and retraction you may can give free higher values as long as your extruder can deal with it. As you changed to a ungeared dual drive your values observed sound pretty logical. A non geared extruder compared to a extruder geared 7:1 in theorie should loose acceleration capability 7:1 and should be able to go 7 times higher speed than his brother. Both are theoretical, a ungeared will not be that much faster for other reasons, and the geared one will not accelerate that much faster due to transmission friction. But your found values 100% match what I observed till now. I assume you could retract faster but not with more accel. assuming you are using Linear_Advance I'd suggest to recheck your Lin_Advanced K-factor and your temperature as 2.5mm retraction with linear advance are a little much. without Lin_advance 2.5mm on a direct drive are fine, on bowden a bit short I'd say, but inside the normal

[badbod]

@MarkusThur Yes, lin_advance, bowden ~500mm K 0.62, I have not played with speed of retractions, only acceleration. the 25mm/s was without lin_adv and seemed to provide a sure fire no string even on long travel. so I have been sticking with that for now. without lin_adv is 6.5mm retract, and while I had it setup as direct drive I was using 1mm without lin_adv, but shifting even the modest weight of a 20mm nema around which was only just powerful enough on a 3:1 BMG, so I thought it more hassle than it was worth cos had to slow down so much to stop ringing etc. Ill look at direct drive again when I get my hands on a super light weight type, maybe an orbiter? For now though , bowden with lin_adv still gives super quality and great speed.

Ill try playing with the retract speed see if I can get it lower, I can run 1.5mm with no stringing but long travel gives a weak start. It is obviously oozing out somewhere, just dont see it as strings. Maybe, now I have a bit more scope with acceleration, I could find a lower retract but 2.5mm is still good for 500mm of bowden :-)

from 410 steps to 93 steps, (how is that 3:1 ? who did the math on that ?) hmm, well, I think any loss of resolution is not an issue here, and given that all the tapping and the loud banging at >700 accell , whether it stepper driver/motor/MCU or the extruder, that's all gone now at up to 1K as I have tested. I don't know what the upper limit will be, but I guess 3x700 so maybe 2K+. Wonder how that will affect the CR-10 Smart, with it's stock 6K accell on E ? Does not matter, if the sweet spot is ~700 when running at 80mm/s then it is well within the capabilities of the hardware now rather than riding on the raggety edge.

Yes, I was not thinking faster, rather slower, in terms of number of steps required. Seemed like I was hitting a hard wall of steps. was already running the extruder stepper at 650mA , maybe could have tried a bit more, se if that changed anything? hmm, rather not push it that way. Probably another limit somewhere anyway.

[badbod]

back to the point though, with S-Curve enabled, nothing I did seemed to affect the bulging corners in any way, print speeds, acceleration jerk, all had no effect whatsoever. I will try with JD next see if all the banging about has gone with that too. If so then ... last I tested JD it did nicely control the S-curve bulge.

[MarkusThur]

@badbod I think I missunderstood you, or you me... :-) S_Curve_acceleration itself can't do anything about corners bulge... It can help reduce ringing / vibrations before and after a corner. And it can prevent loosing steps while accelerating / decellerating at values close to the mechanical limit. So paively it helps with bulge also, but not alone. The thing that helps with bulgy corners is: Lin_advance as it directly adresses the source of the issue. (the old approach was coasting :-) but there you really need to tune a lot and have to adjust to everything, fillament, form of object, print speed, and and and). Calibrating the extruder as overextrusion increases the Overpressure causing it. And indirect improvement: -Higher corner speed by higher jerk / proper JD Value -less time in corner by higher acceleration. both at the cost of more ringing. what can eat the winnings from it regarding bulgy corners. and double indirect: S_Curve_accel as it can reduce the ringing that was caused before by the higher acceleration.

So working on S_curve_accel does in no way help you vs bulgy corners. It helps you with ringing you may have caused in the process of getting rid of bulg... You are adressing the issue from the back

[badbod]

It caused them, with S-curve enabled large bulgy corners, without it nice crisp sharp corners, Could not seem to do anything about it, no matter what other settings I tried to play with. I use S-curve when not using lin_adv but always with JD and have no problems, but with lin_adv, enabling S-curve gives me the bulges I cant get rid of unless I turn it off, Have not tried using JD since changing extruder, will try it with JD, so lin_adv, JD and S-curve, might be s_curve and jerk not playing nice together? I always use jd and S-curve when not using lin_adv. Turned JD off for Lin_adv as couldnt get E retract A up above 600 using the geared extruder with JD on. Should be fine with the non geared I think

[MarkusThur]

Ok, if S_Curve is able to produce bulgy corners, you really should go back some steps... And may confirm your basic settings without the advanced stuff first.

Ignore the Z-Seam, and in yellow the landing noses as I was redujusting the retract:

but yellow, without S-Curve, and a bad Lin_Advance setting: grey with proper settings for those things: And yes no.. We are investigating a possible interference between S_Curve_Acceleration and Linear_Advance. I am using high jerk values as high as 16 and accelerations at around 3500 with S_Curve, Lin_advance and Classic Jerk, controled by a at2560mega with TMC2208 steppers in Step/Dir mode. But especially printers that obviously cant go that high values seem to have a interference issues, as well as this causes high load on the at2560mega and on the TMCs also, which needs both to be cooled properly. (I tested by reducing the cooling and got some interesting effects, including unexspected speeddowns and uneccessary lost steps.)

I still did not hear you telling about Linear_Advance... And presumably, at accelerations low as 500mm/s^2 S_Curve_acceleration may have a negative impact on bulges in corners, if i think a second time about it... Think of it as the driving school like soft degressive breaking at a red traffic light, short before the stop line, your car stays a long while in that area, especially if you then also softaccelerate. Totally different if you do it "pitstop style". Then the passengers will be shaked around, but the time at the stop line is very low.

Now we imagine our car is loosing a bit oil... this will cause a big oil blub at the stop line, if the oil pressure is not reduced.. (what exactly happens without LIN_Advance...) and may even be bigger, if you do it driving school style instead of pit stop style and a weak break.

But if the oil pressure decreases with the rpm of the engine (what in this model lin_advance does), the nicest and fastest line will be drawn by lin_advance with S-Curve, if there is no sideeffect between them.... and the values for K-factor, jerk and acceleration are set to the maximum acceptable, to not make the passengers vomit or cause the car to slip by blocked wheels :-)

So you definitely should: Calibrate your extruder (set the hole in the oil system to the exspected size) Figure out the highest acceptable acceleration and jerk for your system, without mechanically overloading it (not using Lin_advance or S_Curve.. just classic jerk and accel) then activate and calibrate Linear_Advance... If your accels are low, you may not even consider activating S_Curve anyways, but u may, if you feel, that you have slight ringing that you want to get rid of, or can increase accel and jerk by it. Then try if you may even get better results with JD instead of classic jerk... (it should be a bit faster in total, but not really nicer) nd yes as from the car "model" S_Curve can be counter productive on low acceleration and jerk values..

nevertheless I have something to investigate iot to find the possible interference between S_Curve_accel and Lin_advance... Atm I asume that S-Curve may not calculate a well shaped S-Curve / a helpful S_Curve. You may have a look at the S_Curve I linked before... In a worst case, a bad shaped S_Curve accel would jerk, then slow accel, then jerk again, then slow and slower accel and then move continously... Imagine a driver accelerating or decellerating like that...Passengers WILL complain.

[badbod]

yes, with that extruder setup making loud banging noises, obviously misbehaving, seemed to be doing infinite accell reversals randomly. Did not see any vibration or ringing while printing from 20 to 80mm/s, 1000 A accell on X/Y 175mm/s travel., so was moving round pretty darned quickly too. Just E misbehaving around retracts. Quality of print excellent.

this board is LPC1769, with 2209 drivers. and it certainly does not seem to handle retracts with high accel and lin_adv, dont know if cpu or drivers, have a fan on them, but heat is not the issue here, shouldnt be mechanical either cos it can pull 6000 accel all day on the same BMG without lin_adv. wierd full tilt infinite accell reversals starting at relatively low retraction accell. Food for thought?

[MarkusThur]

Definitely food.. The TC2209 drivers are even better than the 2208 regarding the accel and so on... Especially they accept a little more load with same cooling needs. But I have two questions imediately.. UART or Step/Dir mode? Configured in Marlin as TMC respectively TMC_standalone. or with standard timing setting for the slower A4988?. Interestingy the issue may also be in TMCs in UART mode... If we asume, that the Serial comm has to send a lot of data to the X,Y,(with mesh bedlevel also the Z) and the E driver on a scurved, lin advance, mesh leveled corner. If I find nothing else, I will investigate that direction also... So it may could be a interface overload also :-) last but not least, could you recheck the settings for Ejerk, EAccel and EFeedrate?

[badbod]

UART mode, stealthchop,, no hybrid, no square_wave, no adaptive_step_smoothing. changing mode to spreadcycle or using hybrid only seemed to make it worse. UBL 10x10 mesh fade 10, I notice the Serial speed is set to 19200 in pins for the uarts, says for reliability in comments. I tried Jerk from 5 through to 15 one at a time then in pairs then all as a set. did not seem to make any difference. Some wierdness with s-curve producing bulgy corners , and running through all the settings etc made no difference at all, enabling JD fixed that so looks like jerk was being ignored (bugfix branch?)

[offtopic] hehe , reworked my setup a bit yesterday, I didnt like the bowden coming through the frame. It was interference fit at best with the added 50mm on right for BLTouch full bed coverage. Tubes a wee bit longer now, but not much change to cal so all good

[/offtopic]

[MarkusThur]

Thanks a lot... I will keep that 19200 in mind,when reading it. Atm just from a feeling, this could be part of the issue. As well as that JD fixed it. I think JD is the better approach anyways, even it is hard to optimize JD setting, without knowing the "jerkability" of the system. So from what I have seen till now, there is something like a interference issue.

Could you try to set a higher communication rate to see if this fixes the problem also? Keeping in mind, that faster comms = higher processor load, wich means it could have other side effects, like slowdown because of calculations not ready in time?

[badbod]

wow, long delay, sorry. I am testing out the Creality all metal high temp hotend, and moved back to direct drive with a metal mount and larger stepper motor (42/34) to accommodate the all metal non geared extruder. hopefully by Sunday will be printing with it. I should be able to report back with some results on the baud rates and feature combinations as soon as I have the hardware change dialed in.

[MarkusThur]

No Prob, I also got quiet a while... High workload and reading that code.. From what I see till now, there is no "mistake" in the code. From what I found it does what it should do / leads to retracts before corners depending on the speed change involved.

[nefelim4ag]

https://github.com/Klipper3d/klipper/commit/acd165cbea2f48812b7fd96c28b81622e5c13665

Klipper have some sort of duct tape for TMC2208 and PressureAdvanced (LinearAdvanced)

[ManuelMcLure]

Klipper3d/klipper@acd165c

Klipper have some sort of duct tape for TMC2208 and PressureAdvanced (LinearAdvanced)

Klipper does most of its calculations on the much faster processor of the Raspberry Pi it runs on. Marlin doesn’t have that luxury - it needs to be very lean and mean. Not to say that it can’t do a better job than it currently does, but it’s unlikely that the Klipper solution will work on a printer board.

[nefelim4ag]

@ManuelMcLure looks like they just accounting steps for extruder and just check no step-dir-step in 1ms window, no rocket science in theory just need some hacks in planner and time and flags. Not look like rocket science or a high calculation load.

As someone already does some strange stuff around MINIMUM_STEPPER_PULSE & etc to try to avoid that problem, it is just enough to not send any signals step signals after dir for extruder as a workaround for some time like 0.1 ms.

(I'm not sure how reliable that can work of course because I'm not aware of planner arch in marlin) or just allow users to change stepper pulse for extruder by separate flag may be...

[MarkusThur]

OK, this go very long now and I still didn't have the time to setup my 32-bit processor due to personal reasons.. (may call it lazy :-)).

I try to summarize here in some short words the findings:

1. S_Curve + Lin_Advance does what it should do
2. Exactly this may cause issues (unhealthy noise of the extruder) as some setups may not be able to follow the imposed movement "step - change direction - step" for different individual reasons, which even may overlay. 2.1. "Gear Slip" from mechanical "weakness" on geared extruders. 2.2. Motor Overcurrent may occur, this should affect non geared extruders and / or TMC2208 mainly. Especially as 2208's tend to run at their (uncooled) current specification limits already in typical printer setup 2.3. Step - dir -Step commands come in a too fast to be processed correctly by the TMC 22xx drivers, this should affect geared extruders mainly, as those need exactly the gear ratio more steps / faster steps. 2.4. Main processor not able calculate / send the steps correctly.

Suggestion:

• As the "Experimental S_Curve" Flag just does nothing more than to allow this "risky" setting, it may should explain the risk it imposes better in the comment as by this findings.

• the idea presented by @Nefelim4ag and @ManuelMcLure can get rid of it I think, but reviewing the Klipper solution i think this can be achived much more easy with following idea in mind:

First find the smallest time window that allows a proper step - dir - step (this maybe different for different drivers / processors and extruders), so this maybe a configurable value.

Then when finding a "step - dir - step" event that is faster than the window, just impose a step lost on that two steps and don't send em. On nongeared extruders this may never happen, on geared extruders the imposed missbehaviour sould be acceptable :-). Let's try to calculate the impact :-).

400 steps / mm equals 0.0025 mm/step, when ommiting the steps the material wil not flow forward 0.0025 mmand then not retract 0.0025 mm. This should give the wanted presure reduction also and should not be negative for the print. Your print will in worst case miss 0.006 mm^3 of material :-)

[tombrazier]

I am working on a solution to this problem. I think it's not too hard to add to some other LA changes I am working on. Main challenge is frguring out how to change some highly optimised assembly code without breaking it.