Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Marlin 1.1.0-RC7 #4237

Closed
thinkyhead opened this issue Jul 8, 2016 · 73 comments
Closed

Marlin 1.1.0-RC7 #4237

thinkyhead opened this issue Jul 8, 2016 · 73 comments
Labels
T: Development Makefiles, PlatformIO, Python scripts, etc.

Comments

@thinkyhead
Copy link
Member

thinkyhead commented Jul 8, 2016 •
edited
Loading

This is a placeholder for the Change Log for 1.1.0-RC7 where we can itemize all the changes worth mentioning since RC6.

Here's a convenient link to all PRs since RC6…

Full Change Log

New / Updated Features

Performance & Stability

Configuration

Homing and Bed Leveling

Mesh (Manual) Bed Leveling

LCD Controllers

Languages

For Developers
@thinkyhead thinkyhead added the T: Development Makefiles, PlatformIO, Python scripts, etc. label Jul 8, 2016
@Roxy-3D
Copy link
Member

Roxy-3D commented Jul 8, 2016

I presume the RC tag will point at this very soon? And RCBugFix will initially point at the same thing the RC tag points at?

@thinkyhead
Copy link
Member Author

thinkyhead commented Jul 8, 2016 •
edited
Loading

Yep. But in one or two (or three) days. There are a couple of annoying bugs still hanging around. I'm starting this now because there's so much to do to get ready… like 7 more pages of PRs to go through.

@petrzjunior
Copy link
Contributor

petrzjunior commented Jul 8, 2016 •
edited
Loading

What about the Stop print bug? Is anyone going to fix it? Should be done before release.

@Roxy-3D
Copy link
Member

Roxy-3D commented Jul 8, 2016

What about the Stop print bug?

Almost for sure... ThinkyHead is looking at that.

Is anyone going to fix it?

Almost for sure, somebody is going to get it fixed. There is a better than 50%-50% chance it will be ThinkyHead that finds and fixes it. But there are other people that fix SD Memory card issues so one of those people may find it before he does.

Should be done before release.

Agreed. But we are only talking about about starting a new Release Candidate and not actually promoting a Release Candidate to 'Golden' status.

@Blue-Marlin
Copy link
Contributor

It won't be bad if you'd follow what is going on here.
The loop after stop when printing from SD issue is fixed.
The shift position after stop problem is minimized for Cartesian printers as far physics allows. (You can't simply stop a full speed move without losing steps)
The forward calculation for DELTAs is ready but not applied in quick stop now.

The question nobody raised up to now is: "Does it make sense to continue after a emergency stop at all. Wouldn't it be better to use 'pause' if you intend to continue."

@thinkyhead
Copy link
Member Author

thinkyhead commented Jul 8, 2016 •
edited
Loading

What about the Stop print bug?

@petrzjunior The "stop print" bug was fixed a couple of days ago.

Does it make sense to continue after a emergency stop at all.

@Blue-Marlin Not so much, so we don't necessarily need to support it to the same extent as Pause / Resume. But on the other hand, does it make sense that we can't quick-stop the machine in a way that we can still "know" its position? The current implementation can lose steps as it just suddenly stops stepping, no matter the speed. (The printer might jump off the table at high speeds, haha!) The thing is, if we wanted to have the machine do a gradual stop we'd have to augment the stepper routines, adding overhead at all times. So it's a trade-off. With quick-stop, we ask the steppers where they left off, but we should probably clear the known_position flags for X and Y too, to reflect the uncertainty.

@jstefanop
Copy link

So RC7 wont be the final 1.1 release?

@thinkyhead
Copy link
Member Author

thinkyhead commented Jul 8, 2016 •
edited
Loading

So RC7 wont be the final 1.1 release?

@jstefanop That will depend on how many bugs are found and how serious they are. If it appears very stable, we may release it as-it-is. If it only has some minor things, we may patch it up and release that as 1.1.0. But if it has any serious or complex issues, we would consider doing another interim release to work those out. This release, as all releases, will generate an upsurge in issue reports, and we will need to sort out which are configuration issues versus real bugs.

Personally, I expect no serious issues. But we haven't tested on every piece of hardware. To help with that, in a couple of weeks I'm hosting a Marlin test lab with the "PDX 3D Printing Lab" meetup group here in Portland. We're getting together about 20-25 users and their printers for a one-day test lab where we will go through configuration, installation, calibration, and testing. I will be fixing-up any extant issues as we find them. More precise details on the lab will be available soon, as we work them out.

@oxivanisher
Copy link
Contributor

I like that. Will surely help test the RC7 on my delta. 👍

@jackshi618
Copy link

When publishing RC7?

@Blue-Marlin
Copy link
Contributor

Blue-Marlin commented Jul 15, 2016 •
edited
Loading

When ready! Still too much to do.

@jackshi618
Copy link

Waiting for a long time.

@MrExo3D
Copy link

MrExo3D commented Jul 15, 2016

Feel free to help out to make things faster..

@jbrazio
Copy link
Contributor

jbrazio commented Jul 15, 2016

I have to take some people as jokers otherwise the swearing would be bad from my side. :-)

@thinkyhead
Copy link
Member Author

thinkyhead commented Jul 17, 2016 •
edited
Loading

Sorry for the long wait @jackshi618 — I also keep expecting the release to be ready "any minute now" and then we discover some subtle bug like #4310 that is challenging to solve, or some minor code cleanup (in this instance with redundant bed-leveling functions) turns into a bigger piece of work requiring additional regression testing.

Of course, when investigating bugs we have to wait for feedback from testers, and sometimes this back-and-forth takes days. During those waiting periods we tend to work on code cleanup, trying to reduce the build size, writing documentation, discussing the roadmap, polishing the configuration files, and trying to address longstanding weak-points. So we are not idle!

The good news is that we have only a few un-fixed issues remaining, with testers and active debugging ongoing. As soon as we deal with these last remaining items and all our testers give us a green light, RC7 will be unleashed on the world. It should be any day now…!

@Roxy-3D
Copy link
Member

Roxy-3D commented Jul 17, 2016 •
edited
Loading

Sorry for the long wait @jackshi618 — I also keep expecting the release to be ready "any minute now" and then we discover some subtle bug like #4310 that is challenging to solve, or some minor code cleanup (in this instance with redundant bed-leveling functions) turns into a bigger piece of work requiring additional regression testing.

I have a lot of these issues fixed in my new code. I think this will all work (and be ready) in the Development branch that gets released at the same time as you go Golden! Let's freeze the probing and auto bed leveling parts of the Release Candidate.

@thinkyhead
Copy link
Member Author

Let's freeze the probing and auto bed leveling parts of the Release Candidate.

Let's fix the bugs. Then freeze.

@Roxy-3D
Copy link
Member

Roxy-3D commented Jul 17, 2016

Well... The thing is very few people are seeing problems in the bed leveling and probing right now. And those few that do have some quirks can probably get by just fine with the new bed leveling system. They can help test it too!

@thinkyhead
Copy link
Member Author

thinkyhead commented Jul 17, 2016 •
edited
Loading

very few people are seeing problems

Very few people are testing.

can probably get by just fine with the new bed leveling system

@Roxy-3D Are you planning to include your new bed leveling system in RC7 then?

@Roxy-3D
Copy link
Member

Roxy-3D commented Jul 17, 2016 •
edited
Loading

I really feel that would be a mistake. It is far too invasive. I've been trying very hard to do everything clean and correct. But you know how even 10 or 15 lines of new code can cause problems. This is literally 1000 lines of new code when you add in the Mesh Validation Tool. (Don't worry about code size. Much of it can be turned off. And all of the original G29 code (all 3 flavors) is gone. Plus, I'm going to offer the ability to do the iterative Least Squares Fit instead of the big QR_SOLVE which saves 10Kb.)

But with that said... I just finished my first print with it 30 minutes ago. Everything seems to be working correctly. But I'm not done with the Mesh Validation Tool, and once that is working how I want I was going to use it's results to finish up the Mesh Editor. (I had to stop working on the Mesh Editor because I didn't have the information I needed to fine tune the Mesh.) Both of those things are straight forward now that the system is working. And even better, both of those things don't need to hook into the main body of Marlin so it is much faster to code.

I was thinking it made sense to release at the same time you promote the RC to 'Golden'. But if it is going to take 4 or 6 weeks to get to that point, how bad would it be to put bug fixes and code clean up into both branches? I guess what I'm asking is would it be a bad thing to release the Development Branch ahead of the Golden Release ?

@thinkyhead
Copy link
Member Author

@Roxy-3D I suggest we release 1.1.0-RC7 with the current cleaned-up (soon bug-free) leveling and homing code. Then when it has been certified as working by the community, we release RC7 as our final 1.1.0. (With no pre-release "golden" anything.) The new bed leveling code would be placed in another branch at that time, and we would include it in Marlin 1.1.1-RC1.

@jbrazio
Copy link
Contributor

jbrazio commented Jul 17, 2016

We get out of one RC cycle to enter another one ?.. I frown a bit at that Scott.
(I know you spoken about a branch.. but a branch with the master one having heavy development would mean a mess to merge back them together aka the MarlinDev syndrome). When we enter 1.1.0 and start developing 1.1.1 we should be out of RC mode until we feel we want to release 1.1.1, only then we enter RC mode and freeze.

For 1.1.0 I agree with @Roxy-3D no UBL, this would be our main feature for 1.1.1.

@thinkyhead
Copy link
Member Author

thinkyhead commented Jul 17, 2016 •
edited
Loading

I frown a bit at that Scott.

I didn't state anything about an acceleration to 1.1.1-RC1. But that would be the first one we "release to the public," yes?

And, perhaps the only thing that differs in 1.1.1 is the new bed leveling. So far that's the first and only (known) feature that we have slated for 1.1.1.

@Roxy-3D
Copy link
Member

Roxy-3D commented Jul 17, 2016 •
edited
Loading

Should we conceal that and just do it "in-house"?

We don't have a full test suite of machine types available. We need users to help verify correct operation.

What most companies do as part of the release process is they stop making any changes that don't add to 'stability'. A lot of time, it is a judgment call. (For example, a very minor bug that can be worked around and is very difficult to fix would get pushed out to be addressed in a Development cycle) A super serious bug that only requires a + sign being changed to a - sign would probably get the OK to be changed. (I realize you both know this. I'm just trying to communicate my thinking.)

And that is 1/2 of my thinking on why we should 'try' to freeze the Bed Leveling and Probing sections of the code. Those areas of the code work. There are some minor issues but even so, there are usually good work arounds. Changes in those areas are like opening a can of worms. You open the lid, and pretty soon you have worms crawling all over the table. (The other 1/2 of my thinking is I can't keep up with all of the changes. First I have to figure out what you did, and then I have to change everything I did to match it. And then debug all of those changes in my code.)

Can we at least agree to 'try' to avoid making serious changes to the Auto Bed Leveling and Probing code? I think that would help us stabilize things. And it would certainly make it easier for me to get my code finished.

@thinkyhead
Copy link
Member Author

thinkyhead commented Jul 17, 2016 •
edited
Loading

we should 'try' to freeze the Bed Leveling and Probing sections of the code. Those areas of the code work.

From my point of view both homing and leveling are currently broken. Delta issues where it only probes one corner. G28 homing losing track of the current position. . . . These need to be confirmed as fixed before unleashing this thing.

@thinkyhead
Copy link
Member Author

thinkyhead commented Jul 17, 2016 •
edited
Loading

I can't keep up with all of the changes.

This is what Richard ran into by trying to get too far ahead of everyday bug-fixing and cleanup. It's great if you have standalone code that you wrote yourself, which eschews all the old cruft. But if you rely on hooking into the existing broken functions and methodologies, copying or building upon what already exists, then you're bound to get thrown by the bug fixes and cleanup.

The amount of reduction and simplification that has been made is pretty impressive, getting down to the essentials. After AnHardt#58 there shouldn't be too much more, but it would be good to do a comprehensive review and make sure everything is still holding together, and see what more might be got rid of at this point.

@Roxy-3D
Copy link
Member

Roxy-3D commented Jul 17, 2016 •
edited
Loading

From my point of view both homing and leveling are currently broken. Delta issues where it only probes one corner. G28 homing losing track of the current position. . . . These need to be fixed before unleashing this thing.

Ooops! I forgot about that. You are correct that needs to be fixed! (And incidentally... The changes for the Delta ABL issues won't phase me a bit! That code is all gone.)

@jbrazio
Copy link
Contributor

jbrazio commented Jul 17, 2016 •
edited by thinkyhead
Loading

I can see Roxy's standpoint, specially when she is playing behind the scenes getting something ready to be presented and we keep changing code that will be replaced in the end.. But until we have UBL on the wild.. MBL and ABL will need to be patched a brought down to some standard degree of "cleanup".

I personally would advise to branch out UBL and Roxxane to publish the code she is working on, I bet some people would love to weigh in in a constructive way. This not only would be good for Marlin dev as we could be reviewing and suggesting possible improvements sooner but it would also be good for her as she would finally learn how to use git from the cmd line. :-P

@jbrazio jbrazio mentioned this issue Jul 18, 2016
Closed
@thinkyhead
Copy link
Member Author

thinkyhead commented Jul 23, 2016 •
edited
Loading

Does it make sense to break the package apart

My approach —when the code has diverged too much to do a simple rebase— is to go over the changes by hand using the Github diff view (on the site or in the app) and re-apply the changes where they make sense in the newest code. That way if new methodologies have been developed, the code will be brought up to date. I try to do the changes in some logical order and create new commits that feature each type of change. A lot of that process can use copy-and-paste, so it's not as infernal as it sounds.

@Roxy-3D
Copy link
Member

Roxy-3D commented Jul 23, 2016 •
edited
Loading

OK.... I don't know enough to argue if I wanted to (and I dont!!!). But from how I see the world, none of these changes have any value unless the whole set of changes is present. So, it is kind of a 'Take it or leave it' thing.

But I'll get the whole set into that branch and transfer ownership so you can decide the 'right' way to get that branch started. (I don't have the Mesh Editor fully alive... But it is coming along pretty fast. In the next few days I'll probably be at a place where you can grab it and load it on your printer.)

@thinkyhead
Copy link
Member Author

it is kind of a 'Take it or leave it' thing

I look forward to taking it all in.

@Roxy-3D
Copy link
Member

Roxy-3D commented Jul 24, 2016

I crossed all of the UBL code over to a branch of devel-ubl, but it looks like all of that effort was for nothing. devel-ubl branches off of RC instead of RCBugFix. Aaaaurrggghhhh !

@thinkyhead @jbrazio

I've emailed you both a .ZIP file of the UBL code working with RCBugFix as of July 4th, 2016. Can you take a look and make a recommendation on how how we should proceed? I'm hoping you can just get the few changes that have happened in the last 10 days into it, and get a suitable development branch setup. The file extension needs to be changed from .ABC back to .ZIP (Google won't let .ZIP files be sent)

@thinkyhead
Copy link
Member Author

thinkyhead commented Jul 24, 2016 •
edited
Loading

If it started from July 4, it should be easy to extract the changes and make a branch here. I will try the following:

git remote add roxy [email protected]:Roxy-3D/Marlin.git
git fetch roxy
git checkout 'RCBugFix@{2016-07-04 23:00:00}' -b july_four_plus_ubl
git diff july_four_plus_ubl roxy/devel-ubl | git apply
git push --set-upstream upstream july_four_plus_ubl

Voila: https://github.com/MarlinFirmware/Marlin/tree/july_four_plus_ubl

The date that most closely matched your devel-ubl branch was July 5 at 12:34:33…

git checkout 'RCBugFix@{2016-07-05 12:34:33}' -b july_four_plus_ubl

There were only a few diffs, all regressions.

@Roxy-3D
Copy link
Member

Roxy-3D commented Jul 24, 2016 •
edited
Loading

No... The problem is, you can't grab the one I did on github. I forked the devel-ubl branch into my account and did the work to get my changes into it and working. Only later I found out the devel-ubl branch was started from RC-6 (as it existed on July 4th). It did not start from RCBugFix as it existed on July 4th.

(And in fact... looking at the files in july_four_plus_ubl there are no G25.cpp, G26.cpp or G29.cpp files. Those files are definitely in the .ZIP file.)

Can you take another look at things with this extra information available to you? One option is for me to fork the current RCBugFix and try to work as fast as possible to get my stuff moved to it. That will probably take me several days of effort. I don't want to do anything without clear and concise guidance that it won't be wasted effort.

That is why I emailed the .ZIP file to you. That .ZIP file is RCBugFix as it existed on July 4th with the UBL code running very solid. If we could get a branch of RCBugFix from July 4th broken out of the tree, every change between the two sets of files would be something UBL needed. That logic might help simplify things. Or alternatively, if we could get a branch of RCBugFix from July 4th broken out, every file in that .ZIP file can simply replace every file in the newly created branch. At that point, any change is part of the UBL System when the commit happens.

(That last idea might be the simplest way to get things into GitHub and close to the current RCBugFix. At least on 'Direct Commits' the GitHub system ignores (and refuses to do anything) if there is not a difference between the two files.) I'm not sure if time stamps on the files enter in for the normal Git operations, but at worst case I guess we could force the time stamps to stay the same to make the commit go smoothly.)

@thinkyhead
Copy link
Member Author

thinkyhead commented Jul 24, 2016 •
edited
Loading

@Roxy-3D I dropped your files into the july_four_plus_ubl branch (same as devel-ubl, I guess), went through and turned the differences into commits using Github Desktop. I pushed the branch then re-pointed the head of devel-ubl to the new commits. So now the devel-ubl branch has the 4 commits I created. You can see those commits here.

For a compare view, we can compare devel-ubl to devel-ubl-base to see all the changes.

@Roxy-3D
Copy link
Member

Roxy-3D commented Jul 24, 2016 •
edited
Loading

OK THANKS!!!!!! I'm very confused because I looked at the files in july_four_plus_ubl and my new files were missing when I wrote that message. Did I catch a view of it while things were in process?

Anyway... Just looking at the files and the commits, that looks viable! I'm guessing those extra branches can go away now?

I need confirmation: Should I fork the devel-ubl branch to continue my work? As soon as I hear back... I'll fork and verify everything is still working. I will also delete the current fork in my repository so I just have the one good fork. And then I'll be in a position to do Pull Requests to get stuff back to what ever branch you tell me to fork.

Update: It looks like the Readme.md file did not make it over to that branch. It is supposed to look like this: https://github.com/Roxy-3D/Marlin_with_UBL/blob/RC/README.md I guess I might have made the .ZIP file at too low of a level?

@thinkyhead
Copy link
Member Author

thinkyhead commented Jul 24, 2016 •
edited
Loading

my new files were missing

I presumed your fork's devel-ubl branch would already have your changes pushed. I only manually merged in the contents of the ZIP file a short time ago.

Should I fork the devel-ubl branch…?

You can do that now, if you wish. I've finished patching up those commits. After you've got it working the way you like, later on we can isolate the changes and then apply the more up-to-date equivalent changes to the latest RCBugFix code.

verify everything is still working

Don't forget to use the config files in example_configurations/Roxy-3D.

@Roxy-3D
Copy link
Member

Roxy-3D commented Jul 24, 2016

Thanks Again! Can you get the Readme file close to what I have? The contents I have in it are aimed at helping people understand what the current status of UBL is and what they should expect.

I'll re-fork devel-ubl and continue forward!

@thinkyhead
Copy link
Member Author

thinkyhead commented Jul 24, 2016 •
edited
Loading

Can you get the Readme file close to what I have?

The README.md in your ZIP file is no different from the README.md file from July 5. I'm sure you can do the update, as needed.

@Roxy-3D
Copy link
Member

Roxy-3D commented Jul 24, 2016

OK. I brute forced the Readme to be correct. But the fish logo is missing because the Documentation directory is not there. I don't dare to do that.

@jbrazio
Copy link
Contributor

jbrazio commented Jul 24, 2016

I fixed the image for you @Roxy-3D

@Roxy-3D
Copy link
Member

Roxy-3D commented Jul 24, 2016 •
edited
Loading

Thank You! We can't do anything without the Marlin being there! :)

Now, please tell me how hard I have to twist your arm to get you to load it up on your printer?

@thinkyhead
Copy link
Member Author

thinkyhead commented Jul 25, 2016 •
edited
Loading

I've updated the Change Log above. It's kind of long. I see an RC7 release in the near future. One issue that I hope we can clear up is…

  • After upgrade users have a "stuck" Z axis.

Speed / acceleration-related issues are…

Are there any blocking issues that we need to address ahead of foisting this release onto the world?

@jbrazio
Copy link
Contributor

jbrazio commented Jul 25, 2016

I've got all "possible bug" and "bug found" issues marked for the milestone, so it would be cool either we discard or confirm them.

@thinkyhead
Copy link
Member Author

Ah yes. Very helpful… I'll go through some of them now. https://github.com/MarlinFirmware/Marlin/milestone/53

@thinkyhead
Copy link
Member Author

When things get as quiet as they are lately, either it's the height of Summer, or it's time to put out another release. I vote for the latter, and may the issues start flooding in.

@jbrazio
Copy link
Contributor

jbrazio commented Jul 27, 2016

I'm quietly working on the buzzer.

@thinkyhead
Copy link
Member Author

I'm quietly working on the buzzer.

How ironic!

@Blue-Marlin
Copy link
Contributor

Yes - ironic and completely hopeless.
There is no loop in Marlin fast and reliable enough to play tones - except you'd use an interrupt.
The lowest frequency you can play with a buzzer/hummer is its own resonance frequency.
If your rectangular wave is interrupted by the screen refresh you will ether hear that frequency or nothing, for that time (25-180ms depending on the display).
For a simple test just toggle the beeper pin in loop() an or idle(). (taping the noise device will save your nerves)

@jbrazio
Copy link
Contributor

jbrazio commented Jul 27, 2016

except you'd use an interrupt.

😉

@Blue-Marlin
Copy link
Contributor

Please don't do that. Please.
Better go back to blocking tones limited to 2s, calling the heater update at lease 5 times a second.
Interrupt time is just tooo valuable.

@jbrazio
Copy link
Contributor

jbrazio commented Jul 27, 2016

Don't worry.

@Blue-Marlin
Copy link
Contributor

I don't worry - I'm scared!
All you need to know to not try it was in #3913 (comment) and #3913 (comment)

@thinkyhead
Copy link
Member Author

thinkyhead commented Jul 27, 2016 •
edited
Loading

@jbrazio I presume you are not writing your own low-level functions to toggle the pin, just trying to figure out a way to make tones sound nicer. It occurs to me to ask: Do the LCD controllers that support playing tones do their own tone-generation directly on the controller board, so we just turn them on and off?

@AnHardt
Copy link
Contributor

AnHardt commented Dec 10, 2016

I guess , this can be closed.

@github-actions
Copy link

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 github-actions bot locked and limited conversation to collaborators Mar 31, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
T: Development Makefiles, PlatformIO, Python scripts, etc.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests