Dual X / Y breaks E0 motor direction

[CNCmarlin]

Bug Description

All motors function correctly except motor connected to E0 which only moves in one direction.

My Configurations

Configuration.zip
Configuration_adv.zip

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

Steps to Reproduce

1. [First Step]
   Configure marlin for dual x-axis and dual y-axis motor configuration.

2. [Second Step]
   flash configuration onto mks 1.4 turbo board

3. [and so on...]
   move each individual axis forward and backward

Expected behavior: [What you expect to happen]
each axis would move forward and backward

Actual behavior: [What actually happens]
each axis except the motor attached to the driver from E0 moves forward and backward, while E0 only moves in one direction.

Additional Information

in my configuration.h , I have zero extruders, I disabled min and max software endstops (I plan on using stall guard for endstops), and changed the steppers to my tmc2209. In configuration_adv.h I turned on dual x and y axis, enabled a few tmc debug and status options, and changed the voltage for my motors.

I also bought a new MKS 1.4_TURBO board and fixed none of my issues.

I have tried many things to find if this was hardware or software-related. I swapped motor wires from the E0 driver and E1 driver, the issue still affected the motor attached to the E0 driver. I swapped drivers similar to the motors wires and had the same issue the motor that was connected to E0 would only move in one direction.

Thanks for any and all help!

• Provide pictures or links to videos that clearly demonstrate the issue.
• See How Can I Contribute for additional guidelines.

[ellensp]

I think I have confirmed this is a bug.
I set INVERT_{X|Y}2_VS_{X|Y}_DIR false so that X and X2 , Y and Y2 should be in unison. I then connected LEDs to the enable step and direction lines of X,Y,X2,Y2
Then I ran some test gcode that just has lots of random XY moves.
Both sets of LEDs should be identical. they are not. X2(E0) direction line is one of the differences.
Short video
Edit: after working out what this was, it is not a bug. This is a pin conflict due to a Configuration error.

[CNCmarlin]

Thanks for your investigation! Is this something that can be fixed in the near future? Or is there more pressing issues to fix first?

[ellensp]

have patience, I've only just begun to look into this!
Next I checked out pin definitions, they all look fine.

PIN: 2.12        E0_ENABLE_PIN                          protected
.                X2_ENABLE_PIN                          protected
PIN: 0.10        E1_ENABLE_PIN                          protected
.                Y2_ENABLE_PIN                          protected
PIN: 2.13        E0_STEP_PIN                            protected
.                X2_STEP_PIN                            protected
PIN: 0.01        E1_STEP_PIN                            protected
.                Y2_STEP_PIN                            protected
PIN: 0.00        E1_DIR_PIN                             protected
.                Y2_DIR_PIN                             protected
PIN: 0.11        E0_DIR_PIN                             protected
.                X2_DIR_PIN                             protected

[ellensp]

The brightness of the LED I have on X2_DIR_PIN is not on or off, but something else. I suspect this pin is not getting initialized and is still in input mode.
If I remove the protected status from this pin, I can manual turn it on and off with a m42 P11 S0 or S255

[ellensp]

You have #define SERIAL_PORT 2 in Configuration.h
These are the hardware serial ports on a lpc1768/9

  Port  |  TX   |  RX   |
   ---  |  ---  |  ---  |
Serial  | P0_02 | P0_03 | 
Serial1 | P0_15 | P0_16 | 
Serial2 | P0_10 | P0_11 | 
Serial3 | P0_00 | P0_01 |

X2_DIR_PIN is P0_11, Ie Serial2 RX!!!
Y2_ENABLE_PIN is P0_10, Ie Serial2 TX!!!
This is in conflict.

[thinkyhead]

See if #16981 helps catch the issue. It checks for some conflicts at compile time.

[CNCmarlin]

Thanks for your help! I have been trying to figure this one out for weeks and you figure it out in less than a day!

I do have one last question for you, I would like to add the BTT TFT 35 3.0 screen to my build but it requires a serial... Which one would I want to use?

Thanks again for your hard work.

[CNCmarlin]

I have figured out my last question, I simply used serial 0 and everything is working as it should be for the BTT TFT 35. Before this last update, I was getting a lot of errors when trying to use serial 0. So thanks for your guy's continued work of this great piece of open source code!

[peterpan894]

Unfortunatly I still have the same problem on my SKR 1.4 Turbo board. I am uing latest firmware. I use the TMC5160 drivers.

It seems to be a firmware issue, the DIRE0 pin is always high, the connection to the LPC1769 is correct, no soldering problem. I also replaced the TMC5160 driver.

I only use
#define SERIAL_PORT -1

The serial 2 is deactivated
//#define SERIAL_PORT_2 1

Inside the pins_BTT_SKR_V1_4.h the configuration of E0 is correct (i assume..)

#define E0_STEP_PIN P2_13
#define E0_DIR_PIN P0_11
#define E0_ENABLE_PIN P2_12
#ifndef E0_CS_PIN
#define E0_CS_PIN P1_04
#endif

I use the E0 as dual Z, added

#define Z2_STEP_PIN P2_13
#define Z2_DIR_PIN P0_11
#define Z2_ENABLE_PIN P2_12
#ifndef Z2_CS_PIN
#define Z2_CS_PIN P1_04
#endif

It seems that the pin P0_11 is configured as input, the state is always high (3.3V), measured at the driver input. The M122 check does not show an error. The movement of the Z-Axis is correct but it moves only in one direction.

I checked the M43 command:
PIN: 0.11 E0_DIR_PIN protected
. Z2_DIR_PIN protected

I can toggle the pin with M43 T I LP0.9 W500
Pulsing PIN: 0.11 E0_DIR_PIN Output = 1
. Z2_DIR_PIN Output = 1
This puts the 0.11 pin to 0, measured at the driver input.

Here my configuration
configuration.zip

[boelle]

@CNCmarlin is the issue still there?

[boelle]

Lack of Activity
This issue is being closed due to lack of activity. If you have solved the
issue, please let us know how you solved it. If you haven't, please tell us
what else you've tried in the meantime, and possibly this issue will be
reopened.

[github-actions]

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.