*Unofficial* 1.22.0-gtj1 Release *Unofficial*
-
@gtj0 reading config from Duet could be a really good idea, but it wouldn't limit the usage of PanelDue with other firmware's.
-
I just created 1.22.0-gtj3
https://github.com/gtjoseph/PanelDueFirmware/releases/tag/v1.22.0-gtj3
Changes since last release:
The ability to remember the active and standby temps when
heaters are turned off is back and controlled by a new
setup option. The default is "off" to be compatible with
the DWC.Fixed an issue where the tool selection button wasn't
cycling through the states correctly.Fixed an issue where the number of macro columns
wasn't taking effect until a panel reset -
@gtj0 Look like everything works fine for me :D.
-
@gtj0 the firmware number also changes on the display to 1.22 or not because I used it but remains at 1.21.3 release. stand
-
@dragonn said in *Unofficial* 1.22.0-gtj1 Release *Unofficial*:
BTW. do you have plans to fix/add option to select with fan is controlled with PanelDue? My part cooling fan is connected to number 3 and not one :P. Would be nice to allow user selecting witch fan is controlled by PanelDue.
@dragonn Is your part cooling fan assigned to a tool? If so, I could make the fan control automatically use the fan assigned to the active tool.
@dc42 The output from M408 S3 just prints the integer equivalent of the fan bitmap instead of outputting a json array like the axis map. It's no big deal to work with the bitmap but would there be heartburn with backwards compatibility if I gave you a pull request to print the array instead of the bitmap?
-
M408 S3 produces the same output as HTML request rr_status with type=1 so it can't be changed without breaking DWC. Besides, the status response is already rather long and I don't want to lengthen it unnecessarily.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 said in *Unofficial* 1.22.0-gtj1 Release *Unofficial*:
M408 S3 produces the same output as HTML request rr_status with type=1 so it can't be changed without breaking DWC. Besides, the status response is already rather long and I don't want to lengthen it unnecessarily.
OK, no worries. Using the bitmap is easy enough.
-
@gtj0 said in *Unofficial* 1.22.0-gtj1 Release *Unofficial*:
@dragonn Is your part cooling fan assigned to a tool? If so, I could make the fan control automatically use the fan assigned to the active tool.
Yes, it it. Would be a nice solution if this could work this way.
-
I played around with this on a dual extruder machine (converted flashforge creator pro) and ended up going back to the "official" release. I was using the version "2" (which included the setup option for toggling sticky temps.)
The problem was that the paneldue seemed to frequently lose track of the state of the duet, so I'd see tools showing as active (that weren't) or inactive (that were), etc. The temp set points would also get out of sync: the paneldue would show a target temp very different than what the duet (and DWC) would show. (This was with both sticky temps on and off. I more frequently used it with sticky temps turned off, as it's much less confusing when the set points on the paneldue match the set points in DWC.)
I could usually "fix" the issue by hitting the reset button on the paneldue (or unplugging it and plugging it back in.) After the paneldue rebooted, it'd get the correct information. (At least until my next print finished.) I'd frequently find myself having to reset my paneldue while preparing for a print because the LCD was showing me incorrect information. I'd see a "target temperature" of 190 (which I might use to load filament) and watch the actual current temp go somewhere completely different (because the info shown on the paneldue was incorrect or perhaps it was still trying to display a sticky temp?)
As for the sticky temps, I think the DWC does it CORRECTLY and that the design of this change is confusing. A "control panel" for any device should reflect the current state of that device. In terms of temperature, it reflects the CURRENT temperature and the CURRENT TARGET temperature. The "sticky temp" this paneldue firmware adds creates a fuzzy "could be the target temperature, but might not be at the moment" value.
Perhaps it'd be better if, instead of changing the "CURRENT TARGET" temperature to show that sticky temp (when it's not actually the current target), you could add an element to the UI when a person goes to change the current target temp: the last used temp appears as an option as well as the existing -5, -1, SET, +1, +5 buttons.
In that case, I'd suggest using two rows. The top row would have two values: "0" and "n" (where n is the last used temp.) The second row would contain the existing temp buttons. Something like (please pardon the formatting):
[ 0 ] [ 240 ]
[-5] [-1] [SET] [+1] [+5]If something like that is done, it might be slightly cleaner to present it with the "SET" button between the two temperature presets (0 and 240 above), making the +/- buttons slightly larger:
[ 0 ] [ SET ] [ 240 ]
[ -5 ] [ -1 ] [ +1 ] [ +5 ] -
Thanks for the feedback!
I struggled with this but the lack of positive states and the ability to simply change a heater state without changing its set points in RRF is a little frustrating. Ideally the panel should show the exact state of the controller but that currently makes the user interface a little "sub-optimal". Let me see if I can do something like what you suggest. Maybe "Last Set Point" or something.
As for getting out of sync, I'm going to try and work on that this weekend.
