[BUG] MANUAL_Y_HOME_POS inverts Y-axis and Y-axis sometimes moves with G0 X_ or G0 Z_ Command!

[keen101]

Bug Description

Basically i am modifying my Lulzbot Mini 1 to have a Prusa Mini Bed. I removed my bed leveling washers and as such decided to temporarily disable all bed levelling until i decide it is working well enough that i want to put in my new Einsy Rambo board and install a pinda probe. I needed to download the latest Marlin firmware to disable the bed levelling. Then i wanted to center the print area directly in the center of the new prusa mini build plate. I attempted to use MANUAL_X_HOME_POS and MANUAL_Y_HOME_POS to set the needed offsets to be exactly in the center. MANUAL_X_HOME_POS by itself worked fine. MANUAL_Y_HOME_POS at any value (positive or negative or zero) causes a weird bug to occur. Two things happen. The main issue is that my already inverted Y-axis is then inverted again and ignores the endstops and will crash because it is moving the wrong direction. The second issue is that sometimes when moving the x-axis or z-axis motors independently will now cause the Y-axis motor to move (although slow-ish and still in the wrong direction). Only the old Marlin 1.1.0.11 out of the ones i tested does not have the bug, however that is also the only version i have not been able to disable bed levelling on because of an error with the steppers.cpp file when i do. Marlin 1.1.9 and up (including the bugfix branch) all have the bug. It might be because i am the only person not using bed levelling in the whole world and as such perhaps i am the first to encounter this bug.

Describes your environment Include information about: • The Marlin version: 2.0 (also affects the development branch and 1.1.9) • Machine model and manufacturer: Lulzbot Mini 1 • Electronics board: Mini Rambo 1.1b • Host software: PopOS 19.10 (Ubuntu Linux) (not applicable) • Slicer: Lulzbot Cura 21.08 • Printing method: Testing through USB using the Lulzbot Cura "pronterface / gcode terminal” • Configuration.h files (in a ZIP file)

My Configurations

Required: Please include a ZIP file containing your Configuration.h and Configuration_adv.h files.

Steps to Reproduce

Steps to reproduce:

1. Obtain a printer with an inverted Y-axis, preferably a Lulzbot Mini, and preferably one with an older Rambo Mini mainboard.
2. Download Marlin 2.0.
3. Copy relevant configuration.h settings from Lulzbot Mini marlin source (http://download.lulzbot.com/Mini/1.04/software/firmware/Marlin_Mini_Source_v1.1.0.11_fb1929d.tar.gz)
4. disable auto bed levelling (if enabled)
5. compile and upload new firmware to Lulzbot Mini w/ Rambo Mini 1.1b
6. Test that all axis home correctly and endstops work.
7. Go back to Configuration.h and uncomment MANUAL_X_HOME_POS 0 and MANUAL_Y_HOME_POS 0. Feel free to leave them at 0. MANUAL_X_HOME_POS will have no problems by itself. But MANUAL_Y_HOME_POS will introduce at a minimum an inverted Y-axis and will ignore endstops. The Y-axis motor will also occasionally move slowly (in the wrong direction) when issuing manual X-axis and Z-axis command or when using the Lulzbot Cura 21.08 “pronterface” control panel.

Expected behavior: [What you expect to happen]

Expected behavior: Y-axis functions like normal before enabling MANUAL_Y_HOMEPOS. Only the X or Z axis should move when issuing a G0 X or G0 Z_ command.

Actual behavior: [What actually happens]

Enabling MANUAL_Y_HOME_POS causes the Y-Axis motor to get inverted and ignores endstops and goes the wrong way, which results in the y-axis stepper making grinding noises. In addition sometimes when only issuing a command to move only the x-axis or only the z-axis it will slowly move the Y-axis (still in the wrong direction) also resulting in grinding noises.

Additional Information

5. Attempted resolution: Tested this on Marlin 2.0.5.3, 1.1.9.1, and bugfix-2.0.x and all reproduce the bug.
6. Steps to work around (if any): The only version of marlin that I tested that does not have the bug is the original old version of marlin that ships with the original Lulzbot Mini (Marlin_Mini_Source_v1.1.0.11_fb1929d). Which is too old for me since I am testing a modification where I wanted to temporarily disable bed leveling, which is not possible in 1.1.0.11 because it creates an error in the steppers.cpp file.

Other relevant information: When having MANUAL_Y_HOME_POS enabled and the Y-axis is inverted. Changing #define INVERT_Y_DIR true to #define INVERT_Y_DIR false does indeed correct the Y-axis direction but breaks the Y homing function. Homing will then ignore the endstop because the Y-axis is moving the wrong way. Found the bug when attempting to flash custom marlin firmware on my Lulzbot-prusa mini hybrid (lulzbot mini frame with prusa mini heatbed and build plate) after removing the bed leveling washers and disabling the bed leveling features. Also while following this guide for bed centering https://www.youtube.com/watch?v=Dqt8cUtzOfs.

[keen101]

https://github.com/keen101/marlin-bug/blob/master/Marlin-configuration-files-andrew-bugreport.zip

[sjasonsmith]

I'm confused by the zip file you linked to. Are any of those configuration files configured to reproduce the bug? All the settings you mention seem to be commented out.

Can you post a zip file containing only the configuration files needed to reproduce the problem from the bugfix-2.0.x branch?

[keen101]

yes, let me know if this works now? I literally just tested this one again, it reproduces the bug so I'm not sure why you said those settings are commented out. But let me know if you have any other confusion.

https://github.com/keen101/marlin-bug/blob/master/Marlin-Bugfix-2.0.x.zip

[sjasonsmith]

You are probably right, I just overlooked things as I was bouncing between the files. Either way, it will be easier to understand with the simpler ZIP file.

[keen101]

ok, great. It's possible that one or more of the other files were saved in the "working" configuration. So it's possible i overlooked them when i zipped them up. Either way I'm happy for someone to be looking into it and seeing if someone else can reproduce my problem. I would love to help to track this down so someone can either fix it or tell me if i configured something wrong. Let me know if you need any more info or need me to test new code.

[AnHardt]

Slow moving of an unexpected axis is possible if you have any kind of SKEW_CORRECTION enabled. Please verify this is off.

[keen101]

Slow moving of an unexpected axis is possible if you have any kind of SKEW_CORRECTION enabled. Please verify this is off.

Unless it is enabled by default it should not be enabled as far as i know. I'm not sure why you couldn't look in the zip file i uploaded to look, but from what i can tell it says "//#define SKEW_CORRECTION" which should mean that it is not enabled? Correct? Or are there other settings that would enable skew_correction?

[keen101]

Does anyone have a lulzbot mini that can test this? Alternatively is there another way to configure bed centring adjustment?

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label / comment or this will be closed in 5 days.

[keen101]

Still need someone to double check my report. Still a bug as far as i know. Would love some help to confirm and/or solve this issue.

On Thu, Aug 6, 2020 at 7:22 PM github-actions[bot] notifications@github.com wrote:

This issue is stale because it has been open 30 days with no activity. Remove stale label / comment or this will be closed in 5 days.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/18479#issuecomment-670269843, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACXJTVGDLURS5F3LAPJAEDR7NJOHANCNFSM4OM36YNA .

[boelle]

just curious, are you using bugfix-2.0.x branch ?

[keen101]

Yes, last I tried I was.

On Sat, Aug 8, 2020, 9:57 AM Bo Herrmannsen notifications@github.com wrote:

just curious, are you using bugfix-2.0.x branch https://github.com/MarlinFirmware/Marlin/tree/bugfix-2.0.x ?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/18479#issuecomment-670944528, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACXJTTPCODKW5VFCA5TKVTR7VYWDANCNFSM4OM36YNA .

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label / comment or this will be closed in 5 days.

[keen101]

Hey Marcio, can you check out this marlin firmware? Can you tell me what is wrong in the code or whether it is repeatable on your lulzbot mini?

Josh West said you might be a handy person to contact.

https://github.com/marciot

@marciot

On Mon, Sep 7, 2020 at 7:28 PM github-actions[bot] notifications@github.com wrote:

This issue is stale because it has been open 30 days with no activity. Remove stale label / comment or this will be closed in 5 days.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/18479#issuecomment-688567116, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACXJTVF4UXZMBKOXX2D3VTSEWCDXANCNFSM4OM36YNA .

[marciot]

Hey Marcio, can you check out this marlin firmware? Can you tell me what is wrong in the code or whether it is repeatable on your lulzbot mini? Josh West said you might be a handy person to contact. https://github.com/marciot @marciot

My Mini printer has been heavily modified, with Trinamic drivers and changes to homing, etc. Probably not a good test case. But if you want, throw in Drunken Octopus Marlin on there and see if the problem persists:

https://github.com/drunken-octopus/drunken-octopus-marlin

[keen101]

Hey Marcio, can you check out this marlin firmware? Can you tell me what is wrong in the code or whether it is repeatable on your lulzbot mini? Josh West said you might be a handy person to contact. https://github.com/marciot @marciot

My Mini printer has been heavily modified, with Trinamic drivers and changes to homing, etc. Probably not a good test case. But if you want, throw in Drunken Octopus Marlin on there and see if the problem persists:

https://github.com/drunken-octopus/drunken-octopus-marlin

Thanks for the quick reply. I'll look into that. I have a new Rambo Einsy i got from Ultimaker that i plan to put in there with trinamic drivers at some point. But i was curious to get things working before i did that. I'm wondering if these weird issues are only present in a printer that has no bed leveling at all (like i currently do).

[keen101]

My Mini printer has been heavily modified, with Trinamic drivers and changes to homing, etc. Probably not a good test case. But if you want, throw in Drunken Octopus Marlin on there and see if the problem persists:

https://github.com/drunken-octopus/drunken-octopus-marlin

Hey Marcio, Your Drunken Octopus Marlin firmware works! I'm not sure why the main marlin does not, but you sir are my hero!

[marciot]

Hey Marcio, Your Drunken Octopus Marlin firmware works! I'm not sure why the main marlin does not, but you sir are my hero!

@keen101: I'm glad to hear! There aren't any differences in the source code per se that I think would account for this, so my guess is that you simply have some crucial difference in the config files.

A big part of what Drunken Octopus brings to the table is the auto-generation of config files for all the various LulzBot printers and variants. There's a lot of work that went into that to get around all the idiosyncrasies of the printers.

[github-actions[bot]]

This issue has had no activity in the last 30 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 7 days.

[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.