How to print Gcode from Host

I could be wrong but I thought fillet.py called everything else.

Enrique, I've been meaning to say since ages ago, your script is working great now, I've finally got the extruder temperature control working properly in my reprap library so I should be trying some skeinforged prints in the next few days.

Hi Greenarrow,

Indeed fillet.py does call everything else.

Thanks for trying out the tool chain, it's good to know it's working for you because I know it's currently hard to use, and I estimate that at any one time there are around ten bugs

By the way, nice work on your PCB plotter. It's great that with just a simple tool, you've opened up a whole new capability for us. In time, we might be able to fabricate a perfectly sized watertight container to hold the ferric chloride & board with no mess.


Hey Brendan,

Sorry about the lack of organized documentation. Each file does have html documentation, for example fillet.py has the help file fillet.html, but they're not explained together yet. Skeinforge is the name of the entire tool chain, but confusingly there is no script called skeinforge. Right now the chain consists of slice, fill, comb, stretch & fillet. To use the chain, call any part of the chain and it will automagically call everything before. It will also automatically call vectorwrite.py to make a scalable vector graphics file that can be opened in Mozilla or any other svg capable viewer. To start, I suggest in a shell calling fillet.py
> python fillet.py

Then maybe clicking on the '?' button to read the fillet documentation. Then try filleting a .gts file. The latest documentation for fillet is below.

Cheers,
Enrique


Fillet is a script to fillet or bevel the corners on a gcode file.

Fillets rounds the corners slightly in a variety of ways. This is to reduce corner blobbing and sudden extruder acceleration. The default radio button choice is 'Bevel'. If the default choice is 'Do Not Fillet', the gcode text is handed over the next tool in the skeinforge chain. To run fillet, in a shell type:
> python fillet.py

To run fillet, install python 2.x on your machine, which is avaliable from [www.python.org]

To use the preferences dialog you'll also need Tkinter, which probably came with the python installation. If it did not, look for it at:
www.tcl.tk/software/tcltk/

To export a GNU Triangulated Surface file from Art of Illusion, you can use the Export GNU Triangulated Surface script at:
[members.axion.net]

To bring it into Art of Illusion, drop it into the folder ArtOfIllusion/Scripts/Tools/.

The GNU Triangulated Surface format is supported by Mesh Viewer, and it is described at:
[gts.sourceforge.net]

To turn an STL file into filled, filleted gcode, first import the file using the STL import plugin in the import submenu of the file menu of Art of Illusion. Then from the Scripts submenu in the Tools menu, choose Export GNU Triangulated Surface and select the imported STL shape. Then type 'python slice.py' in a shell in the folder which slice & fillet are in and when the dialog pops up, set the parameters and click 'Save Preferences'. Then type 'python fill.py' in a shell in the folder which fill is in and when the dialog pops up, set the parameters and click 'Save Preferences'. Then type 'python comb.py' in a shell in the folder which fill is in and when the dialog pops up, change the parameters if you wish but the default 'Comb Hair' is fine. Then type 'python stretch.py' in a shell in the folder which fill is in and when the dialog pops up, change the parameters if you wish but the default stretch is conservative. Then type 'python fillet.py' in a shell and when the dialog pops up, change the parameters if you wish but the default bevel is fine. Then click 'Fillet', choose the file which you exported in Export GNU Triangulated Surface and the filled & filleted file will be saved with the suffix '_fillet'.

To write documentation for this program, open a shell in the fillet.py directory, then type 'pydoc -w fillet', then open 'fillet.html' in a browser or click on the '?' button in the dialog. To use other functions of fillet, type 'python' in a shell to run the python interpreter, then type 'import fillet' to import this program.

The computation intensive python modules will use psyco if it is available and run about twice as fast. Psyco is described at:
[psyco.sourceforge.net]

The psyco download page is:
[psyco.sourceforge.net]

A quick aside: The GTS project produced a tool called stl2gts.

It is installed on Ubuntu by installing: libgts - GNU Triangulated Surface Library

The program seems to only want to work with stdin/out instead of specifying file names as parameters though. It took me a minute to figure that out. Here is how I call it:

(stl2gts < motor-coupling.stl ) >> motor-coupling.gts

The resulting gts file at least loads in the Skeinforge scripts. Anyway, I'm planning on using this to make my front-end able to directly open GTS or STL files.

Ok, it works now.

def main():
#filePrefix = 'poly-holder'
#filePrefix = 'Hollow Square'
filePrefix = 'motor-coupling'
filletChainFile(filePrefix + '.gts')
previewFile(filePrefix + '_fillet.gcode')

It seems filletChainFile is the orchestrator of the whole tool chain.

Hi Enrique

I just generated my first nearly usable file.

I had to do a couple of Edits.

I actually used Mach3 and the first line:-

(*CMST '('*)

caused a problem, it will not accept nested comments so I had to delete it. Ironic as you put it in for me. However when you add Start.txt that could go in there if required so perhaps it could be removed from the next version.

Also you put out all data on every line.

X Y Z and F are only needed if they change so you could reduce file size a lot.

G01 G02 G03 & G00 are also modal.


So this would work

G01 X10 Y20 Z0 F100
Y21. (implied G01 X10 Z0 F100)
X11. Y22.

etc.


I checked with Zach and the latest Gcode firmware should accept this.


Zach has also implemented M108 instead of M100 and Snnn instead of Pnnn as P is a reserved word in most G code as a delay i.e. G4 P2.0 and M100 is a reserved internal M function on some CNC implementations.


Lastly could the gcode suffix be a user parameter as my system requires filename.agc and I bet some others have a different requirement? Some you can change on the CNC but some you can't.

---

Regards

Ian

The (*CMST '('*) caused EMC to barf too.

Also the "M110 1.0" phrase caused problems. Perhaps "M110 (1.0)"?

However, by simply removing the "(*CMST '('*)", changing the "M110" line and adding a M30 (program end) to the end of the file I was able to get it to load correctly in EMC/Axis.

-------

I noticed that my part is floating in the air though... g-Code offers various user coordinate systems (G54-G59.3). If you use one of those (G54 is the most common) then you can simply set the XYZ 0 to the lower left corner of the bounding cube. If you do that then we can simply "touch-off" the 0 location for the part. ("Touch-Off" means to jog the tool to a particular location and then tell the machine where it is in a given coordinate system.)

Edited 1 time(s). Last edit at 05/29/2008 05:34PM by Brendan Erwin.

Thanks for all the suggestions, a skeinforge update with the stuff that was easy to implement is attached.


Ian

I've dropped (*CMST '('*). Skeinforge now looks for Start.txt or start.txt and puts that at the beginning of the gcode file. Right after it is initialized with stuff like extruder speed and temperature, it looks for a file called EndOfTheBeginning.txt or endofthebeginning.txt and adds that. At the end of the file it adds End.txt or end.txt. I've changed M100 to M108 and P to S.

Removing redundant gcodes and changing the extension to .agc will be done after I make an export plugin system. It could be done without it, but it'll be easier with a plugin system and I like things easy


Brendan,

I added an M30 (program end) at the end of the file. The command M110 1.0 was changed to M110.

Once I make raft.py & hop.py, which will take at least a few weeks, people will be able start the part at a desired altitude. For now, you can try adding commands to Start.txt or EndOfTheBeginning.txt or you can move the shape in Art of Illusion so that it starts at the right altitude.

Merry meet,
Enrique

Awesome.

One of the other changes I've made is to change all print commands to:

print >> sys.stderr, "stuff to print"

This was needed since, at least for now, the only way I can get the g-code to automagically import into Axis is by dumping it out stdout. If you'd like, I'll make the same change again to this latest code and post it back here for you to use. Let me know.

That reminds me, when you are designing that export plugin system having stdout be a destination instead of just a file would be great. (currently I read the gcode from disk and then delete the file, so I could just keep doing that if it gets hairy.)

Well, if you want it here is the code with the search/replace done to replace print with print >> sys.stderr

I also added "import sys" to all the files.

Come to think of it, I think the G5n coordinate system thing should be left to the start.txt mechanism.

Although I still think the part geometry should always start at 0,0,0 no matter what the input file says.

brendanjerwin Wrote:
-------------------------------------------------------

> Although I still think the part geometry should
> always start at 0,0,0 no matter what the input
> file says.

That would seem preferable to me as well - I'd rather have the script do the smart thing than force anyone who wants to use the toolchain to learn how to manipulate surfaces in AoI - that seems like an unnecessary requirement to impose on a user, and can only hinder adoption. If a user has a good reason to change the coordinate system, they probably know that, and will be able to put that in the start.txt file, right?

Hi


I would add my vote for 0,0,0 start as well. I take it this is lower left so all geometry is positive coordinates?

The Start.txt can take care of tool offsets and XY shifts.

---

Regards

Ian

Enrique

Many thanks for your efforts, really appreciated, it has quickly brought me to the point of actual printing. This weekend all being well.

---

Regards

Ian

I squashed an infill at the edges bug, so attached is the updated skeinforge.

I'll add an option to center the shape. It will however take a few weeks , because it would be part of raft.py, which will take a few weeks. I prefer to release stuff together, because that way I don't have to later deprecate code.

Hi Enrique

Adding M30 at the end of the main file causes a problem if you use end.txt. M30 really means rewind (From paper tape days) and it blocks any code after the M30 (apart from sub routines, but that's another story) so could it be taken out to go in end.txt. I wondered also if it would help to generate start.txt and end.txt as boiler plate files so users just have to edit and add code. End.txt could contain M30 and start.txt could contain maybe contain the file name as a comment.

---

Regards

Ian

hey guys...

just so we all stay on the same page with the gcode stuff, would you mind documenting and/or adding any info to the GCode page on the wiki?

[reprap.org]

it would be great if we can keep all this progress compatible. =)

Hi Zach

Can't register to access wiki........

---

Regards

Ian

Yo Ian,

Would putting M30 just after adding in end.txt work? Then M30 would be the very last line of gcode.

Thanks for the idea of adding the filename, I'll add it as a comment once I make the export plugin module. It will be easier for me to implement it then because only the very end of the tool chain only sees the filename.

Enrique

M30 isn't the only end code.

[http://www.linuxcnc.org/docs/html/gcode_main.html#sub:M0,-M1,-M2,] (include the last comma in the URL.)

I used M30 simply because that is what I remembered at the time. I think M2 would be a little more appropriate though. In either case I think just leaving it up to end.txt to deal with that would be the best route.

Nophead,

I squashed the extra perimeter when there is a small opening bug which you found when slicing Y_Housing_Square_Top. I also squashed an occasionally do not fill a triangular area bug, so attached is the updated skeinforge.

Brendan,

Thanks for the M2 suggestion. The program no longer adds M30 at the end of the file. In the end_example.txt file, there is the M2 command, and indeed that's all there is.

The files end_example.txt and start_example are not called by the program, there just gcode examples. Only start.txt and end.txt are added to the gcode.

Hi

Enrique

Putting the M30 after adding end.txt would be fine.
However would it be better to put it in end.txt so users can change it?
Also when I suggested generating basic start.txt and end.txt this must be if they don't exist. (Don't want to overwrite someone's carefully crafted set up files)

Brendan

M30 is rewind ie on some controls the programmes goes back to start and all you have to do is press start and the Gcode runs again. On old paper tape machines the tape rewound when it read M30.

M02 is programme end no rewind. Used an paper tape machines where the tape was looped.

M00 is pause ie stop programme but carry on to the following programme line when start button pressed.

M01 is optional stop ie pause only when the optional stop input was on. (usually a toggle switch)

This is Fanuc code usage which is the de facto standard. They do vary on other CNC's

Leading zero suppression means M0 M1 & M2 are accepted as M00 M01 M02

---

Regards

Ian

Enrique,
Thanks for the update. I finally got up to date with your code again, I am just using slice.py and fill.py at the moment. I should be able to try Kyle's bridge soon.

The extra shells is option is great, it should make very strong objects.

Unfortunately all the bugs seem to be still in this version, just a bit less extreme.



This is the second layer. It still has the infill sharp turn bug. Also as it is a solid layer I would not expect the second shell. It is not on the bottom or the third layer.



This is the infill crossing outline bug.



There is a very small instance (yellow triangle) of the outline in mid air bug.

I have attached the GTS file.

None of these look like show stoppers so I am building the object as I write this.

Regards, Chris

---

[www.hydraraptor.blogspot.com]

Enrique,
It has big problems with Kyle's bridge:-

The triangular girders get thinner than the filament as they approach zero thickness at the top. That causes the inside edge to be outside of the outside edge in slice.

After dice all the middle slices disappear so the top section is floating. I have "Infill In Direction of Bridges" ticked but it still does diagonal fill along the bridge. Odd that it is in the slice preferences and not the fill preferences.

---

[www.hydraraptor.blogspot.com]

Enrique,
A couple more bugs I think: -

When I sliced the x-idler bracket it did the infill on the second and third layers parallel to the axes, as if it though it was bridge perhaps.

I think when it does inner shells in tight places it allows it to get so thin it overlaps itself. I.e. it steps inwards by the width of the filament but does not check that there is still room for a filament.

Regards, Chris

---

[www.hydraraptor.blogspot.com]

Attached is an updated skeinforge with several of the bugs have been fixed, so the y-housing-square-top can be fabricated with only one tiny overlap bug remaining. However, the tight shell overlap bug remains so the truss still can not be fabricated.

"Infill In Direction of Bridges" is in the slice preferences and not the fill preferences, because you pointed out that the filaments spanning a bridge have a circular cross section rather than being squashed ovals. So the extrusion width is less and the layer thickness is more for that layer, which changes that slice layer.

The extra shell in the alternating solid layers is actually an undocumented feature, rather than a bug. In the opto bracket picture in your experimental extruder post:
[bp2.blogger.com]

we can see that the hole detached from the fill because the hole contracted inward, away from the infill which was contracting outward. One way of reducing the delamination is to have alternating layers where there is an extra perimeter. The extra perimeter will contract with the inner perimeter and has a line connection to it, rather than the series of points which the infill connects with, so it will have a strong connection to it. Then the infill of the next layer can connect to that extra perimeter, which although it has contracted, is still outside the inner perimeter. Overall you'll get sort of an accordion connection, which ain't as strong as a regular connection, but is better than no connection. I will document that in the next update.

Enrique,
I updated but this version seems to have worse infill bugs and takes almost exactly twice as long.

Here is what it does to the x-carriage: -



The are large areas missing on the bottom layer so not really usable.

The version I did with skeinforge was much better: -



Regards, Chris

---

[www.hydraraptor.blogspot.com]

Hi Nophead,

Sorry about the missing fill bug. I saw and squashed it a few days ago, but didn't post an update because it didn't seem important enough.

Attached is an updated skeinforge with all known bugs fixed. Now that the thin section bug is squashed, it can fill Kyle's simple truss correctly. Unfortunately, the extra overlap checking takes time, and the program will be slow for a long time because my order of development is bugfixes, features, documentation, speed.

The "Import Tiny Details" choice has been dropped in slice because the alternative option created incorrect fill. An "Extra Shells on Alternating Solid Layers" choice has been added, so the number of extra shells on the alternating solid layers can now be changed independently of the "Extra Shells on the Sparse Layer". For consistency, all the "Fill*" options in fill.py have been renamed "Infill*". Because of the way the preferences are saved, all those preferences will have to be reentered, if they are different from the defaults, which are copied from your blog

It took me longer than I expected to fix the thin section bug, so any estimated schedules I gave out are delayed by a week.

Thanks Enrique,
I will have another go at Kyle's truss this evening.

I think that we might need an extra parameter in the fill process. I assume that at the moment you shrink the outline by half the filament width and also space the infill threads by the filament width.

I think these value need to be independent because the infill should be squashed together for stength but the outer surfaces are not so the filament is slightly wider there.

---

[www.hydraraptor.blogspot.com]

Enrique,
Fill no longer works because it calls euclidean.getSurroundingLoops() but you have removed that from euclidean.py.

---

[www.hydraraptor.blogspot.com]

Hi Nophead,

I tried out the latest zip file and the new fill does not call euclidean.getSurroundingLoops(), which is indeed removed from the new euclidean. The new name for the similar function is euclidean.getOrderedSurroundingLoops(). So it may be that somehow when you downloaded the new zip file you ended up with the old fill.py and the new euclidean.py. I suggest deleting all the old skeinforge files you can find, except for the .csv preference files, download the new code again into another skeinforge folder and transfer the .csv files to the new folder.

Currently in the fill process I shrink the outline by half the filament width, I space the infill threads by the filament width, and then around the extrusion there is a no infill zone that is the filament width minus the "Infill Perimeter Overlap (ratio)" times half the filament width wide. For the extra parameter "perimeter width", I could shrink the outline by half a perimeter width, and then have a no fill zone that is half a perimeter width wide, plus half the filament width minus the "Infill Perimeter Overlap" times half the filament width wide. Would that work well, or is there another combination of parameters you'd prefer?