Skip to content
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

Closed
Bjerg opened this issue Jul 29, 2020 · 34 comments
Labels
bug Something isn't working.

Comments

@Bjerg
Copy link

Bjerg commented Jul 29, 2020

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

@Bjerg Bjerg added the bug Something isn't working. label Jul 29, 2020
@Bjerg Bjerg changed the title [BUG] After print finished it does a homing & purge sequence but no line [BUG] After print finished it does a homing & purge sequence no line but then crashes into the part if its too tall Jul 29, 2020
@malcmcmreal
Copy link

malcmcmreal commented Jul 29, 2020

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:
https://forum.prusaprinters.org/forum/hardware-firmware-and-software-help/immediately-after-successful-print-mini-goes-into-mesh-bed-leveling-procedure/

@zoltan-l
Copy link
Contributor

zoltan-l commented Aug 5, 2020

Bjerg, Malcolmcmreal
can you please attach your gcode? The best wpuld be the .3mf project file.

@zoltan-l
Copy link
Contributor

zoltan-l commented Aug 5, 2020

seems malcmcmreal´s trouble was the G80 at the end part of the G-code which is another way of asking for MBL

@Bjerg
Copy link
Author

Bjerg commented Aug 5, 2020

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
Shape-Box.zip

@malcmcmreal
Copy link

seems malcmcmreal´s trouble was the G80 at the end part of the G-code which is another way of asking for MBL

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:
test print.zip

@zoltan-l
Copy link
Contributor

zoltan-l commented Aug 6, 2020

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

@zoltan-l
Copy link
Contributor

zoltan-l commented Aug 6, 2020

Gentlemen, can you do me a favour? Post here all G-code changes and places where you inserted you custom G-code?

@malcmcmreal
Copy link

Hope this helps, I've only changed my start and end gcode in slicer. Changes I've made are in bold

START GCODE
G90 ; use absolute coordinates
M83 ; extruder relative mode
G28 ; home all
G1 X100 Y100 F4000
G1 Z1.5 F50 ; park position
M301 P17.10 I1.25 D58.60 ; PID values tuned with RHD_B fan and Mosquito @ 220C

M104 S170 ; set extruder temp for bed leveling
M140 S[first_layer_bed_temperature] ; set bed temp
M109 R170 ; wait for bed leveling temp
M190 S[first_layer_bed_temperature] ; wait for bed temp
G4 S120; wait 2 mins
G28 ; home all without mesh bed level
G29 ; mesh bed leveling
M104 S[first_layer_temperature] ; set extruder temp
G92 E0.0
G1 Y0.0 X179 F2400
G1 Z3 F720
M109 S[first_layer_temperature] ; wait for extruder temp
M92 E415 ; for Bondtech extruder
 
 
; intro line
G1 X170 F1000
G1 Z0.2 F720
G1 X110.0 E8.0 F900
G1 X40.0 E10.0 F700
G1 E-0.8 F2100; anti-stringing retract
G1 X41.0 E0 F1000.0 ; -1mm wipe
G1 X36.0 E0 F1000.0 ; 5mm line @ 0
G1 E0.6 F1800; detract 80%

G92 E0.0
 
M221 S95 ; set flow
 
 
END GCODE
G1 E-1 F2100 ; retract
{if layer_z < max_print_height}G1 Z{z_offset+min(layer_z+15, max_print_height)}{endif} F720 ; Move print head up
G1 X178 Y180 F4200 ; park print head
M84; stop the stepper motors
G4 ; wait
M104 S0 ; turn off temperature
M140 S0 ; turn off heatbed
M107 ; turn off fan
M221 S100 ; reset flow
M220 S100 ; reset speed factor
M900 K0 ; reset linear acceleration

@zoltan-l
Copy link
Contributor

zoltan-l commented Aug 6, 2020

Bjerg,
does this happen also with g-code without M92?

@Bjerg
Copy link
Author

Bjerg commented Aug 6, 2020

@zoltan-l just tried it only happens with M92 enabled without it does not. on 4.1.0 and up

@zoltan-l
Copy link
Contributor

zoltan-l commented Aug 6, 2020

@Bjerg
thanks, this will help much, we suspected it - forwarded to development team - stay tuned

@zoltan-l zoltan-l added 4.1.0 scheduled We are working on it or we have scheduled it for one of the next releases. labels Aug 6, 2020
@derenma
Copy link

derenma commented Sep 4, 2020

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.

@FrenzyIncarnate
Copy link

FrenzyIncarnate commented Oct 12, 2020

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".
Mine reacts a bit different tho. Goes to X178 Y180 as usual then goes to X 0 Y180 Z0 and stops there after the print ends. I will also be looking forward of dev teams solution

@FrenzyIncarnate
Copy link

Hello. I've found a way to prevent this until there is a fix. As we know Bondtech gives us 2 solutions
1 adding that line to Start Gcode at Slicers printer settings
2 they provide a Gcode file that does not print just sets required Estep value.

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.

@ModelTrainNut
Copy link

Multiple M92 axes on one line will trigger the problem on roughly half the prints on my MINI:
M92 X100.4 Y100.6 Z100.8

I separated the axes onto multiple lines and have not seen the problem for weeks:
M92 X100.4
M92 Y100.6
M92 Z400.8

@hamlinjacob
Copy link

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.

@hamlinjacob
Copy link

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.

@malcmcmreal
Copy link

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

@hamlinjacob
Copy link

hamlinjacob commented Dec 19, 2020 via email

@ModelTrainNut
Copy link

ModelTrainNut commented Dec 19, 2020 via email

@derenma
Copy link

derenma commented Dec 19, 2020

@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.

@ModelTrainNut
Copy link

ModelTrainNut commented Dec 19, 2020 via email

@hamlinjacob
Copy link

hamlinjacob commented Dec 19, 2020 via email

@ModelTrainNut
Copy link

ModelTrainNut commented Dec 19, 2020 via email

@zoltan-l
Copy link
Contributor

zoltan-l commented Dec 20, 2020

Guys,
the cause has been discovered. It is not a M92 issue. The team is working on it. It is caused by the comment line which is longer than 95 characters and is created by Slicer from Custom Gcode added to slicer and contains Gcodes. Workaround: enter your gcode file and delete this long comment line containg Gcodes.
The bug will be resolved in the next release.

@derenma
Copy link

derenma commented Dec 20, 2020

@zoltan-l So I am only partially crazy? NICE!

#864

@derenma
Copy link

derenma commented Dec 20, 2020

I am not going down that rabbit hole again. 🤣

@hamlinjacob
Copy link

I just added a pause to the end of the print file before end gcode and it is another easy workaround.

@hamlinjacob
Copy link

The issue still isn't fixed with the latest firmware update and slicer update :(

@derenma
Copy link

derenma commented Feb 14, 2021

I think this is the PR for the fix: #1217

It's going to be in a future release soon, hopefully.

@zoltan-l
Copy link
Contributor

Correct

@JohnnyDeer
Copy link

@Bjerg this issue should be fixed, can you confirm it and consider this issue to close?

@FrenzyIncarnate
Copy link

Hello guys. I believe Jo Prusa said that e-step values will be adjusted via screen. When this will be implemented?

@Bjerg
Copy link
Author

Bjerg commented Jun 7, 2021

@JohnnyDeer its working now no more weird behaviour after print finishes ill close the issue for now

@Bjerg Bjerg closed this as completed Jun 7, 2021
@danopernis danopernis removed the scheduled We are working on it or we have scheduled it for one of the next releases. label Aug 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working.
Projects
None yet
Development

No branches or pull requests

9 participants