Print Unintentionally Scaled Along Z-Axis

[Jack-Castleman]

Currently operating an Elegoo Saturn 3 Ultra. I been trying to set an accurate XY scale and tolerance compensation for a new resin so that I can print some functional parts. Usually, I just set up the print in Chitubox, slice, and write off the .goo file.

For this resin, I wanted to increase the rest time before curing on the bottom layers to combat blooming that I noticed on some of my parts. So, I imported the .goo file, made the edit, and saved the file; however, when I ran the print, the resulting parts were very flat compared to what I was expecting. Upon further inspection, the parts had been scaled along the z-axis (>1:4 scale). I figured that this might have been an error on my part, so I restarted the process and repeated the print but received the same result.

Is there a setting in UV Tools that could be causing this? In UV Tools, the layer height of the top layer matches my expected print height. Is there an issue with import/export of .goo files through UV Tools?

[sn4k3]

Should not. The best way is to print the original file without uvtools so you can confirm if the problem is uvtools or not

[sn4k3]

I compared both files and differences are only the print times, none of the layers have different Z and heights match the layer.

Opening file RESIONE M70_standalone.goo: Done in 0.48s
Opening file RESIONE M70_standalone_UV_Tools.goo: Done in 0.01s
[Global #13]
PrintTime: 2154.92 != 2437.42
MaterialGrams: 17.008501 != 15.453
TemporaryOutputFileFullPath: D:\Tiago\Desktop\RESIONE M70_standalone.goo.tmp != D:\Tiago\Desktop\RESIONE M70_standalone_UV_Tools.goo.tmp
FileFullPath: D:\Tiago\Desktop\RESIONE M70_standalone.goo != D:\Tiago\Desktop\RESIONE M70_standalone_UV_Tools.goo
FileFullPathNoExt: D:\Tiago\Desktop\RESIONE M70_standalone != D:\Tiago\Desktop\RESIONE M70_standalone_UV_Tools
Filename: RESIONE M70_standalone.goo != RESIONE M70_standalone_UV_Tools.goo
FilenameNoExt: RESIONE M70_standalone != RESIONE M70_standalone_UV_Tools
FilenameStripExtensions: RESIONE M70_standalone != RESIONE M70_standalone_UV_Tools
PrintTimeComputed: 2154.92 != 2437.42
PrintTimeHours: 0.6 != 0.68
PrintTimeString: 00h35m != 00h40m
DisplayTotalOffTime: 1407.32 != 1689.82
DisplayTotalOffTimeString: 00h23m27s != 00h28m09s

[Jack-Castleman]

That was something that I noticed and another reason why the problem is so weird. My plan is to try again this week with a resin I have already calibrated.

[Jack-Castleman]

I ran through the same steps as before (increase bottom layer rest after retract time) with a resin that I have already calibrated and does not generally need the rest time to fight blooming. The results were as before. Pictures and files below.

Unmodified:

Modified with UVTools:

Elegoo ABS-Like 2.0 UVTools Test Prints.zip

[sn4k3]

I think the problem is the printer is stop printing earlier...
I compare again the files and the only differences are the wait time on bottom layers AND the use of PerLayerSettings flag. All other bytes match. (5 layers wait time parameters + a flag = Total 6 differences).
As the diferences are so tiny I think the problem is the flag that control where to follow global settings or layer settings, some printers goes bad with it. (Do you have latest firmware?) Recently I saw someone that after the firmware upgrade printer start to ignore some functions.

Here the UVtools file just with the PerLayerSettings flag set to 0.
Elegoo ABS-Like_standalone_02h39m_4ml_GLOBALSETTINGS.zip

Try that, if it print then is printer crappy firmware.
However note that with that set to 0, wait times for bottom layers will be the global ones as it will ignore per layer data.

[Jack-Castleman]

I was able to successfully print the part with the file you provided. This would imply that manipulating any print settings on a layer basis other than bottom and normal will cause a failure, correct? I imagine that this would occur on all of Elegoo's resin printers and not just the Saturn 3 Ultra.

[sn4k3]

I really don't know... Most likely a firmware bug. So far almost all firmwares have flaws and never work to it full potential. The easiest part and also the one that is free to fix is never good on mSLA and are turning full capable printers into lame and basic machines.

You can also make another test, on the file that do the problem render a full encode by drawing a black pixel on black background at any layer. Save file and print. That will force a full encode, rewritting the file with UVtools norms. This because your file was partial saved (only parameters changed) and it's still using your slicer encoder. It should work either way but try the UVtools encoder instead.