Skeinforge Powwow

Hi Enrique

I tracked down the correct location which is now \alterations so the help needs updating at some time.

I moved start.txt and end.txt and they work OK but there is an M107 that is appended after end.txt for some reason.

I moved my endofthebeginning.txt to \alterations but that seems to be ignored. Am I still missing a setting?

---

Regards

Ian

For that M107 I'd check your Cool prefs. There are options for turning the fan on and off.

-Tim

Tim,

The 'First Early Startup Distance' should trigger. Since it isn't for you send me your preferences and model as a zip file.

"Minimum Distance for Early Shutdown" should do that, but oozebane does not work well. There's a good chance I'll replace oozebane in several months.


Ian,

In the preface help, the following is written about the start file:

When preface is generating the code, if there is a file with the name of the "Name of Start File" setting, the default being start.txt, it will be added that to the very beginning of the gcode. If there is a file with the name of the "Name of End File" setting, the default being end.txt, it will be added to the very end. Preface 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. Preface looks for those files in the alterations folder in the .skeinforge folder in the home directory. If it doesn't find the file it then looks in the alterations folder in the skeinforge_tools folder. If it doesn't find anything there it looks in the craft_plugins folder.


Please tell me where you saw the incorrect help, so I can update or redirect it.

The endofthebeginning.txt file is no longer used. Instead, each of the lines preface adds is now optional, so you only need a start file.

Cheers,
Enrique

Hi Enrique

The endofthebeginning.txt info is in /skeinforge.html right at the beginning.

Tim

I was referring to the fact that the end.txt was not being added at the very end of the file as it should be according to documentation. I think the M107 is in the wrong place. It should be before end.txt is appended.

---

Regards

Ian

Hi Enrique

In the Preface help you have:-

If "Add M110 GCode for Compatibility with Nophead's Code" is chosen, then preface will add an M110 line for compatibility

That option is not there.

---

Regards

Ian

Hi Enrique,

I encountered a problem when running skeinforge on treasurechest.stl by Zaggo ( [www.thingiverse.com] )

$ python skeinforge.py ~/Desktop/treasurechest.stl
File /home/erik/Desktop/treasurechest.stl is being chain exported.
Carve procedure took 45 seconds.
Preface procedure took 1 seconds.
Inset procedure took 114 seconds.
Traceback (most recent call last):
File "skeinforge.py", line 331, in
main()
File "skeinforge.py", line 326, in main
writeOutput( ' '.join( sys.argv[ 1 : ] ) )
File "skeinforge.py", line 296, in writeOutput
craft.writeOutput( fileName )
File "/home/erik/RepRap/trunk/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/craft.py", line 42, in writeOutput
pluginModule.writeOutput( fileName )
File "/home/erik/RepRap/trunk/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/craft_plugins/export.py", line 137, in writeOutput
gcodeText = consecution.getChainTextFromProcedures( fileName, procedures[ : - 1 ], gcodeText )
File "/home/erik/RepRap/trunk/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/skeinforge_utilities/consecution.py", line 38, in getChainTextFromProcedures
text = craftModule.getCraftedText( fileName, text )
File "/home/erik/RepRap/trunk/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/craft_plugins/fill.py", line 392, in getCraftedText
return getCraftedTextFromText( gcodec.getTextIfEmpty( fileName, text ), fillPreferences )
File "/home/erik/RepRap/trunk/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/craft_plugins/fill.py", line 400, in getCraftedTextFromText
return FillSkein().getCraftedGcode( fillPreferences, gcodeText )
File "/home/erik/RepRap/trunk/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/craft_plugins/fill.py", line 1101, in getCraftedGcode
self.addFill( layerIndex )
File "/home/erik/RepRap/trunk/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/craft_plugins/fill.py", line 987, in addFill
paths = euclidean.getPathsFromEndpoints( endpoints, layerFillInset, aroundPixelTable, aroundWidth )
File "/home/erik/RepRap/trunk/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/skeinforge_utilities/euclidean.py", line 548, in getPathsFromEndpoints
addSegmentToPixelTable( beginningPoint, beginningEndpoint.otherEndpoint.point, pixelTable, 0, 0, width )
File "/home/erik/RepRap/trunk/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/skeinforge_utilities/euclidean.py", line 123, in addSegmentToPixelTable
gradient = deltaY / deltaX
ZeroDivisionError: float division

I could mitigate the problem by modifying euclidean.py as follows:
Index: skeinforge_tools/skeinforge_utilities/euclidean.py
===================================================================
--- skeinforge_tools/skeinforge_utilities/euclidean.py (revision 3293)
+++ skeinforge_tools/skeinforge_utilities/euclidean.py (working copy)
@@ -120,7 +120,10 @@
beginComplex = newBeginComplex
deltaX = endComplex.real - beginComplex.real
deltaY = endComplex.imag - beginComplex.imag
- gradient = deltaY / deltaX
+ if deltaX > 0.0:
+ gradient = deltaY / deltaX
+ else:
+ gradient = 0.0
xEnd = int( round( beginComplex.real ) )
yEnd = beginComplex.imag + gradient * ( xEnd - beginComplex.real )
xGap = getReverseFloatPart( beginComplex.real + 0.5 )



Anyway, while my hack allowed me to produce a G-Code file which looked fine (after visual inspection in skeinview), it is not a very programmatically sound solution... I believe that in the cases where deltaX is 0.0, deltaY is also 0.0. This probably shoudn't be if deltaX > 0.0, because negative deltaX values might be valid?
I'm using skeinforge from svn revision 3293.

Another minor issue I have is with comb. From the skeinforge documentation it says: "Comb bends the extruder travel paths around holes in the carve, 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."

I'm currently working on a Bowden extrusion system. Right now my extruder has no sharp stop and startup, but it oozes a long time after stopping extrusion and takes more time to build op pressure. While I'm still working on fixing this (which is certainly possible!), combing sound like exactly what I need to reduce string across my builds. But I never use this feature because it always puts the travel path around the object's outside, not the inside, leaving me with even more strings.
From Zaggo's video I noticed how little strings he had compared to me. So I thought it must be because of his use of the comb feature. Using skeinview, I saw that Zaggo had the travel on the inside of the object.

I've added my settings as tar.gz and .zip files so you can replicate the problem or tell me if I'm misinterpreting how to properly configure skeinforge...

Enrique, don't get me wrong, Skeinforge is the most amazing, sophisticated and fully featured piece of software that we could have wished for as a community! I'm really grateful for all the time that was put into it.

---

Regards,

Erik de Bruijn
[Ultimaker.com] - [blog.erikdebruijn.nl]

Enrique...I'm hoping to begin moving all three stages of my repstrap in the next couple of days. To that end I have been reading the gcode output of skeinforge. Great work. Wonderful program. Thanks.

My only question has to do with all the F code on each line. In standard Gcode the F is only printed if there is a change. It's modal which corresponds to global. Why it bothers me is trying to find where the speed changes I have to look at every line. If it was printed only when it was changed I could find those lines where the speed changed very quickly.

Not a complaint. Just hoping you could change Feedrate to a global variable...and add the if statement that would print it when it changes.

Arvin

Ian,

The "Add M110 GCode for Compatibility with Nophead's Code" no longer exists because raft now uses M110 for the temperature of the chamber. That is not in the html documentation because I only update the html whenever I announce a new version. You can get the most recent documentation by looking at the top of the .py file. That documentation is not always up to date, but it is more recent that the html.


Erik,

I tried filled the treasurechest and there were no major warnings, like Zaggo mentioned on thingiverse. I was not able to reproduce the divide by zero error. I speculate that either Zaggo changed the file or that I may some recent change that eliminated the warnings. Whatever the case, thanks for the bug fix, to be on the safe side I added it to euclidean along with a warning.

Since my last update, I modified comb. I don't remember exactly what I did, but I think I changed it to orbit on the inside, because I saw a mention of the clumping problem. So try the latest version at:
[members.axion.net]

Thanks for the skeinforge praise, it's good to see that instead of just complaints and feature requests


Arvin,

To get rid of the unchanging gcode, in export set the "Export Operations:" radio group to 'Gcode Small'. The output would then be a minimal gcode with only changed feed rates.

Thanks also for the skeinforge compliment, two in one day is rare

Enrique, the Orbit function works again. I now get very pretty prints without too much strings! This made my day yesterday. Now I'm out for new challenges.

[off topic] Somehow inter-layer adhesion still isn't what it should be. With very thin layers (.25) there isn't much energy in the plastic to heat up the plastic below it. I'm scared that the corner brackets that I print will not be strong enough and that if I start giving away parts that they will end up with a very fragile machine. I printed most other parts by now. (B.t.w. they are already reserved for a specific person.)[/off topic]

---

Regards,

Erik de Bruijn
[Ultimaker.com] - [blog.erikdebruijn.nl]

Hi Erik,

... then you have to raise the ambient temperature - best by enclosing and heating your build area ... it's a problem/option discussed every once

Edited 1 time(s). Last edit at 10/09/2009 08:26AM by VDX.

Hi Erik,

I don't have any specific bonding problem with 0.3mm filament and 0.24 layers of ABS at 240C, but I would use mulitiple outlines to get the wall thickness up and I don't think objects are as strong as when using larger filament. You can go up to about 260C to get better bonding before the ABS starts to go brown.

I make Darwin parts with 0.5mm filament / 0.4mm layers because the extra resolution is unecessary and takes longer.

Edited 1 time(s). Last edit at 10/09/2009 10:18AM by nophead.

---

[www.hydraraptor.blogspot.com]

I posted a challenge for improving skeinforge's raft making... (not that it's bad, just that there's room for reducing waste)
Since many are following this topic, I thought I'd post a link to the Skeinforge contributions topic here:
[dev.forums.reprap.org]
Of course the same goes for the Java host or any other software you might be using (are there other alternatives you know of?)

---

Regards,

Erik de Bruijn
[Ultimaker.com] - [blog.erikdebruijn.nl]

The latest skeinforge is attached, on my website at:
[members.axion.net]

and in subversion at:
[reprap.svn.sourceforge.net]

Thanks to Erik who wrote the 3D-to-5D-Gcode php GPL'd script at:
[objects.reprap.org]

skeinforge now has the lash.py tool to compensate for backlash.

Thanks to Tim, who is developing a square tube repstrap at:
[bothacker.com]

and his excellent bug reports, the incorrect inset bug in fill is now squashed.

The default extension for alteration gcode files is now .gcode instead of .txt. Where the file name is a preference, like in homing, you can still choose another file extension. If you have any .txt scripts, it is recommended you change their extension to .gcode and change your preference, if there is one, to .gcode.

The wording in speed has been changed, flowrate has become flow rate and feedrate is now feed rate. Also the flow rate choice has been changed from a radio group to a checkbox. So please enter your speed preferences again.

I've changed the '..Nozzle Height over Half Layer Thickness' preferences in raft to '..Nozzle Height over Layer Thickness'. So 'Base Nozzle Lift over Half Base Layer Thickness' with a default of 0.75 is now 'Base Nozzle Lift over Base Layer Thickness' with a default of 0.375. 'Interface Nozzle Lift over Half Interface Layer Thickness' with a default of 0.9 is now 'Interface Nozzle Lift over Interface Layer Thickness' with a default of 0.45. 'Operating Nozzle Lift over Half Layer Thickness' with a default of 1.0 is now 'Operating Nozzle Lift over Layer Thickness' with a default of 0.5. If you have changed the nozzle lift preferences from their defaults, please go in raft and enter your nozzle lift preferences again at half their original values.

Cheers,
Enrique

Hi

I am at last getting fairly good results from my repstrap using Skeinforge which is producing excellent g code.

My machine has a lot of inertia so I am running at very slow feed rates around 4mm/second with the extruder rate reduced accordingly. There is one thing puzzling me in the preferences. I am using a raft and the feed rate for the raft is about half the build feed rate. As I have a fixed extruder rate I would like to build the raft at the same speed as the object but I cannot find a preference that controls this speed reduction. Does anyone know what preference I need to alter?

Another solution would be to output a lower extrusion rate for the raft but as the machine is very slow anyway I would rather up the raft speed.

I am hoping to just get acceptable objects so I can use the repstrap to build a Mendel

( I have just realised that I can set Skeinforge to out put a single F word on feed rate change so I can make a fairly trivial edit to the gcode file to speed up the raft. However it would still be nice to know how to achieve this within Skeinforge)

Edited 1 time(s). Last edit at 10/20/2009 10:09AM by emt.

---

Regards

Ian

Ian, I think the parameter you are looking for is called "Base Layer Thickness over Layer Thickness" in the "Raft" dialog - this sets the speed reduction of the head feed rate for the base layer. The idea is that a slower head feedrate for a given plastic flow rate gives a bigger, thicker filament, which is better at absorbing irregularities in the build base. Setting it to 1 should speed up the first layer, but when I was using rafts, I found the thick first layer worked quite well.

Wade

Thanks Wade

It also controls the height of the base layer as I just found out.

You mentioned "when I was using rafts", I take it you don't now. What material are you feeding and how do you manage without raft?

---

Regards

Ian

AFAIK, Wade's using PLA, polylactic acid. It has a low melting point and low shrinkage, so it hardly warps even when you don't use a raft. I also have PLA but didn't get around to trying it yet... need... more... time...

---

Regards,

Erik de Bruijn
[Ultimaker.com] - [blog.erikdebruijn.nl]

Hi
I am getting very close to really good objects as I slowly understand what all the preferences do. I think the last thing I need to adjust is the position of the infill in relation to the perimeter of each layer. I seem to have a gap. Does any one know the preference that controls this gap?

---

Regards

Ian

Ian,

First make sure you are using the latest Skeinforge. Enrique fixed an inset infill bug in the last release.

If that doesn't fix it, "Infill perimeter overlap" should be what you are looking for.

-Tim

Hi Tim

Many thanks, I had not looked in inset.

---

Regards

Ian

Enrique, I have just tested the version from yesterday (20091022) and THANK YOU, THANK YOU, THANK YOU for the X/Y positional information in both Behold and SkeinView. THAAAAAAAAAANKS ...

Also, moving the jitter from comb to a separate plugin is super idea, finally I can only turn on jitter without having to mess with the comb (sometimes I really dislike comb, sometimes it is great).

All best
bogdan

hi,

thanks so much for skeinforge! unfortunately, i'm having these problems with skeinforge in that we're trying to dedicate an old Mac PPC, OS X 10.5.8, Python 2.6.3 to MakerBot duties. Has anyone gotten skeinforge to work with Mac PPC?

I've tried many things, all to no avail:
• vanilla .skeinforge folder
• moved location of skeinforge to different places
• tried with different .stl files that work fine on my Intel Mac

here's an example:


File ../dodecahedron.stl is being chain exported.
Traceback (most recent call last):
File "skeinforge.py", line 314, in
main()
File "skeinforge.py", line 309, in main
writeOutput( ' '.join( sys.argv[ 1 : ] ) )
File "skeinforge.py", line 275, in writeOutput
pluginModule.writeOutput( fileName )
File "/Users/Shared/skeinforge/skeinforge_tools/export.py", line 129, in writeOutput
gcodeText = unpause.getUnpauseChainGcode( fileName, gcodeText )
File "/Users/Shared/skeinforge/skeinforge_tools/unpause.py", line 74, in getUnpauseChainGcode
gcodeText = fillet.getFilletChainGcode( fileName, gcodeText )
File "/Users/Shared/skeinforge/skeinforge_tools/fillet.py", line 240, in getFilletChainGcode
gcodeText = oozebane.getOozebaneChainGcode( fileName, gcodeText )
File "/Users/Shared/skeinforge/skeinforge_tools/oozebane.py", line 112, in getOozebaneChainGcode
gcodeText = wipe.getWipeChainGcode( fileName, gcodeText )
File "/Users/Shared/skeinforge/skeinforge_tools/wipe.py", line 100, in getWipeChainGcode
gcodeText = hop.getHopChainGcode( fileName, gcodeText )
File "/Users/Shared/skeinforge/skeinforge_tools/hop.py", line 87, in getHopChainGcode
gcodeText = stretch.getStretchChainGcode( fileName, gcodeText )
File "/Users/Shared/skeinforge/skeinforge_tools/stretch.py", line 102, in getStretchChainGcode
gcodeText = cool.getCoolChainGcode( fileName, gcodeText )
File "/Users/Shared/skeinforge/skeinforge_tools/cool.py", line 103, in getCoolChainGcode
gcodeText = clip.getClipChainGcode( fileName, gcodeText )
File "/Users/Shared/skeinforge/skeinforge_tools/clip.py", line 91, in getClipChainGcode
gcodeText = comb.getCombChainGcode( fileName, gcodeText )
File "/Users/Shared/skeinforge/skeinforge_tools/comb.py", line 97, in getCombChainGcode
gcodeText = tower.getTowerChainGcode( fileName, gcodeText )
File "/Users/Shared/skeinforge/skeinforge_tools/tower.py", line 101, in getTowerChainGcode
gcodeText = raft.getRaftChainGcode( fileName, gcodeText )
File "/Users/Shared/skeinforge/skeinforge_tools/raft.py", line 207, in getRaftChainGcode
gcodeText = speed.getSpeedChainGcode( fileName, gcodeText )
File "/Users/Shared/skeinforge/skeinforge_tools/speed.py", line 111, in getSpeedChainGcode
gcodeText = multiply.getMultiplyChainGcode( fileName, gcodeText )
File "/Users/Shared/skeinforge/skeinforge_tools/multiply.py", line 94, in getMultiplyChainGcode
gcodeText = fill.getFillChainGcode( fileName, gcodeText )
File "/Users/Shared/skeinforge/skeinforge_tools/fill.py", line 385, in getFillChainGcode
gcodeText = inset.getInsetChainGcode( fileName, gcodeText )
File "/Users/Shared/skeinforge/skeinforge_tools/inset.py", line 154, in getInsetChainGcode
gcodeText = carve.getCarveGcode( fileName )
File "/Users/Shared/skeinforge/skeinforge_tools/carve.py", line 101, in getCarveGcode
skein.parseCarving( carvePreferences, carving, fileName )
File "/Users/Shared/skeinforge/skeinforge_tools/carve.py", line 373, in parseCarving
rotatedBoundaryLayers = carving.getCarveRotatedBoundaryLayers()
File "/Users/Shared/skeinforge/skeinforge_tools/skeinforge_utilities/triangle_mesh.py", line 583, in getCarveRotatedBoundaryLayers
z = self.getZAddExtruderPaths( z )
File "/Users/Shared/skeinforge/skeinforge_tools/skeinforge_utilities/triangle_mesh.py", line 637, in getZAddExtruderPaths
rotatedBoundaryLayer.loops = self.getLoopsFromMesh( zPlusAround )
File "/Users/Shared/skeinforge/skeinforge_tools/skeinforge_utilities/triangle_mesh.py", line 610, in getLoopsFromMesh
simplifiedLoops.append( euclidean.getSimplifiedLoop( originalLoop, self.importRadius ) )
File "/Users/Shared/skeinforge/skeinforge_tools/skeinforge_utilities/euclidean.py", line 678, in getSimplifiedLoop
return getAwayPoints( loopComplex, radius )
File "/Users/Shared/skeinforge/skeinforge_tools/skeinforge_utilities/euclidean.py", line 223, in getAwayPoints
if not isCloseXYPlane( overlapDistance, pixelTable, pointComplex, x, y ):
File "/Users/Shared/skeinforge/skeinforge_tools/skeinforge_utilities/euclidean.py", line 788, in isCloseXYPlane
squareValues = getSquareValues( pixelTable, x, y )
File "/Users/Shared/skeinforge/skeinforge_tools/skeinforge_utilities/euclidean.py", line 699, in getSquareValues
for xStep in xrange( x - 1, x + 2 ):
OverflowError: long int too large to convert to int

When I try to convert one of the Mendel .stl files to gcode with Skeinforge some of the orbit movements are shifted in the -x direction. Since I have disabled the raft, this means the print head tries to move beyond the home position, which resets the coordinate system and messes up everything else. I've observed the same behavior with the raft on, but because I don't hit the home position it isn't as catastrophic.

I've attached my Skeinforge preferences, the .stl file I am using as input ant the gcode file I get back. Searching through the gcode file for "X-4" will find the first major occurrence of the problem about half way through the file.

The following is the console output, which seems normal to me.

~/reprap_python_beanshell$ ./skeinforge.py ~/Desktop/y-bar-clamp_10off.stl
File /home/mccoyn/Desktop/y-bar-clamp_10off.stl is being chain exported.
Carve procedure took 5 seconds.
Preface procedure took 0 seconds.
Inset procedure took 13 seconds.
Fill procedure took 25 seconds.
Speed procedure took 2 seconds.
Comb procedure took 10 seconds.
Clip procedure took 2 seconds.
Cool procedure took 5 seconds.
Stretch procedure took 3 seconds.
Home procedure took 3 seconds.
Lash procedure took 2 seconds.
Fillet procedure took 5 seconds.
The lower left corner of the behold window is at 0.089, 0.2
The upper right corner of the behold window is at 23.908, 23.801
The lower left corner of the skeinview window is at 0.089, 0.2
The upper right corner of the skeinview window is at 23.908, 23.801


Statistics are being generated for the file /home/mccoyn/Desktop/y-bar-clamp_10off_export.gcode
On the X axis, the extrusion starts at 0 mm and ends at 24 mm, for a width of 24 mm.
On the Y axis, the extrusion starts at 0 mm and ends at 24 mm, for a depth of 24 mm.
On the Z axis, the extrusion starts at 0 mm and ends at 14 mm, for a height of 13 mm.

The average feedRate is 52.4 mm/s, (3141.1 mm/min).
The cross section area is 0.402 mm2.
The extrusion diameter is 0.715 mm.
The extruder speed is 3000.0
The extruder was extruding 72.2 percent of the time.
The extruder was toggled 500 times.
The layer thickness is 0.65 mm.
The operating flow rate is 24.1 mm3/s.
The perimeter extrusion fill density ratio is 1.06
The perimeter width is 0.585 mm.

The following procedures have been performed on the skein:
carve
preface
inset
fill
speed
comb
clip
cool
stretch
home
lash
fillet

The text has 16993 lines and a size of 556.0 KB.
The total build time is 321 s.
The total distance extruded is 12139.7 mm.
The total distance traveled is 16813.5 mm.
The version is 2009-10-14
The volume extruded is 4.87 cc.

The exported file is saved as /home/mccoyn/Desktop/y-bar-clamp_10off_export.gcode
It took 87 seconds to export the file.

Hey Enrique,

Thanks a bunch for all the super cool new options you embedded into Skeinforge but I have to report another bug.

I get this error trying to print the attached stl. STL parses ok from what I can c, and it is fixed in netfabb to be fully mainfold so no reason for it not to print properly.

I attached also the used profile (but tried few other profiles also with exactly the same results). The used versions are the one from 09-10-22 and 09-10-31 (latest one from your site).


When I convert the object to GTS (using AOI) I get the same error.

[arhimed@gedora10 Skeinforge]$ ./skeinforge.py 
Skeinforge preferences have been saved.
File /home/arhimed/PRINT/MENDEL/_fixed_x-180-z-bearing-plate_2off (fixed).stl is being chain exported.
Carve procedure took 3 seconds.
Preface procedure took 0 seconds.
Inset procedure took 20 seconds.
Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib64/python2.5/lib-tk/Tkinter.py", line 1403, in __call__
    return self.func(*args)
  File "/home/arhimed/Dev/Skeinforge/skeinforge_tools/skeinforge_utilities/preferences.py", line 1529, in execute
    self.repository.execute()
  File "./skeinforge.py", line 290, in execute
    writeOutput( fileName )
  File "./skeinforge.py", line 267, in writeOutput
    craft.writeOutput( fileName )
  File "/home/arhimed/Dev/Skeinforge/skeinforge_tools/craft.py", line 69, in writeOutput
    pluginModule.writeOutput( fileName )
  File "/home/arhimed/Dev/Skeinforge/skeinforge_tools/craft_plugins/export.py", line 136, in writeOutput
    gcodeText = consecution.getChainTextFromProcedures( fileName, procedures[ : - 1 ], gcodeText )
  File "/home/arhimed/Dev/Skeinforge/skeinforge_tools/skeinforge_utilities/consecution.py", line 39, in getChainTextFromProcedures
    text = craftModule.getCraftedText( fileName, text )
  File "/home/arhimed/Dev/Skeinforge/skeinforge_tools/craft_plugins/fill.py", line 407, in getCraftedText
    return getCraftedTextFromText( gcodec.getTextIfEmpty( fileName, text ), fillRepository )
  File "/home/arhimed/Dev/Skeinforge/skeinforge_tools/craft_plugins/fill.py", line 417, in getCraftedTextFromText
    return FillSkein().getCraftedGcode( fillRepository, gcodeText )
  File "/home/arhimed/Dev/Skeinforge/skeinforge_tools/craft_plugins/fill.py", line 1107, in getCraftedGcode
    self.addFill( layerIndex )
  File "/home/arhimed/Dev/Skeinforge/skeinforge_tools/craft_plugins/fill.py", line 981, in addFill
    self.addGrid( arounds, fillLoops, gridPointInsetX, layerIndex, paths, aroundPixelTable, aroundWidth, reverseZRotationAngle, surroundingCarves )
  File "/home/arhimed/Dev/Skeinforge/skeinforge_tools/craft_plugins/fill.py", line 999, in addGrid
    gridPoints = self.getGridPoints( fillLoops, reverseZRotationAngle )
  File "/home/arhimed/Dev/Skeinforge/skeinforge_tools/craft_plugins/fill.py", line 1160, in getGridPoints
    self.addGridLinePoints( begin, end, gridPoints, gridRotationAngle, offset, y )
  File "/home/arhimed/Dev/Skeinforge/skeinforge_tools/craft_plugins/fill.py", line 1033, in addGridLinePoints
    if self.isPointInsideLineSegments( gridPointComplex ):
  File "/home/arhimed/Dev/Skeinforge/skeinforge_tools/craft_plugins/fill.py", line 1199, in isPointInsideLineSegments
    lineSegments = self.horizontalSegmentLists[ fillLine ]
IndexError: list index out of range
[arhimed@gedora10 Skeinforge]$ rpm -qa | grep -i tkinte
tkinter-2.5.2-1.fc10.x86_64
[arhimed@gedora10 Skeinforge]$ python --version
Python 2.5.2
[arhimed@gedora10 Skeinforge]$

Hope this is enough data for debugging, if there's anything else I might send you please do not hesitate to ask.

br,
Bogdan

I'm having problems on OSX 10.5.8 with a build I downloaded earlier today. Not only does it crash on most of my very simple models, it hangs with a blank screen on one of the supplied models (see below).

Any suggestions on where to start looking? I'm going to assume it's a problem with the default python install.

$ ./skeinforge.py models/Screw\ Holder\ Bottom.stl
File models/Screw Holder Bottom.stl is being chain exported.
Carve procedure took 2 seconds.
Preface procedure took 0 seconds.
Inset procedure took 4 seconds.
Fill procedure took 5 seconds.
Speed procedure took 1 seconds.
Raft procedure took 1 seconds.
Jitter procedure took 1 seconds.
Comb procedure took 4 seconds.
Clip procedure took 0 seconds.
Cool procedure took 0 seconds.
Home procedure took 1 seconds.
Fillet procedure took 2 seconds.
The lower left corner of the behold window is at -3.156, -4.36
The upper right corner of the behold window is at 63.156, 44.6
[it hung here for an hour or two and I used ^C to kill it.]

Edited 1 time(s). Last edit at 11/03/2009 04:44PM by jet.

The bound checking skeinforge is attached and at:
[members.axion.net]

The unabridged skeinforge now goes over the 613K limit of the forum software. Where is a good place that I can store larger files?

I know about subversion, but it is much quicker for me to upload a file then switch over to windows, use subversion, then switch back to Linux for development; necessary because I am not able to install subversion on my Linux partition.


Bogdan,

The problem is caused because your 'Infill Perimeter Overlap' setting is too high. Try keeping it below 0.7. I've changed the relevant inset documentation to:

"The 'Infill Perimeter Overlap' ratio is the amount the infill overlaps the perimeter over the extrusion width. The higher the value the more the infill will overlap the perimeter, and the thicker join between the infill and the perimeter. If the value is too high, the join will be so thick that the nozzle will run plow through the join below making a mess, also when it is above 0.7 fill will not be able to create infill correctly, the default is 0.15."

I've added an out of bounds array check in fill, so that even if the 'Infill Perimeter Overlap' is very high it won't crash, but it would still make a bad fill pattern and fill will complain. It would be nice if somehow a good fill pattern could be made even with a high 'Infill Perimeter Overlap' ratio, but I don't know how to do that and I have other stuff to do.

If you want the infill to overlap a lot, the best way would be to use stretch to stretch the infill. You could set the 'Path Stretch over Perimeter Width" to a value of say 0.5, set the 'Infill Perimeter Overlap' to 0.5 and get a similar effect as your 'Infill Perimeter Overlap' of 1.0 without fill complaining.


jet,

I tried the 'Screw Holder Bottom.stl' model and it worked. Please post you settings as a zipped file. To be on the safe side, also post or email your version of skeinforge. Without that I can not reproduce your bug.


Cheers,
e

Edited 1 time(s). Last edit at 11/03/2009 11:41PM by Enrique.

Enrique, you are a wizard, thanks a bunch.

The high infill per overlap I use for PP as it springs a lot so with very high overlap it actually come to a right place

Check the pictures here: [www.bitsfrombytes.com]

With ABS the original 0.1-0.2 is ok

thanks again
bogdan

Hi Enrique,

... i see you've added an endmill and laser too

What are your plans about adding hatch-lines for the outer area for dismanteling the objects out of the bulk after laminating?

Viktor

Enrique,

Dear wizard, I love the new look and the new organization but I have to report a bug, the analyze plugin's miss the exit button (used to be in the lower right corner) and the 3d one cannot rotate around the axes?

all best
bogdan

E.: I'm tried again with the version you just posted, 2009-11-03 and had the same problem. Attached are my settings, I'm using "rapman ABS".

thx,
--jet