* repair reverse_pass()
And make it readeble.
This was broken a long time ago.
Not competely unfunctional but far from optimal.
* Minor speedup when calling calculate_trapezoid_for_block
2 float / to 1 foat / and 2 float *
* Various style changes
During long lasting moves of a delta machine neither the temperatures are maintained nor buttons checked nor ... .
The fix is to call 'manage_heater()' and 'idle()' every now and then in the loop where the move is segmented.
The code is abot the same as in G2_G3 wher we had the same problem with too large circles lasting too long.
Fixing #7510
Move 'lcd_bootscreen()' from `lcd_init()` to 'setup()' where it is cexecute exactly once. Saves 'bool show_bootscreen'.
Move the call of 'lcd_custom_bootscreen()' to the begin of 'lcd_bootscreen()'.
Move the delays into the related functions.
Move the picture loop around 'lcd_kill_screen()' into the function.
millis_t is long - divisions take for ever.
Return a kind of millisecond instead of microsecond -
divided by 1024 instead of 1000 for speed. (2.4% error)
That does not matter because block_buffer_runtime is
already a too short estimation.
Shrink the return-type.
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.
`ftostr62sign()` is used only when displaing/editing
Steps/mm. A sign is not needed - the value is always positive.
Because the number part is long there is no't much place for the values name.
With this PR the is one more char for the name possible.
The non utf8 version of turkish is a bit unhandy.
Delete `language_tr.h`
Rename `language_tr_utf.h` to `language_tr.h`
Provide a propper utf8-mapper for Turkish and use it.
Currently we draw and send the screens for a graphical LCD all at once.
We draw in two or four parts but draw them directly behind each other.
For the tested status screen this takes 59-62ms in a single block.
During this time nothing else (except the interrupts) can be done.
When printing a sequence of very short moves the buffer drains - sometimes until it's empty.
This PR splits the screen update into parts.
Currently we have 10 time slots. During the first one the complete screen is drawn. (60,0,0,0,0,0,0,0,0,0,0)
Here i introduce pauses for doing other things. (30,30,0,0,0,0,0,0) or (15,15,15,15,0,0,0,0,0,0)
Drawing in consecutive time slots prevents from lagging too much. Even with a 4 stripe display all the drawing is done after 400ms.
Previous experiments with a even better distribution of the time slots like
(30,0,0,0,0,30,0,0,0,0) and (15,0,15,0,15,0,15,0,0,0) did not feel good when using the menu, because of too much lag.
Because of the previous PRs to speed up the display updates and especially reducing the difference between drawing 2 or 4 stripes,
it now makes sense for the REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER to go from 2 to 4 stripes. This costs about 1-2ms per complete
screen update, but is payed back by having partial updates lasting only the half time and two additional brakes. Also ~256 byte of
framebuffer are saved in RAM.
13:45:59.213 : echo: #:17 >:13 s:30; #:16 >:13 s:29; S#:33 S>:26 S:59
13:46:00.213 : echo: #:16 >:14 s:30; #:17 >:13 s:30; S#:33 S>:27 S:60
13:46:01.215 : echo: #:17 >:13 s:30; #:16 >:13 s:29; S#:33 S>:26 S:59
13:46:02.215 : echo: #:16 >:13 s:29; #:16 >:14 s:30; S#:32 S>:27 S:59
13:46:03.214 : echo: #:17 >:13 s:30; #:17 >:13 s:30; S#:34 S>:26 S:60
13:46:04.214 : echo: #:16 >:13 s:29; #:16 >:14 s:30; S#:32 S>:27 S:59
13:46:05.212 : echo: #:16 >:14 s:30; #:17 >:13 s:30; S#:33 S>:27 S:60
13:46:06.212 : echo: #:17 >:13 s:30; #:16 >:13 s:29; S#:33 S>:26 S:59
03:30:36.779 : echo: #:8 >:7 s:15; #:10 >:7 s:17; #:8 >:6 s:14; #:8 >:7 s:15; S#:34 S>:27 S:61
03:30:37.778 : echo: #:8 >:6 s:14; #:10 >:7 s:17; #:9 >:7 s:16; #:8 >:6 s:14; S#:35 S>:26 S:61
03:30:38.778 : echo: #:8 >:6 s:14; #:11 >:7 s:18; #:8 >:6 s:14; #:8 >:7 s:15; S#:35 S>:26 S:61
03:30:39.777 : echo: #:8 >:6 s:14; #:10 >:7 s:17; #:8 >:8 s:16; #:8 >:6 s:14; S#:34 S>:27 S:61
03:30:40.780 : echo: #:8 >:6 s:14; #:11 >:7 s:18; #:8 >:6 s:14; #:8 >:6 s:14; S#:35 S>:25 S:60
03:30:41.780 : echo: #:9 >:6 s:15; #:10 >:7 s:17; #:8 >:6 s:14; #:9 >:6 s:15; S#:36 S>:25 S:61
03:30:42.779 : echo: #:8 >:6 s:14; #:10 >:8 s:18; #:8 >:6 s:14; #:8 >:6 s:14; S#:34 S>:26 S:60
03:30:43.778 : echo: #:9 >:6 s:15; #:10 >:7 s:17; #:8 >:7 s:15; #:9 >:6 s:15; S#:36 S>:26 S:62
#: draw a stripe
>: transfer a stripe
s: sum of of draw and transfer for one stripe
S#: sum of draws for a complete screen
S>: sum of transfers for a complete screen
S: time to draw and transfer a complete screen
For speeding up font drawing unify font decent.
Tr and Gr have ben the only fonts with a font decent of -2.
Sorry for some, a bit compressd, but hopefully still readeble symbols.
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.
These '{' are important to avoid the redefinition of `unsigned char _sreg = SREG;`
at the same level.
Used in
```
#define CRITICAL_SECTION_START unsigned char _sreg = SREG; cli();
```
Why double touch probing is not a good thing.
It's widely believed we can get better __probing__ results when using a double touch when probing.
Let's compare to double touch __homing__.
Or better let's begin with single touch __homing__.
We home to find out out position, so our position is unknown.
To find the endstop we have to move into the direction of the endstop.
The maximum way we have to move is a bit longer than the axis length.
When we arrive at the endstop - when it triggers, the stepper pulses are stopped immediately.
It's a sudden stop. No smooth deacceleration is possible.
Depending on the speed and the moving mass we lose steps here.
Only if we approached slow enough (below jerk speed?) we will not lose steps.
Moving a complete axis length, that slow, takes for ever.
To speed up homing, we now make the first approach faster, get a guess about our position,
back up a bit and make a second slower approach to get a exact result without losing steps.
What we do in double touch probing is the same. But the difference here is:
a. we already know where we are
b. if the first approach is to fast we will lose steps here to.
But this time there is no second approach to set the position to 0. We are measuring only.
The lost steps are permanent until we home the next time.
So if you experienced permanently rising values in M48 you now know why. (Too fast, suddenly stopped, first approach)
What can we do to improve probing?
We can use the information about our current position.
We can make a really fast, but deaccelerated, move to a place we know it is a bit before the trigger point.
And then move the rest of the way really slow.
Replace all fastDigitalRead/Write() with READ/WRITE()
Define SCK_PIN, MISO_PIN, MOSI_PIN in pins.h if not already defined in the pins_*.h files.
Remove these conditional pin definitions from the pin-files. They are now always defined.
Define separate sets of SPI-pins for AT90USB with and without Teensy support in fastio.h.
Likely this was the main reason for all that confusion about the AT90USB-SPI pins.
Unify run_z_probe
Add double touch for DELTAs.
Introduce Z_PROBE_SPEED_FAST and Z_PROBE_SPEED_SLOW
defaulting to homing_feedrate_mm_m[Z_AXIS] and homing_feedrate_mm_m[Z_AXIS]/2
and use it in `homeaxis()` instead of `do_blocking_move_to_axis_pos()`.
`do_blocking_move_to_axis_pos` was wrong because it performed subdivided, delta-corrected moves for x- and y-axis.
The first common move for delta homing is like quick_home but for 3 towers.
Fix two warnings.
Similar to the current Arduino HardwareSerial
but with max. 256 byte buffer-size.
Deactivated by default.
The boards with AT90USB processor (USBCON) already use a TX-buffer.
when no known axis needs to be homed.
Most changes are only caused from altering the indentation.
```
if (axis == X_AXIS ? HOMEAXIS_DO(X) : axis == Y_AXIS ? HOMEAXIS_DO(Y) : axis == Z_AXIS ? HOMEAXIS_DO(Z) : 0) {
...
}
to
if (!(axis == X_AXIS ? HOMEAXIS_DO(X) : axis == Y_AXIS ? HOMEAXIS_DO(Y) : axis == Z_AXIS ? HOMEAXIS_DO(Z) : 0)) return;
...
```
Use logic in Z_SAFE_HOMING
From
```
if (home_all_axis || homeZ) {
if (home_all_axis) {
...
home z
}
else if (homeZ) { // Don't need to Home Z twice
home z
}
}
```
to
```
if (home_all_axis || homeZ) {
if (home_all_axis) {
...
}
home z
}
```
Always define MIN_Z_HEIGHT_FOR_HOMING even if 0
Always make a potential rise to `home_offset[Z_AXIS]` possible in G28.
Get rid of some very ugly constructs in MBL (ultralcd.cpp).
Add an emergency-command parser to MarlinSerial's RX interrupt.
The parser tries to find and execute M108,M112,M410 before the commands disappear in the RX-buffer.
To avoid false positives for M117, comments and commands followed by filenames (M23, M28, M30, M32, M33) are filtered.
This enables Marlin to receive and react on the Emergency command at all times - regardless of whether the buffers are full or not. It remains to convince hosts to send the commands. To inform the hosts about the new feature a new entry in the M115-report was made. "`EMERGENCY_CODES:M112,M108,M410;`".
The parser is fast. It only ever needs two switch decisions and one assignment of the new state for every character.
One problem remains. If the host has sent an incomplete line before sending an emergency command the emergency command could be omitted when the parser is in `state_IGNORE`.
In that case the host should send "\ncommand\n"
Also introduces M108 to break the waiting for the heaters in M109, M190 and M303.
Rename `cancel_heatup` to `wait_for_heatup` to better see the purpose.
Move and extend axis_unhomed test to deploy/stow_z_probe().
Move and extend position store/restore to deploy/stow_z_probe().
Now all kinds of probes can use the 'E' parameter in G29/M48.
Allen key probes can be used now for grid and 3-point levelling.
Deploying the Allen Key probe uses big moves in z direction.
Too dangerous for an unhomed z-axis.
Throw a compile time error when we try to configure an
Allen Key probe homing to z-min and having no other z-min-endstop.
The `PROBE_IS_TRIGGERED_WHEN_STOWED_TEST` is able to detect if a probe is
successfully deployed/stowed.
It was part of the Allen Key probes code only.
Now the function is generally available.
Currently this test is compulsory for Allen Key probes to not alter the used behaviour
If you want to add the test for an other type of probe simply add
```
#define PROBE_IS_TRIGGERED_WHEN_STOWED_TEST
```
to your config.
If Z_RAISE_BETWEEN_PROBINGS is null or undefined the probe is currently not raised by home_offset[Z_AXIS] and zprobe_zoffset.
But when different from 0 is.
If an undefined Z_RAISE_BETWEEN_PROBINGS expands to 0 (and it does) this is the solution.
A similar asymmetry exists with the newly introduced 'short-cut' in G28 - but its the rise before anything is probed - so should not make a difference.
`dock_sled()` is never called with offset parameter - remove it.
We move x only - so only that needs to be homed. Consequence is - we can home to z-min now with a sled probe!
Feedrates are set and restored in `do_blocking_move()`.
We already checked if the probe is deployed/stowed in deploy/stow_probe.
```
if (z_loc < _Z_RAISE_PROBE_DEPLOY_STOW + 5) z_loc = _Z_RAISE_PROBE_DEPLOY_STOW;
```
makes no sense - remove.
Now the raise is the same for deploy/stow -> move before the if.
Replace the if with a ternary.
Instead writing LOW/HIGH use the boolean `stow` we already have.
There is no reason for not using the sled probe in G29/M48 with 'E'.
It takes a while but works. (tested!)
and saving ~1k memory
by limiting the `#pragma GCC optimize (3)` optimisation to `ultralcd_st7920_u8glib_rrd.h`. These optimisation was and is not done for all the other displays, is the reason for the big additionally use of memory, because the complete 'ultralcd.cpp' and 'dogm_lcd_implementation.h' was optimised (sadly i did not observe a change in speed).
Unrolling the loop in `ST7920_SWSPI_SND_8BIT()`, what i expected the optimiser to do, by hand, saved some speed by eliminating the loop variable (i) compares and increases. Every CPU cycle in this loop costs at least 0.5ms per display update because it's executed more than 1k times/s.
The delays are now pre-filled with the calculated values for 4.5V driven ST7920.
A way to simply add __your__ timing into the configuration was made.
At 4.5V
1.) The CLK signal needs to be at least 200ns high and 200ns low.
2.) The DAT pin needs to be set at least 40ns before CLK goes high and must stay at this value until 40ns after CLK went high.
A nop takes one processor cycle.
For 16MHz one nop lasts 62.5ns.
For 20MHz one not lasts 50ns.
To fulfill condition 1.) we need 200/62.5 = 3.2 => 4 cycles (200/50 = 4 => 4). For the low phase, setting the pin takes much longer. For the high phase we (theoretically) have to throw in 2 nops, because changing the CLK takes only 2 cycles.
Condition 2.) is always fulfilled because the processor needs two cycles (100 - 125ns) for switching the CLK pin.
Needs tests and feedback.
Especially i cant test 20MHz, 3DRAG and displays supplied wit less than 5V.
Are the delays right? Please experiment with longer or shorter delays. And give feedback.
Already tested are 5 displays with 4.9V - 5.1V at 16MHz where no delays are needed.
Introduce save_delay() for long delays what otherwise would cause
watchdog resets
Explizit lcd_set_custom_characters(false) at the end of bootscreen().
Else the charset is not proper set in case of LCD_PROGRESS_BAR.
Custom Splash Screen for full graphic displays.
Too complicated for the hitachis without knowing what exactly to display.
On top of #4032
Realisation of an idea from #3996
Init display and show bootscreen later, but init display in `kill()`
to init outputs before the bootscreen delays but being able to display
kill errors.
Remove SF_ARC_FIX from G5 (Cubic B-spline).
SF_ARC_FIX is a fix for G2/G3 (arcs) where Skeinforge always produced relative instead of absolute coordinates for the endpoint of an arc.
It's very unlikely this is also a problem with Cubic B-splines. More likely is copying from the G2/G3 code.
No compromises for the manage_heater(). manage_heater() will return immediately when there is nothing to do, but needs a constant detaT to work proper.
Calling idle() only every 200ms results in a display update every ~2 seconds - that should be enough.
For the other functionalities in idle() and manage_inactivity() 200ms is a lot but hopefully works.
Speedup sreen update delay
and correct a comment.
A module division by 10 is slooooow. (powers of 2 are fast - but then you can AND a bitmask with the same result)
AnHardtandScott Lahteine
