I love strange kinematics, and when I discovered the parallel scara I had to build one.

The Duet did not have support for this kinematics in stock firmware but @JoergS5 had an almost complete implementation that we have developed further. The firmware works very good now.

The machine is made mostly of printed parts and items you can easily get hold of, and a hacksaw and hand drill. No machined parts. The precision is not the best but it still works pretty good (just a nightmare to calibrate). It's still a prototype/proof of concept so it does not look very good and many parts are stuff I had laying around.

The body rides on 3 12mm rods with LML12UU-like bearings, and has one leadscrew. The inner joints have two 6806 bearings per arm. The elbows use two 8mm thrust bearings each, preloaded with an m8 rod, a crude solution that works very well. That joint is very stiff. The hotend joint has two 6704 (20x27x4) very thin and light bearings inside. Lots of bearings.

The motors driving the arms are 48mm 0.9degree NEMA 17 with a 20t pulley leading to a 200t printed pulley. This gives a gearing of 1:10 which is very much on the low side. 1:30 would be far better. But upping the microstepping to 64 or even 256 saves the situation. A problem with 256 microstepping is that the Maestro starts to get stepping rate problem over 400mm/s.
Using a normal gearbox is not possible due to their backlash. A machine like this needs a gearbox with almost no play, like a harmonic drive. A belt gearbox works pretty good but the gearing is limited due to size.

With the 180 and 216 mm long arms the printing area is approximately 300x200mm. The actual print area is actually half-circleish shaped and quite a lot bigger.

The printer can move at blazing speeds and accelerations without any drama and shaking. The kinematics is similar to a polar delta but just 2 axis instead of 3. Currently it has a fair amount of ghosting at high speed/acceleration, but prints very good at a more reasonable 60mm/s and 2000 acceleration. I think the ghosting is due to a far too wobbly tower, or possibly flex in the belts. I have got some metal clamps for the 12mm rods and some more 3060 extrusion in the mail, it might help.

I made a little video showing it moving fast https://www.youtube.com/watch?v=MW8HApFoy38.

Here is an earlier version doing the first reasonably successful benchy print.

Those arms were made of small U-beam and far too wobbly, changing to bigger 20 mm square beams made a massive difference.

The very first little prototype to get a feel for the kinematics, a very useful little toy

I'll bring my 5 bar scara that was supposed to be shown two years ago.

Just have to get the thing moving again..

After some quick tuning of the hotend and more mechanical calibrations I managed to print this stunning benchy, at 120mm/s and 2500mm/s^2 acceleration. I'm surprised!

@iamthebest22 No updates I'm afraid. It works perfectly fine, I use it to print various small parts for other projects. The accuracy is not good enough for big mechanical parts, we need a calibration method for that.

It's actually a very simple mechanical construction. Some parts from my CAD files:
https://a360.co/3dNKGjZ
You have to make your own Z axis

Is there any way to build the firmware without eclipse? Good old make?

I just updated my firmware sources for the first time since january and getting it to compile and link again was the same nightmare it was back then. Hours of randomly clicking around on "Build clean", "refresh", "build all", restart eclipse, delete directories, pressing F5, sometimes getting one step closer to a successful build.
The problems are all in configuration and/or dependency management. Or my total lack of understanding eclipse.

I finally got it building again, slightly frustrated.

I am still shocked with the quality of the prints this machine can produce. It beats my CoreXY machines and is almost on par with the delta.

Apart from the need for better cooling and extrusion control (not the focus of this project) this dragon looks amazing. I hold it in a light to show the flaws as much as possible.

There is a very small amount of ghosting and some strange visible lines.

I think these lines are an stepper artifact, the gearing of the arms are still on the low side.
My delta machine (not duet but TMC drivers) have similar patterns but not as visible.

I managed to break my last ceramic heatblock, a fragile construction. And they stopped producing those They were amazing, heated up in 20s and could handle high flows. The RRF PID tuning used to warn that "ultimate temperature" was unsafe when auto tuning

Sorry for my rant before, I was far too agitated to post on forums.

The problems had nothing to do with my configuration and setup. I didn't change a thing between starting to try to compile and successfully building a working firmware. No build configuration changes, no source file changes, none of the files in git were changed. The issues I had was everything from strange compilation errors in CoreNG, something about a Pin class, to linker errors where it was missing syscalls.o or symbols defined multiple times,

I think one of the keys to why it got resolved was a project refresh (F5) in eclipse.

I noted the change of GccPath and the need for an updated compiler. The old q2 compiler crashed on the new sources, "../src/Storage/FileInfoParser.cpp:764:6: internal compiler error: Segmentation fault". Scary.

My dislike for eclipse is now even stronger than it was before

A hint for everyone building a parallel scara:
Before mounting the head move the arms around in all kind of strange positions and make sure that the distal arms are at the same height (or at the offset you designed them to have). Especially try to reach the same spot with different arm-angles. If they do not line up everywhere it will be impossible to get flat XY movement in the z-plane.
It can be quite a lot of work to get it all right but it is at the same time a kind of self-verification of the machine that all joints rotate perpendicular to the same plane. A very nifty feature.
I had to use a mixture of gentle filing on some plastic pieces and brute force bending and twisting the aluminium tubes to get this machine straight. Alu-extrusions from the local hardware store are not made for precision machinery.

It looks like typical delta waves on your printed parts. Bent diagonal patterns on flat surfaces. That's a sign that something is not perfect with the linear motion. It could be the pulleys, idler, linear bearings, ...
The bend in your patterns is not very sharp, the predator is a very large machine. A smaller machine will get sharper bends. If you move the model to the edge of the platform the angles should change, and the patterns will get tighter or more spread out depending on what/which towers is the cause.

When it is motor/driver related you usually get a tight, highly repetitive patterns. If you turn off microstepping it will show up very clearly. That's not a suggestion to solve your problem, but a fun experiment to see what it looks like

I'll bring my five bar scara and possibly some other fun stuff.

I made a little tool to help you plan the arm lengths:
https://github.com/bondus/5barscara/tree/master/JS

Fetch the git and open the html in a browser. It's a very crude little tool where you can experiment with arm lengths and work modes, it renders the possible work area and you can mouse in the work area to see the arms.

I have build a five bar, it actually works very well. The double arms makes it very strong in the XY-plane, exactly what we need when FDM printing.
There are a few tricky parts building a five bar.

You need to gear down your motors a lot to get enough steps/mm. And you need a gearbox with almost no backlash at all. The normal gearboxes you often find with steppers have way too much backlash. Ideally you would want a harmonic drive or possibly a cycloidal gearbox. I used gigantic pulleys (260t) and belts on my machine.

You have to be very precise on the length of the arms, and the angle of your homing sensors. A small error will result in warped parts. This is the similar to a delta printer, except that the firmware have amazing calibration algorithms to compensate for errors. The Five Bar firmware has no such features.

It can also be tricky to make the arm move in a perfectly flat plane. It's important to make sure all bearing rotate in the same plane. It is actually an over constrained system and if not built perfect there will be tensions in the arms.
A bed probe can compensate for small errors ofc.

I'll bring my 5 bar scara that was supposed to be shown two years ago.

Just have to get the thing moving again..

Sorry for barging in. But...

If you were to describe the robot as a number of transformation matrices (https://en.wikipedia.org/wiki/Denavit–Hartenberg_parameters) you could describe any serial robot with any number of axis. Even a serial scara could fit in this (except the bed).

Matrices are very nice to work with.

Combine this with the matrix defined cartesian and you can describe any combination of linear cartesian and serial rotary kinematics. What a dream

@iamthebest22 No updates I'm afraid. It works perfectly fine, I use it to print various small parts for other projects. The accuracy is not good enough for big mechanical parts, we need a calibration method for that.

It's actually a very simple mechanical construction. Some parts from my CAD files:
https://a360.co/3dNKGjZ
You have to make your own Z axis

@arhi If you do not return true from IsContinuousRotationAxis() that is exactly what you get. You can still rotate multiple rotations, it only affects the automatic wrapping.

@arhi It's supposed to be used with polar/arm printers, if you move 360 degrees you end up at the same place.

M92 sets steps/deg in this case and not steps/mm. For example a 0.9deg stepper with 16 microstepping and a 20:1 gearbox will be 16*20/0.9 = 355.556 steps/deg

@pgoellner It worked when I played around with it.

When IsContinuousRotationAxis() returns true the firmware should always find the closest direction to rotate to reach the goal.

It has to be a G0 move for it to do this.

I'll probably sort it out. Just venting a bit

A "build clean" and another attempt to build gave another error:

23:29:55 **** Incremental Build of configuration DuetM_RTOS for project RepRapFirmware ****
make -j16 all
make: *** No rule to make target 'src/GPIO/GpioPorts.o', needed by 'DuetMaestroFirmware.elf'. Stop.

23:29:56 Build Failed. 1 errors, 0 warnings. (took 1s.23ms)

Eclipse and the RRF build system is very fragile and frustrating.

I avoid to update my local repo, each time I get these seemingly random errors.