[BUG] Height issues after consecutive prints without restart

[kgabriel-dev]

Bug Description

When I do some prints without restarting the printer in between them, the printer does one of the following two things: 1) When starting the print, right after the printer has homed all axis and wants to begin the actual print, it moves down instead of moving to the point at which the print starts. The endstops for the height axis get pushed down, but that does not stop the printer from trying to move further down. That forces me to shut the printer down. 2) The print starts correctly. However, the first layer is printed too close to the print bed. For me, it looks like the data from the mesh bed leveling is not applied to the print. I then cancel the print and restart the printer.

In both cases, restarting the printer solves the issue and the next print works fine. For both prints, before and after the restart, I use the exact same gcode file. The issue appears most often after the third print. It does not matter if the prints before that are successful or fail / get aborted.

Steps to Reproduce

1. Install the newest firmware (v1.5.1)
2. Start some prints (you can cancel them during the print)
3. One of the prints (most often, but not always) the third one will fail with one of the two failures described above.

Expected behavior: Every print should be successful, no matter how many I have done or tried before without restarting the printer.

Actual behavior: One of the prints I do in a row fails because the printer moves wrong at some point.

Additional Information

The exact hex file I use is this one: MEGA_S_TMC_BLT_10_v1.5.1.hex

[knutwurst]

Thanks for the extensive description! That helps me :)

Could you do me a favor and tell me how many files are on the SD card?

And would you do a test with an almost empty SD card with only one file on it?

Does that make a difference?

EDIT: If it works with less files on the SD card, you can test this preview-version: MEGA_S_TMC_BLT_10_v1.5.2-preview.hex.zip

[kgabriel-dev]

Hey, thank you for your quick response! Despite the extensive description, I did forget to mention a major detail... I do not print from the SD card. Instead, I print using OctoPrint running on a Raspberry Pi. However, I still think this issue is related to the firmware since it first appeared after upgrading to version 1.5. Should I still try to print from an empty SD card or is there something else I should do now?

[knutwurst]

oh ok That is new. Previously, sorting the SD card used up too much RAM. Can you still test the 1.5.2?

[kgabriel-dev]

Sure. I will now do some prints from an empty SD card with the new firmware.

[knutwurst]

No no, if you haven't used an SD card before, then you don't need to start now. It's important not to change too many variables at once.

[kgabriel-dev]

I have now tried it with OctoPrint and the firmware version 1.5.2, and the second print failed with a first layer too close to the print bed. Out of curiosity, I then started the next print without restarting the printer, and the printer then moved down into the print bed right after homing. After restarting the printer, I started the print from the SD card (with only this one file on it) and it crashed into the bed again. After turning the printer off and on again, the next print from the SD card started fine.

While printing from the SD card, I was able to see the reported position of the print head and when it crashed into the bed, the reported height was 0.15 mm. That's the correct height for this print.

[knutwurst]

So it doesn't look like a RAM issue. I'll investigate further.

Would you mind testing the pre2 version? -> MEGA_S_TMC_BLT_10_v1.5.2-pre2.hex.zip

[kgabriel-dev]

Oops, I haven't seen this message. I will try it with the new version. I think I'll have an answer by tomorrow.

[kgabriel-dev]

I have now tested the pre2 version and I am sorry to report that it hasn't solved the issue. I started a print, aborted it after about a minute and then started the next print. When beginning the second print, the print head moved down after homing and the print did not start correctly.

Due to some issues with Cura I switched the slicer temporarily to the Prusa Slicer. After doing so, I noticed that the problem changed a bit. The printer doesn't move down indefinitely, instead it moves down a bit after homing and then tries to start the print. Because it moved down too far, the print head cannot move as it gets blocked by the print bed. I do not know if this information helps you further investigating the problem. If you need the starting gcode, you can find the one from Cura and the one from Prusa below.

Prusa Slicer Start Gcode

``` G90 ; use absolute coordinates M83 ; extruder relative mode M204 S[machine_max_acceleration_extruding] T[machine_max_acceleration_retracting] M104 S[first_layer_temperature] ; set extruder temp M140 S[first_layer_bed_temperature] ; set bed temp G28 ; home all M501 M420 S1 G1 Y1.0 Z0.3 F1000 ; move print head up M190 S[first_layer_bed_temperature] ; wait for bed temp M109 S[first_layer_temperature] ; wait for extruder temp G92 E0.0 ; initial load G1 X205.0 E19 F1000 G1 Y1.6 G1 X5.0 E19 F1000 G92 E0.0 ; intro line G1 Y2.0 Z0.2 F1000 G1 X65.0 E9.0 F1000 G1 X105.0 E12.5 F1000 G92 E0.0 ```

Cura Start Gcode

``` ;Profil Homepage: https://github.com/NilsRo/Cura_Anycubic_MegaS_Profile ;Slicer Information - (Support for OctoPrint Slicer Estimator) ;Slicer info:material_guid;{material_guid} ;Slicer info:material_id;{material_id} ;Slicer info:material_brand;{material_brand} ;Slicer info:material_name;{material_name} ;Slicer info:filament_cost;{filament_cost} ;Slicer info:material_bed_temperature;{material_bed_temperature} ;Slicer info:material_bed_temperature_layer_0;{material_bed_temperature_layer_0} ;Slicer info:material_print_temperature;{material_print_temperature} ;Slicer info:material_print_temperature_layer_0;{material_print_temperature_layer_0} ;Slicer info:material_flow;{material_flow} ;Slicer info:layer_height;{layer_height} ;Slicer info:machine_nozzle_size;{machine_nozzle_size} ;Slicer info:wall_thickness;{wall_thickness} ;Slicer info:speed_print;{speed_print} ;Slicer info:speed_topbottom;{speed_topbottom} ;Slicer info:travel_speed;{travel_speed} ;Slicer info:support;{support} ;Slicer info:retraction_speed;{retraction_speed} ;Slicer info:retraction_amount;{retraction_amount} ;Slicer info:layer_height;{layer_height} ;Slicer info:infill_pattern;{infill_pattern} ;Slicer info:infill_sparse_density;{infill_sparse_density} ;Slicer info:cool_fan_enabled;{cool_fan_enabled} ;Slicer info:cool_fan_speed;{cool_fan_speed} ;Slicer info:sliced_at;{day} {date} {time} G21 ; metric values G90 ; absolute positioning M82 ; set extruder to absolute mode M107 ; start with the fan off M140 S{material_bed_temperature_layer_0} ; Start heating the bed M104 S{material_print_temperature_layer_0} ; start heating the hot end M190 S{material_bed_temperature_layer_0} ; wait for bed M109 S{material_print_temperature_layer_0} ; wait for hotend M300 S1000 P500 ; BEEP heating done G28 X0 Y10 Z0 ; move X/Y to min endstops M501 M420 S1 ; Enable leveling M420 Z2.0 ; Set leveling fading height to 2 mm G0 Z0.15 ; lift nozzle a bit G92 E0 ; zero the extruded length G1 X50 E20 F500 ; Extrude 20mm of filament in a 5cm line. G92 E0 ; zero the extruded length again G1 E-2 F500 ; Retract a little G1 X50 F500 ; wipe away from the filament line G1 X100 F9000 ; Quickly wipe away from the filament line ```

Thanks for your efforts to solve the issue so far! Please let me know if there is something else I can do to help you.

[St-Aris]

I haven't had this specific issue, but did have some weird ass issues where the printer would do all the printing and x/yz movement, but would stop extracting filament randomly. Tried all sorts to resolve - even tried replacing the filament stepper, but in the end what solved it was clearing the eeprom to FW defaults, saving, and starting everything over.

If you have upgraded several times and not loaded FW defaults and saved the eeprom as per instructions - it may be worth doing again. In my case there must have been some turds lurking in the eeprom which caused this due to me not doing a FW default in between updates.

Before you update, go into octoprint terminal and do an M503 so you can get all your settings, including mesh levelling for easy input afterwards.

If I recall correctly, I think I also had slightly different results between Cura and Prusaslicer.

[kgabriel-dev]

Thank you for the tip. However, I did this after every of the last few updates, so the cause of the problem seems to be something else.

[rafal1295]

Hello, I'm experiencing the same issue as @kgabriel-dev. I have the latest firmware from the master branch. In my case, I'm using the hex file from the MEGA_TMC_BLT_11 project. The problem manifests itself in a way that after homing all axes, the printer's head doesn't stop even after triggering the endstop. It starts pushing against the bed, which forces me to either turn off the printer or reconnect to the OctoPrint server. The issue occurs when attempting to perform a second or subsequent print.

The previous firmware version that my printer was running on was from June 2022 - commit 84c181d4cfaef29673bdc3746cbae3093ac3b2e7. This issue was not present in that version.

[knutwurst]

@rafal1295 which firmware version did you use? 1.5.1. or 1.5.2? And can you test the current master branch?

If the issue persists on the current master, I have to investigate further. It might be a marlin related issue in the upstream sources I use.

[rafal1295]

@knutwurst I have been using firmware version 1.5.2. Currently, I am away from home. On the upcoming Friday or Saturday, I will attempt to perform a firmware test from the master branch and let you know the results of this test.

[GammaGallagher]

Hi @knutwurst First off, thank you for your work on this branch, it is very much appreciated.

I see similar behaviour as kgabriel-dev. However, I do print from an SD card, which only contains four files.

I noticed this behaviour after I cancelled a print, and restarted the print. I noticed two main things when reprinting:

1. If the print is (re)started when the print head is below the sensor threshold for Z axis, the print head will crash into the build plate, even though the homing seqence runs "fine".
2. If the print head is above the sensor threshold, it seems to ignore the Z (-)offset and prints above the build plate.

Additionally, the axis movement function menu options do not respond. Attempting to spot check the bed in the bed level menu (double tap the bed segment) the Z axis will only lower until it triggers the Z axis sensor and completely ignores the negative offset. However, attempting to rehome the z axis and then spot check same spot caused the print head to crash into the bed.

Other than restarting, the only way I was able to get the printer to respond as expected was to use the Home Z axis in the homing menu. This has to be done twice, as the first time lifts the print head up a small amount and does not home. Second press of homing Z axis then moves up enough to trigger the sensor. Then going back into the Axis movement menu to move the head above the Z axis sensor trigger and then running a print or run a spot check on the print bed in the bed leveling menu seems to work.

I wonder if it is a combination two problems? A.Not consistently applying Z offset. B. Bad homing logic if the homing activity happens when the Z axis sensor is fully triggered, and the hop behaviour does not move it past the sensor trigger threshold.

When in this bad state, I noticed that homing actions do not hop the Z axis up before moving X or Y, causing it to run the crashed head against the bed. ouch.

File used: CHIRON_v1.5.2.hex

I hope this helps track down this issue.

[knutwurst]

Well, I'm happy to build a test version, but it would be useful if each of you could compile and test the current master. I'm still trying to figure out the error and need your feedback :)

[GammaGallagher]

That is fair. It may have to wait until the weekend for me to run that and do some testing (and figure out what I am doing).

[GammaGallagher]

My Status so far: Compiled Master Firmware for Chrion (Marlin-2-0-x-Anycubic-i3-MEGA-S-master) Restarted Printer

• Ran Bed level routine with the stock probe. (saved)
• Tested Centre/centre of print bed, point (13), by pressing the touch point twice.
  • Z Too low by -.6mm (-16.80mm offset)
  • adjusted by +.6mm offset to -16.20mm (saved)
• Navigated back to bed level from sub menu
  • Retested (13).
  • Did not rehome on any axis
  • Z is too low again
  • Backed out without saving
  • Returned to main menu
• Home menu
  • Selected home Z axis
  • Z axis hop did not exceed 16.20mm offset
  • Sensor lights remained off, it did not appear to home correctly.
  • Selected home Z axis again
  • Z hop now past the sensor point, and rehomed Z successfully
• Navigated to bed level menu
  • Retested (13)
  • All Axis homed correctly
  • Point (13) "touched" with the correct offset
  • Returned to Main Menu without saving.
• Navigated to bed level menu
  • Started to retest (13), but did not complete (only pressed once which triggers homing only)
  • X axis started homing, no Z hop (this was alarming as no Z hop before head movement on a fresh bed level session could mean the head drags across the print bed if it were touching, which has happened before. In the other tests above, the Z hop occurred)
  • Y homed
  • Z home did not rise enough to successfully re-trigger the endstop sensor. (this was similar to how a Z home action in the Home menu did not raise the Z axis past the offset until the second attempt. Did not press (13) a second time.)
  • Backed out to main menu without saving.
• Navigated to bed level menu
  • Retested (13)
  • Did not rehome !!!! drove print head into the plate and would not stop. Powered off the printer.

I think from what I have gathered so far, the homing behaviour does not respect the Z axis end stop sensor if the sensor is fully engaged. Sometimes it will hop ~10mm, but this is not enough to clear the endstop since the lowest point is past -16mm. Sometimes it will not hop and just move, which can be catastrophic. The core Z homing behaviour does not travel far enough to overtake the offset of -16mm, and either needs to travel a larger distance (20mm?), or just keep going(loop?) until the sensor is no longer engaged (lights on). However the Z hop before axis movement is also not consistently applied every time under these same conditions.

I will continue testing other behaviour and menu options, though I am actually reluctant to start any prints, if the prints start while the print head is below the end stop trigger point, well, as it seems any action that rehomes below -~10mm and performs x/y movements just repeatedly causes head crashes. While I have already written off the nozzle, I am concerned about damaging the print bed.

If there are any specific test regimes you would like me to try, let me know. I will try to make time for them.

[rafal1295]

@rafal1295 which firmware version did you use? 1.5.1. or 1.5.2? And can you test the current master branch?

If the issue persists on the current master, I have to investigate further. It might be a marlin related issue in the upstream sources I use.

@knutwurst problem still persists on the master branch. Additionally, the problem now occurs with every printing attempt.

https://github.com/knutwurst/Marlin-2-0-x-Anycubic-i3-MEGA-S/assets/38333033/13f13876-4588-41a2-9eeb-ec8d344344d2

[GammaGallagher]

Update #1

Printer turned on

• Home menu
  • home all axis successfully
• Navigated to Bed level menu
  • Test point (13) by pressing twice
  • touch point did not reflect offset (the Z axis only dropped until the endstop just triggered and then stopped)
  • backed out to main menu without saving
• Navigated to Bed level menu
  • Retested (13)
  • homed all axis correctly
  • touched point with offsets correctly
  • backed out ot main menu without saving
• move axis menu
  • note print head is below end stop sensor trigger point
  • Z +/- commands do nothing.
  • X/Y commands move the head/Bed, but Very very VERY slowly. Motor steps a few times a second
  • L/M/H speed options do nothing to change the speed
  • Select Home, homes X/Y does not Z hop (still near offset position)
  • Z then hops, but not enough to home.
  • Pressing a second time homes all axis successfully.
  • X/Y/Z axis movements now move based on L/M/H speeds
  • Z will now +/- correctly.
  • Z will go below endstop trigger, but does not seem to move past -10mm (this seems like expected behaviour)
  • Select Home again
  • Hops Z axis, and homes correctly.
  • Attempting to exceed ~-10mm is prevented within this menu.

Takeway: It seems that the homing behaviour causes some setting in the printer's current state to override some behaviours. Homing from the main Homing menu does not seem allow Z below the endstop when it should be allowed in other triggered behaviours. Rehoming using another function like the bed leveling does seem to resolve this after a second attempt. However moving to another function like the Axis movements, the Z homing does not work until it is within the -10mm offset range. Axis movement menu does not drop below ~-10mm, it can rehome first try each time, since the hop before rehoming seems to be roughly 10mm.

The strange (painfully) slow movement when changing from bed leveling to Axis movement is perplexing though.

[kgabriel-dev]

Today I compiled the firmware as well and while testing it I got some different results:

I first flashed it, load the FW defaults and configured everything using the printer's display (z-probe offset and disabled the filament sensor) and then started the first print. The print started but the print head was too low, scratching on the bed. After starting the second attempt (without restarting the printer), the print head moved down after homing.

After restarting the printer, I was able to do four successful prints in a row without any issues!

To gather some more data, I restarted the printer one more time and during the next print the nozzle scratched on the bed again.

[knutwurst]

Hi everyone.

I just pushed a handfull test-fixes regarding the soft-endstops and the sd file sorting (which causes a higher ram usage) to the master.

Unfortunately, I'm still groping in the dark, since almost everything has changed since 1.5.0 and nothing is structured like it was in 1.4.x.

So it would be great if you guys could help me with testing to see if anything improves.

An important note: If you are in the Special Menu, you should ALWAYS exit the menu completely before printing.

[kgabriel-dev]

Hey, I tested the new version and sadly it did not solve the issue. After installing and configuring everything, the first print started with the head moving down again. And after restarting the printer then, the first print worked fine but the second one did also let the print head move down right after homing, forcing me to shut the printer down. So, for me, this version worked worse than the version with the commit hash 76cb3ae, but maybe it was just luck that I was able to get some working prints in a row with the old version?

[St-Aris]

You are using a BL Touch? What happens if you use a firmware without and do manual bed level mesh.

[GammaGallagher]

Same here, the behaviour is much worse. Attempting to touch point 13 (manual mesh) on the bed level menu more than once just drives the print head into the bed. It is quite a lot more repeatable now.

[knutwurst]

Can you read out the current status of your endstops with M211 and then deactivate them manually with M211 S0 or activate them with M211 S1?

In the current master, the software endstops are no longer changed at runtime. This means that the commands set with M211 are used.

I'm interested in whether the behavior is different, whether the endstops are activated or deactivated.

Please remember to save with M500.

[GammaGallagher]

M211 is S1 (ON) Turning OFF (S0) results in the Z axis ignoring the end stop when using the Move Axis menu. It does not seem to change the behaviour when testing the mesh points in the bed level menu.

[knutwurst]

M211 is S1 (ON) Turning OFF (S0) results in the Z axis ignoring the end stop when using the Move Axis menu. It does not seem to change the behaviour when testing the mesh points in the bed level menu.

Yes I know :) This is also normal behavior. But I'm concerned with whether the printer behaves differently when printing.

[GammaGallagher]

From the standpoint of my Chiron, the behaviour using the current master does not change. Did a dozen or so very quick test prints with M211 on and off, and the behaviour is the same. That is to say it is neither printing in the air nor crashing the print head while printing. So the test master seems to be ok from the printing stand point, so far. I will have to try some more later.

[GammaGallagher]

Retested printing with a fresh file. Now with M211 on or off, the print head doesn't lower to the offset. When attempting the Bed level mesh, it would do the same unless I tested it twice. Then I printed again, but the print head crashed into the plate (both with M211 on and off). Still doesn't consistently Z hop during homing when the endstop is engaged.

[GammaGallagher]

M211 is S1 (ON) Turning OFF (S0) results in the Z axis ignoring the end stop when using the Move Axis menu. It does not seem to change the behaviour when testing the mesh points in the bed level menu.

Yes I know :) This is also normal behavior. But I'm concerned with whether the printer behaves differently when printing.

As a shot in the dark, I put M420 S1 after the G28 in the Gcode. The test print is consistently printing on the bed as expected.

[kgabriel-dev]

According to the Marlin docs you have to use M420 S after using G28, see the notes here. I used this command all the time (see my start gcode in one of the first comments) and have the issue.

[GammaGallagher]

I did note that after doing some research, which lead me to investigate my Gcode. There is plenty of literature that suggest it should be in the Gcode. Thing is, I never used to need this line when producting Gcode while printing using other builds of Marlin, and now I have no idea how it has been working for so long. This suggests to me there is something different in the way that this build handles the mesh or probe offset values. I do not expect it to be a solution, but just a clue to what is going on.

[rafal1295]

@knutwurst @kgabriel-dev It seems that the issue disappeared for me after removing M501 GCode from starting GCode. Since I removed it, I haven't noticed any problems so far with the printer's head crashing to the bed.

[knutwurst]

Now that we're getting closer, I might not be able to reproduce the bug. Do you all use different Start codes?

Do any of you use the one from the wiki? https://github.com/knutwurst/Marlin-2-0-x-Anycubic-i3-MEGA-S/wiki/Start-and-Endcode-with-preheat-and-purge-line

[GammaGallagher]

I do not.

In saying that, the last dozen prints started fine after modifying my start gcode. My remaining issue seems to be with how the homing and mesh leveling actions in the UI behave, which may not be related. So, I am mostly good so far.

[kgabriel-dev]

I will remove the M501 gcode command from my start gcode as well and then start some prints, (hopefully) without restarting the printer. The M501 command seems to be the only major difference from the start gcode posted in the wiki for me, so I am optimistic it will work!

[knutwurst]

Then please keep us up to date :)

[kgabriel-dev]

Hey, removing the M501 command from the start gcode seems to solve the issue for me as well! I was able to start some prints one after another without having to restart the printer. Thanks everyone for solving the problem!

[ElCapitanYolo]

Hello everyone! I had the same issue when i installed the version 1.4.3 back in April 2023. My printer had the following behaviour: [q] When starting the print, right after the printer has homed all axis and wants to begin the actual print, it moves down instead of moving to the point at which the print starts. The endstops for the height axis get pushed down, but that does not stop the printer from trying to move further down. That forces me to shut the printer down. [uq]

Printer details: Anycubic i3 Mega S Trigorilla board 1.0 TMC2208 Clone BLT (3dTouch)

Partial Solution: I installed the clone BLT on pin D11, instead of D4 with assistance from a friend who knows VS and assigned the relevant pin in the code.

Result: The Z-homing was fixed, proper bed leveling by clone BLT applied and reading were OK.

I said "partial solution" due to the fact that although the printer was homing properly and i was getting BLT bed leveling readings (25 points) and bed visualizer was OK on octoprint, there was lack of implementation of the leveling. During the print the nozzle was not applying z-corrections. I have amended starting G-Code with G28 and M420 S1 accordingly. Hence, I ended up with the latest version 1.5.2 BUT with the manual bed leveling edition (MEGA_S_TMC_v1.5.2.hex). I currently using this variable of 1.5.2 because i'm completely noob with code editing/compiling. :P

[St-Aris]

Is this a bug, for which removing M501 is just a workaround?

[Bastians-Bits]

Just wanted to say thank you, @knutwurst @kgabriel-dev @rafal1295 @GammaGallagher! Your discussion and findings are a life saver! I suffered from the same problem that the print head would smash into the bed on the start of a print. After removing M501 after G28 Z0 it worked like a charm!

I am also curious about @St-Aris question. Is that the expected behaviour or a bug in the firmware? Worked like a charm on the stock fw for years, weirdly enough one print also worked with the M501 in it oO

Running MEGA_X_BLT_10_v1.5.2.hex on my Anycubic Mega X.

[FuzzyLotus]

EDIT: Actually - I don't think this helps lol

Heyo! Just wanted to thank everyone who contributed to the thread and post another workaround.

Instead of removing the m501 gcode command from the start code, you can add the m501 at the end of the "end gcode" section instead. That seems to have fixed the issue for me.

Here is my start GCODE:

G90 ; use absolute coordinates M83 ; extruder relative mode M204 S[machine_max_acceleration_extruding] T[machine_max_acceleration_retracting] M104 S[first_layer_temperature] ; set extruder temp M140 S[first_layer_bed_temperature] ; set bed temp G28 ; home all M501 M420 S1 G1 Y1.0 Z0.3 F1000 ; move print head up M190 S[first_layer_bed_temperature] ; wait for bed temp M109 S[first_layer_temperature] ; wait for extruder temp G92 E0.0 ; initial load G1 X205.0 E19 F1000 G1 Y1.6 G1 X5.0 E19 F1000 G92 E0.0 ; intro line G1 Y2.0 Z0.2 F1000 G1 X65.0 E9.0 F1000 G1 X105.0 E12.5 F1000 G92 E0.0

And end GCODE:

G1 E-1.0 F2100 ; retract G92 E0.0 G1{if max_layer_z < max_print_height} Z{z_offset+min(max_layer_z+30, max_print_height)}{endif} E-34.0 F720 ; move print head up & retract filament G4 ; wait M104 S0 ; turn off temperature M140 S0 ; turn off heatbed M107 ; turn off fan G1 X0 Y105 F3000 ; park print head M84 ; disable motors G90 M300 P300 S4000 M501

[St-Aris]

Was this fixed or do we still need the M501 workaround?

[knutwurst]

@St-Aris it should work as expected in the new Version. However, you should note that M501 should never appear in the start code. This was never required and was never intended. It just didn't have such extreme effects in the past.

A suitable start and end code can also be found in the wiki: https://github.com/knutwurst/Marlin-2-0-x-Anycubic-i3-MEGA-S/wiki/Start-and-Endcode-with-preheat-and-purge-line