Marlin: Printer fails to home after done printing

[maviles798]

Description

My printer homing fails after printing it is a delta printer (Anycubic Kossel linear plus) it was printing fine and out of nowhere it started with this problem.
The printer homes fine if i autohome it. but i cant do anything when its done printing and it autohomes.

In the video i have to push the endstop in order to stop it from crashing with the x pillar.

PLEASE HELP.

Steps to Reproduce

1. I send something to print
2. Prints the part fine and with no mistakes
3. When it starts homing right after finishing the print the it starts going up for a small distance then the y and z motors stop and and only the x motor keeps going up until it crashes with the frame then the printer screen shows [homing failed printer halted] and i have to restart the printer.

Additional Information

• https://www.youtube.com/watch?v=euYCeoyhQk4

[thinkyhead]

• Please ZIP the G-code you are using and attach it to your next reply.
• Also ZIP and include your Configuration.h and Configuration_adv.h files.

[maviles798]

here are the files that you need, thank you. its a strange error because some times works good and sometimes crashes even with the same gcode file.
config.h and adv.h + g code.zip

[thinkyhead]

Marlin now checks to see that after a homing move an endstop is actually triggered. If it doesn't see a triggered endstop it assumes that homing failed, and locks up the machine.

Make sure your endstops are reliable by testing with M119 under various conditions. You might try turning on ENDSTOP_NOISE_FILTER to see if it helps.

[F0x06]

Marlin version: bugfix-1.1.x (2018-07-31), also tested with 1.1.9

Hi, i have the exact same problem with my Anycubic Kossel when my print finishes, in my case X Y towers are stuck and Z crashes and force until "homing failed printer halted" message appears. This happens not every times, seems a bit random can't figure out what is the problem. Tested all my endstops with M119, no problems detected. Attached my configs and my last gcode when the bug occured.

PS: Never seen this bug on older Marlin shipped with my printer.

Any solution except the ENDSTOP_NOISE_FILTER one ?

bugreport_files.zip

[maviles798]

I manage to fix it in my printer one screw was loose and also the endstops were giving fake signals due to having them near power supply wires yo can fix that by adding a 100 nf capasitor connected parallel to the endstops
Or using the endstop_noise_ filter

[F0x06]

@maviles798 Thank you for the solution, i will try the capacitor one, because endstop_noise_ filter impact homing precision.

[bigbaldbob1]

I have also started having this problem since I switched to 1.1.9, and I am using an AnyCubic Kossel Linear Plus as well. Mine seems to crash into the X tower when returning home after a print on about 1 out of 4 prints. The gcode file in the attached zip file was for my last print when it did crash. I have tested my endstops using M119, and they appear to be working correctly. The attached zip file also includes my config files in case they are useful.
tower_crash_files.zip

[bigbaldbob1]

I wanted to add a little more information after I closely watched the end of a print as the home command failed. When the print was finished, it executed a 5mm upward movement that I have in my "end of print" code. Then it looked like the printer was going to home, but instead of all 3 steppers driving toward the endstops, only the X stepper was driving. This caused the head to move quickly toward the X tower. I manually tripped the X endstop limit switch, and the Y stepper started driving. I tried to trip the Y endstop limit switch, but was too slow; and the head crashed into the Y tower. This doesn't look like an endstop problem to me. It looks like the Auto Home 'G28' command is having a problem and not driving all steppers, very important for a delta printer. Here is the very end of the print commands copied from Octoprint terminal:

Send: N162374 G0 X101.86 Y18.785*16
Recv: ok
Send: N162375 G0 X101.5 Y18.425*35
Recv: ok
Send: N162376 G1 F1500 E4195.90047*5
Recv: ok
Send: N162377 M107*19
Recv: ok
Send: N162378 M104 S0*92
Recv: ok
Send: N162379 M140 S0*93
Recv: ok
Send: N162380 G91*47
Recv: ok
Send: N162381 G1 E-1 F300*59
Recv: ok
Send: N162382 G1 Z+5.0 E-5 F3000*118
Recv: ok
Send: N162383 G90*45
Recv: ok
Send: N162384 G28*41
[...]
Recv: Error:Printer halted. kill() called!
Changing monitoring state from "Printing" to "Cancelling"

[thinkyhead]

It sounds like old endstop states are hanging around, so when the machine starts to home it thinks one or more of the endstops has already been triggered, so it's going straight to the "homing re-bump" moves. There were changes to the endstops code by @ejtagle and myself, and perhaps we broke something in the process.

If enabling ENDSTOP_NOISE_FILTER doesn't help, then we need to gather more information:

Try a very small G-code that does a few moves and then has a G28 at the end to see if it has the same issue. Also enable DEBUG_LEVELING_FEATURE and re-flash. Then put M111 S248 in front of that G28 command. You'll get extra log output indicating what happens during the G28 to confuse the firmware.

[maviles798]

Enabling endstop_noise_filter fixed the problem in my case. I bought the capacitor but I haven't tried them to see if that fixes the problem.

Today I will make some test to see if with the capacitors my printer works fine. If it does I will let you know.

[maviles798]

I install the capacitors and the printer keeps going to the x tower when its done printing some times.
this is the code of a normal g28 comand.

Log Output

>>> G28
Machine Type: Delta
Probe: FIX_MOUNTED_PROBE
Probe Offset X:0 Y:0 Z:-9.15 (Aligned With & Below Nozzle)
Auto Bed Leveling: BILINEAR (disabled)
  current_position=(0.00, 0.00, 0.28) : setup_for_endstop_or_probe_move
> endstops.enable(true)
  current_position=(0.00, 0.00, 0.28) : >>> home_delta
  current_position=(0.00, 0.00, 0.00) : sync_plan_position
>>> homeaxis(X)
Home 1 Fast:
>>> do_homing_move(X, 330.00, [60.00])
  current_position=(0.00, 312.55, 312.55) : sync_plan_position
<<< do_homing_move(X)
Move Away:
>>> do_homing_move(X, -5.00, [60.00])
  current_position=(0.00, 312.55, 312.55) : sync_plan_position
<<< do_homing_move(X)
Home 2 Slow:
>>> do_homing_move(X, 10.00, 30.00)
  current_position=(0.00, 312.55, 312.55) : sync_plan_position
<<< do_homing_move(X)
delta_endstop_adj:
>>> do_homing_move(X, -0.30, [60.00])
  current_position=(0.00, 312.55, 312.55) : sync_plan_position
<<< do_homing_move(X)
<<< homeaxis(X)
>>> homeaxis(Y)
Home 1 Fast:
>>> do_homing_move(Y, 330.00, [60.00])
  current_position=(-0.30, 0.00, 312.55) : sync_plan_position
<<< do_homing_move(Y)
Move Away:
>>> do_homing_move(Y, -5.00, [60.00])
  current_position=(-0.30, 0.00, 312.55) : sync_plan_position
<<< do_homing_move(Y)
Home 2 Slow:
>>> do_homing_move(Y, 10.00, 30.00)
  current_position=(-0.30, 0.00, 312.55) : sync_plan_position
<<< do_homing_move(Y)
delta_endstop_adj:
>>> do_homing_move(Y, -0.09, [60.00])
  current_position=(-0.30, 0.00, 312.55) : sync_plan_position
<<< do_homing_move(Y)
<<< homeaxis(Y)
>>> homeaxis(Z)
Home 1 Fast:
>>> do_homing_move(Z, 454.72, [60.00])
  current_position=(-0.30, -0.09, 0.00) : sync_plan_position
<<< do_homing_move(Z)
Move Away:
>>> do_homing_move(Z, -5.00, [60.00])
  current_position=(-0.30, -0.09, 0.00) : sync_plan_position
<<< do_homing_move(Z)
Home 2 Slow:
>>> do_homing_move(Z, 10.00, 15.00)
  current_position=(-0.30, -0.09, 0.00) : sync_plan_position
<<< do_homing_move(Z)
delta_endstop_adj:
>>> do_homing_move(Z, -1.45, [60.00])
  current_position=(-0.30, -0.09, 0.00) : sync_plan_position
<<< do_homing_move(Z)
<<< homeaxis(Z)
>>> set_axis_is_at_home(X)
For X
 position_shift = 0.00
 soft_endstop_min = -110.00
 soft_endstop_max = 110.00
  current_position=(0.00, -0.09, -1.45) :
<<< set_axis_is_at_home(X)
>>> set_axis_is_at_home(Y)
For Y
 position_shift = 0.00
 soft_endstop_min = -110.00
 soft_endstop_max = 110.00
  current_position=(0.00, 0.00, -1.45) :
<<< set_axis_is_at_home(Y)
>>> set_axis_is_at_home(Z)
For Z
 position_shift = 0.00
 soft_endstop_min = 0.00
 soft_endstop_max = 302.55
  current_position=(0.00, 0.00, 302.55) :
<<< set_axis_is_at_home(Z)
  current_position=(0.00, 0.00, 302.55) : sync_plan_position_kinematic
  current_position=(0.00, 0.00, 302.55) : <<< home_delta
>>> do_blocking_move_to(0.00, 0.00, 237.28)
  destination=(0.00, 0.00, 302.55) : set_destination_from_current
  destination=(0.00, 0.00, 237.28) : prepare_uninterpolated_move_to_destination
  current_position=(0.00, 0.00, 237.28) : zone border move
  current_position=(0.00, 0.00, 237.28) : xy move
<<< do_blocking_move_to
  current_position=(0.00, 0.00, 237.28) : clean_up_after_endstop_or_probe_move
<<< G28
>>> g28
SENDING:G28
>>> G28
Machine Type: Delta
Probe: FIX_MOUNTED_PROBE
Probe Offset X:0 Y:0 Z:-9.15 (Aligned With & Below Nozzle)
Auto Bed Leveling: BILINEAR (disabled)
  current_position=(0.00, 0.00, 237.28) : setup_for_endstop_or_probe_move
> endstops.enable(true)
  current_position=(0.00, 0.00, 237.28) : >>> home_delta
  current_position=(0.00, 0.00, 0.00) : sync_plan_position
>>> homeaxis(X)
Home 1 Fast:
>>> do_homing_move(X, 330.00, [60.00])
  current_position=(0.00, 312.55, 312.55) : sync_plan_position
<<< do_homing_move(X)
Move Away:
>>> do_homing_move(X, -5.00, [60.00])
  current_position=(0.00, 312.55, 312.55) : sync_plan_position
<<< do_homing_move(X)
Home 2 Slow:
>>> do_homing_move(X, 10.00, 30.00)
  current_position=(0.00, 312.55, 312.55) : sync_plan_position
<<< do_homing_move(X)
delta_endstop_adj:
>>> do_homing_move(X, -0.30, [60.00])
  current_position=(0.00, 312.55, 312.55) : sync_plan_position
<<< do_homing_move(X)
<<< homeaxis(X)
>>> homeaxis(Y)
Home 1 Fast:
>>> do_homing_move(Y, 330.00, [60.00])
  current_position=(-0.30, 0.00, 312.55) : sync_plan_position
<<< do_homing_move(Y)
Move Away:
>>> do_homing_move(Y, -5.00, [60.00])
  current_position=(-0.30, 0.00, 312.55) : sync_plan_position
<<< do_homing_move(Y)
Home 2 Slow:
>>> do_homing_move(Y, 10.00, 30.00)
  current_position=(-0.30, 0.00, 312.55) : sync_plan_position
<<< do_homing_move(Y)
delta_endstop_adj:
>>> do_homing_move(Y, -0.09, [60.00])
  current_position=(-0.30, 0.00, 312.55) : sync_plan_position
<<< do_homing_move(Y)
<<< homeaxis(Y)
>>> homeaxis(Z)
Home 1 Fast:
>>> do_homing_move(Z, 454.72, [60.00])
  current_position=(-0.30, -0.09, 0.00) : sync_plan_position
<<< do_homing_move(Z)
Move Away:
>>> do_homing_move(Z, -5.00, [60.00])
  current_position=(-0.30, -0.09, 0.00) : sync_plan_position
<<< do_homing_move(Z)
Home 2 Slow:
>>> do_homing_move(Z, 10.00, 15.00)
  current_position=(-0.30, -0.09, 0.00) : sync_plan_position
<<< do_homing_move(Z)
delta_endstop_adj:
>>> do_homing_move(Z, -1.45, [60.00])
  current_position=(-0.30, -0.09, 0.00) : sync_plan_position
<<< do_homing_move(Z)
<<< homeaxis(Z)
>>> set_axis_is_at_home(X)
For X
 position_shift = 0.00
 soft_endstop_min = -110.00
 soft_endstop_max = 110.00
  current_position=(0.00, -0.09, -1.45) :
<<< set_axis_is_at_home(X)
>>> set_axis_is_at_home(Y)
For Y
 position_shift = 0.00
 soft_endstop_min = -110.00
 soft_endstop_max = 110.00
  current_position=(0.00, 0.00, -1.45) :
<<< set_axis_is_at_home(Y)
>>> set_axis_is_at_home(Z)
For Z
 position_shift = 0.00
 soft_endstop_min = 0.00
 soft_endstop_max = 302.55
  current_position=(0.00, 0.00, 302.55) :
<<< set_axis_is_at_home(Z)
  current_position=(0.00, 0.00, 302.55) : sync_plan_position_kinematic
  current_position=(0.00, 0.00, 302.55) : <<< home_delta
>>> do_blocking_move_to(0.00, 0.00, 237.28)
  destination=(0.00, 0.00, 302.55) : set_destination_from_current
  destination=(0.00, 0.00, 237.28) : prepare_uninterpolated_move_to_destination
  current_position=(0.00, 0.00, 237.28) : zone border move
  current_position=(0.00, 0.00, 237.28) : xy move
<<< do_blocking_move_to
  current_position=(0.00, 0.00, 237.28) : clean_up_after_endstop_or_probe_move
<<< G28

i will try to get one when it fails.

[maviles798]

this is the code that gives me after a fail homing
Print started at: 14:55:08
echo:Unknown command: "G21"
Error:Printer halted. kill() called!
[ERROR] Error:Printer halted. kill() called!

[F0x06]

@maviles798
Already seen the Unknown G21 command message, I will try to enable debug and also give more informations, I can confirm that on older versions of Marlin I never had this issue.

[ejtagle]

G21: Enable inch support and you will get rid of it (even if you are not using inches in your gcode)

[F0x06]

Thanks for the tip @ejtagle in Configuration.h this can be enabled with #define INCH_MODE_SUPPORT
I finished the capacitors installation, I will come back for the results.

[cheerynik]

Опис

Мій принтер не налаштовується після друку, це дельта-принтер (лінійний плюс Anycubic Kossel), він добре друкувався, і з нізвідки він почав цю проблему.
Принтер відмінно працює, якщо я його автономно. але я не можу робити що-небудь, коли його зроблено друк, і він autohomes.

У відео я повинен натиснути endstop, щоб зупинити його з краху зі стовпом x.

БУДЬ ЛАСКА, ДОПОМОЖІТЬ.

Кроки до відтворення

1. Я щось надсилаю для друку
2. Друкує частину добре, без помилок
3. Коли він починає самонаведення після закінчення друку, він починає підніматися на невелику відстань, після чого двигуни y та z зупиняються і тільки двигун х продовжує зростати до тих пір, поки не зникне кадр, тоді на екрані принтера з'явиться ], і мені доведеться перезапустити принтер.

Додаткова інформація

• https://www.youtube.com/watch?v=euYCeoyhQk4

I have a similar problem anycubic kossel pulley. marlin 1.1.9
This is not the case in the previous version.

[cheerynik]

I solved this problem in the following way:
commented at the end of the team: program Cura-15.04 > end.gcode > G28 X0 Y0
my version of this team: > end.gcode > G28
and no more error, everything works fine.
screenshot > https://drive.google.com/file/d/19aQ8OVihISKA1N04M9E9zveIABI-vbvU/view?usp=sharing

;X0 Y0не має сенсу, якщо ";" інтерпретується як початок коментаря або нічого не робить в Марліні,

yes, everything was right to delete those values. I wanted to see what caused this error.

[AnHardt]

And why G28 at all?
If you want to go to [0,0,] use G1 X0 Y0. The numbers behind the axis qualifiers are NOT evaluated in Marlin at all. G28 is not a go to. It only determines where the print head is. It does it's job and leaves the printhead (more or less) where it is. The end position is not fixed. If you switch from min- to max- homing switches, the printhead will end up at the other end.
I'm not familiar with Curas end-code syntax or your notation, But homing in 3 axis instead of 2 befor is asking for trouble with a nozzle deep in your new printed part - if you home to z-min. ;X0 Y0 is either meaningless if the ';' is interpreted as begin of a comment, or does nothing in Marlin because our G0, G1 is not modal. You can't send an endless sequence of lines with coordinates. In Marlin (unlike a normal CNC machine) you have to repeat the command (G0, G1) in every line.

Ah. The screenshot clearifies. ; starts acomment. You could have just deleted that.

[thinkyhead]

In Marlin (unlike a normal CNC machine) you have to repeat the command (G0, G1) in every line.

Interesting point. Perhaps we should treat command lines that start with X, Y, Z, or F as a G0, G1, G2, G3, or G5 depending on the last one used…. as an option.

[AnHardt]

@thinkyhead
Have a look into the grbl parser or the NIST documents.
But it looks as if our interpretation is not a problem. At least the 3D-printer slicers and hosts do know about our interpretation.

On a DELTA everyting behind the G28 is meaningless anyway.

[cheerynik]

І чому G28 взагалі?

I'm an inexperienced user. my suggestion concerns only the error that occurs when finished printing in version 1.1.9. this error is on the video. At the end of the game, the G28 team solved this problem. it may be necessary to make corrections to the firmware, but I do not know where it can be changed in the firmware.
"end.gcode" there is a default snooze in the cura slicer program, I changed the command and there are no more errors. Here is a video of successful print ending after changing the command.
[] (https://drive.google.com/file/d/1y7LkegDCL7MQ6iTP5wf3wfTSGPazA90k/view?usp=sharing)

[pablopeu]

Just came here to comment that I also have this crashing on an anycubic delta plus, perfect print and then crash into the X column, will try to replace the endcode G28 by G0 X0 Y0 Z300 in CURA (3.41) and post results after some more prints.

[AnHardt]

Z0 is not a good choice! How about near Zmax?

[pablopeu]

I think you are commenting on my erroneous post, after posting it I noticed my error and changed it to z300, otherwise it would crash into the just finished print 😳

[AnHardt]

Emm - yes. Usually i scan the messages in my Thunderbird. I don't see any other way to handle more than 2500 messages a month alone for Marlin. Thunderbirds filters do help me a lot. But i don't get messages about edits.

[cheerynik]

you need to pay attention to when this error occurs. It seems to me that this happens after the printing is canceled. when the print is canceled and then we are passing a new task. After you cancel the print, you must restart the printer and re-connect with the print program. This option also helps to avoid printing errors. please try this option to solve this error. I will be grateful for the test.

[pablopeu]

I was next to the machine, I received it yesterday and it was build time 😀 I'm paying more attention to it than the sunday football,..
I was next to it when it finished the piece with surface ironing, saw after the print incremental moves and then to my horror go straight to the column and crashing into it (Im used to have a big red button on my CNC machine)
The print finished as it should, its the homing that failed.

What I can tell you is that I properly cancelled a previous job via the front panel (stop job) and after small correction in cura and without restarting the machine I proceeded to print as I described above.

[pablopeu]

Got it on video: https://www.youtube.com/watch?v=bwFKKYPyYho
Here is the STL and gcode: https://www.dropbox.com/s/442x65exgd6z5xf/20mm_stl%26gcode.rar?dl=0

Not sure what would be my action after the crash I turned off the machine in panic...

[AnHardt]

Where is your [0,0,0] located? For a DELTA BED_CENTER_AT_0_0 is absolutely required.
Is DELTA_PRINTABLE_RADIUS < DELTA_RADIUS * 2 ?
Are the ???_SOFTWARE_ENDSTOPS_? all on?

Diagonal rods can't be more than vertical or horizontal - else sign gets lost in sqrt(), other values go to infinity.

Do your slicer and your host both produce end-g-code? (protocol instead of source g-code)
Did you already post your configs?

[pablopeu]

Here are my configs: https://www.dropbox.com/s/e6baaznj6w78lts/Marlin%20Config%20Pablou%20crash%20delta.rar?dl=0
DELTA_RADIUS has a value thats overriden after calibration so I need to find out where to read the value at the machine.

If you check the video I posted I just noticed something weird, homing starts as it should after the print, but if you concentrate at the display and before I panic to turn the machine off, the X value thats fixed at 313 suddenly changes to 330 and that change makes it crash, at 1:00 in the video. Its like homing was all normal and a new destination point appeared that changed the head direction into the X column

[pablopeu]

just to be clear, the machine prints amazingly well, and it homes perfectly every time when the program starts, as Cura adds a G28 to each and every program start.

[AnHardt]

Did you ever test with ENDSTOP_NOISE_FILTER on ? The difference to the first homing could be, for example, a running part cooling fan causing noise on the endstops.

[pablopeu]

You are assuming there is a noise problem, I'm not, but I'll check it nevertheless, on weekdays I'll need to find the time.
The noise does not explain the sudden destination change on the display prior to the crash, or does it?
Not sure how ENDSTOP_NOISE_FILTER works on marlin, does it have a threshold to be set or the debounce time is preset?

[pablopeu]

I come from Mach3 automation world, and there the debounce is configurable, too high of a value and the switch is ignored altogether, that's why I ask, I don't want to change a crash midway for one at the top...

[AnHardt]

The display does not show where the nozzle is, but whats planned for it to go to.
As soon homing begins it shows
current_position[X_AXIS] = current_position[Y_AXIS] = current_position[Z_AXIS] = (delta_height + 10);
Any momentary triggered endstop will stop the common upward move. Thereafter the towers are homed individually. X begins do_homing_move(axis, 1.5f * max_length(axis) * axis_home_dir);
From the position the common move started, x should be the top most, so should have stopped at its endstop. But i can hear x running much too long for already being at the endstop before the belt begins to skip. I assume x is still not at the endstop when the skipping begins, but mechanically blocked by the other diagonals, pressing the carriage against the x-tower, or something similar.

[pablopeu]

OK, I don't recall if that was the case but it may be, crash was about midway to the end switches.

As I told you on the post above, I come from mach3 world (retroffited many machines) and I like to solve the problems at the hardware level first if its possible, so what would be the solution here? Use shielded cables for the switches its my first idea, add debounce circuitry second (cap+resistor), then if this fails do the software solution.
Shielded cables alone should solve it. what do you think?

[AnHardt]

See also https://github.com/MarlinFirmware/Marlin/issues/11907#issuecomment-424061047
A parallel 100nF capacitor is usually enough.

[pablopeu]

OK, have plenty, will check when I manage to get a few free hours and report back.

[maviles798]

I tried the capacitors and the printer keeps crashing to the x tower. The capacitors reduce the frequency of the printer failing but doesn't fix it

[pablopeu]

OK, I think I have audio shielded cable, will try that, the switch cables run thru the column core (good noise isolation) and then exit them almost touching the axis steppers which at that precise moment are moving fast, so a shield should help there.

Maybe a simpler solution may be just a little shield from scrap coaxial cable from where they exit the columns to the trigorilla board.

[F0x06]

Since I installed the 100nf capacitors no crashes anymore. 20 prints without problems now. I'm on bugfix-2.0.x

[fefmandan]

Hi, I have the same problem,After printing.It starts going up to home and it crashes in X.
Is it from the new firmware? cause before it was running fine,until I changed the firmware to 1.1.9.
Can some one help please?
I'm a beginner,so I don't know much about what is happening.
Thanks.

[pablopeu]

Installed the 100nf caps on all the three stops and managed to print twelve test coins in a row, my previous best was 4, left the machine printing overnight... will report if problem repeats...

[AnHardt]

@fefmandan
If you problem is really that much the same, why not just reading this thread up to here?

[AnHardt]

Yes, it is firmware. In previous versions we had a one-step-denoiser by default.

[F0x06]

@pablopeu Better soldering than mine lol

[AnHardt]

We slightly improved the description and the configurability of the noise filter in #11912. If you want more technological background have a look into my suggestion at #11917.

[fefmandan]

Thanks,I will try to Installed the 100nf caps. Thanks for the picture,At least I know where to install them.

[pablopeu]

We slightly improved the description and the configurability of the noise filter in #11912. If you want more technological background have a look into my suggestion at #11917.

so my understandment is that the improvement will be seen on 2.0 no hotfix for 1.1.9, will have to wait for stable new release.
Problem did not appear again, hopefully its gone for good.

[AnHardt]

Making the filter adjustable is a new feature. Probably this will not find its way back into the 1.x.x branches.

[Jellono]

I have seen this exact issue I upgraded my Anycubic Kossil from 1.1.0 to 1.1.9 and the trouble described began happening, I rolled back to the old firmware and all is well,

[pablopeu]

Install the capacitors, it solved the problem for me
On Oct 8, 2018, 21:47 -0300, Jellono [e-mail], wrote:

I have seen this exact issue I upgraded my Anycubic Kossil from 1.1.0 to 1.1.9 and the trouble described began happening, I rolled back to the old firmware and all is well,
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[thinkyhead]

I rolled back to the old firmware and all is well

That would work! Did you do any other troubleshooting first?

[dgrat]

I just finished building a 1m tall Delta. I confirm this issue. My guess is electrical noise and or no low pass filter? No oscilloscope here.

[schlnk]

I have exactly the same problem but on my cartesian printer (PrintBox3D One). It crushes sporadically while homing. Here the screenshot of the crash:

I managed to capture debug output of the failed G28, please see below. Position before G28 was 135.00, 110.00, 10.00. Also I noticed if ENDSTOPS_ALWAYS_ON_DEFAULT is enabled then my printer starts to print with enormous shifts in perimeters and infill. Hope this information will be helpful in narrowing the problem.

22:57:49.469 : <<< G28 22:57:52.067 : N24 G1 Z10 F300*48 22:57:59.932 : N25 G1 X50 F4800*8 22:58:00.151 : N26 G1 X100 F4800*63 22:58:00.311 : N27 G1 X150 F4800*59 22:58:03.354 : N28 G1 X185 F4800*60 22:58:04.510 : N29 G1 X185 F4800*61 22:58:04.888 : N30 G1 X185 F4800*53 22:58:06.071 : N31 G1 Y110 F4800*57 22:58:07.641 : N32 G1 X135 F4800*60 22:58:12.147 : N33 G28*35 22:58:12.150 : >>> G28 22:58:12.154 : Machine Type: Cartesian 22:58:12.154 : Probe: NONE 22:58:12.158 : Mesh Bed Leveling (disabled) 22:58:12.162 : current_position=(135.00, 110.00, 10.00) : setup_for_endstop_or_probe_move 22:58:12.167 : > endstops.enable(true) 22:58:12.167 : >>> homeaxis(X) 22:58:12.167 : Home 1 Fast: 22:58:12.171 : >>> do_homing_move(X, -285.00, [16.00]) 22:58:12.179 : current_position=(0.00, 110.00, 10.00) : sync_plan_position 22:58:20.735 : <<< do_homing_move(X) 22:58:20.735 : Move Away: 22:58:20.739 : >>> do_homing_move(X, 5.00, [16.00]) 22:58:20.743 : current_position=(0.00, 110.00, 10.00) : sync_plan_position 22:58:21.174 : <<< do_homing_move(X) 22:58:21.174 : Home 2 Slow: 22:58:21.178 : >>> do_homing_move(X, -10.00, 8.00) 22:58:21.182 : current_position=(0.00, 110.00, 10.00) : sync_plan_position 22:58:21.923 : <<< do_homing_move(X) 22:58:21.923 : >>> set_axis_is_at_home(X) 22:58:21.923 : For X axis: 22:58:21.927 : home_offset = 0.00 22:58:21.927 : position_shift = 0.00 22:58:21.931 : soft_endstop_min = 0.00 22:58:21.931 : soft_endstop_max = 190.00 22:58:21.936 : > home_offset[X] = 0.00 22:58:21.940 : current_position=(0.00, 110.00, 10.00) : 22:58:21.940 : <<< set_axis_is_at_home(X) 22:58:21.948 : current_position=(0.00, 110.00, 10.00) : sync_plan_position 22:58:21.952 : current_position=(0.00, 110.00, 10.00) : > AFTER set_axis_is_at_home 22:58:21.956 : <<< homeaxis(X) 22:58:21.956 : >>> homeaxis(Y) 22:58:21.956 : Home 1 Fast: 22:58:21.960 : >>> do_homing_move(Y, 240.00, [16.00]) 22:58:21.964 : current_position=(0.00, 0.00, 10.00) : sync_plan_position 22:58:22.763 : <<< do_homing_move(Y) 22:58:22.763 : Move Away: 22:58:22.767 : >>> do_homing_move(Y, -5.00, [16.00]) 22:58:22.771 : current_position=(0.00, 0.00, 10.00) : sync_plan_position 22:58:23.201 : <<< do_homing_move(Y) 22:58:23.201 : Home 2 Slow: 22:58:23.205 : >>> do_homing_move(Y, 10.00, 8.00) 22:58:23.209 : current_position=(0.00, 0.00, 10.00) : sync_plan_position 22:58:24.581 : Error:Printer halted. kill() called!

[AnHardt]

@schlnk
Denoise your endstops or activate ENDSTOP_NOISE_FILTER.

[schlnk]

Yes, I saw this advice earlier in this thread. But the strange thing is, that I didn't observe such behavior on the original firmware (sprinter). Also other people in this thread complain that this issue was introduced in 1.1.9, there were no such problems in earlier versions of Marlin. Is this a bug or these changes in endstops sensitivity were made intentionally? What was the purpose?

[p3p]

From what I remember we stopped compensating for noisy hardware by default so we didn't penalise well designed hardware with the loss in precision that the filtering caused, we added an option to turn the filtering back on for those that actually needed it.

[schlnk]

Thanks for the clarification. I'll try to denoise my endstops and report the result back.

[schlnk]

So, before installing capacitors I tried to dig into the problem with printer crash while homing more deeply. I have cartesian printer PrintBox3D One. It has normally closed endstops, wiring is done well - the wires from endstops are twisted. My train of thought was as follows:

1. The printer crashes at the arbitrary distance from the endstops. Because endstops are NC the only possible reason for that is contact bounce. So I tried to hook up oscilloscope and acquired impulses with amplitude 0,6Vcc (according to Atmega2560 datasheet this is logical 1) while homing. I tried amplitudes 1..3V with no luck. No such impulses were detected, but printer kept crashing.

2. So I decided to take another route. I turned on PINS_DEBUGGING and endstops monitoring with M43 E1. The result was interesting

In the successful Y homing attempt you can clearly see that Y endstop was hit:

Y_MAX:1
Y_MAX:0

But there is no such record in the failed attempt, because Y stopped halfway to home, but Marlin thinks it should be home for some reason. Complete log: rhlog.txt

So I think this problem is not caused by noisy endstops, something wrong with home movement planning.

I'm ready to help with narrowing this problem if you provide me with troubleshooting instructions.

PS. There is a bug in enable endstops monitoring code M43 E1. Marlin_main.cpp should be corrected as follows:

    // Enable or disable endstop monitoring
    if (parser.seen('E')) {
//    endstop_monitor_flag = parser.value_bool();
      Endstops::monitor_flag = parser.value_bool();
      SERIAL_PROTOCOLPGM("endstop monitor ");
//    serialprintPGM(endstop_monitor_flag ? PSTR("en") : PSTR("dis"));
      serialprintPGM(Endstops::monitor_flag ? PSTR("en") : PSTR("dis"));
      SERIAL_PROTOCOLLNPGM("abled");
      return;
    }

[pablopeu]

So, before installing capacitors...

If there is an error in the code, how do you explain that after installing the capacitors I never had this problem again? (touches wood lol)

[schlnk]

I don't know. But what I see from oscilloscope and from logs, is that no false triggering of endstop was registered.

Maybe it is some kind of race conditions in the code, and ENDSTOP_NOISE_FILTER just masks it?

BTW, capacitor, as far as I understand, also introduces inaccuracy in homing. If you have 100nF capacitor and use arduino pull-up resistor 20-50K, then you will have 0,005 sec delay in endstop detection. With homing speed of 20 mm/sec it could result in 0.1 mm positioning error.

[ejtagle]

@schlnk : Please remember Arduino is using interrupt-on-edge, so a pulse as narrow as 62nS should be enough to fool it... You need to configure your DSO for such narrow pulses...

[maviles798]

I don't think that it is a noice problem either become I installed the capacitors it worked perfectly for a couple of months and now I have the problem again.

[pablopeu]

I don't think that it is a noice problem either become I installed the capacitors it worked perfectly for a couple of months and now I have the problem again.

Where did you installed the caps, near the switches or near the board? Mine are very close to the board

[thinkyhead]

All you can do is keep adding debug logging at each level of endstop code until it's clear where the false trigger (if any) is occurring. It has to be on your machine since you have the issue. Maybe through this process some unexpected culprit may be discovered.

[schlnk]

It's me again. I spend a couple of hours trying to troubleshoot the problem. What I've done:

1. Soldered 100nF capacitors near endstop terminals on the shield (my printer has custom shield, not ramps).
2. Changed Endstops::run_monitor() to perform enstops checks more frequent: if (!monitor_count); monitor(); (disabled division counter check).
3. Tried to move Y axis back and forth (axis didn't touch endstop) in a loop and monitor console output. Look what I saw:
   

Do you see that sometimes Z_MIN endstop is detected, sometimes Y_MAX (my printer has Y_MAX) and sometimes even X_MIN (not shown on the screenshot). Timestamps (I used millis()) indicated that it was very short triggering.

So, capacitors obviously didn't solve the problem. Also is very strange, that DSO didn't registered any pulses with logical 1 level at endstop terminals either (my endstops are NC, I tried 2.4V, then lowered trigger to 1V and only at ~0.6V DSO catches something, but it couldn't be logical 1 afaik). It seems to me, that endstops inputs are triggering by very low level, but how is it possible? Are there any configuration parameters to adjust pin sensitivity on Arduino Mega?

I'm lost, do you have any ideas of further troubleshooting?

[thinkyhead]

NC switches should be immune to induction. Do you have the pullup resistors on or off? Try switching them the other way.

[ejtagle]

It's me again. I spend a couple of hours trying to troubleshoot the problem. What I've done…
…I'm lost, do you have any ideas of further troubleshooting?

If you are using millis(), then the time is more than a millisecond...
The Endstops::run_monitor() function is called every millisecond by the temperature timer ISR.
That function calls the Endstops::update() function, and that function directly reads the IO pins of the Arduino.

According to the Atmega datasheet, section 31.1, low level is below 5v * 0.3 = 1.5v. Any glitch above that and you could get a logic "1" (Vil)
And the logic "1" threshold is 5v * 0.6 =3v. Any voltage below 3v is not warrantied to be a "1" logic value (could read as a 0)

But, the problem i do suspect you could be having is either a bad solder joint, or a ground bounce problem.

Does the problem happen when the motors are moving, or when the heater is heating?
Are the limit switches NC to GND ?
Where is the GND of those switches taken from ? (you should NEVER take the GND from those switches from the power supply. GND for the switches should use a dedicated GND wire, and that wire should be tied to the GND of the limit switch entry exclusively...

[ejtagle]

And, as said by @thinkyhead , NC limit switches need PULL UP enabled (if they close to GND)

[schlnk]

NC switches should be immune to induction. Do you have the pullup resistors on or off? Try switching them the other way.

@thinkyhead Yes, pullups are enabled (ENDSTOPPULLUPS define in Configuration.h is uncommented). But I don't actually get what do you mean by _"Try switching them the other way"._ ? Do you mean I should try to resolder endstops to NO?

According to the Atmega datasheet, section 31.1, low level is below 5v * 0.3 = 1.5v. Any glitch above that and you could get a logic "1" (Vil)
And the logic "1" threshold is 5v * 0.6 =3v. Any voltage below 3v is not warrantied to be a "1" logic value (could read as a 0)

@ejtagle I set up my DSO to acquire pulses with more than 1V amplitude, but it didn't catch anything. Prior installing capacitors I also noticed that endstop triggering was detected when I just touch my endstop terminal by DSO probe. Endstop was closed to GND at that moment. How could it be?

Does the problem happen when the motors are moving, or when the heater is heating?

@ejtagle Heater is turned off. I observed the problem when motors were moving (I experimenting only with Y motor). But prior to installing capacitors I suspect that I saw the problem when no motors were moving.

Are the limit switches NC to GND ?
Where is the GND of those switches taken from ? (you should NEVER take the GND from those switches from the power supply. GND for the switches should use a dedicated GND wire, and that wire should be tied to the GND of the limit switch entry exclusively...

@ejtagle Below you can see the photo of my shield. GND is taken from GND pin of Arduino Mega. Arduino is powered via USB port by computer (Arduino doesn't have dedicated 5V power supply). Printer also has 24V PSU with dedicated GND (GND of Arduino and GND of PSU are not connected).

But, the problem i do suspect you could be having is either a bad solder joint, or a ground bounce problem.

I suspect that something wrong with the ground, because bad solder joint couldnt happen with all axes. Could you please direct me how I can troubleshoot it?

Thanks for your help, guys.

UPD1: Another observation. I suppose that these false endstop triggerings dont even correlate with the endstops noise. I set my DSO trigger level just above GND noise (~620mV), so it doesn't constantly stop acquiring signal. Then I ran G1 commands in a loop. False endsop triggering messages started to appear on the console, but nothing on DSO. DSO is directly hooked to Y_MAX pin on the shield. It is really weird.

UPD2: I resoldered endsop pins and GND on the shield to ensure this is not a soldering joint problem, but nothing has changed.

[schlnk]

For those who want to test their endstops for purity. Try to uncomment //#define ENDSTOPS_ALWAYS_ON_DEFAULT in Configuration_adv.h, disable #define ENDSTOP_NOISE_FILTER in Configuration.h if it was enabled, compile and upload firmware and try to print something not trivial (for example this). If you see shifts in layers or perimeters, then you have endstop problem.

[ejtagle]

@schlnk : completely independent GND between Arduino and PSU is impossible to achieve: Let´s assume you have opto-isolated solid state relays for your heatbed and hotend… The problem starts with the motor drivers.

All motor drivers so far require common ground between the Arduino and the Power supply (unless you are opto-isolating them…)

Consider each ground wire as a resistance: If the wires are not properly sized, then current peaks will make create a voltage drop in the GND cable. Depending on where there is a connection between the Arduino GND and the power GND, the Arduino GND could move relative to the power GND...

[thinkyhead]

I don't actually get what do you mean by "Try switching them the other way"

If pullups are off, try them on. If on, try them off. But they should most likely be ON.

[thinkyhead]

If you see shifts in layers or perimeters, then you have endstop problem.

The M43 E command can also be useful to watch endstops.

[schlnk]

Consider each ground wire as a resistance: If the wires are not properly sized, then current peaks will make create a voltage drop in the GND cable. Depending on where there is a connection between the Arduino GND and the power GND, the Arduino GND could move relative to the power GND.

@ejtagle I don't think this is the case. I'm pretty sure that Arduino GND and PSU GND are not connected (at least multimeter shows infinite resistance between them). And I would not be surprised that drivers has optoisolated inputs because this printer has custom drivers, you can see one of them on the pic. below.

And even if GNDs of Arduino and PSU were connected, Arduino measures signal relative to it's own GND. And if there were some logical 1 levels then my DSO obviously registered it.

If pullups are off, try them on. If on, try them off. But they should most likely be ON.

@thinkyhead thanks for the clarification, Pullups are on - I see Vcc on my DSO when endstops are hit, and this is correct I think. I don't understand how disabling pullups help narrow the problem.

The M43 Ecommand can also be useful to watch endstops.

Some modifications in the 1.9.x code should be made in order to make this command catch short endsops triggering:

1. The bug with enabling pin monitoring should be fixed (see PS in this post)
2. Check frequency should be increased as described in p.2 in this post. Otherwise false endsops triggering will not be detected (that's why I was initially thinking that the problem was in the firmware).

[thinkyhead]

The bug with enabling pin monitoring should be fixed (see PS in this post)

Fixed on October 26 in the bugfix-1.1.x branch.

Check frequency should be increased

Endstops used to be checked at the frequency of the stepper ISR (2KHz minimum and more often when actually moving) but I've been told on many occasions that 1KHz should be an adequate frequency to catch endstop signals — and this frequency shouldn't matter at all for switches which fully change state and stay there.

[yuyat]

Same here in my delta printer.

• v1.1.8 release works correctly.
• v1.1.9 release fails to home after done printing. It happens if printing lasts several hours, in short prints works well.

[thinkyhead]

How about bugfix-2.0.x?

[yuyat]

Temporary solution, at close range all endstops work properly.

G1 Z 298 X 0 Y 0
M104 S0
M140 S0
G91
G1 E-1 F300
G28
M84
G90

[TechyBen]

Getting similar error. No fault when using supplied firmware. Fault with 1.1.9. Always the same motor that stops working. Will try yuyats "fix" above in Gcode from CURA prints from SD card.

If it is hardware, its one that was filtered out in 1.1.8, but is now picked up in 1.1.9? I guess I could also attempt to print from PC and from SD and see if error only appears when printing from SD card?

[engelbja]

Same problem here, after print, homes a few mm correct and then slams into x tower.
Marlin 1.1.9 - Happens connected to Simplify3d and/or SD card

[maviles798]

You just have to add a 100 nanofarad capasitor to your endstops, that will fix the problem. Put them close to the moderboad for better results

[yuyat]

You just have to add a 100 nanofarad capasitor to your endstops, that will fix the problem. Put them close to the moderboad for better results

Why should we solve a software problem with hardware? In previous versions this problem doesn't exist.
It only happens when print has lasted a long time and the distance to HOME is> 5 cm.
If the printing lasts <2 or If I do HOME at 1 cm, there are no problems, it works correctly.

In addition, adding capacitors generates delays, which implies errors in the measurements. If you use G33 to calibrate your printer, you will be adding errors in each HOME of each iteration.

[pablopeu]

Its not a software problem if you fix it with hardware. The software
solution is a workaround for a common hardware problem...
Yes, you are aware of it now, because the software workaround was removed
in 1.1.9, don't worry, developers said they added a even better solution in
2.0

On Mon, Jan 7, 2019 at 4:05 PM yuyat [e-mail] wrote:

You just have to add a 100 nanofarad capasitor to your endstops, that will
fix the problem. Put them close to the moderboad for better results

Why should we solve a software problem with hardware? In previous versions
this problem doesn't exist.
It only happens when print has lasted a long time and the distance to HOME
is> 5 cm.
If the printing lasts <2 or If I do HOME at 1 cm, there are no problems,
it works correctly.

In addition, adding capacitors generates delays, which implies errors in
the measurements. If you use G33 to calibrate your printer, you will be
adding errors in each HOME of each iteration.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/11676#issuecomment-452045070,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AYlubMRdx8h9-Iy17rMh4Po-LLMFSKfoks5vA5pzgaJpZM4WT5U9
.

[maviles798]

If you don't like it don't use it, find a way to fix it on you own. Or wait to Marlin 2.0.
Works for me and for a lot of people.

[TechyBen]

Its not a software problem if you fix it with hardware. The software solution is a workaround for a common hardware problem... Yes, you are aware of it now, because the software workaround was removed in 1.1.9, don't worry, developers said they added a even better solution in 2.0
…
On Mon, Jan 7, 2019 at 4:05 PM yuyat @.*> wrote: You just have to add a 100 nanofarad capasitor to your endstops, that will fix the problem. Put them close to the moderboad for better results Why should we solve a software problem with hardware? In previous versions this problem doesn't exist. It only happens when print has lasted a long time and the distance to HOME is> 5 cm. If the printing lasts <2 or If I do HOME at 1 cm, there are no problems, it works correctly. In addition, adding capacitors generates delays, which implies errors in the measurements. If you use G33 to calibrate your printer, you will be adding errors in each HOME of each iteration. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#11676 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AYlubMRdx8h9-Iy17rMh4Po-LLMFSKfoks5vA5pzgaJpZM4WT5U9 .

How can it be a hardware problem is it does not happen when close to homing? The wires to the end stops don't change due to distance of the print head.

AH... I think I get it. When homing and distance over 5cm, the old "anti endstop interference trigger" protecting in code kicked in, then when under 5cm it did not? Now it's been removed entirely?

[pablopeu]

I think that continuing to discuss about if its hardware or software is
pointless due to the fact that 1.1.9 is not going to receive any more
updates and the problem in this thread is solved in 2.0...

A couple of workarounds are available in this same thread...

On Tue, Jan 8, 2019 at 7:25 AM TechyBen [e-mail] wrote:

Its not a software problem if you fix it with hardware. The software
solution is a workaround for a common hardware problem... Yes, you are
aware of it now, because the software workaround was removed in 1.1.9,
don't worry, developers said they added a even better solution in 2.0
… <#m_-3651013706139476746_>
On Mon, Jan 7, 2019 at 4:05 PM yuyat @.*> wrote: You just have to
add a 100 nanofarad capasitor to your endstops, that will fix the problem.
Put them close to the moderboad for better results Why should we solve a
software problem with hardware? In previous versions this problem doesn't
exist. It only happens when print has lasted a long time and the distance
to HOME is> 5 cm. If the printing lasts <2 or If I do HOME at 1 cm, there
are no problems, it works correctly. In addition, adding capacitors
generates delays, which implies errors in the measurements. If you use G33
to calibrate your printer, you will be adding errors in each HOME of each
iteration. — You are receiving this because you were mentioned. Reply to
this email directly, view it on GitHub <#11676 (comment)
https://github.com/MarlinFirmware/Marlin/issues/11676#issuecomment-452045070>,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AYlubMRdx8h9-Iy17rMh4Po-LLMFSKfoks5vA5pzgaJpZM4WT5U9
.

How can it be a hardware problem is it does not happen when close to
homing? The wires to the end stops don't change due to distance of the
print head.

AH... I think I get it. When homing and distance over 5cm, the old "anti
endstop interference trigger" protecting in code kicked in, then when under
5cm it did not? Now it's been removed entirely?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/11676#issuecomment-452248618,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AYlubCpAmHiVVtY71TiDku-rGcLv7Tuqks5vBHIXgaJpZM4WT5U9
.

[TechyBen]

Honest question. Why does "Auto home" when clicked on the display work every time. But Gcode homing (after print finish) fails a third of the time?

[JBTechRacing]

Same issue here. Kossel Linear Plus on Marlin bugfix 2.0 however. I notice mine does it after a rather long print. 4 hours or more then crashes into X tower. last Night I had a 13hr print going, woke up this morning to the head waded up into the X tower. Funny thing, if I go into Octo print, re-connect and click the Home button, it moves all motors up and homes properly. I also noticed this problem after I enabled Timelapse, could be a coincidence as I just enabled that after I did the 2.0 update. Short prints seem to work fine.

[pablopeu]

Installed the caps as I posted before and I use 1.1.9 over octoprint with
the timelapse enabled, never a problem again since they were installed.

On Tue, Jan 22, 2019 at 1:11 PM JBTechRacing [e-mail]
wrote:

Same issue here. Kossel Linear Plus on Marlin bugfix 2.0 however. I notice
mine does it after a rather long print. 4 hours or more then crashes into X
tower. last Night I had a 13hr print going, woke up this morning to the
head waded up into the X tower. Funny thing, if I go into Octo print,
re-connect and click the Home button, it moves all motors up and homes
properly. I also noticed this problem after I enabled Timelapse, could be a
coincidence as I just enabled that after I did the 2.0 update. Short prints
seem to work fine.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/11676#issuecomment-456457876,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AYlubLt1DPBPHKWqu-MWJQuyoMct4_XRks5vFzgxgaJpZM4WT5U9
.

[JBTechRacing]

This doesn't seem like a HW problem. If its a short time period print it homes fine, over about 4 hours and its like it doesn't know how to home properly. Personally, sounds like the caps are a band aid for a software problem. Mine has not proven to be elevation dependent, but more time dependent. Ive made short elevation prints that took a little over 2 hours and boom, it crashed on final homing. But I can do a quick print that's taller, and doesn't crash. Something isn't making sense here. And again, Im on Marlin 2.0

[engelbja]

I have this X tower problem on 20 minutes - 2hour prints - did not print any longer yet. With me it happens 100% of the time the last 15 prints.
I have played around with my ending script in Simplify 3d.
With my gcode in this way - I did not experience this problem on the last 5 prints:
M400
G91 ; set to relative position
G1 Z20 F4000
G90 ; set to absolute position
M104 S0 ; turn off extruder
M140 S0 ; turn off bed
M84 ; disable motors
M107 ; fan off
G28

I basically moved my G28 to the last position. Don`t know if the M84 disable motors are helping here.
Must maybe just add M84 before and after G28 .

I changed my gcode to above without the G28 command, just to raise the nozzle after a print, but now I added the G28 like above.

[engelbja]

My longest print now were 4 hours and about 20 different prints and on 1.1.9 it homes perfectly with the above end code

[dgrat]

My printer still crashes into the tower after a print in 2.0.x. Never happens if I have not started or stopped a print. Always happens if (100%). Need to restart if I want to home after stop/pause. Fans/Heater seem not to be the problem :/ I haven't checked whether the switches trigger while homing.

[boelle]

@maviles798 problem solved?

[maviles798]

@boelle yes you just have to add a 100 nf cap to the end switches

[engelbja]

I just use M84 before and after G28 and no more problems.
About 2 kg filament and 30 - 300 minute prints and no issues anymore.

[boelle]

@maviles798 so maybe click the green close button below?

[maviles798]

@engelbja do you add the m84 after and before in the end code or the start code? or in both?

[boelle]

@maviles798 click close, you can still write after its closed

[engelbja]

@engelbja do you add the m84 after and before in the end code or the start code? or in both?

Only in the end code.
This is my end code:
M400
M104 S0 ; turn off extruder
M140 S0 ; turn off bed
M107 ; fan off
M84
G28
M84

[engelbja]

Sorry edited my last comment, there are only a m84 before and after the G28

[AnHardt]

@engelbja
If M84 helps with homing your DELTA, then its likely your extruder stepper causing the noise on the endstop lined causing your trouble. Shielding the extruder stepper cable, separating extruder and endstop cables, denoise capacitors at the endstop connectors, software denoising will probably also have the same effect.

[engelbja]

I must also mention that I replaced the a4988 xyz with tmc2208. But had the same problem until I use the m84 before homing. But Yes I think you are correct. M84 was luckily just a easier fix in my case.

[hellochenwang]

For those who would like to know more about why adding the 100nF capacitor:

There are two sorts of crosstalk you can get between electrical wires:

1. Magnetic induction. A cable carrying a current that varies rapidly (even if only occasionally) generates a magnetic field, which can be coupled to another cable. For example, a stepper motor or bed heater cable could induce a voltage in an endstop switch cable. Minimise this be making sure that the outgoing and return conductors carrying the current are as close together as possible (i.e. in the same multicore cable), and preferably twisting them together. Similarly for the signal and ground connections of the endstop switch circuit.
2. Capacitive coupling. A cable carrying a varying voltage runs close to a signal cable with a high impedance input, and the capacitance between the cables gives rise to a voltage on the signal cable. Minimise this by shielding one or both cables (independently), or keeping them away from each other, or avoiding high impedance signal inputs.

source: https://reprap.org/forum/read.php?1,584390

[hapklaar]

I have this issue in latest Marlin 2 bugfix release on my AnyCubic Delta. Is the 100nF capacitor on endstops near mainboard still the best fix for this?

Can someone explain why this only happens on the X axis for everyone?

[TeodikD]

I have this issue in latest Marlin 2 bugfix release on my AnyCubic Delta. Is the 100nF capacitor on endstops near mainboard still the best fix for this?

Can someone explain why this only happens on the X axis for everyone?

No man don`t do that , you can easily fix it in your gcode building software

[TeodikD]

---

i really dont know what are you guyz talking abut.
are you crazy or something.
dont do that capacitor bull@#$% , maybe that works for some of you some times but it brings new problem with it and will damage your printer.
kossel after print homing fail is a simple bug by G.code building software`s like CURA.
all you have to do is change your homing style in your G.Code building software from "Cartesian" to "Delta".
Maybe in new Marlin update we get little fix that transform Cartesian_Homing_Code to Delta_Homing_Code by it self but until that Marlin Fix you can Fix it very easily.

---

1) open your Cura.
2) go to "Preferences" in top then "Configure Cura..."
3) go to "Printers" Tab // select your printer // click "Machine Settings"

((( now you can see "Start G-code" and "End G-code" )))

4) in End G-code side delete line "G28 X0 Y0"
5) under "M84" add "G28 ;Home"
6) Save and Done

your code will be like this in End G-code side.

---

M104 S0
M140 S0
;Retract the filament
G92 E1
G1 E-1 F300
M84
G28 ;Home

---

from now all G.codes that be made by your cura will be home 100% perfectly.

[Uthering]

i really dont know what are you guyz talking abut.
are you crazy or something.
dont do that capacitor bull@#$% , maybe that works for some of you some times but it brings new problem with it and will damage your printer.
kossel after print homing fail is a simple bug by G.code building software`s like CURA.
all you have to do is change your homing style in your G.Code building software from "Cartesian" to "Delta".
Maybe in new Marlin update we get little fix that transform Cartesian_Homing_Code to Delta_Homing_Code by it self but until that Marlin Fix you can Fix it very easily.

1. open your Cura.
2. go to "Preferences" in top then "Configure Cura..."
3. go to "Printers" Tab // select your printer // click "Machine Settings"

((( now you can see "Start G-code" and "End G-code" )))

1. in End G-code side delete line "G28 X0 Y0"
2. under "M84" add "G28 ;Home"
3. Save and Done

your code will be like this in End G-code side.

M104 S0
M140 S0
;Retract the filament
G92 E1
G1 E-1 F300
M84
G28 ;Home

from now all G.codes that be made by your cura will be home 100% perfectly.

Nice try, yet not works for me :(

It looks like only X-axis motor works on G28 command. So, if the model is not high, then X-endstop will not be reached and head will bump the X-axis stand.

Could someone help me to locate the code that is responsible for such behaviour?

[wyattearp]

FYI - with a 2.0.5.3 build of Marlin - this still sporadically happens with my AnyCubic. I assume no one here found a solution?

[henridbr]

I get the same trouble with my AnyCubic Kossel Linear +.
I change from Anycubic firmware to Marlin 2.0 which works fine except this one.
It occurs sporadically.
I'll check the M84 before G28 trick.
I am using Simplify3D : FFF settings -> Scripts -> Ending Scripts -> add M84 before G28.
One can also modify directly the Gcode file using Notepad.
Seems to work fine.

[wyattearp]

@henridbr it's probably pretty common - but this was the code that seemed to cause the issue, maybe one in 10 times:

M140 S0
M107
M104 S0
M140 S0
;Retract the filament
G92 E1
G1 E-1 F300
G28 X0 Y0
M84
M82 ;absolute extrusion mode
M104 S0
;End of Gcode

I read through the G28 code and didn't see an obvious flaw, but I'm wondering if I need to look through the M84 to see if it would have set something else (also - i think it's odd that my Delta printer came with instructions to give G28 X0 Y0 when it should just be G28 I think).

[wyattearp]

Actually, I think this is an error in G28.cpp:234 - planner.sychronize(); isn't called before the checking of homing_needed() and this function depends on externs in motion.cpp which _could_ possibly be modified by one of the other G# up there - still reading though but it seems odd to me to not wait for the planner to finish before checking to see if you should do something.

[henridbr]

You are probably right.
It seems also correct to stop all items at the job's end and then park.
Perhaps looking at M84 to see how it works.

[thinkyhead]

Put M400 before M84 to add extra insurance that the planner will be empty before the steppers are disabled. Note that M84 by itself calls planner.finish_and_disable while M84 with one or more axes will call planner.synchronize before disabling any steppers.

Be cautious in using M84 in G-code because some pre-configured machines or hosts may want to do something "when the print completes" that expects the motors to be enabled.

It may be cleaner for some to set a motor inactivity timeout that always applies, such as 5 minutes, and then let the machine time out the steppers after they've stopped moving instead of putting M84 into the ending G-code in the slicer.

[wyattearp]

It still feels like the issue is either with G28 or the command before it based on the logs:

end: N2078 G92 E1*123
Recv: X:3.53 Y:-2.83 Z:9.90 E:1.00 Count A:19248 B:19470 C:19160
Recv: ok
Send: N2079 G1 E-1 F300*56
Recv: ok
Send: N2080 G28 X0 Y0*40
Recv:  T:199.44 /0.00 B:44.95 /0.00 @:0 B@:0
Recv: echo:busy: processing
Recv:  T:199.67 /0.00 B:44.92 /0.00 @:0 B@:0
Recv: echo:busy: processing
Recv:  T:200.31 /0.00 B:44.81 /0.00 @:0 B@:0
Recv: echo:busy: processing
Recv:  T:200.49 /0.00 B:44.75 /0.00 @:0 B@:0
Recv: echo:busy: processing
Recv:  T:199.93 /0.00 B:44.75 /0.00 @:0 B@:0
Recv: echo:busy: processing
Recv:  T:199.14 /0.00 B:44.66 /0.00 @:0 B@:0
Recv: echo:busy: processing
Recv:  T:197.80 /0.00 B:44.61 /0.00 @:0 B@:0
Recv: echo:busy: processing
Recv:  T:195.92 /0.00 B:44.50 /0.00 @:0 B@:0
Recv: echo:busy: processing
Recv:  T:194.08 /0.00 B:44.45 /0.00 @:0 B@:0
Recv: echo:busy: processing
Recv:  T:192.01 /0.00 B:44.31 /0.00 @:0 B@:0
Recv: echo:busy: processing
Recv: Error:Printer halted. kill() called!

Looking through the G1_G0.cpp now to see if I can understand why it might cause the next G28 to suck at life since there isn't a technically a real error in G28.cpp as best as I can tell (unless somehow bedlevel.cpp::set_bed_leveling_enabled() skips doing any of its planner actions.

[wyattearp]

FYI I have recreated this issue successful on the 2.0.5.3 release at least 5 times. Every time it is the same tower, tower A that the print head crashes into. I believe this is because of the delta.cpp:home_delta() function cleaning out the current position when it doesn't need to but I've not been able to snag the debug logs during a crash to prove it. If someone can explain to me why you would want to throw away the current position when you know it (as opposed to only setting it all to 0,0,0 when you don't know it), that would be extremely helpful for me to be able to commit a fix.

[cheerynik]

I read through the G28 code and didn't see an obvious flaw, but I'm wondering if I need to look through the M84 to see if it would have set something else (also - i think it's odd that my Delta printer came with instructions to give G28 X0 Y0 when it should just be G28 I think).

in my case it solved the problem of returning the extruder to its home position.

[wyattearp]

@cheerynik do you have a test gcode that causes the issue? I just generated one and will be testing again tonight and should hopefully have a patch tomorrow if it's fails the way I think it should with debug flags on

[cheerynik]

slice cura fix startup gcod remove x0 y0 leave g28. after that, there are no more errors in returning home.

[mberntsen]

I've been having the same problem, and I narrowed it down a bit with some additional logging and found the following:
homing a delta is composed of moving up to at least 1 stop, then move the X, Y and Z axis, because of this sequence, it always crashes into axis X.
I've made a program to repeatedly do G28 and G0 Z10, that's how I caught it
In my case an endstop is triggered (different ones each time), based on the interrupt data, which I find odd, but that's what it sais, so I'll be debugging my electronics a bit more.
I had a theory at one point that the probe (being connected to the Y_MIN pin) was triggered and that that made the vertical movement stop (it checks for 'an' andstop, not a specific one, but this does not seem to be the case with me.

[wyattearp]

@mberntsen yep - same thing. The endstop gets a false trigger. When it does, it believes that it's already at the top and thus crashes the into the X tower because the lines in the code individually home in the order of X, Y, Z.

[mberntsen]

I found out that my heavy powersupply (standard in my Anycubic predator) introduces so much noise, that it creates false triggers, must admit, my experimental electronics (esp32 on breadboard with i2c display and U8g2 lib) isn't the most emc compatible design :)

[thinkyhead]

We can't work around bad endstop signals, but smarter Delta homing might do this:

• Move all carriages up until some tower endstop is hit.
• Move all down a little and re-bump until the same stop is hit again.
  
  
  
  • If the endstop is not near where expected then throw an error
  
  
• Hold the tower carriage that hit the first endstop in place and...
• Move the other two up until some tower endstop is hit.
• Move both down a little and re-bump until the same stop is hit again.
  
  
  
  • If the endstop is not near where expected then throw an error
  
  
• Hold the tower carriage that hit the first endstop in place and...
• Move the remaining carriage up until its endstop is hit.
• Move it down a little and re-bump until the same stop is hit again.
  
  
  
  • If the endstop is not near where expected then throw an error
  
  

[jshutrump]

FYI - with a 2.0.5.3 build of Marlin - this still sporadically happens with my AnyCubic. I assume no one here found a solution?

Having same problem after I updated my board to a 32bit and new marlin. Any fix?

[wyattearp]

@jshutrump the current "fix" is to add caps to your end stop sensors, implementation of a software fix like @thinkyhead has discussed will require someone to write that type of routine in the delta.cpp:home_delta() code. The specific issue that around this chunk of code:

  //.....
  line_to_current_position(homing_feedrate(Z_AXIS));
  planner.synchronize();

  // Re-enable stealthChop if used. Disable diag1 pin on driver.
  #if ENABLED(SENSORLESS_HOMING)
    tmc_disable_stallguard(stepperX, stealth_states.x);
    tmc_disable_stallguard(stepperY, stealth_states.y);
    tmc_disable_stallguard(stepperZ, stealth_states.z);
  #endif

  endstops.validate_homing_move(); // <--- life goes bad here for false triggering

  // At least one carriage has reached the top.
  // Now re-home each carriage separately.
  homeaxis(A_AXIS);  // <---  A/X is the first one hit because going up slowly should trigger it, but it's too low and thus keeps going until it crashes the head into the tower.
  homeaxis(B_AXIS);
  homeaxis(C_AXIS);

  // Set all carriages to their home positions
  // Do this here all at once for Delta, because
  // XYZ isn't ABC. Applying this per-tower would
  // give the impression that they are the same.
  LOOP_XYZ(i) set_axis_is_at_home((AxisEnum)i);

As discussed above, if you want to fix this in software, the homeaxis() shouldn't be immediately called but should instead be re-validated by moving down a small percentage of the original distance traveled and then moving back up the same distance to verify that all endstops were hit, otherwise, declare a false, clear the endstops, ... etc.

[wyattearp]

Additionally if you're looking for a "quicker fix" you can try adjusting this in Configuration.h - but it didn't seem to help me:

/**
 * Endstop Noise Threshold
 *
 * Enable if your probe or endstops falsely trigger due to noise.
 *
 * - Higher values may affect repeatability or accuracy of some bed probes.
 * - To fix noise install a 100nF ceramic capacitor inline with the switch.
 * - This feature is not required for common micro-switches mounted on PCBs
 *   based on the Makerbot design, which already have the 100nF capacitor.
 *
 * :[2,3,4,5,6,7]
 */
#define ENDSTOP_NOISE_THRESHOLD 2

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.