SOLVED [ PanelDue Firmware 3.4.0-pre4] M291 issue
-
We observed an issue with M291 that we hadn't seen until updating the firmware to 3.4-pre4 on firmware 3.4b5. It's strange, but repeatable..
If you create a macro with the following code, the message will not display on the PanelDue until after the user clicks OK/Cancel in DWC. The PanelDue just reads "Busy". After clicking OK/Cancel in DWC, the prompt is displayed on the PanelDue.
if boards[0].vIn.current > 23 M291 S3 R"Test" P"Testing"This is vital to our power toggle routine as you now can't turn of a machine from the PanelDue. If you need more info, let us know. I am hoping this is easy to reproduce.
Thanks
-
Hey @oozeBot, I took your script and changed the if condition so it evaluates always true and with that change i couldn't reproduce the issue.
Does it always happen? Are there any further pre-conditions to setup?
Visit me on github at https://github.com/mfs12/
-
Topic has been marked as a question
mfs12
-
@mfs12 I think we've figured this out - with this build, there is at least a 5 second delay in displaying the M291 messages on the PanelDue. During this time, the PanelDue just reads 'Busy'. I can't say it's all M291 messages, but it definitely is happening with the above snippet..
I also forgot to mention this is a 6HC with attached SBC.
So what I initially reported was wrong, but there does seem to be an issue as that delay is long enough where it feels as if it's not working.
-
@oozeBot, can you share your configuration and a detailed step by step procedure. I need also to know how you reach the state busy? So prerequisites are important as well.
Visit me on github at https://github.com/mfs12/
-
@mfs12 I had a chance to revisit this and think I better understand what is happening. This delay does not happen after a fresh reboot. It is only happening after running "M999 A1". This command is used to soft-reset the PanelDue, which is needed as part of our Power Toggle routine, but no longer seems to work in this latest build.
@wilriker had recently added this around 3.2.
It's this "M999 A1" command that is killing our macro. And once recovered, the PanelDue seems sluggish until reset.
As I mentioned, soft-resetting the PanelDue is very important to us. Please let us know how we can assist further in helping make it functional again. Thanks!
-
@oozeBot, please describe your process in detail step by step so i can try to reproduce it. Thanks a lot.
Here's a template how a clean bug report could look like.
Description
Please add a brief description of your bug here.
Versions
Please add a list of products and software versions involved.
Process
Please add a step by step description on how to reproduce the bug.
Experienced Result
Please describe experienced result.
Expected Result
Please describe the expected result.
Visit me on github at https://github.com/mfs12/
-
So the machine I have been testing on has an issue that can't yet be explained. I just tested 4 other machines - all running 3.4b5 - and none of them have issues. For some reason, this machine will not accept M999 (or M999 A1) in a macro - it just goes into a busy state and stays that way. However, M999 works just fine from the console..
So this does not appear to be a PanelDue issue. Thanks and sorry for the false alarm.
-
Topic has been marked as solved
oozeBot
-
This issue has been solved.. thankfully. It was caused by an old version of DuetPiManagementPlugin that was installed. Once removed, M999 is now processing inside macros.
-
@oozebot thanks for reporting the fix!
