STL Slice & Dice - Help Wanted!

Re: STL Slice & Dice - Help Wanted!

Stan Raczynski — Fri, 27 Apr 2012 01:29:31 -0400

Re: STL Slice & Dice - Help Wanted!

Tracy — Tue, 04 May 2010 18:41:58 -0400

(Expanding on another reply)

I'd be glad to share my 20+ years of GCode use.
Absolute Vs Incremental positioning is simple but the difference can be devastating....

Incremental means to move a given distance. x1 means move one unit
Absolute means go to that position...x1 moves to position x1 from wherever your at now.

Absolute is like "go to the oak tree" while incremental tries to get you to the oak tree with "go north 3 steps, now east 4 steps"

Incremental programming is very dangerous. Make a mistake and every move after that is in the wrong position. Absolute is self correcting and only the move in error is effected.

Re: STL Slice & Dice - Help Wanted!

greenarrow — Sun, 13 Jul 2008 10:09:41 -0400

I was thinking the same, though I haven't read what zach was asking, just the last few posts here. all nopheads parts have been made with skeinforge, which are indisputably the best objects anyone has printed.

Re: STL Slice & Dice - Help Wanted!

Kyle Corbitt — Sat, 12 Jul 2008 12:05:24 -0400

Am I missing something, or does skeinforge pretty much fill the requirements Zach was asking for here?

Re: STL Slice & Dice - Help Wanted!

Ru — Sat, 12 Jul 2008 04:36:24 -0400

Quote

I wonder if it might not be simpler to adapt an existing open source Gcode generating program, instead of writing our own?

This would of course be the best solution, but I think it is reasonably safe to say that if this *could* be done, it *would* have been done.

Our particular needs (slicing and dicing) are sufficiently different from the way you'd run a milling machine that it will probably take more than a a small extension to make it work. Once you've made the software break the model down into layers and generate useful infill, you've done most of the work to writing your own CAM system anyway.

Indeed, it could forseeably take a little longer, as you'd need to learn and adapt someone else's code; seldom an easy task ;)

Re: STL Slice & Dice - Help Wanted!

Ralith — Fri, 11 Jul 2008 19:04:12 -0400

Just throwing this out there: I wonder if it might not be simpler to adapt an existing open source Gcode generating program, instead of writing our own? One such seems to exist: [gcam.js.cx] , although it will require some degree of extension (probably not too much) to add support for thermoplastic extrusion machines such as the reprap as well as the CNC mills it currently supports.

Re: STL Slice & Dice - Help Wanted!

james — Thu, 10 Jul 2008 18:19:43 -0400

I've placed some python code in svn at trunk/users/vasile/stl2gcode. It takes an stl file, converts it into povray format, slices it into png-formatted layers and then outputs gcode for each layer.

You'll need stl2pov to make it work. I built a .deb file if anybody needs it.

I haven't tested it on a physical object because I haven't finished my reprap yet.

But, I'm fairly sure it's deficient in a few areas: (1) I haven't done any scaling, so objects will be stretched or squashed along all axes. (2) I haven't delved into the gcode, so I imagine that needs some serious tweaking.

The good news is it slices and produces gcode. Personally, I don't want to make stl files in AoI. I want to describe things in python or lisp or perl and have a program generate pov files. This code is a step toward making that feasible. Code is GPLv3. Patches most welcome!

Re: STL Slice & Dice - Help Wanted!

mellery — Sat, 01 Mar 2008 13:26:47 -0500

> Will it be able to handle every gcode known to
> man? hell no.

well my newest version comes pretty close, though i updated to hardy and that did bad things to java and gcc-avr... gotta fix that first

Re: STL Slice & Dice - Help Wanted!

ZachHoeken — Sat, 01 Mar 2008 11:58:07 -0500

"So what does making the comms to the machine G code actually achieve?"

sorry if i reacted strongly to that. all i really mean was that if you are going to criticize peoples work, you better have a solution or an alternative to back it up.

in addition to that, we're going to great lengths here to build something that *everyone* can build. if that means doing surface mount stuff, expensive stuff, or using hard-to-get parts, then it doesn't help much.

sorry if it was seen as personal, but it really wasnt. i respect and admire nopheads work alot. infact, i've adopted some of it in the arduino, and am subscribed to his excellent blog.

Re: STL Slice & Dice - Help Wanted!

Forrest Higgs — Fri, 29 Feb 2008 16:04:27 -0500

"If you have a better way (that people can easily replicate... no "i found this piece in my junkbin"), please show us, document it, and prove it works. Until then, please let us get back to work."

Whoa! Little harsh there. :P

Re: STL Slice & Dice - Help Wanted!

ZachHoeken — Fri, 29 Feb 2008 15:53:28 -0500

nophead Wrote:
-------------------------------------------------------
> Zach,
> So what does making the comms to the machine G
> code actually achieve? You still can't drive an
> existing CNC with RepRap without replacing the
> electronics. You can't drive RepRap with an
> existing CNC control program because they accept G
> code and output it on a parallel port, they don't
> send it down a USB port.
>
> You can feed G code files like those from Eagle
> to your machine but it is a lot easier and more
> flexible to parse those on the PC and output via
> the RepRap host bot interface as somebody has
> already I think. That has the advantage of working
> on the old and new electronics.

Listen man, not everything has to be the absolute perfect solution.

GCode fills a missing niche in the RepRap technology. There are quite a few pieces of technology out there that generate gcode. Creating a basic gcode parser on the arduino is possible, and mellery and blerik stepped up and made it. It works well, and it can get the job done. Would you prefer I slap blerik in the face and tell him that I only want perfect solutions? No, I want to print and if someone brings me a solution that is one step closer, I'll take it. Plus, these are nice guys.

Is it the best route? probably not.
Will it be able to handle every gcode known to man? hell no.
Does it do a satisfactory job and allow people to quickly use gcode on their reprap machine? yes.

I'm not entirely sure what the alternative you want is. The current version of SNAP cannot handle all the commands that gcode can do (even our limited version of gcode). for example, feedrate and 3-axis DDA moves. what you're proposing (parse gcode on the host) means that we have to come up with a completely new host communication protocol. that in and of itself is a huge undertaking.

Nobody is saying that this is the ultimate reprap solution. People here have a desire to be able to use gcode on their reprap machine and they are implementing it in a way that doesnt require drastic changes.

This firmware is *only* for using gcode on your reprap machine. Its not for driving other CNC systems, nor for use with other CNC applications. Its not designed for that and to bring it up its ridiculous.

If you have a better way (that people can easily replicate... no "i found this piece in my junkbin"), please show us, document it, and prove it works. Until then, please let us get back to work.

Re: STL Slice & Dice - Help Wanted!

emt — Fri, 29 Feb 2008 15:16:48 -0500

Hi Nophead

Most CNC machines have PLC interfaces these days. M functions can be trapped & acted on in the PLC. I have a small machine that will shortly have a common interface to both the single Arduino and a PC based CNC using 2 parallel ports. I believe I can set up the CNC to provide temperature control using a spare analogue or PWM output.

The advantage to me is I can use a single 3 axis system for both replicating and milling. Initially I was concentrating on making it a pluggable switch over and that may well be the way to go. However the G code option allows me to use acceleration and deceleration with the drives and the possibility of using servo drives. Plus the CNC has full jogging and other controls for setting including MPG which is a boon when setting the Z axis. I have also used the CNC for many years and very familiar with it.

Re: STL Slice & Dice - Help Wanted!

nophead — Fri, 29 Feb 2008 14:15:44 -0500

Zach,
So what does making the comms to the machine G code actually achieve? You still can't drive an existing CNC with RepRap without replacing the electronics. You can't drive RepRap with an existing CNC control program because they accept G code and output it on a parallel port, they don't send it down a USB port.

You can feed G code files like those from Eagle to your machine but it is a lot easier and more flexible to parse those on the PC and output via the RepRap host bot interface as somebody has already I think. That has the advantage of working on the old and new electronics.

Re: STL Slice & Dice - Help Wanted!

ZachHoeken — Fri, 29 Feb 2008 13:16:02 -0500

blerik: i'll add that in for sure. good work.

ian: thanks for the suggestions, i'll try and implement them

nophead: they'd have to figure that out themselves. one easy solution is to use the arduino electronics with their existing CNC machine. nobody has done it yet, so we cant give you an exact example, but the potential exists.

also, its important to implement them as custom commands, so that someone could use this as a real CNC controller if they want. for example, i'm going to try and use my mcwire machine as a PCB router and it would be nice to be able to use all the pre-existing Eagle -> GCode converters.

Re: STL Slice & Dice - Help Wanted!

nophead — Fri, 29 Feb 2008 11:21:56 -0500

>I am thinking here of users running the code on an existing CNC machine with an extruder attached.

How does that work exactly? How do the non standard codes thet control the extruder speed and temperature actually get to the extruder if you are using an existing machine?

Re: STL Slice & Dice - Help Wanted!

emt — Fri, 29 Feb 2008 11:10:50 -0500

Hi

Running GcodeWriter I see the following message frequently repeated:-

RrHalfPlane.find(): plane not found!

Also what controls the speed as it seems to run at actual extrusion speed? Presumably it could run a lot faster when it is only producing a file.

If a real running file is to be produced a method of setting will be needed. This could be G28 homing followed by an absolute move to a suitable start position. It occurred to me that an INI file could be useful where this absolute information is stored as I guess this will be different on every machine. This could be read by the GcodeWriter and appended into the appropriate position in the file.

Also for real G code consistency M30 needs to be implemented as end of file.

Also a few real CNC machines need the decimal point in the F word to ensure the correct feed is used.

The other thing I would strongly suggest is that if possible the G code is converted to absolute mode. This based on years of experience of people running incremental programmes with out first jogging the machine to the correct start position or interrupting a job, jogging away and forgetting to jog back. The result at the very least is a scrapped job but frequently machine damage as well.
A G28 implementation at the beginning of the file should at least trap an incorrect start position.

I am thinking here of users running the code on an existing CNC machine with an extruder attached.

None of this is a criticism of what has been achieved which is very impressive, just suggestions to help the development.

Re: STL Slice & Dice - Help Wanted!

Anonymous User — Thu, 28 Feb 2008 16:24:54 -0500

Ok, got it,

Attached you'll find the java source for GCodeWriter ported to the latest revision (1369). Also attached are minimug.nc and RepRap.jar for those that don't want to compile it.

To use it, change the following preferences:

Geometry=gcodewriter
Port(name)=/dev/ttyS0 or the equivalent on your computer to print directly to the Arduino
Port(name)=stdout to print to standard out (for testing)
Port(name)=filename.nc to print to filename.nc

When the print is done, check the output for errors before printing!

Zach, can you add these files to Subversion? The only lines added to the project are these:

else if (geometry.compareToIgnoreCase("gcodewriter") == 0)
return new GCodeWriter(prefs);

And the GCodeWriter.java code, so it'll break exactly nothing unless you want it to.

Re: STL Slice & Dice - Help Wanted!

ZachHoeken — Thu, 28 Feb 2008 15:10:04 -0500

awesome. i'm looking forward to playing with this. yay!

Re: STL Slice & Dice - Help Wanted!

Anonymous User — Thu, 28 Feb 2008 13:57:33 -0500

Zach,

You can try and merge the diff file that is on the first page. It should merge without too much problems. It prints to stdout only though. Or you can wait for me to get the subversion head version working. I found that my problems are related to java3d. I use a too old version. I tried installing the newest version yesterday, but found out really late I also need jogl libraries. So I'll be testing that later tonight.

It really is too bad the RepRap host code needs Java3d 1.5.1 and not 1.5.0, because that version comes standard with the newest osx 10.4.

You can also try printing with the minimug.nc file I generated previously. It probably needs some work in a text editor, but the toolpaths themselves are straight from the host, so they should be good.

--Blerik

Re: STL Slice & Dice - Help Wanted!

ZachHoeken — Thu, 28 Feb 2008 12:54:14 -0500

Adrian, the current heavyweight champion of slice/dice has fixed the host software! The current subversion build successfully handles the minimug file.

I'm putting the povray stuff on hold and admitting defeat. Yay!

blerik: lets take the gcodewriter stuff and get it into the current subversion. i'd like to start using that and making it my primary print output format.

Re: STL Slice & Dice - Help Wanted!

Adrian Bowyer — Wed, 27 Feb 2008 12:21:10 -0500

Yes - I didn't mean to imply that all STL files were incorrect; far from it. It's just that in general enough are wrong to mean that any algorithm has to be robust against geometrically small but topologically inconsistent errors.

Re: STL Slice & Dice - Help Wanted!

Anonymous User — Wed, 27 Feb 2008 12:07:15 -0500

I did some research on the printed object stl files (the ones with modifications) here: [reprap.org]

I checked out Bed-corner-1.1.stl, X-motor-bracket-flattened.stl and corner-bracket-degroof-vik.stl. All three are perfect. vertex connectivity is sane (each point is a part of 3 or more triangles), and the vertex-to-vertex rule is never broken, which means the meshes are watertight. And these are not trivial meshes. So it is possible to get proper stl files for objects. And it seems the host software likes these objects better (some were created to get rid of overhangs, and some to get around printing bugs). Slicing these meshes should be possible using my algorithm. I'll try and cobble up something over the weekend...

--Blerik

Re: STL Slice & Dice - Help Wanted!

deadgenome — Tue, 26 Feb 2008 16:59:37 -0500

ummm.... the inside or outside of a given polygon is represented by the order the polygons points are listed. This is what is used to calculate the surface normal which is then use to calculate the dot product between that and the camera to work out the backface cull. If it is positive, the angle is less than 90 and the face is drawn, if it is negative, the angle is more than 90 and the face is culled.

Re: STL Slice & Dice - Help Wanted!

Anonymous User — Mon, 25 Feb 2008 11:56:17 -0500

I'll just keep working on the GCodeWriter, and leave the slice and dice be for now. It works good enough for simple stuff. And for really complex stuff, you can always resort to raster scanning* like the CandyFab guys do. Your printed objects will look like crap, but they will be functional.

--Blerik

* Alternating between X and Y scanning for each layer of course

*edit*

Did some more work. Temperature works now, and writing to a file as well. It even prints to the serial if you leave it as default (had to get the filename from somewhere, so I used the Port(name) property ;)).

*edit again*
Forgot to mention the magic 'stdout' filename. If the code sees this filename, it prints to stdout instead of to a file. I tried using the canonical unix - (dash) filename, but savePreferences doesn't like it.

Re: STL Slice & Dice - Help Wanted!

Forrest Higgs — Mon, 25 Feb 2008 11:44:55 -0500

Adrian's the man on this sort of thing. He's much more up-to-date on the state-of-the-art. I can give you a bit of a thought experiment, though.

Suppose you have some object that you've confected and you put a triangular mesh around it prior to generating an STL. Okay, if the mesh is sound, knowing what is inside the object and what is outside is a bit of a trivial exercise.

Suppose, however, that your object, usually as a result of flaws stemming from having done boolean ops on ideal solids to generate more complex forms, has flaws where, for example, all or part of a single surface projects into the object. When you apply a triangular mesh to this flawed object you are going to perforce generate a mesh that isn't sound. Following the logic to it's bitter end, without a sound triangular mesh you can't be for certain that your tests for sidedness and inside outside, especially if you have a triangular projecting through or cutting another, becomes problematic.

The question then is whether you can find the errant triangles and fix them via your code. That's quite a nasty problem. That's why put myself in the loop. I can see the consequences of stuff that code has a difficult time spotting in flawed slices and especially flawed toolpaths.

I've worked with AoI quite a lot and have regularly encountered situations where this sort thing happens.

Re: STL Slice & Dice - Help Wanted!

Adrian Bowyer — Mon, 25 Feb 2008 11:36:02 -0500

> Are you seriously saying that modeling apps don't even know the difference between the
> inside and the outside of a solid?

Yes. It doesn't matter for graphics because the ones that are wrong are almost always very small, or at least very thin. But those do matter for manufacture because everything has to really join up.

> Are you allowed to call your files .stl when the contents don't even look like stl?

Many do...

> I think AoI uses CSG internally, not sure if you can export it. And PovRay of course uses
> CSG in its scripts.

All these system have CSG _operations_. But those mainly act on boundary-representation objects, not CSG objects. Once it gets there, RepRap uses a CSG _representation_, which is very tough, and is guaranteed (for example) to have no leaks. It consists of unions and intersections of planar inequalities. That is:

P1: a1*x + b1*y + c1 <= 0
P2: a2*x + b2*y + c2 <= 0
P3: a3*x + b3*y + c3 <= 0
.
.
.

Polygon = (P1 U P2) ^ P3 U (P4 ^ P5)

and so on, where U is union and ^ is intersection.

Re: STL Slice & Dice - Help Wanted!

Anonymous User — Mon, 25 Feb 2008 11:13:06 -0500

@Adrian and Forrest:

Are you seriously saying that modeling apps don't even know the difference between the inside and the outside of a solid? I find that very hard to believe (I'm naive, I know). You'd see it instantly in the app when a triangle is inside out. Backface culling discards the triangle, and you see a hole. I can accept a triangle that is inside out, but connected properly to its neighbors (happens when the neighbors overlap). But not a triangle mesh with one reversed triangle. Hardware shaders rely on the right hand rule to be correct. Most 3d apps I've checked (ok, lots of games) seem to do alright. Am I really naive now?

Does AoI also export stl meshes that violate the vertex-to-vertex rule? Are you allowed to call your files .stl when the contents don't even look like stl?

--Blerik

*edit* @Forrest:
I think AoI uses CSG internally, not sure if you can export it. And PovRay of course uses CSG in its scripts. Some people already use PovRay to slice stl files, might as well make the objects in PovRay then. There are very nice gui editors for PovRay.

Re: STL Slice & Dice - Help Wanted!

Forrest Higgs — Mon, 25 Feb 2008 10:58:25 -0500

LOL! More a pragmatic one, I think.

"Especially so as we know that there is a robust representation (a boolean one) if one can get to it..."

Ideally, or is there actually operational code out there, open source or closed, that expresses the ideal? (:P)

Re: STL Slice & Dice - Help Wanted!

Adrian Bowyer — Mon, 25 Feb 2008 10:45:26 -0500

I see the point, but that is a slight counsel of despair, I think. Especially so as we know that there is a robust representation (a boolean one) if one can get to it...

Re: STL Slice & Dice - Help Wanted!

Forrest Higgs — Mon, 25 Feb 2008 10:40:18 -0500

Right now, I do a visual inspection of each layer's toolpath display before I do a print. I store them all in a file and then cycle through them looking for problems. I've also got a rudimentary editing function that let's be repair bad layer toolpaths. I've worked with solids modeling since the late 1960's on and off and I've never seen a perfect solids modeling app. There are so many special cases that often conflict with other special cases that writing a package that always gets everything right is, imo, a bit like hunting for the Holy Grail.

Thus, I advocate not so much trying to make a perfect app, but rather creating an app that allows you to scan for problems and fix them when you find them. You can get usuable toolpath files if you put the user into the loop. :)-D