search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.34k stars 19.26k forks source link

Homing after initial auto home is not consistent since May 20/21 - Issue with ENDSTOP_NOISE_FILTER [BugFix-1.1.x] #10986

Closed autonumous closed 5 years ago

autonumous commented 6 years ago

Just noticed that i’m getting odd intermittent behaviours when homing (g28) after initial home.

Replicated with the following sequence:

Power on machine or following a reset
G28 
G27
G28

Result: head moves along Y towards Zero,/Endstop But stops at random point, i.e. Y axis doesn't hit the end stop. Then normal expected behaviour, i.e. X zeros, then it moves to the predefined XY offset, and then zeros Z. It should ultimately end at (55,30,5), and although it says that on the screen, Y can be way off!! Sometimes only a few mm from the Dock.

Expected result: Head move to Y=0, X=0, then move to defined position (55,30) then zero Z and ultimately stop at (55,30,5)

Sometimes it works, but if i repeat it will normally fail again. Other times I've had multiple G28’s fail in a row (3 or 4 in row).
The initial home/G28 following reset/power-on always works as expected.

I’ve also confirmed with the following precess, removing the nozzle parking (g27), and just moving to an arbitrary point, then homing again.

Reset
G28
g1 x200 y150
G28

i’ve tested my previous compiled firmwares and the last good firewall not exhibiting this issue was compiled May 20th 13:52 (UTC), the first one with the issue was 21st May 23:17 (UTC) These files were compiled against the available BugFix-1.1.x at the time.

I’m currently looking through the commits, but wondered if anybody else has experience similar issue?

GMagician commented 6 years ago

What kind of endstop are you using? just a switch?

Some enhancements has been done some time ago about a better/faster endstop handling. This end up to a system more prone to false detection if H/W is not well done

Try ENDSTOP_NOISE_FILTER

autonumous commented 6 years ago

on May 21st i see there were a number of commits related to endstops

Add Endstop Noise Filter a971cac Add ENDSTOP_NOISE_FILTER to example configs e63113e Fix interrupt-based endstop detection 3a4a229

I don’t have ENDSTOP_NOISE_FILTER enabled. never had any noise related issues. I use microswitch on X/Y, the Initial G28 always works.

Of course could be unrelated to the above, i’ll look through the code and will try testing.

GMagician commented 6 years ago

Just microswitch, if H/W is not as good as required (missing filter to inputs), may lead to false detection now. Give ENDSTOP_NOISE_FILTER a try. If it solve you may follow remarks indication to fix your hardware

GMagician commented 6 years ago

@autonumous the commits your are reporting are the ones I was talking about. Please try also latest bugfix. Endstop logic is under modification

autonumous commented 6 years ago

@GMagician, thanks, i’ll give it a try, but everything was fine before, so has something else been implemented and thus now requiring noise filtering (Interrupt based?) ? and why only on Y? I will check if my controller board contains any filtering capacitors.

I’m currently using the latest Bugfix.

autonumous commented 6 years ago

need to go out for a few hours, but will test that option later today

GMagician commented 6 years ago

@autonumous maybe your issue is due to something else, but before better to be sure. Before commits you reported homing was more immune to noise but was more slow to detect and less repetitive.

autonumous commented 6 years ago

@GMagician 👍 I tried enabling ENDSTOP_NOISE_FILTER, and it seems to have resolved the issue or at least during the 10+ or so tests I’ve performed.

Interesting that option fixed an issue that (for me) was only introduced in that change. :-) Also interesting that i’ve not seen the issue with the initial G28 following reset/power-on.

Anyway seems good now, and makes sense, I assume my end-stop wires are running parallel with some motor wires and that a small single is being induced, and thus triggering, will look at adding a capacitor.

GMagician commented 6 years ago

if you use NC micro and set NC to +5V and once pressed they connect to GND maybe you can solve with no ENDSTOP_NOISE_FILTER

EDIT: I have 2 Z home switches connected this way with ramps and I have no issues (my cables run with stepper as well)

autonumous commented 6 years ago

I thought the issue was resolved, anyway, went to print something today (first time since the weekend) and noticed when homing, the nozzle ends up 10.2 mm from the bed, should be 5mm. Everything is configured as it was before.

if i disable ENDSTOP_NOISE_FILTER, then it homes with nozzle 5 mm above the bed, as configured. (still have the issue with the Y end-stop triggering on subsequent homes)

This has been tested against the latest BugFix-1.1.x

as per #10866 , I’m going to test my End Stop cabling. I can open this as a new bug against ENDSTOP_NOISE_FILTER if required.

thinkyhead commented 6 years ago

Does it seem to be false-triggering on the re-bump of Z? What's your Z_HOME_BUMP_MM value?

autonumous commented 6 years ago

Z_HOME_BUMP_MM is 3.

It's not that it's false triggering, but once it's detected the bed, the final move seems to move the wrong direction.

thinkyhead commented 6 years ago

So it homes, hits the Z endstop, moves away to do the bump, then moves away again…?

Let's gather more information:

boubouexpress commented 6 years ago

I have the same problem alor I handed over my old version that works perfectly it is a modification that causes problem.

autonumous commented 6 years ago

@thinkyhead, thanks for suggestion, sorry for delay, seems enabling DEBUG_LEVELING_FEATURE pushed the firmware size over the max size, causing

avrdude: verification error, first mismatch at byte 0x3c000

Anyway, i’ve disabled various features, used the latest Bugfix1.1.x, enabled DEBUG_LEVELING_FEATURE, issued M111 S247, confirmed same issue persists, attached the requested output.

The observed behaviour is , homes, hits the z End Stop, moves away, pauses momentarily, then continues moving away (wrong direction) and then stops. The actual distance is 8.3 mm from the head to the bed.

Normally the process without ENDSTOP_NOISE_FILTER is: hits z, moves back, then moves in slowly, triggers and moves back to the final resting place 5mm above bed.

Marlin-20180616-DebugBed.txt Marlin-20180616-DebugBed-EndStopNoiseFilter.txt

Hope the above helps, anything else let me know. I’ll try to upload a video it that helps.

autonumous commented 6 years ago

So using the latest bugfix-1.1.x I either have the issue on the y axis when homing caused by noise and fixed with ENDSTOP_NOISE_FILTER, which consequently introduces another issue with the Z.

Therefore given the noise issue can also be fixed with hardware, I’ve added a 100nF capacitor to the connector, disabled the ENDSTOP_NOISE_FILTER option. Y homing now looks better (as it was previously before the endstop updates).

However I then noticed the Z was now exhibiting inconsistencies when homing. Not like the ones when using ENDSTOP_NOISE_FILTER (moving the wrong way), but a mm or so difference each time i homed. I use the following IR sensor , I figured it might be false-triggering, due to the same ‘Noise' issue, so i’ve again added a 100nF capacitor to the connector. So far seems good.

Just to be sure, I’ve then recompiled with ENDSTOP_NOISE_FILTER, same original issue with Z, homes, hits the z End Stop, moves away, pauses momentarily, then continues moving away (wrong direction) and then stops, so assuming the above capacitor fix continues to work, I won’t need to used this option, but i do think there is a bug within the code.

ManuelMcLure commented 6 years ago

What stepper drivers are you using? There's been reports of problems with a second G28 for people using TMC2130 drivers.

boubouexpress commented 6 years ago

The latest release (1.1.x.zip … 1.1.8)=no problem of homing

The daily bugfix build (bugfix-1.1.x.zip) = homing problem

autonumous commented 6 years ago

@ManuelMcLure, i’m using A4988 drivers.

thinkyhead commented 6 years ago

@boubouexpress — Please do the following:

csoh90 commented 6 years ago

(pardon me for bad english) bugfix-3axisnormal.txt bugfix-3axisbad.txt bugfix-xaxisgood.txt bugfix-xaxisbad.txt

Same problem here. A4988, ramps 1.4.

ENDSTOP_NOISE_FILTER not enabled. Enalbing ENDSTOP_NOISE_FILTER produces compile time error (as of commit 5374544, on arduino-1.8.1)

No homing problems on since 1.0.x ~ 1.1.8

Premature stopping on bugfix-1.1.x. Tried two bugfix revision(one around 2018.5.25, one 2018.6.22) ENDSTOP_NOISE_FILTER may have reduced premature stopping, but not to zero (tested on 2018.5. no log left) like previous versions.

Attached four logfiles, two full g28, two g28 x0 good and bad. No difference on debug log.

ejtagle commented 6 years ago

Can you try PR #11098 ? ... This PR is fixing endstops problems if using ENDSTOP_NOISE_FILTER enabled... Please, report if it solves anything for you

autonumous commented 6 years ago

@ejtagle Was that PR for bugfix-1.1.x or 2.0.x?

ejtagle commented 6 years ago

It is just for 2.0.x. If it works, we will port it to 1.1.x ...

csoh90 commented 6 years ago

Reporting status after patch b880028 (#11136) this patch apparantly eliminates premature stopping on homing if ENDSTOP_NOISE_FILTER is defined. It still wouldn't if ENDSTOP_NOISE_FILTER is undefined(I wonder the real culprit is caught or just bandaid is applied) But I have found yet another abnormal operation still existent after this patch and ENDSTOP_NOISE_FILTER defined.

bugfix-180629-g28-normal.txt bugfix-180629-g28-xrebumpskipped.txt bugfix-180629-g28-yrebumpskipped.txt

It skips some move Sometimes(very low probability, around 1 to 50 chance). For example, [normal G28] x moves to home -> x endstop hit -> small x rebump -> y moves to home -> y endstop hit -> small y rebump -> xy move to center(safe homing) -> z homing -> z endstop(sensor) hit -> ...

what I observed is like

x moves to home -> x endstop hit -> NO small x rebump(skipped) -> y moves to home -> y endstop hit -> small y rebump -> xy move to center(safe homing) -> z homing -> z endstop(sensor) hit -> ...

or

x moves to home -> x endstop hit -> small x rebump -> y moves to home -> y endstop hit -> NO small y rebump(skipped) -> xy move to center(safe homing) -> z homing -> z endstop(sensor) hit -> ...

or worse,

x moves to home -> x endstop hit -> small x rebump -> y moves to home -> y endstop hit -> small y rebump -> SKIPPED xy move to center(safe homing) -> z homing -> head crash

this problem exists for all three bugfix 1.1.x versions I tested(5.25, 6.22 - patch 5374544 , 6.29 - patch 485d50e) Attached file for normal g28, g28 x rebump skipped, g28 y rebump skipped log.

thinkyhead commented 6 years ago

I'm not sure why moves would be canceled when they're not moving towards an endstop. That would seem to indicate that:

We'll have to look closer at the endstops code as it currently exists to see how this is possible.

boelle commented 5 years ago

@autonumous is this still an issue with latest bugfix 2.0?

github-actions[bot] commented 4 years ago

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.