Parallel SCARA
-
Hello, I think about constructing a SCARA printer like the RepRap Morgan printer, used with Duet3D. It's a parallel SCARA printer.
Different from the Morgan, I will create the stepper motors on different axes, maybe (like a mits-rp scara).Is there a mathematical model in the firmware to describe the stepper A and B to X, Y relationship, which I can change myself to support such a printer?
A further thought is to delegate processing to an FPGA, if calculation is too complex.
I want to build the SCARA with cycloidal drives (3d printed), and Z simply like a cartesian printer.
-
To support parallel arm SCARA, a new Kinematics class would have to be added. It should be simpler to write than serial SCARA because there isn't the complication of continuous rotation axes and switching between two different arm modes.
-
Dear David, is it possible that you help me a bit, what to change or add? I will give back the source if it's of interest. There is no rush, I could start in a month. I first wanted to check whether it's possible.
-
@joergs5, yes it's possible because the kinematics part of RepRapFirmware has been designed to make it relatively easy to add new kinematics. But it does require some C++ programming expertise. This document https://github.com/dc42/RepRapFirmware/blob/dev/AddingNewKinematics.md gives a brief overview. I can help with the detail.
To support parallel SCARA I think the easiest approach would be to copy the existing serial SCARA files (ScaraKinematics.h and .cpp) to new files for parallel SCARA, change the angle computation function, and remove the support for multiple arm modes and continuous rotation axes.
-
Thanks a lot, David, I will start analyzing the existing code and the documents.
I will publish here in this thread, as soon as I have something.
-
Dear David, I have one question left for now: accelaration seems to be connected to DriveMovement, so I have to split a movement to different acceleration phases, because in DriveMoment the acceleration value is fixed?
In parallel scara, a movemement from a to b has different acceleration rates and rates are changing for both steppers.
I would try to get constant speed to ease extrusion rate and to calculate acceleration rates depending on position.
-
RepRapFirmware applies acceleration controls and speed limits to XYZ movement, not to individual motors. I appreciate that for architectures such as SCARA, higher speeds and accelerations are possible at some positions. In practice, this would only increase the speed of long travel movements; and as travel movements generally account for a small proportion of total printing time, using position-dependent acceleration and speed wouldn't improve print times very much.
It would be possible to add a second level of acceleration and speed control for segmented kinematics types such as SCARA, but this is not straightforward. For example, on a serial SCARA machine, the maximum acceleration of the proximal arm depends on the position and acceleration of the distal arm too.
-
We have misunderstood each other. It is not about maximum speed, but the mathematical model. In article https://www.pmdcorp.com/resources/get/motion-kinematics-article figures 4a and 4b is explained, that for a given real-world-movement, the stepper speeds must be nonlinear (each stepper different), so acceleration nonlinear also. I did not find this mathematical model in your source.
I'll build scara first, change your proposed sources, print out and then look whether the lines are correct or the calculation needs corrections. I will let you know.
-
@joergs5 said in Parallel SCARA:
We have misunderstood each other. It is not about maximum speed, but the mathematical model. In article https://www.pmdcorp.com/resources/get/motion-kinematics-article figures 4a and 4b is explained, that for a given real-world-movement, the stepper speeds must be nonlinear (each stepper different), so acceleration nonlinear also. I did not find this mathematical model in your source.
I'll build scara first, change your proposed sources, print out and then look whether the lines are correct or the calculation needs corrections. I will let you know.
Like all other SCARA firmwares that I know of, long moves are split into short segments, then the firmware makes the approximation that within a short move, the motor movement is linear. The trigonometric calculations take too long to perform them when calculating the time of every step.
-
Thanks for the information. I thought of precalculation of all moves in a PC, make a lookup table for all stepper commands and store in RAM connected to Arduino. But this may be overengineering. This project is exciting, I will shorten the other projects and will start this one faster!
-
Calculations are easier than I thought if the scara is build with one axis for the two arms and the 4 arm sections have equal length (equal length means parallelogram and easy calibration). Then the angle between the two arms, which are connected to the steppers, define the radius and the middle line angle defines the position on the circle. Speed is the vector addition of the radius change (a straight line) and the movement on the circle.
I can split the movement into angles or into distance. I'll check which one produces less errors from the theoretically perfect line. The error differs by source and destination position.
I made a fork of v2-dev now and will compile and test.
-
@joergs5 said in Parallel SCARA:
Calculations are easier than I thought if the scara is build with one axis for the two arms and the 4 arm sections have equal length (equal length means parallelogram and easy calibration). Then the angle between the two arms, which are connected to the steppers, define the radius and the middle line angle defines the position on the circle. Speed is the vector addition of the radius change (a straight line) and the movement on the circle.
I can split the movement into angles or into distance. I'll check which one produces less errors from the theoretically perfect line. The error differs by source and destination position.
I made a fork of v2-dev now and will compile and test.
RRF already includes code to segment the movement, so you don't need to write that. All you need to do is enable segmentation in your parallel SCARA kinematics class, just like the serial SCARA one does.
-
Thanks for the info. The reason for searching is I want to check whether the code is exact enough. I did not find the exact location in the source where the planning is: how many segments are used. I would like to segment differently depending on the source and destination location, because the errors are differently (e.g. printing a diagonal is exact because only radius is changed, a movement horizontal is unexact). I would like to use one segment for the diagonal and more segments the more the linear movement differs from the real movement.
-
In your kinematics parameters you can set a number of segments/second and also a minimum segment length in mm. The segment length will be chosen so as to achieve the number of segments/second you specify, subject to the minimum segment length you specify. So slow enough moves will use the minimum segment length, while for fast moves the segment size will increased so as not to exceed the segments/second.
G0 moves are not segmented.
-
I think I found it: DDA SetPositions().
-
Sorry, you answered while I searched. Thanks for your answer!
M669 the S and T parameters.
-
The segmentation itself is done in file GCodes.cpp, functions DoStraightMove and ReadMove. But please don't change those functions if you want your eventual PR for Parallel SCARA support to be accepted.
-
I will only change the places you told me. Your information is valuable for me to further understand the code.
