How to print Gcode from Host

Hi Enrique

Today I tried my first job. I don't know if I have something wrong with my preferences but the code generated seems to go round and round the perimeter of the job and the raft many many times.

The sequence is first it moves round the perimeter of the job many times without extruder. The extruder comes on and builds the first layer of the raft. Then it goes many times round the raft perimeter with the extruder on.

I attach the STL file and my settings files. Any advice would be appreciated.

---

Regards

Ian

Hi Ian,

Round and round she goes is actually a feature, not a bug. The idea is to circle round before going to another layer with a different temperature to give the extruder time to reach the new temperature. The time it goes around for is set in the raft dialog. The orbiting time preferences are:
Temperature Change Time of Raft (seconds)
Temperature Change Time of Layer Outline (seconds)
Temperature Change Time of Layer Within (seconds)
Temperature Change Time of Next Layers (seconds)

The temperature is also set in the raft dialog. The temperature preferences are:
Temperature of Raft (Celcius)
Temperature of Shape Layer Outline (Celcius)
Temperature of Shape Layer Within (Celcius)
Temperature of Shape Next Layers (Celcius)

The temperature defaults are for ABS. If you want to change the material, first open material and change the material there, then reopen raft and adjust the temperatures from the defaults for that material if necessary.

There is no way at present for skeinforge to change the file extension, I'll add an option in export to do that, probably within a week.

Cheers,
Enrique

Hi Enrique.

That explains the round & round. It may not be required. On my machine I had to create the M functions and I use feed back. When a M104 is actioned the G code programme waits for a temperature achieved signal back from the interface before it moves onto the next line of programme. I don't know if Nophead and Brendan have done the same thing. If they have the round and round just adds delays. Also there is a g code delay which could be implemented G4 P? where P is normally seconds but this does vary. Could a flag be added somewhere to switch of all the delay movements for those machines where they are not needed.

Thanks again for all your work on this. Although the part I made is not very pretty the potential is very clear.

---

Regards

Ian

Quote

I don't know if Nophead and Brendan have done the same thing.

While waiting for the nozzle to change temperature my extruder oozes (the plastic falls due to gravity if you leave it hot long enough). That means I have to run it for a few seconds to refill the barrel. After that if has a few cm of filament dangling, so I wipe it off before moving to the object.

My build procedure is this:

Warm up to raft temperature and wait 1 minute for PTFE nozzle to expand and filament to melt above the PTFE / brass junction.

Wipe the nozzle.

Go to near the first raft position, run the extruder for about 1s to make a blob and then do 5mm of lead-in to the raft. This is needed to get the first line of the raft to stick. The reason is that by the time the head has moved from the wipe station to the raft position a few mm of filament will have oozed and be too cold to stick. It curls upwards and prevents the rest of the first line sticking.

I do the first layer of the raft: sparse zig-zag of 1mm filament at 4mm/s, height 0.7mm.

I set the temperature for subsequent raft layers, but don't wait for it to get there (it would ooze and need a wipe if I did).
Do the next two layers of the raft, a close, but not solid, zigzag of 0.5mm filament at 16mm/s.

I then place the fan over the raft and cool for 2 minutes to get a reliable raft temperature. I turn the temperature down while the fan is running so as not to stress the heater, which would stress the PTFE.

I then warm up to the first layer temperature (at the home position) and wait for 1m minute again and then wipe the nozzle again.

I return to the raft corner and draw a rectangle round the object, 1mm from the edge of the raft (the raft overlaps the object by a material dependent amount). This ensures the filament is flowing properly and no cold ooze to prevent sticking.

I then do the first layer of the object at half speed and a little lower (0.15mm) to make it stick. 0.05mm makes all the difference.

I then increase the temperature for the other layers, but do not wait for it to get there.

I then extrude the rest of the object at full speed with no pauses between layers. I do slow down on layers with not much on them to avoid overheating. On low temperature plastics I run the fan after the first layer.

Ideally I would always wait for temperature changes to take effect, but I have no clean way of starting a new layer after a pause. I would have to wipe the nozzle, but by the time I move back to the object it would have oozed. HydraRaptor only moves at 32mm/s. I am hoping to solve these problems by moving 5 times faster with my turbo charged Darwin. I also plan to revese the extruder motor to stop the ooze. That will give a pause before it starts again, but with the shaft encoder that should be repeatable.

---

[www.hydraraptor.blogspot.com]

Awesome description Nophead. This is the kind of thing that we should copy to the Builders Wiki. I've often gone searching through your blog trying to figure out how you did something. Mind if I cut and paste it in?

Also, Enrique, I think I found another bug in Skeinforge. I'm getting my 2nd full layers on the base and a few on the top side of my part where the center of the holes are filled in, but not any of the rest of the part. It seems to be dependant on extrusion width - a width of 0.7 (which is what my extruder extrudes at) causes this, but setting it to 0.6 makes it work correctly. Check out the pics and attached Gcode and stl.

I did manage to get a useful part out of it though - my Extruder is now running with a modified printed part! Woo!

Here's the pics:

old-motor-holder_export_04.svg

old-motor-holder_export_05.svg

Ok, I can't get the svg files to display properly, but hopefully you guys get the idea.

Also, Enrique, are you in Vancouver? I've got a friend out there who might be interested in a Reprap.

Wade

Edited 4 time(s). Last edit at 10/08/2008 05:05PM by Wade.

Wade,
Yes go ahead and put it in. I will try to expand it later with more detail, pictures and a video.

---

[www.hydraraptor.blogspot.com]

hi avreyone

how do i make a counter in g codes fanuc

If you have a complete GCode interpreter, you can do counter-like constructs, for example:

[www.woodweb.com]

but I doubt very much that the Arduino SW has a full GCode interpreter. Instead, you will have to repeat the same GCode sequences with offset coordinates.

Hi Enrique,

I'm experiencing some problems with the latest Skeinforge (using the latest revision from svn). Basically, Skeinforge crashes with a ZeroDivisionError.
This happens with a lot of models, and the problems started with the latest update. The revision from ca. 3 weeks ago works well.

To reproduce, use the default values for all preferences except these:
slice_shape: Extrusion Diameter (mm): 0.5
tower: Maximum Tower Height (layers): 10

..then slice the attached minimal STL file (exported from AOI). The gts export gives the exact same problem.


~/= Marius

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

------------------------------
Python backtrace:

File pyrasticks-test-10210019/pyrasticks-test.gts is being chain exported.
The extrusion fill density ratio is 0.853
Traceback (most recent call last):
File "skeinforge.py", line 291, in
main()
File "skeinforge.py", line 286, in main
writeOutput( ' '.join( sys.argv[ 1 : ] ) )
File "skeinforge.py", line 250, in writeOutput
pluginModule.writeOutput( filename )
File "/Users/kintel/code/metalab/checkout/reprap/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/export.py", line 111, in writeOutput
gcodeText = fillet.getFilletChainGcode( filename, gcodeText )
File "/Users/kintel/code/metalab/checkout/reprap/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/fillet.py", line 228, in getFilletChainGcode
gcodeText = oozebane.getOozebaneChainGcode( filename, gcodeText )
File "/Users/kintel/code/metalab/checkout/reprap/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/oozebane.py", line 103, in getOozebaneChainGcode
gcodeText = nozzle_wipe.getNozzleWipeChainGcode( filename, gcodeText )
File "/Users/kintel/code/metalab/checkout/reprap/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/nozzle_wipe.py", line 99, in getNozzleWipeChainGcode
gcodeText = hop.getHopChainGcode( filename, gcodeText )
File "/Users/kintel/code/metalab/checkout/reprap/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/hop.py", line 87, in getHopChainGcode
gcodeText = stretch.getStretchChainGcode( filename, gcodeText )
File "/Users/kintel/code/metalab/checkout/reprap/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/stretch.py", line 102, in getStretchChainGcode
gcodeText = cool.getCoolChainGcode( filename, gcodeText )
File "/Users/kintel/code/metalab/checkout/reprap/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/cool.py", line 103, in getCoolChainGcode
gcodeText = raft.getRaftChainGcode( filename, gcodeText )
File "/Users/kintel/code/metalab/checkout/reprap/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/raft.py", line 141, in getRaftChainGcode
gcodeText = clip.getClipChainGcode( filename, gcodeText )
File "/Users/kintel/code/metalab/checkout/reprap/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/clip.py", line 92, in getClipChainGcode
gcodeText = comb.getCombChainGcode( filename, gcodeText )
File "/Users/kintel/code/metalab/checkout/reprap/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/comb.py", line 95, in getCombChainGcode
return getCombGcode( gcodeText, combPreferences )
File "/Users/kintel/code/metalab/checkout/reprap/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/comb.py", line 109, in getCombGcode
skein.parseGcode( combPreferences, gcodeText )
File "/Users/kintel/code/metalab/checkout/reprap/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/comb.py", line 513, in parseGcode
self.parseAddTravel( line )
File "/Users/kintel/code/metalab/checkout/reprap/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/comb.py", line 487, in parseAddTravel
self.addIfTravel( splitLine )
File "/Users/kintel/code/metalab/checkout/reprap/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/comb.py", line 213, in addIfTravel
self.insertPathsAroundBetween( location )
File "/Users/kintel/code/metalab/checkout/reprap/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/comb.py", line 394, in insertPathsAroundBetween
self.addPathBeforeEnd( outerPerimeter )
File "/Users/kintel/code/metalab/checkout/reprap/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/comb.py", line 229, in addPathBeforeEnd
centers = intercircle.getCentersFromCircleNodes( circleNodes )
File "/Users/kintel/code/metalab/checkout/reprap/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/skeinforge_utilities/intercircle.py", line 110, in getCentersFromCircleNodes
circleIntersections = getCircleIntersectionsFromCircleNodes( circleNodes )
File "/Users/kintel/code/metalab/checkout/reprap/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/skeinforge_utilities/intercircle.py", line 156, in getCircleIntersectionsFromCircleNodes
if not circleIntersectionForward.isWithinCircles( circleNodes ):
File "/Users/kintel/code/metalab/checkout/reprap/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/skeinforge_utilities/intercircle.py", line 430, in isWithinCircles
absolutePosition = self.getAbsolutePosition()
File "/Users/kintel/code/metalab/checkout/reprap/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/skeinforge_utilities/intercircle.py", line 397, in getAbsolutePosition
return self.getPositionRelativeToBehind().plus( self.circleNodeBehind.circle )
File "/Users/kintel/code/metalab/checkout/reprap/reprap/miscellaneous/python-beanshell-scripts/skeinforge_tools/skeinforge_utilities/intercircle.py", line 425, in getPositionRelativeToBehind
rotatedClockwiseQuarter.scale( halfChordWidth / rotatedClockwiseQuarter.length() )
ZeroDivisionError: float division

A bunch of bugs in comb and fill have been fixed, the update is attached and in subversion. A bit of stuff has been added to comb and fillet, and the updated documentation for those is below. Included in the comb stuff is different speed in corners, as suggested by John Gilmore in the acceleration post at:
[forums.reprap.org]

Dave and xsainnz are working on a slice file format at:
[sourceforge.net]

A long while after that format is stable, we'll be able to slice the Solidworks boundary representation or the Art of Illusion constructive solid geometry shapes directly, so getting around the stl / triangle mesh problems. This will only work on the original shapes, once they're turned into triangle meshes the correct shape information is lost. So, if you aren't already, please keep a copy of your designs in the original format.


Ian,

In the export tool, the 'File Extension' field has been added which determines the file extension added to the name of the output file, the default is gcode.

Cheers,
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. The 'Minimum Perimeter Departure Distance over Extrusion Width' is the ratio of the minimum distance that the extruder will travel and loop before leaving an outer perimeter. A high value means the extruder will loop many times before leaving, so that the ooze will finish within the perimeter, a low value means the extruder will not loop and a stringer might be created from the outer perimeter.


Fillet rounds the corners slightly in a variety of ways. This is to reduce corner blobbing and sudden extruder acceleration. The 'Arc Point' method fillets the corners with an arc using the gcode point form. The 'Arc Radius' method fillets with an arc using the gcode radius form. The 'Arc Segment' method fillets corners with an arc composed of several segments. The 'Bevel' method bevels each corner. The default radio button choice is 'Bevel'.

The 'Corner Feedrate over Operating Feedrate' is the ratio of the feedrate in corners over the operating feedrate. With a high value the extruder will move quickly in corners, accelerating quickly and leaving a thin extrusion. With a low value, the extruder will move slowly in corners, accelerating gently and leaving a thick extrusion. The default value is 1.0. The 'Fillet Radius over Extrusion Width' ratio determines how much wide the fillet will be, the default is 0.35. The 'Reversal Slowdown over Extrusion Width' ratio determines how far before a path reversal the extruder will slow down. Some tools, like nozzle wipe, double back the path of the extruder and this option will add a slowdown point in that path so there won't be a sudden jerk at the end of the path. The default value is 0.5 and if the value is less than 0.1 a slowdown will not be added.

Edited 1 time(s). Last edit at 10/22/2008 04:22AM by Enrique.

I guess you're aware of this, so just FYI: This update didn't appear to resolve the ZeroDivisionError I reported a few days ago.

Another thing btw.: Eventually, we would like to spend some time getting dirty with the skeinforge source code to be able to fix stuff and experiment with our own ideas. Do you have any suggested starting points for this?

Also, whenever we get this far, it would make sense for us to contribute any fixes or cleanups we do. Is it kosher to just commit stuff to svn, or would this break your workflow? (I'm asking since I have a feeling, due to your empty commit messages that you're merely dumping each release onto svn, not really using it as a daily tool).

Cheers,

---

~/= Marius

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

Hi Marcus,

I could not reproduce the zero division bug, so please email me your zipped preferences.

The best place to start working with the skeinforge code is at the periphery. The import plugins will be changed one the slice format is made, so the best place in the periphery would be in the analyze plugins, like skeinview.

Indeed, I just use dump stuff to svn, so please email me your updates.

Cheers,
Enrique

Enrique,

My skeinforge prefs are attached.

I'm running this on the built-in Python 2.5.1 on Mac OS X 10.5.

---

~/= Marius

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

Hi Marcus,

Thanks for sending the zipped preferences. The updated skeinforge is attached and in subversion.

Cheers,
Enrique

Hi Enrique,

Thanks a lot for your super-quick fix!
It all looks fine again here now : )

---

~/= Marius

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

Where can I find a compatible set of software for arduino and skeinforge? I have the GCode_Interpreter in reprap-arduino-firmware-1.3 working to extrude a test rectangle. When I create gcode from skeinforge it includes M108 to set the flowrate which is not in the arduino gcode interpreter.

The Arduino GCode interpreter does indeed support the M108 command.
I've always been using the latest version from Subversion, so it might be that you've encountered a bug in the current released version.

Zach has mentioned that he'll try to get out a new release soon. In the meanwhile, you could try the bleeding edge

---

~/= Marius

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

Hi again,

We've been playing around a bit with towering and combing and have found some dubious behavior with these settings:

Look at the attached file. It describes two circular towers with single-filament-width walls.

We observe the following behavior which we don't quite understand:
1) When only combing is used, the extruder makes two entire round around each layer, both on the inside and the outside of the object.
2) When both combing and towering is turned on, the extruder is moved down, through the recently build layers, to the _first_ tower layer, thus destroying the towering layers just built.

Both of these can easily be observed in Skeinview.

The current workaround is to never use tower and comb at the same time, and be very careful about when combing is ever turned on (e.g. never use it for hollow objects).

---

~/= Marius

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

Hi Marcus,

Thanks for the bug report, the updated skeinforge is in subversion and attached to this post.

Cheers,
E

Here's another small bug report regarding the latest Skeinforge - this one smacked my Y axis into the side of my machine. No damage, but I guess I better get that Sanguino up and running and build some max opto endstops.

I have a small end.txt file to lift the head and shut down the heater; otherwise the head melts a hole into the just built object.

This wasn't happening a few days ago, but now the end.txt is getting included, but changed. Since I included a G91 to do a relative 10 mm move, the new coordinates do a relative X and Y move that I don't want.

Here's the relevant bits:
end.txt:
G91
G1 Z10
M104 S10

gets converted to this at the end of the gcode:
G1 X32.9 Y86.64 Z21.18 F960.0
M103
M103
M104 S0
G91
G1 X32.9 Y86.64 Z11.76 F960.0
M104 S10

I included the previous G1 command so you can see where it's getting those XYZ values.

Which brinds up another problem I'm having - anyone have any luck Skeinforging the opto endstop? All I get is a tiny little raft, no part at all, and no errors from Skeinforge.

Attached are the stl's for the diagonal tie and the opto bracket, as well as my Skeinforge prefs, and the output Gcodes.

Thanks again for this software Enrique!

Wade

Hi Wade,
I made opto flags with skeinforge. They are quite thin so I think if your filament width is too big bits don't come out.

---

[www.hydraraptor.blogspot.com]

Hi Wade,

Raft was changing the end.txt part, I modified raft so it stops rafting at the end of the extrusion section.

The opto endstop file was not being sliced because the incorrect solidworks binary file starts with:
"solid binary STL from Solid Edge, Unigraphics Solutions Inc."

according to the wikipedia stl format article:
[en.wikipedia.org]

binary stl files should start with anything but "solid". I heard the solidworks stl generator was bad, this confirms it In stl.py in the import plugins folder I added a check for that line, and to parse it as binary regardless.

The updated skeinforge is attached, the subversion version will be updated in the next skeinforge dump, which will probably be in very roughly a week.

Cheers,
E

Enrique,

Playing around a bit with oozebane, I think I have a suggestion for improvement:
Today, when the extruder is turned off for a very short time, e.g. when moving up to the next layer, the oozebane kicks in. The value of oozebane here is minimal, and only useful if the parameters are tuned perfectly.

My suggestion would be to implement a minimum time the extruder has to be off before oozebane kicks in.

I might of course have misunderstood something..

---

~/= Marius

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

Attached and in subversion is the updated skeinforge with lots of bug fixes.

Infill density has been renamed "Infill Solidity" so please set your infill solidity preference in fill, because the infill density preference is now lost.

The "Interior Infill Density over Exterior Density" preference has been added. It is the ratio of the infill density of the interior over the infill density of the exterior surfaces, the default is 0.9. The exterior should have a high infill density, so that the surface will be strong and watertight. With the interior infill density a bit lower than the exterior, the plastic will not fill up higher than the extruder nozzle. If the interior density is too high that could happen, as Nophead described in the Hydraraptor "Bearing Fruit" post at:
[hydraraptor.blogspot.com]

There is now the grid option, to create a square / octagonal honeycomb like grid. The time required to generate the grid increases with the fourth power of the "Infill Solidity", so when choosing the grid option, set the infill solidity to 0.2 or less so that skeinforge doesn't take a ludicrous amount of time to generate the infill.

The documentation for fill follows below.

Cheers,
E



The diaphragm is a solid group of layers, at regular intervals. It can be used with a sparse infill to give the object watertight, horizontal compartments and/or a higher shear strength. The "Diaphragm Period" is the number of layers between diaphrams. The "Diaphragm Thickness" is the number of layers the diaphram is composed of. The default diaphragm is zero, because the diaphragm feature is rarely
used.

The "Extra Shells on Alternating Solid Layers" preference is the number of extra shells, which are interior perimeter loops, on the alternating solid layers. The "Extra Shells on Base" preference is the number of extra shells on the bottom, base layer and every even solid layer after that. Setting this to a different value than the "Extra Shells on Alternating Solid Layers" means the infill pattern will alternate, creating a strong interleaved bond even if the perimeter loop shrinks. The "Extra Shells on Sparse Layer" preference is the number of extra shells on the sparse layers. The solid layers are those at the top & bottom, and wherever the object has a plateau or overhang, the sparse layers are the layers in between. Adding extra shells makes the object stronger & heavier.

The "Grid Extra Overlap" preference is the amount of extra overlap added when extruding the grid to compensate for the fact that when the first thread going through a grid point is extruded, since there is nothing there yet for it to connect to it will shrink extra. The "Grid Square Half Width over Extrusion Width" preference is the ratio of the amount the grid square is increased in each direction over the extrusion width, the default is zero. With a value of one or so the grid pattern will have large squares to go with the octogons. The "Infill Pattern" can be set to "Grid" or "Line". The grid option makes a funky octogon square honeycomb like pattern which gives the object extra strength. However, the grid pattern means extra turns for the extruder and therefore extra wear & tear, also it takes longer to generate, so the default is line. The time required to generate the grid increases with the fourth power of the "Infill Solidity", so when choosing the grid option, set the infill solidity to 0.2 or less so that skeinforge doesn't take a ludicrous amount of time to generate the infill.

The "Infill Begin Rotation" preference is the amount the infill direction of the base and every second layer thereafter is rotated. The default value of forty five degrees gives a diagonal infill. The "Infill Odd Layer Extra Rotation" preference is the extra amount the infill direction of the odd layers is rotated compared to the base layer. With the default value of ninety degrees the odd layer infill will be perpendicular to the base layer. The "Infill Begin Rotation Repeat" preference is the number of layers that the infill begin rotation will repeat. With the default of one, the object will have alternating cross hatching. With a value higher than one, the infill will go in one direction more often,
giving the object more strength in one direction and less in the other, this is useful for beams and cantilevers.

The most important preference in fill is the "Infill Solidity". A value of one means the infill lines will be right beside each other, resulting in a solid, strong, heavy shape which takes a long time to extrude. A low value means the infill will be sparse, the interior will be mosty empty space, the object will be weak, light and quick to build. The default is 0.2.

The "Interior Infill Density over Exterior Density" preference is the ratio of the infill density of the interior over the infill density of the exterior surfaces, the default is 0.9. The exterior should have a high infill density, so that the surface will be strong and watertight. With the interior infill density a bit lower than the exterior, the plastic will not fill up higher than the extruder nozzle. If the interior density is too high that could happen, as Nophead described in the Hydraraptor "Bearing Fruit" post at:
[hydraraptor.blogspot.com]

The "Solid Surface Thickness" preference is the number of solid layers that are at the bottom, top, plateaus and overhang. With a value of zero, the entire object will be composed of a sparse infill, and water could flow right through it. With a value of one, water will leak slowly through the surface and with a value of three, the object could be watertight. The higher the solid surface thickness, the stronger and heavier the object will be. The default is three.

Attached and in subversion is the updated skeinforge with a few bug fixes.

There is now a hex grid option in fill, to create a hexagonal grid. With cross hatching, the cross grid has a different thickness than the base grid, so it is not an equal, optimal honeycomb.

Some help understanding oozebane would be appreciated. In the example below using skeinforge from the Nov 6 zip file above, the feedrate drops before the extruder is switched off. Will this not cause a blob near the end of the extrusion?

Without oozebane, my gcode starts:
G21
G90
G28
M103
M105
M108 S130.0
M104 S220.0
M101
G1 X3.84 Y1.32 Z0.18 F960.0
G1 X9.13 Y1.32 Z0.18 F960.0
G1 X9.13 Y9.88 Z0.18 F960.0
G1 X1.47 Y9.88 Z0.18 F960.0
G1 X1.47 Y1.32 Z0.18 F960.0
G1 X3.63 Y1.32 Z0.18 F960.0
M103
M104 S195.0
G1 X1.13 Y0.98 Z0.65 F480.0
G1 X9.47 Y0.98 Z0.65 F480.0
.....

With oozebane, I get:
G21
G90
G28
M103
M105
M108 S130.0
M104 S220.0
M101
G1 X3.84 Y1.32 Z0.18 F960.0
G1 X9.13 Y1.32 Z0.18 F960.0
G1 X9.13 Y9.88 Z0.18 F960.0
G1 X1.47 Y9.88 Z0.18 F960.0
G1 X1.47 Y6.16 Z0.18 F720.0
M103
G1 X1.47 Y2.66 Z0.18 F240.0
G1 X1.47 Y1.32 Z0.18 F240.0
G1 X3.63 Y1.32 Z0.18 F960.0
M104 S195.0
G1 X1.13 Y0.98 Z0.65 F480.0
G1 X9.47 Y0.98 Z0.65 F480.0
.....

Indeed it would bring about a blob. Oozebane is is full of bugs, you have found another. The updated skeinforge is attached and at:
[members.axion.net]

Thanks for this. The slow-down still does not complete correctly because on the last move the feedrate goes back up to the original value. I feel I ought to submit a fix rather than just report it but I do not yet have sufficient understanding of the code to do this with confidence. The number of slowdown steps is set to 2 and it is the third which has the fast speed so guess the process is starting too early. The gcode output from the first moves of diamond.gts is below

Jon

without oozebane :
.....
G1 X5.936 Y-2.584 Z-6.316 F960.0
M101
G1 X8.823 Y0.304 Z-6.316 F960.0
G1 X0.154 Y8.973 Z-6.316 F960.0
G1 X-9.223 Y-0.404 Z-6.316 F960.0
G1 X-0.554 Y-9.073 Z-6.316 F960.0
G1 X5.788 Y-2.732 Z-6.316 F960.0 .....
M103
( )
G1 X4.762 Y-3.512 Z-5.847 F960.0

with oozebane:
....
G1 X5.936 Y-2.584 Z-6.316 F960.0
M101
G1 X8.823 Y0.304 Z-6.316 F960.0
G1 X0.154 Y8.973 Z-6.316 F960.0
G1 X-9.223 Y-0.404 Z-6.316 F960.0
G1 X-0.554 Y-9.073 Z-6.316 F960.0
M103
G1 X0.838 Y-7.681 Z-6.316 F720.0
G1 X3.313 Y-5.207 Z-6.316 F240.0
G1 X5.788 Y-2.732 Z-6.316 F960.0
( )
G1 X4.762 Y-3.512 Z-5.847 F960.0

Hi Enrique

Many thank for adding the file extension parameter which speeds up the process.

I still have one query on the times set in Raft.

If I change all the temperature change times to zero I still get a lot of round and round movements without extrusion. I thought maybe zero is ignored so I tried .1 of a second but I still get a lot of moves that take a lot longer than .1 of a second. These moves are not really required as my extruder is set up to feed hold the CNC until extruder reaches commanded temperature. Should a zero setting suppress the round & round movements?

---

Regards

Ian

Hi Jonwise,

Thanks for posting the oozebane output, the latest skeinforge with updated oozebane is attached and at:
[members.axion.net]

Ian,

I tried setting all the temperature change times to zero and the raft loops disappeared as they should. Comb and cool also sometimes make loops, so download the latest version. Then raft the object & look at the file with skeinview or something, then comb the raft gcode file & look, then cool the comb gcode file & look.

Cheers,
Enrique