Panel Due with RRF 3.0 issue

A Former User

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.

MrSteve920

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.

smoki3

@MrSteve920
Sounds exactly as my problem

dc42

@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.

smoki3

@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

dc42

@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.

MrSteve920

@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.

smoki3

@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

mloidl

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

MrSteve920

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?

dc42

Thanks for reminding me about this. I can see why the behaviour has changed, and I will fix it in 3.01-RC2.

dc42

This should be fixed in the RRF3 internal build at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0.

MrSteve920

@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.

Damien

I know this is an old post but I am having similar problems with Paneldue 7i. The panel was working fine, even after I updated my Duet 2 Maestro board to 3.1.1. I decided to update the firmware in the paneldue and now its stuck on "connecting" and none of the buttons work.(i.e. Nothing happens).

Any suggestions?

A Former User

@Damien said in Panel Due with RRF 3.0 issue:

Any suggestions?

read the https://github.com/Duet3D/RepRapFirmware/blob/v3-dev/WHATS_NEW_RRF3.md#reprapfirmware-310 before upgrading.

All PanelDue users: the PanelDue connector (or IO_0 on Duet 3) is no longer dedicated to PanelDue, therefore if you connect a PanelDue to this port you must use the following command in config.g to enable it: M575 P1 S1 B57600. You can use baud rates other than 57600, however the IAP files all assume 57600 baud; therefore if you use another baud rate then PanelDue will not display firmware update progress.