X Axis home fails

[notching]

Seemingly having an issue where X axis home is not working. Steps to reproduce:

1. Move carriage to extreme right
2. Send home X axis request
3. Carriage moves about half way along the axis, before stopping and giving up. Does not make it to stop switch.
4. Prints are misaligned on the bed.

May be related to: MarlinFirmware/Marlin#11224
(although this turned into a Z axis issue).

Does not happen with original Anycubic FW.

[davidramiro]

Hi and thanks for the feedback, sadly I cannot reproduce this issue.

To troubleshoot further, can you please send me your complete output of M503? Furthermore, please enable full debugging with M111 S247 and call G28 X. Anything interesting on the terminal when it stops halfway?

[notching]

Output from octoprint terminal is not very helpful:

Send: M111 S247
Recv: echo:DEBUG:ECHO,INFO,ERRORS,COMMUNICATION
Recv: ok
Recv: T:29.50 /0.00 B:29.43 /0.00 @:0 B@:0
Recv: T:29.50 /0.00 B:29.49 /0.00 @:0 B@:0
Recv: T:29.50 /0.00 B:29.43 /0.00 @:0 B@:0
Send: G28 X
Recv: echo:G28 X
Recv: T:29.50 /0.00 B:29.46 /0.00 @:0 B@:0
Recv: echo:busy: processing
Printer seems to support the busy protocol, will adjust timeouts and set busy interval accordingly
Recv: T:29.50 /0.00 B:29.40 /0.00 @:0 B@:0
Recv: Error:Printer halted. kill() called!
Changing monitoring state from "Operational" to "Error: Printer halted. kill() called!"
Changing monitoring state from "Error: Printer halted. kill() called!" to "Offline (Error: Printer halted. kill() called!)"
Connection closed, closing down monitor

M503

Send: M503
Recv: echo: G21 ; (mm)
Recv:
Recv: echo:Filament settings: Disabled
Recv: echo: M200 D1.75
Recv: echo: M200 D0
Recv: echo:Steps per unit:
Recv: echo: M92 X80.00 Y80.00 Z400.00 E438.12
Recv: echo:Maximum feedrates (units/s):
Recv: echo: M203 X500.00 Y500.00 Z6.00 E60.00
Recv: echo:Maximum Acceleration (units/s2):
Recv: echo: M201 X3000 Y3000 Z60 E10000
Recv: echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
Recv: echo: M204 P4000.00 R3000.00 T4000.00
Recv: echo:Advanced: Q<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> X<max_x_jerk> Y<max_y_jerk> Z<max_z_jerk> E<max_e_jerk>
Recv: echo: M205 Q20000 S0.00 T0.00 X20.00 Y20.00 Z0.40 E5.00
Recv: echo:Home offset:
Recv: echo: M206 X0.00 Y0.00 Z0.00
Recv: echo:Mesh Bed Leveling:
Recv: echo: M420 S0 Z0.00
Recv: echo:Endstop adjustment:
Recv: echo: M666 Z0.00
Recv: echo:PID settings:
Recv: echo: M301 P17.49 I1.29 D59.10
Recv: echo: M304 P216.90 I42.70 D275.43
Recv: echo:Linear Advance:
Recv: echo: M900 K0.00
Recv: ok

[notching]

Note that if I send the home request twice at the start of a print - all is okay.

[notching]

note that this only happens "sometimes". Here's the output of a good x home:

Send: G28 X
Recv: echo:G28 X
[...]
Recv: echo:busy: processing
[...]
Recv: echo:busy: processing
Recv: X:-5.00 Y:0.00 Z:5.00 E:0.00 Count X:-400 Y:0 Z:2000
Recv: ok

[davidramiro]

Please try again with the newest release and reset your EEPROM after (M502 + M500). For testing, please only use your adjusted Titan extruder steps, without adjusting acceleration and jerk.

[notching]

Have tried this. Still the same issue unfortunately. I'm wondering if this is the way anycubic have wired the end stop sensors (perhaps lack of pulldowns/ups) + the v1.1.9 sensing change. May be time to get out the oscilloscope...

[davidramiro]

There is an option to enable electromagnetic interference filtering in Marlin, described as follows:

 /**
 * Endstop Noise Filter
 *
 * Enable this option if endstops falsely trigger due to noise.
 * NOTE: Enabling this feature means adds an error of +/-0.2mm, so homing
 * will end up at a slightly different position on each G28. This will also
 * reduce accuracy of some bed probes.
 * For mechanical switches, the better approach to reduce noise is to install
 * a 100 nanofarads ceramic capacitor in parallel with the switch, making it
 * essentially noise-proof without sacrificing accuracy.
 * This option also increases MCU load when endstops or the probe are enabled.
 * So this is not recommended. USE AT YOUR OWN RISK.
 * (This feature is not required for common micro-switches mounted on PCBs
 * based on the Makerbot design, since they already include the 100nF capacitor.)
 */

Which version of the firmware are you using (TMC2208, reversed, stock)? I can enable it and compile it on a test build for you.

[notching]

Thanks, I'm using TMC2208 reversed. If you send me the config I can play around with different settings as well.

[davidramiro]

Alright, maybe this one works for you: https://kore.cc/i3mega/download/testing/notching-190103-TMC2208_reversed-TEST.hex

The complete source is included in this repository, so feel free to tinker around. For this build I have reversed the motor direction from line 857 to 865 and uncommented line 590 to enable the noise filter.

[notching]

Thanks David. This has (after 30 or so checks) fixed the issue.
Looking at the switch PCB's there's a no pull-up/down resistor or cap on these - just an unused current limit resistor for an LED that does not turn on.
There could be filtering on the trigorilla PCA, but have not got that far yet.

[davidramiro]

Glad this issue is fixed for now, though I am surprised I have never encountered this issue and never got a similar bug report.
Even if their design is missing any filter, maybe yours is faulty in another way. Might be worth a try to use the spare one they included in the package. Or adding a 100nF capacitor wouldn't be so hard either, since Marlin does not recommend using this option if you can avoid it - it needs additional processing power on an already weak 8bit chip.

I'll close this issue for now but please keep me updated if you decide to investigate further.

[notching]

Had already replaced the switch :-).

If the Trigorilla is based on the Ramps board (think it is) - then there's no pullup/down resistors, just the internal CPU resistor. This is likely to be weak, making the likelihood of noise introducing issues high - especially if the wires are placed next to current carrying ones - like the stepper motors.

Suspect this will affect a proportion of units - probably depends how close the current carrying wires are to the endstop sense wires. We may want to consider including this feature in the main branch if others report the same issues.

[davidramiro]

If you already ruled out the switch itself it is safe to say it's just a matter of time since we get another report on this. Especially with the addition of PWM powered heatbed, this is just asking for EMI issues. I am surprised you're the first one since this FW is at over 1200 downloads so far. Any mods on your end that might be a source of interference?

Please let me know if you run into any CPU overhead issues while printing - e.g. frequent busy processing reports on the terminal. If everything is going well, I will definitely add this.

[notching]

If I'm reading the changes in the source code - it seems that v1.1.9 code is only checking the value once. This is just bad programming practise for an unfiltered input on a microcontroller. There must be a way of checking this more frequently (-0.2mm is quite a bit of CPU time). I guess this was changed for some other reason, a compromise likely.

I'm planning on introducing the BL-touch sensor - an additional 0.2mm won't work for this sigh. Actually worried about Z levelling now as well!

May just be better to add caps for v1.1.9 on other alternative is to "fix" the 0.2mm v1.1.9 issue in firmware - if even possible.

I'll let you know how I get on with this, If I see any issues etc

[davidramiro]

0.2mm is definitely concerning, especially on a dual Z endstop machine, even without a BLtouch. Not so much for X and Y, but I like my nozzle not to crash into the bed because of this inaccuracy. Didn't think that through, now I am very hesitant to ship this as default in the firmware.

Maybe decreasing the number of samples used to detect a faulty trigger might at least reduce the travel over/undershoot by a bit? Referencing https://github.com/davidramiro/Marlin-AI3M/blob/master/Marlin/endstops.cpp#L540

[notching]

Wouldn't a better way to be stop the stepper on the first endstop signal, then check the signal again a number of times. If the signal is no longer present, start the stepper up again, and repeat (up to 3x) until the endstop signal is good? Perhaps thats too drastic a change.

Assuming that 50% of samples is bad is a little silly IMHO. Usually it's an outlier or two. If we set endstop_poll_count = 2 or 3 should get rid of most of the issues - but this still leaves us with 0.1mm?

[notching]

OR - perhaps - we slow down the speed of the steppers when homing? Longer to home but more accurate.

[davidramiro]

Wouldn't a better way to be stop the stepper on the first endstop signal, then check the signal again a number of times. If the signal is no longer present, start the stepper up again, and repeat (up to 3x) until the endstop signal is good? Perhaps thats too drastic a change.

Might be a good way, though I reckon this would better be suggested to the Marlin team themselves.

Assuming that 50% of samples is bad is a little silly IMHO. Usually it's an outlier or two. If we set endstop_poll_count = 2 or 3 should get rid of most of the issues - but this still leaves us with 0.1mm?

OR - perhaps - we slow down the speed of the steppers when homing? Longer to home but more accurate.

0.1mm on Z is still unacceptable for me. Reducing the speed is a good suggestion, but even decreasing the speed by tenfold (and it's pretty slow by default already!) would still result in 0.01mm inaccuracy which is still 25% of the distance I level my bed to.

Homing feedrate is an easily adjustable variable in Configuration.h, maybe even adjusting the max feedrate by GCode with M203 is enough - not sure though. Feel free to try that out,

After all, we can't blame Marlin though. Maybe their software filtering is not easily adjustable for our case, but adding a 100nF cap is not too much to ask from a printer manufacturer, even more so when it seems to be common practice for microswitch based endstops.

Makes me wonder why this doesn't seem to be a common issue, their default firmware is based on Marlin 1.1.1 which didn't even have an option for noise filtering. Maybe the way endstop states get polled got changed somehow within these versions? You mentioned a sensing change, mind showing me what you found?

[md66pt]

Seemingly having an issue where X axis home is not working. Steps to reproduce:

1. Move carriage to extreme right

2. Send home X axis request

3. Carriage moves about half way along the axis, before stopping and giving up. Does not make it to stop switch.

4. Prints are misaligned on the bed.

May be related to: MarlinFirmware/Marlin#11224
(although this turned into a Z axis issue).

Does not happen with original Anycubic FW.

Hi guys!

I have exactly the same issue!
Unfortunatly i have allready soldered a 100nF cap to every endstop but that didn't change anything!
I had the hint with the cap from a forum. Is this soldering correct? Cap between S and G?

I'm running on stock fw again, but sucks without thermal protection and PID for hotbed.

Thx.

[davidramiro]

Somebody got the noise filter to work only on X and Y over at MarlinFirmware/Marlin#11224, let's hope he can chime in on this.

[md66pt]

Thanks david!
I looked at your link and tried what Patrick said: enabling endstop noise filter and setting poll count to 1.
So far it seems to work and i can't see something weird with z accuracy!
By the way: Thank you so much for your effort on the whole firmware thing. I appreciate it much!

@notching Can you try too for proof?
Although still crazy why the 100nF cap is not doing the job! Bigger Cap? Smaller Cap? I'm not really in this deep enough to say.

[davidramiro]

Thanks david!
I looked at your link and tried what Patrick said: enabling endstop noise filter and setting poll count to 1.
So far it seems to work and i can't see something weird with z accuracy!
By the way: Thank you so much for your effort on the whole firmware thing. I appreciate it much!

Glad it works for you, though I am still concerned about Z accuracy - I don't want to sacrifice accuracy, even if only a slight chance. Disabling noise filtering on the Z endstops would be the best way to do it, so I am curious if @Patrick60 can show us his way of doing that.

For now, I will reopen this issue since we can be sure now this isn't an isolated issue even though the majority of users has probably not encountered it.

[mensikv]

Hi, I just want to chime in - I am running Marlin 1.1.9 on Anycubic i3 Mega with TMC2208 and my X homing is also broken - sometimes it works, but usually after a print it detects the X endspot incorrectly.
I do not have your version of Marlin, but altered version from derhopp.

[davidramiro]

For now, I have created another branch to troubleshoot this issue. Since my printer doesn't have these kind of issues, please feel free to try this out and report back on possible inaccuracy on the Z axis.

Thanks a lot so far for the constructive discussion!

[davidramiro]

I looked at your link and tried what Patrick said: enabling endstop noise filter and setting poll count to 1.

That's what I thought of doing as well (hence my now purged commit 98dc813), though a value of 1 might not be enough to ensure reliable filtering.

After doing some more digging, it seems to be obvious now that the noise filtering was always on at Marlin <=1.1.8, with a polling rate of 2. See MarlinFirmware/Marlin#11907 (comment) and MarlinFirmware/Marlin#11626. Since there were no drastic inaccuracies on the default manufacturer firmware, I think this is pretty much safe to push onto master branch if I'm not mistaken here - proper testing of course still required.

But since a single poll would result in even less delay, @md66pt, I am very curious if your settings really filter the noise reliably. Please do some testing and report back.

[notching]

Just a note that noise can still be induced if the 100nf cap is placed at the switch. Ideally, the cap should be as close to the pin of the microcontroller as possible. In practise, the endstop header on the Trigorialla PCA should be acceptable.
Setting the polling rate = 2 seems like a reasonable solution too :-).

[davidramiro]

Setting the polling rate = 2 seems like a reasonable solution too :-).

At least to get things back to the state of the default firmware, I guess it's the closest we can get. I suppose the +-0.2mm inaccuracy is quoted from the 7ms delay (1KHz polling and default 7 samples) and possible fast homing movements of X and Y. Considering how slow the Z axis moves, a 2ms delay would not induce any noticeable inaccuracy.

Anyways, if you have some time to spare, please feel free to get out your oscilloscope, I am extremely curious to have a look at the noisy signal. I suspect either the proximity of the endstop wires to the X axis stepper motor or the heatbed PWM with its substancial amount of current to be responsible for the noise.

[md66pt]

But since a single poll would result in even less delay, @md66pt, I am very curious if your settings really filter the noise reliably. Please do some testing and report back.

@davidramiro I tested a lot and did some prints too. So far i didn't have a single error and seems to be absolutely accurate. Homing works everytime, tried from different positions and stops allways at the exact same point as far as i am measuring.

Don't know if its only the poll count or the combination with the caps i soldered, but i will continue with value 1 for now.

I will report if troubles occur!

[davidramiro]

After some extensive testing, two polls don't seem to affect Z homing accuracy at all. I pushed it onto the master branch, though I am still leaving this issue open to encourage further examination.

[davidramiro]

After another ~40 hours of printing without any issue and the first layer looking perfect every time, I consider 2 endstop polls to be a good solution that doesn't interfere with homing accuracy.

I'll close this for now, thanks for the feedback everybody.