I’m not sure if this still hold true of the latest versions of Preform, but today I just realized how slow Preform is at doing the actual slicing.
It’s one of the faster programs at generating supports, but slicing not so much. Today I started a print of an STL which had the supports already generated, so all I needed to do is send it to the printer. I selected 0.025 layer height, and that resulted in a 2866 layer print, which would take 13:08 hours to print.
So Preform began to send the data to the printer, and the printer began its first layer about 45 seconds after I clicked print. 1:42 hour later it was done slicing the model. By the time it was done sending the data, the print was already at layer 69.
I also sliced the same model with Slic3r at the same resolution and it generated the same number of slices, 2866, but only took 5 minutes to generate the slices. Now I agree that there’s a big difference between generating images, vs. generating G-Code, so I loaded the same file into Cura, which took 561 seconds (9.5 minutes) to generate the G-Code.
Perhaps instead of creating an image of each slice (as per most other slicing software) Formlabs preform calculates a path for the laser at each layer, in much the same way as a lot of 3D CAM software does (which creates a cutter path track for each Z axis level height) that could be the reason Preform is slower than software which simply produces a series of 2D images for each layer. Those images are then displayed on the LCD display or through the DLP projector to print.
I’m pretty sure it’s not the computer. It really is that slow. Primarily because the model is very complex, due to the supports. When Preform generates it’s own supports, I think they are treated differently, but when you import a model with supports already generated, each supports branch is treated as part of the model, so I think that’s what it’s slowing it down.
That was my thinking exactly. But then I sliced the model in Cura, which generates G-Code, which is basically the same as the code generated by PreForm (I.e. a tool path, not just a series of images).
Cura took less than 10 minutes to generate the complete G-Code for all 2866 layers.
The G-Code used in Cura for your type of printer is very simple - no tool paths, nothing complicated. Have a look at a complete layer sequence by viewing the g-code, it something like below
G-code (and M-Code) is simply code to control a machine, that includes many commands in addition to calling a cutter path
For the purpose of this explanation I have ignored the control system used by Formlabs - it may well be a proprietary set of instructions that have moved away from traditional codes of machine control, but the fundamental principles will be the same.
…
If we look at the G-code to move through a tool path (that could be a laser path) of a simple ellipse of say 100 x 60, then we end up with this:
So as you can see G-codes can do both That is control the projection of an image, or control a cutter path, but the cutter path calculation is significantly more complicated than simply moving the z plane and displaying an image at each layer, I guess that might be a big factor as to why Preform is slower - its got a much more complex and processor intensive task to do than the slice and control software on your budget printer.
(M-Codes are miscellaneous functions often specific to a specific machine)
I did not select a MSLA printer in Cura, I selected the Peopoly Moai, which is a laser SLA printer just like the Form1, so it generated a “real” tool path.
The GCode for the print I mentioned n the original post was simply too large to even open up in a Word document, so I put a simpler model in Cura and slice’s it with the MOAI 0.1mm profile. it generated a 42MB Gcode file. The same model was then sliced in Slic3r for the MP Mini MSLA, and it gave me a 3.4MB CWS file.
FWIW, the MSLA CWS file is not G-Code it’s just a zip containing a print profile textfile, and a bunch of PNG files representing each layer. Here is what Layer 100 looks like
And here is an excerpt from the GCode with only layer 100 and the printer G-Code Preamble and post code. I had to convert them to a PDF because text files and such are not allowed here. PM_nun_complete - Layer 100.pdf (137.1 KB)
Same… I’ve had prints with >1 day of printing and it never took more than 15 minutes to calculate all the layers and then upload it to the machine… using my laptop.
What material profile did you select/ and can you please upload the STL files rather than just your FORM file
I presume from the picture that its your own supports rather than Preform’s - It looks like there is a lot of unsupported areas (the wings for example)?
The profile is Gray v3, and yes, the supports were generated in Slic3r, not Preform.
I exported the whole model with supports as a single STL file, then printed it both on the Form 1+, and the MP Mini at 0.025. without any additional supports.
All the areas that need supports have supports. The tips of the wings point upward at angles that don’t require supports. As you can see from the photo below, it prints just fine:
Yes - The STL file (rather than the Form File) would have allowed people to play with the supports and see if its the lack of support generation by Preform that causes your problem (that is slow speeds in Preform upload)
That’s the whole point though, isn’t i? If you let Preform generate its own supports, the output will be totally different.
The idea is not to judge its ability to generate supports, rather to see how fast or slow it is when it has to slice a very complex model, which in this case is complex because of the dense supports.
Yeah, I’ve never had it take more than like 10 minutes, I haven’t done as large 25 micron prints, but I’ve filled the platform with prints at 50 microns
Oh well, it is a nice little model, especially for those that like miniatures. It can be printed with any profile (I think), since the supports are already built in, you can just drop it on the platform, select 0.025 layer height, whatever profile you want, and click print.
But if no one wants to try it, I guess we’ll never know how fast (or slow) Preform really is. Too bad.
