How to print Gcode from Host

I'm about half way through building the next LiveDVD. It will focused on developers so I was wanting to include this script. Is it ready for inclusion? Where from? Is it just a python script or does it need any other supporting files as well?

If you grab the latest version of the archive that Enrique has posted, that should have everything you need in it, assuming the box has python installed. The scripts also rely on Art of Illusion for one of the early processing steps, but I assume that will be included with your distro. In fact, if you move the two .bsh scripts from Enrique's archive to the scripts\tools directory of Art of Illusion, that will save one more step for the end user.

It is certainly functional - Nophead has been printing parts with it. I say go for it.

Kyle,

I'm glad it worked for you. After slicing there is still the fill stage, which takes very roughly as long as slicing. I'll try to slice and dice the truss this Sunday. If my computer can't slice it in a reasonable time, I'll ask you for the sliced gcode, which I assume is huge. The truss is by far the most complicated shape sliced to date.

Hi Reece

The scripts are zipped at:
[members.axion.net]

The python script chain needs python and the python GUI needs Tkinter with python bindings, information for which is at:
www.tcl.tk/software/tcltk/

The Art of Illusion .bsh files are in the Art of Illusion Scripts folder and the necessary supporting file is Export GNU Triangulated Surface. A helpful file is Import GNU Triangulated Surface. There is also Truncated Teardrop Shaper to make truncated teardrop holes and Gearweaver to make extruded gears. Please toss em all into the Art of Illusion scripts/tools directory.

The scripts can turn stl into gcode modern art. Unfortunately I haven't seen a posting of the python code to run the extruder off gcode. If you or someone else know where it is, please post it and I'll toss it into all future python zip files.

Cheers,
Enrique

Enrique Wrote:
-------------------------------------------------------
> Kyle,
>
> I'm glad it worked for you. After slicing there
> is still the fill stage, which takes very roughly
> as long as slicing. I'll try to slice and dice
> the truss this Sunday. If my computer can't slice
> it in a reasonable time, I'll ask you for the
> sliced gcode, which I assume is huge. The truss
> is by far the most complicated shape sliced to
> date.

I'm sorry, that's what I meant - I ran fillet.py as you suggested and presumably did the slicing, filling and filleting. The Gcode is ~7MB and the SVG is 13MB. Let me know if you want 'em.

Attached is the latest reprap python zipfile, which includes stretch.py, which stretches the threads to partially compensate for filament shrinkage when extruded. The important value for the stretch preferences is "Maximum Stretch Over Half Extrusion Width (ratio)" which is the ratio of the maximum amount the thread will be stretched compared to half of the extrusion width. The default is 0.3, if you do not want to use stretch, set the value to zero.

This, along with alternating extra shells, is to reduce horizontal delamination. It does not to decrease warpage, it just means the warped shape will now be in one piece

Also, when there is a bridge in the shape, like over the top of a truncated teardrop hole, the fill direction will now be in the direction of the bridge, so the fill can span without infill connections over empty space. In theory, this enables long bridges, at least long enough to span small holes.

Kyle,

By all means, post a link to the zipped truss gcode. You did a great job making the truss and slicing it, I figure it must of taken a long time to make the no steep overhang truss. With the original at ~7 MB and a typical zip gcode compression of about eight to one, the zipped file will be a Meg, still too big to be attached to a posting. If you don't have a place to post, please email it to me.

By the way, would you like to try a span experiment? When Nophead extruded his Cat's Cradle:
[hydraraptor.blogspot.com]

the filaments spanned a great distance. It might be possible to make your truss at its current size without overhang supports, although a large version of the truss would still need overhang supports because of the square cube law. Would you like to make & post a simple test truss with only two triangles on the bottom and one span without supports on top? Then maybe someone with an extruder could make it and we would all get an interesting picture

Cheers,
Enrique

Hi Enrique,
I am still using a very old version of Skienforge as it was doing everything I wanted so I have not updated. I have started getting null pointer errors so I will have to update soon.

An interesting bug occurred when I sliced the Darwin diagonal tie brackets. The stl file seems to have some bugs in it. The Reprap host slices it with some bits missing. Skienforge has an extra bit so I went with that as I can remove it afterwards with a drill. You have moved on so far you have probably fixed it already but the reason I mention it is that is illustrates bridge spanning.

The bracket has an 8mm vertical hole all the way through but Skeinforge decided to do a single layer with no hole in it part way up. The threads spanned the hole no problem and with no sagging because they pull tight with shrinkage. They did not bind horizontally though because having nothing to rest on they did not get squashed to an oval so they were too far apart to fuse. They would support the next layer though so I expect we could make completely hollow boxes with lids.

One of the reasons I have not kept up with the latest is I do not understand what most of your extra features are for.

Why do I want to fillet corners? Shouldn't I adjust the model if I wanted that? The filament has a minimum bend radius so all corners are filleted to that radius naturally.

What do you mean by beveling and what is it for?

Can you explain exactly what the hair combing does please. I throw way all head moves when the extruder is off so it probably won't do anything on my machine unless I mod my end.

I don't totally understand your latest post. Isn't that what "Infill perimeter overlap" does in Skeinforge?

---

[www.hydraraptor.blogspot.com]

Ok, the complete sliced truss along with the original STL and the SVG file are located at [hyperfileshare.com]. One thing that just occurred to me is that I don't know how your scripts determine which way is down on a particular STL file - does it have something to do with an orientation you can set in Art of Illusion before exporting the gts?

--------------
[related topic]

Attached is the STL file rendered below, with two triangles and a support "bridge". It is 7 cm^3, which I don't think would take too long to print, although it is true much of the time would be spent traveling from one isolated island on a level to another, which I'm sure increases print time greatly.



I think that the only person with a working skeinforge gcode interpreter right now is nophead - so nophead, would you be willing to try a test print of the attached STL, using Enrique's latest scripts with bridge support built in? I think it would be interesting to see what happens.

A dimensioned drawing, just for reference:

My machine just broke as I was reading your post! The flexible drive disintegrated yet again but it had just made 9 Darwin corner brackets, 3 opto brackets and 6 diagonal ties plus all the stuff I blogged recently.

Easy to fix, so I should be up and running next week and I will give it a go if Enrique's new code is compatible with mine.

---

[www.hydraraptor.blogspot.com]

Hi Nophead,

The corner filleting is a very small filleting on all filaments, even the infill filaments. This is to avoid sharp corners where the extrusion would blob and where the extruder would have to accelerate instantly. For example an extrusion extrusion width of 0.6 mm gives a half extrusion width of 0.3 mm, which gives a filleting radius of 0.21 mm = 0.7 * 0.3 mm.

Beveling is one of the filleting choices. It just slices off a diagonal off each corner, creating two nearby points at each corner. The other choices with filleting are arc segments, arc point and arc radius. The arc segments choice turns the corner into a series of small line segments along an arc. The arc point choice writes an arc gcode with a center and endpoint, the Arduino host should support this, but I have not seen this used with the gcode from the python slice and dice chain. The arc radius writes an arc gcode with a radius and endpoint, I don't know if the Arduino host can support this yet.

Hair combing moves the head around holes when the extruder is off to avoid almost all stringers in holes. Almost all the stringers which remain are between islands. So if you modded your end, there would be almost no stringers in the opto bracket, and some would be removed in the corner bracket.

Infill perimeter overlap overlaps the infill and overlap, assuming the infilll and perimeter do not contract after they are deposited. The stretch script stretches the filament in the opposite direction to the estimated contraction, so that after it is deposited, it will end up closer to where it's supposed to be. Since the modeling is really basic, the estimated contraction will be inaccurate, so the default "Maximum Stretch Over Half Extrusion Width (ratio)" is 0.3, which I guess will be less than the least that most plastics will contract.

I looked at the diagonal-tie-bracket and I guess the problem is that two of the holes just barely miss each other. Would it be a good idea for the designer to add a few mm of separation?

Yo Kyle,

Indeed the Expoxt GNU script follows the orientation set in Art of Illusion. The AOI version 2.5.1 that I'm using has a confusing bug in the top view where the z grid coordinates are reversed, so to check orientation I sometimes play around with the z value in the Properties pane. If you want to be extra careful, after you make the gcode you can check that Layer 0 really is the bottom layer.

Kyle,
Both Enrique's stuff and the RepRap host slice along the z-axis but in AOI that is forward backwards so the front view is actually the top of the object. Very confusing!

Enrique,
I know the RepRap host has problems with corner blobing but I don't, nor with infinite accelaration, my firmware sorts that out, so I guess I will just turn all these things off when I upgrade. The hair combing will be interesting but I will have to rewrite my s/w completely to be able to see it!

---

[www.hydraraptor.blogspot.com]

Enrique,

I'm using EMC2 to control my mill/repstrap and need to write some code to interface with the reprap specific hardware. (EMC2 lets you write applications to implement custom M-Codes.)

Anyway, I need a list of the custom M-Codes you expect to have implemented. Where would be the best place to find that?

Nophead,

Does your software implement the M-Codes? If so, which ones?

brendanjerwin,
I don't use the g-code to control my machine directly, I just use it to import the filament paths, so I only look at G1, M110 (it's filament height but I just use it to detect Skeinforge rather than RepRap) and M103 for end of thread (extruder off) . I also look for G92 from the RepRap host to start the first thread after it does some messing around for calibration.

My parser is very simple but also brittle to changes in the host or Enrique's code which is why I never updated once I got a version that worked.

---

[www.hydraraptor.blogspot.com]

Well that's not a lot of help!

------

You mentioned earlier that you thought it was a bad idea to have the slice/dice software directly export g-code. I agree with you. With the slice/dice operations being as expensive as they are (I've heard folks mention hours) an intermediate language certainly does seem to be in order. In some sense, that's exactly what you are doing now.

Some analysis of how you are using the g code output could be helpful in starting to define what that intermediate language would be/do.

All I do is convert the gcode into a list of layers, each of which is a list of threads, which are lists of points, which are Enrique's vec3 class.

I can then control the machine or view it in my previewer or make animated gifs.

I have attached the parser, it is trivial, less than 100 lines. XML would be even easier to parse in Python.

I have functions which tell me the bounding cube, total filament length, total head move distance, whether a path is open or closed, perimeter or hole, etc. All trivial stuff.

I aim to publish the whole thing when it becomes compatible with Darwin.

---

[www.hydraraptor.blogspot.com]

Hi Brendanjerwin,

An explanation of the gcodes is at:
[reprap.org]

A gcode example is at:
[forums.reprap.org]

In the skeinforge tool chain there are more gcodes being used, but they are only used for communicating within the tool chain or for viewing the gcode. For example there is M114, which as of today indicates a new layer is starting, which is used by the vectorwrite viewer and some other scripts. Attached is the python beanshell zipped code with the latest gcodes.

The only code actually being used to move the extruder is G1. In the case of skeinforge, the words after G1 are always the absolute position in millimeters. The gcode M101 is used to turn the extruder on and M103 to turn it off.

To see what more of the codes do, in a shell you can type 'python', then type 'import analyze', then type 'analyze.commentFile()', which will write comments for the first gcode file in the folder. The beginning output from that is below.

In case there is any confusion, generating the gcode takes a long time, however, parsing it is fast, at least a hundred times faster than extruding. The parser simply ignores any gcode line it does not need.

Cheers,
Enrique


( GCode generated by May 20, 2008 slice.py )
( Extruder Initialization )
( Set extruder speed to 210.0. )
M100 P210
( Turn extruder off. )
M103
( Set temperature to 200.0 C. )
M104 P200
( Custom code for temperature reading. )
M105
( Set extrusion diameter to 0.7 mm. )
M108 (0.7
M117 (0.76095
( Set extrusion width to 0.801 mm. )
M109 (0.801
( Set layer thickness to 0.534 mm. )
M110 (0.534
M111 (0.654
( Set units to mm. )
G21
( Set positioning to absolute. )
G90
( Start at home. )
G28
( The slice) procedure has been performed. )
M112 (slice)
( The fill) procedure has been performed. )
M112 (fill)
( Initialization is finished, extrusion is starting. )
M113
( Extruder paths for layer 0 )
( New layer is starting. )
M114 (0
( Linear move to 0.0, -3.077, -3.411. )
G1 X0.0 Y-3.077 Z-3.411 F600.0
( Turn extruder on. )
M101
( Loop is starting. )
M115 (edge
( Linear move to 16.902, -3.077, -3.411. )
G1 X16.902 Y-3.077 Z-3.411 F600.0
( Linear move to 17.611, -3.764, -3.411. )

Thanks for the info.

It looks like the current scheme uses the existing:

M7 - Coolant on
This turns the fan on.

M9 - Coolant off
This turns the fan off.

That will cause a problem since those codes will already be handled by EMC2. I wonder if we can change the Arduino GCode Interpreter to use some other code? Zach? Are you tuned in to this conversation?

It seems to me that it would be ok to make new codes since we already have to use specialized CAM software to generate the g-code. There isn't any benefit to using existing m codes. M101 - M199 are all available. How about we switch to using M106 and M107 for fan on and off?

Anyway, what if I want to run the fan AND flood coolant at the same time?!?! An automated mess.

I'd like to move the discussion concerning EMC2 to this topic:

[forums.reprap.org]

That way this one can get back to chronicling Nophead's and Enrique's adventures.

I've uploaded the scripts to SVN - they can be accessed from [reprap.svn.sourceforge.net]

Enrique,
I have noticed a bug in Skeinforge that affects the build quality. I don't know if it is still in your latest code. It could even be the way I parse it. Here is a simple example: -


Where the red infill changes direction it has two sharp points instead of two loops. That results in excess material causing surfaces to have ridges on them. If the extruder was off, making it two separate threads, it would be correct but not ideal.

Here is a more complex example :-


Edited 4 time(s). Last edit at 05/25/2008 06:46AM by nophead.

---

[www.hydraraptor.blogspot.com]

Enrique,
A couple more bugs have appeared when I started slicing pulley housings.

The infill crosses holes and itself sometimes: -



These inner outlines appear for a couple of layers with very strange infill around the edge: -



There is nothing above or below so these artifacts will be extruded into fresh air.

Edited 4 time(s). Last edit at 05/25/2008 07:31AM by nophead.

---

[www.hydraraptor.blogspot.com]

Hi Nophead,

For the bug where the fill doubles back at a sharp angle, that is corrected in the new code. I've got to leave now, so I'll test the Y_Housing_Square_Top fill in hole bug later.

Cheers,
Enrique

Enrique,
OK looks like I need finally need to update. The X motor bracket took 24.5 hours to slice with the beanscript so it was getting bit ridicules anyway.

---

[www.hydraraptor.blogspot.com]

Nophead,

I couldn't find Y_Housing_Square_Top in the reprap-cartesian-bot-1.0.5 folder. If the fill in hole bug is present in the new skeinforge, could you please post the Y_Housing_Square_Top shape?

Enrique

Hi Enrique

I am just about ready to try running a G code file generated with your scripts.

The only thing puzzling me at the moment is where you derive the object axis datums as the code generates a Z-1.74 dimension for the first pass where I expected it to be Z zero.

With my machine I normally use object bottom left viewed from above as Y0 and X0

---

Regards

Ian

Ian,
Enrique's skeinforge code outputs the same coordinates that are in AOI when you export the object. So if you want bottom left at the origin you have to move the object so its bottom left corner is at the origin in AOI. I assume the Python versions is the same, but I have not tried it yet.

My code calculates the bounding cube and then offsets to make (0,0,0) the bottom centre of the object. (0,0,0) is the centre of the table on HydraRaptor. Seems like CNC folks have a different convention. That way it does not matter where the object was in AOI.

If I am making one object then I add a random offset so that I am not wearing out the same area of the bed each time.

If I am making n objects the same I have a routine which spaces them out enough for the head to get between them.

---

[www.hydraraptor.blogspot.com]

This is a bugfix for a now squashed occasional divide by zero bug.

The new attached code also uses comments instead of M codes for most skeinforge specific commands, thanks to the excellent suggestions of Ian and Brendan. The only remaining skeinforge specific M code is M110.

It takes me extra time to upload to subversion because of software problems on my machine, so I'll only occasionally update the code at:
[reprap.svn.sourceforge.net]

The newest code will still be in this thread or at:
[members.axion.net]

Edited 1 time(s). Last edit at 05/26/2008 05:32PM by Enrique.

Thanks nophead

I don't think CNC have different convention, most people have their own scheme.

What CNC machine usually do have is at least 2 coordinate registers. A work or programme zero can easily be different to physical machine zero and the offset is retained even through power off. So when you home the machine it finds the switches just like Reprap and sets what I call machine zero. However programmes then use the work zero as reference.

Z is treated differently in that you have tool offsets, 1 for each tool (or extruder). When offsets are invoked with G43 H1 for tool 1 all Z moves are shifted by the offset so it is easy to use table top as Z0 for extruding. G49 cancels the offset and subsequent moves refer to the machine zero.

Set up is usually achieved by jogging to the Zero point required and Hot keys loading the different offset registers.

There is usually another Hot Key that toggles axis position display between the 2 registers.

None of this is set in stone and there are many different methods but I think the above method is the most common.

Hope I am not teaching Grandma apologies if so.

---

Regards

Ian

>Hope I am not teaching Grandma apologies if so.
Not as far as I am concerned, I know nothing about conventional CNC.

---

[www.hydraraptor.blogspot.com]

Enrique,

I'm putting together the Axis "Wizard" front-end for Skeinforge but I'm not clear on the correct usage. There are about a bazillion different seemingly atomic steps in there! (sliceFile, filletFile, arcSegmentFile, srcRadiusFile....)

Each one does have a description of what it does I see, but I'm unable to comprehend those descriptions due to lack of context. (I hope it's just lack of context...)

Can you give me an example or 10 of some basic work-flows through the tool-chain and perhaps why I'd want to do one operation vs. another?

Thanks.

Here is what I have so far:

from Tkinter import *
from math import *
from fillet import *
from slice import *
from fill import *
from preview import *
import tkMessageBox
import os

def main():
#filePrefix = 'poly-holder'
#filePrefix = 'Hollow Square'
filePrefix = 'motor-coupling'
sliceFile(filePrefix + '.gts')
filletFile(filePrefix + '_slice.gcode')
fillFile(filePrefix + '_slice_fillet.gcode')
previewFile(filePrefix + '_slice_fillet_fill.gcode')

It seems to work ok, but I don't think fillFile is doing anything. It takes 0 seconds and the preview is showing no filled layers. What am I missing?