Octoprint: PSU Control no longer works in 1.3.11rc2

[burgedm]

PSU Control was working perfectly fine with 1.3.10 but when I upgraded to 1.3.11rc1 and then rc2 it no longer automatically turns off my printer.

The log file has an entry "Idle timeout reached after 5 minute(s). Turning heaters off prior to shutting off PSU" but it does not actually turn off the printer.

Nothing else is logged in the octopi logs or in the OS logs.

I'll reiterate that things were working perfectly fine until the upgrade - that's all that has changed.

[GitIssueBot]

Hi @burgedm,

It looks like there is some information missing from your bug report that will be needed in order to solve the problem. Read the Contribution Guidelines which will provide you with a template to fill out here so that your bug report is ready to be investigated (I promise I'll go away then too!).

If you did not intend to report a bug but wanted to request a feature or brain storm about some kind of development, please take special note of the title format to use as described in the Contribution Guidelines.

Please do not abuse the bug tracker as a support forum - that can be found at discourse.octoprint.org. Go there for any kind of issues with network connectivity, webcam functionality, printer detection or any other kind of such support requests or general questions.

Also make sure you are at the right place - this is the bug tracker of the official version of OctoPrint, not the Raspberry Pi image OctoPi nor any unbundled third party OctoPrint plugins or unofficial versions. Make sure too that you have read through the Frequently Asked Questions and searched the existing tickets for your problem - try multiple search terms please.

I'm marking this one now as needing some more information. Please understand that if you do not provide that information within the next two weeks (until 2019-04-21 21:40 UTC) I'll close this ticket so it doesn't clutter the bug tracker. This is nothing personal, so please just be considerate and help the maintainers solve this problem quickly by following the guidelines linked above. Remember, the less time the devs have to spend running after information on tickets, the more time they have to actually solve problems and add awesome new features. Thank you!

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being, so don't expect any replies from me :) Your ticket is read by humans too, I'm just not one of them.

[tedder]

Please share your octoprint.log, from startup (plugin loading) through where you trigger the PSU control. You might need to increase your log level if you believe there's truly nothing in there.

[burgedm]

Sure, once I get home.

I had it at debug level yesterday and there is no sign the octopi attempts to execute the command to power off the power supply.

--
David Burgess
Senior Systems Specialist
Flight Information Services Automation

[phone]

From: Ted Timmons [mailto:[email protected]]
Sent: Sunday, April 7, 2019 19:35
To: foosel/OctoPrint [e-mail]
Cc: Burgess, Dave [e-mail]; Mention [e-mail]
Subject: Re: [foosel/OctoPrint] PSU Control no longer works in 1.3.11rc2 (#3112)

Please share your octoprint.log, from startup (plugin loading) through where you trigger the PSU control. You might need to increase your log level if you believe there's truly nothing in there.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/foosel/OctoPrint/issues/3112#issuecomment-480642637, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AtihbrNuIbeNXff02SYPIOEvnWbJMBh-ks5veoC9gaJpZM4cg8_s.

---

This electronic message, as well as any transmitted files included in the electronic message, may contain privileged or confidential information and is intended solely for the use of the individual(s) or entity to which it is addressed. If you have received this electronic message in error please notify the sender immediately and delete the electronic message. Any unauthorized copying, disclosure or distribution of the electronic message is strictly forbidden. NAV CANADA accepts no liability for any damage caused by any virus and/or other malicious code transmitted by this electronic communication.

Le présent message électronique et tout fichier qui peut y être joint peuvent contenir des renseignements privilégiés ou confidentiels destinés à l’usage exclusif des personnes ou des organismes à qui ils s’adressent. Si vous avez reçu ce message électronique par erreur, veuillez en informer l’expéditeur immédiatement et supprimez le. Toute reproduction, divulgation ou distribution du présent message électronique est strictement interdite. NAV CANADA n’assume aucune responsabilité en cas de dommage causé par tout virus ou autre programme malveillant transmis par ce message électronique.

[foosel]

I need all the data requested in the ticket template, otherwise I can't look into this. Also pinging @kantlivelong who's the author of the affected plugin.

[burgedm]

Here's the log file, at 2019-04-09 00:45:50,849 the PSU is commanded ON, it's currently configured to turn OFF after two minutes of inactivity.

octoprint.log

[tedder]

So PSU Control is turning it on properly. That works- as confirmed by the serial connection 5 seconds later. And after a few seconds we can see the polling:

2019-04-09 00:46:11,599 - octoprint.plugins.psucontrol - DEBUG - Sensing system command executed. PID=22587, Command=/home/pi/.octoprint/scripts/power-toggle.sh
2019-04-09 00:46:11,701 - octoprint.plugins.psucontrol - DEBUG - Sensing system command returned: 0
2019-04-09 00:46:11,702 - octoprint.plugins.psucontrol - DEBUG - isPSUOn: True
2019-04-09 00:46:16,738 - octoprint.plugins.psucontrol - DEBUG - Sensing system command executed. PID=22591, Command=/home/pi/.octoprint/scripts/power-toggle.sh

I think it goes to the plugin author at this point.

[kantlivelong]

Hmm, will have a look. Trying to get my test env up but having issues.

[foosel]

@kantlivelong I think it might be this sentry issue. What I don't understand is why that didn't happen earlier because the target could always be None as far as I know.

edit to add more details:

Looks like the offending heater is chamber, which is newly introduced in 1.3.11. I'll take a look into why it appears to be initialized differently from the tool and bed heaters after all.

[foosel]

Dug a bit deeper and you have the same issue with printers that do not report a bed temperature. target (and actual) can and will stay None in these cases.

A simple None check of both actual and target here would make sense and solve it.

I'm a bit reluctant to modify OctoPrint here to default to 0 instead of None because a) that will change OctoPrint's behaviour compared to prior versions and b) it will no longer allow to distinguish between "value reported by firmware" and "no value reported by firmware".

[kantlivelong]

Thanks @foosel !

Tested out good here. Merged and released 0.1.8.

[foosel]

Perfect, closing this then.

[burgedm]

Uh guys ...

The firmware is reporting the temperatures just fine.
It displays on the "Temperature Pane" gives me a proper graph, it displays in the NavBar plugin, it displays on the video stream from my camera when I'm in full screen and as I reported at the beginning ... it works fine with the previous version of Octopi (1.3.10).

[foosel]

1.3.11 introduces parsing of chamber temperatures. The temperature data handed from OctoPrint to plugins thus contains an entry for a chamber heater. If your firmware doesn't report chamber data said data will be None though. And that is what the PSU Control's heater routine could not handle, neither for bed nor for chamber entries.

So unless you are telling me that you have a heated chamber configured in your firmware and thus data for T, B and C in your M105 outputs - this is the bug.

Of course, if you had fully filled out a ticket template as instructed in several places and even provided with during creation of a ticket, you'd also have shared a serial.log and we could have more easily verified this. As things are now we have to rely on reading code and running assumptions based on that, and your report combined with what's in the code and what's changed in 1.3.11 heavily points at the missing handling of None entries in the temperature data in the PSU Control plugin's auto shutdown code to be the culprit.

Please update the plugin and test. If it's still broken we can reevaluate this.

PS: I'm not a guy.

[burgedm]

Now you're just being an ass so ... I'm done.

[kantlivelong]

Perfect! If there's an issue be sure to open it up in the appropriate repo and fill out all required info.