STL Slice & Dice - Help Wanted!

I recently got my bot up and running and compatible with the RepRap host software. Unfortunately, there are still problems with the slice and dice code so I am still unable to print anything. I have very little experience with 3D programming which is a bummer, because I'd love to help with that. However, it seems like this problem is one that we should have looked to outside sources for inspiration/help first instead of trying to do it all ourselves. While 3D modelers are somewhat lacking in open source, 3D renderers are actually very badass.

Enter Povray. If you havent heard of it, google it. Its the same program that I use to render awesome looking raytraced images of the PCB's from Eagle. It is a powerhouse to say the least. I'm fairly sure it has support from major places like Pixar, etc. One of the major advantages of Povray, other than being cross-platform is that it can easily be scripted. Not only are the object/scene files plain text that is fairly easy to generate programmatically, but the program itself can be run from the commandline and supports quite a bit of powerful commands. Needless to say, that bodes well for an automatic slice and dice program.

So, you're probably thinking... great Zach, thanks for throwing us another pie-in-the-sky idea that its completely untested. Then I'll say... come on now, cut me some slack. I dont know if you've heard of CandyFab 4000, but if you havent please check it out. Its an amazingly rad 3D printer that uses hot air and sugar to print large-scale 3D models. I've met the people behind it a few times and they are amazing to say the least. Their website is located here: [candyfab.org]

Now, these guys actually did most of the work for us! They even have a very nice article on how to slice an STL file into bitmaps using Povray, located here: [www.evilmadscientist.com]

Unfortunately, there isnt really an open source bitmap -> path tool (yet!) but that should be fairly easy to write. In fact, I think Forrest may have already written it... (update: check these out: [www.editthis.info])

So, is anyone down to take a crack at this? I already have a ton of work cut out for me. Now that the Arduino stuff is working properly, I need to finish documenting the McWire Cartesian Bot. After that is finished, I'd like to work more on the Arduino GCode interpreter. Since learning it, I've become a gcode fan. Its ugly, but it works damnit.

Here's what I'm picturing: We need something that takes a STL file in, and outputs GCode suitable for controlling a RepRap machine. Most of the work will be in figuring out the best way to glue the components together. It would consist of a 2-stage process:

1. slice STL into 2D images based on layer height. (ideally PNG)
2. create toolpaths based on 2D image and output it.
3. output toolpaths as GCode suitable for a RepRap machine (see reprap gcode thread)

Ideally, it would be nice to take a Unix approach and have this as modular as possible by keeping them separate. One script slices up the STL into images, then the next one dices it up into toolpaths. Finally, the toolpaths are output as GCode with all the necessary extra commands to set temperature, move Z, start/stop extruder, etc.

If anyone is interested in doing it, please reply here and take a shot at it. I have no guarantees, but I do have a strong feeling that this is going to be a potentially very interesting path that could pay off big.

Cheers,
Zach

ZachHoeken Wrote:
-------------------------------------------------------
> I recently got my bot up and running and
> compatible with the RepRap host software.
> Unfortunately, there are still problems with the
> slice and dice code so I am still unable to print
> anything.

Can you tell us what the problem is exactly? I thought that with the SNAP firmware bug fixed, you could at least print the test hexagon.

> Ideally, it would be nice to take a Unix approach
> and have this as modular as possible by keeping
> them separate. One script slices up the STL into
> images, then the next one dices it up into
> toolpaths. Finally, the toolpaths are output as
> GCode with all the necessary extra commands to set
> temperature, move Z, start/stop extruder, etc.

The host software also does this in two passes. STLSlice z-sorts all the STL triangles, and figures out what parts intersect the plane to create some polygons defining the slice, LayerProducer creates the contour toolpaths and the hatch infill. They both work good enough. No need to rewrite it completely. Most CAM software can generate contour paths and infill paths fine as well. Just not the hatch infill RepRap uses.

Outputting gcode instead of snap commands can be done by adapting the NullCartesianMachine code to output it. This would be the path of least resistance. I've already written some parts of it, just struggling with the user interface bits (and the fact that I do not have a functioning RepRap, which makes testing a bit challenging).

I'll see what I can do this weekend.

*edit*

> 1. slice STL into 2D images based on layer height. (ideally PNG)

PNG is far from ideal here. You want a vector format. Otherwise you throw away the vector info in phase 1, and need to reconstruct it in phase 2 (since it is the contour toolpath already).

--Blerik

Edited 1 time(s). Last edit at 02/22/2008 11:39AM by blerik.

I've written a couple of 3d engines already (in flash and haXe) and have written a file parser for x3d for one of them, so I could probably help out... my thoughts would be that if x3d (or another 3d format with an xml tree, but hey x3d already exists) was used internally by the system you could do some neat things along the lines of -

convert object {
stl >> x3d
option to run save data to file function
}

slice object {
x3d data gets sliced into a series of closed paths (outlines)
closed paths get loaded back into x3d alongside original model data
option to run save data to file function
}

dice object {
closed paths get diced into a series of open paths (fill)
link open paths to closed paths to give complete print path for layer.
linked paths get loaded back into x3d alongside original data and closed paths
option to run save data to file function
}

print object {
convert print path from x3d to gcode
send paths
}


this would also have the benefit of being able to skip the first step and export x3d directly from blender or maya or whatever + you could draw actual tool paths in your 3d package if you want that level of control and skip the first 3 steps..
also, for futureproofing, x3d stores UV texture info which as far as I'm aware STL does not, so when someone works out how to stick a colour printhead onto a reprap, the system is already there to allow this.

*edit* - I have not looked though the existing codebase yet so do not know how much of this sort of stuff is already covered, or perhaps done in a much better way than what I am suggesting... will do so v. soon

Edited 2 time(s). Last edit at 02/22/2008 11:51AM by deadgenome.

It's been a while since I've played with Povray but I think it's possible to create an object that's the intersection of an arbitrary object and a plane. Do that repeatedly, moving the Z of the plane and rendering each frame to a PNG. Hmm, can Povray do flat (i.e. non-camera) projections?

How about using Fab Labs Cam.py python script?

to convert the .stl to gcode directly then we need to add to the python to add the reprap gcode setup commands..

Bruce

ignore povray... to slice up an object horizontally into a series of closed paths is mathematically pretty easy... I'll try to code something up over the weekend if I have the time.

was thinking further about the idea of using x3d.... it also gives the option of using any of the major 3d packages to study the path data at any point in the process & frees us from the constraints of using a commercial file format, while allowing us to still use that format for input as long as we have an stl > x3d convertor

Slice code is here: [reprap.svn.sourceforge.net]

It is pretty easy to read, so it should be pretty easy to adapt to what you need.

--Blerik

Edited 1 time(s). Last edit at 02/22/2008 01:13PM by blerik.

degroof Wrote:
-------------------------------------------------------
> It's been a while since I've played with Povray
> but I think it's possible to create an object
> that's the intersection of an arbitrary object and
> a plane. Do that repeatedly, moving the Z of the
> plane and rendering each frame to a PNG. Hmm, can
> Povray do flat (i.e. non-camera) projections?

yes, if you read the post, i linked to a page that explains *exactly* how to do that.

blerik Wrote:
-------------------------------------------------------
> ZachHoeken Wrote:
> --------------------------------------------------
> -----
> > I recently got my bot up and running and
> > compatible with the RepRap host software.
> > Unfortunately, there are still problems with
> the
> > slice and dice code so I am still unable to
> print
> > anything.
>
> Can you tell us what the problem is exactly? I
> thought that with the SNAP firmware bug fixed, you
> could at least print the test hexagon.

yeah, its nothing with the firmware. rather, the host generates lots of errors during the slice/dice process. stuff like "half-plane not found, fell off line segment, etc."

i'll post the debug output later tonight.

> > Ideally, it would be nice to take a Unix
> approach
> > and have this as modular as possible by keeping
> > them separate. One script slices up the STL
> into
> > images, then the next one dices it up into
> > toolpaths. Finally, the toolpaths are output
> as
> > GCode with all the necessary extra commands to
> set
> > temperature, move Z, start/stop extruder, etc.
>
> The host software also does this in two passes.
> STLSlice z-sorts all the STL triangles, and
> figures out what parts intersect the plane to
> create some polygons defining the slice,
> LayerProducer creates the contour toolpaths and
> the hatch infill. They both work good enough. No
> need to rewrite it completely. Most CAM software
> can generate contour paths and infill paths fine
> as well. Just not the hatch infill RepRap uses.
>
> Outputting gcode instead of snap commands can be
> done by adapting the NullCartesianMachine code to
> output it. This would be the path of least
> resistance. I've already written some parts of it,
> just struggling with the user interface bits (and
> the fact that I do not have a functioning RepRap,
> which makes testing a bit challenging).
>
> I'll see what I can do this weekend.

yes, that is the path of least resistance, but seeing as how the host software is having problems with slice and dice right now, not even that will help.

moving to a system where we rely on another solid open source project means that we dont have to worry about this anymore. let them deal with the slicing, we'll do the dicing, and things will be great!

>
> *edit*
>
> > 1. slice STL into 2D images based on layer
> height. (ideally PNG)
>
> PNG is far from ideal here. You want a vector
> format. Otherwise you throw away the vector info
> in phase 1, and need to reconstruct it in phase 2
> (since it is the contour toolpath already).
>
> --Blerik

I understand that vector stuff is technically superior here. However, with the current state of the reprap host software I would much rather have a solid slice/dice process that works every time than and 'ideal' system that is buggy.

brucew Wrote:
-------------------------------------------------------
> How about using Fab Labs Cam.py python script?
>
> to convert the .stl to gcode directly then we need
> to add to the python to add the reprap gcode setup
> commands..
>
> Bruce

#
# (c) Massachusetts Institute of Technology 2006
# Permission granted for experimental and personal use;
# license for commercial sale available from MIT.
#

deadgenome Wrote:
-------------------------------------------------------
> ignore povray... to slice up an object
> horizontally into a series of closed paths is
> mathematically pretty easy... I'll try to code
> something up over the weekend if I have the time.
>

thats the problem. sure, its easy to do, but why waste our time re-inventing the wheel when someone has already done it, and has probably already done it better than we will be able to?

can you code up a solution that encompasses all the outliers (STL is a real bastard)? can you make it cross platform? do you want to maintain it for everyone else?

povray does it. it does it well. i dunno why everyone on reprap is obsessed with re-inventing everything. tools are meant to be *used*. you dont make your own hammer to build a shelf do you?

Can PovRay output a slice made of polygons or is it limited to bitmaps? If not it does may well do something well but it doesn't do what we want it to do well. You don't use a sledgehammer to build a shelf do you?

Why are you unable to print anything with the RepRap host when Vik has printed half a Darwin with it?

---

[www.hydraraptor.blogspot.com]

If STL outliers are the problem, push it through MeshLab. It has nice smoothing and healing functions and will leave your STL file 100% minty fresh or your money back

And I'm trying to minimize the code I have to write. If I can use the RepRap host software for slicing and dicing, that's fine by me. It's either that, or writing an algorithm that traces the contours of a povray generated bitmap, do tool radius compensation on that, do the infill after that, without leaving voids and without overfilling. That seems to me to be a whole lot more work. It does enable me to do nice stuff like auto-tearing of holes, but that is for the future.

I can also try and modify Gcam to create the proper infills, then I don't need Povray, and I don't need to do the bitmap tracing bits. But the Gcam codebase is totally new for me, so it'll take me longer. And I still need to do the tool radius compensation, because the Arduino firmware isn't up for that yet.

But as I was saying before, I'll try and look into it this weekend. If the RepRap host code is a total loss (hard to imagine after Vik printed 32 of the 39 RepRap shapes with it) I'll rewrite the whole dicing bit to work with bitmaps. Or I'll rewrite the slicing bits to work better. Or I'll modify Gcam. Whichever is the least amount of work.

*edit* When looking back at this post, I see a whole lot of text, but a simple message:

Slicing is the easy bit. It's the dicing that is hard.

The lesson for me is to think first, post second...

--Blerik

Edited 1 time(s). Last edit at 02/22/2008 06:30PM by blerik.

I've been working on a slice and dice script for Art of Illusion, but so far all I have is an in progress script to export the topology of a Art of Illusion Trimesh. It exports the nodes, the faces and the edges of any Trimesh that is selected. It would be easier to get the polygon from the edges array exported from this script than from an STL file, where you have to carefully assemble the edges from the unconnected triangles. It is online at:
[members.axion.net]

The comma separated values file from that script can be opened in a spreadsheet and can be opened by my associated Art of Illusion script Import Topology, online at:
[members.axion.net]

It looks like it will be possible to make a slice and dice script for Art of Illusion, but it'll take at least a few weeks.

I haven't run Forrest's script to output an extruder path. However the example file I read at:
www.3dreplicators.com/coupling.xml

is well written and easy to understand. It looks possible to translate it into GCode.

Could you please post the GCode file to make your text hexagon? It would make it easier to make an extruder GCode file.

brucew Wrote:
-------------------------------------------------------
> How about using Fab Labs Cam.py python script?
>
> to convert the .stl to gcode directly then we need
> to add to the python to add the reprap gcode setup
> commands..
>
> Bruce

#
# (c) Massachusetts Institute of Technology 2006
# Permission granted for experimental and personal use;
# license for commercial sale available from MIT.
#


Oh Yuck..? you could replace the Y if you want..

well we could just use some of the code?? to make something just for .STL to gcode

Bruce

As people more aware of the problem have already said, slicing isn't complex. The advantage of serious ray tracing systems is that they can do various geometric operations extremely efficiently, and therefore a little faster than an amateur renderer. Using povray as anything other than a visualisation tool seems rather baffling to me.

Tracing a path onto a slice is a far more interesting and complex problem. I've been putting a little bit of thought in to it since I read about someone complaining about little wispy bits of webbing crossing voids in their fabbed objects where the deposition head crossed air and left a trail. I'll probably look a little further in to that sort of thing when I feel keener... it is at least something you can examine without having a fabber handy to test it on.

So what exactly is causing the problem here? The object files? The STL parser? The STL slicer and dicer? STL itself?

It sounds like STL is a particularly unpleasant sort of file format. Will changing to a more sensible format that will make it harder to specify 'broken' objects help at all? If the answer is yes, I can rant on a bit more

Feel free to say 'no' to shut me up.

I only want to have a go at building some slice and dice code for my own education/entertainment, not to tread on anyones toes or to reinvent the wheel. I think I can do a good job at it as well with something like the process I have outlined above and will happily nick any existing code that helps and ditch any that doesn't. Anything that I do on this I will post with links to my source. Gonna hide for a while now and see if I get anywhere...

before I hide, just noticed the new post above mine (must have posted the same time as me)

I agree with ru, STL is nasty. It also does not do everything that we may need in the future. I know I have banged on about it a bit, but an xml based format for the system (such as x3d) covers all bases as far as I can tell. This does not prevent us from using existing STL objects, it just means we need a file parser from stl to our internal format. This is not difficult, the last time I wrote a 3d file parser it took a day.

Also, as ru points out, slicing is very easy, we are doing it on the horizontal plane, so it doen't even need any matrix mutiplication for rotating anything.

let's not try to cobble stuff together using a mish mash of technologies. That is not the definition of object orientated design. If people really want to get creative, take a pen and paper and work out the different logics of hatching various arbitary shapes and then write simple functions of the solutions, so that we have a library of different fill strategies to work from.

That would be very useful.

this list of strategies/functions should then be very easy to port into any future language that we care to use, allowing us the freedom to use any future device that is created.


Rant over & I hope I haven't upset anyone with it.

wow, i had no idea this was such a hotbutton issue. i got a very similar response from the dev team. i have a feeling this is a bike shed problem. (http://en.wikipedia.org/wiki/Color_of_the_bikeshed)

here's the deal: i have a working machine that i want to print stuff with. currently for whatever reasons the RepRap host code doesnt work for me to print a minimug. all i know is that i want to print a mug, and that i'm willing to try just about anything to get it working.

my gut feeling tells me that using pre-existing tools will allow me to do it since it worked for the evil mad scientist folks. i had assumed that the RepRap community would be all for it and want to help, but i guess i was wrong. i'm still going forward with my plans. if you want to help, i'd love to have you. send me a PM if you want to collaborate on the downlow.

to the rest of you, here's my challenge: the first one who creates a program/script/process capable of taking every single STL file contained in the Darwin Cartesian Bot release file and turning it into some sort of printable toolpath (gcode, SNAP, etc) wins. I'm not sure what you win, but you definitely win something. maybe i'll print you a minimug or two and mail it to you.

the race is on.

[downloads.sourceforge.net]

blue, no green... arrrgh!!!
I'll go hide again now...

Come on Zach! That is low. The least you can do is give us a proper description of your problems with printing the MiniMug. So the rest of the team can try and understand the issues. Now you're just a baby; my favorite toy is broken, someone get me a new one...

I'm going to tinker around with my Gcode writer some more. If that turns out to be a dead-end, I'll look into other ways. Not before. I had hoped to find a debug log attached this morning, but I'll manage without one.

--Blerik

The correct prize for this sort of endeavour is of course 'prestige'.

I'll stand by above comment... I don't think povray *is* a suitable tool. But if you can actually make use of it, good for you

I'm grabbing the JDK now, and I'm going to have a peek at the reprap host stuff. I'm not feeling confident... the recent blog posting (I don't recall who from, but I'm sure you'll all remember) about a part which wasn't fully printed due to software failure. The fact that this is even possible, let alone ghastly things like the extrusion head stopping during garbage collects suggests there's a fundamental problem with the way the host software has been architected.

Not that I'm suggesting I can magically fix it, but I can sure bitch and make unhelpful suggestions like the best open sourcerer.

I think this is an interesting idea and I'll have a look and see what I can over the next few days (the first part at least, and see where we go from there).

My work life has been pretty hectic but is starting to ease off now so I'll have a bit of breathing room. Hopefully it is just 90% other peoples stuff and my 10% will be just putting it together in a new way.

If not, I'll probably give up pretty quickly, I've had enough stress in my life so a couple of days making bits of software fit together with simple cut and paste scripts looks good but a couple of weeks of banging my head against a wall is likely to end up with it being literal :-)

I'm hoping I don't need to know *anything* about the inner workings of slice and dice algorithms or STL etc. Looking at the candyfab page it looks like the start at least should be relatively simple.

Of course, another complication is I don't know much about PovRay and nothing about scripting it but I'm willing to learn something new in order to be distracted from my rushed life :-)

Edited 1 time(s). Last edit at 02/23/2008 07:40AM by reece.arnott.

OK, I've been looking over some of the sequence of things and heres what I've come up with...

1. slice STL into 2D images based on layer height. (ideally PNG)

This actually breaks down into 2 stages if we follow the Mad Scientist approach:
a. stl -> povray .inc file
b. povray .inc file -> PNG files

a. should be extremely simple, just compile and reuse Python script, as is, from
[www.xs4all.nl]
except I get a make error:
Makefile:9: *** missing separator. Stop.
Which seems to be an error normally associated with spaces replacing tabs except its not in this case.

Also tried on Windows XP to download [www.xs4all.nl] for win32 source/compiled version.

This sort of worked; at least it produced the output I expected except there may be something wrong/non-standard with the stl files I got (unzipped the latest ones downloaded from sourceforge - reprap-cartesian-bot-1.0.4.zip)as they had issues. I tried a few at random and it always came up with a warning that the file header had a large number of triangles (5768 in one case) but it could only find a few (22 in that case).

b. Should be relatively simple, just use povray script displayed on webpage [www.evilmadscientist.com] with modified paramters eg. z slice height, .inc file name etc. I haven't tried this yet.

May need to go through their other script (.pov file in [www.evilmadscientist.com]) but I don't think so.

For this to work of course, you need to have povray installed, another 19MB download on my Ubuntu Gutsy machine (including help files)
or 10MB Windows XP download from [www.povray.org]


2. create toolpaths based on 2D image and output it.
More complex, requires research but probably a lot of code that can be reused (especially if Forrest has already done the majority of the work). I haven't even scratched the surface yet. Only followed a couple of links.

3. output toolpaths as GCode suitable for a RepRap machine
Too much info spread over the threads for me to absorb at the moment but it feels as if its fast moving. Probably best if someone already involved did the integration.
Maybe something similar to [cvs.linuxcnc.org]

Looks like it's going to take a bit to get it going and might have too much overhead doing it this exact way anyway (eg. using povray just as slice-and-dicer is rather inefficient - you have to convert the stl files into povrays .inc format and also download/install povray which takes quite a bit of space compared to the build your own approach).

Possibly a better approach would be talk to eg. AoI developers or [www.openrp.com] (although I don't think their software is open source, just freeware) and get them to include and support some/most/all this functionality as it would probably of use to a good percentage of their core clients as well as just us. Looking back up the posts, Enrique is already in the process of doing something like this for AoI anyway :-)

So... Zach, for the immediate future, figure out what your issue is so we can help debug the current code.

Enrique and blerik, keep up the good work it sounds like you're probably more the men for the job than I.

And me? Well... it looks like this is more complicated than I'd like so I'll do a bit more groundwork over the next few days and try and map out the issues and some solutions but I think its probably going to be better if I get on with the next version of the LiveCD which I've been putting off until my life was more sorted :-)

I'm working on Export Slices; which is at:
[members.axion.net]

and the test shape is a hollow square, at:
[members.axion.net]

Although it is nowhere near finished and it can not do anything useful now, it can already slice an Art of Illusion Triangle Mesh. Indeed only a Triangle Mesh, if you make a cube or boolean, you have to turn it into a triangle mesh for export slices to convert it. Just one slice right now, because it is easier to debug that way

Two good GCode articles at the following places:
www.linuxcnc.org/handbook/gcode/g-code.html
[en.wikipedia.org]

I have a few questions about the reprap GCode.

Is absolute positioning available? If so what is an example absolute positioning code?

Is there a code for turning the extruder on and off? If there isn't I suggest M4, ( turn spindle counterclockwise ) for extruder on. For turning the extruder off I suggest M5 ( stop spindle turning ).

Is there a code for temperature?

Is there a code block at the beginning of the file and if so what is it?

I just looked at the OpenRP site, and was initially full of hope, until I got to this little section...

Quote

"If we made the source code and algorithms public, then the security of the RP file format would be compromised. Anyone with a little bit of programming knowledge would be able to write a program to bypass the password in a RP file. The OpenRP solution gives you all the tools you need to get STL data from a RP file. So under normal circumstances one should not be bothered with the innards of the RP file format... unless you are interested in bypassing the password."

I think that's enough to be a deal breaker. It means that app RP users are completely at the mercy of the RP tool providers. If the tools are imperfect, or perhaps aren't supported on a platform you'd like, you're totally out of luck.

More importantly, this sort of 'security by obscurity', hiding the security methods, is an entirely silly thing to do and does not fill me with confidence about the skills of the format's designers. If a system needs to be kept secret to be secure, then it has no security at all. It implies that the breaking of such a system is not overly complex. So as soon as one person cracks the password system, all the security is rendered useless and *still* there will be no truely open access to the file format. If they'd done it properly, they'd have released everything. There are plenty of secure, open source file encryption systems out there, and they clearly should have taken that approach

Anyway, rant over. I've got a little more complaining to do about other things, but I'll drop that into a different thread

blerik Wrote:
-------------------------------------------------------
> Come on Zach! That is low. The least you can do is
> give us a proper description of your problems with
> printing the MiniMug. So the rest of the team can
> try and understand the issues. Now you're just a
> baby; my favorite toy is broken, someone get me a
> new one...

i posted it in the forums. to be fair i did send it to the core team on friday before i posted this, so its not like i'm not trying to help them.

i wouldnt say i'm being a baby, because i'm actually working to get a reliable solution built. sometimes rocking the boat is a little bit fun and/or necessary.

>
> I'm going to tinker around with my Gcode writer
> some more. If that turns out to be a dead-end,
> I'll look into other ways. Not before. I had hoped
> to find a debug log attached this morning, but
> I'll manage without one.

if that turns out to be the best/fastest way to reliable printing, you can expect a full public apology from me =)

reece.arnott Wrote:
-------------------------------------------------------
> OK, I've been looking over some of the sequence of
> things and heres what I've come up with...
>
> 1. slice STL into 2D images based on layer height.
> (ideally PNG)
>
> This actually breaks down into 2 stages if we
> follow the Mad Scientist approach:
> a. stl -> povray .inc file
> b. povray .inc file -> PNG files

i managed to get it to compile and i have a perl script that does all that. i'll upload that soon, as well as get in contact with the author to fix that bug.

in the meantime, check out this zip file with rendered images of the cartesian bot parts: [osotite.com]

the script is in that folder. its perl.

> 2. create toolpaths based on 2D image and output
> it.
> More complex, requires research but probably a lot
> of code that can be reused (especially if Forrest
> has already done the majority of the work). I
> haven't even scratched the surface yet. Only
> followed a couple of links.

i snagged forrests code and i'll port it to something more FOSS. suggestions welcome. i'm comfy with perl and to a lesser extent python. lets not aggravate over language though. hell, i could even do java if we want.

> 3. output toolpaths as GCode suitable for a RepRap
> machine
> Too much info spread over the threads for me to
> absorb at the moment but it feels as if its fast
> moving. Probably best if someone already involved
> did the integration.
> Maybe something similar to
> [cvs.linuxcnc.org]
> author.py?rev=1.1

toolpaths -> gcode is going to be easy. generating toolpaths will be the hard part. i am definitely willing to handle this part.

Enrique Wrote:
-------------------------------------------------------
> I'm working on Export Slices; which is at:
> [members.axion.net].
> bsh

awesome! how do i run that??

>
> I have a few questions about the reprap GCode.
>
> Is absolute positioning available? If so what is
> an example absolute positioning code?

yes, its easy. you may want to refer directly to the source code. the parsing stuff is simple to understand. the way it work is this: when you send a movements gcode, for example:

G1 X20 Y30 Z-10

in incremental mode it means go x+20, y+30, z-10 units on a straight line.

in absolute mode, it means go to x:20, y:30, z:-10 from whatever internal point its on. you must keep track of that point yourself. there are functions to tell it to reset to zero, and it starts out at zero as well.

> Is there a code for turning the extruder on and
> off? If there isn't I suggest M4, ( turn spindle
> counterclockwise ) for extruder on. For turning
> the extruder off I suggest M5 ( stop spindle
> turning ).

read the source... M codes above 100 are open for custom codes, and thats where i've put them. source located here: [svn.reprap.org]

(or the code is in the newest arduino firmware release)

> Is there a code for temperature?

yes, read thru code above.

> Is there a code block at the beginning of the file
> and if so what is it?

not that i know of... just gcode commands sent sequentially. i've been keeping them in a flat file. it might be a good idea to include gcodes to home the machine, turn on heater, etc.

Ok, wasted a Saturday on the subversion trunk code, so all this applies to RepRap host 0.8.1.

Attached you'll find a gcode file for printing a MiniMug using:

200 degrees as a temperature (change this if you like, it's in the beginning only)
1 mm extrusion diameter
0.8 mm layer height
RepRap native feedrates (probably unuseable, remove if you like)
*edit* Relative positioning, so you can easily change the position of the piece without needing to change the whole file

It uses only these gcodes:

G0
G1
G21
G91
M101
M103
M104
M9

It is the output of the attached (and very ugly) code with some minor touchups. It is a diff, so you have to copy NullCartesianMachine.java to GCodeWriter.java first, then run the diff on it (patch -l -c GCodeWriter.java GCodeWriter.diff). Add two lines to MachineFactory.java like so:

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

And you're good to go. Startup the Host software (version 0.8.1 only!), open the prefs, change nullcartesian to gcodewriter, change the cooldown on the extruder to 0 seconds (no use waiting on a virtual extruder), and you're good to go. The output goes to stdout for now...


To Do's:

TODO: convert feedrate from RepRap host value to GCode value
TODO: fixup preamble and postamble code
TODO: Make the code print to a file, use the Port(name) property for filename
TODO: fixup warmup segments GCode (forgets to turn on extruder)
TODO: Get temperature from properties
TODO: fixup all the RR: println commands
TODO: find a better place for the code. You cannot even detect a layer change without hacking now.
TODO: fix the moveTo code to understand the startUp, endUp flags (But I don't understand that code yet).
TODO: read Zach's GCode examples to check if I messed up.
TODO: make GCodeWriter a subclass of NullCartesian, so I don't have to fix code all over the place.

Edited 1 time(s). Last edit at 02/25/2008 04:28AM by blerik.