-
Notifications
You must be signed in to change notification settings - Fork 113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PSU idle timer ignores non-Marlin (Klipper) g-codes and shuts down when not idle!! #172
Comments
logs? |
haven't enabled DEBUG for this as wasn't expecting these commands to be ignored.
I was running though the klipper style commands during this. The idle timer is set for 25 mins and probably G28 will not be classed as idle so probably ran G28 at 14:10:49 and everything else was Klipper macros and commands... |
Going to need full logs. May as well include serial logs. |
Serial logs not enabled nor is general DEBUG, just DEBUG on plugin and the full log is the same as above except I chopped of the repeated isPSUon and some of the heartbeats every 15 mins, otherwise, that was all she wrote... |
octoprint.log with octoprint DEBUG and plugin DEBUG and idle timer set to 2 mins
serial.log
|
@kantlivelong What Information are you still Awaiting? |
The octoprint.log is not complete. It lacks startup info or even a rollover notice thus it's a snippet. This ticket so far consisted of a painful attempt at getting logs when none were provided to begin with. Enable serial logs. Wipe the logs. Restart OctoPrint. Re-create issue. UPLOAD logs. |
sorry that only including relevant logs caused you such pain :D |
Not all that familiar with Klipper but I'd imagine the macros(or non-gcode commands) are mostly used outside of normal printing (with exception of tool changes maybe?). #166 once merged/released should fix that. For now you should be able to workaround by using a longer idle timeout as 2 minutes is pretty short (For instance Z probing can take 2+ minutes) |
Lol, I set the timeout to 2 mins just to reproduce the issue quicker. Was 25 mins when I first encountered this! |
What PSU control option causes the plugin to send the postPowerOn command(s) when printing?
I implemented the above mentioned fix to recognise klipper commands, don't know if this is related |
Is this a separate issue? If so, open a new ticket with logs. |
This should be fixed with 23a88bb in devel. |
v1.0.0 released. |
What were you doing?
DELTA_CALIBRATE METHOD=manual
after going thru 6 of the 7 points, manually adjusting the z-height with TESTZ command and then moving on to next point with ACCEPT command
What did you expect to happen?
complete the calibration steps and SAVE_CONFIG
What happened instead?
the PSU Plugin decided what I was doing was not worthy of staying powered on for and abruptly shut-off, losing all of the operations and data captured up to that point.
Version of OctoPrint-PSUControl
PSU Control (0.1.11)
Operating System running OctoPrint
Raspbian GNU/Linux 8.0 (jessie)
Printer model & used firmware incl. version
Delta / SKR1.3 / raspi2b / ATX PSU
Link to octoprint.log with octoprnt.plugins.psucontrol set to DEBUG
added below, FULL octoprint.log with DEBUG enabled on octoprint AND the plugin. plus serial.log of the entire conversation
serial.log
octoprint.log
Wiring diagram
NA
The text was updated successfully, but these errors were encountered: