Hi all,
I've recently gotten TP-Link Smart Plug up and running on my machine (Ender 3 Pro) but I'm noticing what I suspect is a very odd behavior. The plug connects via Octoprint and can be toggled on and off from the menu.
HOWEVER, when I turn the plug/machine on via Octoprint and begin a new print, the Z-axis motor is loud and stutters and the Y-axis Gantry slams in the forward and continues running trying to throw the plate from the machine. All is solved with a hard power down on Raspberry Pi, but I know this can't be the intended behavior.
Appreciate any help.
My Setup: Ender 3 Pro with RspPi 3b+, SKR E3 Mini & TFT35 (simulation mode)
Can you provide FRESH log files with the issue occurring? Include serial log as well.
Yeah, my plugin doesn't do anything relative to motion, it literally just communicates with the plug itself and monitor for gcode commands internally. This sounds like it's unrelated to the plugin.
Sure, I just pulled these. I've run sent one print via Octoprint and run a leveling gcode off directly off the machine since.
Admittedly, I'm not sure at all what I'm looking at here, so in the timeline, I installed the Shutdown Printer plug in, tested it (which shut the machine off). I turned it on via Octoprint and then it happened. It happened yesterday before I had the Shutdown Printer plug in installed so I don't believe that the case.octoprint - short.log (433.8 KB) serial.log (148 Bytes)
I believe my time is set up wrong (different issue I need to address) but I condensed the print log, which should be from the most recent successful print, to me installing Shutdown Printer, to testing it and turning it back on with Octoprint, sending another print and then the problem happening, the reset and the beginning of the next print.
That's why I was so confused. Im connected to the wall via a power strip, the printer is plugged into the smart outlet, and the Pi directly into the power strip so that it runs when the printer is powered off.
I have no issues with it plugged into the smart home other than this.
I'm terrified to test it, because of the potential damage to the machine, but I can attempt to plug it straight into the wall and see if I can duplicate it like that, I'm not sure if the power strip could have anything to do with it, but its all I can think of. I guess that and turning it on via the App and seeing if the same thing happens.
Have you tried without any other plugins enabled? I see errors from spaghetti detective, and possibly detailed progress on startup. BTW, you need to enable serial.log and restart octoprint for that file to be of any good use.
I wouldn't think having them plugged into a power strip would cause this, but I'm curious if you were using the power strip prior? I have seen posts here on the forum of weird things happening relative to being plugged into the same circuit as a refrigerator and weird things happening when the freezer's compressor would kick in.
I realized that I didn't have serial log enabled after I posted it and was going to run another print to log it but did some trouble shooting on my own first. The Spegetti Errors are because I'm still waiting for my ribbon cable to show up. Yes, the powering situation was always the same. To put this into words, the Z motor is always silent. Under this circumstance, its a loud "ERNNTT" with a vibration.
So I ran these combinations without running a power cycle on the Pi and every time, using the motion options on the printer I was able to test and recreate the motor issue:
- Off: Octoprint / On: Octoprint
- Off: Octoprint / On: Kasa
- Off: Kasa / On: Octoprint
- Off: Kasa / On: Kasa
Then I powered the Pi and and cycling the power, the motor was silent and moved as expected:
So to me that screamed that there's something going to as a result of the Pi being connected (and because it was happening outside Octoprint (Kasa On/Off) it's not issue with your plug in. One of the things I wanted to do was to cover the 5v prong on the USB between the printer and the Pi, so because rebooting the Pi fixed the issue, I figured what better time than now.
So I covered the 5v prong on the USB so that the screen powers down when the printer shuts off and isn't being powered by the Pi. I ran these combinations without running a power cycle on the Pi and every time, the printer functioned flawlessly:
- Off: Octoprint / On: Octoprint
- Off: Octoprint / On: Kasa
- Off: Kasa / On: Octoprint
- Off: Kasa / On: Kasa
So in short, there was something going on with machine when the display was being continuously powered by the Pi and the smartplug was being used. By stopping the Pi from powering the screen and allowing the printer to fully shutdown, I seem to have solved (at least from a practical sense) the issue.
In other words, "when my Pi tries to power the printer's controller board and it tries to home the axes there's not enough current for the steppers and it makes a weird sound".
Buy something like an IKEA KOPPLA three-outlet power strip, plug this into the TP-LInk, plug your Pi's power adapter and the printer's power brick into the KOPPLA. They all come up together. They all go out together.
Not exactly, the in other words would more accurately be something like "When my printer power cycles (on>off>on) and the Pi stays connected and powering the board, the steppers freak out (which may be the result of not receiving enough power) and ignore limits and try to push the extruder/bed past zero".
I all of this was happening was happening after the smart plug was turned back off after the shutdown command was sent (while the Pi was still connected and sending power to the TFT35). Stopping the Pi from powering the board seems to have solved the problem. Yes, I could simply move the smart plug to the front of the power strip, but I want to leave the Pi running when the printer shuts down.