[BUG] Junction Deviation is Borked.... #17146
Comments
Yes, please zip up your configs and attach them for review. |
|
Don't take my report as "talking shit"... That's not my intention at all. I hope you take a look at my configs and tell me I'm and idiot... I've spent the last couple of days making tweaks to various things and getting nowhere. For the most part my prints come out one of two ways.. looking like Tux 1&3 with JD enabled or Tux 2&4 with JD disabled. |
|
What's weird is that it doesn't affect all circular movements. Some circular movements don't make the extruder go crazy and come out fine...Some seem to be at too much of an angle and the extruder goes craszy. So to me.. with my limited knowledge it seems like some sort of math issue. This particular Tux model is just the worst I've come across. The following is the thiniverse link .https://www.thingiverse.com/thing:1809605 EDIT* I should have posted that I'm printing that model at 30% size. |
|
Printed the bottom of the model. Here is my result. Latest Bugfix, Ender 3, SKR Mini E3 v1.2 |
|
@DaMadOne: You've overridden the default Those are set for you automatically, so were defaults (commented out) not working on your TMC2209s? |
|
@thisiskeithb It is all disabled for me. I know that you didn't wrote it to me, just wanted to say it. |
|
It may help to set the slicer to use minimum length segments. I'm not sure how a lot of short segments interact with these various settings versus curves with longer segments. This would be a good area of exploration. |
That change was made after I was already having problems. Another bug report here that was already closed but had a similar sounding issue mentioned those settings. So I looked at it and tried it. The comments pertaining to those config lines seem to suggest the settings I applied are the "best default" settings for the stepper drivers I'm using so I figured it was worth a shot. I didn't notice anything negative(or positive) from them in my testing so I left them. That same bug report did show that they used settings in the middle of all the defaults(and different from mine) and got positive results from it.. I have not tried those exact settings because the settings they said they used seemed to almost match the numbers in the commented out lines that I enabled and changed but saw no difference In my prints. So it didn't seem worth while to spend anymore time changing those. I couldn't find it last night but another report had some videos posted in the comments. If you watch the before and after videos and try to filter out the other noise and just listen to the extruder then you can hear the difference. That sound it exactly what I'm seeing/hearing. Another model it show up on consistently is the benchy. Most of the boat hull prints well. There is a series of layers that cause this issue though. It's nowhere near as extreme as the tux model but you can't miss it when comparing LA with and without JD. Maybe someone who understands the math behind LA and JD can take a look at those models maybe have an idea of whats going on. |
I will take a look at this tomorrow and will let you know the results. |
Could very well be, I guess OP should check how the layers are "drawn" in its slicer preview, additionally CNCKitchen has a video/semi-tutorial on youtube about this : https://www.youtube.com/watch?v=Hvw3DrVAeTA |
|
In my case there are no pausing at all, just continuous X / Y motor stuttering, that causes the rough layers/surface noticeable on the prints, but I can feel it on the stepper motors too when printing. Edit: |
|
You didn't post your configuration so it's hard to tell what could be wrong from pics with the light/seams at a different place on each pictures. What's your config / setup / JD value ? Bowden ? Direct drive ? Did you do the jerk to JD conversion correctly ? Did you try other values for JD ? I have pretty round circles on a bowden/cartesian setup with JD (0.12) / S-curve on, no LA, and : print speeds from 40 to 60-65-ish, 0.1 to 0.3mm on a 0.4mm nozzle. |
|
Didn't thought that my confings too are needed, sorry.
|
|
Well, I'm not saying there is no bugs, but both you and OP has that issue with JD, so it's best to check / cross-check both of your configurations, make sure there's a legit need for marlin devs to dig deeper. Might be a bit of a blind shot, but did you try to use "a well known 3D printer model's config" regarding JD / accel ? |
|
I "followed" the Ender 3 and BTT SKR Mini E3 v1.2 example files, and I made my own guide. The annoying part is that, with Classic Jerk I get better result in that model (same gcode), and I can feel the steppers too, that they are not stutter when printing the curves. |
|
A different avenue; are you printing from SD / Storage media or are you printing over the serial port? Perhaps we are seeing some automated slowdown due to buffer starvation. |
|
I print from SD card. |
|
I'm getting down to further testing today. I will use this post as a sort of scratch pad that I will update periodically with what I am trying and the results. First up today was to upgrade to 2.0.5. HERE are the config files as they sit right now. I cut out and am only using part of the middle of the tux model to speed up test prints. First print shows the stutter. EDIT* I should have probably zipped up the right config files.... corrected. Next test was to try printing the same gcode from SD since I've been using Octoprint. Stutter is still there so that should rule that out. Also before anyone asks I had octoprint disconnected when I printed this. I've decided to try to slow things down to see if speed makes any difference. P@50/EP@40 test is currently printing but already found something interesting. I'm printing 3 walls thick and when printing the 2 inner walls I can hear and see the extruder stuttering at 50mm/s. I have a knob on my extruder which makes it really easy to see. However, when it moves to printing the outer perimeter(40mm/s) the the audible and visual indicators from the extruder are gone or at least not noticeable. Comparing this print to the previous it definitely looks better. It's not as smooth as with JD disabled but I'm guessing that is due to the inner 2 perimeters still stuttering while printing.. so I guess my next test will be to print with both P&EP@40mm/s.... With both P&EP@40mm/s both the inner and outer perimeters sound and look to be printing smoothly. So what does this tell us? I don't know but I know that with CJ I can print at faster speeds so this doesn't really help me. Maybe this info helps one of the devs or gives someone an idea of something to tell me to try. @thinkyhead mentioned to try setting the slicer to use minimum line segments. I can't find this setting or even anything that sounds like it to me in Cura or PrusaSlicer. Can you point me in the right direction? Preferably in PrusaSlicer because I don't really use Cura. @Moyster mentioned THIS video. I checked it out and tried the Resolution setting in PrusaSlicer they mentioned and changing this at all (even to 0.1) makes even the preview look bad so i'm not bothering to try to print it. Interesting... so I didn't try printing with resolution set to 0.5 since that looked really bad. However I decided to try 0.05. You can notice it in the print preview but not by much so I decided to try printing it with P@60mm/s and EP@50mms. So far printing OK. This doesn't really answer why the same gcode printed with JD enabled vs not shows serious differences. Or maybe JD is much more precise when compared to CJ and CJ was just hiding this issue? Well maybe not... The print finished and when compared to the Tux printed without JD the quality of the outer shell suffers with res set to 0.05. Trying again with 0.25... err.. wait.... nevermind. As I was typing it got to the point it's printing the circles and it's back to stuttering(just to be clear, by stuttering I mean it's obvious the extruder is moving back and forth really fast) so I guess I can hit cancel on that one. Reading through comments on the video @Moyster posted and it's interesting to me that "W Boumans" also figured out he had to slow down to 40mm/s. The other poster mentioned it (messing with resolution) "solved it completely" but I can say from comparing them it does not.. only hides it at the cost of print quality. Some more things I've tried that didn't help were. Based on the 2nd one above with JD enabled it's not possible to tune EJERK from the menus or gcode anymore as far as I can tell. M503 does not show an M205 value for E (M205 B20000.00 S0.00 T0.00 J0.08) and it's not in the jerk menus on LCD. Or am I missing something? Is it even worth trying to mess with this value based on the issue I'm having? Things your probably can't tell by looking at my configs are that for the most part the mechanics of my E3Pro are pretty much stock. Bowden extruder(upgraded metal creality extruder), Capricorn Bowden tube as short as I could comfortably make it and a Micro-Swiss all metal hot end. I don't think any of that should have anything to do with my results but I've not listed that before. Based on tests I did I have retraction set to 2mm @ 25mm/s. Attached is the gcode I've been printing today in case anyone wants to look at it. Plus all of the slicer settings are at the bottom if those are of any interest. I'm out of ideas short of just sticking with classic jerk since I do like the benefits LA has given me when it comes to speeding up prints without definition loss. If anyone has any bright ideas for me to try or wants me to supply anymore info than I already have please let me know. |
|
moved this from my other comment Question for someone in the know. Kinda thinking out loud. Is the math for JD more/less/sameish to the math for CJ(classic jerk) when it comes to CPU usage? Wondering if it's possible to be hitting processing limits of the STM32's on these boards? Probably not? Since the stutter to me seems more like a ton of retracts than it does some processing problem. When the extruder is stuttering it doesn't seem like X/Y are also stuttering but maybe it's just harder to see and hear. |
|
@DaMadOne : what thinkyhead was referring to (minimum segment length) is what the video I linked talks about. #17171 |
This is correct - if you're using JD the extruder jerk is calculated according to the following formula: where |
|
@Moyster I changed I'm open to any ideas. |
|
I see you have Linear Advance, and working with Cura... That will not work very well. Reslice with Slicer using Lin advance, or alternatively, turn off linear advance and see if you can simulate the issue. There is an incompatibility between Curas extrusions widths and Lin Advance... |
Don't know how is that even makes sense, as I printed it with and without LA, and it was the same, but ok. |
This isn't remotely true. Is it true that Cura makes MANY assumptions? Yes it does. Does Cura break LA? then the answer is no. You can tell by reading the OP and checking out pics that I posted that the slicer doesn't matter. I can print a terribly calibrated Cura prints with LA and JD enabled and tell the difference. It's only slightly different from my better calibrated Prusa Slicer profile between JD enabled and not. It's easy enough to turn off most of Curas advanced features. It doesn't help to regurgitate the crap people read and hear from reddit. |
|
On to block buffer size. I didn't mention it but things I tried didn't make a difference. |
|
The more I dive down this rabbit hole of bug reports and Pull Requests the more I'm convinced this isn't an immediately solvable issue. LA just wasn't developed with bowden extruders in mind. So I can either jump to a direct drive system or disable LA. At this point I've decided to disable LA and dial in the parameters that I can. |
|
@ManuelMcLure I'm a little inebriated right now but I'l check out the math tomorrow. Would be interesting to see what that ends up at. .. if it turns out that math ends up at a high jerk value that would be very telling i would think. |
|
Hey there, I'm also using a SKR Mini E3 1.2 board and also got weird artifacts when enabling JD The lines are always wavy around curves, doesn't matter if I enable or disable linear advance it's always a bit wavy. |
|
If this is an issue specifically with the SKR Mini E3 v1.2 and maybe with other SKR boards too, then how can we make sure of it, then solve it? |
Build back your original board, use the same firmware options and verify on the original board with the same gcode? |
I would have done that already, but I no longer have the original board. |
|
Just want to leave a link to potentially relevant issue: #15473 What I learned there is that JD with LA and optionally acceleration control in Cura makes an easily reproducible issue, but it is present even without LA/JD/acceleration control, though very rare (like once per 200 layers). You can try to enable acceleration control in Cura (assign different accelerations for infill/perimeters/e.t.c) and see how prints will get completely wrecked. On the bright side, currently on SKR PRO 1.1 I see much less (if at all) of an issue. So the issue might be more reproducible on |
|
Duplicate of #17342 |
|
Just saw this and the linked video:
Unfortunately this is not a solution. Even Cura's default max resolution/deviation settings are way too high to accurately reproduce fine detail, and due to numerical instability, they produce inconsistent results on consecutive layers, resulting in non-smooth surfaces. For fine detail, max deviation needs to be on the order of microstep size. There's a similar problem in Marlin firmware that compounds on top of this too, Any real viable solution of these problems needs to avoid depending on "make gigantic imprecise segments". |
Well this really could be addressed by the slicer authors. I won't list all the potential approaches, but I can think of a few ways to mitigate this effect. |
The thing we're trying to look at here is the behavior of junction deviation in the presence of many small segments. In the other thread I was keen to state that we're not trying to solve the issue by this method, but to eliminate factors that could be contributing to the bad acceleration effects. I am asking testers to reduce the number of segments and give feedback so that we can see whether there is any effect and what that effect is. But the deeper investigation involves a lot of logging and doing lots of French curves and Fibonacci spirals. |
|
Inconsistency between consecutive layers can be solved by slicers if they care, yes, but loss of detail can't. In any case I'm in full agreement that eliminating other factors (tiny segments) that could be involved with this JD bug is a good debugging technique. I just misunderstood the low-res slicing recommendation as a statement that high-res slicing is undesirable or unsupported in general. |
|
To clarify, the stuttering appears for some arcs. |
|
This is worth a read for anyone using 2208 and 2209… #11825 (comment) |
|
@thinkyhead I believe stealthchop issues are not relevant as it stops all extrusion permanently, while in this case it misses alot of steps. In my case TMC2209 was in SpreadCycle mode. |
@thinkyhead So, is it enough to just turn off StealthChop and try to print a sample with JD to test it? Because I did it and it didn't turn out any better, but was loud the whole time... SKR Mini E3 v1.2, TMC 2209, latest bugfix. |
|
For anybody looking here, I've posted a workaround in #17342 which solves the issue for me until the actual bug is fixed. |
|
@XDA-Bam I've tested MIN_STEPS values of 16 and 6 with JD on SKR PRO. I see hardly any differences in surface quality. MIN_STEPS 16 has slightly less "noise" on the surface, but still very far from JERK quality. Jerk surface quality is better with all MIN_STEPS values (16, 6, 1).
|
|
@BarsMonster Could you share your test file? I would like to test it too, on SKR Mini E3 v1.2. |
|
@qwewer0 It's here: |
|
Apologies, didn't notice this was closed. Continuing here: #17342 Another dataset; I took the STL from @BarsMonster (#17146 (comment)) and printed the same .GCODE file with JD (J=0.08) and CLASSIC_JERK. (X, Y JERK 10) Results below. Both printed directly from SD card on SKR Mini E3 v1.2 running 2.0.5.3. I honestly can't see a difference here. Both with
|
|
With @BarsMonster test file, I can't reproduce the the issue with JD. (SKR Mini E3 v1.2) |
|
@swilkens @qwewer0 Do you have high resolution enabled in your slicer? You must have segments with length of ~0.1-0.5mm in the output to trigger the issue. With Cura you achieve that by setting Maximum Resolution ~0.2mm and maximum deviation of ~0.002mm (as an ultimate example). As we see in the code (#17342 (comment)) , with segments of 1mm or longer - issue would not be reproduced. |
|
@BarsMonster In PrusaSlicer the "Slice gap closing radius" (Cracks smaller than 2x gap closing radius are being filled during the triangle mesh slicing) is set to 0.049, so maybe the max resolution would be 0.1. |
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
There are numerous reports of JD affecting prints when LA is used. There has been much discussion about it and it seems the bug reports get closed due to inactivity most of the time. But something isn't right,
From left to right is Cura with JD enabled, then classic jerk. The 3rd and 4th print is Prusa Slicer both with JD enabled and without. I don't use Cura much and as such my profile is probably not that dialed in an why it doesn;t look as good..
I'm only showing it to show that the slicer used doesn't really matter much. It doesn't take a rocket scientist to see the prints with classic jerk are better.The 1st and 3rd print are jagged AF and the 2nd and 4th ones are much better.
With JD enabled the extruder goes nuts on circular prints and is very herky jerky producing the 1st and 3rd print of the Tux model that is not right.. . Without JD enabled circular prints are very smooth. Logic dictates that JD should be much better than classic jerk... but real world tests show otherwise.
I'm running an Ender 3 Pro with an SKR E3 DIP with TMC2209's.
I printed them with the same Marlin 2.0.4.4 firmware so configuration doesn't really matter but if you want me to post my config files then let me know.
The text was updated successfully, but these errors were encountered: