Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Unable to perform any moves using G91 (relative positioning) after homing #20370

Closed
coolcheat opened this issue Dec 4, 2020 · 21 comments · Fixed by #20389
Closed

[BUG] Unable to perform any moves using G91 (relative positioning) after homing #20370

coolcheat opened this issue Dec 4, 2020 · 21 comments · Fixed by #20389

Comments

@coolcheat
Copy link

coolcheat commented Dec 4, 2020

Hello everyone!

Thanks for everything so far!

Bug Description

Today, I have tried pulling bugfix-2.0.x and flashing it to my printer.

After flashing the latest bugfix version, it seems like trying to extrude in relative positioning mode causes the printer to go to X=0,Y=0,Z=0 before extruding.

This doesn't happen if I don't execute G28, that is, the printer goes to (0,0,0) only after homing.

Configuration Files

configurations.zip

using the RUMBA+ board, I've got a printer with two extruders.

The following (possibly affecting) configurations have been set:

SINGLENOZZLE (I've setup two extruders to use a single nozzle)
PREVENT_COLD_EXTRUSION has been disabled
S_CURVE_ACCELERATION has been enabled
Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN has been enabled
USE_PROBE_FOR_Z_HOMING has been enabled
NOZZLE_AS_PROBE has been enabled
AUTO_BED_LEVELING_UBL has been enabled
RESTORE_LEVELING_AFTER_G28 has been enabled
Z_SAFE_HOMING has been enabled
NOZZLE_PARK_FEATURE has been enabled

The following drivers are used:
X_DRIVER_TYPE TMC2130
Y_DRIVER_TYPE TMC2130
Z_DRIVER_TYPE TMC2130
Z2_DRIVER_TYPE TMC2130
E0_DRIVER_TYPE A4988
E1_DRIVER_TYPE A4988

Please also see attached configuration files for anything else.

Steps to Reproduce

Do the following:
G28
G91
G1 E5 F300

Expected behavior:

Try to extrude on the spot without going to (0,0,0)

Actual behavior:

The printer first goes to (0,0,0) (very slowly actually) and then extrudes.

Additional Information

I've also tried this without any bed leveling and have experienced the same behavior.

If needed, I can provide addition information or videos.

Thanks!

@rhapsodyv
Copy link
Member

I didn't understand your issue. G28 makes the printer go home. And it will to home using the speed configured in HOMING_FEEDRATE_Z and HOMING_FEEDRATE_XY.

Your gcode is working exactly as expected, if I understood it right...

@coolcheat
Copy link
Author

Well, if I try to extrude when the printer isn't homed it tries to extrude as expected.

However, if I try to extrude with relative positioning after homing, wherever the print head is at, the printer will first go to 0,0,0 and try to extrude only when reaching that position.

Sorry if this wasn't clear from my initial post.

@rhapsodyv
Copy link
Member

I didn't understood yet. If you have G28 first, you are in fact telling: printer, first goes to 0,0,0, then execute the next
command.

@ellensp can you help here? Maybe I'm missing something.

@rhapsodyv
Copy link
Member

rhapsodyv commented Dec 4, 2020

Or are you saying the printer is doing home two times?

Sorry, I'm not trying to tell that you are saying something wrong. I'm not a native English speaker and sometimes I can misunderstanding some sentences! But we will get there! @ellensp will help us.

@coolcheat
Copy link
Author

It's not doing two moves, it just goes to x=0,y=0,z=0 without me asking it to.

When I do g28, I probe the center of the bed, so there's no reason for the printer to move to that location.

Thanks.

@rhapsodyv
Copy link
Member

It's not doing two moves, it just goes to x=0,y=0,z=0 without me asking it to.

When I do g28, I probe the center of the bed, so there's no reason for the printer to move to that location.

Thanks.

Ok, now I think I got you. I will test it.

@coolcheat
Copy link
Author

It's not doing two moves, it just goes to x=0,y=0,z=0 without me asking it to.
When I do g28, I probe the center of the bed, so there's no reason for the printer to move to that location.
Thanks.

Ok, now I think I got you. I will test it.

Thank you! Sorry for not being clear about this in the first place.

@ellensp
Copy link
Contributor

ellensp commented Dec 5, 2020

Himm, something odd does seem to be going on here..

Using provided configs but motherboard set to RAMP 1.4 and single Z

I don't have actual stepper drivers I have LEDs on ENABLE,STEP and DIECTION PINs
Doing this test both X and Y Step pins are dimply lit. On connecting a scope they are getting toggled, enable is active

all the action happens on the "G1 E5 F300", its like there are invisible X and Y components to the move.

M114 does not report any movement on X or Y

NB I did have to comment out https://github.com/MarlinFirmware/Marlin/blob/2.0.x/Marlin/src/module/endstops.cpp#L318
So I could manually triggered endstops without halting, this be a test setup only, not a full machine.

@coolcheat
Copy link
Author

Actually, I originally thought it was because I was trying to extrude in relative mode, but it seems to happen whenever I try to do any relative move after homing!

Same behavior is observed, the printer goes to 0,0,0 and after that refuses to move to any other point with relative positioning.

@coolcheat coolcheat changed the title [BUG] Unable to extrude using G91 (relative positioning) after homing [BUG] Unable to perform any moves using G91 (relative positioning) after homing Dec 5, 2020
@rhapsodyv
Copy link
Member

Can you send M111 S32 first, then do your test, and send the serial output here?

@coolcheat
Copy link
Author

Sure thing!

Send: M111 S32
Recv: echo:DEBUG:LEVELING
Recv: ok
[...]
Send: G28
Recv: >>> G28  X-18.00 Y-5.00 Z0.00
Recv: Machine Type: Cartesian
Recv: Probe: NOZZLE_AS_PROBE
Recv: Probe Offset X0 Y0 Z0.08 (Above Nozzle)
Recv: Raise Z (before homing) by 12.00
Recv: >>> do_blocking_move_to  X-18.00 Y-5.00 Z0.00
Recv: >  X-18.00 Y-5.00 Z12.00
[...]
Recv: echo:busy: processing
Printer seems to support the busy protocol, will adjust timeouts and set busy interval accordingly
Recv: <<< do_blocking_move_to  X-18.00 Y-5.00 Z12.00
Recv:   current_position= X0.00 Y0.00 Z12.00 : sync_plan_position
Recv: >>> do_blocking_move_to  X0.00 Y0.00 Z12.00
Recv: >  X-345.00 Y-405.00 Z12.00
Recv: <<< do_blocking_move_to  X-345.00 Y-405.00 Z12.00
Recv: >>> homeaxis(X)
Recv: Home 1 Fast:
Recv: >>> do_homing_move  X0.00 Y0.00 Z12.00
Recv: ...(X, -345.00, [100.00])
Recv: <<< do_homing_move  X0.00 Y0.00 Z12.00
Recv: Move Away:
Recv: >>> do_homing_move  X0.00 Y0.00 Z12.00
Recv: ...(X, 5.00, [100.00])
Recv: <<< do_homing_move  X0.00 Y0.00 Z12.00
Recv: Home 2 Slow:
Recv: >>> do_homing_move  X0.00 Y0.00 Z12.00
Recv: ...(X, -10.00, 50.00)
[...]
Recv: <<< do_homing_move  X0.00 Y0.00 Z12.00
Recv: >>> set_axis_is_at_home(X)
Recv: Axis X home_offset = 0.00 position_shift = 0.00
Recv: > home_offset[X] = 0.00
Recv:   current_position= X-18.00 Y0.00 Z12.00 :
Recv: <<< set_axis_is_at_home(X)
Recv:   current_position= X-18.00 Y0.00 Z12.00 : sync_plan_position
Recv:   current_position= X-18.00 Y0.00 Z12.00 : > AFTER set_axis_is_at_home
Recv: <<< homeaxis(X)
Recv: >>> homeaxis(Y)
Recv: Home 1 Fast:
Recv: >>> do_homing_move  X-18.00 Y0.00 Z12.00
Recv: ...(Y, -405.00, [100.00])
Recv: <<< do_homing_move  X-18.00 Y0.00 Z12.00
Recv: Move Away:
Recv: >>> do_homing_move  X-18.00 Y0.00 Z12.00
Recv: ...(Y, 5.00, [100.00])
Recv: <<< do_homing_move  X-18.00 Y0.00 Z12.00
Recv: Home 2 Slow:
Recv: >>> do_homing_move  X-18.00 Y0.00 Z12.00
Recv: ...(Y, -10.00, 50.00)
Recv: echo:busy: processing
Recv: <<< do_homing_move  X-18.00 Y0.00 Z12.00
Recv: >>> set_axis_is_at_home(Y)
Recv: Axis Y home_offset = 0.00 position_shift = 0.00
Recv: > home_offset[Y] = 0.00
Recv:   current_position= X-18.00 Y-5.00 Z12.00 :
Recv: <<< set_axis_is_at_home(Y)
Recv:   current_position= X-18.00 Y-5.00 Z12.00 : sync_plan_position
Recv:   current_position= X-18.00 Y-5.00 Z12.00 : > AFTER set_axis_is_at_home
Recv: <<< homeaxis(Y)
Recv: >>> home_z_safely  X-18.00 Y-5.00 Z12.00
Recv:   current_position= X-18.00 Y-5.00 Z12.00 : sync_plan_position
Recv:   destination= X106.00 Y132.00 Z12.00 : home_z_safely
Recv: >>> do_blocking_move_to  X-18.00 Y-5.00 Z12.00
Recv: >  X106.00 Y132.00 Z12.00
[...]
Recv: echo:busy: processing
Recv: <<< do_blocking_move_to  X106.00 Y132.00 Z12.00
Recv: >>> homeaxis(Z)
Recv:   current_position= X106.00 Y132.00 Z12.00 : Probe::set_deployed
Recv: deploy: 1
Recv: Probe::do_z_raise(10.00)
Recv: >>> do_blocking_move_to  X106.00 Y132.00 Z12.00
Recv: >  X106.00 Y132.00 Z12.00
Recv: <<< do_blocking_move_to  X106.00 Y132.00 Z12.00
Recv: >>> do_blocking_move_to  X106.00 Y132.00 Z12.00
Recv: >  X106.00 Y132.00 Z12.00
Recv: <<< do_blocking_move_to  X106.00 Y132.00 Z12.00
Recv: Home 1 Fast:
Recv: >>> do_homing_move  X106.00 Y132.00 Z12.00
Recv: ...(Z, -645.00, [3.17])
[...]
Recv: echo:busy: processing
[...]
Recv: echo:busy: processing
[...]
Recv: <<< do_homing_move  X106.00 Y132.00 Z12.00
Recv: >>> set_axis_is_at_home(Z)
Recv: *** Z HOMED WITH PROBE (Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN) ***
Recv: > probe.offset.z = 0.08
Recv: Axis Z home_offset = 0.00 position_shift = 0.00
Recv: > home_offset[Z] = 0.00
Recv:   current_position= X106.00 Y132.00 Z-0.08 :
Recv: <<< set_axis_is_at_home(Z)
Recv:   current_position= X106.00 Y132.00 Z-0.08 : sync_plan_position
Recv:   current_position= X106.00 Y132.00 Z-0.08 : > AFTER set_axis_is_at_home
Recv:   current_position= X106.00 Y132.00 Z-0.08 : Probe::set_deployed
Recv: deploy: 0
Recv: >>> do_blocking_move_to  X106.00 Y132.00 Z-0.08
Recv: >  X106.00 Y132.00 Z-0.08
Recv: <<< do_blocking_move_to  X106.00 Y132.00 Z-0.08
Recv: <<< homeaxis(Z)
Recv: <<< home_z_safely  X106.00 Y132.00 Z-0.08
Recv: >>> do_blocking_move_to  X106.00 Y132.00 Z-0.08
Recv: >  X106.00 Y132.00 Z10.00
Recv: echo:busy: processing
[...]
Recv: <<< do_blocking_move_to  X106.00 Y132.00 Z10.00
Recv:   current_position= X106.00 Y132.00 Z10.00 : sync_plan_position
Recv: X:106.00 Y:132.00 Z:10.00 E:0.00 Count X:21200 Y:26400 Z:4000
Recv: <<< G28  X106.00 Y132.00 Z10.00
Recv: ok
Send: M113 S19
Recv: ok
[...]
Send: G91
Recv: ok
Send: G1 E5 F300
Recv: ok
Send: G90
Recv: ok

@coolcheat
Copy link
Author

Also, following a hunch I tried setting only 1 extruder and disabling SINGLENOZZLE but that didn't seem to help at all :|

@rhapsodyv
Copy link
Member

I could not reproduce it yet, I will try to get a hardware closer to yours. But it would help a lot if you can try disabling some configs until you find the one that is causing this... 😞

@coolcheat
Copy link
Author

I was thinking of doing the same actually.

Any idea which features I should focus on first?

@rhapsodyv
Copy link
Member

can you enter on marlin discord? Maybe we can guide you to some tests.

@ellensp
Copy link
Contributor

ellensp commented Dec 6, 2020

i would start with no extra features. Just motherboard, thermistors, steps/mm, max feed rates and homing directions, maybe a lcd. Everything else default.

@coolcheat
Copy link
Author

Some updates!

Me and rhapsodyv were able to heavily debug this together.

It seems that the issue is stemming from software endstops as can be evident from the M211 S0 command:

Send: M211 S0
Recv: echo:Soft endstops: OFF Min: X-18.00 Y-5.00 Z0.00 Max: X0.00 Y0.00 Z0.00
Recv: ok

For some reason, the maximum range set by software endstops is 0,0,0 which is forcing the printer to move to that position after homing.

Together, we tried to figure out what is overriding the max range, but were unable to figure this out yet.

@ellensp
Copy link
Contributor

ellensp commented Dec 6, 2020

Using the above information, after several false leads I have worked out the trigger.
Starting with default marlin Configs In bugfix. In Configuration_adv.h is

#define EXTENDED_CAPABILITIES_REPORT
#if ENABLED(EXTENDED_CAPABILITIES_REPORT)
  //#define M115_GEOMETRY_REPORT
#endif

Give the expected result. eg echo:Soft endstops: OFF Min: X0.00 Y0.00 Z0.00 Max: X200.00 Y200.00 Z200.00
If #define M115_GEOMETRY_REPORT is enabled
The result is random data, eg echo:Soft endstops: OFF Min: X0.00 Y0.00 Z0.00 Max: X0.00 Y2052.90 Z0.00

@ellensp
Copy link
Contributor

ellensp commented Dec 6, 2020

Commenting out the following in M115.cpp, seem to work. but need to check for side effects, what it was meant to do etc. and its to late for me here. Perhaps @rhapsodyv could test further

      apply_motion_limits(cmin);
      apply_motion_limits(cmax);

@coolcheat
Copy link
Author

I have confirmed that the issue is resolved when applying #20389 !

Thank you everyone for your time and effort!!

@github-actions
Copy link

github-actions bot commented Feb 5, 2021

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.

@github-actions github-actions bot locked and limited conversation to collaborators Feb 5, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants