Idea: A RepRap Hanging From the Ceiling

Hi,
about half a year ago, when I was building a frame for a Mendel, I started wondering if it was possible to design a printer that uses the inside of a house as its frame? I haven't been able to get the idea out of my head, so I thought I might as well try to build one.

What if we could just skip arms, smooth rods and frames, and just use wires instead? Like this:

This is just the simplified geometry of the idea. I suspect I need at least three wires from the ceiling to even get close to printing a single line reliably in the real world.

The further development of this idea that I like the most is to but all the hardware in one single unit, so the whole printer (except maybe power supply and filament spool) hangs in the anchor points in the house walls and ceiling.

Difficulties

Avoiding rotations around the x- and y-axis (or assuring that every rotation happens around the tip of the print head exactly, but acheiving that seems unlikelily hard) The hanging part of the printer will be subject to forces from the filament and a power chord, and forces from the four wires will not always point in the same direction. All motors must have vertically aligned motor shafts, and accelerations will have to be really low

The special geometry imposes extra work on the math, writing the firmware (or gcode preprocessor) and possibly introducing hardware to help keep the xy-plane wires tight

Finding a reasonable home position without imposing lots of constraints on the print start process and/or the position of anchor points

Potential Rewards

The most compact, easily printed, easily installed and easily distributed RepRap out there

Possibility to retract its strings and park close to the ceiling when not in use. Could make it popular where indoor area is scarce

Extreme print heights (> 1 m)

I already have electronics, motors, power supply lying around, and 9 m of synchromesh cable is purchased. I just need some anchor points, a first version of the CAD and a gcode preprocessor (I'll start with 2d, no z-compensation) in order to try to draw my first open hardware logo. What do you guys think?

The "Finding a reasonable home position"-part turns out to be really easy. I will explain it in the 2d-case first, to avoid unnecessary typing.

The only thing we control in this system, is the length of the three wires. Every possible combination of wire-lengths, (l0, l1, l2), corresponds to a unique point in the avilable print area (a triangle). To map a point (x', y') to the corresponding wire-lengths, all we have to do is place the wires anchor-points in the cartesian coordinate system, and compute the lengths from each anchor point to the point (x', y'). Like this:

When we get 4 anchor points, we get a tetrahedron shaped print volume instead of a triangular print area. The computational work is still only 3 subtractions, 3 squares, 2 additions and 1 square root per wire. I don't expect the atmega to have any troubles with that.

This way of mapping (x',y',z') to (l0, l1, l2, l3) imposes no constraints on where to put anchor points or home position, which is really nice. Keeping anchor point coordinates (xa0, ya0, za0), (xa1, ya1, za1), (xa2, ya2, za2) and (xa3, ya3, za3) stored away somewhere will (hopefully) be all the configuration the user will have to do. I guess getting the 3d coordinates of the anchor point in the ceiling won't be trivial to the user, but it shouldn't be horribly impossible either.

Another thing to keep in mind is that if you have wires from the ceiling, but not bellow, your head will bounce/be pushed up and jumble around if it ever touches a part too high. If you have it like they do in the video, you will not be able to print the room's width, as the wires will collide.

I think I understand what you mean. I'm planning on haveing the three xy-plane wires' anchor points close to the floor, so that they can have some damping effect on the jumbling. These three wires can collide with prints of ceirtain shapes, thats true. It will narrow the printable volume quite a bit.

A pretty wide print unit/carriage will help both with getting a better angle for damping jumbling and for widening the printable volume. I will have that it mind. Did some drawing today, but only on paper. Hopefully I can CAD something postable and show it here tomorrow.

Using only springs/suspended counter-weight to control z-height and keep all lines tensioned seems to give really smooth motion. However, it seems expensible to lose up to one-fourth of our motor torque, just to keep them tight... I can think of two possible solutions to this

A setup with a dedicated z-motor, and no springs at all. This will require the four motors to work against each other to keep the lines tight.

Just avoiding the areas too close to the xy-anchor points.

Since I will have lots of print area anyways, alternative 2 is probably the pragmatic way to go. What I don't like about alternative 2 is that it risks trading simpler software for more complex looks and installation. A hanging counterweight or a tensioned spring, possibly with pulleys would take away all the overall slick looks. It would also make it hard to retract the printer all the way up to the ceiling.

This retract-to-ceiling-feature is something I at least want to try to implement, as I find space-saving important (uhm, well my wife agrees and encourages (ok, forces) me). I suspect that lack of space in peoples apartments are a major barrier to the further spreading of RepRaps.

I'm very eager to test this out in real life now. I have been using alot og time trying to find someone to cooperate with in my hometown, with no luck. Described state of the project in a blog post today at least: vitana.se/opr3d/tbear.

Maybe this SkyDelta design could actually be used for 6 degree of freedom? Or rather 5 degrees of freedom. Anyway similar to the sextupteron. So instead of designing ways to keep the wires tout etc you add 3 more stepper motors but can tilt the head instead. Wouldn't be cheaper, but you might turn an engineering challenge into an advantage.

... some years ago I too had the idea of a 'hanging' printer with 3 roller-blinds (rollos) for the Z-axis and a string-driven horizontal positioner, magnetically 'sticking' to an iron plate, fixed to the ceiling.

Here is the initial post with some links to previous discussions: [forums.reprap.org]

I guess a simple implementation would be a delta printer suspended on strings. If you'd have 3 pairs of parallel strings it should work just like delta arms. Just the movement speed / acceleration / deceleration would be limited by the force gravity exerts. Moving sideways this might be quite slow to avoid backlash. And spooling up the strings without moving the starting position of the arm might be a bit tricky or you'd have to account for it in the kinematic.

... I'm working on more ideas/projects parallel over longer time-spans - so 'not abandoned', but only 'delayed', until it get's more interesting for specific tasks.

In the meantime I've built different mechanics and systems with parallel kinematics and different/innovative driving methodes -- but most of them under NDA's for special projects, so not granted for disclosure

QuotetobbenWhat you're desicribing sounds similar to the SkyDelta without the springs?

Ah right! The sky delta!

Well I don't really know if and how well this idea would work without springs. I'm just spit balling. I guess the more horizontal the strings are the better the x/y acceleration but also more vertical springiness and elasticity. Might have to use stainless steel strings. But X/Y movement is really more important.

Maybe for large scale fabrication and extruding through a large nozzle or something this might be fine with slower speed. The positions of the motors and cranks don't actually have to be symmetrical. Might be an interesting concept for something like cement printing? You could place your motors / spools anywhere in a rough triangle and then calibrate and print. You could sink poles and then string them like you would do a tent. Of course calibration would be quite difficult too.

You would have to use a clever kind of spool, maybe a dual spool with the strings crisscrossing and then tensioned with a third "holder" spool. That way the string wouldn't "wander" when spooling.

Wow, Viktor! I searched your old threads looking for work on the maths and found out you suggested and built a tripod with ball magnets (delta) printer back in 2007! Thats cool!

Anyways, the only maths I found in the thread were simply using Pythagoras to convert (x0,y0) and (x1,y1) into (a0,b0,c0) and (a1,b1,c1). To do a long linear movement with constant velocity we need more information. Chopping every segment into short segments is a solution I know works. Is it the best way, or could we gain efficiency or lots of precision by doing something else?

I tried to find closed expressions anyways. In the attached file I have drawn a system where the hotend moves with constant velocity v. Using Pythagoras, we find

l(t) = sqrt(l_min^2 + (v(t_min - t))^2),

where t is zero at the movement's start, l_min is the length of the orthogonal projection of the anchor point (x_a, y_a) onto the line spanned by v and t_min is the point in time when l = l_min. Now, to find out how motor velocity should change, we only need to take the derivative dl/dt...

I guess needing to compute l_min and t_min before the motion can start is a drawback of this... Does anyone know how delta-firmware does this?

A, B, C is the coordinates of the axis. xa/ya etc is the position of the towers (constrained, xb = -xa for example). oa/ob/oc i the offset / height of the tower endstops. Rod length is the length of the arms.

Inverse formula
I only found information about forward and backward kinematics in the resources. In a way it makes sense since the firmware needs to give the motors constant speeds in small time intervals anyways. Converting the two string lengths (call them A(t_0) and A(t_1)) to a motor speed is a matter of dividing their difference with the travel-time.

Note that the travel-time needs to be computed from the positions and speed given in the gcode.

We know that we start and stop at the correct xyz when using the inverse formula (well, except truncation errors).

Closed expression for motor speed (in 2D)
With my analysis from above, each (potentially long) G0/G1-movement would create 3 equations for motor speeds that depended on time. The firmware could evaluate them continously to update motor speeds, utilizing the full processing power of the CPU.

Since this scheme doesn't chop segments into subsegments, there's no need to comupte more than one travel-time per G0/G1-movement.

To guarantee that we arrive at the correct xyz, we could count steps made my each motor and use the inverse formula-scheme at the end of each line. Would this be neccessary?

I hope I get the time to analyze further, but I don't have a lot of experience with robots and firmware, so please notice me if I'm heading off in an impossible direction here.

BTW talking about motor speeds is a bit confusing because these are step motors and you can address them in relative steps, not motor speed. For example 200 steps per rotation with e.g. 1/16th micro steps etc. But the firmware DOES take acceleration into account to avoid abrupt halts that would lead to jerkiness etc. Generally the firmware splits up a G0/G1 command into small segments (segment length or something in the usual firmwares). Check out the marlin firmware as an example, the code is mostly in a single file and not really that complicated. I'm not an expert about firmware though.

About the formula first I quoted it wrong. Sorry!
ta/tb/tc are the coordinates along the towers and your motor input axis (not A/B/C). The "0" is actually the z coordinate that is set to 0 for calibrating, assuming the print head is probing the print bed. So I think(!) it should actually be:

Then you'll have to look at it a bit different I guess. Instead of varying vertical tower coordinates and one fixed "rod" length you actually have three rods made out of string that are varying their length, and the tower coordinates are fixed. So you'd solve for rod1, rod2, rod3 instead of ta/tb/tc and set the ta/tb/tc to 0. Since the formula doesn't really change you should be able to use stock delta bot firmware. Or simply adjust it a bit and recompile. I'm too tired right now to be sure Here is the link to the marlin firmware kinematic function: [github.com]

If you want to build a stringed delta bot at all that is! A delta bot depends on a parallelogram for the arms to avoid rotating so you'd have to use two strings for each of the three sides. Four strings would be "over constrained" so the string going upwards wouldn't really help I think. So without "double parallel strings" for the three "string arms" of the hanging delta bot the platform would very easily rotate around the vertical axis. This might be a problem anyway of course.

You could also check out the delta bot google group and present your concept there. There are lots of helpful an more knowledgeable people than me there: [groups.google.com]

I get tempted to build since the feedback I get here is such high quality!

You're absolutely right that the existing delta firmware should fill the needs of Hangprinter, it it's just modified to solve for the "rod lengths" =D Thanks!

There is a slight concern with the Marlin firmware in that is uses floats. Rod lengths will typically be long (since a room in a house is the frame), and moves are typically short. Mixing big and small floats give truncation errors. I did a little simulation in C to provoke and measure these errors rather than analyzing. I found that micrometer errors (per computed distance) is not unlikely (code attached).

I've had a look at the exellent Teacup firmware, which uses only integer math. Its wiki page says: "Delta support shouldn't be too difficult to add as well." I'll try that first, but if it proves too time consuming then modified delta Marlin will do the job.

Î wouldn't worry about firmware precision problems too much atm. There is also repetier, another firmware for delta's that uses integer math. But that has the problem with scaling already with large delta bots. You could always divide the scale by 10 of course. Those firmwares are for the 8 bit arduino boards.
Then there is smoothieboard which is 32bit and THEN there is beaglebone black, a complete linux PC on a chip with a cape like BeBoPr. But that gets more expensive and complicated to set up.
----

Wow the sky printer is really cool! The "print quality" is of course disappointing. Not bad for a first design, but it could use some improvement.

In the video you can see how the extruder platform wiggles a lot. So I guess the Z rotation isn't actually the problem but the vertical wiggle is. A parallel wire setup that forms a parallelogram would be more stable but not sure if it would really help that much. The larger the extruder platform the more horizontal the platform would stay, and the more the parallelogram wires would help more. Theoretically the platform can only tilt if one or two of the wires goes limb, so there is a counter force to tilting. You have to make the print head extra heavy. And the further outside you place the weights the better I guess.
The main problem seems to be though that during extrusion the extruder normally "flattens" the extruded material and "scrapes" a bit over the stuff. This is normal but with wires this causes forces upwards and creates slop.

I think this concept is really very interesting because I have the dream of some day printing my own dream house Using really organic shapes. Not sure if you can use clay but maybe a type of cement. Or something that extrudes good. You could install it outside in a large area. But if you scale it up you'd probably have to compensate for the "slop" of the cables. Just dreaming of course! The biggest hurdle would be overhangs and printing ceilings. Of course the material costs for printing a large scale house would be high. But generally this is the best concept for DIY house printing because you don't need large heavy and stiff frames or cranes.

For large scale house / structure printing I'd go for a steward platform with 6 motors resulting in theoretically 6 DOF. So you could tilt the print head on purpose to better print overhangs. Theoretically with a 6 dof print head you could use the sides of the print head to contour around printed areas to smooth them.

They mention an automatic homing system. There are tracking solutions for PC games using web cameras and IR LEDs. That could be used to automatically calibrate and supervise the printing process. Theoretically you could probably have a very clever software that simulates and compensate any expected wiggling and backlash from movement or even wind. Would need some sophisticated algorithm though.

I plan on having the motors on the platform. This makes the design more compact too.

QuoteDejay
The main problem seems to be though that during extrusion the extruder normally "flattens" the extruded material and "scrapes" a bit over the stuff. This is normal but with wires this causes forces upwards and creates slop.

That's why I think three action lines downwards (lines from print platform towards wall/floor) is a good idea. The one action line going to the roof could be made triple and attached to each corner of the triangular print platform to handle forces downwards. Three lines of equal length towards the roof would help keeping the platform flat, and would have no syncing issues since they are driven by the same motor. If this would allow us to skip the paralellogram lines downwards, that would be a nice simplification (no need for bearing at wall/anchor point).

QuoteDejay
They mention an automatic homing system. There are tracking solutions for PC games using web cameras and IR LEDs. That could be used to automatically calibrate and supervise the printing process.

Absolutely, but I think there is a possibility to make the homing process much cheaper and simpler. I sketched it out on the wiki-page. It's basically just putting a detectable point on each of the lines. This procedure forces the linefeed-mechanism to be slack tolerable (which it should be anyways).

... look into the following links of my linked discussion thread - one of them shows my 'string-tripod'-idea with a parallel wire structure:
[forums.reprap.org]

The last concept was a horizontal 2-dimensional wire-head fixed to/along the ceiling -- and three rollos/blinds, arranged 120deg to each other to form a 'self-stiffing' Z-axis, that will lower the printed object without wobbling or complex 3D-movements