The Configuration.h file entries for BL-Touch have been updated to:
```cpp
//#define BLTOUCH
//#define BLTOUCH_DELAY 375 // (ms) Enable and increase if needed
//#define BLTOUCH_HEATERS_OFF // if defined the printer's heaters are
turned off during probe event
```
The electro-magnetic interference from the bed and nozzle are affecting
the BL-Touch repeatability for some users. This problem can be helped
by shutting down the heaters during the actual probe event and then
quickly turning them back on.
Because this code is messing with the heaters, it is written in a
paranoid manner. It only turns the heaters back on if everything is
EXACTLY as it expects things to be. The BL-Touch probe must have been
put into a deployed state less than 20 seconds prior, or the stow()
function will NOT turn the heaters on.
This code has been tested and works for both G28 and probing functions.
Giving a negative number of probe points disables the tower angle
correction calibration ('4point' instead of '7point' solution)
EEPROM version updated
* relocated ubl state to config. store:
* removed a number of ubl state variables and padding which were largely unused - saved 58 bytes of both SRAM and EEPROM;
* modified ubl sanity_check - no longer checks removed state variables that were otherwise unused, where checking didn't seem to accomplish anything, ultimately;
* removed pre_initialized state, saving 64 bytes of SRAM;
* removed automatic saving of UBL state after UBL activation/deactivation;
* consolidated multiple GRID_MAX_POINTS_X/Y to 'Global Leveling' section of EEPROM;
* minor update to G29 Sx notes/instructions;
* renamed mesh load and save parameter to 'slot' from 'm' for clarity;
- Making M665 compatible with repetier (see
http://reprap.org/wiki/G_code#M665:_Set_delta_configuration)
- M665 B also sets the radius for manual calibration menu
- Converting tower ajustment definitions to arrays - tower angle
corrections compatible with Esher 3D wizzard
- Only tower angles need to be adjustable with M665 and stored to EEPROM
- tower radius and diag rod can be adjusted in the FW only with #define
This data corruption problem is very difficult. Just changing the code
a little bit changes whether the problem even happens and what is
affected. I need these changes in the main branch so I can operate with
the extra debug code always available and turned on.
Everything is setup such that if M100 is turned off or DEBUG(ECHO) is
turned off, the code is not affected. M100 has been made a little bit
more inteligent so it can display the serial command buffers in a more
meaningful way (because the data corruption seems to often times end up
in that area).
- On `DELTA` the `M665 H` option supplants `M206`
- On `DELTA` `NO_WORKSPACE_OFFSETS` only reverts `G92` behavior
- Spawn 4 conditionals based on `NO_WORKSPACE_OFFSETS`
- Optimize coordinate space conversion for `DELTA` workspace
- To keep EEPROM version, retain `home_offset[XYZ]`, just ignore XY
===============================================
make changes requested by reviewers
===============================================
add M43 test to Travis, fix EOL, remove trailing spaces
Pretty much... The code is in place. Still more work to do. But it
has a lot of hooks and variables in other code, so commit and merge
before I pick up a million 'Conflicts'.
The fix in #6251 for bilinear Z offset was flawed and broke the Z parameter of G29 for bilinear levelling. This is reverted and a different fix is used for the double-addition of the Z-probe offset to the bilinear correction grid.
Since run_probe was altered to return the probe Z position rather than the nozzle Z position bilinear levelling has been broken because the Z-offset has been applied twice - once in the run_probe function, and then again in the G29 code for bilinear levelling.
- Make all `unified_bed_leveling` data/methods static
- Move some UBL-related variables into the class
- Replace `map_[xy]_index_to_bed_location` with `mesh_index_to_[xy]pos`
With the the current definition of echo_command I cannot compile RCBugFix (Arduino IDE 1.8.1) with the error "invalid conversion from 'const char*' to 'char*'". This change resolves that.
Made the double touch portion a conditional compile based on the
PROBE_DOUBLE_TOUCH flag.
==============================================
Bugfix
The current G38 only stopped a move if it involved the Z axis.
Moved all the G38 code to it's own section and put it where it would
always be executed no matter what axis was moving or if the endstop was
enabled.
Also added a comment to configuration_adv to alert the user the double
tap had to be turned on.
==============================================
Change G38 back to using Z_MIN_PROBE
There's no Z_MIN endstop if Z_DUAL_ENDSTOPS is enabled and you have them
set to the top of the gantry.
G38 started out as using the Z_MIN_PROBE pin. I don't remember why we
changed it to the Z_MIN endstop.
The tool_change function saves the current_position to the destination
array soon after starting. Later in the switching extruder section, the
destination array is modified when moving the Z axis up & down. A later
section of tool_change moves the head back to the “original location”
using the destination array. This later section assumes that the
destination array hasn’t been modified.
The fix is to save the destination Z position and then restore it after
the Z movements have completed.
Going back to using the current_position array for the switching
extruder Z axis moves (and leaving the destination array untouched)
doesn’t fix the problem.
This bug was introduced by the “Make tool_change kinematic compatible”
commit # 847429eff4 which was merged on 10
Oct 2016 as part of PR 4982.
This bug was discovered in Issue 5966.
- Add configuration support for zigzags in either the X or Y axis, for
wipe pads significantly longer in one dimension.
- Add configuration for default number of zig-zag triangles, vs. a
magic number in `Marlin_main.cpp`.
- Update description of auto nozzle wiping to match functionality
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
The target here is to update the screens of graphical and char base
displays as fast as possible, without draining the planner buffer too much.
For that measure the time it takes to draw and transfer one
(partial) screen to the display. Build a max. value from that.
Because ther can be large differences, depending on how much the display
updates are interrupted, the max value is decreased by one ms/s. This way
it can shrink again.
On the other side we keep track on how much time it takes to empty the
planner buffer.
Now we draw the next (partial) display update only then, when we do not
drain the planner buffer to much. We draw only when the time in the
buffer is two times larger than a update takes, or the buffer is empty anyway.
When we have begun to draw a screen we do not wait until the next 100ms
time slot comes. We draw the next partial screen as fast as possible, but
give the system a chance to refill the buffers a bit.
When we see, during drawing a screen, the screen contend has changed,
we stop the current draw and begin to draw the new content from the top.
If ENDSTOP_INTERRUPTS_FEATURE is enabled this tries to set up interrupt routines
for all used endstop pins. If this worked without errors, `endstops.update()` is called
only if one of the endstops changed its state.
The new interrupt routines do not really check the endstops and react upon them. All what they
do, is to set a flag if it makes sense to call the endstop test we are used to.
This can be used on:
* ARM (DUE) based boards - all pins can raise interrupts,
* RAMPS - all 6 endstop pins plus some other on EXT-2 can raise interrupts,
* RAMPS based boards - as long the designers did not change the pins for the endstops or at least left enough,
* all boards, if there are enough pins that can raise interrupts, and you are willing/able to swap with pins dedicated to other purpose.
The extrusion speed was wrong due to a not high enough precision of
esteps to XY steps, therefore now the target float values are used to
calculate the ratio between XY movement and extrusion speed.
The e_speed_multiplier8 was replaced by an absolute multiplier called
abs_adv_steps_multiplier8, therefore one multiplication and bitshift can
be saved inside the stepper ISR. Due to this, also extruder_advance_k is
better suited inside the planner and not the stepper files any more.
Roxy-3D