Printer fails to home after done printing #11676
Comments
thinkyhead
added
the
T: Question
|
|
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. |
|
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 |
|
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 |
|
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 |
|
@maviles798 Thank you for the solution, i will try the capacitor one, because |
|
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. |
|
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: |
|
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 Try a very small G-code that does a few moves and then has a |
|
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. |
|
I install the capacitors and the printer keeps going to the x tower when its done printing some times. Log Outputi will try to get one when it fails. |
|
this is the code that gives me after a fail homing |
|
@maviles798 |
|
G21: Enable inch support and you will get rid of it (even if you are not using inches in your gcode) |
|
Thanks for the tip @ejtagle in Configuration.h this can be enabled with |
I have a similar problem anycubic kossel pulley. marlin 1.1.9 |
|
yes, everything was right to delete those values. I wanted to see what caused this error. |
|
And why G28 at all? Ah. The screenshot clearifies. |
Interesting point. Perhaps we should treat command lines that start with |
|
@thinkyhead On a DELTA everyting behind the G28 is meaningless anyway. |
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 |
|
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. |
|
Z0 is not a good choice! How about near Zmax? |
|
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 😳 |
|
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. |
|
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. |
|
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,.. 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. |
|
Got it on video: https://www.youtube.com/watch?v=bwFKKYPyYho Not sure what would be my action after the crash I turned off the machine in panic... |
|
Where is your [0,0,0] located? For a DELTA 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) |
|
Sorry edited my last comment, there are only a m84 before and after the G28 |
|
@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. |
|
For those who would like to know more about why adding the 100nF capacitor:
|
|
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 |
|
i really dont know what are you guyz talking abut.
((( now you can see "Start G-code" and "End G-code" )))
your code will be like this in End G-code side. M104 S0 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? |
|
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? |
|
I get the same trouble with my AnyCubic Kossel Linear +. |
|
@henridbr it's probably pretty common - but this was the code that seemed to cause the issue, maybe one in 10 times: 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). |
|
Actually, I think this is an error in G28.cpp:234 - |
|
You are probably right. |
|
Put Be cautious in using 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 |
|
It still feels like the issue is either with Looking through the |
|
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 |
in my case it solved the problem of returning the extruder to its home position. |
|
@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 |
|
slice cura fix startup gcod remove x0 y0 leave g28. after that, there are no more errors in returning home. |
|
I've been having the same problem, and I narrowed it down a bit with some additional logging and found the following: |
|
@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. |
|
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 :) |
|
We can't work around bad endstop signals, but smarter Delta homing might do this:
|
Having same problem after I updated my board to a 32bit and new marlin. Any fix? |
|
@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 //.....
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 |
|
Additionally if you're looking for a "quicker fix" you can try adjusting this in /**
* 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 |
* merged in changes in bug fixes since they all make sense * merged in head since fixing types makes sense as well * still looking into how to address MarlinFirmware#11676 - confirmed code location of errors with homing
|
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. |
and others
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
Additional Information
The text was updated successfully, but these errors were encountered: