MPScara G92 and machine coordinate issues

Hello all,

I have been working on a custom scara with a funky drive train, but it functions like a standard MPScara with a belt driven distal arm.

After trying a lot to make Marlin work and it vehemently refusing to do so, I switched to RRF and DWC with the SKR 3 EZ. The motion works fine when commanding moves, but after trying to fine tune the M669 code in the config to be correct per the days of forum searching, now the machine absolutely refuses to use a XY of 0 or move due to it.

Adding G92 in the homeall file or commanding it in console does nothing. Z works perfect, Y does weird arbitrary non-zero numbers, and X never changes below 1100mm.

The attached files show the SolidWorks math to derive the M669 values for min/max angles at home (highlighted blue. Max distal angle is also the 130.9~ since it is mirrored). Other files show the position at boot up which is the same if I home it. And then images of G92 Y0 done twice with an M114 to show the lack of changing X, with the Y changing with each use of the command with one case being ~0.032 or similar.

Of note, if I run a G10 L20 command, it correctly sets the tool position to 0,0,0, but with the machine position still wrong, no motion is allowed.

I'm at my wits end at this point. Because it won't set 0,0 correctly, I can't command any G0/G1 moves since it calls an out of machine limits error, but it will home correctly every time physically. Per the config.g, the volume is 0:635 x 0:635 with the home and 0,0 at the bottom left corner. I will never understand why both Marlin and RRF can make scara so complex, such as Marlin requiring the bed 0 at center and the homing to somewhere far away from said center, but I digress.

With the config.g, the steps/degree are all calculated from the 3d model as is all else. Please let me know what is either wrong with the config or wrong with something because it is currently impossible to even try and make it draw a line. If any files or images need to be provided, I certainly can.

I hope to do a Morgan Scara after this, but the nightmare of just getting the firmware side working is a large put off due to the severe lack of documentation on both sides of the major firmwares.

Yeah, there definitely is a lack of easy-to-use firmware for SCARA. There are too many variations in arm design so it's difficult to make a one-size-fits-all without the configuration becoming the confusing part I have a working SCARA printer running Marlin, but it required a fair amount of modification. You can search through some of my posts in this section from a few years ago helping other people with it. It would take some time to get back familiarized with it, and I haven't checked if the main branch has been changed in the intervening years so the necessary modifications could be different now. And I'm not really familiar with RRF at all.

So both of your motors are stationary like MPSCARA, and the elbow motor has one belt to an intermediate pulley and another to the elbow? And the intermediate pulley has the same number of teeth for both belts? That results in the elbow angular coordinate being relative to the global X axis, since moving the shoulder motor does not change the distal arm's angle relative to global X axis. If the elbow motor rides on the proximal arm (regardless of whether it directly drives the elbow or uses a belt), then the elbow angular coordinate is relative to the proximal arm, and the forward/inverse kinematic math is different. Or if (like mine) the intermediate pulley serves as an additional reduction stage, then it's even more complicated.

There are also multiple ways to approach homing: specify a home XY and use inverse kinematics to calculate the corresponding angles, or specify home angles and use forward kinematics to calculate the home XY. Or in my case I specify the shoulder angle, and calculate the elbow angle from the measured distance between shoulder axis and nozzle. Ultimately you just need the arm physical position, angular coordinates, and cartesian coordinates to all match up with eachother.

Thank you for the response, dekutree.

As far as I've read with marlin, they've essentially given up on support for scara since a late 1.x build and 2.x doesn't even support polar at all. I've seen several instances of people having custom 2.x firmware just to make it work, and I did try those changes too to no avail.

Attached is a picture of the SW model in home position with the blue highlights being the Proximal gear (7:1 reduction) and the distal pulleys (final 7:1) reduction. The Z runs along both joints with a pass through at the distal, but is negligible at this point in time. The config.g was made to have the M669 parameters for the angles have the first numbers at min (home switches: 0,0) and max, the opposite x coordinate of the build volume (0,635mm). A video shows that the machine homes fine per the homall.g file, but as the issue shows, the coordinates only show out of bounds numbers.

A strange part that caused me to even try duet as well was the SKR 3 refused to communicate with the TFT35 V3, but the screen works with a SKR mini E3. That is a separate issue though.

With the attached files, hopefully this can help towards solving the firmware/DWC issue since the machine will move fairly well on its own when allowed to.

Have you tried simply disabling the bounds checking?

It looks like the Marlin code is still mostly the same as what I started with. A few changes, but scara_set_axis_is_at_home is still nonsense, doing inverse kinematics on those SCARA_OFFSET_THETA values. The original MPSCARA used an XY home position but didn't do IK so the angle values were wrong, then the 2021Feb17 update changed it to use home angles and probably worked, and then 2021Mar4 update broke it and has remained unchanged since.

But the Marlin source code is truly a nightmare of preprocessor options scattered in every file, so I don't necessarily recommend using it.

I'd like to see some more screenshots of your CAD model zoomed out and from different angles. So the motherboard rides on the proximal arm, but the shoulder and elbow motors are on the base? And shoulder motor uses a pinion to turn that large gear, while elbow motor uses a worm gear reduction to turn the small pulley above the large gear, with belt running to equal toothed pulley on the elbow? I think that will result in the same kinematic behavior as MPSCARA, where the elbow motor position is relative to the global X axis, with no interference from the shoulder movement. The video looks like the distal arm does rotate some as the shoulder moves, but it may just be a trick of the perspective.

Edited 3 time(s). Last edit at 02/06/2026 08:44PM by dekutree64.

After booting up the scara and testing RRF's M564 command which can disable boundary checks, it still errors and says out of bounds with trying to move X or Y via the DWC's move buttons, not terminal.

The first two images are of the SW model from top down in home position with the radii and print volume shown. These are the min angles set with M669 in the config.g for RRF. Also, the drive is purely spur gears and belt drive. This is meant to copy the MPScara with the x/y motors on the fixed axis, then driving the joints. The crown gears are resin printed due to accuracy needed that fdm couldn't meet with a 0.4 nozzle.

The first 'capture' image shows DWC with the machine homed, then setting the machine to ignore limits and if it was homed, but it still errors out boundaries. The second 'capture' shows the same, but also with trying both G0 and G1 commands via its terminal. They show successful, but no motion occurs whatsoever, along with G92 still not working at all.

One problem with trying to go back to Marlin for this is that the older versions did not yet support the SKR 3 EZ. And I did try that with a custom firmware a random forum user had, but it was seemingly impossible to add the new board to it even when copying files.

At this point, I am stuck with RRF 3.5/3.6 until further notice since it is the only thing that has had correct kinematics so far. If worst comes to worst, it will have to be torn down to make a Tpara which a modified marlin firmware does support, as does RRF.

Also, a side note, the distal arm does move slightly during homing due to the pulley at the shoulder remaining static since the homing is one joint at a time, not together.

Crown gears! That's what I was missing. And I didn't notice the other sideways-mounted arm motor peek into frame in the video. But then what's the large gear/pulley looking thing outside the gearbox?

You can use the latest Marlin. It just needs a few fixes. Here's the thread where I explained what to do: [reprap.org]

Your arm is right-handed, so swap the ACOS signs as described.

A couple of corrections:
1. SCARA_FEEDRATE_SCALING should be disabled. My eyes were not fooling me, and the cartesian speed really was faster with elbow bent and slower with it straight, i.e. overcorrected. I remember combing through the code trying to understand why, and ultimately giving up and just accepting that it works properly with feedrate scaling disabled.
2. SCARA_OFFSET_THETA1 and 2 specify the home position as angles. Since scara_set_axis_is_at_home is broken as is, you can either fix it to use cartesian home or angle home.
Cartesian: Set current_position[axis] = base_home_pos[axis]; and then call inverse_kinematics to update the angular position delta.a and b.
Angles: Set delta.a and b to the theta #defines, call forward_kinematics, and then set current_position[axis] = cartes[axis];

Well, I went and tried the old version of Marlin I tried to use the first time with this machine which is 2.1.2.5. Per your five year old post, Deku, I was able to get most changes made and somehow the firmware decided to communicate with the tft correctly without refusing to work at all.

As it stands, the machine when booted shows center of the bed at (317, 317, 0) and not 0,0 even with the bed center set to 0,0. Either way, minor at this moment. However, like with RRF, there is homing issues. I can move each direction, but feedrate changes make no difference whatsoever. That, and for whatever reason commanding +X goes towards the shoulder in -Y direction, and +Y goes +X despite the motors turning the same direction as was set in RRF's config.g file from a previous post. The machine seems to move with both joints together, but even at 100,000 feedrate, it goes at around 1/2°/s.

Attached is the entire firmware, split in two due to the forum's size limit along with a picture to show the section view of the machine's base which is 3 concentric shafts and far too many bearings. X is a spur to spur connection, Y and Z are spur to crown gear connections leading to belts for their joints respectively. If this stupid thing ever works right, I planned to post it to grabcad and printables, though that may never happen at this rate due to firmware.

The firmware is messy due to trying to disable the Z axis to no avail for testing. Right now, if I tell it to home via the tft, individual X/Y homes do nothing, Z works, but home all just runs the Z axis some and calls the kill() command whether the Z switch is always open, always closed, or messed with by hand.

This puts me around the same spot as before, but back to Marlin which I feel is much more open to customization, even if formulas and definitions are scattered about too many different files.

After a look through your source code, the main problem is your scara_set_axis_is_at_home is still broken. Try this:

  void scara_set_axis_is_at_home(const AxisEnum axis) {
    if (axis == Z_AXIS)
      current_position.z = Z_HOME_POS;
    else {
      delta.a = SCARA_OFFSET_THETA1 - scara_home_offset.a;
      delta.b = SCARA_OFFSET_THETA2 - scara_home_offset.a - scara_home_offset.b;
      forward_kinematics(delta.a, delta.b);
      current_position[axis] = cartes[axis];

      //DEBUG_ECHOLNPGM("homeposition A:", delta.a, " B:", delta.b);
      //DEBUG_ECHOLNPGM_P(PSTR("Cartesian X"), current_position.x, SP_Y_LBL, current_position.y);
      update_software_endstops(axis);
    }
  }

The scara_home_offset values are set with M665, so you can tweak the home angles on the fly. Very useful when you get to calibrating. Shoulder doesn't really matter since any error just rotates the whole coordinate system (lines won't be perfectly square to the edges of the bed, but will be consistent among themselves), but elbow needs to be very accurate or straight lines will come out curved. The arm segment lengths also need to be ridiculously precise, like within 0.1mm. I never added dynamic adjustment of them for mine, but I should have Recompiling and uploading the firmware for every change is extremely tedious.

You also still have QUICK_HOME enabled in Conditionals_post.h, although that may be ok in your case. Mine uses sensorless homing with the elbow in fully bent position, and needs the shoulder to already be in home position when the elbow hits its limit. If you do need sequential homing with elbow motor disabled during shoulder movement, the edit in G28.cpp described in the old thread goes on line 464 in yours, not 356 like the version I started from.

You do not need to edit Conditionals_LCD.h. The SCARA block in it has been moved down toward the bottom and already checks for MP_SCARA.

You'll most likely find yourself wishing for more resolution. Mine has 284.444 steps per degree with 140mm arm segments (280mm total), and still not great print quality. Granted it is using 32 microsteps, which may not have any real benefit over the more common 16. If you're not using 0.9° steppers, they really help.

EDIT: I do vaguely remember something calling kill() when homing Z, now that I think about it. I'll update this if I can figure out what it was and how I fixed it.
EDIT2: Got it! It's in Motion.cpp, first thing in function homeaxis. It just checks for SCARA and kills itself. Remove that and it works.

Edited 2 time(s). Last edit at 02/08/2026 01:34AM by dekutree64.

Got around to making that change, now it is worse(?). It homes Z correctly now by going until the switch is triggered by hand and does the bump distance etc. However, now XY does absolutely nothing. Home buttons on the TFT are as follows: Home all: Z homes but xy motors don't even enable to try. X home, same thing. Y home does literally nothing. Z home works fine. Used M119 several times and ensured the switches were open before homing, so it isn't them declaring it has hit home when it hasn't.

When using the move screen, all motion is still horrifically slow and ignores any eeprom feedrate/accel settings. However, when using the tft's terminal, G28 does nothing but display the current coords (still 317, 317, 0 on boot) along with theta and psi which does change if it is moved to say 307, 307. Also, upon using G1 X10 F500, it moves at a reasonable pace like it should, but the arms tried to go straight out and I had to cut the power to avoid a crash. This happened with RRF too where any G1 commands (when it was working) would make the arms seemingly try to swing forever and not either 1mm or 1°. I checked in the firmware that all instances of Quickhome were indeed disabled. adv_h is disabled, scara.cpp only references it with Tpara. conditionals_post has it disabled (line 295) while leaving all else in that if else statement. G28.cpp was untouched. Attached is a picture of right after boot up, going to tft terminal and typing G28 with nothing else. Z homes and nothing else moves after. Should note the tft move commands do seem to do ~10mm like commanded, but again the feedrate ignores eeprom settings entirely.

As for the accuracy thing, I agree this will likely be trash for precision. but this was only made to test the concept for something bigger with plasma. With a 10:1 cycloidal or decent planetary attached to the motors, it would help a whole lot since speed isn't hyper critical. Really, it just proves true servos and gearboxes are the only way to go since the industrial sector proves they are vastly better than steppers and are actually cheap if you look at the right places. Of course, most hobbyist in this printing world will argue over a $2 stepper vs. a $3 stepper and shame the $3 job, but I digress. Also, I know the model doesn't do the size justice, but the steppers are 1.8° Nema 34's I got for stupid cheap one time with 6 wires for unipolor/bipolar and 1,000 RPM capable with worthless torque (~180 oz-in holding with bipolar).

Don't worry about the slow movement. Until you're reasonably certain that it's been homed properly, bad movement is usually not worth the effort to try and interpret the cause of.

The mystery is why it won't even try to home X and Y. You might have to add some debug printing in G28.cpp to see what it's thinking (particularly whether doX and doY ever get set true). One difference from my version is the added checks for HAS_Y_AXIS. If they've changed it so SCARA only has rotary axes A and B rather than linear axes X and Y, maybe that could be why the normal homing procedure doesn't work. See if you can check its value, like

#if !HAS_Y_AXIS
#error "No Y axis"
#endif

Enabling DEBUG_LEVELING_FEATURE in config.h (line 1987) and then M111 S32 per the comment in the config, I did two tests shown below with G28 and G28 A B. From what I read, it seems to do the Z probing fine, but every XY move seems to just command its current coords, in this case 317, 317.

Adding the above code under line 206 in G28.cpp, I did not see any new output in the console when using g28 after the reboot, so I may have placed it wrong in the code or something else. I truly thank you for putting up with this troubleshooting. I'm not the best with coding in general, but with good instruction and many years of the internet's forums of information, I can make basic things. But so far, the debug only seems to point to the XY or AB doing nothing because it seemingly keeps telling it to move to where it already is, or is not calling a >>>homeaxis(X/Y) command in the console. Also, per the G28 file, it comments that cartesian/SCARA parameters are XYZ to their endstops. At least here, it does not mention AB axes.

Connecting...
Printer is now online.
>>> m111 s32
SENDING:M111 S32
echoEBUGETAIL
>>> G28
SENDING:G28
>>> G28  X317.00 Y317.00 Z0.00
Machine Type: SCARA
Probe: NOZZLE_AS_PROBE
Probe Offset X0 Y0 Z0.00 (Same Z as Nozzle)
Auto Bed Leveling: BILINEAR (disabled)
>>> set_bed_leveling_enabled  X317.00 Y317.00 Z0.00
<<< set_bed_leveling_enabled  X317.00 Y317.00 Z0.00
Raise Z before homing:
do_blocking_move_to_z(5.00, 4.00)
>>> do_blocking_move_to  X317.00 Y317.00 Z0.00
>  X317.00 Y317.00 Z5.00
  destination= X317.00 Y317.00 Z5.00 : prepare_fast_move_to_destination
  destination= X317.00 Y317.00 Z5.00 : prepare_fast_move_to_destination
<<< do_blocking_move_to  X317.00 Y317.00 Z5.00
>>> homeaxis(Z)
  current_position= X317.00 Y317.00 Z5.00 : Probe::set_deployed
deploy: 1
Probe::do_z_raise(10.00)
do_blocking_move_to_z(10.00, 4.00)
>>> do_blocking_move_to  X317.00 Y317.00 Z5.00
>  X317.00 Y317.00 Z10.00
  destination= X317.00 Y317.00 Z10.00 : prepare_fast_move_to_destination
  destination= X317.00 Y317.00 Z10.00 : prepare_fast_move_to_destination
echo:busy: processing
<<< do_blocking_move_to  X317.00 Y317.00 Z10.00
>>> do_blocking_move_to  X317.00 Y317.00 Z10.00
>  X317.00 Y317.00 Z10.00
  destination= X317.00 Y317.00 Z10.00 : prepare_fast_move_to_destination
<<< do_blocking_move_to  X317.00 Y317.00 Z10.00
Home Fast: -42.00mm
>>> do_homing_move  X317.00 Y317.00 Z10.00
...(Z, -42.00, [4.00])
  current_position= X317.00 Y317.00 Z0.00 : sync_plan_position
<<< do_homing_move  X317.00 Y317.00 Z-42.00
Move Away: 5.00mm
>>> do_homing_move  X317.00 Y317.00 Z-42.00
...(Z, 5.00, 4.00)
  current_position= X317.00 Y317.00 Z0.00 : sync_plan_position
echo:busy: processing
<<< do_homing_move  X317.00 Y317.00 Z5.00
Re-bump: -10.00mm
>>> do_homing_move  X317.00 Y317.00 Z5.00
...(Z, -10.00, 2.00)
  current_position= X317.00 Y317.00 Z0.00 : sync_plan_position
<<< do_homing_move  X317.00 Y317.00 Z-10.00
>>> set_axis_is_at_home(Z)
*** Z HOMED WITH PROBE (Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN) ***
> probe.offset.z = 0.00
  current_position= X317.00 Y317.00 Z0.00 :
<<< set_axis_is_at_home(Z)
  current_position= X317.00 Y317.00 Z0.00 : sync_plan_position
  current_position= X317.00 Y317.00 Z0.00 : Probe::set_deployed
deploy: 0
>>> do_blocking_move_to  X317.00 Y317.00 Z0.00
>  X317.00 Y317.00 Z0.00
  destination= X317.00 Y317.00 Z0.00 : prepare_fast_move_to_destination
<<< do_blocking_move_to  X317.00 Y317.00 Z0.00
<<< homeaxis(Z)
>>> move_z_after_homing  X317.00 Y317.00 Z0.00
>>> move_z_after_probing  X317.00 Y317.00 Z0.00
<<< move_z_after_probing  X317.00 Y317.00 Z0.00
<<< move_z_after_homing  X317.00 Y317.00 Z0.00
  current_position= X317.00 Y317.00 Z0.00 : sync_plan_position
SCARA Theta:-13.17  Psi:103.17
<<< G28  X317.00 Y317.00 Z0.00

>>> G28 A B
SENDING:G28 A B
>>> G28  X317.00 Y317.00 Z0.00
Machine Type: SCARA
Probe: NOZZLE_AS_PROBE
Probe Offset X0 Y0 Z0.00 (Same Z as Nozzle)
Auto Bed Leveling: BILINEAR (disabled)
>>> set_bed_leveling_enabled  X317.00 Y317.00 Z0.00
<<< set_bed_leveling_enabled  X317.00 Y317.00 Z0.00
Raise Z before homing:
do_blocking_move_to_z(5.00, 4.00)
>>> do_blocking_move_to  X317.00 Y317.00 Z0.00
>  X317.00 Y317.00 Z5.00
  destination= X317.00 Y317.00 Z5.00 : prepare_fast_move_to_destination
  destination= X317.00 Y317.00 Z5.00 : prepare_fast_move_to_destination
<<< do_blocking_move_to  X317.00 Y317.00 Z5.00
>>> homeaxis(Z)
  current_position= X317.00 Y317.00 Z5.00 : Probe::set_deployed
deploy: 1
Probe::do_z_raise(10.00)
do_blocking_move_to_z(10.00, 4.00)
>>> do_blocking_move_to  X317.00 Y317.00 Z5.00
>  X317.00 Y317.00 Z10.00
  destination= X317.00 Y317.00 Z10.00 : prepare_fast_move_to_destination
  destination= X317.00 Y317.00 Z10.00 : prepare_fast_move_to_destination
echo:busy: processing
<<< do_blocking_move_to  X317.00 Y317.00 Z10.00
>>> do_blocking_move_to  X317.00 Y317.00 Z10.00
>  X317.00 Y317.00 Z10.00
  destination= X317.00 Y317.00 Z10.00 : prepare_fast_move_to_destination
<<< do_blocking_move_to  X317.00 Y317.00 Z10.00
Home Fast: -42.00mm
>>> do_homing_move  X317.00 Y317.00 Z10.00
...(Z, -42.00, [4.00])
  current_position= X317.00 Y317.00 Z0.00 : sync_plan_position
<<< do_homing_move  X317.00 Y317.00 Z-42.00
Move Away: 5.00mm
>>> do_homing_move  X317.00 Y317.00 Z-42.00
...(Z, 5.00, 4.00)
  current_position= X317.00 Y317.00 Z0.00 : sync_plan_position
echo:busy: processing
<<< do_homing_move  X317.00 Y317.00 Z5.00
Re-bump: -10.00mm
>>> do_homing_move  X317.00 Y317.00 Z5.00
...(Z, -10.00, 2.00)
  current_position= X317.00 Y317.00 Z0.00 : sync_plan_position
echo:busy: processing
echo:busy: processing
echo:Homing Failed
Errorrinter halted. kill() called!
[ERROR] Errorrinter halted. kill() called!

That code snippet would have given a compile error nomatter where you put it, so that confirms it is using XY, not AB.

QUICKHOME may still be getting enabled somewhere. Your printout shows a bunch of calls to do_blocking_move_to (which is called by quick_home_xy), whereas homeaxis should only call do_homing_move. Again, you can check it by pasting this anywhere and see if it gives a compile error

#if ENABLED(QUICK_HOME)
#error "Dang it, who's still enabling quickhome"
#endif

Looking more closely at your Configuration.h, it needs some editing to match your image Untitled74584514146949.png from a few posts ago. As explained in that old thread, angle 0 points along positive X and positive angles rotate counterclockwise from there, so SCARA_OFFSET_THETA1 should be (90-1.287) and THETA2 should be (90+130.976). SCARA_OFFSET_X and Y are the location of the shoulder joint relative to bed 0, so should be negative from your current values (X should be 317.5, Y should be -153.4758618). And comment out BED_CENTER_AT_0_0, since those offset values are for 0 at bottom left. I've always used center 0 on mine and we could adjust them for that, but I think either way should work, and since your home angles put the end effector at the lower left corner of the bed, it's nice to have that be 0,0 rather than -317.5,-317.5. Mine's home position has the end effector outside the bed, so it's no less elegant to put 0 at center. You may also need to set MANUAL_X_HOME_POS (and Y) to 0, but I don't think they'll be used either way.

Added the change to the G28 debug and it compiled fine again. This time upon boot, XYZ show 0.00. M114 shows 0 across the board for X,Y,Z, Count A,B and Z. Attached is a video of G28 from pronterface. I have to click the Z endstop manually, but otherwise that is the only input from me. The top GT2 belt moves for Z, but after it is done with that axis, the HTD3M belt below does not move nor the main arm, thus yet again XY makes no attempt to home nor do their motors turn on.

Bed at center and manual XY home pos were all commented out. Made scara_offset X +317.5 and Y -153 with decimals. Theta is shown as below. If it needs to be hard numbers without the math, I can do so. As I see in the homing, along with it not attempting XY, the theta and psi also now show 0.

Of note, though it may be wholly irrelevant, upon boot the tft shows unknown commands for M555 P2 and M82. These may be some weird remnant from the RRF firmware, but it doesn't seem to affect anything.

    #define SCARA_OFFSET_THETA1  90 - 1.287 // degrees
    #define SCARA_OFFSET_THETA2 90 + 130.976 // degrees

G28:

void GcodeSuite::G28() {
  DEBUG_SECTION(log_G28, "G28", DEBUGGING(LEVELING));
  if (DEBUGGING(LEVELING)) log_machine_info();
    #if !HAS_Y_AXIS
      #error "No Y axis"
     #endif
    #if ENABLED(QUICK_HOME)
     #error "Dang it, who's still enabling quickhome"
    #endif

G28 M111 S32 output:

>>> m111 s32
SENDING:M111 S32
echoEBUGETAIL
>>> g28
SENDING:G28
>>> G28  X0.00 Y0.00 Z0.00
Machine Type: SCARA
Probe: NOZZLE_AS_PROBE
Probe Offset X0 Y0 Z0.00 (Same Z as Nozzle)
Auto Bed Leveling: BILINEAR (disabled)
>>> set_bed_leveling_enabled  X0.00 Y0.00 Z0.00
<<< set_bed_leveling_enabled  X0.00 Y0.00 Z0.00
Raise Z before homing:
do_blocking_move_to_z(5.00, 4.00)
>>> do_blocking_move_to  X0.00 Y0.00 Z0.00
>  X0.00 Y0.00 Z5.00
  destination= X0.00 Y0.00 Z5.00 : prepare_fast_move_to_destination
  destination= X0.00 Y0.00 Z5.00 : prepare_fast_move_to_destination
<<< do_blocking_move_to  X0.00 Y0.00 Z5.00
>>> homeaxis(Z)
  current_position= X0.00 Y0.00 Z5.00 : Probe::set_deployed
deploy: 1
Probe::do_z_raise(10.00)
do_blocking_move_to_z(10.00, 4.00)
>>> do_blocking_move_to  X0.00 Y0.00 Z5.00
>  X0.00 Y0.00 Z10.00
  destination= X0.00 Y0.00 Z10.00 : prepare_fast_move_to_destination
  destination= X0.00 Y0.00 Z10.00 : prepare_fast_move_to_destination
echo:busy: processing
<<< do_blocking_move_to  X0.00 Y0.00 Z10.00
>>> do_blocking_move_to  X0.00 Y0.00 Z10.00
>  X0.00 Y0.00 Z10.00
  destination= X0.00 Y0.00 Z10.00 : prepare_fast_move_to_destination
<<< do_blocking_move_to  X0.00 Y0.00 Z10.00
Home Fast: -42.00mm
>>> do_homing_move  X0.00 Y0.00 Z10.00
...(Z, -42.00, [4.00])
  current_position= X0.00 Y0.00 Z0.00 : sync_plan_position
echo:busy: processing
echo:busy: processing
<<< do_homing_move  X0.00 Y0.00 Z-42.00
Move Away: 5.00mm
>>> do_homing_move  X0.00 Y0.00 Z-42.00
...(Z, 5.00, 4.00)
  current_position= X0.00 Y0.00 Z0.00 : sync_plan_position
<<< do_homing_move  X0.00 Y0.00 Z5.00
Re-bump: -10.00mm
>>> do_homing_move  X0.00 Y0.00 Z5.00
...(Z, -10.00, 2.00)
  current_position= X0.00 Y0.00 Z0.00 : sync_plan_position
echo:busy: processing
<<< do_homing_move  X0.00 Y0.00 Z-10.00
>>> set_axis_is_at_home(Z)
*** Z HOMED WITH PROBE (Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN) ***
> probe.offset.z = 0.00
  current_position= X0.00 Y0.00 Z0.00 :
<<< set_axis_is_at_home(Z)
  current_position= X0.00 Y0.00 Z0.00 : sync_plan_position
  current_position= X0.00 Y0.00 Z0.00 : Probe::set_deployed
deploy: 0
>>> do_blocking_move_to  X0.00 Y0.00 Z0.00
>  X0.00 Y0.00 Z0.00
  destination= X0.00 Y0.00 Z0.00 : prepare_fast_move_to_destination
<<< do_blocking_move_to  X0.00 Y0.00 Z0.00
<<< homeaxis(Z)
>>> move_z_after_homing  X0.00 Y0.00 Z0.00
>>> move_z_after_probing  X0.00 Y0.00 Z0.00
<<< move_z_after_probing  X0.00 Y0.00 Z0.00
<<< move_z_after_homing  X0.00 Y0.00 Z0.00
  current_position= X0.00 Y0.00 Z0.00 : sync_plan_position
SCARA Theta:0.00  Psi:0.00
<<< G28  X0.00 Y0.00 Z0.00

We have several users running Scara machines successfully with RepRapFirmware. I have one myself. Have you asked for help on the Duet3D forum? If so, please provide a link to the forum thread.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Hello dc42,

Yes, it is on the Duet3D forum, though with it being firmware/DWC, I wasn't sure which board to put it on, so it is under DWC:
[forum.duet3d.com]

The information posted there should be identical to the initial post as on this thread.

I am open to either RRF or Marlin, just which ever will work to move the SCARA correctly and allow for laser control with a Z axis.

Edited 1 time(s). Last edit at 02/12/2026 05:01AM by Chip Bark.

Math in the theta #defines is fine. In general you should wrap such expressions in parentheses since you can get unexpected interactions with surrounding math when the preprocessor copy/pastes it into the code, but the way these are used it doesn't matter.

So we're confirmed not using quickhome now. I guess the calls to do_blocking_move_to are coming from the planner after do_homing_move calls planner.buffer_segment.

I still don't see why it would skip X and Y, although the axes_should_home function is rather difficult to read.

Try pasting this at line 400 of G28.cpp after all the bool variables are declared so we can get a better idea what it's thinking (if sprintf is undefined, include stdio.h up at the top of the file)

    char str[256];
    sprintf(str, "needX %i, homeX %i, doX %i, trusted %i, homed %i, should %i",
        needX, homeX, doX, axis_is_trusted(X), axis_was_homed(X), axis_should_home(X));
    DEBUG_ECHOLNPGM(str);

You could also try sending

G28 X Y Z

since lines 383 and 384 look like that will force homing X and Y even if it doesn't think they need it for whatever reason.

Deku,

Placed the change here since line 400 is at the end of the bools, but within the parenthesis. If this needs to be moved, let me know. It had no issue compiling as is.

Troubleshooting like this makes me wish there was dedicated forks of firmware specific to a motion style with fine tuned motion planning just for itself, but at the same time, that has its own issues.

 ),
               home_all = NUM_AXIS_GANG(   // Home-all if all or none are flagged
                    homeX == homeX, && homeY == homeX, && homeZ == homeX,
                 && homeI == homeX, && homeJ == homeX, && homeK == homeX,
                 && homeU == homeX, && homeV == homeX, && homeW == homeX
                 char str[256];
                sprintf(str, "needX %i, homeX %i, doX %i, trusted %i, homed %i, should %i",
                  needX, homeX, doX, axis_is_trusted(X), axis_was_homed(X), axis_should_home(X));
                DEBUG_ECHOLNPGM(str);
               ),
               NUM_AXIS_LIST(
                 doX = home_all || homeX, doY = home_all || homeY, doZ = home_all || homeZ,
                 doI = home_all || homeI, doJ = home_all || homeJ, doK = home_all || homeK,
                 doU = home_all || homeU, doV = home_all || homeV, doW = home_all || homeW
               );

Outside of that, the below is fresh boot and running M111 S32 like before, then G28. Cleared the console and ran G28 X Y Z. Both times, Z homes like normal only for XY to not try or enable their motors.

Connecting...
Printer is now online.
>>> m111 S32
SENDING:M111 S32
echoEBUGETAIL
>>> G28
SENDING:G28
>>> G28  X0.00 Y0.00 Z0.00
Machine Type: SCARA
Probe: NOZZLE_AS_PROBE
Probe Offset X0 Y0 Z0.00 (Same Z as Nozzle)
Auto Bed Leveling: BILINEAR (disabled)
>>> set_bed_leveling_enabled  X0.00 Y0.00 Z0.00
<<< set_bed_leveling_enabled  X0.00 Y0.00 Z0.00
Raise Z before homing:
do_blocking_move_to_z(5.00, 4.00)
>>> do_blocking_move_to  X0.00 Y0.00 Z0.00
>  X0.00 Y0.00 Z5.00
  destination= X0.00 Y0.00 Z5.00 : prepare_fast_move_to_destination
  destination= X0.00 Y0.00 Z5.00 : prepare_fast_move_to_destination
<<< do_blocking_move_to  X0.00 Y0.00 Z5.00
>>> homeaxis(Z)
  current_position= X0.00 Y0.00 Z5.00 : Probe::set_deployed
deploy: 1
Probe::do_z_raise(10.00)
do_blocking_move_to_z(10.00, 4.00)
>>> do_blocking_move_to  X0.00 Y0.00 Z5.00
>  X0.00 Y0.00 Z10.00
  destination= X0.00 Y0.00 Z10.00 : prepare_fast_move_to_destination
  destination= X0.00 Y0.00 Z10.00 : prepare_fast_move_to_destination
echo:busy: processing
<<< do_blocking_move_to  X0.00 Y0.00 Z10.00
>>> do_blocking_move_to  X0.00 Y0.00 Z10.00
>  X0.00 Y0.00 Z10.00
  destination= X0.00 Y0.00 Z10.00 : prepare_fast_move_to_destination
<<< do_blocking_move_to  X0.00 Y0.00 Z10.00
Home Fast: -42.00mm
>>> do_homing_move  X0.00 Y0.00 Z10.00
...(Z, -42.00, [4.00])
  current_position= X0.00 Y0.00 Z0.00 : sync_plan_position
<<< do_homing_move  X0.00 Y0.00 Z-42.00
Move Away: 5.00mm
>>> do_homing_move  X0.00 Y0.00 Z-42.00
...(Z, 5.00, 4.00)
  current_position= X0.00 Y0.00 Z0.00 : sync_plan_position
echo:busy: processing
<<< do_homing_move  X0.00 Y0.00 Z5.00
Re-bump: -10.00mm
>>> do_homing_move  X0.00 Y0.00 Z5.00
...(Z, -10.00, 2.00)
  current_position= X0.00 Y0.00 Z0.00 : sync_plan_position
echo:busy: processing
<<< do_homing_move  X0.00 Y0.00 Z-10.00
>>> set_axis_is_at_home(Z)
*** Z HOMED WITH PROBE (Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN) ***
> probe.offset.z = 0.00
  current_position= X0.00 Y0.00 Z0.00 :
<<< set_axis_is_at_home(Z)
  current_position= X0.00 Y0.00 Z0.00 : sync_plan_position
  current_position= X0.00 Y0.00 Z0.00 : Probe::set_deployed
deploy: 0
>>> do_blocking_move_to  X0.00 Y0.00 Z0.00
>  X0.00 Y0.00 Z0.00
  destination= X0.00 Y0.00 Z0.00 : prepare_fast_move_to_destination
<<< do_blocking_move_to  X0.00 Y0.00 Z0.00
<<< homeaxis(Z)
>>> move_z_after_homing  X0.00 Y0.00 Z0.00
>>> move_z_after_probing  X0.00 Y0.00 Z0.00
<<< move_z_after_probing  X0.00 Y0.00 Z0.00
<<< move_z_after_homing  X0.00 Y0.00 Z0.00
  current_position= X0.00 Y0.00 Z0.00 : sync_plan_position
SCARA Theta:0.00  Psi:0.00
<<< G28  X0.00 Y0.00 Z0.00

>> G28 X Y Z
SENDING:G28 X Y Z
>>> G28  X0.00 Y0.00 Z0.00
Machine Type: SCARA
Probe: NOZZLE_AS_PROBE
Probe Offset X0 Y0 Z0.00 (Same Z as Nozzle)
Auto Bed Leveling: BILINEAR (disabled)
>>> set_bed_leveling_enabled  X0.00 Y0.00 Z0.00
<<< set_bed_leveling_enabled  X0.00 Y0.00 Z0.00
Raise Z before homing:
do_blocking_move_to_z(5.00, 4.00)
>>> do_blocking_move_to  X0.00 Y0.00 Z0.00
>  X0.00 Y0.00 Z5.00
  destination= X0.00 Y0.00 Z5.00 : prepare_fast_move_to_destination
  destination= X0.00 Y0.00 Z5.00 : prepare_fast_move_to_destination
<<< do_blocking_move_to  X0.00 Y0.00 Z5.00
>>> homeaxis(Z)
  current_position= X0.00 Y0.00 Z5.00 : Probe::set_deployed
deploy: 1
Probe::do_z_raise(10.00)
do_blocking_move_to_z(10.00, 4.00)
>>> do_blocking_move_to  X0.00 Y0.00 Z5.00
>  X0.00 Y0.00 Z10.00
  destination= X0.00 Y0.00 Z10.00 : prepare_fast_move_to_destination
  destination= X0.00 Y0.00 Z10.00 : prepare_fast_move_to_destination
echo:busy: processing
<<< do_blocking_move_to  X0.00 Y0.00 Z10.00
>>> do_blocking_move_to  X0.00 Y0.00 Z10.00
>  X0.00 Y0.00 Z10.00
  destination= X0.00 Y0.00 Z10.00 : prepare_fast_move_to_destination
<<< do_blocking_move_to  X0.00 Y0.00 Z10.00
Home Fast: -42.00mm
>>> do_homing_move  X0.00 Y0.00 Z10.00
...(Z, -42.00, [4.00])
  current_position= X0.00 Y0.00 Z0.00 : sync_plan_position
<<< do_homing_move  X0.00 Y0.00 Z-42.00
Move Away: 5.00mm
>>> do_homing_move  X0.00 Y0.00 Z-42.00
...(Z, 5.00, 4.00)
  current_position= X0.00 Y0.00 Z0.00 : sync_plan_position
echo:busy: processing
<<< do_homing_move  X0.00 Y0.00 Z5.00
Re-bump: -10.00mm
>>> do_homing_move  X0.00 Y0.00 Z5.00
...(Z, -10.00, 2.00)
  current_position= X0.00 Y0.00 Z0.00 : sync_plan_position
<<< do_homing_move  X0.00 Y0.00 Z-10.00
>>> set_axis_is_at_home(Z)
*** Z HOMED WITH PROBE (Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN) ***
> probe.offset.z = 0.00
  current_position= X0.00 Y0.00 Z0.00 :
<<< set_axis_is_at_home(Z)
  current_position= X0.00 Y0.00 Z0.00 : sync_plan_position
  current_position= X0.00 Y0.00 Z0.00 : Probe::set_deployed
deploy: 0
>>> do_blocking_move_to  X0.00 Y0.00 Z0.00
>  X0.00 Y0.00 Z0.00
  destination= X0.00 Y0.00 Z0.00 : prepare_fast_move_to_destination
<<< do_blocking_move_to  X0.00 Y0.00 Z0.00
<<< homeaxis(Z)
>>> move_z_after_homing  X0.00 Y0.00 Z0.00
>>> move_z_after_probing  X0.00 Y0.00 Z0.00
<<< move_z_after_probing  X0.00 Y0.00 Z0.00
<<< move_z_after_homing  X0.00 Y0.00 Z0.00
  current_position= X0.00 Y0.00 Z0.00 : sync_plan_position
SCARA Theta:0.00  Psi:0.00
<<< G28  X0.00 Y0.00 Z0.00

Hmm, apparently your G28.cpp has been modified since the version you posted on Feb 7. Line 400 should be blank, after the last NUM_AXIS_LIST block, and before #if HAS_Z_AXIS. I'm surprised it compiled with it inside the parentheses I don't see the printout from it, but since G28 X Y Z didn't work, I think the problem is somewhere else anyway. At this point I'd really have to spam print messages throughout that function to reveal the path it takes, and probably a few more rounds tracing other functions from there before we finally discover what broke it. Too much trouble, I think. If you'd like, I can post my working firmware based on version 2.0.9.2. Otherwise I think you'll have to keep trying with RRF.

Deku,

That is the joy of firmware that changes constantly. All files from the 2.1.2.5 marlin were straight from the zip file off their website. I know I was amazed at how much was different when trying 2.1.3-B3.

Please post the firmware you have. I don't mind running through config and adv_config again to set all the parameters again as long as it works. I even tried ArcDroid's firmware which is a scara plasma cutter (uses 2.0.8.1), but due to its age, I was unable to add the SKR 3 EZ board to make it attempt to work.

Times like this make you wish you could ship this thing off to someone and just say 'fix it', of course that would cost more than its worth in parts.

Dang, it looks like mine doesn't support that board either. It may be possible to simply copy-paste the latest HAL folder and boards.h into the old firmware, if no breaking changes have been made to the HAL interface.

I could also try starting from a fresh pull on my printer where I can debug it in person. I had always intended to do a pull request to the main branch with my improvements to the SCARA code, but chickened out since I don't have a proper MPSCARA to test on, and then quickly became out of date with the main branch and gave up. But since the main branch has remained broken for years since, I should have just gone for it without thorough testing. And this time I'll have more confidence with your more MPSCARA-like printer to test it on as well

That sounds helpful, not just to me, but for any of the few people wanting to use mpscara in the future. I know most everything I found was morgan scara, which even that documentation is rough since you can have a single shoulder joint like the original or a dual shoulder joint.

As for the copying of folders, I know I tried just copying the STM32 and files I kept seeing errors for to no avail, such as boards.txt and similar. Most of the issue came from the platform.ini, but even when nearly copying everything from new to old over, it kept saying the board didn't exist. Such is the nature of a massive project such as marlin that started out back when hobby printing was still new.

But, I certainly don't mind my printer becoming a guinea pig for firmware testing. It was made purely to test the motion system and use up parts I had lying around, even if it took 3.5 kg of PLA to make it. As said in prior posts, let me know if there is any information I need to add from the SW model or related. Attached is the angles at the 3 other max corners that was added to the Duet 3d post since that has had dc42 looking at it for the RRF side of things.

I am very thankful to see this topic even getting help since hobby level scara seems to be so obscure. Sad part is you can buy a used industrial scara cheaper than a new ender 3.

Ok, I've got the latest version running now. Try changing the preprocessor check in do_homing_move from ANY(MORGAN_SCARA, MPSCARA) to ENABLED(MORGAN_SCARA), and the one in set_axis_is_at_home from ANY(MORGAN_SCARA, AXEL_TPARA) to IS_SCARA. My clean pull gave a failed to home message the first time I ran it, and I think that's what fixed it.

If that doesn't work, here's my full source code and change log. Most of the configuration edits are specific to my printer, and some are just my personal preferences. You'll have to copy the src/lcd folder from the main Marlin repository because someone got the bright idea to put 50MB of image data in there, so I had to exclude it to keep the filesize reasonable here.

There's a force setting of BED_CENTER_AT_0_0 in Conditionals-5-post.h if IS_KINEMATIC is true (which it is for SCARA). Comment that out and I think it will work with center at bottom left, but I didn't actually test it.


Changes to Configuration.h:
Modified MOTHERBOARD, SERIAL_PORT, and BAUDRATE
Changed X,Y,Z,E_DRIVER_TYPE to TMC2209
Modified SCARA settings
Modified DEFAULT_AXIS_STEPS_PER_UNIT, DEFAULT_MAX_FEEDRATE and DEFAULT_MAX_ACCELERATION values
Enabled CLASSIC_JERK (won't compile SCARA without it)
Modified Y_HOME_DIR
Modified bed size and min/max pos
Disabled software endstops
Modified HOMING_FEEDRATE_MM_M
Enabled SD_SUPPORT
Enabled CR10_STOCKDISPLAY

Configuration_adv.h:
Edited values around line 944 (SENSORLESS_BACKOFF_MM and such)
Disabled ENCODER_RATE_MULTIPLIER (my STM32F103 is pretty slow and often misses encoder pulses, making the menus very difficult to navgate, and even worse if it can suddenly jump 100 units when you don't expect it)
Disabled SHOW_BOOTSCREEN
Changed EVENT_GCODE_SD_ABORT to M18 (disable steppers)
Edited trinamic driver current and microstep settings
Enabled sensorless homing and modified x/y stall sensitivity
Enabled IMPROVE_HOMING_RELIABILITY

Conditionals-5-post.h:
Disabled QUICK_HOME in the IS_SCARA section
Added SCARA_CROSSTALK_FACTOR default settings EDIT: Upon further review, morgan should also have 0 crosstalk

motion.cpp:
In function homeaxis, changed ANY(MORGAN_SCARA, MP_SCARA) to ENABLED(MORGAN_SCARA)
In function do_homing_move, changed ANY(MORGAN_SCARA, MPSCARA) to ENABLED(MORGAN_SCARA)
In function set_axis_is_at_home, changed ANY(MORGAN_SCARA, AXEL_TPARA) to IS_SCARA

scara.cpp:
Copy-pasted my scara_set_axis_is_at_home, inverse_kinematics, and forward_kinematics

G28.cpp:
Added my DISABLE_AXIS_Y code bit, as before

Edited 1 time(s). Last edit at 02/21/2026 04:34AM by dekutree64.

Thank you very much for the files. Going through them and making the changes for this machine has allowed it to finally home and move under command from the tft. But now a new issue has come up, of course this is all testing.

In the picture, all black text is what is the goal for it to be. Red text is what it is doing. Right now, it lets me move any amount positive or negative, homed or not. Not sure if that is specific to scara, but I did comment out all bed_center_0 defines. Next, X moves in what looks to be straight with a cross-talk of either 0.5 or 1.0 (36T:72T reduction, so I think it should be 0.5, but it is currently 1.0). Y however just rotates and X is stationary or barely moves if at all.

With the picture, the red text matches the tft screen where 'up' (Y+) is Y- and X+ is correct on screen, but the arm goes the wrong way: X- moves rightward. Z needs tuning elsewhere since it sounds like it is bound up when it isn't, but that isn't for the scara aspect.

X_HOME_POS and Y was set to 0 with max at bed size to try and set 0 at the corner, but I guess it isn't happy with it.

One question I had when going through config.h was SCARA_HOME_DIST_TO_NOZZLE. I put the number in as the direct diagonal distance from shoulder axis to nozzle at 0,0, but if it needs to measured some other way or if it is ignored fully, then so be it. Another point is, like with the confusion on RRF firmware, the offset theta: is it based on X axis to the right (when looking down on the machine) or is it on Y towards up? RRF is the former, but I want to say Marlin was the latter.

Another freak of nature thing it is doing which I find very odd is that at ~400mm commanded X, it moves normally for a bit then suddenly rockets off at way too fast a rotational speed until crash. Y does the same but at ~200mm. No clue why. It is as if the inverse kinematics is randomly ignored after a point and just runs a set speed on the motor. It doesn't accelerate when doing so, just jumps up to the new fast speed and full sends it to a crash. Note that all motion tested has been purely with the tft and no terminal or terminal in the tft. Large moves are simply a few 100mm moves clicked in succession.

In the end, the tft isn't critical for the UI since lightburn is the ideal final user interface once all is working, but if it can't work pure marlin, it won't work otherwise. At least now there is progress being made. Now I get to hope some stragglers will wonder over to my other post regarding a planetary gearbox design of mine for these N34 motors.

Quote
Chip Bark
One question I had when going through config.h was SCARA_HOME_DIST_TO_NOZZLE. I put the number in as the direct diagonal distance from shoulder axis to nozzle at 0,0, but if it needs to measured some other way or if it is ignored fully, then so be it.

lol, I intentionally didn't explain that so I could use you as a guinea pig, and apparently the comment above it is not clear enough after all It should work with 352.6486, or you can ignore it and just set THETA2 to (90+130.976) or 220.976 like before. I calculated THETA2 that way since it's easy to measure the shoulder-to-nozzle distance on my printer after homing, whereas measuring the exact elbow angle is not. But I'll probably just remove that value entirely. I added handling of the M665 values for MPSCARA since then, so now it's easy enough to start with the nominal elbow angle and adjust while printing rectangles until the lines are straight and square, rather than trying to get it perfect by measuring the printer itself.

Quote

Another point is, like with the confusion on RRF firmware, the offset theta: is it based on X axis to the right (when looking down on the machine) or is it on Y towards up? RRF is the former, but I want to say Marlin was the latter.

Positive X is right, positive Y is up, zero angle points to the right (along positive X), positive angle rotates counterclockwise. So there is still a problem with the configuration if it's moving in the opposite directions. Is it possible your motor directions are wrong? You could try setting INVERT_X_DIR and Y to true, or to be more certain, compile it as a non-scara printer and see if positive X and Y moves cause counterclockwise motion like they should.

I think you're right that your machine should have 0.5 crosstalk. I didn't realize there was a 2:1 reduction between the intermediate axis and the elbow. Mine is 40:60 from intermediate to elbow, and crosstalk factor 0.333, so I think the formula is 1-elbow/intermediate, which is 1-0.5=0.5 in your case. And MPSCARA has equal teeth on the intermediate and elbow, giving 1-1=0 crosstalk. Crosstalk factor 1 is for designs where the elbow motor rides on the proximal arm, so 100% of shoulder motion is applied to the distal arm as well.

Now that I think about it, your Z axis probably has crosstalk too, since it uses a similar pulley system to the elbow. And it will be even more confusing since elbow motion affects it too... What are all the reduction ratios involved? Motor to shoulder intermediate, shoulder intermediate to elbow intermediate, and elbow intermediate to end effector. The code for it should go in inverse_kinematics where it calls motion.delta.set. But Z-only moves may not work properly, and would be difficult to figure out where all you'd need to insert the correction...

X_HOME_POS and Y shouldn't do anything. When the SCARA_OFFSET_THETA are defined, it uses the forward_kinematics function to calculate the cartesian home position from them.

Edited 2 time(s). Last edit at 02/22/2026 01:54AM by dekutree64.

I am glad to have the machine be a guinea pig since it didn't work otherwise. Attached is a section view to show all three reductions. 7:1 for both X and Y, 2:1 for Z and 1:1 for all Z belt moves. Ideally the Z motor would be on the distal arm, but I was determined to use three N34 motors just to use them, thus this horrendous mess of bearings for a tri-axle concentric design.

With that, the motors assuming false inverting is CW from the motor, then due to orientations, X is CW on the arm, Y is CCW by default. I'll invert the motors when I can and invert its homing to match since it homes correctly.

After that, with cross talk being likely 0.5, it will be a fun time getting X and Y to move together for Y moves. I wonder if it would be good to re-enable the software endstops since the 0,0 on a corner is the ideal goal?

As for the Z and the double cross-talk, it really makes me with the firmware, both marlin and RRF, has options to simply say: if X AND/OR Y AND Z, add motion accordingly, else just Z. But alas, I doubt the firmware would be happy with an if statement in the motion calcs like that. If all else fails with Z, I can ignore it entirely for the purpose of the laser, or use the motor for something else on the machine. No clue what other function it would use a stepper for since a print head is only good for large flat parts. I dare not do that without a heated bed.

All the while, I get to keep working on the Tpara design slowly but surely since hopefully its firmware will go more straightforward, but something tells me it won't.

Hmm, maybe only X should be inverted then. EDIT: I just checked and you still have Y inverted from my configuration, so set X true, Y false, and both home directions positive.

From what I can tell in the code, software endstops aren't really used on SCARA. When it's enabled, any XY positions outside the arm's reach will be "pulled in", but that's it. Personally I think it would be better to also enforce the XY min/max values, and "push out" any positions too close to the shoulder axis (to the MIDDLE_DEAD_ZONE_R value that's currently only defined for MORGAN_SCARA), and perhaps just hold the current position if the target is almost directly on the axis where pushing it out would cause numerical accuracy problems. But I'll probably leave it alone for now and focus on getting the critical fixes integrated into the main branch first.

1:1 on the Z intermediates is good. In that case, I think you can just do this

    motion.delta.set(
      DEGREES(THETA1),
      DEGREES(THETA2 - THETA1 * SCARA_CROSSTALK_FACTOR),
      z - (THETA1 + THETA2) * (8/(M_PI*2))); // Convert from radians to 8mm per leadscrew revolution

Delta requires movement of all motors for Z, so hopefully SCARA will call its kinematic function for Z-only moves too. Homing may still be a problem since we disabled the SCARA bit in do_homing_move so each axis motor moves separately (Z probably won't get the correction). But if we re-enable it, then it's impossible to disable the elbow motor while homing the shoulder, so the arm can crash into itself depending on where it starts from. Same with quickhome (which moves both motors simultaneously), plus then the elbow may get a wrong value if it reaches its endstop first and then the shoulder continues moving and crosstalking it to a different angle. I suppose in the worst case you could use quickhome and manually position the arm in such a way that it will reach the shoulder endstop first.

Edited 1 time(s). Last edit at 02/22/2026 02:37PM by dekutree64.

Big news: after changing the motor directions and the cross-talk back to 0.5f, it moves full X and Y (635,0 & 0,635 respectively) correctly with both arms moving in tandem and no crashing into the tower. When giving a G1 X634, Y634 F1000 command, it moves in what looks to be a very steady diagonal line like it should, other than the slack in the gearing.

Found two things with this: When it homes, it sets home to (-1,-1) and max is (634,634). Not critical, but if I command it to move from 634 -> 635, it freaks out due to boundaries and runs off at mach 2 for a crash. X will likely do the same, but it explains last night's issue since if it assumed a 0 at center, -400 X was 'out of bounds'.

Now for the Z. Without implementing the cross-talk Z yet, it is acting beyond wrong even for cartesian movement. With a corrected 1600 steps/mm (200 steps/rev * 32 microstep / 8mm/rev lead * 2:1 reduction), it is trying to move well over that. If I ask it to move 1mm, it moves a full rotation at the distal pulley, so the motor is doing 2 full revs for 1mm. When homing, the motor runs at about 2-4 revs/sec which is far, far too fast or reasonable. The strange thing is the Z moves fine with RRF, and looking at that config.g, I still had the steps for it wrong at 2800. Regardless, marlin is making the Z odd.

When trying to implement your Z cross-talk code into scara.cpp which was the only place the motion.delta.set showed up, the error is as follows (line 169 - 173):

Marlin\src\module\scara.cpp:173:7: error: 'Z' was not declared in this scope
  173 |       Z - (THETA1 + THETA2) * (8/(M_PI*2))); //Convert from radians to 8mm per leadscrew revolution
      |       ^

Attached is a video of it moving with G1 XY 634 F2000 (It is slow, but it looks like it can handle F10k later) and a video of it homing with the Z issues quite audible and visual. Also, got to love AC lighting and the wonderful wave pattern it makes with cameras.

Still, big progress with it now moving correctly more or less. I only wanted the Z to allow for bed leveling since this was to be portable (25 lbs and cumbersome, but it is portable) for a laser/plasma which needs no Z movement, but helps for a skewed work plane.

Excellent! I wish I'd thought to verify the motor directions sooner.

I'm not sure exactly why the home position is reading -1,-1, but maybe it rounds toward negative infinity if it goes just a touch below zero. What matters is that the home angle values match the physical angles of the arm when it reaches the endstops, and that the arm lengths are measured precisely. When you have it fully calibrated, the resulting home position will be somewhere near 0,0, but not exact.

I think enabling the soft endstops will prevent the runaway motion. I just don't tell it to go anywhere it can't reach.

The fast Z movement is because Z_MICROSTEPS is set to 0 in the Configuration_adv.h you posted yesterday, presumably left from my configuration (I have a T8x2mm leadscrew, so 100 steps/mm is plenty without microstepping). Although it is odd you're only getting 8x more movement than requested rather than 32x. Your steps/mm calculation looks right to me.

The compile error is because z should be lowercase.

It would be a waste of your elaborate mechanical construction, but for the proposed usage it would be easier to have a manual Z adjustment on the end effector rather than using a motor for it.

Fixed the Z microstep error. Annoying in a way how it has an array earlier for microstep modes but then each motor has a defined step elsewhere. Side gripe: very annoying that VSC pulls 100% cpu just to build marlin.

Either way, using a lowercase Z, which I tried prior too, still errors:

Marlin\src\module\scara.cpp:173:7: error: 'z' was not declared in this scope
  173 |       z - (THETA1 + THETA2) * (8/(M_PI*2))); //Convert from radians to 8mm per leadscrew revolution
      |       ^
*** [.pio\build\STM32H723VG_btt\src\src\module\scara.cpp.o] Error 1

Here is the same error when copy and pasting your code straight into it instead of prior when I just typed it in for no real reason:

Marlin\src\module\scara.cpp:173:7: error: 'z' was not declared in this scope
  173 |       z - (THETA1 + THETA2) * (8/(M_PI*2))); // Convert from radians to 8mm per leadscrew revolution
      |       ^

Sorry, should have double-checked. It's raw.z