Closed rflulling closed 4 years ago
thinkyhead
commented
4 years ago Please test the bugfix-2.0.x branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.
rflulling
commented
4 years ago Finally got a good compile. Had to flat out comment out Use_Controller_fan. I had been falling asleep in the merge of configuration, and configuration_h
Kept having trouble with Controller_Fan_Pin, seems some one on the team really, REALLY wants to prevent any one from EVER using FAN_PIN which is the 1st of 3 ports on the hardware. I normally flip PE6 and PC8 in the Pins file allowing the Controller fan to work on Port 1. Not no more. Everything brings the compile to a dead halt if it even thinks Port 1 is being used. -I have seen nothing written that explains why this should be.
Weirder, there is a define for E0 auto fan pin as PC9, but nothing for E1 or E2, and what exactly is PC9? -"Lucy you gots some splaining to do!"
So now that nuisance is set aside... Back to the main topic. MARLIN-BugFix-2.0.x (20200417@1057GMT): PASS MOTION TEST MARLIN-BugFix-2.0.x (20200417@1057GMT): PASS EXTRUSION TEST
One anomaly, Persistent message, "settings stored."
rflulling
commented
4 years ago Been running on Bug Fix. several weeks. Any chance this issue is resolved? I feel weird being the only one who seem to have reported this. Yet there is no reason for that I know, and the only change being an update to 2.0.5.3. And bug-fix being more recent did not have the issue at all. Other versions of the firmware, older compile work fine too.
boelle
commented
4 years ago @rflulling still an issue?
boelle
commented
4 years ago Lack of Activity This issue is being closed due to lack of activity. If you have solved the issue, please let us know how you solved it. If you haven't, please tell us what else you've tried in the meantime, and possibly this issue will be reopened.
rflulling
commented
4 years ago @boelle : closed while I was not looking. As I said previously, this directly effected Marlin 2.0.5.3.
It was suggested that run BugFix, and so I have been. Unless 2.0.5.3 has been quietly patched, then this is still an issue, in that release.
However, assuming that since it is not an issue in BugFix, when the merge comes, we will see if the bug persists on the release versions. But I cannot say more until after merge happens.
I will reopen this issue at that time if needed.
thisiskeithb
commented
4 years ago However, assuming that since it is not an issue in BugFix, when the merge comes, we will see if the bug persists on the release versions. But I cannot say more until after merge happens.
No, bugfix-2.0.x is the basis of the next 2.0.x release. If it works in bugfix, it'll work in the release branch once the next version is tagged & released. Fixes are rarely back-ported to previously tagged releases, which is why we always ask users to try the latest bugfix-2.0.x release when reporting & testing issues.
github-actions[bot]
commented
4 years ago 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.
Bug Description
Dual Y Configuration. Y0 Goes wrong direction 50% of the time. That is no mater what direction you send, it always moves positive.
My Configurations
Marlin Config (2.0.5.3).zip
Marlin 2.0.5.3 on SKR PRO 1.1 Drivers ST820.
Steps to Reproduce
Compile install Marlin 2.0.3 ( no bug ) Compile install Marlin 2.0.5.3 (bug)
Expected behavior: [What you expect to happen] Y0 and Y1 should run opposite but sync to drag the X axis.
Actual behavior: [What actually happens] Y0 always moves one direction. Y1 moves as expected.
Additional Information
At first I thought this was related to a pair of TMC5160 just installed on E0 and E1. But first switched the Physical driver in case it was some how damaged while the new ones were installed. But no same behavior. So removed the two drivers, and rolled back to a last known good Marlin 2.0.3. Y0 works correctly. Leaving the drivers removed, I installed (a just in case something like this would happen), copy of Marlin 2.0.5.3 that has the exact same configuration and drivers as Marlin 2.0.3. Y0 exhibits the bug again. Now opened 2.03 and 2.053 and compared the configuration files and pin files in WinMerge. For any accidental omission or deviance. None found. Though there are of course plenty of Marlin source changes.
Hardware has been eliminated as suspect. Configuration set by user has eliminated as suspect.
Conclusion. Unknown bug in 2.0.5.3 which I think is causing an issue with the Dual Y function. Though this is only a guess.
NOTE: This configuration is entirely loaded with ST820 drivers. This means that several functions are deliberately reversed, since Marlin has no call for the ST820. Apologies if this creates a problem for testing. Though I anticipate you will not need to directly test these files submitted.