Panel Due with RRF 3.0 issue
-
I am using the Panel Due 7 inch on my Duet 2 WiFi and RRF3.
I recognize that the temperatures and coordinates freezing after a while of printing. Then I am not able to control the temperatures or sent any macro. The Screen is still responding but the duet does not accept these commands.The only button which is working is the emergency stop.
A reboot fixes the issue but after some times it happens again.
-
@smoki3 mine froze on me at least once but powering off fixed it and i'll see if it occurs again.
-
Be sure your Panel is on the latest available firmware release.
-
@Danal it is
-
Does pressing the Reset button on the PanelDue always fix it immediately? When it stops displaying temperature changes, are you still able to switch between the 4 pages?
-
@dc42 said in Panel Due with RRF 3.0 issue:
Does pressing the Reset button on the PanelDue always fix it immediately? When it stops displaying temperature changes, are you still able to switch between the 4 pages?
Yes it is possible to switch between the pages.
Have to try it with the reset button -
@dc42 said in Panel Due with RRF 3.0 issue:
Does pressing the Reset button on the PanelDue always fix it immediately? When it stops displaying temperature changes, are you still able to switch between the 4 pages?
I tested today after another freeze with the reset button of the duet.
The PanelDue is not able to connect again with the duet2. It stays with "connecting" until I reset the duet2. But the Emergency stop button is working.
-
unrelated; but maybe helpfull troublehooting tip for PanelDue? Could help point to Panel, wire, or Duet 2 Wifi.
@dc42 said in Maestro will not communicate to display:My guess it that it's the cable. If you connect a PC running YAT or Pronterface etc. to the Duet via USB and send M111 S1 P3, then every command received by the Duet will be echoed to USB. If the Duet is receiving data from the 5i then you should see "aux: M408" lines regularly.
-
I'm seeing a similar issue as well with the Panel Due on RRF3. I have not experienced the display of temperature or coordinates freezing on its own. When I go to the control page and click a macro to run, the display stops updating and the macro is never run. The display isn't actually frozen l, but no variable readings are being updated.
If given enough time though (around 15 minutes roughly), the display does seem to unfreeze/reconnect to the duet and any macros that I wanted to run get performed. Resetting the panel due does not immediately fix the problem as the display doesn't reconnect to the duet.
This wasn't a problem on 2.04 and it's not a problem when a print isn't running. Panel Due is on latest firmware.
-
@MrSteve920
Sounds exactly as my problem -
@MrSteve920 said in Panel Due with RRF 3.0 issue:
When I go to the control page and click a macro to run, the display stops updating and the macro is never run.
Please provide your config.g file and a sample macro file for which this occurs. If possible, also please confirm whether it still happens using the 3.01beta1 release.
-
@dc42 said in Panel Due with RRF 3.0 issue:
@MrSteve920 said in Panel Due with RRF 3.0 issue:
When I go to the control page and click a macro to run, the display stops updating and the macro is never run.
Please provide your config.g file and a sample macro file for which this occurs. If possible, also please confirm whether it still happens using the 3.01beta1 release.
I think you got it wrong: If the temperatures and coordinates are already frozen then it is not possible to run any macro or something else.
So its not related to any macro. The problem is more or less that the connection between the duet and panel due is broken
-
@smoki3 said in Panel Due with RRF 3.0 issue:
@dc42 said in Panel Due with RRF 3.0 issue:
@MrSteve920 said in Panel Due with RRF 3.0 issue:
When I go to the control page and click a macro to run, the display stops updating and the macro is never run.
Please provide your config.g file and a sample macro file for which this occurs. If possible, also please confirm whether it still happens using the 3.01beta1 release.
I think you got it wrong: If the temperatures and coordinates are already frozen then it is not possible to run any macro or something else.
So its not related to any macro. The problem is more or less that the connection between the duet and panel due is broken
That's not what @MrSteve920 said:
I have not experienced the display of temperature or coordinates freezing on its own. When I go to the control page and click a macro to run, the display stops updating and the macro is never run.
-
@dc42 Requested files attached:
config.g
1_Lights Off.g
Config.g has been configured to account for the changes from release 3.0 to pre-release 3.01 beta 1, but I can't see how that would make a difference.Again to reiterate, I am not seeing any freezing on the temperature/coordinates prior to pressing a macro button on the panel. Also just for full disclosure, running these macros over the web interface causes absolutely no issues and it does seem to happen regardless of what macro I try to run (I've been using my overhead lights off macro as a test case).
Tested this issue against 3.01 beta 1 and the issue is still present on that pre-release build.
-
@MrSteve920 Now I got what you mean. I also noticed that especially when you are printing and you call a macro for example "led off.g" then it has few minutes delay until it is executed. Thats also really wired
-
Seems since v3 macro execution started from PanelDue is queued until a non printing move is done. At least this is what i have observed so far.
For large print (especially the first layer), it may take a long time until the macro is executed.This happens to me when i try to switch On/Off my lights with the macros on the PanelDue. When executed from DWC it is executed after some moves, as with RRF 2.0.5.
I will post my config later, since i currently have no access to it.
Edit:
Here are my config files. 1_Licht_ein.g and 2_Licht_aus.g are the macros mentioned in the post.personal_config.g
estop_enable.g
estop_disable.g
config.g
2_Licht_aus.g
1_Licht_ein.g -
Is this something that will be resolved in the future or is this just going to stay the way it is because of some changes that were made in reprap 3?
-
Thanks for reminding me about this. I can see why the behaviour has changed, and I will fix it in 3.01-RC2.
-
This should be fixed in the RRF3 internal build at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0.
-
@dc42 Not a problem! Thanks for being so responsive as always. In the end, this is a pretty minor bug but it will be nice to have this working properly again.