Software reset not starting up



  • For some reason, software reboots (M999) don't seem to do a working reboot anymore. The machine clearly resets in some way, but it never seems to manage to actually start up again. I can hear my thermostatic fan starting and keep running permanently instead of briefly until the firmware takes over and I can't reach my Duet on the network. Powercycling it manually works fine. I saw this happening the first time yesterday, after I updated to the 1.15d firmware, and now it happens every time.

    Any ideas? Thanks!


  • administrators

    I just tried M999 from both the web interface and PanelDue, with firmware 1.15d, and it works for me. The thermostatic fan turns on for about half a second before the firmware turns it off again.

    Does anyone else have this problem?



  • Reset works for me, but i've to reset the panel to refresh information otherwise it stay at last state.
    I also have weird movements when the duet is not connected to a network while hard reset on board.


  • administrators

    @cubexupgrade:

    Reset works for me, but i've to reset the panel to refresh information otherwise it stay at last state.

    Which PanelDue firmware are you running? If it's 1.14 or earlier, you may find that 1.15beta fixes that.

    @cubexupgrade:

    I also have weird movements when the duet is not connected to a network while hard reset on board.

    Are you using a pre-production Duet WiFi? If so, that is a known issue, which we fixed on the production boards.



  • Fwiw, after updating to 1.15d, then only a brief delay was released 1.15e, which I accordingly did update my DuetWiFi board to successfully. The thing that I am noticing and have yet to discover the "why" is that, for example, if I write a change to config.g via the web interface and am prompted to reset in order to affect changes, thereafter, instead of quickly being up and running again I've been experiencing LONG time periods where I cannot get the board back online. A power cycling fixes the issue immediately, but even the Paneldue v1.1 is showing "reconnecting…" during these long waits for the board to become reachable once again. Any ideas?


  • administrators

    Have you tried replacing the SD card?



  • @jrlederer:

    Fwiw, after updating to 1.15d, then only a brief delay was released 1.15e, which I accordingly did update my DuetWiFi board to successfully. The thing that I am noticing and have yet to discover the "why" is that, for example, if I write a change to config.g via the web interface and am prompted to reset in order to affect changes, thereafter, instead of quickly being up and running again I've been experiencing LONG time periods where I cannot get the board back online. A power cycling fixes the issue immediately, but even the Paneldue v1.1 is showing "reconnecting…" during these long waits for the board to become reachable once again. Any ideas?

    I don't like resetting the Duet (I only have 0.8.5 in operation, btw) when I make changes to the config.g. It takes too long, as you say, even on a good day. David has made this suggestion recently, and it's a good one: simply execute the gcode commands that you are adding to your config.g, save the config.g, and no need to reset. You will have the new values in case you DO reset, but you will also have the new values without resetting. I have been doing it this way for some time, and it is super convenient.


  • administrators

    Another way is to send:

    M98 Pconfig.g



  • That is infinitely better! I wonder why the web interface wants to reset rather than execute config.g?



  • Just running config.g again obviously doesn't reset previously set values to their defaults if they're not in config.g anymore, which a reset does. So resetting does make sure the state reflects only config.g and nothing else that might have been set previously.


  • administrators

    There are a few differences between running config.g as a macro compared with when it runs at startup. For example, network related commands such as setting IP address won't work (they don't work yet on the Duet WiFi anyway), also a T0 command will behave differently. So restarting is safer, and it normally takes only a couple of seconds.



  • All very good points to consider. Thanks.



  • Also also, if you have a bogus setting (typo, say) in your config.g, you don't find out until you execute it from a fresh start. If that's right away you probably remember what you changed. If that's some days later you may have no idea why your machine suddenly stopped working.



  • This is a good point too. When I'm calibrating or doing something that requires me to make frequent small changes, I make the changes to config.g, and then copy and paste the entire gcode line directly from what is in the file, so if there is any typo I am affected right away, as well as when I reset. I don't like resetting, especially if the heaters are at temp, because then I have to wait for them to stabilize again, as well as for the web interface to reconnect etc etc.



  • This is all very useful and interesting information, but the reason I mentioned it was to determine whether others had similar behavior, and foremost to see whether this is to be expected or if it's an unwanted side effect that needs addressing. Thanks, though, for the tips ; I very well may alter my habits wrt resetting in the future based on the points brought up in this thread.

    Jonathan


Locked
 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.