PSU not turning off after idle time

[andrewsil1]

Installed recently for the first time. Manual control of the PSU from the icon works fine, but after waiting the configured 5 idle minutes, (and much longer), the PSU is not being shut off. The default of ignoring M105 is enabled, and that’s the only traffic I see in the monitor other than a lot of “wait” responses and the returned temp info.

I am running Repetier firmware. Any other info you’d like me to provide, or suggestions on fixing?

[andrewsil1]

Oh also, I’m just using m80/m81 commands and internal state control, I.e. no hardware connection to the printer or PSU other than the usb serial line.

[kantlivelong]

Perhaps similar to #27?

If not please provide DEBUG logs and serial logs.

[andrewsil1]

I'm not quite sure why, but the idle timer is now working. Does the idle timer implementation rely in any way on the string set for temperature command ignoring in the Octoprint terminal filter window? The reason I ask is that the terminal window was not previously filtering out the returned temp commands because repetier formats them like this:
Recv: T:18.45 /0 B:17.83 /0 B@:0 @:0
which doesn't match the default filtering regex. I changed it to a slightly more brute force regex of "Recv: T:*" and then the terminal filtering started working and possibly coincidentally, at the same time the idle timer for PSUControl seemed to start functioning as well.

The only remaining problem I have is that PSUControl starts up assuming that the PSU is off, when actually the PSU turns on automatically when Octoprint establishes the connection. This means that I have click the icon once manually in order to get it in sync every time the server restarts. I suppose I could fix this with a GPIO pin, but it'd be a lot simpler if there was a way to configure PSU control to assume that the printer is on when the connection is established.

[andrewsil1]

Ok, I thought it was working, but it’s not. It works when the printer hasn’t been heated up yet. After a print, it doesn’t work, even though it’s cooled down sufficiently.

The debug log contains this interesting snippet where t looks like it’s going to shut off but then doesn’t:

octoprint.plugins.psucontrol - DEBUG - isPSUOn: True 2017-10-14 23:02:28,437 - octoprint.plugins.psucontrol - INFO - Idle timeout reached after 5 minute(s). Turning heaters off prior to shutting off PSU. 2017-10-14 23:02:28,440 - octoprint.plugins.psucontrol - DEBUG - Heater bed already off. 2017-10-14 23:02:28,442 - octoprint.plugins.psucontrol - DEBUG - Heater tool1 already off. 2017-10-14 23:02:28,445 - octoprint.plugins.psucontrol - DEBUG - Heater tool0 already off. 2017-10-14 23:02:31,079 - octoprint.plugins.psucontrol - DEBUG - isPSUOn: True 2017-10-14 23:02:36,088 - octoprint.plugins.psucontrol - DEBUG - isPSUOn: True 2017-10-14 23:02:41,097 - octoprint.plugins.psucontrol - DEBUG - isPSUOn: True 2017-10-14 23:02:46,109 - octoprint.plugins.psucontrol - DEBUG - isPSUOn: True 2017-10-14

[kantlivelong]

The connection is considered idle when no commands (minus excludes) are sent to the printer after X minutes. Filters are client side only and have no affect on the internals of the plugin. The internal sensing is very basic so I would suggest using command or GPIO. You can even just use a command that reads your switching GPIO pin status if you'd like

Please send full logs with the issue occurring. (Use something like pastebin)

[andrewsil1]

OK, finally captured logs of this occurring.
Octoprint log here: https://pastebin.com/dl/KX5PQhLy
You can see at 05:08:55 the attempt to power down heaters, discovers they're already off, then doesn't bother turning off the ATX. Is this expected?

Serial log here: (too big for pastebin, crashing the browser...)
serial.log

[kantlivelong]

Interesting...

I see the log mentioning a bed, tool0, and tool1 but in the wait responses I see T:190.35 /120 B:54.50 /0 B@:0 @:0.

Are you using multiple hotends or multiple beds?

[andrewsil1]

Neither. Must be a repetier bug...?

[kantlivelong]

Can you check your printer profile in OctoPrint? There is an option to define the number of extruders and I suspect you have it set to 2 when it should be 1.

[andrewsil1]

Yes, I’ll have a look and report back. Thanks-

[andrewsil1]

Nope, it’s set to 1. On the other hand, the printer firmware is auto reporting temps (support for which I think is a new feature within the latest Octoprint), so it seems to me like the reporting of a non-existent bed would be Repetier’s fault (or of the configuration used to generate it.)

[kantlivelong]

Spoke with another developer and it looks like B@:0 @:0 is power information and not temps.

Kind of confused on why it would think there are 2 tools when you only have 1 set but I'm thinking that that is the issue here.

[andrewsil1]

Oh, right it does report the current output power for both the head and the bed in the 0-255 range. I’ll dig into the firmware configuration source and see if it’s accidentally set to 2 extenders even though this is supposed to be the single head version of the firmware.

[andrewsil1]

Oh wait, there’s two powers reported: one head, one bed. So which bit do you think is indicating two extruders?

[kantlivelong]

Within OctoPrint itself you can define how many extruders you have ( https://imgur.com/a/vQAB0 ). That is my only idea at this point without adding additional debug info and having you retest.

[kantlivelong]

I also just noticed a line in the serial log referencing tool1. Wonder if calling that is making OctoPrint think that there is a tool1.

2017-10-24 05:03:55,034 - Send: N142866 M104 T1 S0*31

[andrewsil1]

I’ll check the scripts in the slicer to see whether that’s being included inappropriately for some reason. There is definitely only one head defined in Octoprint, per your previous message. I do think the temp reporting format is correct – one head, one bed, plus one power level for each (the bed is using PWM, not bangbang.)

[kantlivelong]

I've replicated the issue by sending the M104 T1 S0 command to a printer with only one tool. Should be a simple fix on my side but first I am going to work with the developers of OctoPrint to see if it is a bug there.

[andrewsil1]

FYI, I found that T104 T1 S0 was uncommented in the Felix Simplify3D profile for the end-of-print script (where all the other instances of T1 are commented out in the single head version of the profile), so that explains where the random use of T1 is coming from. I’m commenting it out manually and will test again.

[kantlivelong]

I've created a PR in OctoPrint core for this. See OctoPrint#2182

[kantlivelong]

Closing as the PR has been merged. Should be available in OctoPrint 1.3.6