How to print Gcode from Host

Hi Enrique,
Sorry about that, for some reason the unzip overwrote some files but not others.

I actually only want to increase the perimeter shrink slightly and leave the infill perimeter spacing the same but I think what you propose makes more sense logically. I can just compensate by changing the overlap slightly.

Of course the perimeter width should be relative to the filament diameter. I still think my scheme of specifying diameter, height/diameter and width/diameter is more direct than diameter, width/height and density. The machine sets the height and diameter, I measure the width. These are the primary parameters. Aspect ratio and density have to be calculated from these. I think this becomes more compelling now that we have two widths.

I finally got to try Kyle's truss. It turned out pretty good. I will blog it on the main blog.

Edited 1 time(s). Last edit at 06/14/2008 07:06AM by nophead.

---

[www.hydraraptor.blogspot.com]

Hi Enrique,
A couple more bugs I'm afraid: -

I have "Infill Density (ratio): 0.25" but the object is now 100% filled all the way through.

Still some infill lines missing, here is a simple example: -



Did the meaning of "Infill Perimeter Overlap (ratio)" change at some point? I have always had it set to 0.5 but now I seem to be getting far too much plastic in the infill for some reason.

Chris

---

[www.hydraraptor.blogspot.com]

Hi Nophead,

Thanks for noticing the 100% infill bug, the updated bugfixed skeinforge is attached.

After you mentioned the problem with not overwriting fill.py, I realized that it was because I have the preferences in the same folder as the program, so you had to move preference files around whenever you updated the program. This design flaw is a holdover from when I was developing the preferences. The preferences are now saved in the .skeinforge folder in the home directory. You'll have to move your preferences there or input your values again.

The remaining missing infill bug is rare, and I could not reproduce it with my parameters. Could you please post the gts file and your preferences? It is not necessary to post all the files with most bugs because they occur everywhere, but this one is rare enough that I'll need everything.

The "Infill Perimeter Overlap (ratio)" parameter still has the same meaning. I tried changing it, and it still works, putting in a value of 0.0 instead of the default 0.5 resulted in a wider gap between the infill and perimeter. When I view the extruder paths I can't see more plastic so I'm just going to speculate wildly. I'm hoping that it may be related to the 100% infill bug, it may be that when there is a sparse infill that gives the plastic a bit more place to go. It may be that the extruder is going over the same place twice, which would not be visible in the viewer, although I checked the gcode and could not find any duplicated locations so that probably ain't it.

Hi Enrique,
Here are my preferences:-

Format is tab separated preferences.
Extrusion Diameter (mm): 0.5
Extrusion Density (ratio): 0.82
Extrusion Width Over Thickness (ratio): 1.5
Open File to be Sliced
Import Coarseness (ratio): 1.0
Correct Mesh True
Unproven Mesh False
Infill Bridge Width Over Thickness (ratio): 1.5
Infill in Direction of Bridges False
Slice All GNU Triangulated Surface Files in a Directory False
Slice File True

Format is tab separated preferences.
Diaphragm Period (layers): 299
Diaphragm Thickness (layers): 0
Extra Shells on Alternating Solid Layer (layers): 1
Extra Shells on Base (layers): 0
Extra Shells on Sparse Layer (layers): 1
Feedrate (mm/s): 16.0
Open File to be Filled H:/CHRIS/Projects/RepRaptor/Darwin/stl/Fan-leg.gts
Infill Begin Rotation (degrees): 45.0
Infill Density (ratio): 0.25
Infill Odd Layer Extra Rotation (degrees): 90.0
Infill Perimeter Overlap (ratio): 0.5
Solid Surface Thickness (layers): 3
Fill All Unmodified Files in a Directory False
Fill File True

The gts is attached.

Yes I think the 100% fill makes the extra material far worse. Possibly the overlap parameter needs to be 0 or there will always be too much plastic. When I was using my own software I had a much lower value and it only affected the ends of the infill. I arrived at 0.5 when I first used you software because the infill was not sticking to the perimeter. More experimentation required I think. It might need to be higher on the first layer, or on the sparse layers.

---

[www.hydraraptor.blogspot.com]

Enrique,
I updated and set the infill overlap to 0 and the missing infill bug went away on the fan base. It also produced a much better looking result. I had begun to think there was too much plastic in the solid layers. I have been making smaller objects recently so of course the perimeter to area ratio is higher, so the effect of the overlap is greater.

I think whatever reason I had it set to 0.5 has long gone, although I will have to print a big object to be sure.

Chris

---

[www.hydraraptor.blogspot.com]

Nophead,
Thanks for sending the Fan-base file and preferences. With those I was able to reproduce and squash the missing infill bug in the attached skeinforge.

Enrique,
Thanks for writing it and fixing the bugs so promptly!

I am finding the dimensional accuracy is not all that good. The outside seems to shrink a bit but the holes seem to shrink more. Can you remind me what stretch.py does.

---

[www.hydraraptor.blogspot.com]

Hi Nophead,

Stretch is a script to stretch 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. With a value of one or more, the script might stretch a couple of threads in opposite directions so much that they overlap. In theory this would be because they'll contract back to the desired places, but in practice they might not. The optimal value of stretch will be different for different materials, so the default value of 0.3 is chosen because it will counter the contraction a bit, but not enough to cause overlap trouble.

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 "Maximum Stretch Over Half 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.

I found and squashed a perimeter overlap bug. As a side effect of the big fix, the perimeter corners are sharper and the toolchain is a bit faster.

I added tower.py, a script to extrude a few layers up, then go across to other regions.

This script commands the fabricator to extrude a disconnected region for a few layers, then go to another disconnected region and extrude there. Its purpose is to reduce the number of stringers between a shape and reduce extruder travel. The important value for the tower preferences is "Maximum Tower Height (layers)" which is the maximum number of layers that the extruder will extrude in one region before going to another. When the value is zero tower will do nothing. Because tower could result in the extruder collidiing with an already extruded part of the shape and because extruding in one region for more than one layer
could result in the shape melting, the default is the safe value of zero.

Tower works by looking for islands in each layer and if it finds another island in the layer above, it goes to the next layer above instead of going across to other regions on the original layer. It checks for collision with shapes already extruded within a cone from the nozzle tip. The "Extruder Possible Collision Cone Angle (degrees)" preference is the angle of that cone. Realistic values for the cone angle range between zero and ninety. The higher the angle, the less likely a collision with the rest of the shape is, generally the extruder will stay in the region for only a few layers before a collision is detected with the wide cone. The default angle is sixty degrees.

The "Tower Start Layer" is the layer which the script starts extruding towers. It is best to not tower at least the first layer because the temperature of the first layer should sometimes be different than that of the other layers. The default preference is three. To run tower, in a shell type:
> python tower.py


Hi Nophead,

Thanks for pointing out that using extrusion width over extrusion diameter would be better than the complicated density method used before, so that has been changed in slice. The slice defaults are set to end up with the same height and width as hydraraptor had before, so extrusion diameter is now 0.6 mm, extrusion height over diameter is 0.67 & extrusion width over diameter is 1.0; which gives a height of 0.4 mm and a width of 0.6 mm. Extrusion perimeter width over diameter has been added to have wider perimeters.

To calculate the infill perimeter overlap, there is the choice of calculating from the perimeter and infill which may be more logical and calculating from the perimeter only which is simpler. The default is with perimeter and infill. The new default infill perimeter overlap is 0.1 instead of the old 0.0 calculated from infill extrusion width, because the perimeter is wider 0.1 calculated from perimeter and infill should be close to 0.0 from the old infill alone calculation.


Hey Brendan,

Thanks for writing up your excellent MCode reference at:
[reprap.org]

Also, you or someone else may have mentioned that having M108 with Snnn for extruder speed PWM is a machine specific unit. So I'm adding a third Snnn.nnn parameter with the flowrate in mm3/s, so in future machines with different motors can calculate what the extrusion speed should be. The new line would look like M108 S210 S3.324. Would adding a third parameter cause either the EMC or Arduino to have problems?

EMC should be able to handle the syntax you describe. An MCode application can take 2 parameters. (They like P and S is I remember correctly, but I post-process into that syntax, so don't worry about it.)

Hi Enrique

EMC might be OK but Mach3 would have trouble with 2 S words on one line.

No way of knowing which is which.

How about sticking to a single S word and then having a flag in your software to set the S output as either speed or flow rate as required the machine hardware.

Most machines would need one or the other but not both.

Edited 2 time(s). Last edit at 06/28/2008 09:14AM by Ian Eagland.

---

Regards

Ian

Well, EMC wouldn't actually get 2 S Words. It would be S and P I think.

My vote would actually be for skeinforge to just output the mm3/s number and let post-processing decide what to do with it. On machines that need PWM the post-processing would simply decide what values to map to.

I am curious, does skeinforge deal with variable extrusion rates? If so, isn't mm3/s the only usable value? As opposed to PWM that is.

Also, is mm3/s intended to be extrusion rate or feed-stock feed rate?

Hi Brendan

For some CNC machines skeinforge takes the place of the post processor. The code output is usable directly into Mach3 without any further work so the option in skeinforge to output speed or volume as an S word should meet all requirements.

---

Regards

Ian

I think that skeinforge shouldn't need to be concerned with the conversion of extrusion volume to PWM. If it was just a boolean flag or something I'd say "put it in skeinforge" but the translation of desired extrusion volume to motor PWM seems much more complicated than that...

Hi Brendan

I wasn't expecting conversion of volume to PWM. Just asking that Enrique maintains compatibility with Arduino G code which accepts the 'S' parameter as a number between 0 and 255. My implementation of Mach3 uses the Arduino G code firmware for extruder and heater control.

---

Regards

Ian

Thanks Ian and Brendan for chewing on the flow rate question.


Yo Brendan,

Would Ian's suggestion of having a preference for PWM or flow rate work out? In other words, there would be a choice to either input the PWM or have the flow rate calculated, then the choice would be added to the M108 Snnn line.

Currently, there is only one flow rate. In future I'm planning on adding some tools which would vary the flow rate. They would multiply whatever number there is in the nnn part of the M108 line.

The mm3/s is intended to be extrusion flow rate. Some machines would calculate the feed-stock feed rate from the flow rate and the feed stock diameter.

Eventually I assume that all the g-code interpreters will be changed to expect an actual extrusion rate rather than a PWM value since PWM is too specific to be meaningful. Once the rotational encoder stuff is complete, PWM should be pretty close to meaningless. Less meaningless might be RPM, but better still would be mm3/s extrusion rate.

However, for now my vote is to take the simple path and relegate the M108 word to start.txt. Later, when you need to vary or more specifically define flow-rate you can add it to the guts of things and by then I expect it will be better defined as a less meaningless parameter than PWM.

Below is the description of raft.py, which adds a raft and the flowrate to the gcode. Raft is part of the attached, latest version of skeinforge.

For the flowrate, there is now a choice of "Do Not Add Flowrate", "Metric" and the default "PWM Setting". When "Do Not Add Flowrate" is selected, raft does not add the M108 flowrate, so any flowrate added in start.txt will not be overridden. If "Metric" is selected, the flowrate in cubic millimeters per second will be added to the output. If "PWM Setting" is selected, the value in the "Flowrate PWM Setting" field will be added to the output.

Cheers,
Enrique


Raft is a script to create a reusable raft, elevate the nozzle and set the feedrate, flowrate and temperature.

Raft is based on the Nophead's reusable raft, which has a base layer running one way, and a couple of perpendicular layers above. Each set of layers can be set to a different temperature. There is the option of having the extruder orbit the raft for a while, so the heater barrel has time to reach a different temperature, without ooze accumulating around the nozzle. To run raft, in a shell type:
> python raft.py

The important values for the raft preferences are the temperatures of the raft, the first layer and the next layers. These will be different for each material. The default preferences for ABS, HDPE, PCL & PLA are from Nophead's experiments. To change the material, in a shell type:
> python material.py

This brings up the material preferences dialog. In that dialog you can add or delete a material on the listbox and you can change the selected material. After you change the selected material, run raft again. If there are preferences for the new material, those will be in the raft dialog. If there are no preferences for the new material, the preferences will be set to defaults and you will have to set new preferences for the new material.

The raft script sets the feedrate, flowrate and temperature. If the "Add Raft, Elevate Nozzle, Orbit and Set Altitude" checkbox is checked, the script will also create a raft, elevate the nozzle, orbit and set the altitude of the bottom of the raft.

The "Base Infill Density" preference is the infill density ratio of the base of the raft, the default ratio is half. The "Base Layer Height over Extrusion Height" preference is the ratio of the height & width of the base layer compared to the height and width of the shape infill, the default is two. The "Base Layers" preference is the number of base layers, the default is one. The "Base Nozzle Lift over Half Base Extrusion Height" is the amount the nozzle is above the center of the extrusion divided by half the base extrusion height.

The interface of the raft has equivalent preferences called "Interface Infill Density", "Interface Layer Height over Extrusion Height", "Interface Layers" and "Interface Nozzle Lift over Half Base Extrusion Height". The
shape has the equivalent preference of called "Operating Nozzle Lift over Half Extrusion Height".

The altitude that the bottom of the raft will be set to the "Bottom Altitude" preference. The feedrate for the shape will be set to the 'Feedrate" preference. The feedrate will be slower for raft layers which have thicker extrusions than the shape infill.

In the "Flowrate Choice" radio button group, if "Do Not Add Flowrate" is selected then raft will not add a flowrate to the gcode output. If "Metric" is selected, the flowrate in cubic millimeters per second will be added to the output. If "PWM Setting" is selected, the value in the "Flowrate PWM Setting" field will be added to the output.

The raft fills a rectangle whose size is the rectangle around the bottom layer of the shape expanded on each side by the "Raft Outset Radius over Extrusion Width" preference times the extrusion width, minus the "Infill Overhang" ratio times the width of the extrusion of the raft.

The extruder will orbit for at least "Temperature Change Time of Raft" seconds before extruding the raft. It will orbit for at least "Temperature Change Time of First Layer" seconds before extruding the first layer of the shape. It will orbit for at least "Temperature Change Time of Next Layers" seconds before extruding the next layers of the shape. If a time is zero, it will not orbit.

The "Temperature of Raft" preference sets the temperature of the raft. The "Temperature of Shape First Layer" preference sets the temperature of the first layer of the shape. The "Temperature of Shape Next Layers" preference sets the temperature of the next layers of the shape.

Enrique, I found a small bug in your script - everytime it prints the tag, it leaves the closing ")" off of the line, and emc2 complains. Not a big deal at all, and I may get around to fixing it for myself.

Major kudos for building this great tool!

Hi Kyle,

Thanks for spotting the now squashed bracket bug. Another bug, where the material defaults were not copied over, has also been squashed. The updated skeinforge is attached.

Cheers,
E

Attached is the latest skeinforge, which now has the export tool. Below is the description of export, which gives the option of sending gcode to an export plugin and can print the output to a file. There are also descriptions of the included plugins, gcode_only and gcode_small.

To print the output to a file, in the export dialog set the "Also Send Output To" field to the file you want. For example to send the output to stderr, set the field to "sys.stderr".

Cheers,
Enrique



Export is a script to pick an export plugin and optionally print the output to a file.

Export presents the user with a choice of the export plugins in the export_plugins folder. The chosen plugin will then modify the gcode or translate it into another format. There is also the "Do Not Change Output" choice, which will not change the output.

To print the output to a file, add the file output name to the "Also Send Output To" field. A common choice is sys.stdout to print the output in the shell screen. Another common choice is sys.stderr. The default is nothing, in which case the output will not be printed to a file.

If the "Delete M110 Gcode Line" checkbox is true, export will delete the M110 gcode line, whose only purpose is to indicate that the gcode is generated by skeinforge. The M110 gcode is not necessary to run a fabricator.

An export plugin is a script in the export_plugins folder which has the functions getOuput and writeOutput.

To run export, in a shell type:
> python export.py


Gcode_only is an export plugin to remove all the comments from a gcode file.

An export plugin is a script in the export_plugins folder which has the functions getOuput and writeOutput. It is meant to be run from the export tool.

The getOuput function of this script takes a gcode text and returns that text without comments. The writeOutput function of this script takes a gcode text and writes that text without comments to a file.


Gcode_small is an export plugin to remove the comments and the redundant z and feedrate parameters from a gcode file.

An export plugin is a script in the export_plugins folder which has the functions getOuput and writeOutput. It is meant to be run from the export tool.

The getOuput function of this script takes a gcode text and returns that text without comments and redundant z and feedrate parameters. The writeOutput function of this script takes a gcode text and writes that text without comments and redundant z and feedrate parameterscomments to a file.

Many of the functions in this script are copied from gcodec in skeinforge_utilities. They are copied rather than imported so developers making new plugins do not have to learn about gcodec, the code here is all they need to learn.

Hey Enrique,

Looks good, I'm going to try and get away with running your script unmodified (or maybe just inserting g-codes to wipe the tool between layers) in Brendan's EMC2 extension. How goes the plugin plan? It's probably just as easy to write a simple script that parses the file after it has been outputted, but that's another step.

Have you given any thought to making a slightly easier to use GUI, that puts all the preferences from the half-a-dozen separate scripts up on the screen at once? The process of calling each one independently is nonintuitive. If not, I may work on that later this year when I have more time, or see if any of my friends are interested in working with this. This is a great package you're putting together, and I think its extensibility is the key to its usefulness.

Hi Kyle,

The plugins are in the export_plugins folder. The two example plugins are gcode_only and gcode_small. To make a plugin, make a script with the following two functions:

def getOutput( gcodeText ):
which gets the exported version of a gcode file. If this plugin writes an output than should not be printed, an empty string should be returned.

def writeOutput( filename, gcodeText ):
which writes the exported version of a gcode file.

Then toss the script into the export_plugins folder. To ensure that the script works on platforms which do not handle file capitalization properly, give the script a lower case name.

I agree that accessing all the preferences from one place is a good idea, I'm hoping to get around to it in about a month. For now, slice has most of the preferences that you would change. Export is now the end of the chain so once you've set the parameters run skeinforge by typing
>python export.py

In general, I'll be making skeinforge more extensible over the next two months.

The skeinforge toolchain now has an actual skeinforge module, which simply calls the rest of the chain.

Also Nophead's preview, his layer viewer, is now called from gifscene, an analyze plugin. I was not able to install the Python Imaging Library on my machine, which is necessary for preview to work so I can only hope that I'm calling Nophead's code correctly. If someone with the Imaging tries it out, please post the results in this thread.

Documention for both modules follows below.

Cheers,
Enrique



Introduction

Skeinforge is a tool chain to forge a gcode skein for a model.

The tool chain starts with slice, which slices the model into layers, then the layers are modified by other tools in turn like fill, comb, tower, raft, stretch, fillet & export. Each tool automatically gets the gcode from the previous tool. So if you want a sliced & filled gcode, call the fill tool and it will call slice, then it will fill and output the gcode. If you want to use all the tools, call export and it will call in turn all the other tools down the chain to produce the gcode file. Skeinforge itself simply calls export, since that is the end of the chain.

To run skeinforge, type in a shell in the same folder as skeinforge:
> python skeinforge.py

To run only fill for example, type in the skeinforge_tools folder which fill is in:
> python fill.py

If you do not want a tool after fill to modify the output, deselect the Activate checkbox for that tool. When the Activate checkbox is off, the tool will just hand off the gcode to the next tool without modifying it.

There are also tools which handle preferences for the chain, like material & polyfile.

The analyze tool calls plugins in the analyze_plugins folder, which will analyze the gcode in some way if their Activate checkbox is selected.



Getting Started

For skeinforge to run, install python 2.x on your machine, which is available 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 run gifscene you need the Python Imaging Library, which can be downloaded from:
www.pythonware.com/products/pil/

Skeinforge imports GNU Triangulated Surface (.gts) files. To turn an STL file into a GTS file, you can use the Export GNU Triangulated Surface script at:
[members.axion.net]

The Export GNU Triangulated Surface script is also in the Art of Illusion folder, which is in the same folder as skeinforge.py.

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

Then import the STL file using the STL import plugin in the import submenu of the Art of Illusion file menu. Then from the Scripts submenu in the Tools menu, choose 'Export GNU Triangulated Surface' and select the imported STL shape. Click the 'Export Selected' checkbox and click OK.

Once you've created the GTS file, you can turn it into gcode by typing in a shell in the same folder as skeinforge:
> python skeinforge.py

When the skeinforge dialog pops up, click 'Skeinforge', choose the file which you exported in 'Export GNU Triangulated Surface' and the gcode file will be saved with the suffix '_export.gcode'.



End of the Beginning

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.




Gifscene is a script to display a gif for each layer of a gcode file.

The default 'Activate Gifscene' 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 Gifscene' checkbox is on, when gifscene is run directly.

To run gifscene, in a shell in the folder which gifscene is in type:
> python gifscene.py

To run gifscene you need the Python Imaging Library, which can be downloaded from:
www.pythonware.com/products/pil/

I have not been able to install the Python Imaging Library, so I can only hope that I'm calling Nophead's code correctly. If you have the Python Imaging Library and gifscene still does not work for you, please post that in the 'How to Print Gcode from Host' thread at:
[forums.reprap.org]

Great work as always. I'll definitely have to test this new version out.

Many thanks Enrique.

Can't test at the moment as my machine is stripped for modification.

---

Regards

Ian

Thanks for the update Enrique,

I have a few issues (and also a few fixes - will post once I have the toolchain running again), but I'm stuck on one issue (see below for the trace):
It appears that there is a problem in gcodec.getModule().
You're using an absolute filename as an argument to __import__. This is, AFAIU, not according to the documentation and fails on my system (Python 2.5.1 on Mac OS X).

It might be better to import using ModuleType as described here:
[coding.derkeiler.com]

Any ideas?

----------
Exception in Tkinter callback
Traceback (most recent call last):
File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-tk/Tkinter.py", line 1403, in __call__
return self.func(*args)
File "skeinforge_tools/skeinforge_utilities/preferences.py", line 231, in displayTool
pluginModule = gcodec.getModule( self.name, self.folderName, self.moduleFilename )
File "skeinforge_tools/skeinforge_utilities/gcodec.py", line 119, in getModule
folderPluginsModule = __import__( pluginsFolderName, globals(), locals(), [ filename ], - 1 )
ImportError: No module named /Users/kintel/Downloads/reprap_python_beanshell-1/skeinforge_tools

---

~/= Marius

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

Hello Marius,

Thanks for trying out skeinforge. I'm using absolute imports in order to be able to import from the module or from a level above it. Dynamic importing was a pain to get working in python, and indeed there may be a better way.

Thanks for the stack trace, but the standard python stack trace did not give enough information for me to know what the gcodec.getModule() error was. So I've added a { try, except } in getModule to print more information. Please try the latest skeinforge and post the new more informative error if it occurs again.

Cheers,
Enrique

Edited 3 time(s). Last edit at 08/02/2008 10:31PM by Enrique.

Hi Enrique,

See below for a new trace.

~/= Marius

--
We are Elektropeople for a better living.


No module named /Users/kintel/Downloads/reprap_python_beanshell-1/skeinforge_tools
That error means; could not import a module with the filename analyze
folder name analyze
and module filename skeinforge.py
giving a plugins folder name of /Users/kintel/Downloads/reprap_python_beanshell-1/skeinforge_tools
The system path is:
['', '/Users/kintel/Downloads/reprap_python_beanshell-1', '/Library/Python/2.5/site-packages/readline-2.5.1-py2.5-macosx-10.5-i386.egg', '/Library/Python/2.5/site-packages/PyOpenGL-3.0.0b1-py2.5.egg', '/Library/Python/2.5/site-packages/Louie-1.1-py2.5.egg', '/Library/Python/2.5/site-packages/nose-0.10.1-py2.5.egg', '/Library/Python/2.5/site-packages/SQLAlchemy-0.4.2p3-py2.5.egg', '/Library/Python/2.5/site-packages/numpy-1.0.5.dev4763-py2.5-macosx-10.5-i386.egg', '/Library/Python/2.5/site-packages/matplotlib-0.98pre-py2.5-macosx-10.5-i386.egg', '/Library/Python/2.5/site-packages/scipy-0.7.0.dev3812-py2.5-macosx-10.5-i386.egg', '/Library/Python/2.5/site-packages/pymc-2.0DEV_r624-py2.5-macosx-10.3-i386.egg', '/Library/Python/2.5/site-packages/ipython-0.8.3.svn.r3001-py2.5.egg', '/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python25.zip', '/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5', '/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-darwin', '/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-mac', '/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-mac/lib-scriptpackages', '/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python', '/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-tk', '/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload', '/Library/Python/2.5/site-packages', '/Library/Python/2.5/site-packages/PIL', '/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/PyObjC']
Exception in Tkinter callback
Traceback (most recent call last):
File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-tk/Tkinter.py", line 1403, in __call__
return self.func(*args)
File "skeinforge_tools/skeinforge_utilities/preferences.py", line 235, in displayTool
pluginModule = gcodec.getModule( self.name, self.folderName, self.moduleFilename )
File "skeinforge_tools/skeinforge_utilities/gcodec.py", line 132, in getModule
return folderPluginsModule.__dict__[ filename ]
AttributeError: 'NoneType' object has no attribute '__dict__'

Hi,

Thanks for the dialog re. module loading Enrique
I have attached a patch with some suggestions for fixes/improvements.
It would be cool if you could look at it and incorporate what you think makes sense.

skeinforge.py: Support for running the toolchain from the cmd-line without the open file dialog.

raft.py: Bugfixes for uninitialized extrusionTop and operatingJump when _not_ using a raft. I also added a suggestion for starting the extruder early. This is also makes sense only when not using a raft.

preferences.py: Fixed path handling of the file open dialog. The previous version never worked on Mac OS X.

layers.py, preview.py, gifscene.py, statistic.py, vectorwrite.py: Fixed up the code so it works again. NB! This only work as long as there are comments in the gcode file.

I'm also trying to maintain a svn version of your scripts in the reprap svn repository. It would be awesome if we could all use the same repository - it would make it a whole lot easier to manage local changes.

Cheers,

---

~/= Marius

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