Paciente8159 / uCNC

µCNC - Universal CNC firmware for microcontrollers
https://github.com/Paciente8159/uCNC/wiki
GNU General Public License v3.0
265 stars 60 forks source link

[BUG] zero after hmap results in non-zero work position #679

Closed tomjnixon closed 4 months ago

tomjnixon commented 4 months ago

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:

$H
G10 P0 L20 X0 Y0 Z0
[verbose] <Idle|MPos:0.000,104.000,45.000|FS:0.000,0>

go to start pos for hmap and reset zero again:

G0 X0 Y-41 Z-22.5
G10 P0 L20 X0 Y0 Z0

run hmap:

G39 X0.5 Y0.5 I41 J19 Z-2 R2.5 F50
[PRB:0.000,0.000,0.000:1]
...
[PRB:0.000,0.000,0.000:1]
[MSG:HMAP start corner;0.500;63.500]
[MSG:HMAP end corner;41.500;82.500]
[MSG:HMAP control points;16]
[MSG:HMAP;0;0;0.000]
...
[MSG:HMAP;3;3;-0.028]

zero again:

G10 P0 L20 X0 Y0 Z0
[verbose] <Idle|MPos:0.500,63.500,21.816|FS:0.000,0|Pn:P>
$10=0
[verbose] <Idle|WPos:-54.667,-25.333,1.316|FS:0.000,0|Pn:P>
$#
[G54:55.167,88.833,20.500]
[G55:0.000,0.000,0.000]
[G56:0.000,0.000,0.000]
[G57:0.000,0.000,0.000]
[G58:0.000,0.000,0.000]
[G59:0.000,0.000,0.000]
[G28:0.000,0.000,0.000]
[G30:0.000,0.000,0.000]
[G92:0.000,0.000,0.000]
[TLO:0.000]
[PRB:0.000,0.000,0.000:0]

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 of mc_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.

tomjnixon commented 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:

https://github.com/Paciente8159/uCNC/blob/857f96d47742e2b4a13ab5c4183eaf924576eb08/uCNC/src/core/parser.c#L1806

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.

Paciente8159 commented 4 months ago

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.