I want to release a new firmware for Scara arm 3d printers

Hi all,

I'm developing new firmware for scara arm based on repetier firmware, not marlin and i'm planning to release it as open source firmware which means you can use, modify, sell printers with this firmware for free.

The coolest features are autobed level, autobed correction, semi auto calibration, so it will be easy to calibrate.

I added some new gcode command only for scara arm.
G5 to rotating arm & forearm individually. At user interface i also add command to rotate individually.
G58 to close arm, which will ended with all positions at endstop
G28 homing route which will start with go to endstop and ended with bed center position.

With this firmware you can easy to change your bed center and change your orientation.
Which mean you can make you bed center at front, behind, right or left of your scara center axis.

I'm not using the words theta, psi to define the parameters. They confuse me, i'm using the words shoulder, elbow, arm length, forearm length. They are easy for me to understand, and hopefully easy for you to understand too.

You can see my first run video with this firmware here [youtu.be]
In that video i have problem with my hardware design, I still working on the hardware, there are alot of improvement but i still haven't finish yet with the hardware. So please don't consentrate at the hardware design in that video, look at how it run.

The firmware is running well in that video, it moves as it suppose to.
And with the calibration route, it quite accurate even with my ugly first design.
The difficulty to make scara arm running well is to calibrate the arm, forearm length and steps per degree for each motor.
This firmware is self calculating those parameter, which means you just enter inaccurate values, then do some magic tricks and the robot will self calibrate to get the correct values. The result is you print is accurate and square.

In my opinion, if the hardware is good, it will be as accurate as cartesian with delta speed and very large print area.

Please comment about this firmware, are you interested, are there any other feature that suppose to be there.


Thanks
Kusuma

Edited 6 time(s). Last edit at 01/22/2017 02:05AM by Wangsamax.

Of course, we are very interested !!
g2/g3 movements should be possible...

Hi all,

I am announcing my version of firmware can be downloaded at this site for free. [www.wangsamas.com]
I develop it from repetier firmware with additional Scara kinematics, Indonesian languages and changed menu.
for Scara Arm I added new Gcodes
G5 X___ for rotating X Axis
G5 Y___ for rotating Y Axis
G50 for calibration

Kusuma Ruslan

Edited 1 time(s). Last edit at 02/01/2017 05:54AM by Wangsamax.

Your firmware looks interesting, the LCD user interface has a lot of interesting features, do you think your firmware can be adapted for a Morgan type parallel arm Scara ?

Not yet. It works with single arm scara. I will make it works for paralel scara as morgan, maybe in few months later.

It's working for plotter in this video

[youtu.be]

[youtu.be]

Need help maybe you can save me

Hi Guys
I would appreciate if anyone can help me, I,ve been working on my scara 3d printer for a while on and off.
i have posted before on the site, and members have been helpful.
The problem i am having is as follows
When i home both arms to the endstops, that seems to be good. I use pronterface for that.
Then i send a command G0 X0 Y0
Both arms move , but the point where the nozzle will be does not end up at the center of my bed where i want 0,0 to be.
I have attached a TOP view Drawing of my current SCARA with dimesions in mm.
I have used many different marlin firmwares from VitaminRad, Invent main, DSR from Thingverse and even from Miklos Devecz ( See his You tube video )
For the life of me everyone i use gives me a different location after homing.
Also i have tried to do a test print of an stl file even though the 0,0 is not in the correct position .
I use pronterface to import the gcode which i create with Cura.
It prints, but it seems off scewed or not to scale.
When i say prints i don't have pla flowing yet, it's just testing to see if all will work before running all options, fans, nozzle, cooling fans etc.
I am very confused, and i would appreciate if someone can help me with my situation.
I am glad to share other info as well if required, such as the marlin firmware that i am using to test my printer.
My arms lengths are 171 mm and 190 mm
I am using for motors x and y , pulleys with 20 teeth- 2 mm pitch which are turing the pulleys on the arms with GT2 belts
Pulleys on arms have an OD of 75.8 mm and have 120 teeth with 2 mm pitch
In marlin i am using 53.33 as the steps for X AND Y
I am not an expert with programming, but i think i have set the values correctly in the configuration.h file accordingly, though i maybe wrong.
Is there some secret formula that i need to tweak for the kinematics which are situated in marlin_main.cpp ??
Maybe my Manual x,y,z home positions are not correct.
But if you se the image i have attached with dimensions, someone will be able to give me that info, as to what i need to modify.

All help welcome, Thank you guys, i will wait for your responses

ScaraMan

I may be biased, but IMO it's a waste of time trying to get good results from a SCARA printer with 8-bit controller electronics and firmware. The trigonometric calculations needed for a SCARA printer are beyond the capabilities of 8-bit controllers if you want to achieve reasonable speeds. That said, many SCARA designs are prone to vibration anyway because of the cantilevered arms, so you may be restricted to slow speeds anyway.

I posted my experience upgrading a low-cost SCARA arm printer at [miscsolutions.wordpress.com] (see also the previous and following posts in that series). Now, the maximum print speed I can use is limited by vibration, not by the electronics.

---

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 may be biased, but IMO it's a waste of time trying to get good results from a SCARA printer with 8-bit controller electronics and firmware.

I've been thinking about this and I have to disagree. As i see it, the problem with scara printers is that they are not designed to be easy to program. I'll try to describe an ideal printer to program.

An ideal printer would be of the parallel type with the driven rotating arm axis for each side in line with each other, like the reprap morgan in this video. [www.youtube.com] This is because when both steppers move at the same rate in the same direction then the focal point moves in an arc, not an ellipse or curve of some kind as what happens when the driven rotating arm axes are a few inches apart.

To simplify calculations it should also be a given that all 4 arms are the same length between bearing centers, making the shape outlined by the arms a square parallelogram. It should also be a given that the point of extrusion be below the center of the bearing opposite the driven rotating arm axis.

Now, the simplest possible printer firmware is cartesian based, so assume you use an up/down z axis. In a cartesian printer when it is told to move the carriage right the x stepper gets told to move, say 10 steps right. Therefore, you can easily predict where the carriage will be. This isn't true in a non ideal scara printer as the other stepper drags the carriage away when a stepper is moved. In the ideal scara printer when you move both steppers in opposite directions the carriage moves farther away or towards in a perfect line to the rotating arm axis.

Because of this predictable movement you can use mostly standard cartesian firmware on the printer. The only modification that i think needs to be done is to slow the rate of extrusion with arcs of a wide radius and vice versa. The printed output will look rather like the cross section of an onion with each layer inside the next. As you might imagine, this requires a custom slicer which will draw arcs of increasing size that finish at the shape perimeter.