Showing posts with label 3d printer. Show all posts
Showing posts with label 3d printer. Show all posts
Lets digress.
I figured a small 3d printer would be a good place to experiment - after all, the print volume is expandable without significant change in the electronics or software. And smaller things - to a certain scale - are easier to build than large things.
So I picked 36 cubic inches as a arbitrary figure and started designing.
I don't like the idea of a z-axis table. What if I had, say, a T-Rex skull, and I was struck with the desire to print a doily atop it? Z-axis tables impose limits of volume and weight to the things that you want to print upon. Arguably, most printers are interested in the creation of separate parts that are later assembled into interesting objects, but I come from a device-modification background, and think the ability to append is what raises the 3d printer several notches above more traditional forms of material manipulation.
So z-axis controls the printhead height directly. Leadscrews - ala Darwin, et al. are an excellent method of lineal actuation - in use for probably two hundred years to control machine tools.
That being said, I am being seduced by the idea of hydraulic cylinders. Small, low pressure cylinders are quite easy to build and plumb.
But I'm not seduced yet, so leadscrews it is.
At first I was planning to have the y and x axes raised by a set of z-axis legs, but this meant a number of leadscrews running at once for vertical translation. There is a lovely design involoving ballchain that the Darwin uses, but I don't like having to use that many jackscrews.
So I decided to have the z-axis raise the printhead itself, and started cutting out parts on that theory.
While tinkering together a mockup this week, I realized that structurally it makes more sence to have the z-axis raise the y-axis.
This allows an 'overhanging beam' style of printer, which gives a lot more access to the area underneath the printhead.
Essentially a bastard combination of a hammerhead and a kangaroo crane. With the ability to translate along the x-axis, although as I've pointed out before, polar coordinates could be used with a rotation along the x-axis.
At first glance, this looks unstable, but seeing as the printhead mass is known, its really a simple job to adequately counterweight and brace this arm.
A 3d printer is a machine tool, and as when constructing all machine tools, solidness and rigidity need to be our watchwords. Luckily, the framework nesscary to control a kilogram printhead to accurate placement of a tenth of a millimeter is a lot easier than controlling a cutterhead with forces of hundreds of pounds and accuracy of a hundreth of a millimeter or better.


'kangahead crane?'
Stepper motors seem tidy because they seem controllable. Pulse it once, see the shaft move x degrees. To move any distance, rinse and repeat. However, in a 3d printer, it seems that most of the time - all of the time is being spent on the R & R.
The problem - from a junkyard point of view - is that stepper motors are not as readily available as ordinary motors. And they need a much more complicated interface than a simple H-bridge or relay.
For a sophisticated mechanism, this is not a big problem. Steppers can be bought online with almost any combination of resolution and power. Stepper control circuit designs and boards are also widely available.
But the point of RepStrapping is to build a 3d printer out of ordianry and simple components.

So why not have a mechanism with a continuous motor that scans the entire print area, and just fire material at the right spots? Slaving the X and Y axes together would produce a slightly slanted scan pattern, but probably not enough to be significant. But slaving X Y and Z together would produce a nasty tilt. Unless of course, the frame was pre-tilted to accommodate the slant.

The biggest difference would be the need for accurate position measurements. With a stepper, you can be lazy and count steps from a starting position. The position's value will drift of course, but only by a small amount, and probably comparably along each scan line.

It seems to me that rather than screwing around with the usual poistion sensors, we should just take a look at the optical mouse. Mount a mouse in a poistion where it can scan a rail as the head moves. The mouse I use now cost $14.95 and claims a 2000 dots per inch sensativity.
being a USB device, to does not require any seperate interface to be used with the host PC, either.

This would also mean that the gcode would have to be compiled into a 'bitmap' format.