Old RepRap project FAQ

From RepRap
Revision as of 04:56, 12 January 2006 by ForrestHiggs (talk) (version migrated from twiki)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

-- Main.ForrestHiggs - 11 Jan 2006

FAQ

[Olliver] Question: What directions are our X,Y,Z axes? Same as AoI?

[Bowyer] Answer: I think we need a RH coordinate system (thumb = X, index = Y, 2nd = Z) and it would seem reasonable for Z to be the vertical/layer direction. But of courseany convention will do.

One thing that is really useful in the Stratasys software is that you can tumble your object about at the last minute to get the orientation right for manufacture, an idea we should emulate, I think. It allows you to point at a face with the mouse and say "make that +Y" o.w.e.; looking at Java3D thatshould be simple to implement - it has a ray-trace query.

[Olliver] Question: Should I design the stage to fit in place of the top spider, or to fit on it?

[Bowyer] Answer: I think so - when this sort of decision comes up I have a sort of priority list that goes... Make it...

  • with RP wherever possible.
  • as modular as possible.
  • as simple as possible.
  • as easy to repair as possible.
  • as reliable as possible.
  • as strong as possible.
  • as accurate as possible.

Conventional engineering would doubtless put 5 and 7 much higher up the list.

But conventional engineering doesn't have self-repair as implicit, nor Darwin to assist...

I'd welcome others' thoughts on different orderings of that list, or on additions and subtractions to/from it.

[Higgs] Question: I ran across Hans Wargers' turntable design in the Wiki.

http://staff.bath.ac.uk/ensab/replicator/Downloads/Wargers/wargers.html

Did anything come of this design? It looks easy enough to fabricate.*

[Bowyer] Answer: We haven't done anything with it; I don't know if Hans has.


Calibration

[Higgs] Question: I've read through the postings and the wiki and it seems to be that we're looking at a .5 mm accuracy for reprap. To that end I've seen a lot said about selecting thread pitches and stepper steps to get that to happen. I've probably missed the rest that got said about this issue but with what I have read it seems to me that we may have a soft place in our development programme at this point.

Looking at the pic in Vik's "Screw-driven axis posting on 17 December I couldn't help noting that in the lateral direction that Vik is depending on the rigidity of those steel rods and the accuracy of the pitch of the threads on that drive rod. It struck me how simple it would be to not get the two ends of the assembly exactly flat and to get just a little torque into the overall track and platform. That small distortion would introduce errors in the whole system. Similarly, if we don't work on an accurately flat working surface we have similar problems.

Introducing rigid non-polymer materials into the design such as Vik's steel rods and keeping the dimensions of the reprap small will, of course, reduce errors. What happens, however, when we try to make more and more of the reprap out of polymer? We'll start getting a system that expands and contracts substantially with themperature. We'll also start getting creep and most of all we'll start getting load deflections magnitudes greater than what we would see if we were using, say, steel.

I'm not trying to say that we ought to think about doing reprap in metal. More what I am doing is wondering how we calibrate a polymer reprap and how we keep it calibrated so that we can assure the desired level of quality control out of the objects that we create.

[Bowyer] Answer: This is something we've thought about, and should perhaps have documented more. Ed and I are using ground steel cylindrical rods 8mm in diameter for this sort of thing which are cheap accurate and strong.

However I agree that the more polymer gets into the RepRap machine the more difficult this sort of thing gets to control. Non-linearities can be allowed for by doing a detailed callibration and making a map, but add dimensions of temperature and RH to that and it starts to get a bit dodgy. Indeed it would probably be easier to run the whole thing in a big cardboard box with a small air-conditioner attached, which I would like to avoid...

The target accuracy is 0.1mm, incidentally. One of the nice things about FDM is that you can build things much more accurately than the thickness of the filament if you allow offsets, in just the same way that (in reverse) you can machine much more accurately then the diameter of a milling cutter.

[McAuliffe] Question: The best way to go seems to be to run once round the perimiter, and then to fill the interior at 45 degrees; next level up you do the same but at -45 degrees. I have a little Java program to do this for one of my polygons; it includes offsets, so you can allow for the width of the deposited stream. I am in a bit of a quandry over this, as I haven't started on Java3D yet which may eliminate much of what I've done. But if anyone wants copies let me know.

[Bowyer] Answer: That sounds like a good approach.

I'd be interested in a copy of that rectangle code. I'm going to work a bresenham function into the PIC synchronisation model I've been building so that it should be able to accurately produce a line co-operatively beetween otherwise independent axis controllers. The synchronisation is based on an extra clock/sync line between the co-operating devices and is very simple (along the lines we previously discussed).

That synchronisation is proceeding well, and once it goes I'd like to add a little functionality to the stepper test app for printing lines, rectangles and blocks. So I'll start by using your bresenham implementation, and it would be nice to have your block drawing code thrown in there too. The bresenham will probably only work in two dimensions. I assume it is a lot less useful in the third dimension.

As you say, it might be partly throw-away code, but it's going to be useful for testing (and playing).

I have a little trouble and strife that is dragging me away (as you get around this time of year) so this won't be finished as soon as I'd like, but it's hopefully not too far away.

By the way, I'm currently using a dummy device to simulate plastic extrusion. It currently only does "start extruding" and "stop extruding", indicated by an LED. But this seems overly simplistic to me. What are the likely capabilities required by an extrusion head?

For example, it may be something like:

  • Extrude at speed n
  • Stop extrusion (possibly different from speed 0)
  • Select material n
  • Set temperature for material n (0 to turn off heater)
  • Wait for current material to reach temperature
  • Get current material extruder temperature
  • Get quantity of material remaining (maybe just 0 or 1)
  • Notify address x when material is low


Does that seem about right? Any others or alternatives?

Perhaps there would be multiple devices. An independent temperature sensor, etc?

Perhaps there is no need to select a material. Each extruder could be independent and you could just print parts by extruding from the appropriate head (taking into account it's position offset). On the other hand if it turns out to be a carousel scheme (picking up a head, like some plotters and automated milling machines do) then we might need to select the material. The carousel scheme does have the advantage that you can support a greater range of materials without requiring a stronger mechanism or lots of space, but it's also more complicated.

With a carousel, perhaps there should be a separate device for controlling the carousel as well, so the extruder API might be simpler or different.

For example, with mechanics to release the head as soon as it reaches the carousel and lock as it pulls away, it could change heads by just moving to the right co-ordinate, then the API could be just:

Extuder:

  • Extrude at speed n
  • Stop extrusion
  • Set temperature, notify address x when reached
  • Get temperature
  • Notify address x when material is low

Carousel:

Select material n

Or perhaps this could just be a generic motor controller.

Then again, perhaps carousels are best left to Darwin if it's going to add more initial work.

For my repstrap contraption, I'll hopefully get away with just a single head so it's not important but it'd be nice to get something more or less along the right lines committed to code.


Controllers

[Bowyer] One of the provisional decisions we made a while ago was to have Distributed control - each component of the RepRap machine will have its own microcontroller to make it semi-autonomous; they'll all talk using Simon's token ring or I2C.

The idea is to make the machine as modular as possible so that people can easily add their own new write heads or whatever without changing the rest of the design.

As we progress it's becoming clear that almost all the microcontrollers will be pretty similar - a PIC controlling some H-bridges and power-transistor switches with a few analogue and/or digital inputs. I now have a hope that we will be able to design a universal PCB for these that you partly populate for each device (the XYZ controller will need 6 H-bridges, for example, whereas the extrude head only uses one). I was thinking of making a PCB with the PIC at the left-hand end and a repeated series of drivers to the right, so when you expose the board to the UV light you just put a folded bit of black card over and under at the right hand end to mask off the parts you don't need. It shouldn't be too hard to design the tracks so that works.

Ultimately the RepRap machine will be making its own circuits, of course, and all such messing about will go away.

At the moment the development cycle seems quite fast too - just edit a C program, compile it, and download it into the PIC. I don't use an ICE; just a scope and a lot of debug information reporting in the C code. It normally takes me about two days from picking up a soldering iron to get to a working device, after which I draw out the circuit diagram, add comments to the code, and write the document...

I agree that a more powerful board would possibly allow the elimination of the PC from the system, but users are going to need web access to download designs, and some quite heavy disc space to store lots of them anyway; I suspect a PC will be needed for that, so we might as well use it and bask in the excess computing power and speed it offers us above our needs...