[bug] Layer Shifts on bugfix-1.1.x and 2.0.x

[viperchannel]

Description

Random layer shifts on different heights on both x and y axis, sometimes on both, sometimes just on one axis, reducing speed, acc and jerk, raising vref does not show any improvement. (tried reducing it to half)

Sometimes it happens on the second layer, sometimes after 2h. I checked all the mechanical parts; they are fine, and if I go back to a bugfix version from january it works fine without any shifts.

Steps to Reproduce

The only differences between my working jan bugfix (as far as I can remember) and the current 1.1.x bugfix and 2.0 bugfix that I made are:

Activating Babystepping Activating Fade Z Both config files are attached, the working Jan version and the 2.0 Version Configs.zip

Additional Information

This is my first Bug report, this is not my native language. I tried my best, let me know what additional information you need.

[thinkyhead]

Layer shifts are usually a mechanical issue. As far as we know there's no randomness in Marlin. If an issue occurs at some point in a G-code file, it will always occur at the same point in the file. Can you provide a G-code file that demonstrates this issue consistently?

[viperchannel]

I dont think its a gcode issue. The objects in the slicer dont show that behavior in the preview. Also the heigth of the shift is always different. If I print the same file multiple times, sometimes it happens in the second layer, sometimes it works fine untill 2h midprint. I printed an object at least 5 times, everytime it was different, sometimes on X, sometimes on Y. Thats wh I don`t think it is a mechanical issue, since the axis change. Then I flashed from 2.0 to the latest 1.1.x bugfix with the same issue. In both cases I reduced Acc from 1600 to 800. raised an lowered Vref, decreased feedrate to 70%. Then I switched back to my january build, printed the same object (had to slice it again, the only setting I changed was the K value in the startcode to a v1.0 value) and it printed absolutely fine. Could it be, that I somehow reached the cpu capacity of the adruino? I have no idea what else it could be. What I also did: More cooling on the steppers, but they stay cold anyhow. Powered my ramps with and deactivated the diode, so it does not use the arduino VR. (thought it might be caused by dropping 5v because of power consumption) Loosend and tightened the belts removed the belts and made sure all axis move extremely smooth checked the aligment of all axis mit a micrometer Sliced the file multiple times printed with different materials, that require higher and lower bed temperature

I really have no idea what to do else. And since it works with the older marlin version, I think it has something to do with the fw

Oh and btw, the shifts aren`t huge shifts. They range from around 0.5-2mm, but I never measured them.

[viperchannel]

Here is one of the gcodes I have used. The object had a shift in X direction at around 2.1mm heigth, than another one in the opposite direction 1.63mm later, and after another approx 3.3mm it had a shift in Y direction. Before that I printed 2.5kg of the same filament, same kind of objetcs, same slicer settings (exept K value because of V1.0 and 1.5) on my january build with no problems at all. failed object.zip

[teemuatlut]

Could be your drivers overheating. You say you increased cooling for steppers but not to drivers. You also increased Vref that increases heat output. Lowering it to half would likely lead to insufficient torque and to skipped steps.

[viperchannel]

Sorry, I ment the drivers, not the steppers. I have increased cooling on them, but that was not the reason, eaven with the smaller fan, they did not get noticably warm. I just didn`t know what else to do and wanted to eliminate as many reasons that could cause the problem as possible. Adjusting Vref was just a try, it did not help at all. Motors never got above 45°C btw.

[itmachinist]

If you have Z fade with a small number and you have a very uneven bed your nozzle will rub on layers and then cause shifting. you could try increasing the M420 to make it fade over a longer distance.

[viperchannel]

I have also aready though of that. But some shifts happened before reching the fade height and some 20mm after. With a 0.2 layer heigth, thats a lot of layers. I have also tried to move the axis while printing by hand. Thats nearly impossible it has so much torque, i would rip my extruder off the mount bore skip a step. My thought are, that all the calulations like fade height, bed leveling, linear advanced, babysteps somhow max out memory or buffer during a print. Or it has something to do with linAdv 1.5. I have no idea if that is realistic at all.

[autonumous]

I’m currently investigating a similar issue, trying to determine if firmware related or something else.
Had two 5 hour+ prints which have suffered layer shifts in the Y direction.
Initial print was with ABS and had some warping, so i thought might have been with the nozzle hitting the print. 2nd attempt, resliced and used PLA, same result. layer shifts at different heights, always in the Y direction

I'm trying to replicate with simpler, quicker prints that i can observe. All ok so far.

Printer has been fine previously.

[thinkyhead]

Keep experimenting. Disable various features. Test various settings for acceleration and jerk. Etc. The most important thing will be to narrow it down to a single causative factor.

[viperchannel]

I can already tell, that is is 100% caused by the firmware or one of its functions. I did not have a single print without shifts on the newer firmwares and as soon as I switched back to the old one, I didn`t have single shift. Had it printing for 16h yesterday on various prints, including identical gcodes that had shifts with the newer versions with the exact same mechanical, acc, jerk, vref etc settings and not getting a single shift while using the old version.

[Jartza]

I can confirm this with the 2.0.x bugfix -branch. After updating from 1.1.5 there is sometimes "loud thunk" and erratic moves in the middle of print (my printer if very silent normally and these "thunks" didn't happen with 1.1.5) and I'm also experiencing layer shifts, even with prints speeds of 50mm/s (1.1.5 goes fine with 80mm/s). I'm sure there is no mechanical failure or problem with stepper controller reference voltages, I've played around with different accel & jerk speeds. I even tried the BEZIER jerk and while it makes the overall printing smoother, the erratic moves are there.

I try to experiment more during weekend and if possible, make some comparisons with different values.

[LichtiMC]

Finally an issue regarding the TMC2130 layer shifts which occur with the bugfix-branches! I'm experiencing the very same behavior as you guys are describing.

[teemuatlut]

It's possible that I'm seeing the same behavior. I'll need to start eliminating commits and see which change introduced this. If any.

If you guys want to try something, turn off MONITOR_DRIVER_STATUS. That way there will be no communication to the driver after the initial setup.

[viperchannel]

I am kind of happy, I am not the only one that has those issues. I am currently running the TMC2208 on my printer btw. so I do not use SPI.

[teemuatlut]

Also judging by the initial report, this is not isolated to TMC drivers.

[LichtiMC]

OK, may be, just saying I never had any of these problems with the A4988 drivers. This could be because of the less torque of stealthchop though...

I even changed to much oversized stepper motors (400mA to 1700mA, H-Bot) but still I get these layer shifts.

[Jartza]

This could be because of the less torque of stealthchop though...

It is not, I'm running TMC2100 on my printer and it has been condigured to use spreadCycle mode

[Jartza]

Also judging by the initial report, this is not isolated to TMC drivers.

Correct, my other printer (Tevo Black widow) has drv8825 and the same issue seems to bother there too, erratic looking moves that are louder than normal printing, although no layer shifts (yet) as I'm driving steppers with more force.

[Jartza]

Same gcode-file with 1.1.5 (except modified lin_advance value):

[ejtagle]

@Jartza: Could you post your DEFAULT_AXIS_STEPS_PER_UNIT and your DEFAULT_MAX_FEEDRATE ?

A long time ago, when i switched to the bugfix2.0.0 branch, for my printer, i need for the Z axis STEPS_PER_UNIT = 4000, and if i set MAX_FEEDRATE to 3 or more, the Z axis does not move, but it does a horrible noise (brrrr, but with some discontinuities). I am pretty sure there is some overflow in computations somewhere, never investigated them. Maybe that is being triggered somehow in some strange case also

The way to reproduce always reproduce it is:

define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 4000, 97 }

define DEFAULT_MAX_FEEDRATE { 300, 300, 4, 30 }

And try to move the Z axis with the LCD menu...

[Jartza]

#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 400, 96 } #define DEFAULT_MAX_FEEDRATE { 150, 150, 8, 50 }

There is limit how much 8-bit cards can output steps.

I also have #define MINIMUM_STEPPER_PULSE 2

[Jartza]

Printing regular 20x20x20 calibration cube, there's almost always now loud "thunk" also when the the perimeter has been printed (there is just very short move command). I tried to record it on video, but the "thunk" is so low frequency that cellphone mic didn't catch it but it's very audible by ear :)

[itmachinist]

I have my current printer on an old build of 2.0 and its running fine, so ill upgrade it to the latest and let you know if there is any clunking/shifting or whatnot. Ill look, but i might be able to figure out the date i downloaded it and ill know what commit its on.

[Jartza]

My 2.0.x is less than week old, but I will update later today to latest bugfix-2.0.x to see if it helps any.

[Jartza]

Ill look, but i might be able to figure out the date i downloaded it and ill know what commit its on.

Try git log -n1 to see the last commit :)

[viperchannel]

My 2.0 was april 11th, the 1.1.x bugfix was april 17th.

[viperchannel]

By looking at Jartzas pic, i noticed that my shift is different. It looks like his print shifter over several layers. It looks like the little house started to continously move to the left. My shifts are just one layer. For example, it starts the print, after several perfect layers, it shifts in one direction and stays there for a while, untill the next shifts happens. I dont have shifts that stack up on several layers like on the pic

[Jartza]

@viperchannel that's the most rad example. I searched for mechanical failure and tested belts, wheels, bearings etc. from my printer because I had sudden layer shifts in 1-2 layers in some prints and first thought was of course mechanical/electrical issue. After checking everything, I reflashed 1.1.5 and redid the prints with same gcode without any issues (or clunking)

[gloomyandy]

Are you all using UBL? If so you might want to try the very latest (as of a couple of hours ago) bugfix version. There has just been a fix made to the way that UBL handles moves that may have some impact on this (but may not).

[viperchannel]

I was using #define AUTO_BED_LEVELING_BILINEAR on all versions.

[ejtagle]

@Jartza I would agree with you, but i am using an Arduino Due (32bits) and the problem is exactly the same. If i get some free time, i´ll start debugging...

[thinkyhead]

I can already tell, that is is 100% caused by the firmware or one of its functions. My 2.0 was april 11th, the 1.1.x bugfix was april 17th.

I'm unable to reproduce the issue, unfortunately. I now have a small pile of perfect Benchy boats. I'll see if adding enabled features from your configs causes the issue to appear and if I'm able to get the issue to manifest then I'll be able to start narrowing it down to some point in time, and maybe a specific commit.

bugfix version from january it works fine I reflashed 1.1.5

Many changes since January (and since 1.1.5), but I'll do a comparison and see if anything stands out. If you can determine the most recent version or commit where the problem is not present, that will be super helpful.

[thinkyhead]

@viperchannel — Have you tested with LIN_ADVANCE disabled to see if that feature is contributing?

@autonumous — Please zip and attach your configurations.

[viperchannel]

Not yet tested without Lin adv. I will give it a try over the weekend if I find some time.

[Jartza]

@thinkyhead by disabling LIN_ADVANCE do you mean completely removing the define, or just setting the value to 0?

[thinkyhead]

Try both, as time allows.

[Grimshadows]

This is definitely a firmware issue, the machine is randomly going full speed ignoring jerk in tight spaces. It just goes to full speed in the Y direction only. I can tell that it happened from the loud "thunk" that penetrates my walls and vibrates the floor. This started happening when testing non linear prints. It wont do it on prints that simply move in straight lines. If the print has a curve, like a pipe or tunnel whos diameter is on the horizontal plane it will do it. I can visually see that the machine it self is moving faster in certain palces than I set it too.

I can send you the file i am trying to print or gCode and my configuration files if you need. There is something about this firmware that it's not obeying speed and jerk limits and it's torque ripping the Y axis out of step.

let me know what you need, I think I can say this is 100% repeatable at this point for me. Even switched out stepper drivers, got tons of them laying around since it's cheaper to buy them in lots of 4. Standard A4988.

I am really going to hate downgrading firmware for now, all these new features are nifty to have.

[autonumous]

that explains why I’m not able to reproduce with simple models. Simple cubes came out fine. Just tried a benchy had had a very slight layer shift, whereas the “curvy” model i was previously printing had many many layer shift.

[Grimshadows]

Yep simple cubes come out 100% fine, add curves in tight spaces with walls it goes bonkers. All this prints just fine on 1.1.8:

[thinkyhead]

I can send you the file i am trying to print or gCode

@Grimshadows — Please do! I would like to test with the G-code that gives you the most trouble — that cylinder, for example.

[viperchannel]

Some reported they are using the 2130 tmc. Wouldn't they stop the print when overheating and report a driver error? I have also already done the cooling experiment and switched from a 40mm fan to a 120mm fan and still had the shifts.

[thinkyhead]

(comment deleted after reviewing the thread)

[Grimshadows]

@thinkyhead Skimmer Intake Venturi.txt

One thing that I did forget to mention earlier because i hadn't noticed yet. Is that this is also making my extruder overshoot too. To the point that it feed enough filament to snap it inside the extruder just after the gear, My extruder is setup to have a ton of torque when needed enough to break the line if it cant pass through (I have only ever seen that with a clogged head, this head is not clogged). The Y axis torque rip and the extruder over shooting filament seem to happen at the same time.

I am going to try printing using another engine, giving Simplify a swing to see if the behavior is Cura related.

[thinkyhead]

Thanks! I will test it later today and see if I can reproduce the issue. I hope that I can, really, because then we'll all be on the same page!

[Jartza]

@Grimshadows I "dry printed" the gcode (without filament and temps to 0) and I think that's very good model to find out the problem as the printer really shakes violently with that gcode. Maybe I should test print with filament too 😆

[Jartza]

@thinkyhead looks like disabling LIN_ADVANCE either by setting it to 0.00 or undefining LIN_ADVANCE has no effect on this...

[Grimshadows]

@Jartza Those speed settings are really really toned down from the speeds this thing normally runs at. I toned them down thinking it was a speed issue. Doing a run with simplify now at my normal speeds, lets see if it's the slicing engine. i'll give an update in about 35 min. violently shaking is ok as long as im not hitting the chassis harmonic frequency.

[viperchannel]

I am pretty sure, my motors were much warmer on the bugfix versions than they normally are. If you are switching between versions, take a look at that. I cannon play around this weekend, I have some prints I need to get finished first.

[Grimshadows]

Skimmer intake-S3D.txt

Ok, ran the print in Simplify.... So... it may not be the Firmware after all not one skip. I don't even have S3D setup for fine tuning and calibrated for this level of detail. i mainly have it set up for speed. So there must be something that Cura is doing different with the slicer than S3D. I think I am going to calibrate S3D at this point and run with it. I don't want to give up the features gained in 1.1.8. Still doesn't explain why linear shapes print fine on Cura but not curved objects.

Video Link if your curious,: https://youtu.be/FyQbR1NfjtM yes... my tripod is a 3.5 inch VISE.

[viperchannel]

I did all my files in simply and had the skips. So it's not Cura that causes it