RepRap Host Software ToDo?

I have the softare loaded as both binary and source files. I'd like to start contributing to the software side of things. My daily programming language is C# which is not too unlike Java. However, there is a learning curve with the various tools available. I am using NetBeans as of now.

After attempting to look through the code to understand how things are done and why I have only confused my self more. It would be nice if there were some simple documentation that walks through the code and explains the flow.

I'd like to add some simple features such as a menu option to return the working platform back to it default position. I also noticed there are a bunch of remarks where a progress bar is desired. These are things that don't require a complete understanding of the math and could be done by helpers.

It does not have to be an elaborate document. Even a 20 minute forum post would get me started. Explain to me what is going on in the code so I don't need to spend weeks trying to make sense out of it all.

Hey Squintz,

I understand the software a little bit, but not enough to help you out yet. It took me 2-3 separate readings of it to really get a good feel for how it works. i'd say read it for a couple hours ever few days and after that you should really start to understand it.

i pinged adrian, so hopefully he can get in here and give us a high level overview.

I really did not get into it till I had a machine running which has only been the past month.
There is a lot to do but for the most part I am getting it to print and we have seemed to have found the major bugs.
One of the big things Zach and myself would like to work on it the ability to print to a xml file and also software to print from the xml file so then you could have software that does not require a UI. Some of the things I have been working on is the preferance window and adding drop down menus where they could go.

as far as an explanation of the software let me me give it a try.

1. when you load the software you get the menus and workspace image.

2. you have preference window that allows you to set the settings for the machine and ui

3. you can load a STL file which the software draws the files 3d image on the workspace.

4. you have the ability to manipulate the STL image and move it on the workspace.

5. then you have the tools to be able to move and test the steppers and extruder

6. once a STl file is opened and you start the build the stl file is sliced and diced and a perimiter and infill is created for each layer using the preferences this is done with the layer producer.

7. then the producer controls the extruder and steppers on each layer and also turns on the fan.....

8. serial comms are done on a tolkin ring and the controlers are using there own firmware (this is the present electronics and will change in the adruino boards) the steppers have a sync connection so that only one moves at a time. The software has the i/o control for the tolkin ring using an address for each board.



there it is in a nut shell the slice and dice is the part that makes my little mind turn to mush that is Adrian's but it is just a lot of different parts but not to bad when you get into it..

Bruce Wattendorf

Squintz,

Code documentation needs a little work, and I'm sorry but I've no idea how Adrian's slice & dice stuff works inside. Must look someday.

We're mostly Eclipse users, but I recognise the right of Netbeans users to exist It might help if you document how you get the project going under Netbeans for the next person to come along.

Vik :v)

Vik Wrote:
-------------------------------------------------------
> Squintz,
>...
>It might help
> if you document how you get the project going
> under Netbeans for the next person to come along.
>
> Vik :v)

That sounds like a plan. It was a little tricky to get going but now that it is done I know how I did it. I'll install it on another machine just to confirm the steps and will send you some documentation.

Edited 1 time(s). Last edit at 12/02/2007 10:52AM by Squintz.

Mea culpa! I have yet to document how the code deals with STL files and slices them. Nor will I do so this weekend because I am trying to fix a bug in it found by some bloke called Vik :-)

However, here's a quick overview.

STLs are read by a standard Java3D file format handler that returns them as Java3D objects. These are basically lists of triangles in space - three doubles per corner. When you read an STL object in, RepRap forces you to assign a material that it's made from; this is attached as a Java3D user attribute to the triangulation.

Slicing at height Z is done by running through all the triangles one material at a time (so all the printing for one material in a given layer is done before it moves on to the next material in that layer in a multi-material system). Each triangle has Z coordinates that are:

1. All below the slice - add that triangle to the triangulation of the bit already built.
2. All above the slice - forget it.
3. Two below, one above, or vice versa - add the line of intersection of the triangle with the Z plane to the list of edges of the polygons to be laid down at this layer. Add the triangle or quadrilateral (split along a diagonal to make two triangles) below the Z plane to the triangulation of the bit already built.

The triangulation of the bits already built is used in the simulation window to show the object up to the plane that is currently being laid down.

We now have a set of jumbled line segments that ought to meet end to end (roughly - floating point rounding problems etc) and that form a collection of polygons in this layer to be laid down. Polygons may be inside each other (holes in solids) and inside them (islands in holes, and so on) or disjoint. But they should never cross. This is all pretty crappy high-entropy data because of the totally useless and ustructured nature of STL files. If STL had been designed properly you'd know what connected to what all the way down.

The first problem is to join the line segments up end-to-end - it is in this code that Vik's bug lies. The way this works is to slap a rectangle round the lot (easy, because you can track max and min X and Y coordinates as you generate the segments) and then to divide that in a quad tree. The terminating conditions for the recursive code that makes the tree is that a quad contains either no ends, or just two ends of different segments. The trick here is obviously to ensure that a quad division does not go down between two ends that really need to be joined so that they wrongly end up in two different quads; it is in this bit that I am bug hunting.

The program then runs round the polygons from quad to quad linking the ends up.

We now have a set of polygons for RepRap to outline and to fill in. But a list of line segments is a very non-robust representation of a polygon for operations like zig-zag infill, and also it's hard to offset. You need to offset the polygons to make smaller ones inside because the stream of polymer is not zero thickness, so - for example - you need to run the write head slightly inside the polygon you're going to create to outline it. Then the zig-zag infill needs to be a zig-zag in a smaller polygon inside the first offset polygon too.

A set-theoretic (or CSG, or Boolean) polygon representation is robust and is easy to offset, so this is what RepRap creates. It uses a trick invented by Tony Woo called the alternating sum of volumes. You find the convex hull of the polygon, turn that into an intersection of linear half planes (that is things like Ax + By + C <= 0) for all the polygon edges that lie on the hull, then work out the convex hulls of the bits that _wern't_ on the hull and subtract them, then the bits that are left from that and union them, and so on recursively.

It now has a CSG representation of the entire layer as unions and intersections of linear half planes. This can be offset simply by changing the C values - really easy. It is also easy to cross-hatch - you just generate a load of parametric lines and work out the parameter values where they cross the CSG boundaries. For each segment of hatch you membership-test its mid-point against the CSG expression to find out if it's solid or air.

All this CSG stuff is made very fast and very efficient by another quad-tree division. This time that looks at the contributions of each linear half-plane to each quad. Such a plane either cuts the quad, or contributes Universal or Null set to it. In the latter two cases the CSG expression can be simplified using De Morgan's rules inside the quad. Once again this structure can be built recursively, giving a fast-to-search structure both for outlining and infill hatching (credit for this idea: my old chum John Woodwark in the 1980s).

The outlining is done by running round the quads stitching up polygons between quads that contain an intersection or a union of just two half-planes (in other words, they contain a corner). Because of the robustness of the CSG representation this process is guaranteed not to to have any gaps or overlaps (unlike the original crappy STL file, and unlike the unstructured jumble of line segments derived from it).

The infill zig-zag has its ends stitched together by a follow-round-the-edge heuristic that reduces (though not minimises*) the in-air not-plotting movement.

[*Clearly to minimise the in-air moves would need a traveling salesman solution, so we don't have time for that :-)]

Having typed all this, I think I'll put it on the wiki next week as an overview and a start to the detailed docs...

Edited 3 time(s). Last edit at 12/02/2007 10:33AM by Adrian Bowyer.

---

best wishes

Adrian

[reprap.org]
[reprapltd.com]

What's going on in the following code? What is the purpose of org.gui.RepRapBuild class and why is it being added to Box?

//Y_AXIS displays from Top to Bottom instead of Left To Right
Box builderFrame = new Box(BoxLayout.Y_AXIS);

//Add the Builder label to the Box
builderFrame.add(new JLabel("Builder"));

//RepRapBuild is a reprap.gui.RepRapBuild class
builder = new RepRapBuild();

builderFrame.setMinimumSize(new Dimension(0,0));
builderFrame.add(builder);

I have a suggestion to refine the host software: I use an old VGA monitor that I would like to dedicate to the RepRap. Problem is, the preferences window is too high to fit in the screen (640 X 480) and it cannot be scrolled down or right. This limitation also happens at 800 X 600 resolution. Do you think it would
be possible to split the preferences window into several smaller windows
that could fit into a 640 X 480 VGA? In this way, the total cost of the
RepRap project could be reduced by using our older monitors.


DREW

I think that a better solution would be to put scroll bars on the menus.

---

best wishes

Adrian

[reprap.org]
[reprapltd.com]

RE: Preferences window

It works great now at 800 X 600 with Host software V1.x

Thank you guys!

DREW