Some EEPROM allocations do not use the hole allocated space:
- EEPROM_FARM_NUMBER is only numeric 000-999 and only uses 2 bytes to store the Farm number BUT allocated 3 bytes. Added EEPROM_FREE_NR1 as free space that can be used
- EEPROM_CRASH_DET just changes 1 byte to save it status [on/off] but allocated 5 bytes. Added EEPROM_FREE_NR2 to EEPROM_FREE_NR5 as free space that can be used
Just after setting up the w2m matrix, call "clamp_to_software_endstops"
on the current_position (initially [0,0,0]) to move it to the effective
minimal position, which is usually [0,0,non-zero] due to MIN_Z and the
negative probe offset.
This is required to calculate correctly the first relative move:
planning X+10 would unexpectedly calculate a Z shift otherwise.
Tune the "soft" filament recheck to be more in-line with the latest
changes. Relax the thresholds so that a poorly tracking filament
that managed to trigger a recheck can still pass as long as /some/
motion is detected.
Hide the unused fsensor_oq_result() behind the FSENSOR_QUALITY define,
which is likely broken currently anyway.
Cleanup and simplify all the OQ defines.
When doing a PAT9125 "soft check", use two different speeds between
retraction and extrusion. This increases the chances that we can
track the surface.
Depending on the filament surface and moving speed, the PAT9125 sensor
can stop being able to track movement.
In such cases, instead of triggering false errors and/or relying on
previous states, read and use the exposure data off the sensor and
increase error counts only for poorly exposed images instead, which
is a good indicator of a far-away (or missing!) tracking surface.
Rewrite the logic behind the "chunking"/error count behind the PAT9125.
Basic idea: check the _direction_ of movement returned by the optical
sensor and compare it to the direction of the stepper. To avoid doing
this continuosly (and because the optical sensor doesn't necessarily
have the accuracy to track small distances), do so in chunks.
Each time a chunk doesn't match the expected direction, increase the
error count.
Several improvements were done to the previous code:
- Increase the chunk window: this ensures that a filament with
poor response returns an usable direction, while also moving the
average return values from the sensor in the middle of the 12 bits
available for maximum effectiveness.
- Since the returned values are more reliable, reduce the error count
(1.25mm*4 = ~5mm before runout detection)
- Track _both_ positive and negative movement, although only trigger
errors during extrusion (necessary due to several assumptions made
in the mmu/unloading code)
- Do not reset the counters for each block: accumulate distances
correctly, allowing detection of any block lenght.
When the error count is cleared, the cumulative deltas as well as the
segment lenght which is kept inside the stepper isr need to be reset.
Introduce a helper function fsensor_reset_err_cnt to clear all the
required variables in one place which can be used in most cases
(the only exceptions being quality measument).
Introduce a new function st_reset_fsensor to also clear the segment
lenght within the isr.
- Hide all prototypes related to PAT9125 to force all callers
to check for the proper sensor, since the handling differences
are substantial
- Remove unneeded lenght accounting from the stepper isr as as
consequence.
- Keep detailed soft failure counts for the MK3 on the "last print
failures" status screen, but fix build on variants without a PAT9125
by fixing the lcd stats function.
The filament sensor "chunk lenght" needs to be updated every time the
E axis resolution is changed in order to trigger at the same distance.
Introduce a new function fsensor_set_axis_steps_per_unit() and use
it consistent during init, in M92 and M350.
When upgrading K values of a LA1.0 print, also adjust E-jerk settings
(<2) if permissible according to current accell limits. The same is also
true when jerk is set mid-print via 'M205 E'.
Existing values are always restored when switching to another
compatibility mode.
TODO: Since this is stateful, we will need to save the current print
mode / acceleration and jerk in the eeprom for this to survive a power
panic (see prusa3d#2456).
When calculating the advance tick interval, be sure to check for integer
overflow. Very low step rates can result in values exceeding uint16_t
causing premature LA tick delivery.
An overflow resulting in zero would also block in an infinite loop
within advance_spread().
Even though such rates are worthless in terms of compensation and often
result in 0 extra ticks as well, do not disable LA for the block (as
doing so would reset the count for short segments) and do not check for
zero in multiple paces either.
Saturate the interval instead, delaying any further tick to the next
block.
Alex Voinea
3d-gussner
DRracer
D.R.racer
MRprusa3d
vintagepc
Yuri D'Elia