[BFW-6795] Impossible Print? Repeated Print Failures - Arctos Robot X Pulley

[Luke2791]

Description of the bug

I have tried time and time again to print this part with no success. There are no apparent reasons (to me) why it should not be possible. This part has been successfully printed on many other printers (it’s part of a big open source project)… so I am surprised the MK4S has such a hard time with it. Others have printed this and gotten the same result (failed print due to layer shift)

My hope is that this is something that either firmware, software, or slicing can solve - and not a fundamental limitation of the printer’s hardware. Please advise if you are able!

For details, please see this Prusa Forum post and the subsequent conversation:
https://forum.prusa3d.com/forum/english-forum-original-prusa-i3-mk4s-how-do-i-print-this/impossible-print-repeated-print-failures-arctos-robot-x-pulley/

Thanks, -Luke

Prusa Forum Post - Impossible Print.zip

Project file & How to reproduce

This "X Pulley" 3mf file will not print on my printer without a layer shift in the geared/toothed section of the part:

Prusa Forum Post - Impossible Print.zip

Checklist of files included above

• Project file
• Screenshot

Version of PrusaSlicer

Version 2.9.0

Operating system

macOS Sonoma Version 14.7.1

Printer model

MK4S Kit (+ Enclosure Bundle)

[Luke2791]

Update: When I tried some of the "normal" (non-geared parts) they printed just fine. However, when I tried some of the other geared parts for this project, they also failed due to layer shifting. My new hypothesis is that something due to the shape/type/size of these gears is causing the layer shift on my MK4S. Perhaps a slicer or software issue? I also posted the issue on the Prusa Forum.

I am open to any ideas! As communicated previously and on the Prusa Forum - my printer is not the only printer that is struggling to print these...

Attached are some photos and the 3mf file of the parts that failed this morning (same layer shift issue due to geared parts).

2.9.7_GearParts2_Failed.3mf.zip

[u89djt]

First suggestion (from a fellow user): the high perimeter count means you'll get a hard pull through the teeth from the plastic shrinking as it cools. That will tend to lift the points of the teeth upward as the stucture bows in. The tool catching on those would be audible, so video the whole print with the camera aimed where you expect it to happen. It's happening in Y, so it's a failed bed motion because the tool is jammed. Once the layer shift has happened, those points don't line up for a while. After enough layers are deposited, it happens again.
Reduce the pull of the plastic. That needs slower speeds (and more fan if possible) for quicker shrinkage in place of just the most recent plastic, and/or fewer perimeters where possible.
Suggestions for experiments:
Print with two perimeters and reduce the speed.
If that doesn't shift, do it at normal speed. Then gradually increase the number of layers.
Try printing in PLA. PETG warps more.
My guess is that you'll have to print the teeth very slowly with 100% fan.
Why only shifts in the bed slinging direction? Probably an important question. I imagine crash detection dynamics are quite different.

[Luke2791]

Hi there! Thanks for the response @u89djt . Strangely - I finally could find someone who was able to print this on a Prusa MK4S. They used default settings, 4 walls, 30 percent gyroid infill, and didn't have any issues. They printed it at full speed too. So I don't know what's going on. That said - I have met others that had similar failed prints. So what I am after is WHY this is happening on my / MK4S printers - but not others (Bambu, Creality, etc.). As an update, I recently printed it again at 50% speed and only 2 walls, but sadly... it failed again. I have wasted over 1kg of filament on this part alone.

If someone from Prusa3D would kindly check into this and print a test print - that would be wonderful! The goal is to get the printer operating as it SHOULD :). i.e. - normal speed, 4 walls, and 30 percent gyroid infill which is possible on other machines. See attached 3mf file above.

[u89djt]

EDIT cracking spot from mix579 below
Honestly it doesn't seem strange - if you can cool the part properly while it's printing, warping should be less impactful.
Can you find out what conditions the successful print happened in? Cold room? No enclosure?
You've noted that you have an enclosure. As I understand it, enclosures are necessary for things like nylon, but not recommended for PLA and PETG.
See https://help.prusa3d.com/materials
One thing we know for sure is that your y axis is slipping when the tool hits plastic as the bed is pushed forward toward you as you face the printer.
You will hear that happening.
If it only happens when you're printing the thing that will obviously warp when it isn't cooled well enough, your problem is most likely warping. You can only fix that by cooling better by increasing fan speed and/or reducing the temperature of the air the fan is blowing.
My guess: collisions are happening in every direction, but your y axis is slipping at a lower force application challenge.

[mix579]

I tried to print the model OP provided on Prusa Forum, exactly the same result. Wondering if it's related to #4465

[Luke2791]

Thanks for your response, @mix579 . Hopefully a new patch will be sent out soon. Would love to know if you hear any updates!

@u89djt I have tried printing with doors closed and open, fan turned up, and still I am getting the same issue. As previously noted, I have checked belts and grub screws as well. The shift is also "small"... perhaps 0.5-1.5mm at most. So this doesn't look a typical belt tooth slip/shift or other typical shifting phenomena. This is my 6th or 7th printer... and I haven't seen behavior quite like this before. But maybe I am just blind and missing something.

I am using a hardened nozzle (0.4 obxidian), have the setting for hardened nozzle turned on, and I have increased the temp 10-15 deg C, accordingly to help with heat transfer.

[DanielBryars]

How funny @mix579 - I was printing (amongst other things) parts for the ARCTOS robot myself, I had to revert to 6.1.3 to print the gears:

[Mirek1953]

I also join DanielBryars: Above are written posts from u89djt but they seem like excuses to me and the things mentioned there just don't work. Can any of the FW developers here answer a simple question: Why can the same file that failed me on FW 6.2.0 in exactly the same way as seen above in the photos be printed under FW 6.1.3 without any problems, and therefore what did you developers mess up? Print settings: 0.2 SPEED, 4 perimeters gyroid padding 30%. So, gentlemen developers, who will comment on this? A zip print file of X pulley_1-test.3mf is attached.

X pulley_1-test.zip

[Mirek1953]

Just as a hint for developers, I want to mention that the shift of layers occurs when moving from perimeters that create gears to infill. In FW 6.1.3, this transition is completely smooth and the infill starts to print fine, in FW 6.2.0 during this transition, sometimes (and one could almost say always) there is an impact sound as if the nozzle hit something (even though there is nothing on the print) and after this sound there is a shift of the infill layer and thus the overall shift in the next layer. So, gentlemen, developers, you have something to think about. Again, the file chosen for printing is the same bgcode for both versions of FW!

[CZDanol]

This is likely a firmware bug, not a slicer bug. There is an issue for this in the firmware repository: #4465. Internal ticket: BFW-6795

[Mirek1953]

I do not agree with your statement that it is the same mistake as you describe. The described layer shifts also occurred when using a different fill. I am now downgrading the individual versions of FW and trying to find out on which version the error will not occur. And I never claimed that it was a slicer error. How could the slicer participate in this, when I present the same bgcode to the individual versions of FW.

[CZDanol]

I was merely trying to move the discussion to the firmware github repository. Here we are in the Slicer repository, which is maintained by the slicer guys, and us FW devs do not read things here unless prompted.

[Mirek1953]

O.K. I didn't notice it, I'm sorry. So is it possible to somehow move this whole thread to where it properly belongs so that continuity is not lost?

[Luke2791]

@CZDanol @Mirek1953 @DanielBryars let’s either mention this feed (with a link) in an existing open issue or create a new one with links/references and a summary back to this thread. If one of you would like to - feel free to- or I can do it in a few days when I have time again. I’m currently on travel for work. I’d like to be thorough tho - whoever does it. If it’s possible to include links to the Prusa Forum thread I opened, I think that would be helpful too. Thanks for all your help on this. Hope we can get this resolved.

[CZDanol]

I'm trying to arrange a transfer of this issue to our repo.

[CZDanol]

@Luke2791 could you please also attach the exact gcode you used?

[Mirek1953]

Another finding: I managed to document that the "impact" sound I wrote about above has nothing to do with the nozzle hitting an already printed filament on the board. This sound, and we can say "bang", is made by the printer itself in FW 6.2.0. I simulated printing without a filament in the extruder, so the printer was running idle and this sound sounded exactly at the moment I described above without the nozzle hitting anything. When using FW 6.1.3, the described transition is absolutely smooth without any disturbing sounds. During tomorrow (19.2) I will post here the videos from this attempt. And I also made experimental prints with various FW:
FW 6.2.0 failed
FW 6.2.0 RC1 failed
FW 6.2.0 alpha2 seems to be fine and there are no shifts
FW 6.1.3 perfectly fine.
I'll do experiments with FW 6.2.0 alpha1 tomorrow, but I think it's going to be fine.
With these attempts, I try to make it easier for developers to find a defect and narrow the space where the defect occurred. I hope they will appreciate it.. :-) :-)

[Luke2791]

@Mirek1953 you have gone above and beyond! This is fantastic. Thanks for your help in transferring the issue and following up on your experiment results. Appreciate your help with this too, @DanielBryars .

@CZDanol as requested, I have attached a sample 3mf file that does not print correctly on my printer. Please note - the layer shifts are small - usually 1-2mm (not 10+mm as some have experienced). However, these "small" 1mm layer shifts still cause the print to be useless since these small layer shifts mess up the gear teeth. Thanks for your help.

X pulley Failed Print.3mf.zip

[Mirek1953]

Attached are the promised videos of attempts to run the printer without filament. And I managed to install the latest FW 6.2.1 and do a test print. It turned out exactly as expected: The print failed and the layer shifted.

pokusFW.zip

[danopernis]

Thanks to all folks reporting this and taking time (and filament!) to help debugging this issue. This relates to #4465 We believe we have a fix ready and it is undergoing last round of testing. Hopefully we will release 6.2.2 version of the firmware soon.

[Luke2791]

Wonderful to hear, @danopernis ! Please keep us posted as/when you are able. Look forward to seeing the fix!

Also - for reference - I recently reverted my firmware to 6.1.3 - it is was able to print the aforementioned print just fine. So I can now confirm what the others have suggested.