[FW 3.5.2] High jerk good for circular path not for corners
-
@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.
