How to print Gcode from Host

Thanks to Marius, part of the Metalab team building a reprap, whose adventures are described at:
[reprap.soup.io]

skeinforge can now slice files from the command line. For example to skeinforge the Hollow Square file, type:
> python skeinforge.py Hollow Square.gts

Also gifscene, which calls Nophead's preview, now works when called directly. So something like:
> python gifscene Hollow Square_export.gcode

will work. However, it seems that gifscene doesn't work when called from the preferences, so something like:
> python gifscene

then running gifscene from the preferences dialog, for unknown reasons, probably won't work.


In the last couple of weeks, I've ported over part of the Art of Illusion STL importer to the stl.py plugin, so skeinforge can now slice stl files directly.

I've also added Hop, to raise the extruder when it is not extruding.

The script slice.py has been renamed slice_shape, in order to avoid possible name collisions with the python slice keyword. So you'll have to rename slice.csv in the .skeinforge folder in your home directory to slice_shape.csv to keep your slice preferences.

The deprecated class vec3 has been removed entirely. Now, only Vec3 is available. The line to import the Vec3 class from the top level directory that skeinforge.py is in follows:
from skeinforge_tools.skeinforge_utilities.vec3 import Vec3

Thanks for the update!

I'm attaching a gts file which gives the following message 24 times during the comb stage:
"This should never happen, closestBetween should always exist."

The models extrudes fine nevertheless, but since I don't have any experience with comb, I thought I'd let you know. I can send you the aoi file if you prefer.
This message has been around in the last few releases, I just forgot to mention it earlier..

Cheers,

---

~/= Marius

--
We are Elektropeople for a better living.
[reprap.soup.io]
[www.metalab.at]

Very nice!

So if I want to slice an STL file, do I call the stl.py and it exports a .gts to feed to the rest of the script? Or can I call skeinforge.py directly with a .stl file and it will automatically translate it?

I may end up having to go through AoI anyway, because I think my CAD program exports STLs with seemingly randomly offset base coordinates just to make my life more interesting.

The skeinforge documentation summary is on the wiki at:
[reprap.org]

and it is referenced from:
[reprap.org]

This is just the documentation from skeinforge.py, the rest of the documentation is in the documentation folder of the skeinforge toolchain.


Kyle,

You can call skeinforge.py or any other tool directly with a .stl file and it will automatically translate and import it. You can also only translate the file by calling it from import_translator.py, but that is only useful for debugging.


Marius,

Thanks for posting the comb bug, the fixed version is attached.

Comb is a script to bend the extruder travel paths around holes in the slice, to avoid stringers. Or at least that's the theory, no one has actually tested it to see if the stringer follows when the nozzle is not extruding.

Below is the description of cool.py, which is a script to wait around at the end of the layer if necessary to cool the shape.

Also, stretch has been modified so that it stretches the perimeter more than the infill. In theory, with the correct value of 'Perimeter Maximum Stretch Over Extrusion Width', the hole paths will be widened enough that after contraction & squishing they end up at the original model size.

When slice_shape was generating the code, it looked for start.txt, endofthebeginning.txt and end.txt in its folder. Now, it also looks in ~/.skeinforge/gcode_scripts. This way you can have the scripts in a place which is not overwritten when you update skeinforge from the zip file.

I'm now updating the subversion version most of the times that I post an attachment, so it is no longer weeks out of date. The skeinforge subversion code is at:
[reprap.svn.sourceforge.net]

Cheers,
Enrique



Cool is a script to cool the shape.

The default 'Activate Cool' checkbox is on. When it is on, the functions described below will work, when it is off, the functions will not be called.

Cool works by waiting around at the end of a layer that didn't take long to extrude, so it has time to cool down. The important value for the cool preferences is "Minimum Layer Time (seconds)" which is the minimum amount of time the extruder will spend on a layer. If it takes less time to extrude the layer than the minimum layer time, cool adds orbits with the extruder off to give the layer time to cool, so that the next layer is not extruded on a molten base.

If the 'Turn Fan On at Beginning' preference is true, cool will turn the fan on at the beginning of the fabrication. If the 'Turn Fan Off at Ending' preference is true, cool will turn the fan off at the ending of the fabrication.



Stretch is a script to stretch the threads to partially compensate for filament shrinkage when extruded.

The default 'Activate Stretch' checkbox is on. When it is on, the functions described below will work, when it is off, the functions will not be called.

The important value for the stretch preferences is "Perimeter Maximum Stretch Over Extrusion Width (ratio)" which is the ratio of the maximum amount the perimeter thread will be stretched compared to the extrusion width, the default is 0.2. The higher the value the more it will stretch the perimeter and the wider holes will be. If the value is too small, the holes will have to be drilled out after fabrication, if the value is too high, the holes will be too wide and the part will have to junked, so the default is low. The 'Maximum Stretch Over Extrusion Width' is the ratio of the maximum amount the infill threads will be stretched compared to the extrusion width, in general this value should be around half the Perimeter Maximum Stretch preference.

In general, stretch will widen holes and push corners out. The algorithm works by checking at each turning point on the extrusion path what the direction of the thread is at a distance of "Stretch from Distance over Extrusion Width (ratio)" times the extrusion width, on both sides, and moves the thread in the opposite direction. The magnitude of the stretch increases with the amount that the direction of the two threads is similar and by the Stretch Over Extrusion Width ratio. The script then also stretches the thread at two locations on the path on close to the turning points. In practice the filament contraction will be similar but different from the algorithm, so even once the optimal parameters are determined, the stretch script will not be able to eliminate the inaccuracies caused by contraction, but it should reduce them.



When slice is generating the code, if there is a file start.txt, it will add that to the very beginning of the gcode. After it has added some initialization code and just before it adds the extrusion gcode, it will add the file endofthebeginning.txt if it exists. At the very end, it will add the file end.txt if it exists. Slice does not care if the text file names are capitalized, but some file systems do not handle file name cases properly, so to be on the safe side you should give them lower case names. It will first look for the file in the same directory as slice, if it does not find it it will look in ~/.skeinforge/gcode_scripts.

This is Awesome! If I read this thread correctly, it's now possible to print something without using java at all. This is wonderful news. Now if only I had an extruder...

Yes I have printed an entire Darwin without any Java thanks to Enrique's software.

---

[www.hydraraptor.blogspot.com]

So.

I downloaded it, and now have a massive gcode file. This is nice, but what I really want right now is a CAM interface to the arduino gcode interpreter.

I have a hand-written snippet of gcode that I'd like to dump to it. It'd also be nice to be able to "jog" the machine to the proper starting points.

What are you using to feed the gcode file to the arduino? And is there a "jog" type interface?

I've any number of problems with my machine, the X-axis in particular is floppy - I need a stiffer spring to hold the skate bearing against the rail. I've been using minicom to cut'n'paste snippets of gcode, and that has worked for getting kinks out of the machine, but the arduino takes every pasted chunk as one line. Meaning doing anything with more than a few seperate movements is tedious in the extreme.

The Skeinforge help refers to [reprap.soup.io] as the source for instructions on working with the arduino gcode interpreter, but I wasn't able to find anything useful in this context there. There's also a referance to M-Apps, which is the linuxCNC project and the EMC2 machine. Whereas I have the arduino controlling the steppers just fine and would like to test it with something a little more complex.

nophead, from what you've said I've gotten the impression that you have a arduino-driven darwin running with gcode and python? What are you using for the last step in the toolchain? I.E. send gcode to the arduino?

Edit: Nevermind. Downloaded the M-Apps things and wrote "send.py" which is called from the command line to send a gcode file to the arduino. It's just a quick hack, but it seems to work well enough.

Edited 1 time(s). Last edit at 08/23/2008 05:32PM by jgilmore.

Hi

Chris Meighan wrote a G code front end with jogging.

[forums.reprap.org]

Make sure you get the latest version as there was a problem with the first version if you use Windows.

---

Regards

Ian

jgilmore,
No I am not using an arduino, I am using a more powerful processor with a 100Mb Ethernet connection and Python script to do the printing. I have no jog interface, or any GUI for that matter yet.

---

[www.hydraraptor.blogspot.com]

jgilmore,

Zowie, thanks for writing send.py. I've added it to the fabricate folder, which is a grab bag of python code to talk to hardware. If you write a wiki page explaining how to use send, I'll link to it from the skeinforge documentation.

In the skeinforge help, I just mentioned [reprap.soup.io] because they somehow used skeinforge and the Arduino to print stuff. I dunno how they did it.

Hi,

We're using Zach's GCode Host, written in Processing. It's slightly modified, and the latest version is here:
[reprap.svn.sourceforge.net]

For jogging, we wrote our own exerciser, also in Processing:
[reprap.svn.sourceforge.net]

No GUI though, just a keypress interface.

Rumor has it that Zach is cooking up something awesome though

---

~/= Marius

--
We are Elektropeople for a better living.
[reprap.soup.io]
[www.metalab.at]

Enrique, I am willing to write more documentation for it if you feel that would be good. There's not much to write, but I suppose I can wax loquacious if the occasion demands. And I do have a tendancy to talk to little when it comes to telling people how to use things I've written. So where did you want it? (I.E. on which wiki/which page?)

It does sound like Marius and the good folks at reprap.soup.io have a more sophisticated solution. It is written in cpp and requires a different library, which is a downside. But send.py requires python-serial, which I suppose is a different library as well. And theirs certianly has more hours put into it! Hard to have less, after all.

P.S. I wasn't wanting a GUI, honest! I'm more comfortable with a command line interface. Now if only the Arduino didn't take 10 seconds to reset every time... and yes, I know there's a faster bootloader.

jgilmore Wrote:
-------------------------------------------------------
> It does sound like Marius and the good folks at
> reprap.soup.io have a more sophisticated solution.
> It is written in cpp and requires a different
> library, which is a downside.

It's not cpp, but Java/Processing, it's very basic, and it's trivial to get started with; just download Processing (it's like the Arduino IDE) from processing.org and launch the apps I posted a link to.

Edited 1 time(s). Last edit at 08/25/2008 10:17AM by Marius Kintel.

---

~/= Marius

--
We are Elektropeople for a better living.
[reprap.soup.io]
[www.metalab.at]

jqilmore,

What I suggest is writing the description as Arduino_Send, so the full wiki address would be:
[reprap.org]

Once you have a final version of the description, add it as a comment to the beginning of the send.py file, so that when pydoc is run, it will include that description in the generated file send.html. For an example of that, you can look into any of the skeinforge tools, like skeinforge.py.

Enrique, I can't get there. I don't have a registration, and I can't get one either. It doesn't respond to the same login/pw as the forums, gives me an error page. I click the registration link on the error page and get the following message:

"Sorry, but at the moment we're restricting wiki write access to the core development team, because we need to keep track of documentation changes before the first release. After that we'll probably freeze the release documentation pages and open up the rest of the wiki to all."

jgilmore, once you have a final version of the description, just send it to me and I'll add it to send.py and the wiki. You can send it by adding the comment to send.py and posting it to this thread again, or by sending me a private message through the forum or by sending email to perez_enrique at yahoo.com.

The latest version of John's send.py is in the fabricate folder and the documentation for it is at:
[reprap.org]

Gifscene no longer uses gifs, so it has been renamed skeinview. Skeinview is basically a version of preview which does not use the python imaging library and so can be run from within the skeinforge tool chain without running into the python imaging library & multiple Tkinter windows bug.

Two new tools have been added. Nozzle wipe, a script to wipe the nozzle and oozebane, a script to turn off the extruder before the end of a thread. The documentation for this stuff is below and the latest skeinforge is attached.

Cheers,
Enrique



Fabrication

To fabricate a model with gcode and the Arduino you can use the send.py in the fabricate folder. The documentation for it is in the folder as send.html and at:
[reprap.org]

Another way is to use an EMC2 or similar computer controlled milling machine, as described in the "ECM2 based repstrap" forum thread at:
[forums.reprap.org]

using the M-Apps package, which is at:
[forums.reprap.org]

Yet another way is to use Zach's GCode Host, written in Processing:
[reprap.svn.sourceforge.net]

For jogging, the Metalab group wrote their own exerciser, also in Processing:
[reprap.svn.sourceforge.net]

The Metalab group adventures are described at:
[reprap.soup.io]



Skeinview is a script to display each layer of a gcode file.

The default 'Activate Skeinview' checkbox is on. When it is on, the functions described below will work when called from the skeinforge toolchain, when it is off, the functions will not be called from the toolchain. The functions will still be called, whether or not the 'Activate Skeinview' checkbox is on, when skeinview is run directly.

If "Go Around Extruder Off Travel" is selected, the display will include the travel when the extruder is off, which means it will include the nozzle wipe path if any. The "Pixels over Extrusion Width" preference is the scale of the image, the higher the number, the greater the size of the display. If the number is too high, the display will be larger than the screen.



Nozzle wipe is a script to wipe the nozzle.

At the beginning of a layer, depending on the preferences nozzle, wipe will move the nozzle with the extruder off to the arrival point, then to the wipe point, then to the departure point, then back to the layer.

The default 'Activate Nozzle Wipe' checkbox is on. When it is on, the functions described below will work, when it is off, the functions will not be called.

The "Location Arrival X" preference, is the x coordinate of the arrival location. The "Location Arrival Y" and "Location Arrival Z" preferences are the y & z coordinates of the location. The equivalent "Location Wipe.." and "Location Departure.." preferences are for the wipe and departure locations.

The "Nozzle Wipe Period (layers)" preference is the number of layers between nozzle wipes. Nozzle wipe will always wipe just before the first layer, afterwards it will wipe every "Nozzle Wipe Period" layers. With the default of three, nozzle wipe will wipe just before the zeroth layer, the third layer, sixth layer and so on.



Oozebane is a script to turn off the extruder before the end of a thread.

The default 'Activate Oozebane' checkbox is on. When it is on, the functions described below will work, when it is off, the functions will not be called.

The important value for the oozebane preferences is "Early Shutdown Distance Over Extrusion Width (ratio)" which is the ratio of the distance before the end of the thread that the extruder will be turned off over the extrusion width, the default is 2.0. A higher ratio means the extruder will turn off sooner and the end of the line will be thinner.

When oozebane turns the extruder off, it slows the feedrate down in steps so in theory the thread will remain at roughly the same thickness until the end. The "Turn Off Steps" preference is the number of steps, the more steps the smaller the size of the step that the feedrate will be decreased and the larger the size of the resulting gcode file, the default is 3.

Oops, there was an overrun at the end of thread bug in oozebane. The updated version is attached and the documentation is below.

Cheers,
Enrique




Oozebane is a script to turn off the extruder before the end of a thread.

The default 'Activate Oozebane' checkbox is on. When it is on, the functions described below will work, when it is off, the functions will not be called.

The important value for the oozebane preferences is "Early Shutdown Distance Over Extrusion Width (ratio)" which is the ratio of the distance before the end of the thread that the extruder will be turned off over the extrusion width, the default is 2.0. A higher ratio means the extruder will turn off sooner and the end of the line will be thinner.

When oozebane turns the extruder off, it slows the feedrate down in steps so in theory the thread will remain at roughly the same thickness until the end. The "Turn Off Steps" preference is the number of steps, the more steps the smaller the size of the step that the feedrate will be decreased and the larger the size of the resulting gcode file, the default is 3.

Oozebane also turns the extruder on just before the start of a thread. The "Early Startup Maximum Distance Over Extrusion Width" preference is the ratio of the maximum distance before the thread starts that the extruder will be turned off over the extrusion width, the default is 2.0. The longer the extruder has been off, the sooner the extruder will turn back on, the ratio is one minus one over e to the power of the distance the extruder has been off over the "Early Startup Distance Constant Over Extrusion Width".

Enrique, with certain STL files I'm getting the 2nd and third raft layers offset by about half the width of the raft. Here's the STL, and the layer pic:

It only happens with that file; I can build a proper raft with the included HollowSquare.stl.

Just to be sure, I renamed my preferences directory, and re-downloaded the zip file from this thread, but I'm still getting an odd raft.

Can't add the graphics files as they're too large, so here's a zipped version of the Gcode output. The 2nd and 3rd raft layers are the offset ones.

Wade

Wade, thanks for finding the interface offset when the shape is not centered bug and posting the files. The updated skeinforge is attached and at:
[members.axion.net]

In a while I will update the subversion version.

Cheers,
Enrique

Another stupid question - what's the purpose of the bit of code? I've built a sparse 30mm cube, and after each outer rim is built, the code mashes the print head down a couple mm and does an orbit without extruding. I can see the extruder bending - what do I hit to turn that off? And what was the original idea there?

Here's an example of the snippet:

G1 X5.18 Y27.64 Z16.41 F480.0
G1 X4.45 Y27.64 Z16.41 F400.0
M103
G1 X3.75 Y27.64 Z16.41 F240.0
G1 X3.05 Y27.64 Z16.41 F80.0
G1 X2.39 Y27.64 Z16.41 F10.021
G1 X2.36 Y27.61 Z16.41 F480.0
( )
( 16.649 )
( )
( X0.42 Y29.58 Z14.773 )
( X29.58 Y29.58 Z14.773 )
( X29.58 Y0.42 Z14.773 )
( X0.42 Y0.42 Z14.773 )
( )
G1 X1.55 Y27.61 Z17.08 F480.0
G1 X1.23 Y27.61 Z17.16 F480.0
G1 X0.56 Y27.61 Z16.93 F481.11
M101
G1 X0.42 Y27.61 Z16.88 F480.0
G1 X0.42 Y29.4 Z16.88 F480.0
G1 X0.6 Y29.58 Z16.88 F480.0
G1 X29.4 Y29.58 Z16.88 F480.0

I've also attached the whole Gcode file.

Thanks - getting very close to printing some useful parts!

Wade

Wade,

The "( ) " and "(.." lines are comments. Comments are only used in the tool chain and should not be executed by a gcode interpreter. To remove them, in the export tool turn the "Delete Comments" checkbox on.

The and comments are to define a region in a layer. This is useful for some tools, for example the comb tool moves the extruder around regions so that there is less hair in holes.

Enrique

Aha! Yes, it turns out my gcode interpreter is actually moving to the coordinates in the comments - there's the problem! Nixing the comments may help with some buffer issues I was having as well.

Thanks!

Wade

PS - nixing the comments doesn't work. I wiped everything, rebooted, reloaded Skeinforge from the zip file above, and the preferences file .skeinforge/export.csv gets updated to:
Format is tab separated preferences.
Activate Export True
Also Send Output To:
Delete Comments True
Delete M110 Gcode Line True
Do Not Change Output True
gcode_small False
Open File to be Exported

But I'm still getting loads of comments in my gcodes... any ideas?

PPS:
Nevermind, "Export Small" needs to be checked too, now the comments are gone. Good thing I can edit my posts.

Edited 2 time(s). Last edit at 09/10/2008 04:28PM by Wade.

Wade,

Thanks for pointing out the don't actually delete comments bug. It's good that "Gcode Small" deletes comments also, but export should of deleted them even without "Gcode Small". The updated version is attached and at:
[members.axion.net]

In a while I will update the subversion version for the export bug. The oozebane bug was updated in the subversion version a few days ago.

Cheers,
Enrique

Hi,

I have been experimenting with send.py which is a great utility but has a couple of small issues.

First, probably because I use Windows, it ALWAYS resets the Arduino when attaching the serial port and I have found no workaround for this. This leads to the second issue which is that the sender assumes that it will receive an "ok" and nothing else after every command. This is mostly OK except when heating the extruder where a load of temperature readings get returned causing the sender to crash.

I have modified the RepRapArduinoSerialSender.py to tolerate and print additional output and wait for the following "ok". This cures the additional output problem and all that I now need is some serial output buffer handling and all will be perfect ... well, maybe I'll look at that tomorrow

Meanwhile I have attached a copy of the updated sender file for anyone who may find it useful. By the way - in order for any of this to work (at least for Windows) you need to have found and downloaded the pyserial package needed for serial comms and the pywin package for a nice GUI editor/debugger as well as python wrappers for the Windows APIs.

Peter

Thank you pjr. I don't have an extruder so I haven't run into that problem. Several days after finishing with send.py, I'd noticed in my hacking away at the g-code firmware that the tempurature code did repeatedly print the temperature, but hadn't come up with a solution yet. I'll definately be using this. Eventually, I mean.

---

--
I'm building it with Baling Wire

pjr,

Thanks for modifiying RepRapArduinoSerialSender.py, I've added your update to skeinforge in the attachment and in subversion.

A couple of oozebane bugs were fixed.

In raft, the "Turn Extruder On Early" option default is now off because oozebane also turns the extruder on early. The temperature of the outline of the first layer can now be changed and the default temperatures for HDPE were changed to those of Nophead's screw cap extrusion.

Loop tailor has been added. Loop tailor clips the ends of loops, as Nophead suggested, and jitters position to a different place on each layer to prevent the a ridge from forming, as Ronanwarrior suggested. The documentation for loop tailor follows below.

Enrique



Loop tailor is a script to clip loop ends and jitter their position.

The default 'Activate Loop Tailor' checkbox is on. When it is on, the functions described below will work, when it is off, the functions will not be called.

Loop tailor clips the ends of loops and jitters position to a different place on each layer to prevent the a ridge from forming. The "Clip Over Extrusion Width (ratio)" is the ratio of the amount the loops are clipped over the extrusion width. If the ratio is too high loops will have a gap, if the ratio is too low there will be a bulge at the loop ends. The "Jitter Over Extrusion Width (ratio)" is the ratio of the amount the loop ends will be jittered. A high value means the loops will start all over the place and a low value means loops will start at roughly the same place on each layer. To run loop tailor, in a shell type:
> python loop_tailor.py

Loop tailor has been moved into comb and clip. Comb now also moves the extruder to the inside of outer perimeters before turning the extruder on so any start up ooze will be inside the shape.

A bunch of bugs have been fixed in what is now comb and clip. The updated package is attached and in subversion. The description of comb and clip is below.

Enrique


Comb bends the extruder travel paths around holes in the slice, to avoid stringers. It moves the extruder to the inside of outer perimeters before turning the extruder on so any start up ooze will be inside the shape. It jitters the loop end position to a different place on each layer to prevent the a ridge from forming. The 'Arrival Inset Follow Distance over Extrusion Width' is the ratio of the amount before the start of the outer perimeter the extruder will be moved to. A high value means the extruder will move way before the beginning of the perimeter and a low value means the extruder will be moved just before the beginning. The "Jitter Over Extrusion Width (ratio)" is the ratio of the amount the loop ends will be jittered. A high value means the loops will start all over the place and a low value means loops will start at roughly the same place on each layer.


Clip clips the ends of loops to prevent bumps from forming. The "Clip Over Extrusion Width (ratio)" is the ratio of the amount the loops are clipped over the extrusion width. If the ratio is too high loops will have a gap, if the ratio is too low there will be a bulge at the loop ends.

Edited 3 time(s). Last edit at 10/12/2008 02:28AM by Enrique.

Thanks Enrique

I want to use Mach3 and Windows to run G code from Skeinforge. I had a hold up as Mach3 had some issues running M function macros which are now largely resolved so I am back testing.

I have a couple of things I would like to know.

The first is how to change the suffix of generated code to ??.AGC instead of ??.gcode.

Secondly what is controlling the temperature that is output? I need S135 and I get S210 but can't figure out where can it be changed.

---

Regards

Ian