[FW 3.5.2] High jerk good for circular path not for corners
-
@Notepad I am using last stable version from Dec. 2024 (I think it was December).
Yes I will jump into the beta version. I read that the modulation of nozzle temperature depending on flow has been implemented. I have been doing experiments with varying temperature during the print using a postprocessor script and believe me, that is a great feature.
But I will have to update the PanelDue firmware first.
-
@gloomyandy Perhaps you are drawing wrong conclusions from lack of participation of other developers. Some of them modify the firmware for their particular interests, so they just do their own thing and don't care (my speculation).
In any case, mortal users would definitely welcome that kind of adaptive jerk.
Let me try to emphasize. I don't know how to explain my point. Haven't you noticed? Half a world of 3d printing people is talking about things like pressure advance, retraction, flow, speed and acceleration - the key elements to control for a succesfull print. With junction deviation (or something similar) one more advanced mechanism would enable to get rid of defects commonly found everywhere.
Klipper is becoming overwhelmingly popular and is considered the firmware of choice for ambitioned users, but every time I check and compare to RRF I have come to the same conclusion: no reason to switch, and RRF is more polished and reliable.
Until now. Why this adaptive jerk has not been done after years of RRF development... I can't understand. In my naivity, I was even asuming there is some gcode command to tune that, but no.
In my particular case, my prints tend to come out flawlessly, except I get caught by the jerk dilemma. Either low jerk and jerky, stuttering curves with artifacts , or high jerk with smooth, uniform curves but visible ringing around corners. I am constantly changing jerk settings, depending on whether the model has many corners or many curves... Seems not acceptable to me after the underlying factors have been clearly understood. Roughly: Next segment moving in same direction? High jerk! Otherwise: Low jerk! That is not rocket science.
So again, the impact of this feature is not trivial. It is not just "nice to have" but a plain necessity.
Sorry if I my statements are too blunt.
Right now we can see how a certain proprietary printer brand allows itself to treat their clients as slaves, but only because they did many things just right and conquered the market. Open systems, to which Duet3d belongs, can and should perform better.
I said what I said. Let's paint the town red.
-
@Triet Just to clarify, I do not work for or have any direct association with Duet3D. I am the main developer for the stm32 port of RRF firmware and in general I try to keep that code as close as possible to the Duet3D version (particularly for things like motion control). As such I have no direct influence over what goes into the Duet version of RRF firmware. If you wish that version to change then you need to convince @dc42 or @T3P3Tony that this is an area that needs attention. These things typically come down to time and priorities (and to some extent interest), we have all been busy working on changes in 3.6 (which have been pretty major), to some extent we are still catching up on the that in terms of understand how this new code interacts with things like jerk, PA etc. As mentioned above the changes in 3.6 over a big improvement in terms of ringing and I'd encourage you to test that version.
Also I'm not sure that the way that Klipper handles jerk is really much different to RRF, it may be a little smoother (see my tests above), but it is not fundamentally different.
-
@gloomyandy Gotcha. Let's hope @dc42 or @T3P3Tony are reading this.
I will try the last beta and report. But I would rather avoid resonance vibrations by fighting their cause in the first place, better than trying to compensate them.
It is my understanding that junction deviation takes the angle of movement change into account in order to calculate and apply the jerk value, and RRF does not do that. For me, that is an essential difference (caveat: I am not very familiar with Klipper, I just try to assess its advantages).
-
@Triet Your understanding of what RRF does is not correct, it does take the angle of the junction into account. You can see the RRF code here: https://github.com/Duet3D/RepRapFirmware/blob/3.6-dev/src/Movement/DDA.cpp#L1082
As you can see it uses the direction vector of the two moves to calculate the jerk for each axis and applies the configured jerk limits to this.
You can see this in action in my previous post: https://forum.duet3d.com/post/345258
For the square the velocity at the junction is limited to 8.33mm/s, but for the circle the junction is limited to between 60 and 90mm/s, so the junction angle is clearly being used to limit the junction velocity.In the above case Klipper would limit the speed at the corners of the square to 5mm/s while limiting the junctions on the circle to 72.5mm/s. There are differences between how Klipper and RRF handle junctions (see my previous posts for more details), but I don't think they are as big as you think they are.
-
@gloomyandy I have to believe you, anything else would be my blatant arrogance. At the same time, my experience with the firmware release 3.5.4 fails to confirm that.
The resolution of this contradiction is simple. I will install that beta version right now. I will let you know the outcome.
May I assume then that the feature as you described it will be in the next stable (official) release?
-
@Triet said in [FW 3.5.2] High jerk good for circular path not for corners:
May I assume then that the feature as you described it will be in the next stable (official) release?
What feature?
-
@gloomyandy The angle dependent jerk.
-
@Triet That is already present in RRF (and pretty much always has been).
-
@gloomyandy That implies that this thread, including your postings, are senseless.
Let me quote @leone :
"I am doing some motion tuning for a quite big and heavy machine. In general I noticed that having high values of jerk (about 500-600 mm/min) are good enough to travel circular paths smoothly (even tough it depends a lot on the mesh quality), but they are a bit high when printing corners"This is what this whole discussion is about: Same jerk values don't fit well in corners AND curves, and should be made adaptive. This is exactly my concern, as I explained. You can read the details above.
So I cannot follow.
-
@Triet, what @gloomyandy correctly explained is how the jerk is implemented in RRF 3.5.x and also 3.6 betas. The jerk set from the configuration is the max allowable speed change that a specific axis can do between two consecutive moves: RRF checks the components of the direction vector between two consecutive moves to understand how much each axis has to change in speed, if this change is greater than the threshold (jerk), then the threshold itself will be used.
What I proposed as adaptive jerk meant to change dynamically this threshold, based on a non linear relationship with the direction angle. It's one layer of logic above what RRF is already doing, maybe something like "adaptive MAX jerk" would have been more clear
I actually paused this investigation because the results I got with the 3.6 betas and the new input shaping are very good and fixed most of my issues.
I can confirm that find a reliable logic to implement here is more difficult than it might seems. Maybe in future I'll give another chance to the junction deviation or the "adaptive MAX jerk" on top of 3.6 to see if there are real benefits. -
@leone @gloomyandy @Notepad
I installed current beta version and am reporting my findings as promised.
After installation I got this message, which I surely can ignore for the time being:
Let me anticipate that I repeated my problematic print using Version 3.6.0-beta.4.the result was:
Artifacts just disappeared, curved walls are printed smoothly even at low jerk values of 5 mm/s.
Look at this picture (it is just a horizontal section of the real model used as a test): Version 3.5.4 on the left, beta version on the right side:
It is an extreme case of vibrations that could be only partially mitigated by high jerk values. Other measures I took in my desperation (checking the toolhead, belts etc.) might have helped too, but no doubt - this firmware version is the solution.@leone Now, just to learn, I would like to confirm that I understood how jerk is handled in this beta version.
If I set a jerk value, it will not always be applied 100%, as it represents a maximum value only. The actually used jerk will be calculated based on current speed and angle conditions of every two consecutive segments and will be smaller in most cases.
Accordingly, the jerk used in curves with wide radius composed of segments with same speed will be higher than the jerk used in similar curves with smaller radius, as the segments in the later ones are angled higher.
Jerk applied in square corners will be even smaller.
Cases where the direction is reversed will have a minimal jerk value (physically, the print head will come to a standstill at some point).
If all this is correct, from now on it should be considered a good practice to set a jerk value that is just high enough to cover all cases.Correct me If I am wrong please.
A "special" case comes to my mind now, where segments are in a straight line - that happens when flow based acceleration/deceleration is defined in the slicer (this limits the flow change rate, but not based on movement speed alone). So here we often have consecutive segments that do not change direction, just speed. I assume then that if the speed difference is lower than the maximum jerk set, no jerk considerations apply, that is, the speed will change suddenly while trespassing the junction - but I am possibly wrong and steppers will always consider a junction to be a stop point, applying jerk. Feel free to say I have no notion about how steppers work.
Thanks so far.
-
@leone Let me add the following:
below you will see a test model consisting of two connected half-circles, where the outer one is part of the original model, and the inner one was added by me as a part of a cylinder in order to compare.Using firmware 3.5.4, the outer curve was printed with jerky movements, and the print was showing vertical ripples. In this case though the ripples were caused by the model itself, as it is coarsely facetted - you can even recognize the straight lines building the outer curve. I just disliked that the printhead was stuttering. On the other hand, the inner half-circle was printed smoothly, no matter which jerk values I used; its resolution was way higher. All in all, everything was printed as it should, with the exception of the apparent small stops at the junctions of the outer circle, which was causing jerky movements, but the half-circles were printed both OK.
Now using 3.6.0-beta.4 firmware version, even the outer half-circle is printed smoothly! I mean, there are no jerky movements anymore, but what is more astonishing: the print itself shows no vertical ripples anymore!! (But it should, actually). It is printed as a perfect curve, although it is not! No facettes are recognizable at all. In other words, some kind of smoothing of the surface took place (but looking at the gcode, no arc fitting was applied). I would say, this firmware is "cheating", but in a positive way. The print was improved beyond any expectation.Shouldn't that raise even some fidelity concern, I am asking myself now
Let me express the kudos that @dc42 and developers deserve. Version 3.6 is going to be a big throw indeed. I am perplexed.
-
@Triet the smoothing is a side effect of effective input shaping.
-
@Triet said in [FW 3.5.2] High jerk good for circular path not for corners:
which I surely can ignore for the time being:
please upgrade all the firmware and software in the system to the same beta version.
-
@T3P3Tony said in [FW 3.5.2] High jerk good for circular path not for corners:
please upgrade all the firmware and software in the system to the same beta version.
Thanks for the remark.
This is what I did: I downloaded Duet2CombinedFirmware.bin from
https://github.com/Duet3D/RepRapFirmware/releases/tag/3.6.0-beta.4
and installed it as usual, but I saw no files being extracted as it usually happens, and the printer was shutoff sooner as usual.
I am using a Duet 2 WiFi board which was at 3.5.4 prior to updating the firmware. After switching the printer on I found:
Perhaps something went wrong. What may I have done wrong? What is still missing? Isn't that package complete also as beta?
I was assuming that because it is just beta only a partial update should take place, but apparently this is not the case.
Should I repeat the operation?By the way, since I am using this beta version the PanelDue freezes the nozzle temperature display at 186.3 deg C when cooling down after the print, but it looks like a pure display issue.
-
@Triet You also need to update WifiServer.bin and DuetWebControl-SD.bin.
-
@tas You mean DuetWebControl-SD.zip for sure.
Now that you make me look at the file types, I realize that a bin installs differently than a zip (of course), which is why I didn't see file extraction happening. Thanks.Done:
-
@Triet Oops! Yes the zip file. Glad I could help.
-
@Triet said in [FW 3.5.2] High jerk good for circular path not for corners:
I downloaded Duet2CombinedFirmware.bin from
https://github.com/Duet3D/RepRapFirmware/releases/tag/3.6.0-beta.4
and installed it as usual, but I saw no files being extracted as it usually happensBeta versions of the firmware are not packaged together as a single zip file as the main releases are.
