[bugfix-1.1.x] axis homing halts

[Murloc992]

Description

I am trying to setup marlin bugfix-1.1.x on a Trigorilla 1.3 (not 32bit) board.

My X-Axis doesn't want to home no matter what I change. Endstop triggers are very fine. It feels like X axis somehow gets limited on the "MIN" side.

Other axis seems to be fine.

Before I disabled endstop validation printer would just halt itself on X homing.

Steps to Reproduce

1. Manually move X axis to the maximum possible
2. Send a G28 or just G28 X0
3. Observe as X axis does a "ghost" endstop movement in a random spot of the axis, endstop is OPEN
4. Send multiple G28 (or X0) commands till it homes properly
5. Endstop is now TRIGGERED

Expected behavior: It should home on X axis without ghost endstops.

Actual behavior: What I mentioned in the steps part.

Additional Information

This includes configuration.h configuration_adv.h and pins_trigorilla_13.h:
Marlin.zip
Video:
https://www.youtube.com/watch?v=jAUTN1cb_n8

[GMagician]

Maybe you have unfiltered input and some electrical noise will send fake results.
You may try to solve enabling ENDSTOP_NOISE_FILTER in configuration.h.
If it solve you are in such situation and your hardware is weak to electrical noise. Solution is proposed directly in cnf file just above option. If you can't solve in hardware you must live with this option and all negative effects it has.

Don't know which endstop you have, if simple switch, you can try to connect com to "signal", NC to +5V and NO to GND, enable ENDSTOPPULLUP_XM??, but this depends on your knowledges. All these HW operations are intended to be done only if you know what you are doing, you may destroy your hardware.

EDIT: with last suggestion you also have to set to false als X_M??_ENDSTOP_INVERTING

[Murloc992]

My endstops are basic switches. I will try this option. The thing is, other endstops are the same for Y and dual Z endstops and they work perfectly fine.

This is how they look like:

Pins are soldered, from the point of reference they are C NO NC.
Edit1:They are infact soldered as you are saying me to do. I will see what pullups do.
Edit2:They are enabled in my configuration..

There's also a LED connected to COM with a resistor.

[Murloc992]

The noise filter has helped I think. Yet I don't understand what has changed in bugfix-1.1.x to have caused my X endstop to not work anymore?

When I flash older firmware I have (https://github.com/derhopp/Marlin-with-Anycubic-i3-Mega-TFT/tree/bugfix-1.1.x) it works without a budge with identical configuration file.

When I flash newer firmware back it does "ghost" endstop only on X...

[GMagician]

New firmware have changed how endstop detection works. Now is less immune to noise but was done this way to have a more precise and repetitive home position.
Looking at image I think I see a led and a resistor (used to limit led current). No capacitor to filter noise.

Maybe X is noisy because of where cables run along your printer.

[Murloc992]

So basically only way to solve this would be to add 100nF capacitor to the endstop?

[GMagician]

For sure capacitor will filter noise. I think that your board doesn't have any (trigorilla I think is a ramps derived board).

Missing capacitor is a hardware design fault. If option has solved issue that capacitor will do the same (in a better way)

[GMagician]

Note that you have inverting endstops to true so I think your board will close to 5V when micro is pressed. My solution was to close to GND

[Murloc992]

My endstop wiring is like this now, looking at the PCB:
S goes to COM
G goes to NO
V goes through the LED and COM

[GMagician]

Don't know how led is connected but maybe it's not good to change connection

[Murloc992]

LED is connected between V and S. Would a 10uF capacitor do for a test or is it too much?

[GMagician]

ok, so it's really as I told you.. when micro is pressed it close to GND and led will turn on.

I'm not smart in electronic but I think the bigger the capacitor is and stronger the filter will be. Too strong is not good, too few wil not filter enough.
There is a formula to find out filtered frequency.

[Murloc992]

I looked into the wiring. X is the only one connected differently from the others.. It doesn't have the LED hooked up to anything. I bet it's one of the culprits. I might just try to guide a "hack" wire and adjust the connector to make it work like the others.

[Murloc992]

I just added a 10uF capacitor for a test and it works. So if somebody could close this it would be nice. Huge thanks @GMagician !

[GMagician]

You may close it by pressing butto below

[Murloc992]

Woops :)

[Murloc992]

No, adding 100nF capacitors does not fix the issue. It still halts.

I know the soldering job looks a bit shoddy, but multimeter says everything is as it should be.

[Murloc992]

In fact it's only dual Z endstops that fail. They do hit once, then slowly twice and printer halts itself.

[GMagician]

Ok, just to be sure, now what happens? home should be X, Y and then Z. Before was X failing now is Z that fails?

[Murloc992]

X homes, hits endstop twice, this is fine.
Y homes, hits endstop twice too, also fine.
Z homes, hits endstops, rises a bit, hits endstops again slowly. This is normal behavior with old firmware but this time it just fails when it triggers second time.

I tried to "delevel" the Z axis to see what happens, but it levels and homes perfectly, just that it halts.

M119 shows correct number of endstops(X, Y, Z, Z2, Probe) and all function properly.

I am at a loss.

[GMagician]

What do you means with

hits endstops again slowly. This is normal behavior with old firmware but this time it just fails when it triggers second time.

does/doesn't it stops?
or just it doesn't rise again?

Do you still have filter option enabled?

Edit: also you may try to compile with DEBUG_LEVELING_FEATURE option and before homing call M111 S255 this way we well have a debug info to analize

[Murloc992]

Filter is disabled. It homes Z normally, it hits one time normal speed, one time slow speed and stops. After it stops it halts.

[GMagician]

Ok let's try with debug option and M111

[Murloc992]

M111 S38
SENDING:M111 S38
echo:DEBUG:INFO,ERRORS
echo:busy: processing <<< homing Z happens here
Error:Printer halted. kill() called!
[ERROR] Error:Printer halted. kill() called!

This is all I get.

[GMagician]

s255 is more complete

[Murloc992]

It printed me probably whole memory map of the board and then homed Z and halted. No extra info.

All I know is that it fails on endstops.cpp line 233 Endstops::validate_homing_move method.

[Patrick60]

I can confirm the issue on the CR-10S described by seetth. It's only present on Y axis (maybe because the switch is right next to the stepper motor).
I've added a 1uF ceramic capacitor on the switch (in parallel) but it changed nothing.
There's a false detection during the Y movement and either when it stops on the false detection and when it comes back it doesn't trigger the switch anymore, I then have an exception (machine stopped) or it does and the zero Y is in the middle of nowhere. In my case, ENDSTOP_NOISE_FILTER solves the issue. The +/- 0.2mm is not a problem on X and Y axis but not on the Z one so I tweaked the firmware to avoid doing it on that axis.
In the comment, it's indicated that before the firmware performed 2 readings but now without that define (which is the default), it only does one and it maybe explains why it worked with 1.1.8 and not 1.1.9.
I've added a log and apparently on the CR-10S, false detection appears from time to time even when the machine is idle (but with motors on, didn't try off)). I guess that 2 readings should be enough to get rid of it.

[Seetth]

@Patrick60 2 readings? What line or function is that so I can give it a try, in the other hand yes it is random when that issue happens.

[Patrick60]

In file endstops.cpp, at line 516, you have endstop_poll_count = 7;
Change 7 to 1 and you get 2 readings and not 8. it should be the same than in version 1.1.8.
Finally, I have false detection on Z axis too with my BLTouch and so I left this mechanism activated on all axis.

[Seetth]

@Patrick60 If I understood everything (im a noob) the problem its located at endstops.cpp i did change the endstop_poll_count value to 1, but for me still is the same I get halts when homing only at marlin 1.1.9 (Y axis)

[Patrick60]

@Seetth You can change it to 2 rather than one, it will make 3 readings rather than 2 in case you have much noise on this signal (that's my setting, I didn't try 1). Also, are you sure you un-commented (removing the // at start of line) the define ENDSTOP_NOISE_FILTER in configuration.h ?

[Seetth]

@Patrick60 ENDSTOP_NOISE_FILTER option doesn't affect accuracy?

[Patrick60]

@Seetth It affects accuracy when the value is 7 as the reading needs to be 8 times the same to be validated. With 1, you get the same result than with 1.1.8.

[GMagician]

With 1, you get the same result than with 1.1.8.

Not sure about that. Old code tested endstops inside stepper isr and now in temperature isr (every 1ms).

Accuracy is non completely depending on repeat number. Considering that filter is used when a "noise" is present and such noise is "variable" then accuracy depends also by noise itself.

[Seetth]

So in resume if I dont want to risk lose accuracy I better stay on marlin 1.8 until I find I way to get rid of my Z homing halts in marlin 1.9?

[thinkyhead]

Or, ensure noiseless endstop and probe lines. Most probes already filter for noise at the probe side, but induction in the wiring is always a risk with N-O switches. Adding a small capacitor / resistor combo to endstop lines filters out inductive noise and cosmic rays.

[davidramiro]

There's a false detection during the Y movement and either when it stops on the false detection and when it comes back it doesn't trigger the switch anymore, I then have an exception (machine stopped) or it does and the zero Y is in the middle of nowhere. In my case, ENDSTOP_NOISE_FILTER solves the issue. The +/- 0.2mm is not a problem on X and Y axis but not on the Z one so I tweaked the firmware to avoid doing it on that axis.

Hi @Patrick60,

hope you are reading this, I am eager to know how you avoided the noise filter to work on the Z-axis. While I don't have this problem myself, I have a repo of Marlin 1.1.9 for the Anycubic i3 Mega and I have had two people report the same issue, see davidramiro/Marlin-Ai3M#8
ENDSTOP_NOISE_FILTER seems to fix the issue though I don't want to mess with the accuracy of the Z axis. Can you tell me how you proceeded?

Best regards,
David

[MischaI]

I have this trouble too. i will test witch ENDSTOP_NOISE_FILTER

[ruggb]

There's a false detection during the Y movement and either when it stops on the false detection and when it comes back it doesn't trigger the switch anymore, I then have an exception (machine stopped) or it does and the zero Y is in the middle of nowhere. In my case, ENDSTOP_NOISE_FILTER solves the issue. The +/- 0.2mm is not a problem on X and Y axis but not on the Z one so I tweaked the firmware to avoid doing it on that axis.

Hi @Patrick60,

hope you are reading this, I am eager to know how you avoided the noise filter to work on the Z-axis. While I don't have this problem myself, I have a repo of Marlin 1.1.9 for the Anycubic i3 Mega and I have had two people report the same issue, see davidramiro/Marlin-AI3M#8
ENDSTOP_NOISE_FILTER seems to fix the issue though I don't want to mess with the accuracy of the Z axis. Can you tell me how you proceeded?

Best regards,
David

David - I had issues with a mis-triggering Z endstop when I switched to a piezo endstop. I put a 500ms delay in the Z home routine. That was when I had 1.1.9. Since the last 1.1.9 and now with 2.0, I have not put that mod in and it has been working. I also, long ago, had issues with erratic temp control and found out it was noise induced in the thermo sense line by the hotend 12V fan line. I separated those lines and have had no issue. So I would recomment looking at those two things.

[Babbott173]

I can confirm the issue on the CR-10S described by seetth. It's only present on Y axis (maybe because the switch is right next to the stepper motor).
I've added a 1uF ceramic capacitor on the switch (in parallel) but it changed nothing.
There's a false detection during the Y movement and either when it stops on the false detection and when it comes back it doesn't trigger the switch anymore, I then have an exception (machine stopped) or it does and the zero Y is in the middle of nowhere. In my case, ENDSTOP_NOISE_FILTER solves the issue. The +/- 0.2mm is not a problem on X and Y axis but not on the Z one so I tweaked the firmware to avoid doing it on that axis.
In the comment, it's indicated that before the firmware performed 2 readings but now without that define (which is the default), it only does one and it maybe explains why it worked with 1.1.8 and not 1.1.9.
I've added a log and apparently on the CR-10S, false detection appears from time to time even when the machine is idle (but with motors on, didn't try off)). I guess that 2 readings should be enough to get rid of it.

Patrick60 and Seetth.. I third that notion. CR10S BLtouch. Perfectly fine on 1.1.8 then on 1.1.9 Y endstop randomly stops before limit switch and I get a "Homing Failed. PRINTED HALTED. Please Reset". I have started from scratch about 6 times on 1.1.9 files all the way from PrintedSolid 118/119 to TH3d and of course from scratch Marlinfw.org 118 and 119. Always boils down to 119. Im out of ideas and don't want to go back to 118 if we can help it. Has anyone figured this out yet? is it a bug?

[Seetth]

@Babbott173 I just went back to 118 sometime ago, I tried it everything capacitors other endstop switch, printedsolid th3d and official marlin fw several times, etc just keeps happening the same, 118 no problem at all stock endstop no caps or the new ones with caps, few people have this issue but seems we are not that many to take a look on it. The only good thing of this issue its that my printer is ninja silent, I replaced also the steepers

[Babbott173]

@Babbott173 I just went back to 118 sometime ago, I tried it everything capacitors other endstop switch, printedsolid th3d and official marlin fw several times, etc just keeps happening the same, 118 no problem at all stock endstop no caps or the new ones with caps, few people have this issue but seems we are not that many to take a look on it. The only good thing of this issue its that my printer is ninja silent, I replaced also the steepers

@Seetth Yeah I know what you mean. Im working on getting more silent too lol. I have been down for almost 5 weeks being too stubborn to go back to 118. Im assuming you have the Noctura fan on your hotend and also inside your control box?... I have overhauled all fans and including my hotted Noctura... trying to single out all hardware. maybe we have something that is matching installed that is doing this?......I just remembered that i installed an inline noise filter that came with my Noctura fan recently to my control box. Thinking its possible that it can be sending noise down the rails.

[Seetth]

@Babbott173 Better stepeers makes a big difference to factory ones are damn noisy and transfer a lot of vibrations, new stepeers plus dampers made a huge difference plus my control box etc does not exist anymore.

The steppers I install it: https://www.amazon.com/gp/product/B06XSYP24P/ref=ppx_yo_dt_b_asin_title_o00__o00_s00?ie=UTF8&psc=1

How my printer is at the moment (all this triggered cause I want it the version 119 what at the end I cannot use, lol)
https://gyazo.com/c57cf046a58615f92fff468597c75b17

[Seetth]

I may got confused with this and yes I still have the printer halt on 1.9 so I dont use it.

About the noise filters and accuracy lose, when we say accuracy lose we are talking about where the printer homes or do homing or we are talking about the prints accuracy? I hope I make my self clear my english is just bad.

[GMagician]

About the noise filters and accuracy lose, when we say accuracy lose we are talking about where the printer homes or do homing or we are talking about the prints accuracy? I hope I make my self clear my english is just bad.

Only home position is affected by accuracy

[AnHardt]

With noise filtering the home-/probe- position is slightly different - more far away then without.
But has about the same repeatability - will find always the same position.
You may need an other endstop-/probe- offset when changing the amount of filtering, but this will stay the same thereafter.

[Babbott173]

Problem solved!! Don't settle for ENDSTOP_NOISE_FILTER guys!!! I meant to get back to you all but I found out the actual problem. Do all of you have cable extensions??? that is the common denominator here. separate your switch and motor wires from the bundle and BAAAM....no more HALT! i just had to do it for my Y axis. Thanks for your help everyone!

[AnHardt]

At least for the diagnostic of the class of problem where axis stops to move before they reach their target
ENDSTOP_NOISE_FILTER is a worthy tool. If enabling ENDSTOP_NOISE_FILTER helps it's clear - you have a noise problem and not an obscure bug in Marlin..

[Seetth]

Problem solved!! Don't settle for ENDSTOP_NOISE_FILTER guys!!! I meant to get back to you all but I found out the actual problem. Do all of you have cable extensions??? that is the common denominator here. separate your switch and motor wires from the bundle and BAAAM....no more HALT! i just had to do it for my Y axis. Thanks for your help everyone!

DEAR GOD! Yes that was my problem the damn extension cables, I cannot believe that extension generates this long long issue for me, im on marlin 1.9 now no issues at all (extension cable is gone) I wonder if somehow 1.9 is more susceptible to interference since pretty much that extensions are poorly and cheaply made (mine was replaced with a home made build from a shielded cat5 cable and no problem at all, for test i reinstalled my old Z extension cable and the halt start it again.)

Thanks for sharing @Babbott173

[Babbott173]

No Problem! Went on way to long for me too and when I got it figured out you all came to mind!:) Hope this helps everyone else who might be googling this issue going crazy with no answers lol.

@Seetth

[jontech19]

Problem solved!! Don't settle for ENDSTOP_NOISE_FILTER guys!!! I meant to get back to you all but I found out the actual problem. Do all of you have cable extensions??? that is the common denominator here. separate your switch and motor wires from the bundle and BAAAM....no more HALT! i just had to do it for my Y axis. Thanks for your help everyone!

Can you take a picture on how you did it. I don't want to use the ENDSTOP_NOISE_FILTER. Thanks in advance

[ruggb]

Motors are inductors. They generate flyback pulses. There are no flyback diodes on any driver boards that I know of. When I put a diode pack on mine, the change in noise level and missed steps was dramatic. I didn't have switch noise, but I didn't have any wires running with the motor wires either. I did have issues with temp control -- thermistor wires run with fan wires -- Obviously, running any input wires with motor or fan wires is looking for trouble, but I highly recommend those diodes also.

[mecanum]

I had a handmade Prusa i3 with Marlin 1.0.x and no issues with end switches. I decided to update to 1.1.9 and axis homing halts appeared since first homing in axis X and Y. My end stops wires run very close to steppers. I didn't want to rewire the printer, so I soldered a 100 nF capacitors in paraIlel to my endswitches in the electronic side (ramps), and issue solved.

[github-actions]

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.