Yet another kinematics

[bondus]

Hi,

I built a prototype printer with the same XZ kinematics as the kappa printer, if you remember that. A modified Scott Russell straight line mechanism.

(Not the prettiest thing, it's parts scavenged from the junk bin of old printers)

In short the upper sled moves the X axis (non-linear), and the lower sled moves the Z axis if the upper sled moves along.

Looking for software for my experimentations RRF seems to be a good choice. As an old embedded programmer I feel at home at once.

I have figured out the maths and have an idea of how homing and calibration could be done.
I got the firmware building correctly (f*ing eclipse) and just started implementing a new kinematics and is just asking if you have any pointers or examples of similar project that could me help to get started.

Ideally I would like to rotate the tower and drop the moving bed but there are some mechanical challenges to be solved.

[fcwilt]

@bondus said in Yet another kinematics:

kappa printer

What is the rational? What advantages does it have over existing designs?

Thanks.

Frederick

[Wyvern]

Looks like a proof of concept machine.

Pretty cool.

[dc42]

That looks an interesting design! There is a brief guide to implementing new kinematics at https://github.com/dc42/RepRapFirmware/blob/dev/AddingNewKinematics.md.

I suggest you start from the latest code on the dev branch (not v2-dev), because I recently made some changes to the Kinematics interface classes there to support the new generalised Cartesian kinematics.

The X movement could in principle be done in the same way as segment-free delta movement because it looks like the kinematic equations involve nothing worse than square roots. However, it will be simpler for you to implement segmented kinematics, at least initially.

[Alexander Mundy]

Interesting. How are you making all the pivot points exactly the same center to center?

[bondus]

@dc42 Thanks for the hints. Got dev branch running, implemented a Kinematics and got the printer moving. It's moving, but it's not moving right. All the different coordinate systems and origins causes confusion, I need a thinking session with pen and paper
A good thing I discovered was to turn down stepper currents, a lot. I have pounded my endstops quite a lot.

@fcwilt, I need a rational? It's a fun project to get it running.
It is actually a very compact design, the arm can be folded into the tower when not is use. And if the bed is removable or foldable it will be easy to store.
The crane-arm itself has many potential flaws, if you get to far out the stepper has to move much faster than the print head moves, if you get too close to the tower the head moves very fast and the steppers has to be very precise. Proper calibration for non-perfect arms/tower can also be a challenge, but it should be easier than delta.
For most cases Delta and scara are probably better non-cartesian designs than this.

@Alexander-Mundy, I was a bit sloppy when I built them, they are all hand drilled, I might have to redo them at some point. But I used one as a template for the rest, so they are pretty equal at least. Z seems to be pretty straight and at 90deg to the tower when I move the Y motor.
I should get the arms CNC/laser/water/plasma cut, but this is good enough for now.

[bondus]

I got it printing!

The firmware is really nice to work with. Very clean and fairly easy to understand.

Initially I set the motiontype to segmentFreeDelta but that led to slightly bent diagonals. Only one axis is non-linear, the others are linear. Using segmented motion all is fine. I'm getting some "Error: G1/G2/G3: intermediate position outside machine limits"

I can notice that my mechanics is a bit too wobbly to run at any decent speeds. The arm wobbles side to side whenever the nozzle hits the layer below in the print. That has to be fixed for v2

[dc42]

@bondus said in Yet another kinematics:

I'm getting some "Error: G1/G2/G3: intermediate position outside machine limits"

That means that although the end point specified in your G1, G2 or G3 command is reachable, there is a position between the current position and the end point that is either outside the physical capabilities of your machine, or outside the M208 limits you have set. Using segmented kinematics, if the position at which the homing switches trigger is outside the M208 limits, you will get this if you try to move away from the homed position using a G1 command. The workaround is that after homing, use either a G0 command or a G1 S2 command to move from the homed position to an allowed position. You can do that at the end of the home all.g file.

[bondus]

@dc42 I figured it was something like that. It was easily fixed by changing M208 Z to a higher value, it's just a prototype so far.

I guess I should implement LimitPosition() as well. Just a like a delta the possible reachable coordinates narrows when you get above a certain Z, the upper sled would run out of rail.

But for now the firmware is good enough to keep my wobbly prototype running.

[ScruffyGuy]

@bondus

Hey there,
Just found out about the Kappa 3D . I would love to build a Printer Based on it's design.
Are you still working on this firmware? Unfortunately I don't understand much about Kinematics so I won't be of any help, but I still would love to see this get into RepRapFirmware.

Best Regards,
Scruffy

[bondus]

I dismantled that printer a long time ago. And honestly it is a poor way to build a printer. It was pretty wobbly side-to-side, some proper engineering might make it better.

I could dig around for some old code if you want. Mathematically it was not that hard to figure out, old high school math.