PanelDue Firmware 3.5.0-rc6 released

OwenD

@Exerqtor
I have run some tests with the files you uploaded.
The difference I see is that you are using Prusa Slicer.
By default it includes the bed image in the thumbnail. There doesn't seem to be an option to turn it off.
I am using SuperSlicer.
I had it set NOT to include the bed in the thumbnail.
If I set it to include the bed and generate the400x400 image first, then the thumbnail does not display.
This tells me that with the bed included, the thumbnail is likely larger than the amount that PD is parsing to find it.

These two files are the same except in one the bed is included and in the other it is not.

test-superslicer-with-bed.gcode
test-superslicer.gcode

mfs12

@Exerqtor did you update RRF as well. As @dc42 mentioned there was a second problem with RRF thumbnail parsing. I am not sure if this fix already available.

Exerqtor

@mfs12 I'm on 3.5b3+ atm, i don't think it's an newer version thats publicly avalible yet? 🤔

dc42

@Exerqtor said in PanelDue Firmware 3.5.0-rc6 released:

3.5b3+

Please provide the GCode file concerned so that I can test it before we release 3.5beta4.

mfs12

@dc42 this are the testfiles from @Exerqtor

https://mega.nz/folder/1VcgnA7A#3FFCNqOrY9yk6ODI-c6ABQ

OwenD

@dc42 @mfs12

It seems to be related to the detail of the thumbnail.
A thumbnail with 400x400 and 160x160 values of this works as expected on PD

; thumbnail_QOI begin 400x400 86248
; thumbnail_QOI begin 160x160 19260

The 400x400 started on line 15 and finished on 1122
The 160 x 160 started on line 1126 and finished on line 1374

Whereas this will not display on PD

; thumbnail_QOI begin 400x400 89288
; thumbnail_QOI begin 160x160 19600

The 400x400 started on line 15 and finished on 1161
The 160 x 160 started on line 1126 and finished on line 1418

To test it I placed a cylinder on the slicer bed. 10 x 10 x 10
Then right click and select "fill bed with instances"
You can then play with the height of the cylinder (instance 1) until you find the tipping point.

As I noted above, Prusa Slicer by defaults includes the image of the bed as part of the thumbnail, so it's got more detail.
In super slicer you can turn that off so you're only dealing with the print objects.

All files display properly in DWC
I also tried reversing the order the thumbnails were generated and the results remained the same.

EDIT
After some further testing, the tipping point for my test can be seen in these two files.
At 9.56mm high the file works.
At 9.58mm high it doesn't display in PD

remove the .txt from the end
test 9-58.zip.txt

dc42

@OwenD which version of RRF are you using?

OwenD

@dc42 said in PanelDue Firmware 3.5.0-rc6 released:

@OwenD which version of RRF are you using?

@dc42 I'm running
RRF 3.5.0b3+

dc42

@OwenD both those files work for me (thumbnail is displayed on PanelDue) using a slightly more recent build of RRF than 3.5beta4, with the 3.5.0-rc6 PanelDue firmware. However, the second thumbnails finish on lines 1376 and 1381, and the 160x160 come before the 400x400, which is not what you said in your post. Did you post the wrong files?

OwenD

@dc42 said in PanelDue Firmware 3.5.0-rc6 released:

Did you post the wrong files?

When I did the original post I had the 400x00 first.
When I did all the extra testing I tried 160x160 first.
I failed to edit the line numbers.
However I've just realised in amongst all the different tests I must have flashed the wrong version onto PD so that testing to find the "tipping point" is invalid
With RC6 both those files work.
However if you check these files, you should find that the one with 160x160 first works and the one with 400x400 first doesn't display on PD

EDIT
Every file I've tested that had the160x160 thumbnail first works fine, so I'm not really seeing it as a bug. I don't think it's unreasonable to specify the order.

test-superslicer-with-bed-400-160.zip.txt

test-superslicer-with-bed-160-400.zip.txt

ComedianTF2

Testing out Paneldue firmware 3.5.0-rc6 (paneldue 7i) in combination with RepRapFirmware 3.5.0-beta.4 (on a Duet 2 WiFi) is giving a weird issue, in that after a certain amount of time, the paneldue stops responding to any kind of inputs on the LCD. I can still see updates coming from the display like temperature changes and homing status, but touching the screen does nothing.

Unplugging and re-plugging in the cable makes it work again temporarily, but after a bit of time (around a minute or so), it stops working again.

It doesn't seem to be linked to the screensaver, I have the screensaver at 120 seconds, and it stops working before the screensaver kicks in

Rolling back to 3.4.1 on the paneldue seems to fix the problem

droftarts

@ComedianTF2 Thanks for your report, @mfs12 may have to have a look at this. Are these Duet3D or clone boards? Please can you check the wiring connections are all good. Are you using the ribbon cable or 4-wire cable?

Ian

ComedianTF2

@droftarts These are official Duet boards, wiring connections are all good. Using a long ribbon cable, have not tested it out using the 4 pin cable

With the 3.4.1 firmware there are no problems at all