-
Notifications
You must be signed in to change notification settings - Fork 232
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] Print head homing after print (with Video) #864
Comments
#733 ? |
@neophyl Possibly. I am not getting the purge sequence, just the home. Doing a few more tests today to see if I can isolate the issue. This seems like it would be a pain for Prusa to replicate without me sending my whole machine back to them. ;) I am really thinking it has to do with the M301 that I just added since that is the only notable change that I have done in the last day. There are a few scenarios I can still test and will reconnect my OctoPrint pi to see if the console will tell me anything. |
@JohnnyDeer This is a difficult one to replicate, so godspeed. If you want the full "good" and "bad" gcode, let me know. (I unfortunately had Prusament Orange loaded printing 20x test cubes, so that sucked. ;) ) |
@JohnnyDeer Attached the two gcode files at the end of the problem description. Once I was confident that I found the problem, I changed the test cube to around 5mm^3 and it had no effect on the underlying problem. These super-quick prints were printed in Prusament PETG. |
@JohnnyDeer I am curious if you are able to replicate. Please, let me know. |
I am also having a similar behavior |
derenma, did you try to remove the M92 E415 G-code from your .gcode file? |
@zoltan-l I did not. I have to admit that is a good troubleshooting step that I overlooked, but setting esteps for the Bondtech extruder is super critical, IMHO. I'll try this tomorrow in the morning. |
@derenma |
@zoltan-l It's taking me a bit to revert back to a broken state. :) Should be there soon. |
I miss any video proving all have the same issue. I could reproduce the issue using (almost ) identical G-code with and without M92 |
@zoltan-l Tried the following:
|
[ deleted crazy engineer ranting here ] |
The cause is the same like #733 |
@zoltan-l Wheeeeeee! I hope I was able to provide enough breadcrumbs for you to work with. Cheers! |
@derenma |
Woohoo! Just saw the recent commit to fix this issue and it looks solid, FWIW. |
New FW version with fix of this bug is out. @derenma please try it out ad let know if this issue can be closed :) |
@JohnnyDeer @zoltan-l BAM! Put a bow on it and ship it. The "bad" g-code posted a few months ago prints just fine under the exact same conditions. For lulz, I just used a garbage USB drive and a USB extension that is possibly going bad. I had suspected there were additional USB issues that might have been part of this problem, but wasn't sure if there was an association or not. I think I deleted some speculative rants about that in the past..... Oh, thanks a ton! It feels good to be part of a solution in a small way rather than just be a ranting customer. |
@derenma thank you for all your help we appreciate your approach :) |
Yay!
|
Printer type - MINI
Printer firmware version- 4.2.1
Original or Custom firmware - Original
Optional upgrades - Filament Runout Sensor, Bondtech heatbreak/extruder
USB drive or USB/Octoprint - USB
Describe the bug
Printer initiates home after print. Edit: This is dissimilar to #733 as that my printer does not initiate a purge sequence.
How to reproduce
Edit: Found it!! Maybe! Attaching video, dump.bin and gcode.
There is a parsing error with the commented
; start_gcode
comment at the bottom of the gcode. Since that is the only other place in the gcode that contains a G28, it must be getting parsed incorrectly by the firmware. This is likely the cause of #733 where only some of the purge sequence was initiated as well.End gcode comments:
; start_gcode = ; M301 P13.54 I0.98 D46.58 ; Set new PID values for BondTech heatbreak\nG90 ; use absolute coordinates\nM83 ; extruder relative mode\nM104 S170 ; set extruder temp for bed leveling\nM140 S[first_layer_bed_temperature] ; set bed temp\nM109 R170 ; wait for bed leveling temp\nM190 S[first_layer_bed_temperature] ; wait for bed temp\nG28 ; home all without mesh bed level\nG29 ; mesh bed leveling \nM104 S[first_layer_temperature] ; set extruder temp\nG92 E0.0\nG1 Y-2.0 X179 F2400\nG1 Z3 F720\nM109 S[first_layer_temperature] ; wait for extruder temp\n\nM92 E415; e-step update\n\n; intro line\nG1 X170 F1000\nG1 Z0.2 F720\nG1 X110.0 E8.0 F900\nG1 X40.0 E10.0 F700\nG92 E0.0\n\nM221 S95 ; set flow
I believe there is a one-off error somewhere in
gcode_file.cpp
when it sees a ton of comments in one line which causes some of the commented gcode to get processed. Take that with a grain of salt as I do not know the code structure that well in this case.I will test this theory extensively today.
Expected behavior
The printer does not attempt to self-destruct.
G-code
Attached.
Crash dump file
Attached.
Video
This is a reproduced error that I was able to get on video the second time during the same power cycle: https://youtu.be/E0-OvU_h4do
Theory/Debugging
I did one manual homing during this power cycle. I will reboot the printer and update this post if there are any changes in the next test print.Edit: Testing this theory did nothing.gcode and dump.bin
gcode_and_dump.zip
gcode modifiers in slicer
M92 E415
M301 P13.54 I0.98 D46.58
current testing iterations w/ reboots between tests
; end_gcode
and; start_gcode
at the bottom of the file. No failure.Proof and replication
Hmm. I was wrong. The G28 wasn't getting read, but rather the
G1 Y-2.0 X179 F2400
.The Bad:
; start_gcode = ; M301 P13.54 I0.98 D46.58 ; Set new PID values for BondTech heatbreak\nG90 ; use absolute coordinates\nM83 ; extruder relative mode\nM104 S170 ; set extruder temp for bed leveling\nM140 S[first_layer_bed_temperature] ; set bed temp\nM109 R170 ; wait for bed leveling temp\nM190 S[first_layer_bed_temperature] ; wait for bed temp\nG28 ; home all without mesh bed level\nG29 ; mesh bed leveling \nM104 S[first_layer_temperature] ; set extruder temp\nG92 E0.0\nG1 Y-2.0 X179 F2400\nG1 Z3 F720\nM109 S[first_layer_temperature] ; wait for extruder temp\n\nM92 E415; e-step update\n\n; intro line\nG1 X170 F1000\nG1 Z0.2 F720\nG1 X110.0 E8.0 F900\nG1 X40.0 E10.0 F700\nG92 E0.0\n\nM221 S95 ; set flow
The proof [changed
G1 Y-2.0 X179 F2400
toG1 Y180 X179 F2400
:; start_gcode = ; M301 P13.54 I0.98 D46.58 ; Set new PID values for BondTech heatbreak\nG90 ; use absolute coordinates\nM83 ; extruder relative mode\nM104 S170 ; set extruder temp for bed leveling\nM140 S[first_layer_bed_temperature] ; set bed temp\nM109 R170 ; wait for bed leveling temp\nM190 S[first_layer_bed_temperature] ; wait for bed temp\nG28 ; home all without mesh bed level\nG29 ; mesh bed leveling \nM104 S[first_layer_temperature] ; set extruder temp\nG92 E0.0\nG1 Y180 X179 F2400\nG1 Z3 F720\nM109 S[first_layer_temperature] ; wait for extruder temp\n\nM92 E415; e-step update\n\n; intro line\nG1 X170 F1000\nG1 Z0.2 F720\nG1 X110.0 E8.0 F900\nG1 X40.0 E10.0 F700\nG92 E0.0\n\nM221 S95 ; set flow
The fix. Remove the start semicolon and the comment from the above
; M301 P13.54 I0.98 D46.58 ; Set new PID values for BondTech heatbreak\n
:; start_gcode = M301 P13.54 I0.98 D46.58\nG90 ; use absolute coordinates\nM83 ; extruder relative mode\nM104 S170 ; set extruder temp for bed leveling\nM140 S[first_layer_bed_temperature] ; set bed temp\nM109 R170 ; wait for bed leveling temp\nM190 S[first_layer_bed_temperature] ; wait for bed temp\nG28 ; home all without mesh bed level\nG29 ; mesh bed leveling \nM104 S[first_layer_temperature] ; set extruder temp\nG92 E0.0\nG1 Y-2.0 X179 F2400\nG1 Z3 F720\nM109 S[first_layer_temperature] ; wait for extruder temp\n\nM92 E415; e-step update\n\n; intro line\nG1 X170 F1000\nG1 Z0.2 F720\nG1 X110.0 E8.0 F900\nG1 X40.0 E10.0 F700\nG92 E0.0\n\nM221 S95 ; set flow
I have just tested breaking the first line comments, with the M301 line just below, which did not replicate the problem.
; BREAK ME
and; BREAK ME ; HERE
as the first lines in the gcode did not replicate the original issue. Weird.Last Edit:
Conclusion
There is a pointer that is getting bumped ahead somehow which is losing track of where '='s and ';'s happen. I think. It looks like the firmware is processing the
; start_gcode = xxx ;
in some way, but that is just weird.Additional Gcode:
CaliCube_0.25mm_PETG_MINI_2m_Bad_and_Good.zip
The text was updated successfully, but these errors were encountered: