Marlin: [BUG] OctoPrint disconnects when doing PID Autotune on SKR Mini E3 v1.2
Description
OctoPrint disconnects when doing PID Autotune on SKR Mini E3 v1.2
Steps to Reproduce
Checkout bugfix-2.0.x at commit b11551c from Nov 24 2019
Copy configuration.h and configuration_adv.h from
Marlin\config\examples\BigTreeTech\SKR Mini E3 1.2(configs and platformio.ini are attached)- Note: The only change I made was to change the thermistor type because I have a Titan Aero. E-steps are wrong as a result but I wanted to make minimal changes to test a totally vanilla build and didn't plan on actually trying to print or move any motors with this build
- Modify in platformio.ini:
default_envs = STM32F103RC_bigtree_512Kordefault_envs = STM32F103RC_bigtree - Build and install on machine
- Connect OctoPrint and run
M303 E0 S205 C10from the Terminal window
Expected behavior: Normal PID autotune process with successful USB connection
Actual behavior: Error in OctoPrint terminal after 10-15 seconds:
Unexpected error while reading serial port, please consult octoprint.log for details: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:2793
Additional Information
- USB cable has 5V wire snipped so there's no 5V power going to the board from the Pi. Others had issues with this in the past.
- I've tried this before and after updating all PlatformIO libraries to their latest versions. PlatformIO is on Core 4.1.0 and also tried reverting that back to 4.0.3, again with and without latest library versions.
- I have gone through the OctoPrint FAQ article that they link to and none of the points they list apply here: https://community.octoprint.org/t/octoprint-randomly-loses-connection-to-the-printer-with-a-serialexception/228
- OctoPrint previously worked just fine in the exact same configuration with the stock Ender 3 board running Marlin 1.1.9 and the same USB cable, so the cable and Pi should not be an issue
- Tried unplugging webcam and no change
- First reported over in the BTT repo bigtreetech/BIGTREETECH-SKR-mini-E3#119
- This is likely not isolated to just doing a PID Autotune but I do not want to attempt to print without doing the tune first so I cannot verify that
ViolenceUndone
All 24 comments
pid tune works fine for me, and i use octoprint only as the printer is 30 meters away from pc in another room
boelle
on 24 Nov 2019
@boelle Marlin, PlatformIO library, and OctoPrint versions? Have you followed the repro steps of using the latest commit and default configs? It's not working for me and at least one other person so far, so "works on my machine" isn't helpful for figuring out why it works for you and not for us.
ViolenceUndone
on 24 Nov 2019
latest platformio and octorprint
what repro? i know how to config marlin for my setup
boelle
on 24 Nov 2019
The repro that very clearly says to leave all configs as their defaults for the SKR Mini E3 v1.2 based on the latest commit. What Marlin commit did you test against, and with which config files? Did you use the ones that I uploaded as part of the bug reproduction that is a mandatory requirement for filing a bug on here, specifically so people are able to reproduce the bug on their own machines?
ViolenceUndone
on 24 Nov 2019
as said i know how to do config for my own machine but i when i made that config many moons ago i started out with the standard config found here: https://github.com/MarlinFirmware/Marlin/tree/bugfix-2.0.x/Marlin
you forgot to link to that repro so i guess this one: https://github.com/MarlinFirmware/Configurations
that one is not active yet
boelle
on 24 Nov 2019
The repro steps are listed in the bug report including the Marlin commit that it was based on. I uploaded the configuration files that I used and they're attached to the bug report, as the bug report requirements state, rather than pushing a branch. Are you even on the same board? If you are, then you've confirmed that it's possible to configure it in a way that works, but without a comparison of all your changes to all files, there's no way to know what you did that fixed it. If not, then all you've done is confirm that Marlin can do PID Autotunes, which was never really in question here since the community would be up in arms if it stopped working for all boards.
ViolenceUndone
on 24 Nov 2019
I also just confirmed again that this is working fine on the BTT fork of Marlin, but it's based on an older version and I would like to get the printer working on the latest bugfix code. This seems to indicate that there's something specifically in the implementation of this board in the Marlin codebase that's causing the issue. I also tried going back in time and building from commit 2e22846 which had the initial E3 Mini example configurations checked in, and had the same issue. I'm going to go back further and see if I can find a point where using the configs from the BTT fork would work in the base Marlin code to try to isolate where the breaking change was.
ViolenceUndone
on 24 Nov 2019
One important difference compared to the BTT fork is that Marlin now has composite usb set in the env:STM32F103RC_bigtree. So updating from the outdated BTT fork would mean that you should change the environment to env:STM32F103RC_bigtree_NOUSB to have it comparable. Don't have Octoprint available now to test this, but this might have something to do with the problem.
tatusah
on 24 Nov 2019
I actually _just_ noticed this and am in the process of recompiling right now. Will report back in a few.
ViolenceUndone
on 24 Nov 2019
That did the trick, so this is technically not a bug, but rather confusing/misleading when the naming was reversed in 0f57818f2 by @thisiskeithb which then breaks anybody who doesn't go and modify platformio.ini to switch over. Any reason for this change? Should it stay or go back to how it was previously?
ViolenceUndone
on 24 Nov 2019
@ViolenceUndone: Check the issue comments & commit history: https://github.com/MarlinFirmware/Marlin/pull/15890. There was a lot of discussion & changes made after my initial commits.
@thinkyhead: Since we didn't go with defaulting 512k flash on all of BigTreeTech's STM32 environments, it would probably make sense to revert the behavior back to USB composite being left out as the default.
thisiskeithb
on 24 Nov 2019
See https://github.com/MarlinFirmware/Marlin/pull/16006. This reverts the default BigTreeTech STM32F103 environment to not include USB composite support like it did before the 512k PR.
thisiskeithb
on 26 Nov 2019
@ViolenceUndone had a look at what @thisiskeithb said? ^^^
boelle
on 30 Nov 2019
This is also happening with the SKR E3 Dip v1.0
Is there a fix or workaround yet? could someone explain it in laymans terms, i'm a bit of a noob with all this.
RyanParle
on 30 Nov 2019
@RyanParle either get the latest version where the name was switched back, or switch to the _512k_NOUSB environment instead of just _512k which was previously used
@boelle I did, and I had previously asked "Should it stay or go back to how it was previously?" Apparently the decision was to go back, but I was leaving it open-ended for discussion. If everybody is satisfied with changing the name back to how it was before (which is what @thisiskeithb did in #16006) then I would say this can be closed.
ViolenceUndone
on 1 Dec 2019
@RyanParle either get the latest version where the name was switched back, or switch to the _512k_NOUSB environment instead of just _512k which was previously used
Perfect, works a charm.
RyanParle
on 1 Dec 2019
will close then, we can always reopen if needed
boelle
on 1 Dec 2019
Am I reading this right? The solution to the PID tuning problem is to turn off USB composite support? That's not a solution! It's like having a car that acts like the throttle pedal is stuck on full when the air conditioning is turned on, and being told by the mechanic "Well then, just don't run the air conditioning. Problem solved!".
dseven
on 17 Jan 2020
I'd say it's more like having a car where the radio cuts out whilst it is plugged in to a computer for tuning.PID tuning is pretty much a one off operation, you set the values and leave it there.The problem was being worked on at the time of my first post but a fix was to disable the composite USB functionality in order to run PID auto tune. You can take note of the values it gives and re build with those values set in firmware and also enable composite USB.聽Personally the only reason I could see for wanting composite USB is for remote firmware updates, i run my printer on Octoprint all of the time and have not put an sd card in the slot since my last firmware update, so for me it's now a non issue.聽My LYA-L09. On O2.-------- Original Message --------Subject: Re: [MarlinFirmware/Marlin] [BUG] OctoPrint disconnects when doing PID Autotune on SKR Mini E3 v1.2 (#15993)From: iain MacDonnell notifications@github.comTo: MarlinFirmware/Marlin Marlin@noreply.github.comCC: RyanParle ryanparle@deejayry.co.uk,Mention mention@noreply.github.comAm I reading this right? The solution to the PID tuning problem is to turn off USB composite support? That's not a solution! It's like having a car that acts like the throttle pedal is stuck on full when the air conditioning is turned on, and being told by the mechanic "Well then, just don't run the air conditioning. Problem solved!".
鈥擸ou are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.
RyanParle
on 17 Jan 2020
Yes, remote firmware update is my motivation for USB composite support - I got tired of going to the printer to get the SD card, bring it back to my office, copying the file to it, ejecting it from the PC, taking it back to the printer, power-cycling the printer..... the OctoPrint firmware updater makes it nice and convenient. I suppose both operations are not "every day" things, but still... saying you can't do both is not a real solution.
One redditor reported the display and input encoder locking up when this happened, and it basically went into the thermal runaway! I've not been able to reproduce that. For me, so-far, the USB device seems to get reset every ~30 seconds, but I can reconnect, and the autotune procedure continues (and completes) whether I'm connected or not.
dseven
on 17 Jan 2020
One redditor reported the display and input encoder locking up when this happened, and it basically went into the thermal runaway!
I can attest to this as I have 2 mini dip version that will freeze if I attempt to do a auto pid without re flashing my firmware to a the env that has no USB composite support as well as video of it freezing as well when opening cura.
chaoticchoas
on 15 Mar 2020
I have the same problem with my Ender 3 Pro and the BTT SKR Mini E3 V1.2 and Marlin 2.0.5.3
Is there any solution to this by now (other than to disable USB composite)?
Mopemaster
on 28 Apr 2020
I have the same problem with my Ender 3 Pro and the BTT SKR Mini E3 V1.2 and Marlin 2.0.5.3
Is there any solution to this by now (other than to disable USB composite)?
The same configuration, the same problem
rollduck
on 29 Apr 2020
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
![github-actions[bot] picture](https://avatars2.githubusercontent.com/in/15368?v=4&s=40)
github-actions[bot]
on 2 Jul 2020
Related issues
otisczech
路
3Comments
modem7
路
3Comments
ShadowOfTheDamn
路
3Comments
Tamonir
路
3Comments
Glod76
路
3Comments
Most helpful comment
@RyanParle either get the latest version where the name was switched back, or switch to the _512k_NOUSB environment instead of just _512k which was previously used
@boelle I did, and I had previously asked "Should it stay or go back to how it was previously?" Apparently the decision was to go back, but I was leaving it open-ended for discussion. If everybody is satisfied with changing the name back to how it was before (which is what @thisiskeithb did in #16006) then I would say this can be closed.