Welcome! Log In Create A New Profile

Advanced

Scara Firmware Setup Confusion

Posted by Phearl3ss1 
Scara Firmware Setup Confusion
November 26, 2020 06:36PM
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.
Re: Scara Firmware Setup Confusion
November 30, 2020 06:36PM
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).
Re: Scara Firmware Setup Confusion
December 01, 2020 02:05AM
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].
Re: Scara Firmware Setup Confusion
December 02, 2020 12:18AM
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?
Re: Scara Firmware Setup Confusion
December 02, 2020 04:56AM
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].
Re: Scara Firmware Setup Confusion
February 11, 2021 09:55AM
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.
Re: Scara Firmware Setup Confusion
February 12, 2021 02:50AM
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].
Re: Scara Firmware Setup Confusion
February 12, 2021 02:45PM
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.
Re: Scara Firmware Setup Confusion
March 01, 2021 01:57AM
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.
Sorry, only registered users may post in this forum.

Click here to login