Monday, May 14, 2007


RepRap needs your JAVA help!

We are looking for someone to help develop and maintain the RepRap control software. This is an essential part of the project that needs to be be easy and intuitive to use for it to ever gain mainstream adoption. Fortunately, its probably the easiest and least groundbreaking part of the system... and yet still exciting!

The software is the main method of interacting with and controlling the RepRap machine. Unfortunately it is hard to install, needs some UI work, could use some more intelligence with auto-detection/configuration, and has some bugs. The software can also be run in a stand-alone mode without a RepRap machine attached. That means you can get involved in a meaningful way even if you have no interest or capabilities to build the machine. One could do development work without ever having a RepRap machine at all.

There are a variety of tasks that range from simple to hard. Even small improvements to our code would be awesome. As an added bonus, if you agree to take on this challenge, the project is willing to provide free development boards to you. If you are interested, please email directly, or visit our support forums.

To get started now, check out the RepRap Java development instructions.

What about APIs for people to write plugins for other CAD packages?

And what file format does your java software use? Any thoughts of supporting IFC?
I can't access any RepRap Sites except for the Blog. Just not working. And a contact us would be nice so I could e-mail someone.

I'll just add in "about the problem" before the last period to make it more clear.

i think an API would be a great addition. i know that the serial port stuff is pretty basic, so it would make sense to have a class that just interfaces with that.

interesting about the IFC standard. i dont fully understand it, but i support standards.

yeah, our server went down earlier today. it should be up soon. sorry about that!
IFC is an open standard for exchanging intelligent model data. To tell you the truth I don't know if it would be appropriate or not. What I do know is that it's probably going to become the default file format for exchanging 3D model data (maybe along with PDF), at least in the building industry.

Here's a description from the International Alliance for Interoperability (IAI):
"In 1995, the IAI was formed to provide interoperability between the software used by all building project participants. The intent is to provide a means of passing a complete, thorough and accurate building data model from the computer application used by one participant to another; with no loss of information. Industry Foundation Classes (IFCs) are data elements that represent the parts of buildings, or elements of the process, and contain the relevant information about those parts. IFCs are used by computer applications to assemble a computer readable model of the facility that contains all the information of the parts and their relationships to be shared among project participants. The project model constitutes an object-oriented database of the information shared among project participants and continues to grow as the project goes through design, construction and operation."

I can see early support for this format on your part being quite advantageous to the RepRap in the long run.

So how does RepRap work in terms of software at the moment anyway? Does AOI talk directly to RepRap while it prints or does it simply send a file with all the instructions?

I use a program called VectorWorks, for instance, and it would be interesting if it could support RepRap directly.
This comment has been removed by the author.
More semi-relevant info here:

And Nemetschek's new IFC Viewer
currently, the RepRap software works by opening a STL file, which is a standard 3D file that most CAD programs can create. so, we make the object in AOI, then export as STL, and open that for printing in RepRap.

then, it slices it into layers, and computes paths for each layer. it seems like IFC is geared more toward buildings than objects, but if there is enough demand, then someone will build a translator for it.
As far as file formats are concerned, we should be able to read anything 3D that Java3D can read. I think that we should stick to that for the time being.

I hesitate to say it, but when it comes to 3D model APIs, I (and others) wrote the book. See:
It's safer to say that IFC is geared towards the building industry (which includes the need for models of objects) rather than buildings per se. What's makes it interesting (apart from being an open standard) is its ability to provide much more data than just 3D geometry.

It occured to me that this could be advantageous but at the end of the day I guess all a rapid prototyper needs is the 3D geometry.

Keep up the good work. :)

P.S. by the way, what's the story with RepRap and previous RP patents?
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?

Subscribe to
Posts [Atom]