With probes where the nozzle touches the bed
It is safer to retract after the last probe
as PROBE_ACCURACY does.
Signed-off-by: Timofey Titovets <nefelim4ag@gmail.com>
Deprecate the PROBE command's exported value
`{printer.probe.last_z_result}`. This value effectively returns the
toolhead Z position when the probe triggers and user's then need to
adjust the result using the probe's configured z_offset.
Introduce a new `{printer.probe.last_probe_position}` as a
replacement. This replacement has an easier to understand behavior -
it states that the probe hardware estimates that if the toolhead is
commanded to last_probe_position.x, last_probe_position.y and descends
then the tip of the toolhead should first make contact at a Z height
of last_probe_position.z . That is, the new exported value already
takes into account the probe's configured xyz offsets.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Change the low-level probe code to return ProbeResult tuples from
probe_session.pull_probed_results(). Also update callers to use the
calculated bed_xyz values found in the tuple instead of calculating
them from the probe's xyz offsets.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Change the ProbePointsHelper class to return ProbeResult tuples.
Callers of this class are also updated so that they use the tuple's
bed_xyz parameters instead of manually calculating these values from
the probe xyz offsets.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Return the manual probe results in a named tuple containing (bed_x,
bed_y, bed_z, test_x, test_y, and test_z) components. For a manual
probe the test_xyz will always be equal to bed_xyz, but these
components may differ when using automated z probes.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Most errors, aside from amplitude, should never happen.
Output them to the log to simplify later debugging.
Count them to aggregate error metrics.
Signed-off-by: Timofey Titovets <nefelim4ag@gmail.com>
If the sensor coil is disconnected, the frequency is equal to the reference.
If the sensor is misconfigured or damaged, the coil frequency is
greater than 1/4 of the reference frequency.
Signed-off-by: Timofey Titovets <nefelim4ag@gmail.com>
Amplitude errors are useful but often too aggressive.
On some sensors, it is not possible to avoid them completely.
Make them non-critical for homing.
Signed-off-by: Timofey Titovets <nefelim4ag@gmail.com>
I2C error means we don't know the sensor status.
Force data output to the host and cancel homing.
Signed-off-by: Timofey Titovets <nefelim4ag@gmail.com>
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Use a different method of setting the hardware pwm registers so that
the actual cycle_time is much closer to the requested cycle_time.
Also, remove the now unused stm32_timer_output command, as the main
hardware pwm interface provides the same accuracy.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
BTT Eddy uses 12MHz clock in frequency.
Coil is oscillating at 3+MHz.
Which is out of spec for LDC1612 sensors.
Division of coil frequency seems to reduce output noise.
Signed-off-by: Timofey Titovets <nefelim4ag@gmail.com>
The event handler is registered with an incorrect event name, causing the handler to never be called.
Signed-off-by: Maksim Bolgov maksim8024@gmail.com
Currently, there is no way to adjust the calibration curve.
The existing z_offset infrastructure is not applicable
or disabled here.
To make it possible to fine tune calibration curve.
Reload Z_OFFSET helper for probe_eddy_current.
Signed-off-by: Timofey Titovets <nefelim4ag@gmail.com>
It's possible for a motor disable request to occur while processing a
previous motor enable. Use a reactor mutex to ensure the two events
are processed serially.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
To support the cartographer, it is required to output 24 MHz.
With current defaults max output frequency is:
48 MHz/256 = 187.5 KHz
Adjusting the PWM scale allows for ramping up the frequency.
To not mess up with existing PWM users,
define the STM32-specific command.
Signed-off-by: Timofey Titovets <nefelim4ag@gmail.com>
A misplaced sensor or a misconfigured one
can return unreliable results.
Assist with this by refusing to use the too noisy points.
Filter noisy points by the frequency difference to noise ratio.
Signed-off-by: Timofey Titovets <nefelim4ag@gmail.com>
It is possible for USB host controllers to send back-to-back IN tokens
which only gives the MCU ~3us to queue the next USB packet in the
hardware. That can be difficult to do if the MCU has to wake up the
task code. The stm32 "usbotg" hardware does not support a builtin
generic double buffering transmit capability, but it is possible to
load the next packet directly from the irq handler code. This change
adds support for queuing the next packet destined for the host so that
the USB irq handler can directly load it into the hardware.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
The USB buffer size register PCKSIZE.SIZE was not being assigned
correctly. As a result, it was possible for an incoming USB
transmission to write past the allocated buffer space, which could
corrupt memory of other storage. In particular, in some cases gcc may
layout ram in such a way that the trailing bytes of an incoming
message might overlap the buffer for an outgoing message. This could
cause sporadic transmit errors and unstable connections.
Fix by correctly configuring the PCKSIZE.SIZE register.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Allow reqclock to be slightly less than the transmitted messages's
deadline. That is, delay messages with a reqclock far in the future
to slightly past (1<<31) ticks from its deadline. Use (3<<29)
instead, which gives an additional (1<<29) grace period to avoid clock
overflows.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
For correct operation the trsync system must be programmed prior to
the start of endstop checking. This means the desired "reqclock" for
the trsync configuration messages need to use the same "clock" that
the endstop start message uses - even though the actual deadline for
these messages is later.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>