I’m wondering why there isn’t a standard format for 3D print slicing profiles.
Slicing profiles are a critical item of information in today’s world of 3D printing. They ensure the best possible print results by matching a specific material to a specific 3D printer model through the use of print parameters. In other words, the answer to “how do I print this material on that printer?” is “use this profile.”
This works really well in practice. 3D printer operators can develop profiles on their own and store them for future use. They can be shared for others with similar setups. They could even be bought and sold, although I haven’t really seen that yet.
But there’s one nagging problem that really needs to be solved.
The profile formats differ between slicing software tools.
For a long time this wasn’t really an issue. When you purchased a 3D printer, it came with a slicing system and that’s what you would use. The manufacturer would improve the program’s features and you could do more. Often your print profiles can be used on “newer” versions of the software.
But then a problem started to appear with the increasing prevalence of inexpensive desktop 3D printers, most of which are agnostic as to the slicing program used.
Many of the inexpensive Asian machines ship with an old version of Ultimaker Cura, possibly with a .curaprofile file with it. In reality, however, those operating multiple 3D printers these days are accustomed to using different slicers.
The two main slicers these days are Ultimaker Cura and PrusaSlicer, both of which are open sourced. There are some other slicers on the market, but some, like Simplify3D, have fallen so far back in features they are now rarely used. Others are derivatives of the main two, such as SuperSlicer (made from PrusaSlicer), or the countless rebranded Ultimaker Cura versions for specific 3D printer models.
The 3D printer manufacturers assume you are using their version of the provided slicer, but that’s just not right these days. Slicing software is a competitive business, with new versions offering very significant advances in capability. It should be a crime to prevent use of those advanced features.
Usually when encountering a new device, I look for the print profiles and attempt to import them into a “proper” slicer. That is a process that more than not will fail. Sometimes it’s because the old profile format won’t work with a newer version of the software.
Sometimes it’s because the profile is formatted for one slicer when you want to use another.
The typical sequence of events I encounter is:
- Try to repeatedly import the profile to where I want and fail
- Give up and tediously type in ALL the print parameters into a blank profile on the target slicer
That is unacceptable. 3D printer operators should have the freedom to use whatever slicer they want, because the features vary between them.
The solution would be to have the slicer makers agree on a standard XML-based format that would enable export from one and easy import to another. It would enable 3D printer manufacturers to produce “universal” print profiles that could be used by clients using any slicing software.
Of course, there are differences between the slicers. One slicer might have a feature the other one doesn’t. The proper way to handle that scenario is to set clear defaults for when an imported profile doesn’t specify something, and make the operator aware of it.
Will this happen? I’m not sure it will. There are reasons 3D printer manufacturers might want to keep their profiles unique and safely within their own ecosystem. By making them universal, they risk losing some stickiness with the clients.
On the other hand, these systems are open source, and therefore enterprising programmers could simply implement this feature.
I don’t know if this concept will go forward, but at least I feel better by writing about it.
