PanelDueFirmware 3.2.4 released

wilriker

@Karabox said in PanelDueFirmware 3.2.4 released:

on the last sale bought fystec paneldue 5i (clone), updated it to 3.2.4. Installed and turned on the power. I was very surprised to change the color palette from RGB to BGR. Is this a display issue or a firmware feature?

It seems that fsytec is not using the exact same display as the Duet PanelDue 5i and thus the display driver will not match.

You could try to use the PanelDue-v3-5.0.bin instead. It might work since it uses a slightly different display driver.

But note that for clones there is no support.

zapta

@wilriker, the web interface shows slicer based time estimation. Are these estimations also visible in the latest version of paneldue?

In general they are the most accurate and most linear among the estimations provided by the web interface.

Extra points: allows the user to disable all but the slicer based information. All we need is just one good estimation.

Karabox

@wilriker said in PanelDueFirmware 3.2.4 released:

You could try to use the PanelDue-v3-5.0.bin instead. It might work since it uses a slightly different display driver.

But note that for clones there is no support.

You were right, the firmware came up, the red color is in place. Thank you very much!

wilriker

@zapta The slicer based estimate is a feature of DWC and thus not accessible by PanelDue that is connected to RepRapFirmware.

will future firmwares have a command to switch baud rate to 115200 for users still running 57600 or will the new default be 115200 with appropriate change to the reprap config tool?

zapta

@wilriker, do you know how the web interface does it? Do they read the gcode file independently? Do they track the execution of the progress gcode markers embedded in the gcode file?

Would be great this slicer estimation and progress marker be tracked by the Duet natively. This estimation is more accurate and makes all the other time estimations obsolete.

(I have a post processing script that among other things, propagate the slicer time markers to paneldue, displaying hours and minutes left in the standby temp fields of nozzle and bed respectively. It's very accurate but hackish).

dc42

@bearer said in PanelDueFirmware 3.2.4 released:

will future firmwares have a command to switch baud rate to 115200 for users still running 57600 or will the new default be 115200 with appropriate change to the reprap config tool?

No. When you send M997 S4 to flash the PanelDue, the baud rate is automatically changed temporarily to 115200.

wilriker

@zapta I don't know off hand how DWC get's the slicer estimate but it will simply start a countdown based on this number when the print is started. Nothing more fancy. This will be off in the first couple of minutes because it will count along the heat-up time but this will even out eventually the longer the print runs.

@dc42 said in PanelDueFirmware 3.2.4 released:

@bearer said in PanelDueFirmware 3.2.4 released:

will future firmwares have a command to switch baud rate to 115200 for users still running 57600 or will the new default be 115200 with appropriate change to the reprap config tool?

No. When you send M997 S4 to flash the PanelDue, the baud rate is automatically changed temporarily to 115200.

so when using the default 57600 M997 S4 should switch both the Duet and the PanelDue to 115200, and erase/reset as needed? (it didn't, but when set to 115200 it did (erase and reset automagically))

zapta

@wilriker, yes, it seems to fetch and use various print metadata such as estimated total print time.

https://github.com/Duet3D/DuetWebControl/blob/master/src/components/lists/JobFileList.vue#L202

https://github.com/Duet3D/DuetWebControl/blob/master/src/components/panels/JobEstimationsPanel.vue#L41

Would be cleaner and more accurate for duet to track the M73 progress markers and provide the estimation time and percentage to all UIs. That's what most printers do.

oozeBot

Has it been reported that the PanelDue appears to be refreshing (blinking) much more often with this release? I’ve not been able to put my finger on what’s triggering it, but it’s new to 3.2.4 or maybe 3.2.3..

@oozeBot said in PanelDueFirmware 3.2.4 released:

appears to be refreshing (blinking) much more often with this release?

yes, i think i share that sentiment

Exerqtor

@oozeBot said in PanelDueFirmware 3.2.4 released:

Has it been reported that the PanelDue appears to be refreshing (blinking) much more often with this release? I’ve not been able to put my finger on what’s triggering it, but it’s new to 3.2.4 or maybe 3.2.3..

I secound that, started happening with 3.2.3 at least.

wilriker

@bearer said in PanelDueFirmware 3.2.4 released:

so when using the default 57600 M997 S4 should switch both the Duet and the PanelDue to 115200, and erase/reset as needed? (it didn't, but when set to 115200 it did (erase and reset automagically))

The flashing procedure will

send the command to erase-and-reset with the currently configured baud rate (this only has effect if PanelDueFirmware is already 3.2.2 or newer)
It waits one second for the PanelDue to comply - this will then start the Bootloader which is hard-coded to 115200 baud
If Duet board is currently set to something other than 115200 it will change that
bossa code is executed on Duet to flash the PanelDue
After the reset at the end PanelDue will boot and restore the previously configured baud rate
If the Duet baud rate was changed above this will be undone at the end before handing control back to the user

wilriker

@oozeBot said in PanelDueFirmware 3.2.4 released:

Has it been reported that the PanelDue appears to be refreshing (blinking) much more often with this release? I’ve not been able to put my finger on what’s triggering it, but it’s new to 3.2.4 or maybe 3.2.3..

Yes, that was a change introduced in 3.2.3. It will update twice as often than before. If it encounters too many errors related to too frequent status requests it will dynamically slow down request rate until it sees stable responses again.

Also changed in that version was a significant speed up of the initialization phase.

Also @bearer and @Exerqtor

@wilriker said in PanelDueFirmware 3.2.4 released:

The flashing procedure will

send the command to erase-and-reset with the currently configured baud rate (this only has effect of PanelDueFirmware is already 3.2.2 or newer)

On the 7i i have here this is not the case; or it might well send the command but the only way I could update was to either press erase myself or set the baud rate to 115200 for both the Duet and the PanelDue before issuing M997 S4. Both with the previous beta, and again with 3.2.4 trying to reflash itself to 3.2.4.

Update: Just tried a (less than genuine) v3 4.3" and it does erase but not reset with 57600 baud, however with 115200 baud it erases and resets. Will try the (genuine) 7i again later and report back.

BoA

@wilriker I thing that @bearer ment display elements re-drawing, not refreshing the values. Something like during initialization phase, but also later.

https://www.youtube.com/watch?v=gs-aTMfqvMY

wilriker

@bearer said in PanelDueFirmware 3.2.4 released:

Update: Just tried a (less than genuine) v3 4.3" and it does erase but not reset with 57600 baud, however with 115200 baud it erases and resets. Will try the (genuine) 7i again later and report back.

I don't understand why that would be related to baud rate since RRF just sends a specific text and PanelDueFirmware reacts to that in its own application logic.
Nevertheless I will investigate.

@wilriker did another 5 flashes at each baud rate; 7i seems to only occasionally not erase; but consistently does not reset when on 57600. 115200 is all good. I can try to dig out logic analyzer to log the serial traffic later if of interest.

But as long as its not the intended behaviour I'm less confused:)

gloomyandy

My (genuine) 7i also does not seem to reset after a flash (it always seems to erase and program ok). I'm running the 7i at 57600 and have not (yet) tried changing that to 115200 (will do so later if it helps). FYI I'm running this on the LPC version of RRF and had assumed the lack of reset was down to some problem with my port of the code, but perhaps that is not the case?