Closed tomjnixon closed 4 months ago
found it!
The problem is that mc_build_hmap
does not set target
to the final position (it uses it as a temporary instead), and this is expected by the parser:
It's not exactly clear to me why this doesn't happen for linear probes.
There's a fix in the branch i linked above, but it's probably not the best way.
Thanks for the pointer.
A better approach is to call mc_sync_position()
to sync all subsystems (interpolator, motion control and parser).
I also noticed the retraction is not working quite as expected. It should retract at least to a height of the (initial position + R) between points and is not.
Check the #680 for a fix. Let me know if it fixed the issue.
Hi,
I'm using uCNC on a custom machine, with a new board, with the code/configuration as in this branch https://github.com/tomjnixon/uCNC/tree/my_config (based on the current master version, nothing exciting.
The runtime configuration is:
runtime configuration
``` $0 = 33.333 (Step pulse time, microseconds) $1 = 0 (Step idle delay, milliseconds) $2 = 0 (Step pulse invert, mask) $3 = 10 (Step direction invert, mask) $4 = 0 (Invert step enable pin, boolean) $5 = 7 (Invert limit pins, boolean) $6 = 1 (Invert probe pin, boolean) $7 = 0 $10 = 0 (Status report options, mask) $11 = 0.200 (Junction deviation, millimeters) $12 = 0.002 (Arc tolerance, millimeters) $13 = 0 (Report in inches, boolean) $20 = 1 (Soft limits enable, boolean) $21 = 1 (Hard limits enable, boolean) $22 = 1 (Homing cycle enable, boolean) $23 = 6 (Homing direction invert, mask) $24 = 50.000 (Homing locate feed rate, mm/min) $25 = 50.000 (Homing search seek rate, mm/min) $26 = 250 (Homing switch debounce delay, milliseconds) $27 = 0.500 (Homing switch pull-off distance, millimeters) $30 = 1000 (Maximum spindle speed, RPM) $31 = 0 (Minimum spindle speed, RPM) $32 = 0 (Laser-mode enable, boolean) $81 = 0.000 $100 = 200.000 (X-axis travel resolution, step/mm) $101 = 200.000 (Y-axis travel resolution, step/mm) $102 = 3200.000 (Z-axis travel resolution, step/mm) $110 = 500.000 (X-axis maximum rate, mm/min) $111 = 500.000 (Y-axis maximum rate, mm/min) $112 = 200.000 (Z-axis maximum rate, mm/min) $120 = 10.000 (X-axis acceleration, mm/sec^2) $121 = 10.000 (Y-axis acceleration, mm/sec^2) $122 = 10.000 (Z-axis acceleration, mm/sec^2) $130 = 106.000 (X-axis maximum travel, millimeters) $131 = 104.000 (Y-axis maximum travel, millimeters) $132 = 45.000 (Z-axis maximum travel, millimeters) ```Everything expected seems to work OK, but i'm having some trouble with G39 h-mapping. It seems to probe fine and produces reasonable results, but after it's complete, if I zero the work position with
G10 P0 L20 X0 Y0 Z0
, the work position is not actually zeroed -- it ends up with a non-obvious offset.Here's the process that shows the issue, with some collected verbose output:
home and reset zero:
go to start pos for hmap and reset zero again:
run hmap:
zero again:
I'd expect Wpos to be 0; this matches the position shown in UGS, and G0/G1 commands certainly don't move relative to the current position (
G0 Z2
) causes a large movement in X/Y and rapid mashing of the e-stop switch :)I suspected that it might be a missing
mc_sync_position
at the end ofmc_build_hmap
, but adding that doesn't seem to change the behaviour.Thanks, let me know if there's any other information i can provide or tests to perform.