I am experiencing extremely long slicing times. When i hit "Save toolpath to disc" it can take up to 8 hours to create the .BFB file! Granted the finished file is 120MB and uses almost 1KG of ABS in a single print. Not sure if this is normal or i have some setting i don't know of turned on or off.
The output for me is not .Gcode as i run a Cubepro printer that is bits from bytes. I would say its not the computer as its a brand new HP cad workstation.
Any help is greatly appreciated. Attached is my FFF profile.
Thanks!
Re: Long slicing times
Without the models STL-file the FFF-file makes no sense. The settings what ever it may be can't cause this when only 1 process is activated.
But if the STL has faults such as open holes, fliped normales, open geometries inside, walls with only one side (mesh surfaces) .... it seems possible. S3D is not very tolerant against such failures. Do you have run the repair menue for the model?
Also it is possible that the model has too much triangles when it was exported from the CAD-drawing to STL-file.
I have tested this model:
viewtopic.php?f=9&t=9656 ( https://www.thingiverse.com/thing:438789 )
it has only a7 MB STL-file but 80 MB GCode. The slicing needs ~ 1 - 1,5 minutes, a lot of failures included.
The preparing to print to gcode or to bfb takes nearly the identical time for a trouble-free part.
Regards
horst.w
GER
But if the STL has faults such as open holes, fliped normales, open geometries inside, walls with only one side (mesh surfaces) .... it seems possible. S3D is not very tolerant against such failures. Do you have run the repair menue for the model?
Also it is possible that the model has too much triangles when it was exported from the CAD-drawing to STL-file.
I have tested this model:
viewtopic.php?f=9&t=9656 ( https://www.thingiverse.com/thing:438789 )
it has only a7 MB STL-file but 80 MB GCode. The slicing needs ~ 1 - 1,5 minutes, a lot of failures included.
The preparing to print to gcode or to bfb takes nearly the identical time for a trouble-free part.
Regards
horst.w
GER
Re: Long slicing times
Thanks for the reply Horst.w. That’s my dads name by the way! I have also tried this model”terminator” a few weeks back just for fun and ran into the same issue. Since it was just for fun and not for work I aborted it and never printed it. All my files come from solidworks and are not complicated at all. I don’t think I have any inverted normals but I will post the Stl when I am back to work on Monday. I do export them in very high resolution so that could be an issue. The same file when sliced in grabcad for a stratasys dimension elite only takes minutes. FYI I have this issue with all prints and not just one model. The longer the finished print time the longer it takes to process the file.
Re: Long slicing times
Hi,
greetings to my name twin.
S3D is currently the fastest slicer of all. If there are slicing problems, mostly the named failures cause it. The list is not complete and other failures like problems with the graphic-card of the pc or their drivers are not impossible.
To enclose the occurence I think the best is to compare the slicing with a well known model.
If possible download this:
https://www.thingiverse.com/thing:1385312 >>> machine 1 and only the file "Track.stl". S3D shows the model as manifold.
I need on my I3 / NVidia Geforce 1 GB / 4 GB RAM laptop 48 sec to sclice "Track.stl"
Conditions: 0,20 LayerHigh, 6 layer bottom / top, 8 perimeters , NO support (is too variable); Infill 70% or 25% has the same result.
Nice WE
H.
greetings to my name twin.
S3D is currently the fastest slicer of all. If there are slicing problems, mostly the named failures cause it. The list is not complete and other failures like problems with the graphic-card of the pc or their drivers are not impossible.
To enclose the occurence I think the best is to compare the slicing with a well known model.
If possible download this:
https://www.thingiverse.com/thing:1385312 >>> machine 1 and only the file "Track.stl". S3D shows the model as manifold.
I need on my I3 / NVidia Geforce 1 GB / 4 GB RAM laptop 48 sec to sclice "Track.stl"
Conditions: 0,20 LayerHigh, 6 layer bottom / top, 8 perimeters , NO support (is too variable); Infill 70% or 25% has the same result.
Nice WE
H.
Re: Long slicing times
Horst,
Configurations on my machine are as follows
Windows 10 Pro
I7 2.8 ghz
64GB ram
Nvidia Quadro M2200 4gb memory
On the model you suggested “track” it takes 14 seconds from when I hit “prepare to print” until I see the model sliced. When I hit “save toolpath to disc” it takes 7 seconds to create the .Gcode file. The problem is my printer takes a .BFB file and that’s when the problem happens. It will sit there for several hours creating it. I will actually get both a .gcode and a .Bfb file and only the latter is of any use to me. This might be a question for Simplify directly as they coded the conversion into their program. Using other profiles that only create .gcode files it is nearly instant!
Thanks again for the help!
Bernhard
Configurations on my machine are as follows
Windows 10 Pro
I7 2.8 ghz
64GB ram
Nvidia Quadro M2200 4gb memory
On the model you suggested “track” it takes 14 seconds from when I hit “prepare to print” until I see the model sliced. When I hit “save toolpath to disc” it takes 7 seconds to create the .Gcode file. The problem is my printer takes a .BFB file and that’s when the problem happens. It will sit there for several hours creating it. I will actually get both a .gcode and a .Bfb file and only the latter is of any use to me. This might be a question for Simplify directly as they coded the conversion into their program. Using other profiles that only create .gcode files it is nearly instant!
Thanks again for the help!
Bernhard
Re: Long slicing times
Oh, I see it maybe lucrative to upgrade the computer 
Related to an other thread I had tested some small objects with slicing to the bfb-format. but I couldn't find out any time-differences to only writing a gcode-file. That was always the same.
H.
Related to an other thread I had tested some small objects with slicing to the bfb-format. but I couldn't find out any time-differences to only writing a gcode-file. That was always the same.
H.
