[BUG] Octopus V1.1 CoreXY is now CoreYX with current bugfix-2.0.x

[Aurawin]

Did you test the latest bugfix-2.0.x code?

Yes, and the problem still exists.

Bug Description

After fetching today's bugfix-2.0.x from GitHub I've merged all changes to my fork local copy and find that the X/Y motors are switched.

When I move X the Y moves and visa versa, essentially making my Tronxy and TronYX :-(

I have confirmed the motherboard pins and stepper pins match in the core pin file for Octopus. The problem is either in my config or with something further along.

My Config defines that this is a CoreXY setup. #define COREXY

Bug Timeline

New bug

Expected behavior

When I move +10 on the X axis it should move the head 10 on the X axis. When I move +10 on the Y axis the head should move 10 on the Y axis.

Actual behavior

When I move +10 on the X axis the head moves 10 on the Y axis. When I move +10 on the Y axis the head moves 10 on the X axis.

Steps to Reproduce

No response

Version of Marlin Firmware

Bugfix-2.0.9.3

Printer model

Tronxy X5S

Electronics

BigTreeTech Octopus V1_1

Add-ons

BigTreeTech TFT3.5

Bed Leveling

ABL Bilinear mesh

Your Slicer

Cura

Host Software

SD Card (headless)

Additional information & file uploads

Bugfix-2.0.x

Confs.zip

[ellensp]

Bugfix is currently bugfix-2.0.9.3 not 2.0.9.2

[Aurawin]

I am in the process of rebuilding using tag 2.0.9.3. I'll solve out if needed.

[ellensp]

where are you stepper motors, front or back?

As core XY has front Left front stepper A on X and front right stepper B on Y, when looking from the front of the machine. But if stepper motors are at the back then A ie X is on the right most motor, when looking from the front of the machine.

This does not change from controller board to controller board

[Aurawin]

I tried to checkout tag 2.0.9.3 but that build failed, complaining about the Manual_Feedrate_MS. I can confirm, a fresh branch checkout tag 2.0.9.3 yielded this error using the configs attached but bugfix-2.0.x did not.

[Aurawin]

Motor 0 is X (Rear Right) and Motor 1 is Y (Rear Left) as with all previous builds/controllers I've had.

[ellensp]

You MUST use correct config files on the version of code you use. or you get the Manual_Feedrate_MS error https://github.com/MarlinFirmware/Marlin/issues/23656#issuecomment-1025441678

[Aurawin]

I'm not sure why bugfix-2.0.x would compile with these config files but 2.0.9.3 would not. Must be something actually wrong with that tag.

[Aurawin]

Wondering if the stepper motor pins get remapped somewhere down the line. I'm work-a-round this one and test G34 on the QUAD steppers to make sure they are not borked.

[ellensp]

X,Y,Z,Z2 never get remapped only E0, E1 etc depending on if you need E, X2, Z3 etc

[Aurawin]

Changing my CoreXY to a CoreYX does present a confirmed work-a-round using #define COREYX

[Aurawin]

A lot of work has been done to stepper.cpp and stepper.h. Perhaps a code cleanup was too agressive.

[ellensp]

I have just done some corexy testing on a old ramps and two a4988 stepper driver and stepper motors on X and Y Tests where done in absolute more (ie power on state)

    Gcode Command  | G1 X50                 | G1 X0                           | G1 Y50                     | G1 Y0                      |
| version | mode   | X(a)      | Y(b)       | X(a)           | Y(b)           | X(a)      | Y(b)           | X(a)           | Y(b)      |
| bugfix  | corexy | clockwise | clockwise  | anti clockwise | anti clockwise | clockwise | anti clockwise | anti clockwise | clockwise |
| 2.0.9.3 | corexy | clockwise | clockwise  | anti clockwise | anti clockwise | clockwise | anti clockwise | anti clockwise | clockwise |
| 2.0.8.2 | corexy | clockwise | clockwise  | anti clockwise | anti clockwise | clockwise | anti clockwise | anti clockwise | clockwise |
| 2.0.7.2 | corexy | clockwise | clockwise  | anti clockwise | anti clockwise | clockwise | anti clockwise | anti clockwise | clockwise |
| 2.0.6.1 | corexy | clockwise | clockwise  | anti clockwise | anti clockwise | clockwise | anti clockwise | anti clockwise | clockwise |
| 2.0.5.4 | corexy | clockwise | clockwise  | anti clockwise | anti clockwise | clockwise | anti clockwise | anti clockwise | clockwise |
| 2.0.4.4 | corexy | clockwise | clockwise  | anti clockwise | anti clockwise | clockwise | anti clockwise | anti clockwise | clockwise |
| 2.0.3.0 | corexy | clockwise | clockwise  | anti clockwise | anti clockwise | clockwise | anti clockwise | anti clockwise | clockwise |
| 2.0.0.0 | corexy | clockwise | clockwise  | anti clockwise | anti clockwise | clockwise | anti clockwise | anti clockwise | clockwise |
| 1.1.9   | corexy | clockwise | clockwise  | anti clockwise | anti clockwise | clockwise | anti clockwise | anti clockwise | clockwise |

Ie they have not swapped over (I have not checked if my steppers are going correct way or not, not needed for this test)

Clearly I did not try every version.. to many...

[Aurawin]

Thanks for looking at that @ellensp. Was there any changes to the pins of the Octopus? Or parent board that would necessitate a stepper pin re-direct in Octopus?

[Aurawin]

It should be noted that G34 appears to be affected by this issue. Since this is a quad z stepper setup the issue is compounded b/c the first guess is way wrong and totally messes up the alignment, even with CoreYX work-a-round.

[Aurawin]

After playing around with another firmware build I have discovered that CoreXY will manifest as CoreYX, if the kinematics are set to Cartesian. IMO, the flaw appears to be CoreXY = Cartesian instead of CoreXY.

I have since switched firmware platforms, so I will not be able to test any fixes.

Godspeed Marlin.

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