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] Print head homing after print (with Video) #864

Closed
derenma opened this issue Sep 4, 2020 · 22 comments
Closed

[BUG] Print head homing after print (with Video) #864

derenma opened this issue Sep 4, 2020 · 22 comments
Labels
bug Something isn't working.

Comments

@derenma
Copy link

derenma commented Sep 4, 2020

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

  1. M301 set in memory and in gcode causes failure
  2. M301 in memory and not in gcode causes failure (it was actually in the gcode, just commented out in the slicer)
  3. No changes to M301 after reset causes failure (the M301 was still only commented out in the slicer)
  4. Re-added (uncommented) M301 manually to the start gcode and removed both ; 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 to G1 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

@derenma derenma added the bug Something isn't working. label Sep 4, 2020
@neophyl
Copy link

neophyl commented Sep 4, 2020

#733 ?

@derenma
Copy link
Author

derenma commented Sep 4, 2020

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

@derenma
Copy link
Author

derenma commented Sep 10, 2020

@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
Copy link

Hi @derenma yes please, it would be helpful. We think this issue may have same reason as #733.

@derenma
Copy link
Author

derenma commented Sep 10, 2020

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

@derenma
Copy link
Author

derenma commented Sep 12, 2020

@JohnnyDeer I am curious if you are able to replicate. Please, let me know.

@danielo515
Copy link

I am also having a similar behavior

@zoltan-l
Copy link
Contributor

zoltan-l commented Oct 5, 2020

derenma, did you try to remove the M92 E415 G-code from your .gcode file?

@derenma
Copy link
Author

derenma commented Oct 6, 2020

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

@zoltan-l
Copy link
Contributor

zoltan-l commented Oct 7, 2020

@derenma
thanks, looking forward to your response

@derenma
Copy link
Author

derenma commented Oct 7, 2020

@zoltan-l It's taking me a bit to revert back to a broken state. :) Should be there soon.

@zoltan-l
Copy link
Contributor

zoltan-l commented Oct 7, 2020

I miss any video proving all have the same issue. I could reproduce the issue using (almost ) identical G-code with and without M92

@derenma
Copy link
Author

derenma commented Oct 7, 2020

@zoltan-l Tried the following:

  1. Commenting out the M92 at the top of the code - Printer failed.
  2. Deleting the M92 completely from the top of the code - Printer failed.
  3. Attempted a NOP slide into ; start_gcode = AAAAAA... - Print worked as expected. (I have no idea what the stack looks like for this control board, or if I could even attempt such a hack. That was more just for lulz.)

@derenma
Copy link
Author

derenma commented Dec 20, 2020

[ deleted crazy engineer ranting here ]

@zoltan-l
Copy link
Contributor

zoltan-l commented Jan 12, 2021

The cause is the same like #733
workaround same - remove from Gcode the long ( longer than 65 characters) comment line(s) which is (are) misinterpreted by parser.
Scheduled for the next release to be repaired

@derenma
Copy link
Author

derenma commented Feb 11, 2021

@zoltan-l Wheeeeeee! I hope I was able to provide enough breadcrumbs for you to work with. Cheers!

@zoltan-l
Copy link
Contributor

@derenma
Matt thanks, you were great !

@derenma
Copy link
Author

derenma commented May 16, 2021

Woohoo! Just saw the recent commit to fix this issue and it looks solid, FWIW.

@JohnnyDeer
Copy link

New FW version with fix of this bug is out. @derenma please try it out ad let know if this issue can be closed :)
https://github.com/prusa3d/Prusa-Firmware-Buddy/releases/tag/v4.3.2-RC1

@derenma
Copy link
Author

derenma commented May 26, 2021

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

@JohnnyDeer
Copy link

@derenma thank you for all your help we appreciate your approach :)
I´m closing this issue as solved.

@derenma
Copy link
Author

derenma commented Jun 1, 2021 via email

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

5 participants