-
Notifications
You must be signed in to change notification settings - Fork 245
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] After print finished it does a homing & purge sequence no line but then crashes into the part if its too tall #733
Comments
Hi, I have a very similar issue except the printer starts the mesh bed leveling sequence instead of purge. I'm also on 4.1.0, I tried 4.2.0 and still happens there. Never happened 4.0.5. I've tried a different USB stick and re-flashing firmware. Also factory reset a few times. For what's it's worth, I upgrade from 4.0.5 > 4.2.0, noticed the bug, then downgraded back to 4.0.5 and up to 4.1.0. See my post on the help forums including a video: |
Bjerg, Malcolmcmreal |
seems malcmcmreal´s trouble was the G80 at the end part of the G-code which is another way of asking for MBL |
Yes of course here is my gcode. its only happening with 4.1.0 and up Btw my estep is 415 because i have another extruder on first one is with 415 estep last one is default happens with both. Shape-Box_0.2mm_PLA_MINI_16m415.zip Shape-Box_0.2mm_PLA_MINI_16m (3).zip woops forgot the 3mf file |
I've replied in the Prusa forums (https://forum.prusaprinters.org/forum/hardware-firmware-and-software-help/immediately-after-successful-print-mini-goes-into-mesh-bed-leveling-procedure/#post-240376). I tried without the G80 and my issues persisted. By the way, the reason I added the G80 in the first place was to try and stop the steppers from moving post print. The problem was there before my G80 addition. My printer has changed it behavior again, it not longer trys to mesh bed level but now just immediately returns to home post-print. It moves the Z and Y axes at the same time. This happens with and without the G80. Similar to Bjerg, I also have another extruder (Bondtech) with same 415 estep. Here are my files: |
I am investigating, as all of you has inserted user G-codes, and from G-code is not that simple what everything you have changed - stay tuned |
Gentlemen, can you do me a favour? Post here all G-code changes and places where you inserted you custom G-code? |
Hope this helps, I've only changed my start and end gcode in slicer. Changes I've made are in bold START GCODE |
Bjerg, |
@zoltan-l just tried it only happens with M92 enabled without it does not. on 4.1.0 and up |
@Bjerg |
I think I have found the issue in #864. I am seriously wondering if my issue was causing similar problems to the ones in this ticket. |
This issue is also happening with my printer. Only G-code change that I ve made was adding "M92 E415 ; set e-step for bondtech extruder". |
Hello. I've found a way to prevent this until there is a fix. As we know Bondtech gives us 2 solutions When I start my printer first I run that Gcode . By this way even if I swap filament or do a first layer calibration it does not underextrude and finish the prints as it should be. I have removed the M92 E415 from Start Gcode I don't know if people figured this already but just wanted to share it. |
Multiple M92 axes on one line will trigger the problem on roughly half the prints on my MINI: I separated the axes onto multiple lines and have not seen the problem for weeks: |
Has this been resolved with the new release candidate? I am having the same issue with 6 of my minis. All have the bondtech upgrade. |
The bug has not been resolved in the new firmware update. I just flashed one of my minis and ran a test print. The same issue occurs. |
Maybe we should add that installing the Bondtech requires the M92 but also requires swapping some wires on the buddy board. See steps 33-34 https://support.bondtech.se/Guide/01.+Feeder+Upgrade+Kit/59?lang=en maybe that has something to do with it |
I am not sure why swapping extruder wires would cause the end Gcode to
lower to the back left hand corner.
I tried a print without m92 and It did not move to the back left hand corner. So it’s likely a bug related to M92 and the firmware. Apparently an
earlier firmware did not have the issue.
…On Fri, Dec 18, 2020 at 10:30 PM malcmcmreal ***@***.***> wrote:
Maybe we should add that installing the Bondtech requires the M92 but also
requires swapping some wires on the buddy board. See steps 33-34
https://support.bondtech.se/Guide/01.+Feeder+Upgrade+Kit/59?lang=en
maybe that has something to do with it
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#733 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AO2PYQ6DIPKV2IMMZTTMIOTSVQM4XANCNFSM4PLWYZCA>
.
|
I have the factory extruder on my MINI.
When I added the M92 command, with multiple axes on one line, the problem
started for me:
M92 X100.6 Y100.8 Z401.0
I then split it into multiple M92 commands, one for each axis, and the
problem has never happened since:
M92 X100.6
M92 Y100.8
M92 Z401.0
Randy
…On Fri, 18 Dec 2020 at 22:35, hamlinjacob ***@***.***> wrote:
I am not sure why swapping extruder wires would cause the end Gcode to
lower to the back left hand corner.
The other print you sent me finished. It did not move to the back left hand
corner. So it’s likely a bug related to M92 and the firmware. Apparently an
earlier firmware did not have the issue.
On Fri, Dec 18, 2020 at 10:30 PM malcmcmreal ***@***.***>
wrote:
> Maybe we should add that installing the Bondtech requires the M92 but
also
> requires swapping some wires on the buddy board. See steps 33-34
> https://support.bondtech.se/Guide/01.+Feeder+Upgrade+Kit/59?lang=en
>
> maybe that has something to do with it
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <
#733 (comment)
>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AO2PYQ6DIPKV2IMMZTTMIOTSVQM4XANCNFSM4PLWYZCA
>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#733 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIFH6BOGMDABRLPORORGICDSVQNOPANCNFSM4PLWYZCA>
.
|
@hamlinjacob Are you using a USB extension, by chance? I had to remove that as well as replacing my USB stick and my issues went away. Both the stick and extension work fine for normal PC use, but I think there is something else involved that I am missing. |
I am using the original silver plated usb that came with it with no
extension cord.
…On Sat, Dec 19, 2020 at 12:07 AM Matt Deren ***@***.***> wrote:
@hamlinjacob <https://github.com/hamlinjacob> Are you using a USB
extension, by chance? I had to remove that as well as replacing my USB
stick and my issues went away. Both the stick and extension work fine for
normal PC use, but I think there is something else involved that I am
missing.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#733 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIFH6BNX3ZJPUJXBUYCNAJ3SVQYIFANCNFSM4PLWYZCA>
.
|
I am not using a usb extension. I am using a different thumb drive though.
This is also happening through multiple minis. After removing M92 E412 the
issue isn’t there.
Does anyone know what the normal esteps for the mini is? Can we overcome
the Estep issue by increasing flow or extrusion multiplier?
On Sat, Dec 19, 2020 at 8:05 AM ModelTrainNut <[email protected]>
wrote:
… I am using the original silver plated usb that came with it with no
extension cord.
On Sat, Dec 19, 2020 at 12:07 AM Matt Deren ***@***.***>
wrote:
> @hamlinjacob <https://github.com/hamlinjacob> Are you using a USB
> extension, by chance? I had to remove that as well as replacing my USB
> stick and my issues went away. Both the stick and extension work fine for
> normal PC use, but I think there is something else involved that I am
> missing.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <
#733 (comment)
>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AIFH6BNX3ZJPUJXBUYCNAJ3SVQYIFANCNFSM4PLWYZCA
>
> .
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#733 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AO2PYQYOPM5B2NTVRZDPQO3SVSQK7ANCNFSM4PLWYZCA>
.
|
I've never used Set Axis Steps for the Extruder on either my MINI or MK3:
M92 Ennn
I use Set Flow Percentage instead: M221 S103.26 in my case, copying how the
factory MK3 gcode tweaks it to 95% flow to hide an old glitch in Slic3r.
Randy
…On Sat, 19 Dec 2020 at 08:23, hamlinjacob ***@***.***> wrote:
I am not using a usb extension. I am using a different thumb drive though.
This is also happening through multiple minis. After removing M92 E412 the
issue isn’t there.
Does anyone know what the normal esteps for the mini is? Can we overcome
the Estep issue by increasing flow or extrusion multiplier?
On Sat, Dec 19, 2020 at 8:05 AM ModelTrainNut ***@***.***>
wrote:
> I am using the original silver plated usb that came with it with no
> extension cord.
>
> On Sat, Dec 19, 2020 at 12:07 AM Matt Deren ***@***.***>
> wrote:
>
> > @hamlinjacob <https://github.com/hamlinjacob> Are you using a USB
> > extension, by chance? I had to remove that as well as replacing my USB
> > stick and my issues went away. Both the stick and extension work fine
for
> > normal PC use, but I think there is something else involved that I am
> > missing.
> >
> > —
> > You are receiving this because you commented.
> > Reply to this email directly, view it on GitHub
> > <
>
#733 (comment)
> >,
> > or unsubscribe
> > <
>
https://github.com/notifications/unsubscribe-auth/AIFH6BNX3ZJPUJXBUYCNAJ3SVQYIFANCNFSM4PLWYZCA
> >
> > .
> >
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <
#733 (comment)
>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AO2PYQYOPM5B2NTVRZDPQO3SVSQK7ANCNFSM4PLWYZCA
>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#733 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIFH6BP2AOCSK6AICLGCSHDSVSSNXANCNFSM4PLWYZCA>
.
|
Guys, |
I am not going down that rabbit hole again. 🤣 |
I just added a pause to the end of the print file before end gcode and it is another easy workaround. |
The issue still isn't fixed with the latest firmware update and slicer update :( |
I think this is the PR for the fix: #1217 It's going to be in a future release soon, hopefully. |
Correct |
@Bjerg this issue should be fixed, can you confirm it and consider this issue to close? |
Hello guys. I believe Jo Prusa said that e-step values will be adjusted via screen. When this will be implemented? |
@JohnnyDeer its working now no more weird behaviour after print finishes ill close the issue for now |
Printer type -
Mini
Printer firmware version-
4.1.0
Original or Custom firmware
Original
Optional upgrades -
Filament Runout Sensor
USB drive or USB/Octoprint
USB
Describe the bug
After print finishes it homes and makes the purges line move but does not purge only happens after upgrading from 4.0.5 dont think i saw the behaviour in 4.1.0 RC1 does not matter what slicer i use
How to reproduce
I upgraded to 4.1.0 and it made my Mini crash into stuff after it finished printing. so i do not know why or how to reproduce the error
Expected behavior
Its suppose to just do end gcode but it doesnt
G-code
G1 E-1 F2100 ; retract
{if layer_z < max_print_height}G1 Z{z_offset+min(layer_z+5, max_print_height)}{endif} F720 ; Move print head up
G1 X178 Y180 F4200 ; park print head
G4 ; wait
M104 S0 ; turn off temperature
M140 S0 ; turn off heatbed
M107 ; turn off fan
M221 S100 ; reset flow
M900 K0 ; reset LA
M84 ; disable motors
Crash dump file
dump.bin.zip
Video
https://youtu.be/8hS-jPmPzk4
The text was updated successfully, but these errors were encountered: