Marlin: [BUG] Any G0/G1 commands go to origin

[lostcontrol]

Description

This is driving me crazy :angry: I have spent 2 evenings trying to figure out what is happening, without success... It all started after I installed a 3DTouch on my CR-10 Mini. On the hardware side, everything should be fine. The 3DTouch works as expected. I can home all 3 axis with G28 (Z_SAFE_HOMING is enabled) and G29 works. I use bilinear with a 4x3 grid and the process goes fine, I see the XYZ positions being updated properly on the LCD display as the measurements go on. So I think the hardware side looks good and the software part not so bad.

Now, if I send a G0 X100 or any G0/G1 command after homing or bed leveling, the head goes invariably to 0,0,0 and stay there forever. XYZ positions on the LCD display stay at 0,0,0 and using the built-in "Move axis" feature, the value stays at +000.00.

I disabled bed leveling in my configuration to have one less thing that could go wrong but the behavior is exactly the same. You can see my configuration here.

I enabled some debugging output in the code and here is the result:

echo:Marlin bugfix-1.1.x

echo: Last Updated: 2018-07-31 | Author: (none, default config)
echo:Compiled: Apr 10 2019
echo: Free Memory: 12812  PlannerBufferBytes: 1408
echo:V55 stored settings retrieved (655 bytes; crc 25572)
echo:  G21    ; (mm)
echo:  M149 C ; Units in Celsius

echo:Filament settings: Disabled
echo:  M200 D1.75
echo:  M200 D0
echo:Steps per unit:
echo:  M92 X80.00 Y80.00 Z400.00 E93.00
echo:Maximum feedrates (units/s):
echo:  M203 X500.00 Y500.00 Z15.00 E50.00
echo:Maximum Acceleration (units/s2):
echo:  M201 X1000 Y1000 Z1000 E5000
echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
echo:  M204 P500.00 R1000.00 T1000.00
echo:Advanced: Q<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> X<max_x_jerk> Y<max_y_jerk> Z<max_z_jerk> E<max_e_jerk>
echo:  M205 Q20000 S0.00 T0.00 X10.00 Y10.00 Z0.40 E5.00
echo:Material heatup parameters:
echo:  M145 S0 H200 B65 F0
echo:  M145 S1 H235 B70 F0
echo:PID settings:
echo:  M301 P21.73 I1.54 D76.55
echo:  M304 P690.34 I111.47 D1068.83
echo:Z-Probe Offset (mm):
echo:  M851 Z0.00
echo:Linear Advance:
echo:  M900 K0.00
echo:DEBUG:ECHO
ok
echo:G28
  buffer_segment FR:4.00 X:0.00 (0->0) Y:0.00 (0->0) Z:5.00 (0->2000) E:0.00 (0->0)
  buffer_segment FR:250.00 X:0.00 (0->0) Y:0.00 (0->0) Z:5.00 (2000->2000) E:0.00 (0->0)
echo:busy: processing
  buffer_segment FR:24.80 X:-450.00 (0->-36000) Y:-330.00 (0->-26400) Z:5.00 (2000->2000) E:0.00 (0->0)
  buffer_segment FR:20.00 X:-450.00 (0->-36000) Y:0.00 (0->0) Z:5.00 (2000->2000) E:0.00 (0->0)
  buffer_segment FR:20.00 X:5.00 (0->400) Y:0.00 (0->0) Z:5.00 (2000->2000) E:0.00 (0->0)
  buffer_segment FR:10.00 X:-10.00 (0->-800) Y:0.00 (0->0) Z:5.00 (2000->2000) E:0.00 (0->0)
  buffer_segment FR:20.00 X:0.00 (0->0) Y:-330.00 (0->-26400) Z:5.00 (2000->2000) E:0.00 (0->0)
  buffer_segment FR:20.00 X:0.00 (0->0) Y:5.00 (0->400) Z:5.00 (2000->2000) E:0.00 (0->0)
  buffer_segment FR:10.00 X:0.00 (0->0) Y:-10.00 (0->-800) Z:5.00 (2000->2000) E:0.00 (0->0)
echo:busy: processing
  buffer_segment FR:250.00 X:189.00 (0->15120) Y:118.00 (0->9440) Z:5.00 (2000->2000) E:0.00 (0->0)
  buffer_segment FR:4.00 X:189.00 (15120->15120) Y:118.00 (9440->9440) Z:10.00 (2000->4000) E:0.00 (0->0)
  buffer_segment FR:250.00 X:189.00 (15120->15120) Y:118.00 (9440->9440) Z:10.00 (4000->4000) E:0.00 (0->0)
echo:busy: processing
  buffer_segment FR:250.00 X:189.00 (15120->15120) Y:118.00 (9440->9440) Z:10.00 (4000->4000) E:0.00 (0->0)
  buffer_segment FR:4.00 X:189.00 (15120->15120) Y:118.00 (9440->9440) Z:-450.00 (0->-180000) E:0.00 (0->0)
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
  buffer_segment FR:4.00 X:189.00 (15120->15120) Y:118.00 (9440->9440) Z:5.00 (0->2000) E:0.00 (0->0)
echo:busy: processing
  buffer_segment FR:2.00 X:189.00 (15120->15120) Y:118.00 (9440->9440) Z:-10.00 (0->-4000) E:0.00 (0->0)
echo:busy: processing
echo:busy: processing
  buffer_segment FR:4.00 X:189.00 (15120->15120) Y:118.00 (9440->9440) Z:10.00 (0->4000) E:0.00 (0->0)
  buffer_segment FR:250.00 X:189.00 (15120->15120) Y:118.00 (9440->9440) Z:10.00 (4000->4000) E:0.00 (0->0)
echo:busy: processing
  buffer_segment FR:250.00 X:189.00 (15120->15120) Y:118.00 (9440->9440) Z:10.00 (4000->4000) E:0.00 (0->0)
X:189.00 Y:118.00 Z:10.00 E:0.00 Count X:15120 Y:9440 Z:4000
ok
echo:G0 Y100
  buffer_segment FR:25.00 X:0.00 (15120->0) Y:0.00 (9440->0) Z:0.00 (4000->0) E:0.00 (0->0)
ok
echo:G0 X100
  buffer_segment FR:25.00 X:0.00 (0->0) Y:0.00 (0->0) Z:0.00 (0->0) E:0.00 (0->0)
ok
echo:G0 X10
  buffer_segment FR:25.00 X:0.00 (0->0) Y:0.00 (0->0) Z:0.00 (0->0) E:0.00 (0->0)
ok
echo:G0 Z10
  buffer_segment FR:25.00 X:0.00 (0->0) Y:0.00 (0->0) Z:0.00 (0->0) E:0.00 (0->0)
ok

As you can see, G0 Y100 result in a move to 0,0,0. I would expect it to just move the Y axis to 100. I just don't get it. I'm using latest bugfix-1.1.x. Any idea what I'm doing wrong or how I should proceed with further debugging? Thank you.

[swilkens]

Development is currently ongoing in the bugfix-2.0.x branch, you might first try that branch to see if you encounter the same problem.

https://github.com/MarlinFirmware/Marlin/tree/bugfix-2.0.x

[p3p]

Trying out Marlin 2 would be my first recommendation too, failing that you also have quite a few 'extras' turned on, to aid debugging I would turn off everything not directly related to getting the printer moving to try and find a minimum working config.

[lostcontrol]

Thank you guys. I just ported my configuration to bugfix-2.0.x and compiled. I'll give it a try on my CR-10 Mini tomorrow. I didn't find any report of similar issues, either here or on the web. I wonder if I'm doing something fundamentally wrong!? I'll give bugfix-2.0.x a try and report back. Thank you.

[thinkyhead]

Configuration looks okay. Does it help to do M502 followed by M500 and a reboot?

[lostcontrol]

@thinkyhead no, resetting/saving the config didn't help

However, I can confirm that things work "as expected" in bugfix-2.0.x (tried with 2adc37b) :v: :smiley: So something must be wrong in 1.1.x. How stable is bugfix-2.0.x by the way? In any case, thanks again, it was driving me crazy...

Now I put "as expected" between quotes because I think my 3DTouch is crap :sob: I get the following results:

M48 X150 Y115 S0 L2 P5 V2

Mean: 1.124100 Min: 0.750 Max: 1.602 Range: 0.852
Standard Deviation: 0.281412

and every bed leveling run returns very different values:

Bilinear Leveling Grid:
      0      1      2
 0 -0.856 -0.117 +0.000
 1 -0.977 -1.057 -0.864
 2 -0.940 -0.089 -1.011

Bilinear Leveling Grid:
      0      1      2
 0 -0.441 -0.096 -1.065
 1 +0.083 -0.009 -1.084
 2 +0.151 -1.001 -0.115

Bilinear Leveling Grid:
      0      1      2
 0 -0.066 +0.416 +0.256
 1 +0.575 +0.138 +0.852
 2 +0.865 +0.064 +0.797

I tightened the hex screw on the 3DTouch (geeetech) and I get much better results, almost usable, but still not perfect and the probe is getting too close to the bed... Interestingly, doing a M48 X150 Y115 without have the print head moving between probes result in a quite good standard deviation. It seems the needle "rotates/moves" when the print head moves and this affects the repeatability. Cheap is always too cheap... Well, this is off-topic, just wanted to report. Thanks again for suggesting bugfix-2.0.x

[github-actions[bot]]

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.