PanelDue Firmware 3.3.0-rc2 released

mfs12

@dc42 said in PanelDue Firmware 3.3.0-rc2 released:

@mfs12, where does PanelDue get that figure from?

It is set if either M36 "simulatedTime" or M409 K"job" with entry job:file:simulatedTime is received.
If it shall be be continuously updated it depends on interpretation of "job duration" which is not handled so far.

dc42

@mfs12 it might make more sense for me to change RRF to return the remaining time calculated from simulation, then PanelDue can use that directly.

garyd9

@dc42 said in PanelDue Firmware 3.3.0-rc2 released:

@mfs12 it might make more sense for me to change RRF to return the remaining time calculated from simulation, then PanelDue can use that directly.

If you're going to change RRF, wouldn't it be better to add a "simulatedTimeRemaining" instead of changing the definition of something already existing?

mfs12

@dc42 i am fine with any solution. But my preferred solution would be having just one incrementing counter (duration) and three constant values (file, slicer, simulated). This would make the code very simple, require no changes on RRF side and allow most interpretation. Eventually displaying a percentage value "duration / simulatedTime" as well and not only the passed time.

mloidl

The current fields in the object model should not be changed, since they are fine and logical.
Simulated time is a static attribute of a file like file size, file name, .... both in M36 and in the M409 K"job" response (note: it's in the file structure => job:file:simulatedTime).

Best would be to extend the timesRemaining struct by adding a simulation field. This would not change the current behavior for backward compatibility but let RRF calculate the remaining time based on the simulated times as it is already done with the slicer time.

mfs12

@mloidl said in PanelDue Firmware 3.3.0-rc2 released:

Best would be to extend the timesRemaining struct by adding a simulation field. This would not change the current behavior for backward compatibility but let RRF calculate the remaining time based on the simulated times as it is already done with the slicer time.

I don't think this is necessary, as we got all values already and the calculation is trivial.

mloidl

@mfs12 said in PanelDue Firmware 3.3.0-rc2 released:

slicer

Just saw your answer after pressing submit.
Your suggestion would be fine, but since slicerTime (job:timesLeft:slicer) is not a constant value this would lead to RRF changes too.

Edit:
I think i'm wrong. printTime in M36's response seems to be the slicer time, so it would be possible.

DaveA

I just tried to update the PanelDue using M997 S4 and it fails with an error that it can't fine file 'PanelDueFirmware.bin. I downloaded the github file PanelDueFirmware-3.3.0-rc2-v3-7.0.bin into the firmware directory and renamed it to PanelDueFirmware.bin. I know I had
done this successfully before updating to 3.3 probably during one of the 3.2 RCs.

If I look at the file in the firmware directory and right click on the file and select install it updated just fine.

Any ideas?

Phaedrux

@davea As a test can you move that PanelDueFirmware.bin file into the system tab and then send M997 S4 again? Perhaps it's still looking in the sys folder.

dc42

@garyd9 said in PanelDue Firmware 3.3.0-rc2 released:

If you're going to change RRF, wouldn't it be better to add a "simulatedTimeRemaining" instead of changing the definition of something already existing?

That was exactly what I had in mind.

mfs12

@davea said in PanelDue Firmware 3.3.0-rc2 released:

I just tried to update the PanelDue using M997 S4 and it fails with an error that it can't fine file 'PanelDueFirmware.bin. I downloaded the github file PanelDueFirmware-3.3.0-rc2-v3-7.0.bin into the firmware directory and renamed it to PanelDueFirmware.bin. I know I had

@dc42 i had a look into this issue, and can confirm this doesn't work reliable. What is the timeout to wait for the PanelDue until RRF gives up communicating with the PanelDue's bootloader?

mfs12

@DaveA which firmware and hardware versions are you running?

Since version RRF 3.3 you need to put the files into the "firmware" folder. Renaming is also essential as you already did although you can pass the filename to use as a parameter as well. Please check gcode documentation for further details. Double check you didn't misspell the name.

David and me tested different hardware setups and could reliably do updates.

But be careful don't connect the usb connector of your PanelDue this prevents updates!!!

DaveA

Well I found my issue but I'm not sure how I did it. There was, indeed, a typo in the PanelDueFirmware.bin. Somehow I managed to get a leading space or some unprintable character before the P. I can't reproduce adding a leading space as both RRF and Windows will remove a leading space. I didn't notice it in the DWC but when I looked at the card in Windows the filename was shifted one position right.

Sorry for the false alarm.

mfs12

@davea , thanks for the feedback.

fotomas

Since this is a RC2 it is probably not the time asking for new features. But this is more of an adjustment ...

Move the extrusion window a bit lower so the extruder temp can be seen while manually extruding.

mfs12

Hey @fotomas, can you create a seperate thread for this feature request, please?

oliof

@davea ctrl-shift-space will insert a "nonbreaking space" character which will be hard to see and mess with your head. Maybe that happened.

OwenD

I'm note sure if this is related to this release, or if it's only that I have only just noticed.

It seems that if the PanelDue screensaver activates during a long loop, touching the screen doesn't wake it up afterwards, despite popups like M291 working during the macro loop (whilst the screen saver is active).

KipK

@owend I was about to post the same issue. Happened yesterday, after a filament runout pause, the panel due was locked on screen saver. Couldn't wake it.

mfs12

@OwenD @KipK thanks for reporting the issue. I will try to reproduce it.

So what i understand the process is:

wait until screen saver is activated
then trigger a message M291 to display

And you expect that it should wake up in such a case? Did you realize different behavior with previous versions?

BTW i agree it would be definitely handy if the screen gets activated and shows the message to the user.