WebUI reporting the incorrect information from the printer

[Jax-The-Fox]

Description
Now that I have Mariner set up (thank you for patching for Trixie <3), and have been printing with it for a few days, I have noticed an issue with the webUI. The current layer, elapsed and remaining times do not report correctly. I would assume this is an issue with my printer specifically. I am using an Elegoo Saturn S with the newest firmware. This issue happens for me on every file that I have attempted to print. The print itself works fine, and finishes normally, it's just the UI that has the issue.

Reproduction Steps
Steps to reproduce the behavior:

1. Upload File to Mariner
2. Start Print with Mariner
3. See incorrect information in the webUI

Expected Behavior
WebUI showing the correct current layer and remaining time reported over the serial connection on the printer.

Screenshots / Logs

Details:

• Mariner 2 Version: 0.5.3
• Printer Model: Elegoo Saturn S
• Raspberry Pi Model: RPi Zero 2 W

Additional context
Both of the attached images were taken at the exact same time. The 'Layer 175' that the webUI reports has not changed for the duration of the print, which is around 25 minutes at the time of posting this.

[amd989]

Hey, glad to hear installation is working now!

Yes, so it appears that even within the same company the firmware behaves differently. I've been dealing with this problem as well, but I guess in fixing it for my printer, I broke it for the rest. Hard to test because I only have access to one.

If you don't mind providing me with the DEBUG logs for a print, I would appreciate it a lot. It would give me a better idea what is your printer returning when we interrogate for status. You can do so by starting a print (you don't have to use resin) after changing the log level to DEBUG.

For this you have to modify the config under /etc/mariner/config.toml

mariner/config.toml

Line 17 in 30dffc2

log_level = "INFO"

Set it to DEBUG

Then restart the service

sudo systemctl restart mariner3d.service

If you are SSHing to the printer just run

sudo journalctl -u mariner3d.service -f

Then use mariner to start the print. Leave it running for a few layers so that we can observe the pattern.

Copy the log to a text file and upload it here please.

The output should tell us what the printer responds, and we should be able to extrapolate how it works for your firmware.

[frittna]

Hi all,

I was able to fix it. With copilot.
I became a great fan of mariner2 so i decided to make some improvements, in particulair for the use with my Pi camera (CSI serial camera) and my Mars 3 with a Pi-Zero 2 (Trixie 64-bit)

I ran into the same issue with the current layer calculation. Jumps after a few layers, stalls or resumes ramdomly.

My last steps after implementing the timelapse feature in my fork was fixing this bug with copilot.
Now it is stable and not jumping or hanging even with thousands of layers etc.. I can hit pause and resume, all fine.

I am not very professional in coding by myself but i can show you what AI was telling about the cause of your layer bug below.
Look it up in the code of my fork and compare it to your code. (api.py..) Maybe i will make a more usable release of mine soon so that others can use it too without tweaking the PI so much)

-> If you have a camera or if you are interested, i did a vibe-coding marathon to make a really cool "Mariner 2 Cam-Timelapse" release for my Zero2 Pi and Mars 3 printer on top of this wonderful Mariner2 Code from amd989.
It has many small improvements for better user experience and gives more feedback and on top you can stream video and make a timelapse of the print.
infos on: ### https://github.com/frittna/mariner2-cam-timelapse

hope i can help, greets

Comment from Copilot:
"Layer Progress Bug (stuck after a few layers) — analysis and fix
Branch / commit
Fixed on branch mariner2cam-timelapse in commit dadf7a4.

This commit includes:

Layer-detection unstuck fix
Resume-action unblock fix
Observed problem
With this CTB file:

layer_height = 0.05
layer_count = 1869
Layer display starts correctly (1 → 2 → 3 → … → 6), then gets stuck at layer 6 while printing continues.

From logs:

D current/total keeps increasing (so printer is progressing),
but UI layer remains fixed (z_layer=6, same progress value).
Root cause
The Z-based layer estimator had a jump guard (reject jumps > +1 layer).
That guard prevents false jumps from lift/retract positions (good), but it also caused a freeze case:

If one valid exposure-layer Z sample is missed,
next valid sample may appear as +2 (or more) relative to cached _last_z_layer,
jump guard rejects it,
function returned cached _last_z_layer,
UI remained pinned to old layer.
So the system could get stuck on an old Z layer even though byte progress (D) clearly moved on.

Fix in api.py
In _layer_from_z_position(...), invalid/unsafe Z samples now return None (instead of returning cached last layer).
That includes:

invalid Z (None, <= 0),
non-exposure tolerance miss,
out-of-range layer index,
jump-guard rejection (> last + 1).
When None is returned, existing fallback logic is used:

_layer_from_byte_offset(current_byte, end_byte_offset_by_layer)
This allows progress to continue via byte-offset mapping instead of freezing at stale Z-derived layer.

Why this is safer
Z remains preferred when trustworthy.
Retract/lift artifacts still don’t cause huge false jumps.
If Z is ambiguous, byte-offset fallback prevents display lock-up."

greetings!