Marlin: [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.

[yagona]

I also have a modified ANYCUBIC i3 Mega. (I replaced, e.g., all stepper drivers with TMC2208.) As long as I used derhopp's fork of Marlin 1.1.8 or bugfix-1.1.x everything was fine. Recently I merged derhopps's bugfix-1.1.x with the latest Marlin bugfix-1.1.x causing exactly the same problem with z homing as described by Murloc992. I also get the kill message as stated above. However, somehow I could get M111 S38 working with the following result:

LESEN: TFT Serial Command: A21 Z
LESEN: echo:enqueueing "G28 Z"
enqueueing "G28 Z"
LESEN: >>> G28
LESEN: Machine Type: Cartesian
LESEN: Probe: NONE
LESEN: current_position=(-5.00, 0.00, 5.00) : setup_for_endstop_or_probe_move
LESEN: > endstops.enable(true)
LESEN: >>> homeaxis(Z)
LESEN: Home 1 Fast:
LESEN: >>> do_homing_move(Z, -307.50, [4.00])
LESEN: current_position=(-5.00, 0.00, 0.00) : sync_plan_position
...
LESEN: <<< do_homing_move(Z)
LESEN: Move Away:
LESEN: >>> do_homing_move(Z, 2.00, [4.00])
LESEN: current_position=(-5.00, 0.00, 0.00) : sync_plan_position
LESEN: echo:busy: processing
busy: processing
LESEN: <<< do_homing_move(Z)
LESEN: Home 2 Slow:
LESEN: >>> do_homing_move(Z, -4.00, 1.00)
LESEN: current_position=(-5.00, 0.00, 0.00) : sync_plan_position
...
LESEN: <<< do_homing_move(Z)
LESEN: >>> do_homing_move(Z, 0.00, [4.00])
LESEN: current_position=(-5.00, 0.00, 0.00) : sync_plan_position
LESEN: Error:Printer halted. kill() called!
LESEN: TFT Serial Debug: Kill command... J11

[GMagician]

@yagona in your configuration do you have Z_DUAL_ENDSTOPS_ADJUSTMENT equal to 0?
@yagona and @Murloc992 try to set a different value for such parameter.

@thinkyhead and @ejtagle I think that in some situation like this, after home is done, hit_on_purpose will clear hit_state variable and on dual stepper systems, with no offset between 2 steppers, do_homing_move will wrongly test at end if micro are hits and they are not (flag cleared before and not enough time elapsed to set them again in temperature isr). This will kill the system.

[GMagician]

@yagona and @Murloc992 you can try also adding endstops.update call just before endstops.validate_homing_move call in do_homing_move function. This to temporary patch issue

[Murloc992]

@GMagician Z_DUAL_ENDSTOPS_ADJUSTMENT is 0. I have tried to add endstops.update() call before line 3020 in marlin_main but nothing really changed.

What should I try with the adjustment? Positive or negative values?

[yagona]

@GMagician Yes, I had Z_DUAL_ENDSTOPS_ADJUSTMENT at 0. Now, I changed to 0.025 by "M666 Z0.025". This seems to solve the issue. Output is now:

LESEN: TFT Serial Command: A21 Z
LESEN: echo:enqueueing "G28 Z"
enqueueing "G28 Z"
LESEN: >>> G28
LESEN: Machine Type: Cartesian
LESEN: Probe: NONE
LESEN: current_position=(0.00, 0.00, 30.00) : setup_for_endstop_or_probe_move
LESEN: > endstops.enable(true)
LESEN: >>> homeaxis(Z)
LESEN: Home 1 Fast:
LESEN: >>> do_homing_move(Z, -307.50, [4.00])
LESEN: current_position=(0.00, 0.00, 0.00) : sync_plan_position
...
LESEN: <<< do_homing_move(Z)
LESEN: Move Away:
LESEN: >>> do_homing_move(Z, 2.00, [4.00])
LESEN: current_position=(0.00, 0.00, 0.00) : sync_plan_position
...
LESEN: <<< do_homing_move(Z)
LESEN: Home 2 Slow:
LESEN: >>> do_homing_move(Z, -4.00, 1.00)
LESEN: current_position=(0.00, 0.00, 0.00) : sync_plan_position
...
LESEN: <<< do_homing_move(Z)
LESEN: >>> do_homing_move(Z, 0.03, [4.00])
LESEN: current_position=(0.00, 0.00, 0.00) : sync_plan_position
LESEN: <<< do_homing_move(Z)
LESEN: >>> set_axis_is_at_home(Z)
LESEN: For Z axis:
LESEN: home_offset = 0.00
LESEN: position_shift = 0.00
LESEN: soft_endstop_min = 0.00
LESEN: soft_endstop_max = 205.00
LESEN: > home_offset[Z] = 0.00
LESEN: current_position=(0.00, 0.00, 0.00) :
LESEN: <<< set_axis_is_at_home(Z)
LESEN: current_position=(0.00, 0.00, 0.00) : sync_plan_position
LESEN: current_position=(0.00, 0.00, 0.00) : > AFTER set_axis_is_at_home
LESEN: <<< homeaxis(Z)
LESEN: current_position=(0.00, 0.00, 0.00) : sync_plan_position
LESEN: current_position=(0.00, 0.00, 0.00) : clean_up_after_endstop_or_probe_move
LESEN: X:0.00 Y:0.00 Z:0.00 E:0.00 Count X:0 Y:0 Z:0
LESEN: <<< G28

[Murloc992]

@GMagician @yagona interestingly only M666 worked. This solves the issue I guess? Kind of.

[GMagician]

@Murloc992 value should be offset to align two steppers.
But I'm wondering if micro is pressed when such command is executed

[GMagician]

@Murloc992 this is only a temporary patch. it's unusual but M666 Z0 could be a possible value

[Murloc992]

@GMagician both switches get pressed. I will look at this and see if any solution is proposed. :)

[GMagician]

theoretically changing Z_DUAL_ENDSTOPS_ADJUSTMENT will move an axis and this will let endstops.update to be called. calling it before endstops.validate_homing_move should temporary fix as well, but it seems not. Maybe something is escaping from my check

[yagona]

@GMagician I did some further testing according to your suggestions. The results are:

• "M666 Z0.025" suppresses the issue
• both microswitches get pressed (tested by misaligned Z1 and Z2 before homing)
• "Z_DUAL_ENDSTOPS_ADJUSTMENT at 0.025" suppresses the issue as well as M666
• adding "endstops.update" call does not seem to have any effect

[GMagician]

ok, thanks, for the moment you have a solution (I hope you really need z adjustment to align Z1 with Z2). Then I hope someone with more knowledge will try to solve this

[yagona]

@GMagician Thanks a lot for your help! Your suggestions were very useful to identify the probable cause of this issue.

I'd like to add that "M666 Z0.001" also suppresses the issue. This should be well below the resolution of the microswitches.

[Murloc992]

M666 Z0.001 saves itself as Z0.00. It works fine. Maybe it's related to this "floating maths" fix?

[GMagician]

Don't know but for sure also 0 should work. There is something somewhere that doesn't detect endstop status correctly and this will raise error. Changing value will put a movement in planner and there endstop are updated. Don't know more, maybe I'll try to investigate deeper but this goes beyond my limits

[GMagician]

@Murloc992 found something. When stepper are not moving Endstops.update doesn't update anything so basically doesn't workl

[ejtagle]

As stated by @GMagician , M666 schedules a new movement to the queue. I don´t have a Delta, so i can´t test this, but, does M666 Z0 change the homing sequence at all ?

Endstops are updated 1000 times a second in that configuration (because there is no interrupt on endstop feature enabled) - So adding an extra movement should not make a difference

Your description of the issue is a little bit vague: Do you mean the printer halts and needs a reset to resume operation ? (a kill operation ?)

[GMagician]

@ejtagle kill means it completely stop working with message "printer halted".
When movement is queued an endstops.update si called in planner and this will set hit_state (micro are still pressed). After do_move hit_state is tested and if 0 kill

[GMagician]

@ejtagle this is sequence that lead to issues:

• last slow move to find micro
• micro found, steppers stop and endstops.validate_homing_move is called. This will test hit_state, that is ok, and reset it.
• do_home_moving is called to align steppers but since space=0 I think it will not insert anything into queue, but endstops.validate_homing_move is called and this time hit_state is 0 and printer is killed.

As told before by changing Z value with M666 if will put something into planner and since planner call endstops.update here 'hit_state' is updated and set != 0. Once endstops.validate_homing_move is called it doesn't fail.
I think that this issues is also present for all ?_DUAL when offset is 0

[ejtagle]

The only way this could happen is if between the call to endstops.hit_on_purpose() and the call of endstops.validate_homing_move() less than 1 millisecond (and thus, not temperature ISR that updates the endstops) happen.
Adding a safedelay() call of about 5 milliseconds insde validate_homing_move() should fix this issue then. But not when using ENDSTOPS_INTERRUPTS ... As the endstop state is only updated on changes, and no changes are expected if no movements are done.
I maybe the logic is somehow flawed, as originally validate_homing_move() should only be called if there was a move!

[GMagician]

The only way this could happen is if between the call to endstops.hit_on_purpose() and the call of endstops.validate_homing_move()

I think this may be highly probable since no movement are involved, code may take less than 1ms to reach failing call

I maybe the logic is somehow flawed, as originally validate_homing_move() should only be called if there was a move!

const bool is_home_dir = (axis_home_dir > 0) == (distance > 0)

when distance is 0 may be also true and this will call failing function... it should be enough to not set this variable and everything will be ok... In such situation maybe also bl-bouch could be lowerd and this is not good

[ejtagle]

The planner can optatively not schedule a move... :

  // Bail if this is a zero-length block
  if (block->step_event_count < MIN_STEPS_PER_SEGMENT) return false;

Also, the call to stepper.quick_stop() can cause some problems... as that call just sets a flag to abort on the next step ISR. So, a small delay (1mS) could be needed.

[GMagician]

Also, the call to stepper.quick_stop() can cause some problems... as that call just sets a flag to abort on the next step ISR. So, a small delay (1mS) could be needed.

or not to call endstops.validate_homing_move at all (as you said).
Note that as stated above, calling do_homing_move with distance = 0 will also deploy probe and this is not good. In my opinion to solve this should be enough:

const bool is_home_dir = (axis_home_dir > 0) == (distance > 0) && distance

this will solve interrupt case, distance = 0 case and all other

Edit: merging another pull request of mine bl-touch is already fixed even without fixing this

[ejtagle]

@GMagician : I remember when @thinkyhead added the validate_homing_move() call. It was to prevent the issue that when an endstop was not triggered, the homing procedure continued and that was a dangerous behaviour for deltas. If it was for me, i´d add an extra parameter fo the function, but, also changing the condition is fine.
Please, remember that distance is a float, so comparing with 0 will usually lead to errors.

I´d add the check at the start of the function that ensures if distance is below a certain limit, either positive or negative, just do nothing:

if (UNEAR_ZERO(ABS(distance))) return;

[GMagician]

I remember when @thinkyhead added the validate_homing_move() call. It was to prevent the issue that when an endstop was not triggered,

thats ok, but this code raise a "printer kill" and is not also good.

distance is a float, so comparing with 0 will usually lead to errors.

That's true when value is derived from computation, 0 is a well defined value for FP IEEE so if it comes from a #define then match will always succeed

Also test you made may lead to error since it should test something abs "below" MIN_STEPS_PER_SEGMENT converted to axis unit

[ejtagle]

@GMagician : Completely agree with your comments
We should somehow check if movement was queued or not. _populate_block already returns that information, and that information is returned by planner.buffer_line(), so, if it returns false, no movement was queued and no check should be done 👍

[ejtagle]

But, if movement is too short, that function will also return true... :(

[ruggb]

the problem with that endstop is that the signal line is connected thru an LED which has about 1.8V drop. You do not have endstop pullups enabled therefore the inactive voltage on the input pin as about 2.5 - 3V. That isn't a reliable off state with any amount of noise.
I recommend enabling the endstop pullups. If the endstops have been made more sensitive, that just means they have taken the anti-bounce logic out which is the cause of your problems. Instead of waiting for a solid low, it triggers on the first transition. The capacitors you added helped, but enabling the pullups should solve it completely. Leave the logic set to true - that is for active low inputs.

My endstops have pullups and capacitors so I have the pullups disabled.

[GMagician]

@ruggb as I know he has already remove filter and added pullup. Now problem is kill due to a bug in firmware

[GMagician]

@Murloc992, @maar1201gh can you test posted code? it should fix issue but if someone can test it....remember to set offset to 0 and M502/M500 to reset saved value (or m666 just before home)

[yagona]

11261 fixed the homing issue on z for me. Thanks to everyone who contributed to this!

[maar1201gh]

@GMagician , sorry for delay. I tested with #define Z_DUAL_ENDSTOPS_ADJUSTMENT 0 and everything Ok.

Thanks

[GMagician]

@maar1201gh no problem, if also @Murloc992 confirm that this is fixed he may close issue report.

Thanks to all for all test done.

[Murloc992]

@GMagician I was away for a bit, I will test this today and see what is up. :)

[Murloc992]

Yes, it works perfectly!

Thanks @GMagician :)

[Seetth]

Sorry for re-open this again, I have the same issue but mine its a CR-10S, my ends stops are filtered with a cap since long time ago, I have no issues at all with marlin 1.8 but with 1.9 the printer almost always halt when is doing Y homing, 1st do like a if was stuck advance a bit then go back a bit then halt the printer, only on Y axis aka the bed, so far I have found no solution for it thats why I ended here.

Thanks in advance.

[ruggb]

mine did something like that when I forgot to change the polarity of the endstop input.

[thinkyhead]

@Seetth — See if the ENDSTOP_NOISE_FILTER option helps at all.

[Seetth]

This is what the printer do when that happens, https://youtu.be/vjE2ugflItE

@thinkyhead Far as I understand the ENDSTOP_NOISE_FILTER can affect the printer accuracy (im a noob so not everything its clear for me on many points) thats why im still refusing to use ENDSTOP_NOISE_FILTER option.

I use activate the linear advance option on 1.8 and I really like it now I can print really fast now w/o lose quality, I read that linear advance its better on 1.9 that its why im trying to make it run.

[ruggb]

@Seetth I see no movement of the Z axis. X & Y appear to home properly. What am I missing?
Set your Z axis (vertical movement) mid point then run G28. What happens?

[Seetth]

@ruggb My bad for my bad video, what my printer do always for homing since I have the same settings for 1.1.8 and 1.1.9. It's:

Z-lift 5mm
Home X
Home Y
Home Z

With the motors disabled if I home myself Y im almost sure that never happen and I can make a full homing doesnt matter where X or Z are.

At home Y its when this randomly happens. On Z lift 5 mm or home X never happens the other thing I have no normal now its that the BLtouch its my Z endstop since I change a lot the build platforms, I find out that was possible use the BLtouch also for endstop and works perfect for me, with and without BLtouch acting as endstop I have the same issue on 1.9 (the switch for minimum position aka home im not sure if endstop its the right name)

[ruggb]

@Seetth I am having some difficulty understanding you. Sorry.
Your homing process, Z-lift 5mm then, Home X, Home Y, Home Z is normal.
Your video shows Y homing properly, so I am confused about which axis you are referring to.
I am assuming your X axis refers to the carriage position on the gantry; your Y axis refers to your bed's horizontal position front to rear; your Z axis refers to your bed's vertical position, or the vertical position of your gantry.

Using BLTouch as an endstop seems hard to do with consistent results but if you have it working, that is good. I am using a piezo triggered by my nozzle for ABL and endstop, which is awesome.

"(the switch for minimum position aka home im not sure if endstop its the right name)" is the same thing.

Since the problem occurred when you went from 1.8 to 1.9, I am assuming the problem is in the transfer of your settings in the config files. However, bed level code has also changed and a few new variables added. So it might be that all your settings have been implemented but something new has been overlooked.

If you upload both your 1.8 and 1.9 configuration.h files I will compare them and see if I can determine if it is a config issue.

[Seetth]

Sorry for the confusing video, I can confirm that the printer halt on Y axis randomly aka the bed and only in the bed, about the BLtouch as endstop at least for me become a really reliable endstop I never had troubles with it (im using the pseudo smart version) depends on what I doing I change the printer surface from tempered glass to borosilicate ( i think that is the name) to PEI to mirror thats why I attempt to use bltouch like that and im really happy with the results.

As soon I get home I upload both files.

Thanks for answer me.

[ruggb]

yes I do the same thing with my piezo endstop. It sure makes life easier than readjusting the mechanical stop. So the problem is intermittent and does not show on the video. That may be a clue.

[Seetth]

@ruggb Im still out of the city but yes the problem its intermittent but always its the bed only when that happens. Sorry for my ignorance but what its a piezo endstop? I dont know that ones.

[ruggb]

A piezo is a electrical device that moves with applied voltage, often used as a speaker. However, it also works in reverse and produces a voltage with applied pressure. It comes in various size discs. I adapted one to my carriage so when the nozzle hits the bed it moves the piezo and triggers the endstop. It is very sensitive and repeatable withing 0.008mm.

[ejtagle]

@ruggb : A piezo is a great limit switch, but without proper signal conditioning, it is prone to noise pickup ,,, And the pulse that produces is extremely short.
The only reliable solution is to disable the noise filtering and also use proper signal conditioning, otherwise you WILL end with false positives and unreliable homing.
There is no possible sw workaround for this: In this case, i repeat, proper signal conditioning IS A MUST.

[ruggb]

@ejtagle thanks, you are preaching to the choir. Of course I have the interface board and I implemented a 200ms delay (sw workaround--something the developers might want to consider implementing with a variable option) in the home Z movement to let the X&Y home settle out first. I also have to make sure the print fans were not running, which normally they are not unless I bypass some normal procedure. My hotend fan is always on but causes no issues.
However, as long as I don't try to pull filament off the nozzle when it is homing everything is perfect.
It is hard to beat 0.008mm repeatability, isn't it?

[thinkyhead]

a 200ms delay … in the home Z movement

I know we did add some delays for sensorless homing.
If it can help in more cases, sounds like a good idea.

[ruggb]

@thinkyhead - I added my delay (looks like it is 500ms not 200) at the beginning of the Z home routine in Marlin-Main.cpp at about line 4030

      do_blocking_move_to_xy(destination[X_AXIS], destination[Y_AXIS]);
      safe_delay(500); //** settling delay for piezo b4 homing Z
      homeaxis(Z_AXIS);

If u do that the delay time probably needs to be a setting in a config file.
I have a corexy and the gantry movement would trigger the piezo without it.

[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 https://github.com/davidramiro/Marlin-AI3M/issues/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[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.