-
-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Junction velocity limits: sharp corners and smooth traversal of circles are mutually exclusive #4228
Comments
Here's a video showing stutter at 90 mm/s, 5000 mm/s², scv=5: The audio is the most telling - those are rapid pressure advance moves. Here is the file: klipper_scv_test.gcode.txt It lacks any Since all junctions in the whole print have the same angle, you can see the effect of my solution just by increasing scv by 16x (or just 2-3x). Lowering the speed factor to 50% eliminates the stutter as well. Visually (I'll add a pic soon), the 50% speed and high-scv versions (without the stutter) look more similar while the stuttering version has pronounced extrusion difference at the junctions. |
Also following up with some notes from IRC where @KevinOConnor raised some good points (which I hope I've paraphrased ok):
In particular, I computed, a 10° turn at 200 mm/s is only a 3 mm/s instantaneous slowdown along the original direction of motion, but it's a 35 mm/s start in the perpendicular direction. Part of the problem here is that the scv limit may be reflecting either some hard limit of the machine (when users set it very high, like 25-100, for speedboats and such) or a threshold at which print quality problems become unacceptable (when it's set according to the input shaper recommendations, for example). In the latter case it's almost certainly okay to violate it for the sake of improving quality of slight turns (and print time). In the former, it's less clear, but I think it would take a really large print with really high acceleration limits in order for the centripetal velocity limit not to come into play here and sufficiently limit the cornering speed. If it does end up being unacceptable to phase out svc limits at slight turns, the other potential way to address this issue is to suppress the acceleration. I think this can be done by deducting the arc length (or some approximation of it) from the junction deviation algorithm's "virtual arc" from the length of the move, and limiting the max cruising v² for the move to the max starting v² plus the v² obtainable from accelerating the remaining length of the move. This is roughly the fix I already want to make for the corresponding stuttering issue that the centripetal velocity limit can cause, and there's something to be said for using the same fix for both. |
Thanks. Can you also provide the klipper log files from your test prints? (I'd like to know the software versions and configuration.) -Kevin |
I am not sure how you came to that conclusion. According to the formulas you quote (which, I believe, are correct), |
@dmbutyugin, those values are in units of velocity squared. Once you take the square root, you get my factor of just over 10. As for whether a 36-gon is a decent approximation of a circle, I'm not sure, but most real-world models people try to print use fewer segments. The OpenSCAD default |
Right, my bad. Well, that formula is based on the concept of virtual acceleration. So, the toolhead supposedly will experience the same acceleration turning 10 degrees at 50 mm/s as turning 90 degrees at 5 mm/s. I'm not sure if it can be compared to centripetal acceleration directly, as centripetal acceleration is continuous, while this is just 10 points. But in principle, that's just a model. Maybe it is a good opportunity to improve Klipper motion planning and choose some different model instead. |
Right. My point in making the comparison was to highlight that, interpreting the 36-gon of diameter 10 as a circle, you'd want to traverse it at 122 mm/s given a 3000 mm/s² acceleration setting, but scv=5 is limiting you to much lower speed (in addition to possiblt making the speed oscillate rapidly, depending on your acceleration settings).
I think the current model is largely successful, but just has conflicting undesirable behavior in opposite extremes when you take it to moderately to very high speeds and accelerations. Maybe some sort of curve fitting model would do better here, but it's a very big change for the sake of improving something that I think can be improved comparably with much less work. Moreover, I'm not 100% sure, but I strongly suspect the result of doing what I'm doing, then applying input shaper, produces very similar step results to what you'd get with fancy curve fitting. |
@KevinOConnor OK, I'll run some logs again when I have printer idle and a chance to revert patch and test. |
Well, there are 2 parts of that junction deviation model. One part is the principle that the velocity of traversing the angle For example, let's assume a cartesian printer, that prints 90 degrees angle by first going in the direction (1, 1), and then (1, -1) after the angle. Let's assume that the velocity for both moves was set to 5 mm/sec (==scv). Then the X axis will move at the same constant speed of 5/sqrt(2), and Y axis will first move at the constant speed 5/sqrt(2) in the positive direction, then abruptly change its speed to -5/sqrt(2). This is how the junction deviation model will pass this corner. Now let's assume a different scenario - the toolhead moves in Y direction, and there is a 180 degrees turn on Y axis. Let's assume that the speed for both moves was set to 5/sqrt(2). In this case, if we use the junction deviation model, X axis does not move at all. Y axis, on the other hand, starts at 5/sqrt(2) speed, decelerates to 0, and then accelerates to -5/sqrt(2). Note that for Y axis, the situation is not different than the previous case - physically, the printer could go at 5/sqrt(2) speed, and then abruptly change it to -5/sqrt(2), as what happens in the previous case. But the junction deviation model does not allow that and requires the printer to come to a complete stop at the angle, which slows down the print. My point is, this model has its own hiccups. Generally, the function One simple alternative that I could think of is a momentum model: we may want to fix how much momentum a printer can instantaneously take from a toolhead to change its direction. For a turn Below is the chart that compares the two models: Incidentally, for I find it very interesting that the two models that are based on very different physical principles give very close predictions. Unfortunately, that increases the confidence that the current model is working correctly: contrary to your desire, it is indeed more "difficult" for the printer to turn 10 degrees (170 degrees angle between path segments) at 100 mm/sec than to turn 90 degrees at 5 mm/sec, and the junction deviation model does not permit that. @KevinOConnor What is your take on this?
I'm not sure that the default OpenSCAD value is a good argument here. It is probably chosen for performance rather than for the quality of the resulting part. The analysis above suggests that neither 12°, nor 10° is sufficient for fast and quality printing. So, I think the only good way to alleviate your issue is to choose some different model. Still, I don't think that 'patching' an existing formula is the right way to go - in that case, it is no longer based on any physical model or assumptions. Instead, one may say that the junction deviation model does not really reflect the physical constraints of the printer. At least, the current scv was chosen somewhat arbitrarily - there could be some printers with very heavy print bed or gantry, for which it is too much, and there are many printers that could take much more than that. So, maybe we shouldn't bother trying to limit the virtual acceleration during the cornering or the toolhead momentum change, but instead try to limit something else. Just as an example, one may choose |
I don't dispute that, but I claim that neither is "difficult" at all. If scv were 30 or so, we might be talking about something that's difficult, but at scv=5 we're well within the bounds of what's not difficult, and purely aiming to avoid the effects of vibrations (or, perhaps more importantly, the effects of compensation for them).
I agree, but the only "patching" I've proposed is simply not using it at shallow turns angles, but with a window function to phase it out smoothly rather than having a discrete, discontinous cutoff, which would have unstable behavior at the cutoff point. My claim is that, for these angles, the centripetal velocity limit model suffices to keep the junction speed reasonable.
Yes, the JD model does not reflect the physical limits of a machine well at all. The classic jerk model of Marlin was better for that, except that it didn't accumulate cost of discontinuous changes in velocity over a short time, thereby letting a large number of tiny moves grossly exceed the intended limits. If the goal were modeling the physical limits of the machine, one could start over from there and just try to do it right. But that has a lot of undesirable properties too. It's hard to work with in a machine-independent model for the first stage of kinematics, like Klipper does, and it makes acceleration behavior dependent on orientation (and for a delta, position) in space, which can lead to orientation-specific artifacts. JD is desirable not as an attempt to directly model the machine's limits, but as a way of producing reasonable behavior, and works very well for that as long as your JD limit is sufficiently far below the machine's physical limits. But at such low values it does have problems dealing with curves. That's what I want to solve. |
Some random thoughts - in no particular order:
-Kevin |
Some more random thoughts.. FWIW, I think of square_corner_velocity as a mechanism for managing extruder flow rate. If the printer decelerates to zero on each corner then we get terrible results because the extruder can't completely stop the flow of plastic. The pressure_advance system can help with managing flow, but PA works best when there is still some flow - the pressure model doesn't scale linearly all the way to zero pressure. At the other extreme, if the printer goes too fast through corners then the filament may not adhere well to previous layers and at some point the physical stepper may not have sufficient torque. So, I know some people try to tune square_corner_velocity for print times, but in my experience that doesn't really do much. If needed, I'd look to tune square_corner_velocity based on extruder performance. FWIW, long ago when I used Marlin, I had problems with first layer adhesion that I now attribute (in part) to its "jerk" algorithm. No matter how slow I went, it seemed to move through sharp corners too fast - leading to those corners not sticking to glass. Interestingly, the junction deviation algorithm was originally designed for CNC machines. So, although it's useful for managing flow rate on 3d printers, that wasn't its original goal. As I understand it, on a CNC mill, a quality result depends on having a consistent cutting rate. If the cutting rate changes rapidly it alters the finish of the final product (likely due to changes in heat in the part and cutting tool). -Kevin |
While diameter 40 was more convenient for showing it, I'm pretty sure we get the same problem with diameter ~11 (circumference 36, i.e. each segment 1 mm). At that size it really does not make sense to use more than 36 segments. I think I could also make it happen with a 72-gon of larger size, but beyond that it probably gets hard - the virtual junction radius grows pretty quick I think.
That doesn't have an effert by itself because of the way the logic works. You also need
At least with default damping ratios (and I don't know how to tune them), input shaper makes it impossible to go over scv=5 or so. Much beyond that, squares turn into something that doesn't look at all like a square.
I don't use accel_to_decel because it produces significantly slower prints for certain things I care about (gears, threads, etc.) and the vibration it mitigates is non-problematic and better mitigated by input shaper. But I don't think it fixes this problem anyway, as you say. Would you like to see the solution I have in mind for avoiding the acceleration? I've written and tested a version of this already for the corresponding issue with centripetal velocity limit, so it'll take a little more work to adapt it to scv and confirm that it works there too, but I think it will. I don't like this approach as much because it slows down prints considerably vs my preferred one, but I'd prefer it to having the issue go entirely unfixed upstream (and I can still keep my own fix as a local hack if I like). The reason I'm trying to get this fixed upstream is largely for others' anyway; I started really looking at it to the level needed to make a good bug report and discussion after seeing what looked like the same issue in a number of speedboatraces. |
@richfelker There is no reason to raise the junction velocity for FWIW, the problem in your case is exacerbated by the remote direct drive extruder, I suspect. From my personal experience, large magnitude accelerations and decelerations with the enabled Pressure Advance put a lot of stress on such extruders, and they cope with it pretty poorly. So the clicking noise one can hear is likely coming from the extruder. Unfortunately, it seems that this is their limitation due to very high gear reduction ratio.
Thanks, this is an interesting perspective. The JD model makes the toolhead to decelerate up to 0 speed for sharp angles (well, to 0 at 180 degrees turn, and to small non-zero values for other sharp corners). From the point of view of managing the extruder flow, do you think it would be beneficial to keep some small'ish non-zero velocity of the toolhead even for very sharp angles?
Actually, it is not possible for the input_shaper to magnify accelerations. As long as all its coefficients are positive, that is (and Klipper supports only such input shapers right now). So, the commanded stepper acceleration/deceleration after input shaper is always not greater than what it is without input shaping. However, if max_accel_to_decel is set to the same value as max_accel, then indeed there will be 'pointless' accelerations and decelerations while printing. And if the Pressure Advance is enabled, this will put more stress onto extruder. FWIW, even though I also print with higher |
The "polygon" you're seeing better in the stuttering print is not from straighter sides. It's inconsistent extrusion. My pressure advance constant should probably be a little higher than 0.05, but that's enough to mitigate the worst effects of inconsistent extrusion rate, and going up higher is a tradeoff in other areas. And I don't think higher could really solve the problem here - Klipper's PA with smooth_time is such that it can't handle really rapid pressure adjustments, and going to higher PA generally needs either longer smooth_time or lower acceleration.
That's not the case. I'm perfectly fine with it coming out either way (corners getting smoothed over or not). I'm just not fine with the extrusion stuttering from unnecessary oscillations in speed. I could try it again with input shaper disabled to see how it looks without the smoothing, if that would be interesting to anyone.
The clicking noise is from the 1:4 step-up gearbox on top of the motor to compensate for the high (40:1) reduction at the extruder end of the flex cable. It has some tiny amount of backlash, which is irrelevant to print quality thanks to the 40:1 reduction after it, but still relevant to noise level. Without this gearing, the motor would just be stalling trying to do this kind of rapid adjustment to PA offset, requiring a much longer smooth_time and thereby getting the same result as the pic with PA disabled. Note that all this is far worse on bowden extruders, where I got the same kind of pulsing with with 10x the offset. Somewhere I still have videos of my Ender 3's original bowden extruder rapidly spinning back and forth with PA on high acceleration. So it's not just an issue specific to my printer's unique setup. |
I'd think lower acceleration. From my very limited understanding of the processes happening in the hotend, smooth_time should depend on the inertia of the processes in the hotend for the most part. If you increase it, it may happen that you'll start getting inconsistent extrusion during acceleration and deceleration, because PA will start to kick in too early. It is possible to tune this parameter to better match the hotend, however it is rarely needed.
From my experience, it is not entirely accurate. A lot depends on the magnitude of said adjustments. And smooth_time isn't the problem here. If a toolhead accelerates from 50 mm/sec to 100 mm/sec at 3000 mm/sec^2, it only takes 16 msec to do that. Normally, the extruder needs to push all the extra filament in that time frame. If it is a direct drive extruder with a low PA value, it only needs to push a little extra. If it is a bowden setup with a high PA value - it may simply be physically impossible to push those extra few mm of the filament through the tube into the hotend in those 16 msec. And if it's an RDD extruder with a high gearing ratio - even though the amount of extra filament is small, the exruder stepper still has to make a lot of steps to achieve that. And it may still fail to do that because of non-zero inertia of the stepper rotor and the cable.
I see. You could still try using the default accel_to_decel value and see how that works in this case. But generally, I mean, Klipper tries to print an object exactly as it is. And it seems that it is simply not possible to print that polygon object precisely at high speed without any decelerations due to various constraints.
You could also give that a try. At the very least, it could be a practical demonstration of input shaper smoothing at high velocities (or not, depending on the results of the test).
Yes, of course, I did not mean it like that. Bowden setups are even more susceptible. But the point is: bowden setups may be not practical for printing at high accelerations with PA enabled. So either acceleration needs to be reduced, PA disabled (which impacts the dimensional accuracy of the parts and consistency of extrusion), or the extruder made such as to be able to handle the excessive load. There is no easy all-round solution to print very fast and accurately with bowden extruders. The same applies to RDD extruders as well, for the most part. |
If that's the case then it should just inhibit the acceleration and stay at the lower speed between junctions. However I have not seen any indication that it prints the polygon "more accurately" at lower speed. The visible sides appear only because of inconsistent extrusion. If I just lower the speed significantly to make the stutter go away, it looks just as circular as the one with high-speed junctions. |
FWIW, this isn't something I, personally, plan to work on. As high-level feedback, if you have an improvement to the lookahead algorithm then I'd say the next steps are:
A change from junction_deviation to a new algorithm would require widespread test results showing noticeable improvement. The JD algo is a heuristic and I don't doubt it can be improved, but for all its faults, it is a widely used and "battle tested" algorithm.
Okay, but it seems you have customized your printer configuration in an unusual way and your extruder hardware is very uncommon. My high-level feedback is that I'm not able to draw conclusions about general benefits from the results obtained on your hardware / settings. Cheers, |
Not sure I understand your question. FWIW, the red line in your picture at: looks generally like what I'd expect for cornering speeds. That is, the cornering speed of a zero angle (next move goes directly backwards) should be zero, the cornering speed of a 180 angle (no direction change) should be "infinite", and the cornering speed of a 90 degree angle should be a small finite number (eg, ~5mm/s). And, the curve itself should be smooth. Beyond those points though, it's hard for me to say what's ideal. The JD algorithm is also symmetric and is mostly "flat in the middle" - I'm not sure if that could be improved or not.
Yes. Sorry. I worded that poorly. I meant that input_shaper may magnify a negative impact of acceleration changes - not that the acceleration itself would be greater. For example, if the look-ahead algo results in a speed change from 90mm/s to 95mm/s followed shortly after by a change from 95mm/s to 90mm/s, then input_shaper may turn those 2 speed changes into 6 or more speed changes. I don't know if that would negatively impact print quality, but if the speed change is pointless, then, well, it's pointless. If nothing else, it's more work for the rpi cpu to calculate more speed changes that aren't actually helping overall print time. Cheers, |
It is sad, but what's even sadder is this: when I increased it to a 72-gon, Cura sliced it with a tiny move on the order of 0.001 mm on one axis and 0.01 mm on the other at 90° and 270° around the circle, seemingly due to numerical instability reasons with its representation of coordinates as integer microns. As a result, Klipper received the path as 2 rapid ~90° corners and thus slowed all the way down to scv and re-accelerated. So that's one reason folks aren't using better approximations of circles: slicers doing stupid things. Note that Klipper is doing exactly the right thing with this gcode. Any attempt to paper over the tiny move would break printing of tiny detail, for example my microstep-accuracy test print. |
What you describe sounds like a slicer bug. Such issues should be reported and fixed in the slicer itself, wouldn't you agree? I mean, there is really no good reason for any slicer to break on circles (BTW, I suspect that neither Cura nor any other slicer uses fixed-point micron representation internally - only exporting GCode in such format). For example, there was indeed recently a bug in Cura, introduced in 4.7 version, which broke GCode generation for any smooth curves, including circles. This resulted in slow-downs on curves, in any firmware, and zits and blobs there as a result. Devs claimed to fix it in 4.8, but if I got it correctly, if you imported your print profiles from any previous version, you needed to update some parameters related to resolution, otherwise the fix wouldn't work. But newly created profiles would work fine. Note that I wasn't following that issue too closely, so this may be my [mis-]interpretation of the fix. After staying for a while on the version 4.6.2 I switched to SuperSlicer for reasons unrelated to this bug. |
Absolutely. I'm just suggesting a reason people publishing models might be using lower precision approximations - if they had bad experience with slicers botching higher-precision ones and don't want users to have to deal with that and blame them.
It really does. It uses integer coordinates, at least at the phase of generating paths. I actually started writing my comment claiming it had used Anyway I'll try to make a good test case to report this one. Note that it only happens with an actual single-wall circle where Cura is trying to fit the extrusion between approximated inner and outer circles. There's no problem if you have a solid region with circular boundary. None of this negates the Klipper issue I'm trying to find a solution to here; it's just stuff I hit while seeing how practical it is to mitigate with better approximations in the model file. |
Oh well, I suspect you'll need to reproduce it with their new Arachne engine then. There were some notable improvements for such cases there, but there could be some regressions too.
Well, the original report is about printing a prism. As was shown, Klipper is perfectly capable of printing that prism so that it looks like a prism, without smoothing it out to the circle. I'm afraid that's the right behavior. Any improvements in the cornering velocity calculation should retain that. Though my rough estimations show that the current cornering velocity for small turns is perhaps already a bit too optimistic in Klipper, at least for input shaper smoothing. Therefore, I suspect there isn't that much room for further improvements. |
For the Nth time, I'm not complaining about that. The bug report is about the rapidly oscillating accel/decel. If cornering faster produces smoothing that makes the output inaccurate, then the solution is not to keep doing the oscillating accel/decel, but to maintain a consistent speed at the junction velocity for the segments between junctions.
I think that's likely true, and likely a problem that needs to be addressed in input shaper, likely by making the strength of the filter tunable. Otherwise it can't be used without limiting print acceleration to the point that prints are really slow (a case that was already fine without input shaper). |
You mentioned that you increased max_accel_to_decel from its default value. That is the feature designed to limit that behavior. Did you try printing at the default value? I imagine it will still be not perfect, but may offer some improvements.
Unfortunately, that appears to be not possible. It seems that due to their design principles, the amount of smoothing you get depends on the lowest frequency the input shaper can compensate for. The exact amount varies a bit from shaper to shaper, but the general principle holds. So what really matters for input shaper smoothing is the lowest resonance frequency of the printer. If you still wish to reduce smoothing, even if it means more ringing - just set the input shaper frequency to a higher value. And if you are using the accelerometer, the auto-tuning scripts already have So indeed an input shaper is not a silver bullet. For many printers, it does offer improvements in both speed and quality, but on some occasions you might be facing a tradeoff - printing fast and have ringing but no smoothing, print fast and have smoothing instead or print slower and have little ringing and smoothing. And if you are already printing fine and fast without the input shaper - I don't think there is a good reason to enable it. |
I can try and report back. Based on the documentation, I expect what I'll find is that it significantly increases print time by slowing down nearly all moves. My max speed is typically 120-200 mm/s (and 500 mm/s for travel), and almost no moves are able to reach that speed even at full acceleration, so they'd be capped to the speed they could reach at the lower virtual acceleration. Paradoxically, it sounds like using The problem with the accel_to_decel model seems to be that "short zigzag" is defined in terms of time rather than distance. At very high speeds and accelerations, traversing a giant square around the whole bed looks like a "zigzag" to it.
That's not how it works. The frequency is not a strength parameter, it's the frequency of the vibrations you're trying to suppress. Setting it to a higher frequency where you don't have ringing present is just going to make it worse than useless, possibly smoothing meaningful detail at that frequency while not doing anything about the ringing. The problem is that there's no way to configure it to "reduce ringing by 50%" or something. It's a full band-[non]pass filter. |
It will slow down the prints indeed. But you will not have useless accelerations and decelerations. It will work as expected. The exact slow down - it depends, maybe 10-15%? Depends on the model. I was thinking about suggesting to increase max_accel_to_decel in the documentation for the input shaper, but batch simulations show limited improvements in print times. I still want to spend a bit more time on it though.
Depends on your max_accel, but sounds about right.
No, that's not how it works. You will never get slower print by setting higher commanded velocity - but after a certain point the print time will no longer decrease, so at some point, further increasing the commanded velocity makes no difference.
Trust me, I do have some understanding of how it works :) Take a look at the shaper calibration graphs that are generated by the script processing accelerometer output - it shows the remaining vibrations at different frequencies for each shaper (as a ratio from 0 to 1). Or you can play with
That's really not how it works. The thing is, the toolhead pretty much almost never moves at the resonance frequency in the real prints - the resonance frequencies are usually too high for that. So in practice the smoothing has very different reason - because the input shaper computes the weighted average of the toolhead position over some period of time (and over fixed set of points). And that period depends on the frequency of the shaper - the lower the frequency - the bigger the period. That averaging makes the fine details and corners smooth at high printing speeds (and high accelerations, because that gives bigger average speeds). The solution is either printing slower (or at lower accelerations) or reduce the averaging period, so that the average deviates less from the original trajectory. |
No. It will just reduce the magnitude of the useless acceleration/deceleration cycles; it won't eliminate them. They might appear to be eliminated if the In short, it will fail to eliminate useless accelerations and decelerations, but will severely limit the most useful ones. Going on this from the documentation:
If I have a 200 mm move requested at 500 mm/s,
OK, that seems correct, but not much of a condolance when it failed to get rid of oscillating acceleration on curves but made my travel nearly 50% slower....
I don't get what you're claiming. If the actual resonance frequency is something like 45 Hz (my value, measured with test model not with accelerometer analysis), the toolhead does indeed move at that frequency quite a bit - not in a sine wave at that frequency, but in motions that have a very strong component of that frequency in their fourier decomposition. |
It will accelerate to "only" 447 mm/sec (sqrt(2 * 100 * 1000)), accelerating over 50 mm, cruising for 100 mm, and then decelerating, completing the move in 0.67 seconds total, if I did the math right.
At 45 Hz and 2000 mm/sec^2 max accel the toolhead can oscillate by (and thus produce any meaningful details of the size of) ~0.03 mm. These are some very fine details. "in motions that have a very strong component of that frequency in their fourier decomposition" - I am not sure which function of the motion you are talking about (position, velocity, acceleration, etc.) and what integral effect it will have on the positional accuracy of the toolhead. Anyway, if you set mzv to, say, 60 Hz instead of 45 Hz in your configuration, you should not get more smoothing, but you will get much less ringing compensation, like only ~4x instead of ~20x. |
Indeed, I messed up the math, but I was trying to make an example where the effect was clearly unwanted. Unless there's something I'm missing where the scale between the two accelerations limits the badness, I think you can just scale speeds, accelerations, or distances to make a much worse example, no? I guess the ratio of max speed is bounded by On the other hand I'm not convinced it helps the oscillation on curves. If you have a 3mm segment (1.5mm to accelerate) from 50 mm/s at 2000 mm/s², it could achieve 77 mm/s, but only 55 mm/s at 1000 mm/s². That seems to help, but it's entirely dependent on the absolute magnitude of the accelerations. If you change it to 3000 and 1500 or 4000 and 2000, you still have huge oscillations (up to 67 or 77 mm/s, respectively, if I did the math right).
I don't understand that derivation, but also I think you're omitting junctions, which are the whole topic of this issue report. At square corners you have instantaneous velocity jumps of scv (e.g. 5 mm/s) and at 10° turns you have instantaneous jumps of |
I meant that for 90 degrees, the toolhead maintains some small speed (5 mm/s), and so does the filament flow. However, at very sharp corners, the toolhead comes to almost a complete stop currently, which may negatively affect the filament flow in the hotend, and that PA may not be able to deal with it that well. I wanted to ask your opinion about this, and whether maintaining some non-zero velocity even for very sharp corners could be beneficial. Or maybe you see it as more important for the toolhead to slow down completely, e.g. for better filament adhesion.
Input shaper affects only the toolhead kinematics, so it shouldn't adversely affect the extruder. Only the accelerations and decelerations from the lookahead algorithm have effect on extruder kinematics, including PA. On the print quality, any acceleration, deceleration, or any other deviation from the constant speed motion will indeed result in some amount of smoothing by the input shaper. So, any turns even without acceleration or deceleration are affected by input shaper to some degree. But relatively sharp corners, where this effect could be visible, are traversed at low speed, and that reduces smoothing. So, scv=5 mm/sec seems to be a good choice for input shaping as well, and not just for the extruder, because it gives little smoothing even up to quite low resonance frequencies. |
On a side note, but somewhat related to this issue: Some users use ArcWelder to recover curves after slicing or from coarse STL models. One reason is aesthetics, the other is avoiding slowdown on segment junctions.
I've sort of reverted this customization: I scale SqCV by the square root of the acceleration specified by M204. The rationale is obtaining more precision during the first layer, while allowing higher deviation for travel moves. Not that I have hopes of seeing something of this sort on the master branch, I'm just curious if you have an opinion on this. |
I'm starting to doubt my initial premise that it makes sense to traverse curves at the centripetal velocity whose acceleration matches the acceleration limit. A centripetal based limit probably makes sense, but I think it should be based on a much lower acceleration than the liner acceleration limit, possibly 10x lower or so. This works out to a much weaker growth of the limit than JD gives; you have tan(theta/2) instead of sin(theta/2)/(1-sin(theta/2)), so cancelling common factors, it's 1/cos(theta/2) vs 1/(1-sin(theta/2)), or letting u=sin(theta/2), 1/sqrt(1-x**2) vs 1/(1-x). As for the reason for my doubts, the centripetal velocity at linear acceleration limit seems to have adhesion problems for me, pulling the material inward before it can adhere, at least with some materials and acceleration values that work fine for linear acceleration. So I'm turning my attention on this issue to just mitigating the oscillations rather than getting rid of the speed limits that caused them.
This is something I was thinking about yesterday, but taking it further, I concluded that if you want speed, you just don't put junctions in travel; you make all travel moves straight lines from the previous to the next extrusion move. And you can crank acceleration through the roof because, assuming you're doing proper retraction, there're a few [tens of] ms window for any vibrations to damp out during unretract before you start extruding again. |
My impression is that going to zero speed on a 0 degree turn (and near-zero speeds for sharp angles) is the desired behaviour. The basic idea is that if it is a "sharp corner" then getting good adhesion is more important than preventing blobbing. To be clear though, I have not done any particular stress tests to verify this impression.
Agreed. FWIW, though, in a move of 90->95->90mm/s (as an example), it may be the case that just staying at 90mm/s produces better overall results. Said another way, max_accel_to_decel prevents instantaneous acceleration to deceleration (when enabled, there will always be some cruising time between accel and decel). It may be worthwhile to also avoid some cases of instantaneous deceleration to acceleration by lowing the cruising velocity of some moves. I haven't tested this though. Cheers, |
Over the past couple days I worked out some explicit numbers with various models, and found that the only ideas I had that made some physical sense for locally limiting the velocity in ways that prevent the oscillating accel/decel cycles fail to do what's needed. Moreover, any local model is inherently bound to fail if you just split up each move into 2 moves at their midpoints with a 180° junction. At least as I understand it, the I think the right path forward here is just making use of the lookahead we already have. In particular, for each move, it's possible to look at a window (time-based or distance-based) of some delta into the future, and query what the min junction velocity limit is within that window. As stated, that's unstable with respect to a slow junction being just outside the window, so for the min, also include a limit calculated as follows: take the first junction past the end of the window, and compute the maximum attainable velocity for the move leading up to it, starting from the previous junction and reducing the move length by the remainder of the window length. I need to work out a few more examples to make sure this is viable and does what's needed, but I think it achieves what was intended by |
Hello, It looks like there hasn't been any recent updates on this Best regards, ~ Your friendly GitIssueBot PS: I'm just an automated script, not a human being. |
After encountering rapidly oscillations in speed along what should be smooth curves at high max speed, I began investigating the math behind junction velocity limits, and found what I believe are two problems. One is related to the centripetal velocity limit, but this issue report will focus on the square corner velocity (junction deviation algorithm) limit, which is currently the limiting factor and source of the oscillations I saw with reasonable values for
square_corner_velocity
(abbreviated scv from here on).Under the JD algorithm, the maximal allowed velocity for a junction varies with angle as
sin(theta/2) / (1-sin(theta/2))
, wheretheta
is the interior angle (180° being no turn at all). Plugging in values of 90° and 170° for theta, one can compute that the allowed junction velocity for 36-gon approximation of a circle is only 10× the value for a 90° turn (i.e. 10×scv). If one follows the Input Shaper guidelines for using a low scv like 5, that puts an extremely low hard limit of 50 mm/s on the velocity the toolhead can traverse a circle - much lower than the centripetal velocity once you're beyond a few millimeters of radius. Moreover, between junctions the toolhead will accelerate and decelerate, creating oscillating extruder pressure and, with pressure advance, rapid E-axis swings back and forth. If the pressure advance smooth time window is sufficient to smooth out these swings, then extrusion thickness will just oscillate instead as the toolhead velocity oscillates while extruder velocity remains constant.To get smooth motion around a circle at even a moderate print speed like 150 mm/s one would need scv>=15, which produces considerable ringing with input shaper disabled, or severely rounded-off corners with input shaper enabled.
I have done a good deal of experimenting with hacks to solve the problem, and the right approach seems to be smoothly transitioning away from using the junction deviation/scv limit as the junction angle gets large enough to be participating in a curve. At such angles the centripetal velocity limit should suffice to keep the motion reasonable.
The current trick I'm using is applying a power to the
(1-sin(theta/2))
in the denominator of the computed virtual radiusR
. A power of 1.5 (scaling up by a factor of1/sqrt(1-sin(theta/2))
) seems to work well but might be execesive. It increases the radius nearly 4x at an external angle of 45°, and roughly 16x at an external angle of 10° (allowing a 36-gon 'circle' to be traversed at up to 800 mm/s with scv=5). This is of course also throwing off 90° junction velocity by a bit (making it about 20% higher) which could be fixed with renormalization or just interpolating to a different sort of limit.The text was updated successfully, but these errors were encountered: