Commit Graph

23 Commits

Author SHA1 Message Date
Scott Lahteine
5cddfce0ee Endstops::report_state => event_handler 2018-07-11 19:47:25 -05:00
Scott Lahteine
defaa93121
Do a hard kill for failed homing moves (#11160) 2018-06-30 21:53:58 -05:00
Scott Lahteine
e352c1e52d Endstop patch followup 2018-06-27 00:12:42 -05:00
Scott Lahteine
52f5efb78d
Filter endstops state at all times (#11076) 2018-06-21 20:13:16 -05:00
Scott Lahteine
af1721b351 Extra insurance against endstop false positives 2018-06-13 00:36:47 -05:00
Scott Lahteine
3b06a8e917
[1.1.x] Assorted fixes and improvements (#10914)
Co-Authored-By: ejtagle
2018-06-01 19:00:59 -05:00
Scott Lahteine
b20d7129ab Fix reset of endstops and move state 2018-05-24 19:32:58 -05:00
Scott Lahteine
a971cacb06 Add Endstop Noise Filter
Co-Authored-By: ejtagle <ejtagle@hotmail.com>
2018-05-21 15:32:26 -05:00
Scott Lahteine
3a4a229721 Fix interrupt-based endstop detection 2018-05-20 21:24:57 -05:00
Scott Lahteine
38e1823375 Add HAL.h for AVR for easier 2.0.x parity 2018-05-20 21:24:57 -05:00
Scott Lahteine
e8fc0e9a57 Move [xyz]_endstop_adj to Endstops class 2018-03-10 06:54:18 -06:00
Scott Lahteine
47f6fc1e07 Set initial endstops state
Addressing #8662
2017-12-05 01:08:39 -06:00
Scott Lahteine
318c419f77 Implement support for Dual X and Y endstops 2017-10-29 03:49:45 -05:00
Bob-the-Kuhn
0369f97ec1 guaranteed BLTouch detection
To guarantee that the 5mS pulse from a BLTouch is recognized you need to
have the endstops.update() routine run twice in that 5mS period.

At 200 steps per mm, my system has problems  below a feedrate of 120 mm
per minute.

Two things were done to guarantee the two updates within 5mS:
1) In interrupt mode, a check was added to the temperature ISR.  If the
endstop interrupt flag/counter is active then it'll kick off the endstop
update routine every 1mS until the flag/counter is zero.  This
flag/counter is decremented by the temperature ISR AND by the stepper
ISR.

2) In poling mode, code was added to the stepper ISR that will make sure
the ISR runs about every 1.5mS.  The "extra" ISR runs only check the
endstops.  This was done by grabbing the intended ISR delay and, if it's
over 2.0mS, splitting the intended delay into multiple smaller delays.
The first delay can be up to 2.0mS, the next ones 1.5mS (as needed) and
the last no less than 0.5mS.

=========================================

BLTouch error state recovery

If BLTouch already active when deploying the probe then try to reset it
& clear the probe.

If that doesn't fix it then declare an error.

Also added BLTouch init routine to startup section
2017-02-11 12:01:34 -06:00
Scott Lahteine
f3720f4e81 const arguments to test_dual_z_endstops 2016-10-29 16:01:27 -05:00
João Brázio
3ebad4e020 Moves all global enums to a central file 2016-07-19 14:31:09 +01:00
Scott Lahteine
7242d44810 Endstops vars already initialized 2016-07-17 13:38:48 -07:00
Scott Lahteine
e60224a943 Drop FORCE_INLINE from endstops.h
`FORCE_INLINE` seems to have no effect with standard optimization.
2016-05-30 17:08:56 -07:00
Scott Lahteine
26f866b908 Apply static to Endstops class 2016-05-30 16:23:43 -07:00
Scott Lahteine
15fc93d742 Cleanup and consolidate probe conditionals for clarity 2016-05-08 12:59:43 -07:00
Scott Lahteine
24a15332b3 Encapsulate dual Z endstop handling 2016-04-30 17:26:50 -07:00
Scott Lahteine
5076d12344 Localize M119 in Endstops class 2016-04-30 17:26:50 -07:00
Scott Lahteine
5e4e535ce8 Stepper and Endstops as singleton objects 2016-04-30 17:26:50 -07:00