SCARyllA: Dual (parallel) arm SCARA laser engraver build

Hello Everyone,

after some months of reading this forum, searching the web, construction and reconstruction of several ideas, I thought I could share some ideas and images of my machine.
My target: Compact and portable laser engraver for cutting paper and/or thin polymer layers, branding into wood.

There are many machines using cartesian geometry, which would somehow be an "easy" solution with ready available components, software etc....
Nevertheless, I focused onto SCARA-like geometries because:
Small footprint.
No linear rails, no belts,...
Low part count.
...

As far as I tried recherching this forum, the www and literature, there are several different approaches for:

1. Single arm SCARA:
a: Lower arm motor sits on the upper arm and rotates with the upper arm. Motor for the upper arm sits in the base.
Examples are:
- Heliumfrog-SCARA by Mr. Martin Price [www.heliumfrog.com]
This machine is controlled using his selfmade software on an Arduino.

- Vitaminrad-SCARA [forums.reprap.org]
This machine is controlled by a modified Marlin-Software [github.com]

-Scribing SCARA-arm [mindbleach.com]
This machine is controlled using standard GRBL on an Arduino. Inverse kinematics are done on a host PC, sending converted data to the GRBL.

- Commercial SCARA, such as [transistor-man.com]
controlled by LinuxCNC.

b: Both motors sit in the base, and rotation of the lower arm has to be compensated with respect to case 1 a,c.

c: Motor of upper arm sits in the base, motor for lower arm sits on lower arm, and rotation of the lower arm has to be compensated with respect to case 1 a,b.
- Lewis by Insilicoresearch (Mr. Steve Kelly ) [diy3dprinting.blogspot.de]
[github.com]
Firmware ??



2. Parallel-arm SCARA where the motors are spatially separated (personally I would say, these type of machines are "dual arm" SCARAs...):
a: Motors directly drive the upper arm.
Examples are:
- Armstrong by Mr. ttsalo [forums.reprap.org]
Controlled by the following software [github.com]

- Armstrong-style by Mr. EvilMonkey [forums.reprap.org]
Controlled using the ttsalo software [github.com]

b: Motors directly drive the lower arm.
Examples are:
- Wally by Nicholas Seward [reprap.org]
[forums.reprap.org]
[forum.conceptforge.org]


3. Parallel-arm SCARA where the motors are coaxial:
a: Motors directly drive the upper arm.
- Morgan by Mr. Quentin Harley [reprap.org]
Controlled by a modified Marlin software [github.com]
Another possibility would be usage of the smoothieware [smoothieware.org]
Another possibility would be the usage of Teacup [github.com]

b: Motors directly drive the lower arm.
Examples ?? Nothing found...


Please excuse any missing examples...it´s just for getting an idea, otherwise feel free to send me a PN if you think I should list further ones.

Unfortunately all firmwares state something like "supports SCARA geometry" but without defining the real geometry in detail !
Although software documentation seems to be quite crude for me, most SCARA-software can be found for 3.a., the "Morgan" style machine.

Nevertheless, I want to built a machine "Armstrong" style because I think it has some benefits regarding my desired specifications..
Currently, software is a real problem for me, because I do not know anything about programming.
For first tests I think about using "ttsalo´s" software. Here, EvilMonkey already listed some needed modifications.
Alternatively, I would really love to use something like Teacup, but I don´t know how to modify it for the dual arm SCARA geometry....When I´m completely finished with the mechanical build, I will focus again onto software.
I already calculated the inverse kinematics (IC) for it and thought that it should be possible to implement a displacement parameter "d" into the current Teacup-software. When setting d=0, the standard "Morgan" configuration should come up. So here´s my IC calculation:

The problem here is, that I do not know which files to modify. There´s no good documentation where to define new parameters ("d"), where to set the homing sequence, where to set the actual position after homing switch triggering, where to set the bed coordinates etc...
Hopefully I will find a solution in the future for these issues.

For the SCARA geometry the angular resolution is crucial for accuracy and gear backlash makes things worse.
So I decided to use second hand harmonic drives (80:1), Nema17 steppers and two ball bearings in each arm joint.
Laser will be a 405 nm single mode semiconductor diode, focused by a glass lens. Output power around 500 mW.
d=85mm, l1=90mm, l2=125mm.

These are the ball bearings I will use:



And here you can see the current design:




This will be the preliminary working area (in reality somehow smaller, but currently it´s fine for me):


And here are images of the first parts:




So long,
Mike

PS: I called my setup "SCARyllA", which is a combination of SCARA (typically having only one arm) and Skylla (typically having something between five heads and six legs) ... ;-)

Edited 1 time(s). Last edit at 03/29/2015 03:20PM by theothermike.

That is a beautiful design! If I can figure out how to get rid of that startup bug in the firmware that causes the arm to swing over, I will let you know.

---

[scara3dprinter.wordpress.com]

Thank you! Hopefully I can get it running as wanted... and hopefully we both can find a suitable solution for an up to date software..

One suggestion, you may want to add a way to very finely adjust the home position, possible adding a screw with a locknut that the end stop impacts. The start position needs to be as exact as possible or else the print or cut will be distorted and you may have problems adjusting those end stop clamps by hand.

---

[scara3dprinter.wordpress.com]

The only thing I can tell for certain is that it is the G92 command that is causing all the problems with the x arm swinging over at start up.

---

[scara3dprinter.wordpress.com]

Hi,
the fine adjustment screw is a very good advice!
Before manufacturing it, I will redesign it...
Thanks for help !!

Short update...

Harmonic drives (HD) assembled into the HD-carrier, all together mounted with the arms onto the back and middle plane (not visible here)...







Next step will be the stepper mounts...

See WALLY at:

[forum.conceptforge.org]

the one I built never worked well -- lack of fully developed firmware / software

Makes me feeling sad that your machine is not working properly!
Firmware modding is really a pain i.t.a. .... But the "Morgan"-firmware should be quite similar regarding the IC needed for this one here...at least I hope so....

Besides the little bug at startup that causes the arm to swing over, ttsalo's firmware works just fine.

---

[scara3dprinter.wordpress.com]

EVilMonkey, indeed, ttsalo software with your modifications is first choice!

Short update...found some time to fabricate the motor mounts, assembled them onto backplane and mounted steppers...


Next step will be the lower baseplate...

Slow progress...
Today I finished the lower baseplate:




Rupper pads are from ebay:
[www.ebay.de]

That machine is coming together beautifully. What firmware are you going to use?

---

[scara3dprinter.wordpress.com]

Thanks a lot, I hope I can get it running...

You already stated that the modified Marlin-Firmware from ttsalo is working. So that´s one try.

A second try would be "Teacup".Teacup seems to be nicely made and also supports the Teensy3, which would give even more performance. Because it´s state of the art, it would be very nice to get it running...
It was said:

Quote
Traumflug
Looking at the code changes so far it much looks like the other three types aren't too complicated. I'm a bit (positively) surprised how simple this apparently is. Just implement um_to_steps() and steps_to_um() for your mechanics and you're ready to go

For me that seems to be the inverse and forward kinematic, which has to be modified. So, some days ago I tried to calculate the forward calculation...looks ugly, perhaps I can simplify it a bit.
Besides I tried to compile the Teacup-SCARA-Branch for Morgan-setup.
Again with help from Traumflug it compiled (LOOKAHEAD has to be defined in config.h.).

Mr. Kuhlmann made some comments, pointing to dda.c (row 949), dda_maths.c (row 289) and scara.h.

The readme tells us:

Quote
Readme.scara
dda_maths contains modified conversions (new: scara_um_to_steps) from µm to
steps for scara-type printers.
...
dda.c uses the new method instead of the cartesian versions (um_to_steps_x/y).

So, when the forward calculation is finished I try (It´ll be more trial & error because I dont´really know what I´m doing,...;-)) to modify Teacup for the dual arm SCARA by defining the displacement parameter "d" in scara.h, and adding weird calculations in the other files...
We will see.

Looking forward to seeing what you come up with.

---

[scara3dprinter.wordpress.com]

So how does this design overcome the problems surfaced in WALLY design?
Wally used a pre filter to convert X Y code to Wally commands.
Will you be using a controller , Firmware and Software to do this on the fly?

How you going to do Z?
Oops --- laser engraver may not need Z but it helps when cutting thick material.

cozmicray, actually I don´t know exactly what Problems Wally suffers in Detail.
But the Morgan-Setup works well with a more or less comparable kinematic calculation, which has to be adapted, of course.
EvilMonkey also has built a beautiful machine running another Firmware (ttsalo), so I´m not doing something new here.
I will try to run the ttsalo-software and/or the modified Teacup-Firmware on an Arduino Mega with Ramps 1.4 shield.

Z-axis is not used (yet). The whole system is meant to be placed on top of a workpiece, having the focal point in the same plane as it stands on.
But you´re right....some kind of focal adjustment might help.
For me the main problem is first to get the hardware into a basic functionality (ok, done now with the lower baseplate), getting the firmware running onto the Arduino and having the wire connections right with both Steppers running in the correct directions....
Afterwards the Laser Driver, Laser Mount and perhaps a focal adjustment screw can be added.
I also have an idea to make a retrofit z-axis for use with a printhead....but before this there are so many other Tasks :-)

I´m quite new to all this CAD-, CAM-, 3D-print, Mill-, Arduino-, Programming-, ..., Reprap-Stuff, that´s why I´m quite slow and I will see how far this will go...

Quote
cozmicray
So how does this design overcome the problems surfaced in WALLY design?

Wally's problem was that is had a fixed stepper actuating a moving pully, which caused exact positioning of the arms to be a literally moving target.
The problems with the Wally arms were fixed with the GUS arms, but by that point, the Simpson platform was more interesting to develop.

All of that aside, this guy uses traditional SCARA positioning, which isn't as simple as the GUS math, but is already well explored and already had the basics of the firmware written for it.

Have you looked at www.chillipeppr.com. They have a program for the tinyg board specifically for use with laser cutters.

---

[scara3dprinter.wordpress.com]

Never heard about chillipeppr before....
Last minutes I had a short view on it.
Seems that it´s an browser based controlling software, correct? I cannot see any real benefit, perhaps I´m too blind to see. OK, seems to have a pulsed laser output, but not much details about it directly accessible.

For my laser control I think I will use an arduino with pwm output and an enable input which connects to the z-axis or extruder signal...

At first, I will further concentrate on using the ttsalo- and/or Teacup firmware.

Well, no success for today...
I compiled the Teacup-SCARA-Branch (Teacup.SCARA) for the Morgan-setup, uploaded it to an Arduino Mega 2560 with Ramps 1.4 shield, connected it with Pronterface 2014.08.01 and......nothing moves. Steppers are under current and hum, but do not respond. Approx. 20seconds after Pronterface connection, hum disappears and steppers seem to be without current.

When using the Teacup-Master (Teacup.MASTER), steppers can be moved using x- and y-movement commands.

So, something in the Teacup-SCARA-Branch seems to be faulty.....and I don´t know what.

Perhaps somebody here in the forum has a working firmware .zip ?

After receiving the mechanical end switches and seeing the wiggly levers on the end stop mount between the arms I decided to use hall effect switches now.
So I´ll have to redesign the end stop switches mount a bit...
Thought about using the "a3144" sensor and a slightly modified end stop clamp.

Hello Theothermike,

I took a look (probably a bad one by the way !) on the teacup scara but I don't really see how it can get the arms moving ...
On line 165 of [github.com], it calls scara_um_to_steps(startpoint.X, startpoint.Y, x_delta_um, y_delta_um, &tmp_steps_x, &tmp_steps_y);

but in the definition of the function (line 287 of [github.com]) it doesn't makes any use of the x_delta_um, y_delta_um (internal name in the function are distance_x, distance_y).
So ....I don't see how it can move at all the parameters used for the calculation are only origin point and it never calculate the angle difference between start and end ...

The best bet with teacup would be to reuse the new framework made by traumflug.

Please correct me if i'm wrong

Quote
lyscanthrope
The best bet with teacup would be to reuse the new framework made by traumflug.

With "new framework" you mean Configtool? Configtool doesn't change anything in the firmware, it's just a very convenient way to write the config.h file. Firmware code, compilers used, all still the same. Even using an old fashioned config.h (one hand edited file) still works.

Regarding your code investigation, yes, I don't see these two parameters used, either. Perhaps time to do some printf() style debugging to see what's going on. Currently I'm busy with the last few steps to get printing from SD card working.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Sorry for being unclear :s

By new framework, it was just comparing the old scara version and the version currently in git (in which you have added some nice parts for using different mecanics and "start&destination" values).

Sorry to bother you, I took a look at some files I'm just having some questions (not request ) :
- I didn't saw any segmentation, did I miss it ? I understand that they are not needed for linear machines, but I would I have see it in enqueue_home if any.
- I see that it is possible to run the firmware in simulator ; are there already some work done to visualize the tool path ?

Hi there,

during last days&weeks I had too less time (Currently I´m testing and designing the hall effect switch holders....).

Perhaps that´s why SCARA-Teacup DOES not move the arms...!? I´m not sure, because my programming skills are....rudimentary.
With an helping expert or Mentor I might get it working but currently I do not have enough brain Juice to solve the firmware issue from ground up.

It could be ....but it is quite suspicious. I think I have missed something ... if the guy has commited it ...he should have tested before ! So I think I missed something !
Did you manage to have a forward kinematics for your build ? I treid ...but didn't succed

I think the forward kinematic is the following:


Looks weird (quite nested) and I´m sorry it´s not written very clearly, but it was a first try.

Edited 1 time(s). Last edit at 07/02/2015 04:41PM by theothermike.

Yesterday I tested the hall effect switches (HES) on a breadboard with an LED. Seems to work well when using a pullup resistor.

So I decided to design and manufacture a corresponding HES-box (material is black POM):

The HES´s will be glued into the box to give a sturdy finish.
It will be set into the middle beteen the two gears:

Next step will be a small redesign of the magnet holder clamps...

I want to use two 3x6mm NdFeB-magnet rods (N45). Lateral distance between them seems to be OK from the breadboard tests...