Skeinforge - More Memory

I have been trying to use ReplicatorG 0019 w/ Skeinforge in order to slice up a very large and intricate STL that is approximately 400 x 400 x 320mm. After around 16+ hours of compiling , I get the following out of memory error in the ReplicatorG window:

[11:31:29] Traceback (most recent call last):
[11:31:29]   File "skeinforge.py", line 346, in 
[11:31:29]     main()
[11:31:29]   File "skeinforge.py", line 341, in main
[11:31:29]     writeOutput( ' '.join(args) )
[11:31:29]   File "skeinforge.py", line 278, in writeOutput
[11:31:29]     pluginModule.writeOutput( fileName )
[11:31:29]   File "C:\replicatorg-0019\skeinforge\skeinforge_tools\export.py", line 135, in writeOutput
[11:31:29]     gcodeText = unpause.getUnpauseChainGcode( fileName, gcodeText )
[11:31:29]   File "C:\replicatorg-0019\skeinforge\skeinforge_tools\unpause.py", line 74, in getUnpauseChainGcode
[11:31:29]     gcodeText = fillet.getFilletChainGcode( fileName, gcodeText )
[11:31:29]   File "C:\replicatorg-0019\skeinforge\skeinforge_tools\fillet.py", line 240, in getFilletChainGcode
[11:31:29]     gcodeText = oozebane.getOozebaneChainGcode( fileName, gcodeText )
[11:31:29]   File "C:\replicatorg-0019\skeinforge\skeinforge_tools\oozebane.py", line 112, in getOozebaneChainGcode
[11:31:29]     gcodeText = wipe.getWipeChainGcode( fileName, gcodeText )
[11:31:29]   File "C:\replicatorg-0019\skeinforge\skeinforge_tools\wipe.py", line 100, in getWipeChainGcode
[11:31:29]     gcodeText = hop.getHopChainGcode( fileName, gcodeText )
[11:31:29]   File "C:\replicatorg-0019\skeinforge\skeinforge_tools\hop.py", line 87, in getHopChainGcode
[11:31:29]     gcodeText = stretch.getStretchChainGcode( fileName, gcodeText )
[11:31:29]   File "C:\replicatorg-0019\skeinforge\skeinforge_tools\stretch.py", line 102, in getStretchChainGcode
[11:31:29]     gcodeText = cool.getCoolChainGcode( fileName, gcodeText )
[11:31:29]   File "C:\replicatorg-0019\skeinforge\skeinforge_tools\cool.py", line 103, in getCoolChainGcode
[11:31:29]     gcodeText = clip.getClipChainGcode( fileName, gcodeText )
[11:31:29]   File "C:\replicatorg-0019\skeinforge\skeinforge_tools\clip.py", line 91, in getClipChainGcode
[11:31:29]     gcodeText = comb.getCombChainGcode( fileName, gcodeText )
[11:31:29]   File "C:\replicatorg-0019\skeinforge\skeinforge_tools\comb.py", line 97, in getCombChainGcode
[11:31:29]     gcodeText = tower.getTowerChainGcode( fileName, gcodeText )
[11:31:29]   File "C:\replicatorg-0019\skeinforge\skeinforge_tools\tower.py", line 101, in getTowerChainGcode
[11:31:29]     gcodeText = raft.getRaftChainGcode( fileName, gcodeText )
[11:31:29]   File "C:\replicatorg-0019\skeinforge\skeinforge_tools\raft.py", line 207, in getRaftChainGcode
[11:31:29]     gcodeText = speed.getSpeedChainGcode( fileName, gcodeText )
[11:31:29]   File "C:\replicatorg-0019\skeinforge\skeinforge_tools\speed.py", line 111, in getSpeedChainGcode
[11:31:29]     gcodeText = multiply.getMultiplyChainGcode( fileName, gcodeText )
[11:31:29]   File "C:\replicatorg-0019\skeinforge\skeinforge_tools\multiply.py", line 94, in getMultiplyChainGcode
[11:31:29]     gcodeText = fill.getFillChainGcode( fileName, gcodeText )
[11:31:29]   File "C:\replicatorg-0019\skeinforge\skeinforge_tools\fill.py", line 385, in getFillChainGcode
[11:31:29]     gcodeText = inset.getInsetChainGcode( fileName, gcodeText )
[11:31:29]   File "C:\replicatorg-0019\skeinforge\skeinforge_tools\inset.py", line 155, in getInsetChainGcode
[11:31:29]     return getInsetGcode( gcodeText, insetPreferences )
[11:31:29]   File "C:\replicatorg-0019\skeinforge\skeinforge_tools\inset.py", line 167, in getInsetGcode
[11:31:29]     skein.parseGcode( insetPreferences, gcodeText )
[11:31:29]   File "C:\replicatorg-0019\skeinforge\skeinforge_tools\inset.py", line 504, in parseGcode
[11:31:29]     self.addInset( rotatedBoundaryLayer )
[11:31:29]   File "C:\replicatorg-0019\skeinforge\skeinforge_tools\inset.py", line 427, in addInset
[11:31:29]     self.addGcodeFromRemainingLoop( extrudateLoop, alreadyFilledArounds, halfWidth, rotatedBoundaryLayer.z )
[11:31:29]   File "C:\replicatorg-0019\skeinforge\skeinforge_tools\inset.py", line 370, in addGcodeFromRemainingLoop
[11:31:29]     self.addGcodeFromThreadZ( loop + [ loop[ 0 ] ], z )
[11:31:29]   File "C:\replicatorg-0019\skeinforge\skeinforge_tools\inset.py", line 385, in addGcodeFromThreadZ
[11:31:29]     self.addGcodeMovementZ( point, z )
[11:31:29]   File "C:\replicatorg-0019\skeinforge\skeinforge_tools\inset.py", line 390, in addGcodeMovementZ
[11:31:29]     self.addLine( "G1 X%s Y%s Z%s" % ( self.getRounded( point.real ), self.getRounded( point.imag ), self.getRounded( z ) ) )
[11:31:29]   File "C:\replicatorg-0019\skeinforge\skeinforge_tools\inset.py", line 434, in addLine
[11:31:29]     self.output.write( line + "\n" )
[11:31:29] MemoryError: out of memory
[11:31:30] Unrecognized error code returned by Skeinforge.
[11:31:30] Toolpath generation failed!

Does anyone know how to modify Skeinforge to allocate more memory space?

---

Jim Smith
GrassRootsEngineering.com

I ran into the same problem with a model I recently sliced. The model had some areas that sliced too thin, so I modified the part to beef it up a bit. There may have been a mesh defect which was fixed when I made the change, but the other thing I did was add another page file on my spare drive. The page file is virtual memory. Since it uses the hard drive, it cannot be accessed as fast so relying on it substantially will reduce system performance.

After that, I have not had any problem slicing the model. I have watched my memory usage and slicing it still drags the amount of free ram down to 200mb though. I normally have 1500 to 1000mb free.

Thanks for the tip. To test, I changed the page file size on my C drive to 20gb , but I still get the same out of memory error around the same amount of STL slicing time as I did before. I will try making a second pagefile on a different hard drive. But are you sure this isn't some sort of a python memory pre-allocation problem?

Edited 1 time(s). Last edit at 01/12/2011 12:31PM by Jim.

---

Jim Smith
GrassRootsEngineering.com

If a 20GB page file didn't help, I doubt that a second page file will change anything. I just made a new one because I had a spare drive installed and it didn't have a page file already. Expanding the first one should have the same effect.

Since the page file didn't help, try slicing a model that is known to be slice-able. Try this one unless you know of something smaller that has worked before: http://www.thingiverse.com/thing:3462

If a different model works, then there might be a defect in the mesh which causes skeinforge to go bonkers. Have you tried using Meshlab or similar tools to fix it? Meshlab has a number of tools that are supposed to be able to automatically fix a bad mesh. I couldn't get it to fix the "out of memory" error in skeinforge though. If there was a defect, I wasn't able to see it either.

Edited 1 time(s). Last edit at 01/12/2011 05:37PM by dazed.dnc.

Q. How much ram is in the system, and which version of Windows do you run?

Note: Depending on the OS and the amount of total memory, a process may only allocate a certain amount of ram, despite the presence of a page file. A 64 bit OS also makes a difference here. Without this info it's a bit hard to figure out what the problem is.

@dazed, I believe it could be that my stl had holes in it. I tried using meshlab and netfabb to fix them but I still received the same error message. I am currently slicing a dumbed down version of my model of the same 400 x 400 x 320mm size. So far it has had no errors and has been slicing much longer than the original model, even though it is going very very slow. If this fails, I may try using FabStudio with an xml to gcode converter to print with repicatorG.

@cefair, I use an old laptop dedicated for 3D printing that has a fresh install of windows xp professional sp3 with 2gb of ram.

---

Jim Smith
GrassRootsEngineering.com

dazed.dnc, you were correct, my large STL had a number of holes and self intersecting faces in it. I fixed it completely with netfabb. I sliced it with skeinforge and it worked great! It created a huge 68mb g-code file.

But now I have another problem ReplicatorG just hangs when I try to open this massive g-code file. It seems as if there is a maximum file size that can be opened. I tired copy and pasting the code manually in small chunks into a blank g-code tab in ReplicatorG, but it got to a point where it would not let me paste in any new code. Does anyone know how if ReplicaorG has limits to the number of lines of g-code? I know ReplicatorG wasn't really designed with printing parts this large in mind but does anyone know if it is possible to modify it so that my g-code file can be executed with this program? Or should I just try using EMC2?

---

Jim Smith
GrassRootsEngineering.com

Hi

I am using EMC2. I have had no trouble with any of my files but they are not as big as yours.
I switched to EMC because I could not get some of my files to run using the standard host and firmware.
The quickest check might be to use the EMC Live CD and see if the file will load.

---

Regards

Ian

Use send-gcode.exe instead.

---

Bob Morrison
Wörth am Rhein, Germany
"Luke, use the source!"
BLOG - PHOTOS - Thingiverse

Hmm I tired using send-gcode.exe, but it does not work as I don't yet use the 5D firmware. I am currently running the stock ReplicatorG firmware. Is there anyway to use with send-gcode.exe with the ReplicatorG firmware?

---

Jim Smith
GrassRootsEngineering.com

Jim Wrote:
-------------------------------------------------------
> It created a
> huge 68mb g-code file.

My biggest Gcode is 18mb. I think one of them even fills 3/4 of the build plate.

If you look at each layer slice, do you see anything out of the ordinary? Like printing in spaces that should be empty and not printing where it should be filled?

One of the first prints I tried was a modified STL from thingiverse. Instead of loading it into CAD to make the changes, I tried to take a shortcut and tack on extra faces in blender. I didn't connect them via shared vertexes, so when skeinforge sliced it, there were places inside the part where it got confused. It was like it couldn't figure out what volume made up the interior of the part and what volume made up the exterior. I'm wondering if a similar effect is inflating your STL.

It sounds like you might be better off trying to grab dimensions from the print and re-drawing it rather than trying to "patch" it. using mesh tools. What part are you trying to print? Maybe someone on these forums can spot the problem?

I am quite certain the STL is not the problem here anymore. It was fully healed. A G-code file of this size is to be expected because the part is quite complex and is very large (approximately 400 x 400 x 320mm)

The problem now is finding/modifying software that can handle sending all the commands of a gcode file of this size to a reprap motherboard 1.2 running stock replicatorG firmware.

---

Jim Smith
GrassRootsEngineering.com