JUst trying to find out if there is any settings that could be manually added to devices to get this slicer to work on a chromebook for an anycubic photon 4?
tl;dr not unless someone wants to submit a PR to support the .pm4n file format.
I’m done chasing needlessly proprietary mSLA file formats. It’s exhausting. FDM printers use gcode. There’s no reason resin printers can’t standardize on something since the data they encode is SO much simpler. Except the mSLA hardware is ruled by one company out of China that uses file type disruption as a business model to lock in their customers with NDAs. It’s both stupid and evil.
1 Like
Aha, this is the thread I needed!
I am here because I was offered an Anycubic Photon Mono SE for £0 (back story not conveyed to me). It’s obsolete but it printed the two test objects just fine.
My experience is OpenSCAD (since 2025-08) and a slightly tired Creality Ender3; and many years in software.
I knew the filament extrusion slicers have a colourful, somewhat open and usefully competitive family tree. I use Ultimaker Cura 4.13.2 (obsolete?) for diagnostic slicing - because it’s available as a Snap and I’m lazy. Then I use Prusa on the printer itself because it has the right settings.
I expected similar variety and openness for the resin printer when I started looking 
but I found that it’s fully proprietary and compiled for platforms I don’t have or prefer not to trust to a closed source binary. I got my hopes up when I found the grid.space tool family and here I am.
Perhaps for the next person coming looking for a more free & open slicer for resin printers, what are the possible directions?
- Dissecting and documenting the existing file formats, to assist someone to write a backend?
- Recommending hardware platforms which are more open?
- Any other options..?
I presume they are all essentially a stack of PNGs and some headers for each frame and the whole file? Or do the file sizes suggest voxel compression?
Yes, they won’t get any of my money.
It’s also fragile. It only takes one person with the skill, time and annoyance before the model cracks and they suddenly have competition.
tl;dr the uv tools project will edit many proprietary resin printer (MSLA) formats. it’s not a slicer, though. I haven’t looked at it in a while.
there are several reasonable, compact, and simple approaches for MSLA file formats that one could consider. something a stack of RLE images with layer times and peel speeds is what most proprietary formats use. simpler and far more compact would be a stack of SVGs with the same annotations as attributes. layers are so slow to cure that even a modest embedded processor could raster each layer while the next one cures. but none of that matters if the printer driver boards can’t support it. it boggles the mind that MSLA printer hardware doesn’t do this and instead wants files that are 100s of MBs.
there have been several attempts at open design / open source MSLA printers. the biggest barrier is a reliable and consistent part supply. invariably, the most crucial parts all come out of china. lcds for light masks change like the wind, so good luck with that. it’s relatively easy to design a board that could be manufactured any number of places … so much easier that an FDM printer board. unfortunately, that’s not the hard thing to solve for.