What is the problem?
When using octoprint, seemly randomly (at the beginning of a print only) the printer will do its homing, leveling and then go into corner, not move and extrude.
I tested with four prints and it has happened every time. If I restart I bet it will fix it but I would like to keep this reproducible state so hopefully we can solve this issue.
What did you already try to solve it?
I posted this question prior. I was told it might be electrical interference so I went through great lengths to address this. I isolated the power supply/ssr from the main board (BTT SKR Mini E3 v2) and the Pi (3B+). Everything was placed in its own box and I used copper tape on all walls of all boxes. The machine is isolated in its own aluminum lined enclosure. I got a new extremely short usb cable with a ferrite magnet and wrapped the cable with copper.
I also upgraded the power supply to the official pi one and have had 0 issues with undervoltage.
octoprint (4).log (456.7 KB)
There was four attempts at printing that all did the same error. I canceled the prints. I did not restart octoprint or the machine (ender 5).
Additional information about your setup
Using bug fix marlin version. I am able to print without issue with octorpint most of the time. Never had this issue when printing directly from printer (not octoprint).
Can you enable serial.log in the serial connection settings, then reproduce the issue and upload it.
What it comes down to is where the commands come from, is it your gcode file, bad communication to the printer, a plugin/OctoPrint or something else.
Also, the safe mode question from the initial template: Have you tried running in safe mode and did safe mode fix the issue?
Thank you for your help.
I didn't want to try running in safe mode because I didn't want to lose my "broken" state.
Serial logging was disabled, I just enabled it and will post results if it happens again.
So, I just got the printer "working" by including G90 in my start gcode. Does this make sense that this could solve the problem? Not that it matters, but I looked at a bunch of sample start gcodes and nobody included this.
It does make sense, because it is the difference between relative and absolute extrusion mode. If the printer is in the wrong mode, then things will go very wrong.
I don't really understand the reasoning here... Surely if running in safe mode fixes the issue, then you have narrowed it down to a plugin? Should be one of the first troubleshooting steps.
Sorry for the miscommunication on safe mode...I'm just coming from a programming background where keeping a reproducible bug state is very helpful. Of course I don't mind testing in safe mode and disabling any plugins if required.
Safe Mode is your friend. It takes your instance of OctoPrint back to the "basic configuration" searching for hokey plugins is a true PIA. It's how you learn.
Living in the Windows Server, Linux Server, Windows Desktop & Linux - Pi OS worlds, you end up doing many things you'd not thought of. Actually I started with FORTRAN on cards, on a DEC PDP11. I jumped at a chance to touch an AppleII+, I became a pretty good BASIC programmer. That was 35 years ago. OMG.
Take off your programmer hat, you've entered the "server" world.
Reading .log files is a skill learned. I started by reading Wireshark or Zenmap logs, of complete 2 minute network scans. It created ~7K log items in 2 minutes. That 2 minutes & Seven Thousand lines to read,takes 1/2 a day or so, to fully read & find the issue. .log files are the same way, they exist in Windows, Linux - Pi OS, Mac-OS X, Solaris, VMS, OS390. "Patience Grasshopper"
@hendr1x : Could you solve the problem? I have exactly the same and i wonder why other people don't have this. At first i thought the wifi connection is the problem but after setting up a lan connection it has gone worse. I'm desperate and would be very thankful for any suggestions.
@michelstrichel The problem with just "tagging along" on someone else's unsolved issue is that you assume that your problem is EXACTLY the same and you don't provide us with the details and log files from YOUR environment.
If you open a new topic, fill out the template and provide us with your information, you'll have a much better chance of getting YOUR problem fixed.
@michelstrichel I was able to confirm that the problem is when I run home/auto bed level (G28 + G29) while in absolute positioning mode. The fix for me was to call G91 (relative positioning) before the commands and then after run G90 (absolute) after which my slicer (cura) runs in.
This is all in machine settings -> "Start g code" of my slicer.
@hendr1x : Thank you so much. This solved it for me too.
@b-morgan : I thought this is a forum. At least the about-site says it is: About - OctoPrint Community Forum. A forum is a place where people can ask other people when they need help, isn't it? I asked a specific question to a specific person who could have the answer. And i was right. The problem has been solved without making a PHD thesis of it.
I unknowingly had this same problem and used the same G90 solution, thanks so much!