Auto bed leveling manages coordinates in strange way, leaving final position incorrect #3311

ozligia · 2016-04-02T03:04:10Z

Hello, everybody. I have an issue with auto bed level configuration for my CoreXY 3D printer.
(RCBugFix branch)
My brief settings are (full config attached):

#define X_HOME_DIR -1
#define Y_HOME_DIR -1
#define Z_HOME_DIR -1

#define X_MIN_POS 0
#define Y_MIN_POS 0
#define Z_MIN_POS 0
#define X_MAX_POS 225
#define Y_MAX_POS 190
#define Z_MAX_POS 100

#define AUTO_BED_LEVELING_FEATURE

#define LEFT_PROBE_BED_POSITION 8
#define RIGHT_PROBE_BED_POSITION 200
#define FRONT_PROBE_BED_POSITION 38
#define BACK_PROBE_BED_POSITION 190

#define AUTO_BED_LEVELING_GRID_POINTS 2

#define X_PROBE_OFFSET_FROM_EXTRUDER 8
#define Y_PROBE_OFFSET_FROM_EXTRUDER 38
#define Z_PROBE_OFFSET_FROM_EXTRUDER -0.99

#define FIX_MOUNTED_PROBE

 #define Z_SAFE_HOMING 

#define Z_SAFE_HOMING_X_POINT ((X_MIN_POS + X_MAX_POS) / 2)
#define Z_SAFE_HOMING_Y_POINT ((Y_MIN_POS + Y_MAX_POS) / 2)

I do G28, nozzle goes to X:104, Y:57, Z:0.99 (We have set, probe in the center of table, Ok)
I do G29.
Carriage goes to front right X:192, Y:0 (That is what LCD tells). However in reality nozzle(!) goes somewhere to: X: 215, Y:33 (this values are not precise)
Carriage goes to front left X:0, Y:0 (That is what LCD tells).Nozzle is about: X:22, Y33
Carriage goes to back left X:0, Y:152 (That is what LCD tells) Nozzle is about X:24, Y:186
Carriage goes to back right X:192, Y:152 (That is what LCD tells) Nozzle is about X:214, Y:185
The most strange thing: as bed level routine ends, coordinates are set: X: 171.9, Y:19.9. All next moves are made accordingly to last coordinate set

Is it a bug or configuration issue?

PS. Failovered to 1.0.2 and configured auto bed leveling at once without any issue.
And it seems that coordinate system for auto bed leveling is rotated by 90 degrees CCW origin in latest builds

Configuration.zip

The text was updated successfully, but these errors were encountered:

g2david · 2016-04-02T08:59:03Z

SENDING:G29
gcode_G29 >>>
G29 Auto Bed Leveling
setup_for_endstop_move > enable_endstops(true)
z_before = (before) 40.00
probe_pt >>>
> ProbeAction:1
> current_position: (132.50, -42.50, 23.45)
Z Raise to z_before 40.00
> do_blocking_move_to_z 40.00
do_blocking_move_to: (132.50, -42.50, 40.00)
> do_blocking_move_to_xy 158.00, 65.00
do_blocking_move_to: (158.00, 65.00, 40.00)
> ProbeDeploy
deploy_z_probe > current_position: (158.00, 65.00, 40.00)
echo:busy: processing
run_z_probe > current_position: (158.00, 65.00, 8.67)
<<< probe_pt
z_before = (between) 13.67
probe_pt >>>
> ProbeAction:0
> current_position: (158.00, 65.00, 8.67)
Z Raise to z_before 13.67
> do_blocking_move_to_z 13.67
do_blocking_move_to: (158.00, 65.00, 13.67)
> do_blocking_move_to_xy 107.00, 65.00
do_blocking_move_to: (107.00, 65.00, 13.67)
echo:busy: processing
run_z_probe > current_position: (107.00, 65.00, 8.75)
<<< probe_pt
z_before = (between) 13.75
probe_pt >>>
> ProbeAction:0
> current_position: (107.00, 65.00, 8.75)
Z Raise to z_before 13.75
> do_blocking_move_to_z 13.75
do_blocking_move_to: (107.00, 65.00, 13.75)
> do_blocking_move_to_xy 56.00, 65.00
do_blocking_move_to: (56.00, 65.00, 13.75)
run_z_probe > current_position: (56.00, 65.00, 8.83)
<<< probe_pt
z_before = (between) 13.83
probe_pt >>>
> ProbeAction:0
> current_position: (56.00, 65.00, 8.83)
Z Raise to z_before 13.83
> do_blocking_move_to_z 13.83
do_blocking_move_to: (56.00, 65.00, 13.83)
> do_blocking_move_to_xy 5.00, 65.00
do_blocking_move_to: (5.00, 65.00, 13.83)
Disconnected.

paulusjacobus · 2016-04-02T11:41:05Z

You have to disable the software end stops then it does a proper g29.

Sent from my iPad

On 2 Apr 2016, at 2:04 PM, ozligia notifications@github.com wrote:

Hello, everybody. I have an issue with auto bed level configuration for my CoreXY 3D printer.
My brief settings are (full config attached):

#define X_HOME_DIR -1
#define Y_HOME_DIR -1
#define Z_HOME_DIR -1

#define X_MIN_POS 0
#define Y_MIN_POS 0
#define Z_MIN_POS 0
#define X_MAX_POS 225
#define Y_MAX_POS 190
#define Z_MAX_POS 100

#define AUTO_BED_LEVELING_FEATURE

#define LEFT_PROBE_BED_POSITION 8
#define RIGHT_PROBE_BED_POSITION 200
#define FRONT_PROBE_BED_POSITION 38
#define BACK_PROBE_BED_POSITION 190

#define AUTO_BED_LEVELING_GRID_POINTS 2

#define X_PROBE_OFFSET_FROM_EXTRUDER 8
#define Y_PROBE_OFFSET_FROM_EXTRUDER 38
#define Z_PROBE_OFFSET_FROM_EXTRUDER -0.99

#define FIX_MOUNTED_PROBE

#define Z_SAFE_HOMING

#define Z_SAFE_HOMING_X_POINT ((X_MIN_POS + X_MAX_POS) / 2)
#define Z_SAFE_HOMING_Y_POINT ((Y_MIN_POS + Y_MAX_POS) / 2)
I do G28, nozzle goes to X:104, Y:57, Z:099 (We have set, probe in the center of table, Ok)
I do G29.
Carriage goes to front right X:192, Y:0 (That is what LCD tells). However in reality nozzle(!) goes somewhere to: X: 215, Y:33 (this values are not precise)
Carriage goes to front left X:0, Y:0 (That is what LCD tells).Nozzle is about: X:22, Y33
Carriage goes to back left X:0, Y:152 (That is what LCD tells) Nozzle is about X:24, Y:186
Carriage goes to back right X:192, Y:152 (That is what LCD tells) Nozzle is about X:214, Y:185
The most strange thing: as bed level routine ends, coordinates are set: X: 171.9, Y:19.9. All next moves are made accordingly to last coordinate set
Is it a bug or configuration issue?

Configuration.zip

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

ozligia · 2016-04-02T13:17:26Z

I have the following in my config:

#define min_software_endstops false // If true, axis won't move to coordinates less than HOME_POS.
#define max_software_endstops true  // If true, axis won't move to coordinates greater than the defined lengths below

Software max endstops enabled, because i have hardware endstops only for minimal values.
Should i really disable max_software_endstops too? I have the same config for software endstops in marlin 1.0.2 and auto bed level does work correctly.

ozligia · 2016-04-02T18:01:39Z

Is there a way to run G29 in verbose mode, to clarify its behavior?

jbrazio · 2016-04-02T18:26:22Z

No it seems that will be as verbose as it will get.

Roxy-3D · 2016-04-03T03:25:09Z

Is there a way to run G29 in verbose mode, to clarify its behavior?

I don't have a CoreXY machine and have never seen one in real life. I might get accused of trying to turn this into a Valentine's thread... Or worse yet, a Black Friday thread...

But the G29 stuff is not conditional upon being Core-XY. If you turn on the debug flags ....

#define DEBUG_LEVELING_FEATURE

and use M111 to set a verbose mode for Auto Bed Leveling and the probe stuff.... I think we will get a lot more information. Maybe something like M111 S32767 ?????

And ThinkyHead isn't going to be difficult to convince we need lots more M111 stuff aimed at Core-?? machines!

jhnphm · 2016-04-03T15:49:27Z

Possibly related to #2845 ?

ozligia · 2016-04-03T17:12:30Z

Hm. Executed with high debug level.
And there is what it says. Probe offset from extruder was set to X:0, Y:0, EEPROM reloaded and saved to defaults
Here is the output:

20:01:35.795 : N604 M503*39
20:01:35.798 : echo:N604 M503*39
20:01:35.798 : echo:Steps per unit:
20:01:35.801 : echo:  M92 X100.00 Y100.00 Z400.00 E100.00
20:01:35.801 : echo:Maximum feedrates (mm/s):
20:01:35.806 : echo:  M203 X200.00 Y200.00 Z8.00 E60.00
20:01:35.806 : echo:Maximum Acceleration (mm/s2):
20:01:35.811 : echo:  M201 X3000 Y3000 Z100 E10000
20:01:35.811 : echo:Accelerations: P=printing, R=retract and T=travel
20:01:35.815 : echo:  M204 P3000.00 R3000.00 T3000.00
20:01:35.819 : echo:Advanced variables: S=Min feedrate (mm/s), T=Min travel feedrate (mm/s), B=minimum segment time (ms), X=maximum XY jerk (mm/s),  Z=maximum Z jerk (mm/s),  E=maximum E jerk (mm/s)
20:01:35.823 : echo:  M205 S0.00 T0.00 B20000 X20.00 Z0.40 E5.00
20:01:35.823 : echo:Home offset (mm):
20:01:35.827 : echo:  M206 X0.00 Y0.00 Z0.00
20:01:35.827 : echo:Material heatup parameters:
20:01:35.827 : echo:  M145 S0 H180 B70 F0
20:01:35.827 : echo:  M145 S1 H240 B110 F0
20:01:35.827 : echo:PID settings:
20:01:35.831 : echo:  M301 P21.92 I1.20 D100.20 C100.00 L20
20:01:35.835 : echo:Filament settings: Disabled
20:01:35.835 : echo:  M200 D3.00
20:01:35.835 : echo:  M200 D0
20:01:35.835 : echo:Z-Probe Offset (mm):
20:01:35.835 : echo:  M851 Z-0.45
20:01:49.089 : N617 G28*19
20:01:49.094 : echo:N617 G28*19
20:01:49.094 : gcode_G28 >>>
20:01:49.094 : setup_for_endstop_move > enable_endstops(true)
20:01:49.097 : >>> homeaxis(0)
20:01:53.767 : > enable_endstops(false)
20:01:53.881 : > enable_endstops(true)
20:01:54.087 : > TRIGGER ENDSTOP > current_position: (0.00, 17.50, 15.45)
20:01:54.091 : set_axis_is_at_home 0 > (home_offset[axis]==0.00) > current_position: (0.00, 17.50, 15.45)
20:01:54.095 : > AFTER set_axis_is_at_home > current_position: (0.00, 17.50, 15.45)
20:01:54.095 : <<< homeaxis(0)
20:01:54.095 : > homeX: (0.00, 17.50, 15.45)
20:01:54.095 : >>> homeaxis(1)
20:01:57.842 : > enable_endstops(false)
20:01:57.961 : > enable_endstops(true)
20:01:58.171 : > TRIGGER ENDSTOP > current_position: (0.00, 0.00, 15.45)
20:01:58.175 : set_axis_is_at_home 1 > (home_offset[axis]==0.00) > current_position: (0.00, 0.00, 15.45)
20:01:58.179 : > AFTER set_axis_is_at_home > current_position: (0.00, 0.00, 15.45)
20:01:58.179 : <<< homeaxis(1)
20:01:58.179 : > homeY: (0.00, 0.00, 15.45)
20:01:58.179 : > Z_SAFE_HOMING >>>
20:01:58.183 : > Z_SAFE_HOMING > home_all_axis > current_position: (0.00, 0.00, 15.45)
20:01:58.186 : > Z_SAFE_HOMING > home_all_axis > destination: (112.00, 95.00, 15.45)
20:01:59.223 : echo:busy: processing
20:01:59.333 : >>> homeaxis(2)
20:01:59.334 : deploy_z_probe > current_position: (112.00, 95.00, 0.00)
20:02:03.098 : > enable_endstops(false)
20:02:03.654 : > enable_endstops(true)
20:02:05.637 : > TRIGGER ENDSTOP > current_position: (112.00, 95.00, 0.00)
20:02:05.642 : set_axis_is_at_home 2 > (home_offset[axis]==0.00) > current_position: (112.00, 95.00, 0.45)
20:02:05.646 : > AFTER set_axis_is_at_home > current_position: (112.00, 95.00, 0.45)
20:02:05.650 : > SERVO_LEVELING > (stow_z_probe())
20:02:05.650 : stow_z_probe > current_position: (112.00, 95.00, 0.45)
20:02:05.650 : <<< homeaxis(2)
20:02:05.650 : <<< Z_SAFE_HOMING
20:02:05.654 : > (home_all_axis || homeZ) > final: (112.00, 95.00, 0.45)
20:02:05.658 : ENDSTOPS_ONLY_FOR_HOMING enable_endstops(false)
20:02:05.658 : <<< gcode_G28
20:02:09.272 : N630 G29*23
20:02:09.274 : echo:N630 G29*23
20:02:09.279 : gcode_G29 >>>
20:02:09.279 : G29 Auto Bed Leveling
20:02:09.279 : setup_for_endstop_move > enable_endstops(true)
20:02:09.283 : z_before = (before) 15.00
20:02:09.283 : probe_pt >>>
20:02:09.283 : > ProbeAction:1
20:02:09.283 : > current_position: (103.50, 8.50, 0.45)
20:02:09.287 : Z Raise to z_before 15.00
20:02:09.287 : > do_blocking_move_to_z 15.00
20:02:09.287 : do_blocking_move_to: (103.50, 8.50, 15.00)
20:02:12.953 : > do_blocking_move_to_xy 225.00, 38.00
20:02:12.957 : do_blocking_move_to: (225.00, 38.00, 15.00)
20:02:13.940 : > ProbeDeploy
20:02:13.944 : deploy_z_probe > current_position: (225.00, 38.00, 15.00)
20:02:19.322 : echo:busy: processing
20:02:20.203 : run_z_probe > current_position: (225.00, 38.00, 0.37)
20:02:20.203 : <<< probe_pt
20:02:20.203 : z_before = (between) 5.38
20:02:20.203 : probe_pt >>>
20:02:20.207 : > ProbeAction:0
20:02:20.207 : > current_position: (225.00, 38.00, 0.37)
20:02:20.207 : Z Raise to z_before 5.38
20:02:20.211 : > do_blocking_move_to_z 5.38
20:02:20.211 : do_blocking_move_to: (225.00, 38.00, 5.38)
20:02:21.546 : > do_blocking_move_to_xy 8.00, 38.00
20:02:21.550 : do_blocking_move_to: (8.00, 38.00, 5.38)
20:02:26.998 : run_z_probe > current_position: (8.00, 38.00, 0.36)
20:02:26.998 : <<< probe_pt
20:02:26.999 : z_before = (between) 5.36
20:02:26.999 : probe_pt >>>
20:02:27.002 : > ProbeAction:0
20:02:27.002 : > current_position: (8.00, 38.00, 0.36)
20:02:27.003 : Z Raise to z_before 5.36
20:02:27.006 : > do_blocking_move_to_z 5.36
20:02:27.006 : do_blocking_move_to: (8.00, 38.00, 5.36)
20:02:28.288 : > do_blocking_move_to_xy 8.00, 190.00
20:02:28.288 : do_blocking_move_to: (8.00, 190.00, 5.36)
20:02:29.472 : echo:busy: processing
20:02:33.216 : run_z_probe > current_position: (8.00, 190.00, 0.47)
20:02:33.220 : <<< probe_pt
20:02:33.220 : z_before = (between) 5.48
20:02:33.220 : probe_pt >>>
20:02:33.220 : > ProbeAction:2
20:02:33.224 : > current_position: (8.00, 190.00, 0.47)
20:02:33.224 : Z Raise to z_before 5.48
20:02:33.224 : > do_blocking_move_to_z 5.48
20:02:33.228 : do_blocking_move_to: (8.00, 190.00, 5.48)
20:02:34.502 : > do_blocking_move_to_xy 225.00, 190.00
20:02:34.505 : do_blocking_move_to: (225.00, 190.00, 5.48)
20:02:39.535 : echo:busy: processing
20:02:40.064 : run_z_probe > current_position: (225.00, 190.00, 0.20)
20:02:40.065 : > ProbeStow (stow_z_probe will do Z Raise)
20:02:40.069 : stow_z_probe > current_position: (225.00, 190.00, 0.20)
20:02:40.069 : <<< probe_pt
20:02:40.072 : > probing complete > current_position: (225.00, 190.00, 0.20)
20:02:40.073 : clean_up_after_endstop_move > ENDSTOPS_ONLY_FOR_HOMING > endstops_not_homing()
20:02:40.085 : Eqn coefficients: a: -0.00058180 b: -0.00017270 d: 0.44059185
20:02:40.085 : planeNormal x: 0.000582 y: 0.000173 z: 1.000000
20:02:40.089 : set_bed_level_equation_lsq > current_position: (207.50, 17.50, 0.33)
20:02:40.089 : 
20:02:40.089 : Bed Level Correction Matrix:
20:02:40.093 : +1.000000 +0.000000 -0.000582
20:02:40.093 : -0.000000 +1.000000 -0.000173
20:02:40.097 : +0.000582 +0.000173 +1.000000
20:02:40.097 : > BEFORE apply_rotation_xyz > z_tmp  = 0.33
20:02:40.101 : > BEFORE apply_rotation_xyz > real_z = 0.20
20:02:40.101 : > AFTER apply_rotation_xyz > z_tmp  = 0.21

Configuration.zip

20:02:40.105 : > corrected Z in G29: (207.50, 17.50, 0.45)
20:02:40.105 : do_blocking_move_to: (207.50, 17.50, 15.45)
20:02:43.881 : <<< gcode_G29

The most strange thing for me:
After G28 we left nozzle at X:112.00, Y:95.00, Z:0.45. All is Ok.
Then G29 starts, and at the very begining it returns:

20:02:09.283 : probe_pt >>>
20:02:09.283 : > ProbeAction:1
20:02:09.283 : > current_position: (103.50, 8.50, 0.45)

And that's all. Head bumps going to Back. Why this coordinate transition occurred i can't imagine.

PS. Latest RCBugFix pulled out today and full configuration attached. Configuration_adv.h was left intact.

Configuration.zip

ozligia · 2016-04-05T15:24:58Z

Any suggestions?
PS. Tried disabling max endstops, leaving only hardware_min endstops. No result

paulusjacobus · 2016-04-05T22:07:59Z

@ozligia the only way I can reproduce your error is when I turn one of my
stepper's connector around or swap endstops Xmin with Ymin on the X axis.
Not sure if that helps. I'm on RCBugFix

On 6 April 2016 at 01:25, ozligia notifications@github.com wrote:

Any suggestions?
PS. Tried disabling max endstops, leaving only hardware_min endstops. No
result

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#3311 (comment)

ozligia · 2016-04-06T20:18:51Z

@paulusjacobus wat type of printer kinematics do you use? I made a guess, that coordinate system is swept around in my first message. But i definitely have x endstop on x, and y endstop on y, as when i home carriage by x and y axis in separate result is correct. X+ is going right, Y+ is going back, so axis directions match the directions that are used in Marlin. However, I remind, that by default in RC branches Y axis is inverted by default, but I prefer to set the following

#define INVERT_X_DIR false    // for Mendel set to false, for Orca set to true
#define INVERT_Y_DIR false    // for Mendel set to true, for Orca set to false
#define INVERT_Z_DIR false    // for Mendel set to false, for Orca set to true

and after that adjust my steppers polarity to move in directions, that marlin is used to.
Can it be the issue? I'll try to confirm this later.

paulusjacobus · 2016-04-06T22:28:43Z

@ozligia I use a corexy and have further two cartesian printers (Prusa It2)

thinkyhead · 2016-04-06T23:16:20Z

@ozligia To help look into this a little further I've added more debugging output to the RCBugFix code. If you download the latest code and try leveling again, this time it will give a little more information around that section where the coordinates mysteriously change with the value -8.5 involved. So if other suggestions don't help, please try leveling again and post the new output.

thinkyhead · 2016-04-06T23:20:58Z

for Mendel set to false, for Orca set to true

Back in the early RepRap days somebody knew what this meant. 😀

ozligia · 2016-04-07T10:09:14Z

@thinkyhead, thanks. Will take a look this eveining (GMT+4)

ozligia · 2016-04-08T16:55:59Z

Hm. It seems that nothing change in output. Do i need any special options? I used M111 S32767

19:53:55.630 : N541 G28*19
19:53:55.632 : echo:N541 G28*19
19:53:55.637 : gcode_G28 >>>
19:53:55.637 : setup_for_endstop_move > enable_endstops(true)
19:53:55.637 : >>> homeaxis(0)
19:53:59.192 : > enable_endstops(false)
19:53:59.302 : > enable_endstops(true)
19:53:59.508 : > TRIGGER ENDSTOP > current_position: (0.00, 15.00, 15.01)
19:53:59.508 : set_axis_is_at_home(0) >>>
19:53:59.512 : > home_offset[axis]==0.00 > current_position: (0.00, 15.00, 15.01)
19:53:59.512 : <<< set_axis_is_at_home(0)
19:53:59.516 : > AFTER set_axis_is_at_home > current_position: (0.00, 15.00, 15.01)
19:53:59.516 : <<< homeaxis(0)
19:53:59.519 : > homeX > current_position: (0.00, 15.00, 15.01)
19:53:59.519 : >>> homeaxis(1)
19:54:03.116 : > enable_endstops(false)
19:54:03.231 : > enable_endstops(true)
19:54:03.432 : > TRIGGER ENDSTOP > current_position: (0.00, 0.00, 15.01)
19:54:03.436 : set_axis_is_at_home(1) >>>
19:54:03.437 : > home_offset[axis]==0.00 > current_position: (0.00, 0.00, 15.01)
19:54:03.437 : <<< set_axis_is_at_home(1)
19:54:03.440 : > AFTER set_axis_is_at_home > current_position: (0.00, 0.00, 15.01)
19:54:03.441 : <<< homeaxis(1)
19:54:03.445 : > homeY > current_position: (0.00, 0.00, 15.01)
19:54:03.445 : > Z_SAFE_HOMING >>>
19:54:03.449 : > Z_SAFE_HOMING > home_all_axis > current_position: (0.00, 0.00, 15.01)
19:54:03.452 : > Z_SAFE_HOMING > home_all_axis > destination: (92.00, 62.00, 15.01)
19:54:04.324 : >>> homeaxis(2)
19:54:04.328 : deploy_z_probe > current_position: (92.00, 62.00, 0.00)
19:54:05.639 : echo:busy: processing
19:54:08.216 : > enable_endstops(false)
19:54:08.740 : > enable_endstops(true)
19:54:10.731 : > TRIGGER ENDSTOP > current_position: (92.00, 62.00, 0.00)
19:54:10.731 : set_axis_is_at_home(2) >>>
19:54:10.735 : > zprobe_zoffset==0.00> home_offset[axis]==0.00 > current_position: (92.00, 62.00, 0.00)
19:54:10.735 : <<< set_axis_is_at_home(2)
19:54:10.739 : > AFTER set_axis_is_at_home > current_position: (92.00, 62.00, 0.00)
19:54:10.743 : > SERVO_LEVELING > (stow_z_probe())
19:54:10.743 : stow_z_probe > current_position: (92.00, 62.00, 0.00)
19:54:10.743 : <<< homeaxis(2)
19:54:10.743 : <<< Z_SAFE_HOMING
19:54:10.747 : > (home_all_axis || homeZ) > final > current_position: (92.00, 62.00, 0.00)
19:54:10.751 : ENDSTOPS_ONLY_FOR_HOMING enable_endstops(false)
19:54:10.751 : <<< gcode_G28
19:54:10.755 : ok
19:54:14.367 : N555 G29*23
19:54:14.372 : echo:N555 G29*23
19:54:14.372 : gcode_G29 >>>
19:54:14.372 : > current_position: (92.00, 62.00, 0.00) <-That is Ok, according to my temp settings
19:54:14.376 : G29 Auto Bed Leveling
19:54:14.376 : setup_for_endstop_move > enable_endstops(true)
19:54:14.376 : z_before = (before) 15
19:54:14.380 : probe_pt >>>
19:54:14.380 : > ProbeAction:1
19:54:14.380 : > current_position: (77.00, 15.00, 0.00)
19:54:14.380 : Z Raise to z_before 15.00
19:54:14.384 : > do_blocking_move_to_z 15.00
19:54:14.384 : do_blocking_move_to: (77.00, 15.00, 15.00)
19:54:18.165 : > do_blocking_move_to_xy 162.00, 7.00
19:54:18.165 : do_blocking_move_to: (162.00, 7.00, 15.00)
19:54:18.849 : > ProbeDeploy
19:54:18.853 : deploy_z_probe > current_position: (162.00, 7.00, 15.00)
19:54:24.374 : echo:busy: processing
19:54:24.853 : run_z_probe > current_position: (162.00, 7.00, 1.07)
19:54:24.858 : <<< probe_pt
19:54:24.858 : z_before = (between) 6.07
19:54:24.858 : probe_pt >>>
19:54:24.858 : > ProbeAction:0
19:54:24.862 : > current_position: (162.00, 7.00, 1.07)
19:54:24.862 : Z Raise to z_before 6.07
19:54:24.862 : > do_blocking_move_to_z 6.07
19:54:24.865 : do_blocking_move_to: (162.00, 7.00, 6.07)
19:54:26.140 : > do_blocking_move_to_xy 7.00, 7.00
19:54:26.140 : do_blocking_move_to: (7.00, 7.00, 6.07)
19:54:31.583 : run_z_probe > current_position: (7.00, 7.00, -0.81)
19:54:31.584 : <<< probe_pt
19:54:31.584 : z_before = (between) 4.19
19:54:31.584 : probe_pt >>>
19:54:31.584 : > ProbeAction:0
19:54:31.587 : > current_position: (7.00, 7.00, -0.81)
19:54:31.588 : Z Raise to z_before 4.19
19:54:31.588 : > do_blocking_move_to_z 4.19
19:54:31.591 : do_blocking_move_to: (7.00, 7.00, 4.19)
19:54:32.865 : > do_blocking_move_to_xy 7.00, 132.00
19:54:32.870 : do_blocking_move_to: (7.00, 132.00, 4.19)
19:54:34.376 : echo:busy: processing
19:54:37.609 : run_z_probe > current_position: (7.00, 132.00, -0.76)
19:54:37.609 : <<< probe_pt
19:54:37.609 : z_before = (between) 4.24
19:54:37.612 : probe_pt >>>
19:54:37.613 : > ProbeAction:2
19:54:37.613 : > current_position: (7.00, 132.00, -0.76)
19:54:37.617 : Z Raise to z_before 4.24
19:54:37.617 : > do_blocking_move_to_z 4.24
19:54:37.617 : do_blocking_move_to: (7.00, 132.00, 4.24)
19:54:38.895 : > do_blocking_move_to_xy 162.00, 132.00
19:54:38.895 : do_blocking_move_to: (162.00, 132.00, 4.24)
19:54:43.609 : run_z_probe > current_position: (162.00, 132.00, 0.52)
19:54:43.609 : > ProbeStow (stow_z_probe will do Z Raise)
19:54:43.610 : stow_z_probe > current_position: (162.00, 132.00, 0.52)
19:54:43.610 : <<< probe_pt
19:54:43.613 : > probing complete > current_position: (162.00, 132.00, 0.52)
19:54:43.614 : clean_up_after_endstop_move > ENDSTOPS_ONLY_FOR_HOMING > endstops_not_homing()
19:54:43.621 : Eqn coefficients: a: 0.01020161 b: -0.00195000 d: -0.72964897
19:54:43.625 : planeNormal x: -0.010202 y: 0.001950 z: 1.000000
19:54:43.630 : set_bed_level_equation_lsq > current_position: (147.00, 15.00, -0.95)
19:54:43.630 : 
19:54:43.630 : Bed Level Correction Matrix:
19:54:43.633 : +0.999948 +0.000000 +0.010201
19:54:43.633 : +0.000020 +0.999998 -0.001950
19:54:43.638 : -0.010201 +0.001950 +0.999946
19:54:43.638 : > BEFORE apply_rotation_xyz > z_tmp  = -0.95
19:54:43.642 : > BEFORE apply_rotation_xyz > real_z = 0.52
19:54:43.642 : > AFTER apply_rotation_xyz > z_tmp  = 0.53
19:54:43.646 : > corrected Z in G29 > current_position: (147.00, 15.00, 0.01)
19:54:43.646 : do_blocking_move_to: (147.00, 15.00, 15.01)
19:54:44.379 : echo:busy: processing
19:54:47.423 : <<< gcode_G29
19:54:47.434 : ok

ozligia · 2016-04-08T17:32:47Z

PS. And y axis inversion did not help

thinkyhead · 2016-04-08T23:57:33Z

The important debug addition is the report of the current coordinates at the beginning of G29. This allows us to know that current_position is correct when G29 first starts. This means that if current_position is being corrupted, it must be some time after G29 starts, but before probe_pt is invoked. So now I can hopefully isolate the point where this alteration is taking place.

thinkyhead · 2016-04-09T00:24:34Z

Ok, so from what I can tell, the error is being caused by this code block in gcode_G29:

...
...
vector_3 uncorrected_position = plan_get_position();
...
current_position[X_AXIS] = uncorrected_position.x;
current_position[Y_AXIS] = uncorrected_position.y;
current_position[Z_AXIS] = uncorrected_position.z;
sync_plan_position();

This is the only code that would alter the current position before the first probe_pt. It's getting the current position as reckoned by the planner / stepper code, which under various circumstances needs to be refreshed with the high-level current_position (anytime current_position is changed directly, for example). So either the G28 routine is failing to call sync_plan_position or this uncorrected_position thing is closer to the cause.

So, as to the first idea – that sync_plan_position isn't being called after G28 – well, it clearly is being called. The debug line "AFTER set_axis_is_at_home > current_position: (92.00, 62.00, 0.00)" happens immediately after sync_plan_position() is called in home_axis. If the position is correct at this point, then it's strange that plan_get_position gives a different value later.

So… for the moment, just try commenting out the lines I've shown above and see how it affects behavior. As long as you just did a G28 command and didn't do a G29 previously, the G29 should work properly without these lines. (However, if you do two or more G29 in a row without G28 between, results will be unpredictable.)

If that manages to help your situation, then we'll know that the "matrix correction" is causing the problem, and can look further into why.

Creativesam · 2016-04-10T15:36:36Z

From ozligiz's comments
i could find something...

1st example

20:02:40.072 : > probing complete > current_position: (225.00, 190.00, 0.20)
20:02:40.089 : set_bed_level_equation_lsq > current_position: (207.50, 17.50, 0.33)

2nd example

19:54:43.613 : > probing complete > current_position: (162.00, 132.00, 0.52)
19:54:43.630 : set_bed_level_equation_lsq > current_position: (147.00, 15.00, -0.95)

the value changes in a certain rule.
At the first case 225,190 changes into 207.5 17.5
At the second case 162,132 changes into 147,15

And i found a simple math formula
Original X value - Altered y value = altered X value.
225,190 -->207.5, 17.5 ====> '225-17.5=207.5'
162,132 -->147, 15 =======> '162-15=147

Actually I have the same problem.
Mine changes
160,186 -->173,-13 =====> '160-(-13)=173'

But the problem is where the value 13 is from.

This value might help.
I used Marlin 1.0.2 ; at that time auto leveling was OK.

ozligia · 2016-04-10T21:08:53Z

Output from G29 with new logging, without commenting lines out from gcode_G29

23:48:51.341 : gcode_G29 >>>
23:48:51.345 : > current_position: (82.00, 57.00, 0.17)
23:48:51.346 : G29 Auto Bed Leveling
23:48:51.349 : BEFORE matrix.set_to_identity > current_position: (82.00, 57.00, 0.17)
23:48:51.350 : sync_plan_position > current_position: (69.50, 12.50, 0.17)
23:48:51.354 : AFTER matrix.set_to_identity > current_position: (69.50, 12.50, 0.17)
23:48:51.354 : setup_for_endstop_move > enable_endstops(true)
23:48:51.357 : z_before = (before) 15
23:48:51.357 : probe_pt >>>

The following is the output with requested lines commented out:

        //current_position[X_AXIS] = uncorrected_position.x;<-
        //current_position[Y_AXIS] = uncorrected_position.y;<-
        //current_position[Z_AXIS] = uncorrected_position.z;<-

23:57:55.196 : gcode_G29 >>>
23:57:55.196 : > current_position: (82.00, 57.00, 0.17)
23:57:55.196 : G29 Auto Bed Leveling
23:57:55.200 : BEFORE matrix.set_to_identity > current_position: (82.00, 57.00, 0.17)
23:57:55.205 : sync_plan_position > current_position: (82.00, 57.00, 0.17)
23:57:55.208 : AFTER matrix.set_to_identity > current_position: (82.00, 57.00, 0.17)
23:57:55.209 : setup_for_endstop_move > enable_endstops(true)
23:57:55.209 : z_before = (before) 15
23:57:55.209 : probe_pt >>>

Here goes some probing...

23:58:58.008 : <<< probe_pt
23:58:58.012 : > probing complete > current_position: (172.00, 152.00, 2.44)
23:58:58.016 : clean_up_after_endstop_move > ENDSTOPS_ONLY_FOR_HOMING > endstops_not_homing()
23:58:58.029 : Eqn coefficients: a: 0.01407582 b: 0.01029028 d: -2.03005051
23:58:58.029 : BEFORE set_bed_level_equation_lsq > current_position: (172.00, 152.00, 2.44)
23:58:58.033 : AFTER set_bed_level_equation_lsq > current_position: (162.02, 10.00, 0.05)
23:58:58.037 : sync_plan_position > current_position: (162.02, 10.00, 0.05)
23:58:58.037 : 
23:58:58.037 : Bed Level Correction Matrix:
23:58:58.041 : +0.999901 +0.000000 +0.014074
23:58:58.041 : -0.000145 +0.999947 +0.010288
23:58:58.045 : -0.014074 -0.010289 +0.999848
23:58:58.045 : > BEFORE apply_rotation_xyz > z_tmp  = 0.05
23:58:58.050 : > BEFORE apply_rotation_xyz > real_z = 2.44
23:58:58.050 : > AFTER apply_rotation_xyz > z_tmp  = 2.94
23:58:58.054 : sync_plan_position > current_position: (162.02, 10.00, 0.67)
23:58:58.057 : > corrected Z in G29 > current_position: (162.02, 10.00, 0.67)
23:58:58.057 : do_blocking_move_to: (162.02, 10.00, 15.67)
23:58:59.790 : echo:busy: processing
23:59:01.789 : echo:busy: processing
23:59:02.170 : <<< gcode_G29

G29 going right after G28, now the printer followed all the points for probing correctly
Final position was set incorrectly.
G29 log.txt

thinkyhead · 2016-04-11T22:11:29Z

The fact that the Y value is affecting the X value points to this being a definite CoreXY-related issue, since ∆A = (∆X + ∆Y) and ∆B = (∆X - ∆Y).

And now that I look closer it does appear that st_set_position is not yet compatible with COREXY or COREXZ, which means plan_set_position is broken too. This isn't a new thing for st_set_position. You're seeing this bug now because Marlin has been getting better CORE support, but some code hasn't caught up.

Try replacing the st_set_position function with this code and see if it helps:

void st_set_position(const long& x, const long& y, const long& z, const long& e) {
  CRITICAL_SECTION_START;

  #if ENABLED(COREXY)
    // corexy planning
    // these equations follow the form of the dA and dB equations on http://www.corexy.com/theory.html
    count_position[A_AXIS] = x + y;
    count_position[B_AXIS] = x - y;
    count_position[Z_AXIS] = z;
  #elif ENABLED(COREXZ)
    // corexz planning
    count_position[A_AXIS] = x + z;
    count_position[Y_AXIS] = y;
    count_position[C_AXIS] = x - z;
  #else
    // default non-h-bot planning
    count_position[X_AXIS] = x;
    count_position[Y_AXIS] = y;
    count_position[Z_AXIS] = z;
  #endif

  count_position[E_AXIS] = e;
  CRITICAL_SECTION_END;
}

If this fixes the issue then I will merge it asap! Hopefully this is the last missing piece for COREXY and COREXZ… but I will continue to watch out for things like this.

paulusjacobus · 2016-04-12T03:58:50Z

Okay @thinkyhead I will try to use this fix and see if it works. Probably
have only time during the weekend but will try.

On 12 April 2016 at 08:11, Scott Lahteine notifications@github.com wrote:

The fact that the Y value is affecting the X value points to this being a
definite CoreXY-related issue, since ∆A = (∆X + ∆Y) and ∆B = (∆X - ∆Y).
And now that I look closer it does appear that st_set_position is not yet
compatible with COREXY or COREXZ, which means plan_set_position is broken
too. This isn't a new thing for st_set_position. You're seeing this bug
now because Marlin has been getting better CORE support, but some code
hasn't caught up.

Try replacing the st_set_position function with this code and see if it
helps:

void st_set_position(const long& x, const long& y, const long& z, const long& e) {
CRITICAL_SECTION_START;

#if ENABLED(COREXY)
// corexy planning
// these equations follow the form of the dA and dB equations on http://www.corexy.com/theory.html
count_position[A_AXIS] = x + y;
count_position[B_AXIS] = x - y;
count_position[Z_AXIS] = z;
#elif ENABLED(COREXZ)
// corexz planning
count_position[A_AXIS] = x + z;
count_position[Y_AXIS] = y;
count_position[C_AXIS] = x - z;
#else
// default non-h-bot planning
count_position[X_AXIS] = x;
count_position[Y_AXIS] = y;
count_position[Z_AXIS] = z;
#endif

count_position[E_AXIS] = e;
CRITICAL_SECTION_END;
}

If this fixes the issue then I will merge it asap! Hopefully this is the
last missing piece for COREXY and COREXZ… but I will continue to watch
out for things like this.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#3311 (comment)

Creativesam · 2016-04-12T05:53:55Z

I replaced that above.. It's working.
Thank you for quick reponse.
I started printing a thing. I will report again.

jorgerobles · 2016-04-13T06:58:26Z

I've used thinkyhead patch on my CoreXY build, it works!

ozligia · 2016-04-13T16:47:54Z

Yep, the code above fixes the issue. Thanks, guys, i really appreciate your work.

github-actions · 2022-04-05T14:02:46Z

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

thinkyhead added Bug: Potential ? Needs: More Data We need more data in order to proceed labels Apr 6, 2016

This was referenced Apr 9, 2016

Additional debug leveling output #3434

Merged

G29 set_bed_level_equation_lsq #3417

Closed

thinkyhead mentioned this issue Apr 11, 2016

Autolevelling grid issue on corexy #3274

Closed

thinkyhead mentioned this issue Apr 11, 2016

Add CORE support to st_set_position and plan_set_position #3466

Merged

ozligia closed this as completed Apr 13, 2016

jhnphm mentioned this issue Apr 18, 2016

Home Position Reset after G29 #2845

Closed

jbrazio modified the milestone: 1.1.0 Jul 16, 2016

github-actions bot locked and limited conversation to collaborators Apr 5, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Auto bed leveling manages coordinates in strange way, leaving final position incorrect #3311

Auto bed leveling manages coordinates in strange way, leaving final position incorrect #3311

ozligia commented Apr 2, 2016

g2david commented Apr 2, 2016

paulusjacobus commented Apr 2, 2016

ozligia commented Apr 2, 2016

ozligia commented Apr 2, 2016

jbrazio commented Apr 2, 2016

Roxy-3D commented Apr 3, 2016

jhnphm commented Apr 3, 2016

ozligia commented Apr 3, 2016

ozligia commented Apr 5, 2016

paulusjacobus commented Apr 5, 2016

ozligia commented Apr 6, 2016

paulusjacobus commented Apr 6, 2016

thinkyhead commented Apr 6, 2016

thinkyhead commented Apr 6, 2016

ozligia commented Apr 7, 2016

ozligia commented Apr 8, 2016

ozligia commented Apr 8, 2016

thinkyhead commented Apr 8, 2016

thinkyhead commented Apr 9, 2016

Creativesam commented Apr 10, 2016

ozligia commented Apr 10, 2016

thinkyhead commented Apr 11, 2016

paulusjacobus commented Apr 12, 2016

Creativesam commented Apr 12, 2016

jorgerobles commented Apr 13, 2016

ozligia commented Apr 13, 2016

github-actions bot commented Apr 5, 2022

Auto bed leveling manages coordinates in strange way, leaving final position incorrect #3311

Auto bed leveling manages coordinates in strange way, leaving final position incorrect #3311

Comments

ozligia commented Apr 2, 2016

g2david commented Apr 2, 2016

paulusjacobus commented Apr 2, 2016

ozligia commented Apr 2, 2016

ozligia commented Apr 2, 2016

jbrazio commented Apr 2, 2016

Roxy-3D commented Apr 3, 2016

jhnphm commented Apr 3, 2016

ozligia commented Apr 3, 2016

ozligia commented Apr 5, 2016

paulusjacobus commented Apr 5, 2016

ozligia commented Apr 6, 2016

paulusjacobus commented Apr 6, 2016

thinkyhead commented Apr 6, 2016

thinkyhead commented Apr 6, 2016

ozligia commented Apr 7, 2016

ozligia commented Apr 8, 2016

ozligia commented Apr 8, 2016

thinkyhead commented Apr 8, 2016

thinkyhead commented Apr 9, 2016

Creativesam commented Apr 10, 2016

ozligia commented Apr 10, 2016

thinkyhead commented Apr 11, 2016

paulusjacobus commented Apr 12, 2016

Creativesam commented Apr 12, 2016

jorgerobles commented Apr 13, 2016

ozligia commented Apr 13, 2016

github-actions bot commented Apr 5, 2022