PanelDueFirmware 3.2.4 released
-
@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).
-
@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.
-
@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)) -
@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
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.
-
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
-
@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.
-
@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
-
@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.
-
@wilriker I thing that @bearer ment display elements re-drawing, not refreshing the values. Something like during initialization phase, but also later.
-
@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:)
-
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?
-
My v3 non-integrated PanelDue configured for 57600 baud does erase and then flash successfully, but never resets after flashing.
-
I think I found the reason why it did not Erase-and-Reset in the beginning and/or reset at the end for some users. Currently testing.
-
@wilriker poke me if you want me to test on my troublesome hardware, genuine and not so genuine (don't think that makes a difference in this case?)
edit: wilriker seems to have fixed in latest rrf 3.02-dev on git
-
@Karabox said in PanelDueFirmware 3.2.4 released:
@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!
I cannot get my fysetc unit to connect now thative upgraded the duet rrf3 fw...
tried the v3-5.0 bin but to no avail ... jsut sits there "connecting" no use ... not communicating with the duet. cant see the files or move the axis ...
was working pretty well before....
-
Did u actually get your fysetc paneldue workign with the other variant of fw - and comunicating the the duet - or just the color changes work? I got hte different colors and the lcd functions on the usb - but it cant seem to connect to the duet on rrf 3.2-beta4