I’ve been trying to print the lid of this print: Chest of Superior Tracking and attempted it twice; both times I’ve had a major shift on the final layers, ruining the print.
In the first case (with the white) it failed at the same time as the second one, mid way through some black layers; the print then paused before starting white, claiming it failed to cut, and so I clicked retry in the hopes to salvage it later.
I uploaded the timelapse here: Watch bad1-timelapse | Streamable
The second case (without white) it failed essentially the same spot, with the exact same issue, same shift even - but this time the AI spaghetti detection triggered and so I just stopped the print.
I uploaded the timelapse here: Watch bad2-timelapse | Streamable
For context: I’ve been 3d printing on/off for the last 10years, and fairly comfortable taking stuff apart, so let me know if I need to. On the other hand, new to bambu, this is my first printer (H2D) that I got last week, and I’ve got ~160hrs on it, with latest firmware etc
In the mean time, I’ve triggered a full print calibration, and I’ve resliced the model and will kick it off a third time.
Unlikely related, but during prints with colour changes, poop 10-30% of the time doesn’t come off in the poop hole, and ends up on the bed. And prints often end with a line of filament coming out the nozzle it failed to wipe. Thought I’d mention it as its the only other issue I have with the printer.
Upload the file as both a STL or 3ml (is that correct?) and the gcode after slicing. I don’t think that it is the printer. Is the lid a separate file??
Timelapse can’t capture the data you probably need:
It looks like it is losing its position shortly after a filament change. Check your PTFE and filament route to make sure the toolhead can move to all 4 corners, quickly, and free of pulling resistance. You can run a multicolor benchy as a small test to see if it fails in the same manner.
I dont think that’s the case, its on black for the layer previous, but it does seem to happen on the first layer the pattern is applied (which is black on black) so layer 181 on my files above
Ive kicked off a different print which is taller to see if its somehow height related, but I suspect its not.
And indeed its odd, ive ran through various possibilities:
one off mistake, test: reprint
slicer error on gcode gen, test: reslice and view in another program
xy issue, counter point: none of the other layers have this issue and all three prints fail on the same layer, with identical shifts (even to the mm and direction)
z issue, test: im currently printing something taller, will check if it gets past this issue
Im kicking myself i didnt setup a camera to record the entire print, as i wanted to see if its somehow getting caught and slipping, or has really high acceleration
I had a printer that would do this layer shift, it was a temp problem affecting the motherboard. Your temps are low. Maybe run the gcode on a gcode viewer program. Certainly resplice with a different program.
So ive printed a different model and it was taller than this one infact - it came out just fine no shifting.
Im going to kick off the failed print a 4th time and this time ill record it failing in the hopes that enlightens me - I may just cut the model up and just print the failing part
There’s no obvious reason why it failed. it just begins the new layer shifted.
So ive tried reslicing, inspecting gcode, printing a different but taller model, printed just the top layers that failed; nothing is consistent except for this model failing the exact same way everytime.
The jump towards the left rear might trigger this.
The timelapse motion is not in the Gcode file, so it is something triggered in the printer itself.
I strongly suspect that the timelapse is causing this behavior.
As if the tool head wants to move outside of the printing area and causing the tool path to shift.
Possibly similar to the behavior someone else has when the skew correction done by the Vision Encoder on a large model drives the controller out of its limits also.
I didn’t know for a 100% sure, but looking at your video (seeing the motion to the left rear corner) and into the gcode file in Bambu Studio, where you can enable the “travel” moves, but there was no travel move in that direction on any layer.
Adding those things together was eventually the trigger.
First of all I am glad you are getting a good part now!
Secondly, this would definitely be a case to report to Bambu Labs, so they can take action on this.
@SupportAssistant please review this discussion on sudden layer shifts triggered by a Timelapse move.
And possibly review the topics regarding the Vision encoder triggering a similar layer shift behavior.
Is this a known issue?