Marlin deadlocks a few seconds after serial connection being established
Marlin deadlocks a few seconds after i connect via pronterface.
My configs are in my forked repo, i use the current RCBuxFix branch, which should be the same as 1.1.0 final atm.
I dont get any errormessages over the serial connection (usb to be precise) and my display just freezes.
Uploading a sketch works just fine and so does the Board when nothing is connected via usb (when its powered through 12V
MaxRink
All 14 comments
my latest backup from the 29. last month seems to work just fine tho, so i doubt its a HW issue
Marlin-RCBugFix.zip
MaxRink
on 4 May 2017
Try the latest bugfix-1.1.x. A crashing issue has just been fixed.
bgort
on 4 May 2017
bugfix-1.1.x fixes the issue for me. Thanks!
anoldguy
on 5 May 2017
Great!
bgort
on 5 May 2017
bugfix-1.1.x fixes the issue for me also. thanks!!!
equake
on 5 May 2017
My printer got in an endless loop restarting with 1.1.0; Bugfix 1.1.x fixed it
LVD-AC
on 5 May 2017
I think we should all discuss how to proceed. My vote would be we take tested and proven fixes that have been added to v1.1.0-BugFix and move them into v1.1.0 But it is only the 100% solid and tested stuff that gets moved there.
That means v1.1.0 will lag a little behind v1.1.0-BugFix. But it will always be solid and working????
Roxy-3D
on 5 May 2017
IMO there is some urgency here to make 1.1.0 work; having an official release that does not even start up is a bit...
I just have been playing moving the print head around, not printing yet, but even BugFix1.1.x did hang up once and I had to reset the printer. I can't repeat that error sending the same commands, seems to be a random communication error; it goes well in 99% of the cases.
LVD-AC
on 5 May 2017
Encountered the same issue. Rolled back to 27.04.2017 RCBugFix and it worked. Will try latest 1.1.x RcBigFix in the evening. (Tested, helped, no deadlock)
ozligia
on 5 May 2017
I have the same exact issue. My lcd works fine but as soon as you connect via usb it locks up. You can see in this video the screen works, then you can hear me connect the usb and a couple seconds later the lcd locks up.
https://youtu.be/gLAtDNyPImY
pryan215
on 5 May 2017
I think we should all discuss how to proceed. My vote would be we take tested and proven fixes that have been added to v1.1.0-BugFix and move them into v1.1.0 But it is only the 100% solid and tested stuff that gets moved there. That means v1.1.0 will lag a little behind v1.1.0-BugFix. But it will always be solid and working????
Well, first, we probably shouldn't be 'releasing' wholly untested code (a single test by anyone would have revealed the recent bug). That aside, I think in this case it makes sense to apply at least #6584 to 1.1.0 right now, mostly because it's such a big deal (it prevents Marlin from working almost entirely) and because it's still relatively early so not too many people have downloaded it yet. FWIW, I don't generally like the idea of modifying releases after their 'publication', as this just creates confusion among users ("no, no..try the -new- 1.1.0"); I'm only suggesting we make an exception now because this is so significant a problem.
Anyway, going forward, I propose that we consider doing 'patch' version increments for bug fixes and minor improvements. I think using the relatively common MAJOR.MINOR.PATCH numbering scheme (that it looks like we're already headed towards using) makes good sense, so right now we could bundle the current bugfixes plus whatever other bugfixing/improving commits come in over the next week or two into 1.1.1, and then next time there are enough (or significant enough) commits to justify another patch increment, we'd go to 1.1.2, and so on. Patch versions could likely be released immediately without any RC-type testing (other than maybe a quick sanity check by whoever actually does the release), as the changes would be minor and probably pretty unlikely to break anything.
For anything more significant, like new features (e.g., a new gcode), or significant changes to how existing features work, we could do a minor version increment to, e.g., 1.2.0. I think it makes sense to have a short 'RC' test window (a few days or a week?) once we're closing in on doing a minor release?
And when -very significant- new features or significant structural changes are made, we would do a major version increment, after more significant RC testing?
A few other points:
- I think during RC testing periods, we should consider implementing a 'new feature freeze' and -only- fix things that are broken, make minor improvements, etc. then.
- As I've suggested previously, I think having some kind of (at least minimal) roadmap or project plan would be a good idea, too, if for no other reason than that it gives developers an idea of where things are going so they can fix/implement/work with some forethought as to what's around the bend. This could be as simple as a bulleted/numbered list of major and minor versions/releases, with the things that people are working on and the version they're targeting. It wouldn't have to be set in stone, but could be changed whenever anyone had a good idea, their schedule shifted, etc. (perhaps after some brief discussion?) ...
Anyway, I'm not sure how all of this squares with what thinky and others are thinking, but wanted to throw these things out there for consideration.
Maybe we need a separate issue where we can have an ongoing discussion?
bgort
on 5 May 2017
+1 @bgort IMO the changes to the previous release can justify naming it Marlin 2.0.0; minor patches would increment to 2.0.1 and major ones to 2.1.0
LVD-AC
on 5 May 2017
bugfix worked for me on loop issue - thanks!
cobrettee
on 5 May 2017
Hm. My comment was not updated. Tested rcbigfix 1.1.x and it helped
ozligia
on 10 May 2017
Related issues
Glod76
路
3Comments
ShadowOfTheDamn
路
3Comments
ahsnuet09
路
3Comments
jerryerry
路
4Comments
Bobsta6
路
3Comments
Most helpful comment
Well, first, we probably shouldn't be 'releasing' wholly untested code (a single test by anyone would have revealed the recent bug). That aside, I think in this case it makes sense to apply at least #6584 to 1.1.0 right now, mostly because it's such a big deal (it prevents Marlin from working almost entirely) and because it's still relatively early so not too many people have downloaded it yet. FWIW, I don't generally like the idea of modifying releases after their 'publication', as this just creates confusion among users ("no, no..try the -new- 1.1.0"); I'm only suggesting we make an exception now because this is so significant a problem.
Anyway, going forward, I propose that we consider doing 'patch' version increments for bug fixes and minor improvements. I think using the relatively common MAJOR.MINOR.PATCH numbering scheme (that it looks like we're already headed towards using) makes good sense, so right now we could bundle the current bugfixes plus whatever other bugfixing/improving commits come in over the next week or two into 1.1.1, and then next time there are enough (or significant enough) commits to justify another patch increment, we'd go to 1.1.2, and so on. Patch versions could likely be released immediately without any RC-type testing (other than maybe a quick sanity check by whoever actually does the release), as the changes would be minor and probably pretty unlikely to break anything.
For anything more significant, like new features (e.g., a new gcode), or significant changes to how existing features work, we could do a minor version increment to, e.g., 1.2.0. I think it makes sense to have a short 'RC' test window (a few days or a week?) once we're closing in on doing a minor release?
And when -very significant- new features or significant structural changes are made, we would do a major version increment, after more significant RC testing?
A few other points:
Anyway, I'm not sure how all of this squares with what thinky and others are thinking, but wanted to throw these things out there for consideration.
Maybe we need a separate issue where we can have an ongoing discussion?