Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Thumbnail generation not parsed by PrusaLink #475

Open
2 tasks done
pjvenda opened this issue Jan 10, 2024 · 6 comments · May be fixed by prusa3d/Prusa-Firmware-Buddy#3954
Open
2 tasks done

Thumbnail generation not parsed by PrusaLink #475

pjvenda opened this issue Jan 10, 2024 · 6 comments · May be fixed by prusa3d/Prusa-Firmware-Buddy#3954
Labels
MINI/+/MK4/XL Relates to Buddy printer

Comments

@pjvenda
Copy link

pjvenda commented Jan 10, 2024

Description of the bug

I am using PrusaSlicer 2.7.1 on the default mk4/IS printer profile and I am finding the thumbnails for the slices I generate are not being interpreted. By PrusaLink. I cannot be sure it was rendered on the printer's screen, I'll have to check on the next print. (PrusaConnect can parse the thumbnail correctly).

Screenshot from 2024-01-10 10-36-33

This is a single colour print, using the 'Generic PETG' profile output to a text gcode file.

I had a look through the gcode and compared a couple of files, one with thumbnails that render and one with thumbnails that do not render. The similarities are that thumbnails exist on both files. The differences are that the ones that work were generated by PrusaSlicer 2.7.0 and have one less tn format:

Screenshot from 2024-01-10 09-40-40

PrusaSlicer 2.7.0 - thumbnails render correctly:

$ cat Temperature-Tower_220-265_0.4n_0.2mm_PETG_MK4IS_1h39m.gcode | grep -i thumbnail 
; thumbnail_QOI begin 16x16 644 
; thumbnail_QOI end 
; thumbnail_QOI begin 313x173 57800 
; thumbnail_QOI end 
; thumbnail_QOI begin 440x240 94000 
; thumbnail_QOI end 
; thumbnail begin 640x480 162688 
; thumbnail end 
; thumbnails = 16x16/QOI, 313x173/QOI, 440x240/QOI, 640x480/PNG 
; thumbnails_format = PNG

PrusaSlicer 2.7.1 - thumbnails not rendering

$ cat Temp_Tower_PETG_0.4n_0.2mm_PETG_MK4IS_1h59m.gcode | grep -i thumbnail 
; thumbnail_QOI begin 16x16 752 
; thumbnail_QOI end 
; thumbnail_QOI begin 313x173 57992 
; thumbnail_QOI end 
; thumbnail_QOI begin 440x240 94964 
; thumbnail_QOI end 
; thumbnail_QOI begin 480x240 101120 
; thumbnail_QOI end 
; thumbnail begin 640x480 165328 
; thumbnail end 
; thumbnails = 16x16/QOI, 313x173/QOI, 440x240/QOI, 480x240/QOI, 640x480/PNG 
; thumbnails_format = PNG

Notice the latter has 5 thumbnail images in different resolutions, whereas the former (the one that works) has 4 - it is missing 480x240/QOI. But this does not appear to be the problem, because I removed this thumbnail from the gcode, changed the thumbnails = line and re-uploaded to PrusaLink; It still does not render.

Project file & How to reproduce

  • Slice a .stl file using the default prusa mk4 IS profile under prusaslicer 2.7.1
    • use single colour filament, generic PETG filament profile, output to ASCII gcode file
  • Import into printer's SD card
  • View in prusaLink -> thumbnail does not render

Checklist of files included above

  • Project file
  • Screenshot

Version of PrusaSlicer

2.7.1+linux-x64-GTK3-202312121425

Operating system

Linux Debian 12

Printer model

Prusa mk4 IS

@pjvenda
Copy link
Author

pjvenda commented Jan 11, 2024

gcode file with thumbnail not rendering attached for reference

Temp_Tower_PETG_0.4n_0.2mm_PETG_MK4IS_1h59m.zip

@pjvenda
Copy link
Author

pjvenda commented Jan 11, 2024

The generated thumbnails that don't render on PrusaLink do render on the printer's screen.

@rtyr rtyr transferred this issue from prusa3d/PrusaSlicer Jan 15, 2024
@ondratu ondratu added the MINI/+/MK4/XL Relates to Buddy printer label Jan 15, 2024
@dunkmann00
Copy link
Contributor

I'm seeing this same problem as well.

@pjvenda
Copy link
Author

pjvenda commented Jan 27, 2024

I have experienced that .bgcode is not affected.

@dunkmann00
Copy link
Contributor

I was just playing around with it myself, and if you move the PNG thumbnail from the last one in the list to the first, the image loads correctly in PrusaLink.

So when I change G-code thumbnails from this:
16x16/QOI, 313x173/QOI, 440x240/QOI, 480x240/QOI, 640x480/PNG (which is the PS default for my MK4)

to this:
640x480/PNG, 16x16/QOI, 313x173/QOI, 440x240/QOI, 480x240/QOI

the image loads.

@dunkmann00
Copy link
Contributor

I think the problem is actually in Prusa-Firmware-Buddy, since its the printer that is returning nothing to the PrusaLink client.

Digging through the code, the problem starts here:

https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/89985d82a48a41cf16732a2fa85c4855dc9ef637/lib/WUI/nhttp/gcode_preview.cpp#L56

And then AFAICT depending on if you have a binary g-code or a regular g-code file a different code path is followed (PlainGcodeReader::stream_thumbnail_start or PrusaPackGcodeReader::stream_thumbnail_start). This would be why the behavior is different depending which format is used.

As to why it works when moving the PNG thumbnail to the front of the list; it looks like there is a limit to the number of lines searched for a PNG thumbnail here:

https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/89985d82a48a41cf16732a2fa85c4855dc9ef637/src/common/gcode/gcode_reader.cpp#L152

So I guess someone will need to determine what they feel is the best way to evaluate the regular g-code for thumbnails. If the Prusa devs are okay with just increasing MAX_SEARCH_LINES I'd be happy to submit a PR for that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
MINI/+/MK4/XL Relates to Buddy printer
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants