[BUG] Layer shifting: Reports and solutions #12403
Comments
|
I'll chime in quickly to confirm multiple idex machines, and rolling back to 1.1.9 problem vanishes. Working on matching settings and trying to reproduce elsewhere now. |
|
If you have S-Curve acceleration, try disabling it and check if you still get layer shifting (see #12398). |
|
If possible, please narrow down to a specific date where the problem starts to manifest. This can be done in LOG2(n) steps by following this procedure:
In this manner the issue can be narrowed down to a specific date. References: #9487, #9768, #11047, #11479, #11577, #11801, #11885, #12239, #12365 |
thinkyhead
added
Bug: Confirmed !
Needs: More Data
|
Hello, I have the same problem on a CoreXY with a MKS SBase motherboard. I have done several tests in my case the deactivation of the S-curve acceleration does not change anything. I will test with the code versions as you request tonight. After having made many attempts to print the same G-code, the shift of the layers is not random. All the parts I have printed that all have the same offset (all the parts are identical). |
|
That is helpful information. I have so far not been able to reproduce the issue, so if it can be narrowed down to some specific change that will be very useful. |
|
To keep some of the discord info here as well, first user reports of shifts came to me on October 20th. I'll have another machine here Friday to give me more opportunity to test, since it only occurs on long prints it'll be a bit slow going to track down. |
My experience is similar. Using a branch from September 21st... I am NOT seeing the failure. UPDATE: I think I just saw a shift in both the X & Y axis with the September 21st code.... Damn!!!! |
|
Test with the version of October 29th last night same problem. I do a test with the version of October 15th tonight. |
|
I flashed Oct 13th last night and am running things now. |
|
version of October 15th same problem for me. |
|
October 1st version no layer shift for me it's okay. |
I'm not sure that is true! Would you mind doing another long print with it please? I'm pretty sure I saw a dual X & Y layer shift with the September 21st code. |
|
First photo firmware on October 1. The screws show the offset of the layers well.
|
|
Omg so much??? Good to know I have 1.1.9 bugfix for now |
|
So, sounds like some change between Oct 1-15 is affecting some (so next try Oct 8). And maybe something from around Sept 21 is affecting others (so next try Sept 25). I'll look at changes between Oct 1-15 and see if there are any suspect commits. |
|
I did a test at the 7 cotobre (last committee of the day) no problem. I'm trying again on October 15th I have a doubt about the firmware I flashed for the test on October 15th (sorry). Do you want my configuration files? If it helps, I use the same ones for each compilation. Edit : No problem with the code of October 15th (still sorry) so for the moment: October 15th ok / October 29th not ok. Next test with the October 21 version. Edit 2 : October 21th it's ok |
|
i'm losing steps with the latest 2.0.x too, i'll try to rollback to 1.1.6, which some people are reporting is working fine. I'm using a corexy with tmc2130 |
|
What low level things are different between 2.0.0 and 1.1.6 ? It is probably not a stepper driver losing steps because of timing differences. The reason I say that is with IDEX machines in Duplication mode, both extruders are losing position at the same time (and the same amount). It feels more like a set_directions() call is missing or getting out of phase with other things happening... |
|
I still had issues with Oct 13th here. Just flashed Sept 27th and I'm running again. I'm using the same 30hr gcode for every test. 2nd idex machine got delayed, didn't see it occur on the singlenozzle crx. Still more to go... |
I'm using the exact same .GCode file. And on that print, I had a small X Axis shift after about 10 hours. And that is with the Sept. 21st code base (bugfix 2.0.0). |
|
If Sept 21 is bad, then try Sept 1 and see if it works. If it does, then try Sept 10, and so on… Too bad we can’t find a short print that consistently causes the issue to occur. I will look at the |
|
I'm going all the way to the 1.1.9 release date of 2.0 since we don't see it in 1.1.9 but have yet to find a good 2.0 date. Just built aug3rd (3 days forward but the couple commits are minor and stop idex crashing was pulled from 1.1) |
Actually.... I've gone a different path. I loaded up the current 1.1.9 and back ported a few things I need into it. I'm 8 hours into a print and so far, no problems... If the print finishes OK, I'll kick off another large print on it to confirm the problem is not on 1.1.9. |
|
I wish that would tell us about 2.0, but who knows where the problem lies? It might be associated with display update, serial communication, G-code parsing, or any number of things. But if you happen to port something into 1.1.9 that causes bad behavior, that would be a great find. |
|
Fyi I'm using SD to eliminate serial errors and monitor from my PC while it's running. |
|
@InsanityAutomation my screen and sd support are disabled, i'm printing trough octoprint. so i dont believe they are causing the problem. i |
|
Earlier on, I was printing petg with a Marlin BF2.0 nightly build #5 which I recompiled yesterday. I'm running an BigtreeTech SKR1.1 (LPC1768) with TMC2130 on all axis. I tend to run stealthchop on x and y axis to keep the noise down. With the default acceleration values of Marlin (3000), I had again skipped steps on the Y axis although I'm running a beefy 2.8A 48Ncm 0.9°/step motor with approx 900mA current and 16 microsteps. The TMC2130 has a big heatsink glued on it (10x the size of a stock one) and is forced cooled. So I can rule out overheating and skipped steps due to this. Only after putting the Y axis acceleration back to 2000, it was working fine. I'm now going to reduce the microsteps to 8 as I don't need that precision with a 0.9° motor. |
|
I just wanted to mention: During probing with G29, sometimes accelerations come with a "thumb" noise, and sometimes they don't. I experimented with lower currents while homing and probing but that led to stalls, not during (sensorless) homing but only while probing. Board is MKS_SGEN_L, TMC2130, bugfix branch. |
|
I noticed a layer shift on my Ender 3, Marlin 2.0.5.3, the board is SKR E3 DIP, TMC 2208 UART. If ADAPTIVE_STEP_SMOOTHING is enable |
|
TLDR: EMI was messing with uart communications on tmc2208 and making the drivers freak out. I got an btt SKR E3 dip v1.1 board with 2208 drivers running in uart. i got random layer shitfting and firmware setting changes seemed to work randomly. Initially it looked like driver overheating and skipping steps momentarily but no they were not overheating.
Eventually i tried using the drivers in standalone mode and it worked just fine. I have not tested it out further because i want to get back to printing, but to me it does seem like EMI is messing with the tmc drivers for short periods somewhat similar to an overheat |
EMI can also be caused by heating the bed or extruder. On my SKR E3 dip v1.1 board, when the bed is warming up, the usb stops working. |
That sounds like a poorly designed board or a missing ground connection to the shield. |
|
An update from me: I downgraded my board to a ramps, running the TMC 2209s in standalone, and was still getting layer shifts. So that ruled out the skr 1.3. the problem seemed to be occurring more and more frequently, so it appeared to be something degrading. So I checked my mechanicals again, and I had one failing bearing. I didn't notice it last time I checked so it must have got worse since then, which matches the increase in frequency I have observed - replaced all bearings on that axis (y) and have printed for 60+ hours with no sign of the issue. |
|
I also noticed that during nozzle cleaning (the nozzle moves back and forth over a brush) some movements are smooth while others produce a "knocking" noise. Same as during probing moves. Feels like it omnits the acceleration phase.. It appears to happen randomly. Repeating the same move may produce the noise, or it may run smoothly. |
Just out of curiosity, did you uncomment "monitor_driver_status"? I just noticed that I had that on and Martin was reducing my current down to a point where i was missing steps and I'm 99% sure that's what's causing my layer shifts. After turning off "monitor_driver_status" and selling my current a touch higher I haven't had any layer shifts. |
|
I just finished hooking an SKR ver1.3 board to my Tronxy X3A printer. The Z steppers are in parallel. I am using 2130 stepper drivers. I am running Marlin 2.0.X The board is controlled by OCTOPI running on a PI B+. Vref pots are at the factory setting. Any attempt to run stealthchop at print speeds higher than 20 mm/sec results in extreme layer shift. Increasing current in software does not seem to help. Hybrid threshold seems to be ignored. With stealthchop off all is well. I will test with monitor_driver_status commented and see if the situation improves. At worst I will just leave stealthchop off. |
|
@bill-orange I have stopped investigating this for now, but my suspicion is that none of the cheap board manufacturers are implementing the TMC steppers correctly. There is a lot more to it than just plopping it in as a replacement (counter to what TMC claims). Looking through the datasheet it seemed that managing EMI, grounding, proper filtering and noise management is crucial. In addition, when using StealthChop, the current requirements and the torque trade-offs are unique compared to the legacy A4988. To give you an example, if you look at any appropriately designed printer for robust use (think Ultimaker, Zortrax etc.), they all have proper ferrite beads, sufficiently powered PSUs and well designed circuit boards (such as sectioned ground pours to manage EMI). |
|
FYI - a lot of my layer shifting and quality problems went away when I reduced my travel speed to the same as the print speed. |
|
I had Y layer shifting happening on a 2.5 hr print. 15mm high part. I have noticed a few other issues....those are other topics. I am going to slow down the max_accel and see if that helps. |
|
I experienced layer shifts again on my Ender 3 that had firmware rev 9c02115 last night, printing https://www.thingiverse.com/thing:2318105. I'm trying again with latest. Using LA, classic jerk, no scurve. With both the old and new firmware build, the circles are all printing with rapid oscillation between fast and slow motion, also visible in the extruder gear rapidly twitching back and forth (due to LA adjusting for the speed). But so far the new has not produced a layer shift (midway through the print now, but past the point of the first shift from last night's). I suspect there was a hard bug causing the shifts (#16128 seems to have been merged before the version I was using, though, and I thought it had already fixed the problem I was experiencing in the past) as well as bad motion behavior making it more likely to be hit, with the former resolved and the latter still present. One other data point: menu UI is now fully responsive during printing. Before it would randomly stutter or miss input, like a load or interrupt timing problem. |
|
Nope, it's shifted again now. F... |
|
I am getting some layer shifting on my prints but it shifts back and forth on the X axis mainly. See attached pic. I am not sure if its the same issue as this bug but I have done so much testing and ruled alot of things and now I am thinking its the firmware so I just started testing that. I also noticed that this happens mainly at higher heights (greater than 100mm) and gets more pronounced the higher it gets. Did anyone try anything that worked?
|
Have you tried the various things people have mentioned above int his thread? |
|
Hi folks . |
I have tried the following: Test #1
Test #2
Test #3
There are alot of posts in this thread but I think I tried everything that worked for others. If not, let me know. What should I try next? |
|
This issue is stale because it has been open 30 days with no activity. Remove stale label / comment or this will be closed in 5 days. |
|
Pinging this because it probably should not be auto-closed. |
I personally think this should be closed, and new issues reported for more specific failures. This has encompassed so many issues over such a long period of time that it is really no longer clear what it contains (unless people feel like reading all 460+ replies). |
|
Fair enough. |
|
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. |
|
Discussion currently being continued at: #19151 |
and others
Is anybody else seeing layer shifts on BugFix 2.0.0 ? I'm seeing one or two of them on long prints. I'm seeing them on the X-Axis (and mostly in the negative X direction).
I'm running an IDEX machine. So mostly, I'm asking if anybody is seeing layer shifts on non-IDEX machines.
Anybody???
UPDATE: I think we know this problem affects non-IDEX machines also. If you are seeing Layer Shifts, please update this thread and let us know what you are seeing.
The text was updated successfully, but these errors were encountered: