Closed maviles798 closed 5 years ago
Configuration.h
and Configuration_adv.h
files.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
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.
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 ?
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 endstopnoise filter
@maviles798 Thank you for the solution, i will try the capacitor one, because endstop_noise_ filter
impact homing precision.
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
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"
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.
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. this is the code of a normal g28 comand.
i will try to get one when it fails.
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!
@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.
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 #define INCH_MODE_SUPPORT
I finished the capacitors installation, I will come back for the results.
Опис
Мій принтер не налаштовується після друку, це дельта-принтер (лінійний плюс Anycubic Kossel), він добре друкувався, і з нізвідки він почав цю проблему. Принтер відмінно працює, якщо я його автономно. але я не можу робити що-небудь, коли його зроблено друк, і він autohomes.
У відео я повинен натиснути endstop, щоб зупинити його з краху зі стовпом x.
БУДЬ ЛАСКА, ДОПОМОЖІТЬ.
Кроки до відтворення
- Я щось надсилаю для друку
- Друкує частину добре, без помилок
- Коли він починає самонаведення після закінчення друку, він починає підніматися на невелику відстань, після чого двигуни y та z зупиняються і тільки двигун х продовжує зростати до тих пір, поки не зникне кадр, тоді на екрані принтера з'явиться ], і мені доведеться перезапустити принтер.
Додаткова інформація
I have a similar problem anycubic kossel pulley. marlin 1.1.9 This is not the case in the previous version.
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.
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.
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.
@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.
І чому 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)
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,.. 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.
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...
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?
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
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.
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.
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?
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...
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.
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?
See also https://github.com/MarlinFirmware/Marlin/issues/11907#issuecomment-424061047 A parallel 100nF capacitor is usually enough.
OK, have plenty, will check when I manage to get a few free hours and report back.
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
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.
Since I installed the 100nf capacitors no crashes anymore. 20 prints without problems now. I'm on bugfix-2.0.x
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.
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...
@fefmandan If you problem is really that much the same, why not just reading this thread up to here?
Yes, it is firmware. In previous versions we had a one-step-denoiser by default.
@pablopeu Better soldering than mine lol
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.
Thanks,I will try to Installed the 100nf caps. Thanks for the picture,At least I know where to install them.
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.
Making the filter adjustable is a new feature. Probably this will not find its way back into the 1.x.x branches.
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