[BUG] Problem with scara homing

[RDS356]

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

Yes, and the problem still exists.

Bug Description

I configured the SCARA arm with all the correct parameters. So much so that, with the arms in the correct physical position and using the MANUAL_X_HOME_POS and MANUAL_Y_HOME_POS options, the movements are correct. But when I perform homing, it brings the arms to the correct side, activates the endstops, and saves the positions. However, after that, the movements become completely meaningless. As you can see in the video, I don't even move the X and Y axes; if I make any movement, whether Z or E, it starts moving the arms in a nonsensical direction.

Bug Timeline

First start.

Expected behavior

Que os movimentos continuem corretos após o homing.

Actual behavior

No response

Steps to Reproduce

1-install and configure scara.
2-homig.

Version of Marlin Firmware

m115 SENDING:M115 FIRMWARE_NAME:Marlin bugfix-2.1.x (May 21 2026 09:26:49) SOURCE_CODE_URL:github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:3D Printer KINEMATICS:SCARA EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff Cap:SERIAL_XON_XOFF:0 Cap:BINARY_FILE_TRANSFER:0 Cap:EEPROM:0 Cap:VOLUMETRIC:1 Cap:AUTOREPORT_POS:0 Cap:AUTOREPORT_TEMP:1 Cap:PROGRESS:0 Cap:PRINT_JOB:1 Cap:AUTOLEVEL:0 Cap:RUNOUT:0 Cap:Z_PROBE:0 Cap:LEVELING_DATA:0 Cap:BUILD_PERCENT:0 Cap:SOFTWARE_POWER:0 Cap:TOGGLE_LIGHTS:0 Cap:CASE_LIGHT_BRIGHTNESS:0 Cap:EMERGENCY_PARSER:0 Cap:HOST_ACTION_COMMANDS:0 Cap:PROMPT_SUPPORT:0 Cap:SDCARD:0 Cap:REPEAT:0 Cap:SD_WRITE:0 Cap:AUTOREPORT_SD_STATUS:0 Cap:LONG_FILENAME:0 Cap:LFN_WRITE:0 Cap:CUSTOM_FIRMWARE_UPLOAD:0 Cap:EXTENDED_M20:0 Cap:THERMAL_PROTECTION:0 Cap:MOTION_MODES:0 Cap:ARCS:1 Cap:BABYSTEPPING:0 Cap:EP_BABYSTEP:0 Cap:CHAMBER_TEMPERATURE:0 Cap:COOLER_TEMPERATURE:0 Cap:MEATPACK:0 Cap:CONFIG_EXPORT:0

Printer model

No response

Electronics

No response

LCD/Controller

No response

Other add-ons

No response

Bed Leveling

None

Your Slicer

None

Host Software

None

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

configs.zip

[RDS356]

Video moving before homing.

https://youtube.com/shorts/GcpKcY-T8Bg?si=h66BCY6nW_sAH4fN

[RDS356]

Video moving after homing.

https://youtube.com/shorts/othnEjhRu9o

[ellensp]

In XY space

#define X_HOME_DIR -1 (ie a low or negative value)
#define Y_HOME_DIR 1 (ie a high value)

with

#define MANUAL_X_HOME_POS 354 (this is not a low value)
#define MANUAL_Y_HOME_POS -13 (this is not a high value)

This does not make sense.

[RDS356]

In XY space

#define X_HOME_DIR -1 (ie a low or negative value) #define Y_HOME_DIR 1 (ie a high value)

with

#define MANUAL_X_HOME_POS 354 (this is not a low value) #define MANUAL_Y_HOME_POS -13 (this is not a high value)

This does not make sense.

This is a SCARA ARM, not cartesian.

#define X_HOME_DIR -1
#define Y_HOME_DIR 1
Direction of endStop.

#define MANUAL_X_HOME_POS 354
#define MANUAL_Y_HOME_POS -13
In this endstop positiion, the arms are: X distance of 354mm of X0 and Y-13 of Y0.

The offsets are 250 and -80 respectively.

At least that's how I understood it, and that's how it is in all the videos I've seen as well.

[RDS356]

I made another video, more complete and with subtitles.

https://youtu.be/GvqrmeKBSO8

[thinkyhead]

It could be that some kinematic stepper synchronization has been missed in the homing procedure. We should look for something like that. It should basically be in the same state after homing that it was at startup, with the exception of the blinking positions.

Whenever there are homing or leveling issues, we ask everyone to follow a standard procedure to gather more information so that we're not just taking stabs in the dark. Here is the boilerplate:

• Download Marlin bugfix-2.1.x to test with the latest code.
• Enable DEBUG_LEVELING_FEATURE and M114_DETAIL and re-flash the firmware.
• Connect to your printer from host software such as Cura, Printrun or Repetier Host.
• Send M502 and M500 to ensure your Configurations are applied.
• Issue the command M111 S247 to enable maximum logging.
• Check M114 D at startup and perform some movements to see how it changes.
• Perform a G28 to do your standard homing procedure.
• Check M114 D and then try some movements.
• Copy the log output into a .TXT file and attach it to your next reply.

Repeat this procedure, if needed, to demonstrate inconsistencies. From these logs we should hopefully get a better idea of what's going on with your machine.

[RDS356]

Hi.
I updated to the current version of the bugfix and some things changed after the homing;

• If moving through some host software the movements are correct, however if it is through the LCD menu, exactly what I already reported happens.
• The limits defined in #define X_MAX_POS and #define Y_MAX_POS are not respected.
  Tanks..

log_1.txt

[RDS356]

//startup

m114 d
SENDING:M114 D
X:354.00 Y:-13.00 Z:70.00 E:0.00 Count A:-622B:1940 Z:28000
SCARA Theta: -46.66 Psi: 145.54
Logical: X: 354.000 Y:-13.000 Z: 70.000
Raw: X: 354.000 Y:-13.000 Z: 70.000
SCARAK: X:-46.636 Y: 145.553 Z: 70.000
Stepper: X:-622 Y:1940 Z:28000 E:0
Degrees: X:-46.662 Y: 145.536
FromStp: X: 354.092 Y:-13.037 Z: 70.000 E: 0.000
Diff: X: 0.092 Y:-0.037 Z: 0.000 E: 0.000

g28xy
SENDING:G28XY
echo:busy: processing
SCARA Theta: -46.66 Psi: 145.54

m114 d
SENDING:M114 D
X:354.00 Y:-13.00 Z:70.00 E:0.00 Count A:-622B:1940 Z:28000
SCARA Theta: -46.66 Psi: 145.54
Logical: X: 354.000 Y:-13.000 Z: 70.000
Raw: X: 354.000 Y:-13.000 Z: 70.000
SCARAK: X:-46.636 Y: 145.553 Z: 70.000
Stepper: X:-622 Y:1940 Z:28000 E:0
Degrees: X:-46.662 Y: 145.536
FromStp: X: 354.092 Y:-13.037 Z: 70.000 E: 0.000
Diff: X: 0.092 Y:-0.037 Z: 0.000 E: 0.000

//After the G28XY, I moved the Z to 1 via the LCD menu. Then I resent the M114 D.

m114 d
SENDING:M114 D
X:0.00 Y:0.00 Z:0.00 E:0.00 Count A:1452B:1355 Z:0
SCARA Theta: 108.93 Psi: 101.65
Logical: X: 0.000 Y: 0.000 Z: 0.000
Raw: X: 0.000 Y: 0.000 Z: 0.000
SCARAK: X: 108.906 Y: 101.622 Z: 0.000
Stepper: X:1452 Y:1355 Z:0 E:0
Degrees: X: 108.927 Y: 101.650
FromStp: X: 0.024 Y:-0.185 Z: 0.000 E: 0.000
Diff: X: 0.024 Y:-0.185 Z: 0.000 E: 0.000

[RDS356]

Previously, to access the submenu "Motion-Move Axis-Move X, MoveY, etc." I changed line 224 of the file "\Marlin\src\lcd\menu\menu_motion.cpp" as shown below;

// Move submenu for each axis
if (NONE(NO_MOTION_BEFORE_HOMING) || motion.all_axes_homed()) {

[kellycris-rgb]

hello..
I'm following this thread because I encountered the same problem.
Any updates on this issue?

[RDS356]

hello.. I'm following this thread because I encountered the same problem. Any updates on this issue?

No, not yet.
After the G28, the marlin loses synchronization.

[DerAndere1]

In order to clip motion at the axis limits, enable and set these config options:
#define DEFAULT_ENDSTOPS_ALWAYS_ON
#define EVENT_GCODE_AFTER_HOMING "M211S1\nM120"

For good measure, add this to the start-G-code of your slicer:

G28
M211 S1
M120

You probably want to apply pull request 28388 (position sync when hardware endstops are hit)

If you want to abort prints when endstops are hit, you need to enable SD_ABORT_ON_ENDSTOP_HIT and/or apply these PRs:
2817 (Extend ABORT_ON_ENDSTOP_HIT to USB-printing)
24634 (Add option ABORT_ON_SOFTWARE_ENDSTOP)

Not sure how well this works with SCARA kinematics.