Scara Firmware Setup Confusion

https://youtu.be/24I21K-Frxk

I am trying to setup a single arm scara. In the configuration.h example I have started with the Mp_Scara. It states:

// SCARA tower offset (position of Tower relative to bed zero position)
// This needs to be reasonably accurate as it defines the printbed position in the SCARA space.

#define SCARA_OFFSET_X 100 //mm
#define SCARA_OFFSET_Y -56 //mm

I assume that zero position means X 0 Y O. If so and if we are measuring from the tower relative to bed zero position why would there be a different offset for the X and Y when both are at the zero position?

Edited 2 time(s). Last edit at 11/26/2020 06:57PM by Phearl3ss1.

Yeah, I do wish someone would write some documentation for this. The Marlin site says "Support for Cartesian, Delta, SCARA, and Core/H-Bot kinematics", and there are some config files here [github.com], but that seems to be the extent of the documentation. No explanation of what exactly is implemented or how to set it up. The original MPSCARA used a script to convert cartesian coordinates to polar coordinates in the gcode so the firmware wouldn't have to do inverse kinematics, but that's no good because it results in inconsistent linear speed of the printhead. There's no mention of whether proper IK has been implemented, or what limitations it may have (e.g. avoiding singularities when the arm segments are parallel to eachother), but judging by the existence of the SCARA_SEGMENTS_PER_SECOND value, I think it has been implemented.

For those SCARA_OFFSET values, I would guess that the idea is to view the printer from above, with bed zero referring to the bottom left corner of the bed, positive X pointing to the right, and positive Y pointing up. Then set those values to the location of the arm's first joint in that space. Using that, together with the segment lengths and joint angles, you can calculate the printhead position... or take the desired printhead location from the gcode and calculate joint angles to get there (inverse kinematics).

But there's no description of how the angles are used. Again if I had to guess, I'd say that both angles set to zero would point the arm straight to the right (printhead position would be x = SCARA_OFFSET_X + SCARA_LINKAGE_1 + SCARA_LINKAGE_2, and y = SCARA_OFFSET_Y). And positive angles would rotate counterclockwise from there.

But that still leaves the question of how to home the printer, unless you position the limit switches to activate when the angles are both zero (arm pointing straight to the right). I would guess that the two SCARA_OFFSET_THETA values refer to the home position angles. So for example if the limit switch for the first joint is positioned to activate when the arm is pointing diagonally down and right, then you'd set SCARA_OFFSET_THETA1 to -45.

My SCARA printer is mostly finished, so I'll be putting these guesses to the test relatively soon (probably a couple weeks).

Have you considered using RepRapFirmware instead of Marlin? [duet3d.dozuki.com]

---

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

I was just looking it over the instructions in the link you provided and a couple paragraphs down already became confused. It states,

In the M574 command, for the X and Y parameters a low-end homing switch means that the homing switch is located at the position of minimum angle, i.e. the arm is rotated fully clockwise. A high-end homing switch is one that triggers when the arm is rotated fully clockwise.

I am confused. If it is rotated fully clockwise wouldn't it be hitting either a high or low endstop? Why wouldn't one be counter clockwise?

Thanks for pointing out the error in that paragraph. I will correct it.

Further down in that page under "Homing files", it says:

Quote

For each of the proximal and distal joints, you should have a homing switch either at the maximum limit (maximum anticlockwise angle as seen from above), or at the minimum limit (maximum clockwise angle). In your M574 command in config.g, for the proximal point use X1 to indicate a switch at the minimum angle limit, or X2 to indicate a maximum angle switch. For the distal joint, use Y1 to indicate a switch at the minimum angle limit, or Y2 to indicate a maximum angle switch.

I hope this clarifies it.

Edited 1 time(s). Last edit at 12/02/2020 04:56AM by dc42.

---

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

After much procrastination, I finally got around to finishing construction of my printer. But now that I've got the firmware configured and flashed, I can confirm that Marlin does not have single-arm SCARA kinematics yet. So we're stuck with expensive Duet boards or nothing for now. Sad because SKR Mini has all the fancy hardware a SCARA needs for under $40.

I just found a schematic of the SKR Mini and it showed a STM32F103 processor. That processor does not have hardware floating point, so it would be slow at doing the trigonometric calculations needed to run a SCARA.

Have you seen the Duet 3 Mini? It costs less than our Duet 2 boards and probably has everything you need. Availability is limited at present but should get better in a couple of weeks.

---

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

Yeah, that's the one I was thinking I'd buy if I can't figure out how to add the necessary calculations in Marlin myself, but it still costs almost as much as the rest of the printer. And true the STM32F103 doesn't have hardware floating point, but considering that Marlin's base CPU usage is low enough for 16MHz AVR, a 72MHz ARM ought to have plenty of cycles to spare for software float calculations.

Spoke too soon! I've been doing more work on my printer, and after many hours of wading through confusing Marlin code, it turns out single-arm SCARA is indeed mostly supported, just lacking in documentation.

First thing, in addition to enabling MP_SCARA in Configuration.h, you have to change Conditionals_LCD.h line 30 to
#if EITHER(MORGAN_SCARA, MP_SCARA)

Then use MANUAL_X_HOME_POS and MANUAL_Y_HOME_POS to define the X/Y position (relative to bed zero) of the nozzle when the arm is in home position.

SCARA_OFFSET_X and SCARA_OFFSET_Y are documented correctly (they specify the position of the shoulder joint relative to bed zero).

SCARA_OFFSET_THETA1 and SCARA_OFFSET_THETA2 do nothing.

SCARA_FEEDRATE_SCALING seems to work. To me eye, the linear speed seems higher when the elbow is highly bent (arc radius small, high degrees per second), but it may just be an optical illusion. The code is difficult to follow, but I can't find any problems in the calculation.

In Scara.cpp function inverse_kinematics, THETA1 and THETA2 are calculated for a left-handed arm. If your arm is right handed, swap the + and - before the ACOS terms.


More technical info for anyone who wants to work in this code:

delta.x contains the proximal arm angle in degrees relative to the absolute X axis, and delta.y contains the distal arm angle in degrees relative to the absolute X axis (NOT relative to the proximal arm). The way the MPSCARA arm is constructed, moving the shoulder motor does not affect the angle of the distal arm relative to X axis, so this works nicely. But if your arm behaves differently, then changes are needed (mine does, so I can advise if anyone needs to get it running before I'm ready to do a pull request).

When homing, after the motors reach the limit switches, the internal cartesian position is set to the MANUAL_HOME_POS values, and the internal motor step positions are calculated by inverse kinematics in Planner::set_position_mm. Then when you send a position gcode later, it calculates the new degree positions by inverse kinematics, converts to steps, and moves the motors according to the difference between that and the old position.

Hey @dekutree64, thanks for these tips. You explained them well, so I managed to get the kinematics working right.
However, I have a problem with homing the my SCARA (I tested the kinematics by manually positioning the scara links). Did you have any problem with it, is there a bug or I cannot set it properly? The thing is, X and Y won't go the home position, only the Z axis will home.
I'm using simple NC microswitches, with "#define USE_XMIN_PLUG", Y and Z, set to minimum, and "#define X_HOME_DIR -1", Y and Z set the -1, of course. For example, when trying the default Configuration.h for a normal cartesian printer, and click the home button on Pronterface, the homing works for all three axis. But when I try it with SCARA configuration it doesn't.
So any idea what could cause the problem and where should I look to make adjustments to the code?
Cheers!

Edited 1 time(s). Last edit at 06/26/2021 02:44PM by DejanN7.

Yeah, homing is the most difficult part to get working because there's so much related code that it's difficult to tell what actually gets run and what should be run. I struggled a lot, but eventually got it narrowed down to just a few small changes:

Conditionals_post.h line 182: Add #if ENABLED(MORGAN_SCARA) check around QUICK_HOME (in other words, don't enable QUICK_HOME)
Motion.cpp lines 1318 and 1542: Change from #if IS_SCARA to #if ENABLED(MORGAN_SCARA) (in other words, the non-SCARA homing process works fine)
G28.cpp line 356: Add this inside the #else case:

        #if (ENABLED(MP_SCARA) && DISABLED(HOME_Y_BEFORE_X))
          DISABLE_AXIS_Y(); // Allow elbow to be dragged around freely during shoulder homing
        #endif

EDIT: Oh I just remembered that I also have software endstops disabled. I think it was causing problems due to the home position being outside the bed. And uncomment #define BED_CENTER_AT_0_0 on line 1300-something in Configuration.h. It may be possible to get it working with bed zero at the bottom left corner, but the coordinate system is much less confusing with center zero.

Edited 1 time(s). Last edit at 06/30/2021 07:13AM by dekutree64.