Open VanessaE opened 4 years ago
Feels a bit like the issue we originally integrated junction deviation for #10171. Small changes in z cause big variations in x/y-speed when z-jerk(speed) is (to) low. What is your z-jerk(speed)?
Z jerk is currently set to 0.4. That's inherited from my smaller machine, though I'm not sure how it got that value. Some default setting I suppose.
I am beyond happy you posted this. I spent all day testing this trying to figure out what in the world was going on. Could not figure out how it was happening. I would run a test print dry run that would work fine, run a different one, it would break, and then rerun the first and it would also be stuttering. Double checked and sure enough my printer starts up with ABL off, and the print I tested with first doesnt home at all, so ABL doesnt get turned on. It ran fine, then I manually turned on ABL and ran the print again. Stuttering.
100% can confirm this is an issue
video of testing here https://youtu.be/x6NTq2Hkm9g
In the video you can see that it was only having issues when I moved x via firmware to X=30+. At that point, the y axis will stutter. Moving the X back to less than 30 removed the stuttering.
Additionally moving the x axis by hand so it was beyond the X=30 mark but considered less in the firmware, the issue was not present. The reverse was also true, recreating the issue and then moving the x carriage to the "safe zone" by hand resulted in the issue continuing. These two scenarios were also done by disabling all steppers once in position to circumvent potential issues with steppers remaining charged.
Testing also included swapping out stepper motor cables, unplugging everything not essential and a few other things. However as i said in the first paragraph, turning ABL on and off is enough to recreate the issue.
BTT SKR 1.4 Turbo, BTT TMC2209 (Spread and stealth had no effect, did not try hybrid), 24V system, 0.9 deg motors, both Z are 1.2A motors and the rest are 1.3A. Z are on individual drivers. Classic jerk enabled
Version is 2.0.5.3
Updated to 2.0.6.1 and still have the issue. Even present without Linear Advance compiled in for me. Z jerk is 0.4
Further testing:
I'll be layering back in the Linear advance and S curve stuff to see if it still works
Updated to 2.0.6.1
Please test the bugfix-2.0.x branch
to see where it stands.
This is with the bugfix-2.0.x
branch, or that is to say, my original report is for that branch, so he does not need to test.
It turns out I can reproduce this without having Linear Advance compiled in, similar to @cpolera's recent comments, and it doesn't seem to matter how high I set the Z jerk (I've gone as high as 5.0, which I'm glad to say doesn't have a deleterious effect on Z motion). A Z jerk that high smooths out the stuttering, but that won't work on machines that can't handle it.
I think the key is simply having low enough Z jerk and bad enough deviation in the probed grid where a travel move happens to cross. I imagine if you did something ridiculous like place a dinner plate on the bed and probe THAT to get a really warped grid, it'd be easiest to see the stuttering.
Updated configs: Marlin-configs-2020-09-22.zip (does not have the higher Z jerk, forgot to re-set that, stupid Prusaslicer "feature")
Realized this behavior prior, but thought, it somehow would be related to the communication between "MKS TFT" and "SKR 1.4".
@VanessaE Thank you for keeping this alive, since it seems no one else is bothered by this!
Would be really nice, if someone would have a look into this (Of cause with the intention to solve it! 😁).
thank you in advance
Could you try this with ABL_BILINEAR_SUBDIVISION
enabled, to see how it impacts the behavior?
You will need to use the absolute latest from bugfix-2.0.x
, as I just fixed an issue which could cause part of the subdivided mesh to be invalid.
I would also appreciate some updated configs from anyone experiencing this, which build against the latest bugfix.
@sjasonsmith No, unfortunately still present. 😭
kind regards
I'm now at commit 41529b65, and can confirm @discip's results. Z jerk of 0.5 for testing, ABL_BILINEAR_SUBDIVISION
with the default of 3 subdivisions compiled-in.
Has there been any progress on this issue? I have been having similar issues with default Classic jerk z (0.3), TRAVEL_EXTRA_XYJERK 5.0 DEFAULT_EJERK 15.0
S-Curve Disabled. Linear advance Enabled. UBL 15x15 grid with 3 point adjustments on start code.
I would be using the latest from Dec.8th I believe. I might have to double check that later.
Edit: I need to update will state results after testing.
It's still there, but turning my z jerk up to 2.0 removed it if that helps.
I have had the same issue for years (and still have), but I always figured that the Z axis just couldn't keep up with ABL at high speeds, as the stuttering gets better when increasing jerk & accel values for Z. Why wouldn't that just be the case? I never figured it to be a bug.
I think it's because as travels move across the bed level mesh, the Z move speed and perhaps direction change frequently according to the angle of each of the mesh's virtual grid sections, crossing the Z jerk limit as it goes along, which in turn triggers X/Y to decelerate/accelerate if those changes are big enough, so that Z doesn't fall behind.
The thing is, tracking the mesh perfectly like that is often pointless for travel moves, so Marlin should just use one-segment, straight-line moves whenever possible. These seem safe cases to do that:
If none of those apply, then Z would either have to track the mesh during travels like it does now, or better yet, have it trace out a simple curve that avoids the highest areas of the mesh along the path. Of course, such a curve would have to be rendered into a handful of short, straight moves, similar in concept to how G2
/G3
arc commands are rendered into many line segments (but this would be much lower "resolution"), and would probably be no different from just following the mesh, as far as stepper control is concerned.
The idea is to minimize changes in Z speed and direction from one segment to the next so that Z jerk and acceleration essentially don't matter, apart from the endpoints (in theory, there would be only one direction change at the apex of the curve).
[1] If any axis has not been homed since start-up, or since the last time any of them idle timed-out, or since the last time the user turned any of them off with M18
/M84
, or if there are other things I'm not thinking of that the firmware can detect that can reasonably be assumed to potentially throw-off an axis' position. If the printer has Trinamic drivers capable of StallGuard, I could also see an argument for detecting if an axis is currently powered-on but has been forced to move by the user pushing the toolhead around, if that feature exists and is capable of this.
[2] If the nozzle is cold, we're obviously not printing, and the nozzle probably has some cooled plastic on it. The only reason we have to follow the mesh is if we're close to Z=0, or if we're printing, but if the Z position is close enough to the part or the bed for the bed level mesh to matter, then the schmutz we assume is on the nozzle will almost certainly hit the part or drag on the bed. So we can assume a cold nozzle is a sign that the mesh is useless at the moment.
[3] If the bed is say 20-30°C below than the current target, or if it's turned off, then in all likelihood, the current bed level mesh will not be valid, since it'll most likely have been set-up/probed while the bed was at working temperature, and beds often shift or warp a little as their temperature changes.
I used to experience the stuttering moves very badly directly after a long move coded in the GCODE for the end of G29. It was on a 8-bit AVR. And it was annoying and sounded really bad.
Sadly, as much as I have tried, I cannot reproduce it anymore with my current printers. No more 8-Bitters available.
I do remember it was exacerbated by setting Junction Deviation low, got better when it was set higher.
One thing those people who can still reproduce this could try, if it has anything to do with trying to follow the mesh, try (just as an experiment) making the offending move at a higher Z level, maybe, or set your FADE HEIGHT really low, That will reduce the amount of mesh following taking place and might help to prove that observation.
@VanessaE That would be a great feature. Another simplified implementation would be to see if the linear travel move would cause a collision with the heated bed or the print and move the z axis accordingly before starting the travel move. It wouldn't be as sexy but the time penalty also wouldn't be too bad as you usually only would have to move a fraction of a mm if any at all.
@FanDjango My bed is very warped (+-0.3mm over a 400mm square) and I witness this at speeds over ca. 150mm/s with 200mm/s/s Z accel. and 0.019mm junction dev or 1mm/s/s/s classic jerk. My solution is just not exceeding those speeds, especially for the first layer. But this is interesting:
I do remember it was exacerbated by setting Junction Deviation low, got better when it was set higher.
That shouldn't be the case, unless you mean with "low" that it's smooth, as the JD factor defines the size of a tangential curve at each direction change. The edges of the mesh grid are such points at which the direction changes, so a higher JD will make the transition from one segment to the next longer and thus smoother. That also corresponds with my observations.
I just read the whole thread and saw some of the videos that were posted relating to this. I think the issue is mechanical and how the z-axis works. The fact that has a screw-drive it cannot have huge accelerations as the forces on the screw cannot be handled. The resolution is 5 times more than the other axis and while is traveling over 300mm in x-y that has to do 5 times the adjustments.
Are they any real problems while printing? I think lower the height fade to 5mm and oiled the screw? Play a bit with the tightness of the springs but do not overtight them.
Can you just repost the eprom settings that you use? Are all default? I have a CR-6 and i can experiment over the weekend.
I have a similar issue in current bugfix_2.0.x that I can readily reproduce. The problem is not present in Release 2.0.7.2
With bed levelling enabled there is a bad vibration with large XY movements at any speed. just moving backwards and forwards using G1 Y0 F6000 to G1 Y300 the vibration noise is awful. if I disable bed levelling M420 S0 the movement is smooth and quiet at all speeds. Using default A4988 stepper drivers on an 8 bit Trigorilla Board.
the mesh is fairly level
Bilinear Leveling Grid:
0 1 2 3 4
0 -0.800 -0.898 -0.865 -0.839 -0.697
1 -0.800 -0.896 -0.824 -0.801 -0.664
2 -0.818 -0.882 -0.801 -0.798 -0.684
3 -0.795 -0.902 -0.842 -0.836 -0.706
4 -0.715 -0.894 -0.883 -0.899 -0.757
My config is the example Anycubic Chiron (Trigorrilla board) S_CURVE_ACCELERATION disabled CLASSIC_JERK disabled
#define DEFAULT_ACCELERATION 2000 // X, Y, Z and E acceleration for printing moves
#define DEFAULT_RETRACT_ACCELERATION 4000 // E acceleration for retracts
#define DEFAULT_TRAVEL_ACCELERATION 2000 // X, Y, Z acceleration for travel (non printing) moves
#if DISABLED(CLASSIC_JERK)
#define JUNCTION_DEVIATION_MM 0.028 // (mm) Distance from real junction edge
#define JD_HANDLE_SMALL_SEGMENTS // Use curvature estimation instead of just the junction angle
// for small segments (< 1mm) with large junction angles (> 135°).
#endif
Hi, my FLSUN Q5 experience severe shuttering with the bugfix-2.0.x branch (STRING_DISTRIBUTION_DATE 2021-03-30) but not with the 2.0.7.2 release. I compiled both version with the exact same settings, printed the exact same gcode (calibration cube) with a skirt of 3 loops.
With the bugfix-2.0.x binary, I just need to wait some seconds to note that when the printer is on the round corner of the skirt stutters a lot (like if there is a buffer underrun), with low or high Jerk settings (5 to 12, the same for eJerk, from 5 to 15). Stuttering doesn't happen with the 2.0.7.2 release.
UBL is compiled but disabled, I attach my .h files, my M503 and 3 photos:
On STRING_DISTRIBUTION_DATE "2021-04-04" i can't see this defect anymore. FLSUN_Q5.zip
Well the solution is already there, isn't it. Thanks for making my machine works. I bump the z jerk to 2mm/sec and can speed up to 300mm/s on the xy. Of course, you have to have a robust design for Z axis. I have 4 z motors so I can set the jerk limit at 5mm/s. Either that or you have an extremely flatbed so z does not need to move at all!!
Please test the bugfix-2.0.x
branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.
watching
video of testing here https://youtu.be/x6NTq2Hkm9g
In the video you can see that it was only having issues when I moved x via firmware to X=30+. At that point, the y axis will stutter. Moving the X back to less than 30 removed the stuttering.
My printer has also been doing this. I noticed it as recently as Friday.
Funny though. I went to reproduce this, and now all of a sudden I can't. I will fiddle some more. What is important, I presume, in my noticing this.. is that I am not using Classic Jerk and have not for about two weeks now.. and it still happened to me.
It also happens on my duet printer, so I am thinking its more about math/formulas than it is about marlin specifically. Here's what I know...
Marlin/EEPROM config:
EEPROM Settings:
What else can I do in order to test/reproduce this? Am I missing some setting combination?
Well, ok. I take it back. I am now able to reproduce it as long as I am in the mesh Z plane (<= 10mm fade height). I set the values pretty high and it still happened. [ https://photos.app.goo.gl/EpTNrtXrQcteQuk8A ]
EEPROM Settings:
Full Configuration: cr10s5_devpeeps_cfg-issue-19217.zip
It doesn't happen at all if I am at X50/Y50/Z5 and move it to X350/Y350/Z50: [ https://photos.app.goo.gl/Zb629DWQFi2N73gr9 ]
But if I go from X350/Y350/Z50 to X50/Y50/Z5 it stutters all the way to the target even when Z is way above the fade height: [ https://photos.app.goo.gl/GEeYztAL83qbDXa18 ]
It is also REALLY obvious the stutter pattern happens over the mesh points. Please let me know what else I can do to help troubleshoot this.
are there any news on that ? I am using SKR 2 on BIQU B1 printer and having that scuttering too. it is happenning after bltouch install and only when ABL is on (g29 command or M420 S1). looks like something with the Z compensation is making those freezes. I tried to play with the Jerk value for Z, but nothing. did anyone figured it out? I am on marlin 2.0.7.2
Please test the
bugfix-2.0.x
branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.
@thinkyhead this is still occurring, even on latest bugfix. See my above comments for detailed reproduction.
@mydevpeeps you still suffer from the problem? it is for sure from the mesh , cause if I print with M420 S0 it is all good. I do not know what to do. I tried to disable the DJ TABLE LOOKUP but the problem persists. tried classic jerk but not helping...
edit: I tried now to disable S_CURVE and set Classic Jerk instead of JD, and it seems to work. I am testing it now in few prints and travels. I will update here.
Just to be sure, this is the problem you are facing too? (google drive video link) video
You can see in the video two printers running the same gcode. one with bltouch on, one without at all. you can see (and mostly hear) the stuttering in the travels. I will be happy for testing it out, but I need some guidance.
turning off S_CURVE did not solve the problem. does anyone have an idea for it? I have Ender 3 v2 with bltouch and no problem at all. the problem only occurs on the BIQU B1. I followed the config files of both printers and they seem the same (except for differences between motors, pid, etc) I am attaching my BIQU B1 config files. Marlin.zip
Increasing the Z acceleration limit resolved the stuttering issue for me.
My limit is 10000, though my acceleration is set to 575. Yes, it still happens to me. I will look at your config this week and compare...
On Sun, Nov 14, 2021, 8:02 AM Nick @.***> wrote:
Increasing the Z acceleration limit resolved the stuttering issue for me.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/19217#issuecomment-968286954, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGEMXIXAZBKRUPS63AGZWZ3UL6XMRANCNFSM4QRIURFQ .
The problem is in MARLIN 2,0.7.2 too, and the 2.0.9.2 version (actual) and the change on Z acce do not fix the problem
I’m currently working on some issues with acceleration which are likely contributing to this. It impacts both trapezoid and S curve acceleration.
While testing that I encountered another issue with CLASSIC_JERK which can make it decelerate unnecessarily between blocks. That may also be playing a role here.
This stuttering still seems to exist with Bilinear ABL enabled as of 2.1.1:
https://youtu.be/3pLBnRX1Ffo https://youtu.be/7-oYB8GjRTQ https://youtu.be/i3hcTgqbM84
Update: can confirm the issue is specific to Marlin as I reverted to stock Creality CRTouch firmware 2.0.8.27 and the stuttering ceased.
If it is the case that the only problem here is that the z jerk is too slow to follow the mesh on fast travel moves, I would actually prefer this not change for the following reason:
When not using z-hop, travel moves occur along the surface of a partially printed part. If you are below the fade height, the top layer of that part is in the shape of the mesh. If we were to disable the z mesh following for fast travel moves, I think we would collide with the part in this case, and I think this case is common.
I'm not sure there's actually a bug here, it makes sense for the firmware to slow down x and y if z can't keep up. That's better than taking an incorrect path through space which can cause damage.
Glad you posted this. I have this with a Robin-pro board. When you were describing your machine I thought it was one of my posts...
So, Robin Pro, IDEX, ABL, 310x310, stock jerk
SKR MINI E3, custom marlin firmware 2.1.2.3. I dont know how fix this issue. I cant modify Zjerk and pushing up z accel its not helping to stop stuttering.
When i go pass the z fade height, no stuttering occurs. Only linear advance enabled and abl (AUTO_BED_LEVELING_BILINEAR).
My bad, sorry. I have enabled ClassicJerk with Z up to 2 and its working fine (i thought that classic_jerk and linear_advance could not be enabled at same time, i need to study more, sorry again):
Could someone point me to right direction? Some guide?
Bug Description
This is
bugfix-2.0.x
commit d84aff701e10a49d5ccc69ce323fdb0fdb84b6dbLong travels exhibit stuttering movement when ABL is configured and enabled.
If I switch ABL off by
M420 S0
(or I could just home, as my config isn't set to turn it back on), or if I turn the Z jerk up a bit (to say 5.0), the stuttering goes away.I suppose you'll need a somewhat larger than usual machine to reproduce this, as it's not noticeable on short travels.
The affected bot uses bilinear ABL mode, with 9x9 probe points across a 320x320 mm bed, using a BLTouch clone for the probe. The bed has a slight bowing-down in the middle (i.e. like a bowl), and there's only about 1.1 mm between its highest and lowest points at the corners, if those details matter.
From the way it looks, each stutter occurs about where the ABL probe points are along the path, but it isn't too consistent (not by eye anyway).
The stuttering isn't harmful, per se, but it does make otherwise quick travel moves take noticeably longer than they otherwise would, which aside from costing time may cause or exacerbate oozing.
My Configurations
Marlin-configs-2020-09-22.zip EEPROM-big-HC.gcode.txt
Steps to Reproduce
G1
commands to move the tool back and forth between one corner of the bed and its diagonal opposite, and observe the behavior.Expected behavior:
Every travel should have a single acceleration, steady state, and deceleration phase regardless of any other properties of the machine.
Actual behavior:
Every long travel move exhibits multiple accel/steady/decel phases throughout the move despite it being a single move event if Z jerk is low.
Additional Information
Video of the issue (simply
G1 X0 Y0 F30000
/G1 X320 Y320
repeated three times):https://youtu.be/kf7Mtqefp3w