[Bug] Most edits cause printer stall or corrupted data on Phrozen Sonic Mini 8K S, *.PRZ

[vinitlee]

System

UVtools v4.0.6 X64
Operative system: Microsoft Windows 10.0.19045 X64
Processor: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
Processor cores: 8
Memory RAM: 16.78 / 31.96 GB
Runtime: win10-x64
Framework: .NET 6.0.25
AvaloniaUI: 11.0.6
OpenCV: 4.8.1

Sreens, resolution, working area, usable area:
1: 2560 x 1440 @ 100% (Primary) (On this)
    WA: 2498 x 1440    UA: 2498 x 1440
2: 1440 x 2560 @ 100%
    WA: 1440 x 2530    UA: 1440 x 2530

Path:       C:\Program Files\UVtools\
Executable: C:\Program Files\UVtools\UVtools.exe
Loaded file: widget_base.prz [Version: 0] [Class: GooFile]

Printer and Slicer

• Printer: Phrozen Sonic Mini 8K S, FW V3218
• Slicer: Lychee Slicer 5.4.300

Description of the bug

Many (but not all) edit operations will cause files to often show a glitched out first layer when printing, but always followed by an error saying "Error! Printing file data exception!".

Things that cause this (not complete list):

• Any Pixel Editor operation
• Pixel arithmetic operations that contain grey values
• Mask operations that contain grey values
• Mask operations with a mask that only contains 0 or 255 and also is applied to a PRZ that does not span entire bed

Things that don't cause this error

• Mask operations with a mask that only contains 0 or 255 and also is applied to a PRZ that spans the entire bed

Attached are two files that show the error in fileExamples.zip. originalFile.prz is the file straight out of the slicer and it prints without error. causesError.prz was made by importing originalFile.prz into UVtools, going into Pixel Editor, adding a 255 white rectangle to a spot that was already fully 255 white, applying, and then saving the file as a PRZ. They seem identical, but causesError.prz renders as a big smear for the first layer and then the print fails during the layer transition.

How to reproduce

1. Generate a PRZ from a slicer
2. Open up in UVtools
3. Go into pixel editor, add a square at grey level 200 in the middle of the first layer
4. Save the PRZ
5. Print in a Mini 8K S

Files

fileExamples.zip

[github-actions[bot]]

This is your first time submitting an issue with UVtools 🥳Please review your issue and ensure that the submit template was followed, the information is complete, and not related to any other open issue. It will be reviewed shortly. Debugging is very important and make the program better. Thanks for contributing and making the software better! 🙌

[sn4k3]

I have review the code and RLE by hand and I conclude that encode/decode of RLE is correct. However, I notice that original file don't make use of the pixel difference in gradients, making each new pixel a 01 sequence instead of a 10, as so, the original file make no use of the red marked strategy:

That's why UVtools open the two files correctly, as it supports all documented compressions of the file format. If printer firmware does not implement the 10 it is incomplete and not following the spec.

UVtools uses 10 compression when sequential pixel difference is <= 15 as stated here:

Your first pixels are: 156 and 162, diff is: 6, which will use 10, but the original just use a new sequence (01) instead of the expected diff

As result of this compression each RLE is smaller. I'm almost certain here that the problem is the printer firmware is not following the Goo spec to the table.

To prove that you can strip antialias from file using UVtools, or use a gradient in wider increments (>15) to not trigger the 10 compression. And report back with your findings.

[vinitlee]

I just ran a few tests. It seems like they're somewhat consistent with your theory, but with some discrepancies.

Test 1: Stripped antialiasing ✔ Test 2: Stripped antialiasing with a first layer dimmed to a max value of 32, still stripped ✔ Test 3: Same stripped file with first layer replaced by a test pattern of adjacent squares of grey values 155, 205, 255 ✔ Test 4: Same as Test 3 plus a square of grey 160 inside the 155 square ✔ Test 5: Same as Test 4 plus horizontal and vertical gradients with around 1 grey level difference between adjacent pixels ❌ Test 6: Pixel pattern containing 0, 155, 205, 255 ❌ Test 7: Pixel pattern containing 0, 155, 160, 205, 255 ❌

Is there any way for me to manually force a file to only use 01 sequences to see if that fixes the issue on a problematic file?

Here are the corresponding PRZ files for the above tests Tests.zip

[sn4k3]

From all that tests, only test 4 run out of my expectation, however the difference is inverse, I have to check the RLE. Test 6 and 7 I expect to fail because aggressive patterns like that generate a large RLE and this machines have no memory to decode it, a known problem along all RLE printers. To revalidate test 6 and 7 you can use same pattern but do it in a 40x40 rectangle.

Is there any way for me to manually force a file to only use 01 sequences to see if that fixes the issue on a problematic file?

No, just by changing code. But I resaved the modified file with the alteration (results in same datasize as original), see if prints: causesError_01.zip

[vinitlee]

I re-ran 6 and 7 constrained to 40x40 rectangles and they now behave as expected. Test 6.1 passes and Test 7.1 fails. And, more importantly, causesError_01.prz works! Seems like good evidence for your theory.

Since this is present on the most up-to-date firmware for this printer, but it's against the spec, would you fold this into UVtool's PRZ export, or would 8K S owners need to find another way around it?

[sn4k3]

Test this file: causesError_10.zip

I improved the 10 compression to not trigger on gradients to 0 and 255. However I don't expect this to fix the current problem. But doesn't hurt to try.

[sn4k3]

I also provide the temporary solution, replace this file on UVtools instalation directory, and it will force 01 compression UVtools.Core.zip

[vinitlee]

causesError_10 does not fix the problem on the printer, as you suspected.

However, the temporary solution does seem to work! I appreciate you sharing it, that's super helpful.

[sn4k3]

This may also be the cause of #776

[sn4k3]

From all that tests, only test 4 run out of my expectation.

As further note Test 4 also did work because gradient compression is limited to stripes up to 255px, and your grey square have a stripe larger than 400px, where 01 compression act instead, as so test 4 does also as expected, if the square were 255px or bellow it would trigger the problem.

[shuhie]

I also provide the temporary solution, replace this file on UVtools instalation directory, and it will force 01 compression UVtools.Core.zip

Should I use this DLL on a Mac with the M3 Max chip?

[sn4k3]

Should I use this DLL on a Mac with the M3 Max chip?

It should work

[shuhie]

Thank you, wanted to ask before I tried it :)

[sn4k3]

Fixed