Sliced Model Intermediate Language - SMIL "smile"

It seems we need a structure to hold the results of a slice/dice that is an intermediate between model geometry and material specific machine strategies.

The idea is to blend XML and G-Code in such a way that the impact to existing software can be minimized.

Based off of this understanding of workflow:

Design Phase:
CAD -> Model File

CAM Phase:
Model File + Extrusion Diameter + Slice Height -> SMIL
Selected Material + Machining Strategies + Sliced Intermediate -> Final G-Code



== SMIL Structure ==

DOCUMENT ELEMENT: SMIL, ATTRS: CreatedDateTime, SourceModel, ExtrusionDiameter, ExtrusionWidth, LayerThickness, InfillBridgeWidthOverThickness

(I don't actually know what these mean: ExtrusionWidth, LayerThickness, InfillBridgeWidthOverThickness)

ELEMENT: LAYER, ATTRS: LayerNumber, IsTopLayer, IsBottomLayer, LengthX, LengthY

LAYER CHILD ELEMENT: TOOL, ATTRS: Name, Sequence

TOOL CHILD ELEMENT: THREAD, ATTRS: Sequence
THREAD ELEMENT TEXT: G-Code Describing Tool Path

=== Example ===
Attached.


== Usage ==

During the second part of the CAM Phase the software which reads in the SMIL will be responsible for deciding:

- Extrusion Feed Rate
- Extrusion Temp
- Feed Rate (X,Y,Z)
- Rapids height and feed rate
- Fan On/Off
- Fan Dwell
- Raft creation

-----------------------
EDITS:

Added LengthX and LengthY attributes to the LAYER element. These can be useful for creating rafts.

Added TOOL Element as a child of the LAYER Element.

Fixed the example file so it is actually XML....

Added THREAD element as a child of the TOOL element.

Renamed it to SMIL

Edited 9 time(s). Last edit at 05/23/2008 10:58PM by Brendan Erwin.

This looks good, I've also been thinking that this could be a good idea, I was also thinking that either having a external index file for a gcode file, or embedding sections gcode in a file would be the best idea

As its in XML, it should be pretty easy to add new parameters and everything remain backwards compatible too.

The only criticism I have is the name 'STL Intermediate Language - SSIL', as this new format will be independent of STL files, e.g. skienforge now uses gnu triangulated surfaces (a different format doing the same thing) maybe a slightly more generic name would be better, something like 'RepRap Toolpath Language'?

Well, I'd love to change the name but I don't know how to change the title of an existing forum topic....



Seriously though, I'm a stickler for accurate names so I agree, it needs to change!

Name options:

RepRap Toolpath Language - RRTL
Sliced Model Intermediate Language - SMIL

Any more?

This also makes me think that we should have a format for describing materials and the strategies for working with them. I want to capture all the stuff Nophead is figuring out...

RepRap Extrusion Material Information - REMI

Like this:

ABS
Median Extrusion Temp.
First Layer Extrusion Temp.
Fan Options
::: Continuous
::: Inter-layer Dwell
Raft strategy
::: (Some way of representing this....)

Here's a problem: Where does infill density fit in this scheme?

The value seems most appropriately tied to the material selected but it plays a large part in determining the internal geometry generated by the slicing.

Perhaps the geometry output by the slice/dice could "tag" a given extrusion thread with an infill percent identifier? Then the post-processor could select only those threads that it wanted?

Or, the slice/dice code could output a standard set of infill renderings? Say it always generates slice geometry for 25%, 50%, 75%, and 100%. (This option seems the safest and most future proof.)

brendanjerwin Wrote:
-------------------------------------------------------
> Here's a problem: Where does infill density fit in
> this scheme?
>
> The value seems most appropriately tied to the
> material selected but it plays a large part in
> determining the internal geometry generated by the
> slicing.
>
> Perhaps the geometry output by the slice/dice
> could "tag" a given extrusion thread with an
> infill percent identifier? Then the post-processor
> could select only those threads that it wanted?
>
> Or, the slice/dice code could output a standard
> set of infill renderings? Say it always generates
> slice geometry for 25%, 50%, 75%, and 100%. (This
> option seems the safest and most future proof.)


You don't want to re-calculate the infill four times if each time takes three computer hours and you'll only end up using one of them. However, I'm not sure what the right solution is.

I hate to add more difficult requirements, but this intermediate format will also need a way to deal with multiple materials, because in the short term we'll want to have at least a print material and an extrusion material, and in the long term, many more than that. Refer to the thread at [forums.reprap.org] for a discussion of how the STL files for various materials might be expressed.

-----
EDIT:
Just for the record, as far as I am aware that .rro format has not been developed, just discussed. I think an explicit format for that must be determined before we can create slice software that interprets multiple materials...

Edited 1 time(s). Last edit at 05/21/2008 05:11PM by Kyle Corbitt.

The Intermediate Language would not need to know of any particular materials but rather it would need to know of particular tool heads.

Poly Extruder, Support Extruder, Conductive Trace Extruder, etc.

As the various tool heads are developed the enumeration can be expanded.

I'll update the description and sample to include this idea.

--------

Oh, also I think the purpose of this Intermediate Language is slightly different than that format. I'm not attempting to create a structure that can completely define a fabrication, but rather just a structure that can provide a generic place to hold the output of a very expensive operation.

Since an intended result of the RepRap project is to have machines evolve, then we will never be at a point in which a set of machine instructions can be rendered and distributed. I think the original thought was that model files could be distributed, but since the slice/dice is so expensive we need this intermediate. (Imagine the slice/dice running on an XO...)

Edited 1 time(s). Last edit at 05/21/2008 05:46PM by brendanjerwin.

I'm not sure that using gcode is particularly useful for an intermediate stage. Gcode is fairy closely tied to the device and the driver system, which limits its portability.

Describing complete toolpaths is very verbose, and probably unnecessary. Perhaps some benchmarking is needed here to see exactly how much time toolpath generation for a layer takes? Verbosity is more annoying here, as it generates very large and unwieldy files.

You could tesselate a layer into a number of segments, where each segment can be infilled with a single continuous run. Identifying these segments isn't a totally simple operation, and perhaps generating these at the same time as slicing could be of some benefit. Given that the filament diameter is known, the end stage gcode generator should be able to generate a tool path for each segment; this would be a trivial task.

This also allows special operations like the 'fillet' and 'comb hair' tricks to avoid blobs of material on sharp corners and reduce in air strands of material for machines that need it. Nophead's fabricator for example has no problem with sharp corners. Newer extruders will have nozzle values to prevent unwanted dribbling. These tasks can be skipped as unnecessary for these fabricators.

Also consider that XML is a rather inefficient way of storing data, combining the less useful aspects of machine and human readability. It is nice to annotate text documents with (see also, HTML, SGML, etc) but for a purely computer generated and computer interpreted data form it is rather excessive. I'm not advocating evil binary formats here, but human unfriendly syntax and grammar lend themselves to faster processing, faster transmission and smaller storage size.

Similarly, GCode was devised as a way for humans to communicate with primitive computers. It is not necessarily the best way for computers to communicate with other computers. The new Tommelise, I believe, does not use GCode internally, and hence makes claim to being able to store significant amount of toolpath data in a fairly small lump of memory, potentially allowing for fabrication of whole parts whilst unplugged from a PC, etc etc.

But as a back-seat software engineer, I won't be backing up my words with action just yet. If you're doing stuff, you're one up on me. But always allow for the possibility that you might be totally wrong. I know I do

Ru Wrote:
-------------------------------------------------------
> I'm not sure that using gcode is particularly
> useful for an intermediate stage. Gcode is fairy
> closely tied to the device and the driver system,
> which limits its portability.
>
> Describing complete toolpaths is very verbose, and
> probably unnecessary. Perhaps some benchmarking is
> needed here to see exactly how much time toolpath
> generation for a layer takes? Verbosity is more
> annoying here, as it generates very large and
> unwieldy files.

I'm attempting to provide a "right-now" solution in which I'm hoping to ride quite a bit on the work done by Nophead and Enrique. Nophead had expressed at one point or another that he thought XML would be good for this so I went with XML. Enrique is outputting g code to express the extrusion threads so I'm trying to use the meat of what he is doing.

The only g code that I'm intending on storing in this format is the stuff that describes the tool path geometry. None of the machine modal stuff. That makes it pretty much completely machine independent.

I am certainly taking as a given that tool path generation is expensive. It is the primary goal of slicing and dicing which is known to be extremely expensive.

As a side note, I personally think the move towards g code (in general, not actually defending it's use in this case) is great since it further opens the project up to the wealth of stuff out there for cnc mills. It also is making my particular EMC based RepStrap much more possible!

> You could tesselate a layer into a number of
> segments, where each segment can be infilled with
> a single continuous run. Identifying these
> segments isn't a totally simple operation, and
> perhaps generating these at the same time as
> slicing could be of some benefit. Given that the
> filament diameter is known, the end stage gcode
> generator should be able to generate a tool path
> for each segment; this would be a trivial task.
>
> This also allows special operations like the
> 'fillet' and 'comb hair' tricks to avoid blobs of
> material on sharp corners and reduce in air
> strands of material for machines that need it.
> Nophead's fabricator for example has no problem
> with sharp corners. Newer extruders will have
> nozzle values to prevent unwanted dribbling. These
> tasks can be skipped as unnecessary for these
> fabricators.

Probably, but even with those features(?) hidden within the layer g code they won't actually hurt the process for a more advanced extruder. (I think.)

> Also consider that XML is a rather inefficient way
> of storing data, combining the less useful aspects
> of machine and human readability. It is nice to
> annotate text documents with (see also, HTML,
> SGML, etc) but for a purely computer generated and
> computer interpreted data form it is rather
> excessive. I'm not advocating evil binary formats
> here, but human unfriendly syntax and grammar lend
> themselves to faster processing, faster
> transmission and smaller storage size.

Yeah, I agree. But you just can't argue with the pervasive nature of XML. I was originally thinking YAML but decided to go with XML to 1) make this idea just a slight bit more acceptable to Nophead since I really want his involvement and 2) EVERYONE can mess with XML and all programmers are comfortable with it. (I know, generalizations.)

> Similarly, GCode was devised as a way for humans
> to communicate with primitive computers. It is not
> necessarily the best way for computers to
> communicate with other computers. The new
> Tommelise, I believe, does not use GCode
> internally, and hence makes claim to being able to
> store significant amount of toolpath data in a
> fairly small lump of memory, potentially allowing
> for fabrication of whole parts whilst unplugged
> from a PC, etc etc.

Again, I agree. But again the state of the universe makes g code the more pragmatic technology. The goal of operating without a PC attached is a good one but I really don't think g code will prevent that. It will, of course, make the storage requirements bigger but have you looked at the cost of SD cards recently?

> But as a back-seat software engineer, I won't be
> backing up my words with action just yet. If
> you're doing stuff, you're one up on me. But
> always allow for the possibility that you might be
> totally wrong. I know I do

It is nice to know that folks out there are allowing for the possibility that I might be totally wrong...


To summarize my goal: I want to find a way to more generically express what Nophead and Enrique are already doing. It's selfish; I want to use their stuff for my fabricator.

Nophead has expressed that his mechanism for post-processing the output of Skeinforge is brittle and that same brittleness has prevented him from using the latest stuff from Enrique. It is also extremely targeted to his machine. I believe this mechanism will help to ease some of those problems.

brendanjerwin, your idea is a good one. It will certainly make life easier for many of us. It is true that this approach has some (relatively minor, in my uninformed opinion) drawbacks, but it will be a lot nicer to have it available than not. Keep it up!

Quote

Quote

But always allow for the possibility that you might be totally wrong. I know I do

It is nice to know that folks out there are allowing for the possibility that I might be totally wrong...

Oh dear... I didn't think that sentence was grammatically ambiguous. Consider the following...

"Always clean you teeth. I know I do!"
"Always check your boots for scorpions. I know I do!"

You can be assured that I don't clean your teeth or check your boots. You can extrapolate how I feel about being totally wrong from my original sentence.

Anyway, irrelevant.

Quote

I'm attempting to provide a "right-now" solution in which I'm hoping to ride quite a bit on the work done by Nophead and Enrique. Nophead had expressed at one point or another that he thought XML would be good for this so I went with XML. Enrique is outputting g code to express the extrusion threads so I'm trying to use the meat of what he is doing.

I notice that there have been various comments in favour of XML. This is because XML is a de-facto standard of sorts, and is often used where it isn't entirely appropriate. We're not using it for partially structured documents (like HTML pages) nor do we have strangely organised data with lots of tree structures of varying shapes. The structure of an intermediate file is quite simple, as you showed above.

There is nothing wrong with expediency, but it would be sad if design decisions that don't matter at the time cause knock-on effects down the line when people are using what was only intended to be a stop-gap solution as production code.

Quote

The only g code that I'm intending on storing in this format is the stuff that describes the tool path geometry. None of the machine modal stuff. That makes it pretty much completely machine independent.

But why use gcode at all? It just seems odd to me. You're storing a sequence of points, which you've chosen to delineate with G1 and prefix with X, Y and Z. Why not brackets and commas for example? Or commas and newlines? These being the way such data is usually represented, after all. This is less of a big deal, though.

Quote

I am certainly taking as a given that tool path generation is expensive. It is the primary goal of slicing and dicing which is known to be extremely expensive.

This concerns me somewhat. Slicing is a very complex operation, especially when handling poorly formed STL files. Infilling a sane 2D polygon (or bit of boolean geometry) should be an order of magnitude simpler and faster, if not more so. I'll have a closer look at how Skeinforge and the RepRap Host do it later.

Quote

As a side note, I personally think the move towards g code (in general, not actually defending it's use in this case) is great since it further opens the project up to the wealth of stuff out there for cnc mills. It also is making my particular EMC based RepStrap much more possible!

I don't dispute the use of gcode or EMC at all! RepRap has spent far too much time reinventing wheels already. But gcode is a machine specific instruction set, and as such should only appear after slicing and infilling. Assuming the previous two steps do their job correctly, an intermediate format to gcode conversion should be fairly smooth and painless..

> Oh dear... I didn't think that sentence was
> grammatically ambiguous. Consider the
> following...
>

I thought I was being funny... Oh well, too much engineer humor..

>
> I notice that there have been various comments in
> favour of XML. This is because XML is a de-facto
> standard of sorts, and is often used where it
> isn't entirely appropriate. We're not using it for
> partially structured documents (like HTML pages)
> nor do we have strangely organised data with lots
> of tree structures of varying shapes. The
> structure of an intermediate file is quite simple,
> as you showed above.
>
> There is nothing wrong with expediency, but it
> would be sad if design decisions that don't matter
> at the time cause knock-on effects down the line
> when people are using what was only intended to be
> a stop-gap solution as production code.

Granted, XML will be bigger, but YAML (for instance) has it's own overhead too. I think the odds of XML causing us big problems in the future are pretty slim. Using XML or not could pretty quickly just turn into a "religious war". I'd like to propose that we just go with XML and move on: it's a universal data structure and will work. The use of g code and all other details I'd still like to discuss though. Cool?

> But why use gcode at all? It just seems odd to me.
> You're storing a sequence of points, which you've
> chosen to delineate with G1 and prefix with X, Y
> and Z. Why not brackets and commas for example? Or
> commas and newlines? These being the way such data
> is usually represented, after all. This is less of
> a big deal, though.

This really boils down to what the producer of the data is comfortable. (That means Mr. Enrique.) I'll see if I can engage him more and get some feedback.

> I am certainly taking as a given that tool path
> generation is expensive. It is the primary goal of
> slicing and dicing which is known to be extremely
> expensive.
>
> This concerns me somewhat. Slicing is a very
> complex operation, especially when handling poorly
> formed STL files. Infilling a sane 2D polygon (or
> bit of boolean geometry) should be an order of
> magnitude simpler and faster, if not more so. I'll
> have a closer look at how Skeinforge and the
> RepRap Host do it later.

Yeah, please do look at that stuff. I'm admittedly working on the outskirts of understanding here. Real deep insight is welcome!

> As a side note, I personally think the move
> towards g code (in general, not actually defending
> it's use in this case) is great since it further
> opens the project up to the wealth of stuff out
> there for cnc mills. It also is making my
> particular EMC based RepStrap much more possible!
>
>
> I don't dispute the use of gcode or EMC at all!
> RepRap has spent far too much time reinventing
> wheels already. But gcode is a machine specific
> instruction set, and as such should only appear
> after slicing and infilling. Assuming the previous
> two steps do their job correctly, an intermediate
> format to gcode conversion should be fairly smooth
> and painless..

Good, I think we are on the same frequency here.

XML may not be very efficient, but with modern computers it's not really going to have a big impact on processing time (most of this will be the slice & dice). If people want to create machines that can run standalone from the PC then they will be loading the fully processed machine control code into the device, not this intermediate format.

I've attached another XML file with the idea of 'threads' within layers, as used in (nopheads?) gcode parser.

Nice. I'll update the first post with an updated example and document the THREAD element.

I added a sequence attribute to the THREAD element since I hate depending on order of elements in xml.

------

Edit: Oh yeah, and allowing Z in the motion descriptions is just fine. I just don't want rapids motion done by the slice/dice.

Edited 1 time(s). Last edit at 05/22/2008 12:49PM by brendanjerwin.

The Z motion probably shouldn't be used in fused deposition modelling, but it may be useful for other things. Another thing I thought of to put at the start of the file is the units: Inches / mm.

Quote

XML may not be very efficient, but with modern computers it's not really going to have a big impact on processing time (most of this will be the slice & dice).

True, but it certainly doesn't keep the file size down. Its the unnecessary bloat I object to. The notion that you don't need to be efficient because we how powerful computers is what bought us Vista

Quote

If people want to create machines that can run standalone from the PC then they will be loading the fully processed machine control code into the device, not this intermediate format.

...which means that each design of standalone fabricator must be given its own object file, rather than anyone with any system being able to grab any intermediate file and have their system finish it off.

This isn't an implausible idea, given how cheap microprocessors can be. Or FPGAs for that matter... slice and dice on soft-core logic, anyone? My other half does research work with FPGAs, but somehow I don't think I can afford her consultancy rates

Greenarrow, Z motion might be useful when extruding some of the more 'liquidy' substances or for conductive trace deposition... I just don't see any reason to restrict it here is all.

Ru, what do you mean each design of fabricator would need it's own object file? The intent of this intermediate format is exactly the opposite. I want to be able to snag a slice/dice just after the expensive, time consuming, operations, but before the output becomes too machine specific. The idea is that the slice/dice code will eat an STL (or other model file), process for hours, and then spit out the intermediate file. Then each fabricator can apply machine and material specific "filler" to the intermediate data and output specific machine instructions.

If slice/dice can be made reasonably fast then this whole idea is not needed. (Although, it might still be nice to have just to help keep some boundaries up.)

As to the bloat, I promise that after the format is working (if it gets off the ground) that I'll open it up to repackaging the logical structures in a lighter-weight container.

Quote

Ru, what do you mean each design of fabricator would need it's own object file?

This was mostly in response to this...

Quote

If people want to create machines that can run standalone from the PC then they will be loading the fully processed machine control code into the device, not this intermediate format.

This means my device isn't entirely standalone... I will need a decent driver to generate gcode on my pc, and then print that to the fabricator. Nothing wrong with that of course, but it would be neat if you could have an object library on a flash storage device that would work on a truly standalone printer that does not need a PC attached. I'm very much in favour of the smart device approach, rather than dumb peripheral.

Only slightly pie-in-the-sky, but I don't think I can turn my hand to embedded systems design overnight

Ru Wrote:
-------------------------------------------------------

> I'm very much in favour of the smart
> device approach, rather than dumb peripheral.
>
> Only slightly pie-in-the-sky, but I don't think I
> can turn my hand to embedded systems design
> overnight

I agree.

I don't think that it would be unreasonable to expect a mid-to-high-end embedded processor to be able to manipulate a sliced object file and generate the actual machine instructions.

I've got a new twist to this whole plan that I think will have a lot of benefits.

I'm going to see if I can get Skeinforge to run unattended. Then, I'll set up a process that will monitor a SVN repository somewhere for changes to or new STL files, continuous integration style. When it detects a change I'll have it run Skeinforge with the various infill levels and then I'll translate those outputs into my intermediate representation and publish those somewhere.

I have a VPS (slicehost.com, really awesome hosting) but if the processing takes too long there I'll shell out to Amazon EC2 for some real horse-power on demand (their biggest VPS is a beast!). I think using EC2 only when there are changes should keep the cost low enough...

Thoughts?

If you want a quick hack to translate Skeinforge files, I suggest using the gRead file included in the Skeinforge package (I think nophead wrote it but I'm not sure). The code below will parse a gcode file and print all the coordinate sets to the screen.

import gRead
layers = []
g = gRead.gRead("simplesq_fillet.gcode", layers)

for l in layers:
	print "new layer"
	# Create new layer XML object here
	for thread in l:
		#Create new thread XML object here
		print "new thread"
		for point in thread:
			print "coordinates", point.x, point,y, point.z

greenarrow:

Thank-you much. Attached is the result.

It transforms the skeinforge-gcode output of the latest skeinforge from SVN (rev 1600) into something close to SMIL.

Oh, BTW, I decided to rename it to Sliced Model Intermediate Language (SMIL). We can pronounce it "smile". It'll be fun.

The code is hard-coded to load a particular input file, but that's not hard to change.

Here is how I call it: rm foo.xml; python ./skeinforge2smil.py >> foo.xml; mate foo.xml

("mate" is a text editor for any non-Mac folks...)

Edited 2 time(s). Last edit at 05/23/2008 11:06PM by Brendan Erwin.

I slapped this together for editing g code.

If you use TextMate it might help. Make a new bundle, add a new language to it and paste this in there:

{ scopeName = 'source.ngc';
fileTypes = ( 'ngc' );
foldingStartMarker = '\(';
foldingStopMarker = '\)';
patterns = (
{ name = 'keyword.control.gcode.ngc';
match = '[g|G]([ \t]*[\d])*[ \t]*';
},
{ name = 'keyword.control.mcode.ngc';
match = '[m|M]([ \t]*[\d])*[ \t]*';
},
{ name = 'variable.parameter.ngc';
match = '[x|X|y|Y|z|Z|f|F|p|P|q|Q](\-?[\d]*\.?[\d]*)';
},
{ name = 'comment.ngc';
begin = '\(';
end = '\)';
},
);
}

Random unhelpful comment... SMIL is already used as an eTLA by 'streaming multimedia interaction language' and prnounced in the same way.

Nothing else immediately springs to mind which is as conveniently pronounceable (using things like T for toolpath or R for reprap, etc). Maybe an A for Abstract might help

But you could always use Builder Definition for Sliced Models...

*cough*

Yeah, I know it's already taken.... but I at least wanted to get something less wrongly specific that the last name.

BDSM. Nice! It kinda conveys a different sort of feeling than "smile" though.

I had a quick go at implementing the format, and looked at the output file when plotting a simple PCB, the resulting file was 506Kb, much larger than I was expecting. I then did an experiment to compare it with a similar plain text based format and got a file size of 275Kb (almost half as much). I've attached the python module I used to create the files.

Hey, sorry I didn't post this here earlier.

Over in the EmcRepStrap thread it was made clear that the slice/dice process isn't all that expensive anymore (the main driving force behind making an intermediate language). I believe that Enrique's plan is to output 'standard' g code with lots of comments and let post processors go from that to whatever final formats are needed.

Edited 1 time(s). Last edit at 05/26/2008 09:39AM by Brendan Erwin.