[Bug] Unwanted lifting during printing

[Tirolin46]

System

UVtools v5.0.8 X64
Operative system: Microsoft Windows 10.0.19045 X64
Graphic card: 
Processor: Intel(R) Core(TM) i5-8500 CPU @ 3.00GHz
Processor cores: 6
Memory RAM: 7.38 / 15.84 GB
Runtime: win-x64
Framework: .NET 9.0.2
AvaloniaUI: 11.2.5
OpenCV: 4.10.0

Path:       C:\Program Files\UVtools\
Executable: C:\Program Files\UVtools\UVtools.exe

Printer and Slicer

• Printer: Uniformation GKtwo
• Slicer: Chitubox Pro v2.0.8

Description of the bug

The problem is when I set zero lift height trough a certain layer range the printer will preform a lifting action with LiftHeight2 and RetractHeight2 before the layer that have a true lifting action.

Example: I have a file that contains 20 layers. I set the parameters to skip lifting actions between 10 and 15 layers. The 16th layer has the true lifting action. During the printing after the exposure of 15th layer it happened a lifting action (only with LiftHeight2 and RetractHeight2 with the corresponding speed). After the 16th layer exposure it happened the two staged lifting action (performed the LiftHeight1 and LiftHeight2 also RetractHeight1 and RetractHeight2 with the corresponding speeds).

I checked the file and look no lifting action on 15th layer but the printer did like I described.

If I only set LiftingHeight1 and RetractHeight1 (LiftHeight2 = 0 and RetractHeight2 = 0) the printer work like I expected, but without a two staged lifting.

What I expect:
Lifting action only happen on the layer where it is setted.

How to reproduce

1. Load any sliced Chitubox file (encrypted .ctb)
2. Edit printing parameters corresponding to the above mentioned way
3. Convert to -> Chitubox -> Chitubox CTB (encrypted)
4. Start the printing without vat and platform (for testing only)

Files

https://we.tl/t-tfa11oe38B

[github-actions]

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'm amazed that disable lift even work... Almost no printer (beside gcode ones) can change layer without a lift (Hard code in firmware), that's why UVtools uses 0.1mm as "disable lift".

During the printing after the exposure of 15th layer it happened a lifting action (only with LiftHeight2 and RetractHeight2 with the corresponding speed).

Is the LiftHeight2 and RetractHeight2 = 0 for those layers?

The attached file doesn't match the description of your printing file "I have a file that contains 20 layers."

[Tirolin46]

I am also surprised that it's work without any lift (this is why I try it first without the vat and platform). The example that I described in the issue is for that better understand the problem, not related to the files that I provided (sorry for that. In the feature I will take more attention).

In relation with the provided files:

XPfinder - unwanted lifting.ctb:
From layer index 0 to 4 is bottom layer -> no problem
From layer index 5 to 12 have same Z position (0.3 mm) -> In UVtool: at layer index 11 no lifting is set, but in reality the printer preform a lifting action with LiftHeight2 and RetractHeight2. At layer index 12 the printer preform a normal two staged lifting action with LifthHeight1-2 and RetractHeight1-2.

The printer repeat the unwanted lifting action before every layer index that has true lifting action:
unwanted lifting at: 19, 27, 35 etc.
wanted lifting at: 20, 27, 36 etc.

XPfinder - NO unwanted lifting.ctb:
From layer index 0 to 4 is bottom layer -> no problem
From layer index 5 to 12 have same Z position (0.3 mm) -> no problem because I set the LiftHeight2 and RetractHeight2 to zero and in this case not happening any lift action at layer index 11, 19, 27 etc., but the preformed lifting action is have only one stage LiftHeight1 and RetractHeight1 (of course :) )

[sn4k3]

By looking at files and following your description, everything is well set on layer table, this is not a issue caused by UVtools.
I have no clue why it does that before the real lift layer. We might never know as we don't have access at firmware to peek.
As you have the printer you can do some experiments to try to find what can trigger that, for example, you can try set where lift is 0mm also set all speeds to 0.
However, this is not really an issue, and it's already incredibly lucky to be able to skip some lifts.

[Tirolin46]

Are you checking like open the file with UVtools or open directly the .ctb files and look their contents? When I reopened the exported [(encrypted) .ctb] file with UVtool, my experience was the same as yours, the layer table was correct.
My thoughts, during the exportation (or conversion) the program put the information in wrong order, but only in a specific case.
Why I think this? Because this unwanted lifting phenomenon happen only in a one specific case.
If the firmware in the printer is doing the phenomenon, it need to be happen on every layer that has a non zero value of LiftHeight2 and RetractHeight2, but not the case. (If I only set LiftHeight2 and RetractHeight2 to zero on that layer (12, 20, 28, etc.) where need a true lifting action and keep the original values everywhere else (5-11, 13-19, 21-27, etc.), the printer also work as I expected)
Is there any way to check directly the .ctb file? (I tried it, but I'm not found any information about file structure.)
What are you think about my thoughts?

[sn4k3]

I checked with UVtools, Inspecting the file directly will show same valus as UVtools, you can use 010 Editor and my templates to debug the file.

[Tirolin46]

This is a really good tool, I don't know why I haven't heard of it before! Where I can find your template?

EDITED!

Okay, I found it!