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.
In the endstop testing section, add the "reverse" logic in addition to "normal" core handling.
In CoreXY/YZ/XZ steppers rotating the same direction gives X movement. Opposing directions produces Y movement.
In CoreYX/ZY/ZX this is reversed. Same = Y, Opposite = X.
----
Fixes the issue where the Y endstop was being checked when moving in the X direction, etc.
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
added conditional compilation for PWMs 1C & 3C
add Teensyduino compatibility
==========================================
changes per review - minor formatting changes
1) remove non-printable character at the end of line 687
2) split a really long comment into two lines
3) got rid of some trailing spaces
============================================
Made pinsDebug_Teensyduino.h the same between this PR and PR 5668 which
is for a re-written pinsDebug.h file.
The changes were:
1) added copyright @ GNU license header
2) a blank line crept in.
1) modified 3 code files
Marlin.h
Marlin_main.cpp
endstops.cpp
2) modified config files so I could test on my machine
Testing was done on an AzteegX3pro based machine.
The probe was hooked to the Z_MIN endstop.
My controller doesn't have a dedicated Z_PROBE input so I couldn't test
that functionality.
Verified that a large file (without any G38 commands) executed the same
before and after the changes.
Verified that the head moves as expected when G38.2 and G38.3 commands
are issued. Single & multiple axis moves were tested along with + and -
directions.
Code was added to the main ISR. In normal operation only one extra IF
statement is evaluated. I didn't notice any performance degradation
because of the added code.
The G38 commands are expected to be issued manually by the operator
during machine setup. The G38 commands wait until the machine is idle
before proceeding. That way the other commands are minimally impacted
by the extra ISR overhead when a G38 command is in the queue.
The G38 commands are very similar to the G28 commands except 1) only the
Z_PROBE is used and movement can be in the + or - direction.
See issue 4677 for a discussion on adding G38 commands to Marlin.
Feature request: add ability to use G38.2 command (CNC)
MarlinFirmware/Marlin#4677
Supports both dual and single head printers (with the correct config).
Includes community sourced feed rate fix.
Rename / move files.
Remove redundant definitions.
Includes:
*firmware version / branch / date.
*extruder count
*board information (name, serial details, power supply type)
*thermistors (names, min/max temperatures)
*printer statistics (PRINTCOUNTER details)
Thanks to @thinkyhead for contributions.
Don't mangel 8.3-filenames with chars > 0x7f
Windows produces 8.3filenames wit chars > 0x7f. Those have been rejected
by Marlin until now.
With these 'malformed' filenames can now be worked with:
In the LCD menue
With RepetierHost (V1.6.1 tested) - full support. Characters are
displayed as '?'
With Octoprint (1.2.10 tested) the files do not appear in the files
area. At the console, listed with M20 they appear with a '�'.
With Pronterface the files appear in the sd-window but you can't start
them. They are mangled by pronterface. The names are altered and than
recected by Marlin. In the console they apper with differen but not the
correct characters.
All in all a little step forward.
Fix for #3593
Fix crashes when the Z axis is moved via LCD
by calling `plan_buffer_line` only when there is enough room in the
planner buffer, to avoid endless recursion.
A brief description about what went wrong is in #1166
@thinkyhead
Hi Scott,
your code from a0f362c@thinkyhead is great, but you forgot to skip the
command.
Symptom `M117 Test`shows `M117 Test` on LCD instead of `Test`.
see also
https://github.com/MarlinFirmware/Marlin/commit/a0f362c735401ebbcd95de3f
6f8e3c2f17ecc770 lines 941, 2851 and so on
Greetings and welcome back
Jochen
* Configuration.h:
* updated header comment
* new UUID feature used
* sync to default config
* typos fixed
* changes better documented
* reflect change in SDSUPPORT feature
* Configuration_adv.h
* updated header comment
* thermal protection tuned to work with K8200
* homing tuned
* sync to default config
* typos fixed
* changes better documented
* reflect change in LCD features
* use long filenames
* use Watchdog
* use Babystepping
* use Auto Filament Change
Currently if you clone Marlin to a directory with a space in the name, Arduino will generate an error.
Because when executed the path ends up split into two separate arguments.
My PID_INTEGRAL_DRIVE_MAX was at 96, which was insufficient for my bed
to reach its intended temperature. The head requires a low maximum power since
I run on 24 volts and it has a somewhat low thermal mass.
I've updated the minimum values from the LCD.
It has been a while that i want to at least fix this.
I have an inductive probe and often i need to set my zOffset to something lower than 0.5.
With the current implementation, the default LCD value is set to 0.5 for some reason.
On my case i need to be able to set it down to 0.0 as my inductive probe can be lower than 0.5.
Before with the LCD we couldn't change this value below 0.5. We had to flash the firmware every time which was painful.
Now we are able to change this value down to 0.0 if needed.
I've also changed the minimum value for Z min acceleration.
In the default configuration it's set to 25 but on the LCD the minimum was 100 which is not coherent.
I've changes the minimum to 10. On this axis, depending on the mechanics/motor drivers we might require very low acceleration, so i guess 10 is somehow realistic.
Bob-the-Kuhn
Roxy-3DandGitHub
dot-bobandScott Lahteine
CONSULitAS
Robert BartlandScott Lahteine
Anthony Birkett
Blue-Marlin
Roxy-3DPrintBoard
Torsten Kurbad
CONSULitAS
CONSULitAS
unknown
Naruto-kyun
Patrick BogenandRichard Wackerbarth
Daniel FriesenandRichard Wackerbarth
Jonathan Bastien-Filiatrault
elgambiteroandCONSULitAS
Chris Petersen
Richard Miles
chris-bo
nicolas-rambaud
chrono
C-o-r-E
OhmEye
Mark Hindess
Erik van der Zalm
Lukas Obermann
Charles Bell
Roxy-3DPrintBoard