Marlin: Printer stops after autolevel process right before start printing.

Created on 26 Nov 2015  Â·  28Comments  Â·  Source: MarlinFirmware/Marlin

Hello i checked the bug list and was not able to identify if this was reported, so i hope it's not a duplicate.. if it is please accept my apologies.

I recently finished configuring the v1.1.0 rc2 for using it with my Prusa i3 Steel (ramps1.4). It does the homing and then the auto level quite normally, in fact it runs some commands to prep the extruder and display a text in the screen, and also consult the parameters of the printing, however when it gets to the "start" position the printer freezes...

here are my config and config adv files (saved as *txt to be able to attach)

Configuration.txt
Configuration_adv.txt

here are the commands I run: before the print starts (running them in Cura 15.04):

G90        ;absolute positioning
M82        ;set extruder to absolute mode
M107       ;start with the fan off
G28             ;G.S: home printer
M851 Z-0.4  ;G.S: Set Z probe offset
G29             ;G.S: autolevel procedure
G1 Z15.0 F{travel_speed} ;raise extruder 15 mm
G92 E0                  ;zero the extruded length
G1 F200 E8              ;extrude 8mm of feed stock
G92 E0                  ;zero the extruded length again
;M92 E1790   ;G.S: correction for Steps per mm when using geared extruder
M503       ;G.S: display print parameters
M117 Printing...   ;Put printing message on LCD screen

i know that all those commands are executed cause i can see the "Printing..." message in the screen, ans also, here are the paramethers that i'm getting from that command M504 right before starting the print:

< echo:SD card ok
< echo:Steps per unit:
< echo:  M92 X200.00 Y200.00 Z8054.00 E680.00
< echo:Maximum feedrates (mm/s):
< echo:  M203 X300.00 Y300.00 Z3.00 E50.00
< echo:Maximum Acceleration (mm/s2):
< echo:  M201 X3000 Y3000 Z100 E20000
< echo:Accelerations: P=printing, R=retract and T=travel
< echo:  M204 P2000.00 R2000.00 T2000.00
< echo:Advanced variables: S=Min feedrate (mm/s), T=Min travel feedrate (mm/s), B=minimum segment time (ms), X=maximum XY jerk (mm/s),  Z=maximum Z jerk (mm/s),  E=maximum E jerk (mm/s)
< echo:  M205 S0.00 T0.00 B20000 X15.00 Z0.40 E5.00
< echo:Home offset (mm):
< echo:  M206 X0.00 Y0.00 Z0.00
< echo:Material heatup parameters:

one last test i did before sending this... even if comment the G29 command (that is, not doing the autolevel process but trying to print immediately after home with G28, it still does the same thing. just stops right when it gets to the start point...
i did this because i thought maybe the G29 process was taking too long and some security restrain was timing out on me...

any clues?

thanks!!

Gabe

Question

All 28 comments

Until the "Printing" i have not seen any heater commands. Are we waiting for the heaters now? What is your g-code-program doing next?
Kicked the cold extrusion you out?

G1 F200 E8 ;extrude 8mm of feed stock

Please give us more g-code and more log.

There have been weird cases where a magical click on the encoder button (LCD display) helped to start.

oh.... sorry yeah there was heater commands in the whole Gcode... (attaching below)
EDIT:
as for the logs, I'm doing an M28 and M928...
attaching all th files below
thanks!

Gabe
gcode.txt
M28_log.txt
Cura output for M28.txt
M928.txt
Cura output for M928.txt

hello guys! :) still no idea what's going on with the printer... :(

Do you have two extruders/nozzles?

Sent from my iPhone

On 1 Dec 2015, at 16:49, gabrielcr78 [email protected] wrote:

hello guys! :) still no idea what's going on with the printer... :(

—
Reply to this email directly or view it on GitHub.

no sir. only one.. but soon enough i want to enable two as i recently received the Chimera from e3dV6 and the Cyclops... (actually it's the legends pack) so i'll be upgrading it during the holidays. :)

Hmmm... Does your heated bed get up to temp? I'm wondering if it's not stuck, just waiting. Have you tried any other files (possibly changing the start code or removing tweak at z) and have you had it printing at all before, or is it a new build?

Sent from my iPhone

On 1 Dec 2015, at 19:25, gabrielcr78 [email protected] wrote:

no sir. only one.. but soon enough i want to enable two as i recently received the Chimera from e3dV6 and the Cyclops... (actually it's the legends pack) so i'll be upgrading it during the holidays. :)

—
Reply to this email directly or view it on GitHub.

measured temp... it gets there indeed... thermistor reports about the same temp than the IR thermometer oh it was printing beatifully (and still does) with the previous version of marlin 1.0.2... this issue is just with the new version of marlin 1.1.0 rc2... i think this might be an issue with the config file... maybe?

It's only important that the thermistor gets there not an unconnected IR Thermometer. The print will only start once the temp is hit, if it's not it will hang forever.

Sent from my iPhone

On 1 Dec 2015, at 21:01, gabrielcr78 [email protected] wrote:

neasured temp... it gets there indeed... thermistor reports about the same temp thatn theIR thermometer

—
Reply to this email directly or view it on GitHub.

i understand that.. i was only mention it to clarify that the temp i'm getting is confirmed. alsoboth temps are there... however the temp of the bed some times exceed the target by 2 or 3 degres and then comes down etc.

Damn, I was hoping it was the same thing that happened to me a while ago. Sorry I'm not the most qualified person to help but I'll keep looking through things and hopefully something will stand out, or someone smarter will see it.

As long as everything is hitting or exceeding slightly on temps then that's fine.

Sent from my iPhone

On 2 Dec 2015, at 00:05, gabrielcr78 [email protected] wrote:

i understand that.. i was only mention it to clarify that the temp i'm getting is confirmed. alsoboth temps are there... however the temp of the bed some times exceed the target by 2 or 3 degres and then comes down etc.

—
Reply to this email directly or view it on GitHub.

thanks a lot!! that's really appreciated!

Maybe we can get some more direct information if you'd use a host program with a 'terminal' like Pronterface or Repetier Host or Octoprint. For debugging that is much more comfortable then writing a g-code file and looking at the logs.

@gabrielcr78 Did you get this worked out? Be sure to try the latest RC, which is RC3, or check out RCBugFix for some of the latest patches. There have been a few bug patches since RC2 that relate to the parser, so it's worth a try….

I'll try RC3 and talk with you guys again to wither confirm it's fixed
thanks!!

Gabe

2016-02-23 22:54 GMT-08:00 Scott Lahteine [email protected]:

@gabrielcr78 https://github.com/gabrielcr78 Did you get this worked
out? Be sure to try the latest RC, which is RC3, or check out RCBugFix
for some of the latest patches. There have been a few bug patches since RC2
that relate to the parser, so it's worth a try….

—
Reply to this email directly or view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/2801#issuecomment-188108751
.


Gabriel Sánchez

I'll try RC3 and talk with you guys again as to whether it's fixed

Great. But be sure to try RCBugFix as well, in case it's fixed there, or in case there is a regression (it broke again).

Thank you for your interest making Marlin better and reporting this issue but this topic has been open for a long period of time without any further development. Marlin has been under heavy development for the past couple of months and moving to it's last mile to finish the RC cycle and release Marlin v1.1.0. We suggest you to try out the latest RCBugfix branch and reopening this issue if required.

I just had this happen to me. Had my Delta working fine with older versions of Marlin. Decided to update and use one of the configurations for deltas.

Send print and once it approaches the print bed it just stops.

Do I have to run G29 before each print or something like that? When I do I get a report of the points but they don't seem to improve if I run it again.

@MRGiacalone Did you test with RCBugFix?

When it stops is the controller still responsive?

It does actually help to do a G29 with Delta since calibrating is often tricky. But if you move the nozzle over the bed manually without doing any G29 do you find that it stays level to the bed?

If needed, you can enable DEBUG_LEVELING_FEATURE and then use M111 S247 to enable most logging. When you do G28 and G29 V4 the machine will print a detailed log of the process. If for some reason the process fails, it will be clearer where and maybe why. With all logging on you can also try "send print" and some logging should occur that might be useful or not.

I have a similar issue, with a Delta and RC7.
I don't use G29, I calibrate it manually.

The printer pauses with M105 as it reached the bed (requires pressing the
LCD rotary knob to proceed), but only if printing from the SDcard inserted
in the 12864 LCD. I would prefer if it just printed away, without this
pause.

Printing from Pronterface it runs fine, no pause.

Do I have to run G29 before each print or something like that? When I do I get a report of the points but they don't seem to improve if I run it again.

Yes. Consecutive G29 will not help. Every G29, G28, reset and some other situations do erase the values a previous G29 measured.

Thank you @thinkyhead .
I haven't tested the RCBugFix yet. I will be doing that during the day.
The controller is unresponsive after it stops. I have to turn the machine off to get it running again.

I did a lot of modifications to the printer, including new Marlin firmware, FSR bed leveling, and added a diamond hot end with three (two additional) steppers. Haven't done any other tests with the bed leveling (printing was going to be a major one). Tried printing with only one stepper active just as before I made the changes. I wanted to print because that would let me know if the autocalibration is actually worlking.

@Blue-Marlin Thank you. I didn't know I had to run it every time I print. Does that mean I have to include G29 in the G-code prefix after the G28?

The controller is unresponsive after it stops.

Curious. Well, try the logging as described above and we'll see where it fails.

@thinkyhead With the RCBugFix the issue is no longer present using the Delta - Kossle Pro configuration. You can close this issue.

@Barrocas How did you calibrate it manually using RC? I used Couture's method for my previous versions of Marlin, and I am curious if anything else has changed in that area. I think it is better to calibrate once (or now and then) rather than every time I print something.

better to calibrate once (or now and then) rather than every time

Truly. I hope to make this happen for more forms of bed leveling in 1.1.1, but perhaps I can make it happen for 1.1.0. Though I think it will be after 1.1.0-RC8 which I don't want to delay much longer.

How did you calibrate it manually using RC?

Kossel mini with RC7, but the Z-min probe was removed (so no G29), and I
used similar methods to the described here:
http://minow.blogspot.pt/

Instead of adjusting endstop screws (up,down,adjust,up,down,adjust...), it
has a set of 3 screws to adjust the bed height near each tower.
Much easier, I just position the hotend near each tower base, check with
paper for bed clearance, adjust base holder screws as needed,
recheck/adjust each tower, check center (adjust in firmware) and done.

I set it once, and check for differences when the glass is removed, or
printer is moved.

Cumprimentos,
D.er Hugo Barrocas

RCBugFix = RC7 + hundreds of patches. Might as well move on to RCBugFix at this point.

I'll try it, thanks.

Tested the Mini Kossel with today's RCbugFix, and it worked fine, the
printer didn't pause anymore at the beginning of the print job, like it
used to do.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Matts-Hub picture Matts-Hub  Â·  3Comments

ahsnuet09 picture ahsnuet09  Â·  3Comments

otisczech picture otisczech  Â·  3Comments

ShadowOfTheDamn picture ShadowOfTheDamn  Â·  3Comments

StefanBruens picture StefanBruens  Â·  4Comments