UVJ format / Open (M)SLA format #687
Replies: 8 comments 12 replies
-
Correct.
It can, like other formats UVtools create a new layer in same position Z, UVJ defines A good and future proof format should be gcode + png images. Forget about weak microcontrollers, microprocessors with Linux and added functions and capabilities are the way to go, even if it adds a little more cost. Just like we see on FDM, most people add a Pi to have octoprint and other features, that is more expensive than provide a final board that is able to do that from start. Pixels vs Vectors: There is one format that UVtools supports that use vectors: SVGX. However, I see no advantage on that. It will support other printers but who wants to print a file sliced with given settings for a given resin profile? That's a user error. Even on FDM I never dare to print other's .gcode even if is for the same printer brand and material, not because I don't trust the file but because I don't trust the settings which are never optimal, same goes otherwise. So, in the end people should always slice their own to guarantee the best settings and success and then having a vector that should be converted to image after all is not a bonus. Also, if you go vector forget about AA or get ready to have a mess in the vectors due the brightness change. |
Beta Was this translation helpful? Give feedback.
-
|
@sn4k3 It skipped my attention the layer in UVJ can have its own Z - thanks for pointing this out. So, UVJ fits then my requirements to a high degree: {mesh} > [slicing] => {UVJ with PNGs} => [firmware preproc] => {G-code with PNGs} => [firmware G-code with PNG processing extension] Resin Specific Settings: like you, I also slice for each (FDM) printer as none is the same like the other, different nozzles, different filament; yet, for MSLA the resin dependent settings seem commonly in the firmware/device, no matter the settings in pwma (Mono 4K) or pmx2 files (Mono X2), the machines doesn't care, it overrides what the slicer set => the files are only describing which voxels to cure, but speed of motion and exposure times are kept & defined in the firmware/device only. How to other MSLA machine behave here? UVJ Multi-Exposure CapabilityBack to UVJ, so essentially I can compose a multi-exposure print like this then: correct? I would then convert in my controller the UVJ into some G-code according the firmware or file-settings (lift/retract, exposure times, etc) - the main task is to bring the exposure image to the LCD. Gcode MockupA brief mockup of G-code to operate a MSLA with Marlin or RRF: RRF with a dedicated plugin supports custom gcode, and call external program on SBC, to put layer/image to the UV LCD. I like to transform at least one of my Anycubic Photon Mono 4K so I can control it better, Turbo Resin gives some direction. Yet I would prefer to replace the mainboard with RAMPS and run PyCNC, but controlling the UV LCD might be the hard to do. |
Beta Was this translation helpful? Give feedback.
-
So far as I know almost all printers respect settings set on file inside a range, settings you set matters, you can try set 20s to normal layers and your anycubic machine will follow that. Global settings are used (set on slicer), advanced formats are able to follow per layer settings, including anycubic. If you use global settings, it allows you to modify parameters via LCD.
Correct. You can generate a UVJ with UVtools and open as zip to inspect the structure.
That looks correct, you can use UVtools and convert to a gcode format and inspect the GCode syntax under it tab, there are already some defined commands. For example export to Chitubox -> ZIP
That is the most difficult part to do and why mSLA is still locked. LCD's are hard to address and there are no documentation. Mono LCDs are produced to a brand and documents are private. |
Beta Was this translation helpful? Give feedback.
-
Mixed BagMy experiences with Mono 4K (Firmware 0.0.11 vs 2.0.2) and Lychee Slicer (4.x and now 5.1.8) has been very inconsistent, it fell back to default settings, even though I set it in the slicer - so I kept checking the settings on the printer directly; I manually changed UV intensity to 50% and when another printing .pwma it kept that setting, so the printer setting override the sliced file settings; after few such encounters, I concluded I can't trust any settings I make in the slicer, but only what I see when the print has started. I'm aware the Mono 4K being entry-level resin printer, so my expectations have been minimal too. I tried UVtools.Cmd to convert sl1 into pwma but it produced a bad file, the file structure looked good, but the layer images were scrambled (confirmed via Photon Workshop beside my own previewer), as soon I made more tests I will post a github Issue (not sure if half-compiled and binary unzipped UVtools interfered with each other). Either way, I will continue to mature my own Python-based tool to handle SL1, PW* and UVJ sufficiently to convert the files myself. WorkflowSo I'm not yet set with the entire workflow of mine.
The reason for .uvj step in between, I like to keep track of resin & machine on command-line, see my Prynt3r tool (very experimental stage, as it's a rewrite), right now it's for FDM only, but I like to extend it to SLA as well, eventually being able to do: Whereas As Mono 4K has no network, I need to transfer file manually - otherwise prynt3r logs all |
Beta Was this translation helpful? Give feedback.
-
UVJ 1.0 Proposal - Vendor Neutral MSLA FormatFeel free to comment, suggest alternatives or additional keys etc. As I realized, @sn4k3 / Tiago has extended silently the UVJ format as proposed by @ezrec / Jason by following new settings:
which implies the 2nd stage of build-plate movement, beside the peeling motion. I support this addition. I propose following addition:
Any .uvj which has not the |
Beta Was this translation helpful? Give feedback.
-
|
I highly recommend that the format version number follows the “semver” spec, specifically:
See https://semver.org/ for the general guidelines. The “Vendor” keys should be in a vendor block that can be added to any section, further wrapped by the vendor name, ie: …. |
Beta Was this translation helpful? Give feedback.
-
Here a sample including @sn4k3 extensions and my "Properties.Vendor.VoxGLSlicer" where I list the settings from my slicer: |
Beta Was this translation helpful? Give feedback.
-
|
I agree with semver which most languages can handle easy, and they are strings. 1 or 1.2 or 1.2.1 are all valid and not forced to use all the dots. Also, instead consider version in an increment int like other formats do which is the simplest. |
Beta Was this translation helpful? Give feedback.
-
|
A few questions of clarification for @ezrec & @sn4k3 : Two Stages of Motion
Now, what is the common practice here, as If Lift vs RetractWhat is the reason to differentiate between One Stage of Motion@sn4k3: When Preview Tiny & Huge@ezrec in your samples you indicated
Is this some guidance of size, or how shall we define tiny vs huge in pixels, and the aspect ratios? Also, the files are optional? Suggested recommendation: "if previews are generated, make background transparent" or so. How to deal with additional files?To adapt @ezrec "Vendor" for Thoughts? |
Beta Was this translation helpful? Give feedback.
-
Note that:
Yes and no. Some printers have a second lift set on firmware, if you set 0mm it will use the firmware default. The problem with 0 values on firmwares is that they are never 0. For example, if you set 0mm lift's it will use firmware default, same goes for speed and everything else. |
Beta Was this translation helpful? Give feedback.
-
|
(continuing clarification of terminologies & notions) Retract HeightsRetractHeight & RetractHeight2: I just checked the firmware of my Mono X2, there is
the Retract Heights are implied to be the same as Lift Height 1 & 2, so they don't appear. The Lychee Slicer and Photon Workshop does the same, there are no Retract Heights 1 & 2, as it is implied to be the same as Lift Height 1 & 2. So, if the format supports it, then RetractHeight 1 & 2 is something like fine-tuning descending the build-plate, and the firmware has to implement the constraints for RetractHeight2 arrive to the next layer Z pos as @sn4ke mentioned above. Light Off Time@ezrec defines (click on image to zoom in)
ChituBox Light Off Time: "Light-off Delay = Building Plate Up and Down Time + Additional Delay Time" as from https://helpcenter.phrozen3d.com/hc/en-us/articles/6371494663833-How-can-Light-off-Delay-improve-3D-prints- The problem with this definition is that CB's "light off delay" is a minimum time, in the worst case the resin is still disturbed & in-motion after descend to Z pos, without any waiting time or "additional delay time".
When I checked ChituBox Interlayer G-code I saw this: which makes it even more confusing, that the "Light-Off Delay" in the ChituBox slicer is not the same as
Now, @ezrec 's defines the wait time after UV light (correct me if I misinterpret your definition), and looking at ChituBox and people tuning with "Light-Off Delay" their printing experience, we end up with at least 3 different times:
From what I've got, these three times are mixed up and called "light-off time" or "light-off delay" confusing everyone, and this we need to resolve. As I was reading up and watching various videos on resolving the confusion, a 4th time was introduced, the wait time between lift & retract aka top Z retention time (e.g. https://www.youtube.com/watch?v=u0V961evYAc) which appear in some ChituBox G-code, which was fine-tuned. So, to sum up, we have 4 times:
I didn't draw the
Since ChituBox 1.9 they came up with the same, just naming the reference a bit differently (discovered this after I made all the graphics above):
Any additional development regarding timing? |
Beta Was this translation helpful? Give feedback.
-
|
To be honest; my comments on those fields were best guesses at the time - I neglected to do any experiments to verify my assumptions.
|
Beta Was this translation helpful? Give feedback.
-
|
Hello everyone, author of https://github.com/nviennot/turbo-resin File formatI would much prefer that we don't use PNG. I've measured the ROM footprint, and it's ~20KB. Not a huge deal, but the RAM footprint is massive: 50KB due to the decompression algorithm. It's awful. It can be done, but there's not going to be much left for the rest of the firmware (e.g., things like wifi support). As a point of comparison, the ROM footprint for the CTB format is 0.3KB, and PWMA 0.3KB. So that's a pretty massive difference. Color depthWe want to support at the very least 4-bit color depth. Note that it'd be nice to support people who want to use the 3D printer as a way to make circuit-boards. MasksThings that are helpful when calibrating a new printer+resin is to do multiple exposures. Sending a 4K (or 8K) image to the LCD takes a long time, like 10secs at times, depending how well the image compresses. Maybe we want to have the ability to apply a given mask as an overlay, but that's something the FPGA driving the LCD panel should be able to understand. And it's hard to write a custom firmware for that. Still, we should allow the file format to eventually specify masks. G-codeI think it's a good idea to use g-code. We could be specifying the acceleration/speed settings in a more standardized format. Maybe masks would be applied via a g-code command like "MXXX mask.png" or maybe "MXXY (x1,y1,x2,y2)" as a rectangle coordinate. Also, I'd like the possibility to implement a force sensor in the printer (like https://blog.honzamrazek.cz/2022/01/prints-not-sticking-to-the-build-plate-layer-separation-rough-surface-on-a-resin-printer-resin-viscosity-the-common-denominator/) which is used by the firmware to decide on the correct build plate movement. The maximum "pressure" could be defined by g-code. All the json-like parameters per-layer is wrong in my opinion. It doesn't compose well. We can't make experiments. Having different speeds is silly. What if I want 3? G-code is the answer. |
Beta Was this translation helpful? Give feedback.
-
|
UVJ is a format made to be "human friendly" to view, inspect, hand edit and then convert to target format. Was not intent to be used on printers. It can be used but not with low spec printers due PNG. Workflow: Convert a format to UVJ -> view/edit -> Convert back to original format -> Print -- Was the original motive of UVJ. If you are looking for a format that handles everything in binary / RLE format look at OSLA, it was composed by me, supports a ton of image types and uses gcode. While it still records global and per layer data in its structure, it is pure informative, all parameters are on gcode and should be parsed from there. Have a look at it. |
Beta Was this translation helpful? Give feedback.
-
|
We are mixing motives now, here my motive:
|
Beta Was this translation helpful? Give feedback.
-
|
@sn4k3 what would be the feature differences between UVJ with the additions we discussed so far and your current OSLA 1.0 definition? To ask specifically:
|
Beta Was this translation helpful? Give feedback.
-
Yes, custom table is there to insert any values you want "without" limitation.
Binary files use only values, however you can use separators key-bytes, the custom table is defined by writer. Readers like UVtools keep the table but won't show it to user as the struct is unknown/custom.
Correct. GCode is preferred if available, if printer unable to follow gcode or not present it will fallback to layer definition table which hold the backup values. |
Beta Was this translation helpful? Give feedback.
-
OSLA: Powerful, Requirement for Labeling Capabilities for Firmware/Device@nviennot the OSLA definition I glanced over, here my thoughts:
The definition is powerful, but with it also makes it hard(er) to support, and labeling what exactly is supported in a firmware/device is required. And the slicers need to know which devices are capable which features of OSLA. The idea to use a load cell to increase print speed as you wrote me by email, is there something the file format needs to support (UVJ or OSLA), or this is mainly a firmware feature [measure area exposed, and combine Z-motions with load cell measurement]? |
Beta Was this translation helpful? Give feedback.
-
|
OSLA is still a draft and I need to make some alterations (Also open to ideas), such as file is limited to 4GB due Is true that the versatility of image format is a "problem" for slicers and UVtools, maybe we should stick with one for previews like RGB24 and another for layers like RLE, instead of giving chooise? That will simplify and make it more easy and less messy to read/write.
Loadcell controls lifts, so in gcode all you need is to implement the loadcell M command to make the lifts by it measurements, eg:
M8001 is the command I just made to indicate lift is handled by loadcell This is just an idea on how to implement the load cell using gcode. |
Beta Was this translation helpful? Give feedback.
-
|
@Spiritdude reached out to me via Twitter to express my opinion on the topic. TBH, I haven't read the discussion. But I have been thinking about programming MSLA machines for a long time in past, and I came up with the following proposal (it is commented example program). I abandoned the idea of building a custom driver electronics recently, so I decided to share it publically: # There are line comments denoted by '#'. There is no other type of comment.
# There is a mandatory language type and version specification
language MSLALang version=1
# Then there can be a list of parameters that the user can set before starting
# the print. Parameters marked as mutable can be adjusted during runtime.
param baseExposure type=number default=2 min=0 max=10 mutable=true
param bottomExposure type=number default=20
param baseLayerCount type=number default=5
# We can also have constants that make it easy for humans to understand what's
# going on
const layerHeight type=number value=0.05
# A few words about types: There are two built-in types: number and string.
# Additional drivers can implement a new types. Usually that would be an image
# that we can project on the screen. However, you cannot reference these types
# from the MSLA language.
# A program in the MSLA language is just a set of function and procedures. One
# of the procedures must be called main. This is the procedure where the
# evaluation of the program starts.
#
# Most of the procedures are built-in or they are imported from other modules.
# Functions are expressions – they take arguments and return a value. They can
# invoke other functions, but they cannot invoke procedures. The functions
# cannot be recursive.
#
# Basically function are "just" named expressions.
#
# We distinguish two types: number and string. The strings can be formatted.
fun exposureTime(layerNumber: number) -> number:
if layerNumber <= baseLayerCount
then bottomExposure
else baseExposure
# This is an example of a function that returns a layer slice name as a string
fun layerSliceName(layerNumber: number) -> string:
"layerImage_${layerNumber}"
# Procedures are non-recursive subprograms that take arguments and perform
# actions on the machine.
#
# Each line is a single invocation of another procedure. The procedures take
# arguments via name=value. If the value should be computed, it has to be
# enclosed inside the argument evaluation section ${}
proc layerCycle(layerNumber: number):
reportLayerStart layerNumber
moveAbs Z=(${layerHeight * (layerNumber + 1)})
# The retrieve function retrieves a slice image from the program archive.
showPattern pattern=(retrieve (layerSliceName layerNumber))
startExposure
wait (exposureTime layerNumber)
machinePeelCycle
reportLayerEnd layerNumber
# Each program starts with a procedure main:
proc main():
home
moveAbs Z=0
for i in 1..5000:
layerCycle(layerNumber)
moveSafeZ
message "Print completed"
# You might be wondering - why such restrictions? Well, the language is designed
# to be decidable. We can decide if the program halts, we can simulate it and
# never run into an infinite loop. This is essential as we want to make precise
# time estimates and simulations of the printing process.
# To make the language useful, we should define a mandatory procedures for given
# types of machines. An example of such mandatory procedure is, e.g.,
# machinePeelCycle. It is a built-in procedure that peels a layer. Every machine
# has it. Dumb machines will just wait and lift; smart machines will use, e.g.,
# a force sensor to peel. Having the minimal set of required procedures allows
# you to write portable programs. However, if you know that you target a
# specific machine, you can use machine-specific procedures.
# The language is designed to be powerful, hackable and human readable, however,
# it comes at the cost that post-processing tools, such as UVTools, will have
# hard time interpreting the programs and modyfing them. However, the question
# is if using a post-processing is a good path in a long term anyways and if all
# the functionality UVTools offer shouldn't be migrated into a custom
# open-source slicer. |
Beta Was this translation helpful? Give feedback.
-
I tried to find information for the UVJ format, beside the source code of UVtools. I found a brief description at https://github.com/ezrec/uv3dp/tree/master/uvj - it seems as if @ezrec defined the format?
What UVJ is missing is the ability to expose multiple images at the same Z, e.g. multi exposure support, which is helpful when printing calibration pieces in one go to find best print settings for a resin or environmental condition (like temperature).
Gathering Thoughts
I'm in the midst to gather my thoughts on a Open (M)SLA format, something like .SL1 or .UVJ, but with multi-exposure support:
main.gcodewhich describes the entire print process using G-code:G1 Z{lift_distance}the firmware would be still in charge of some settingsM356code alike Marlin'sM355M1200 I"img0001.png"Goals
Pixels vs Vectors
For now I tend to think in terms of pixels per exposure image, but in order to support SLA as well, images could be also vector-based (exterior and interior polygons).
The advantage of vector based images would be to a model slice once, and have it print on different SLA or MSLA machines.
Burden on Firmware/Controller
The simplest is the RLE format to pack pixels, like the CTB or PW* formats do, but each machine needs its own format - the burden on the controller and firmware is minimal, just unpacking pixels for the LCD to expose UV light.
The unpack of PNG exposure images is a bigger task, as it requires
libpngto support the many formats (bw, gray, rgb(a) and packing methods), not sure about runtime RAM requirements involved.To rasterize polygons with holes is no easy task for a microcontroller, the complexity direct relates to required RAM as in data structures and/or stacksize involved.
Which leads to the requirement on the controller, a small Atmel running Marlin vs RPi/SBC which runs Linux, which easily can rasterize vector slices, and those many 32bit ARM controllers in between.
Thoughts, Comments, Links
Constructive thoughts, comments and links to useful resources are appreciated.
Beta Was this translation helpful? Give feedback.
All reactions