Marlin 1.1.0-RC7

[thinkyhead]

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 - #3611 : Add `M108` command to cancel `M109`, `M190`, and `M303` - #3625, #3813, #3819, #4298 : Add Print Job Timer and statistics (`PRINTCOUNTER`) - #3653, #4106 : Add temperature watch for the heated bed (`WATCH_BED_TEMP_PERIOD`) - #3662 : New Filament Change feature (`FILAMENT_CHANGE_FEATURE`) - #3676, #4035, #4040, #4126 : New advance extrusion algorithm (`LIN_ADVANCE`) - #3720 : Use a positive flag for Host Keepalive (`HOST_KEEPALIVE`) - #3789 : Add `M999 S1` to restart without flushing the buffer - #3806 : Add CoreYZ support, fix CoreXY, CoreXZ (`COREYZ`) - #3808, #3895 : `SINGLENOZZLE` basic multi-extruder support - #3985 : Support for inches, Fahrenheit, Kelvin (`INCH_MODE_SUPPORT`, `TEMPERATURE_UNITS_SUPPORT`) - #3992 : Add error-checking of `E` parameter in `M303` - #4013 : Add `S` parameter to stay in place on tool-change. Example: `T1 S1` - #4053, #4060, #4094, #4158 : Add support for the Cartesio UI (`BOARD_CNCONTROLS_12`) - #4159 : Support for RigidBot V2 and its digipot (`BOARD_RIGIDBOARD_V2`) - #4192: Support for Vellemann K8400 (`BOARD_K8400`) - #4054, #4354 : Add `NOZZLE_CLEAN_FEATURE` - #4163, #4339 : Add `MIXING_EXTRUDER` and `SWITCHING_EXTRUDER` - #4222 : Add `P` parameter to `M302` (more like RepRapFirmware) - #4226 : Add `EMERGENCY_PARSER` to allow override commands - #4241 : Add a serial transfer buffer option (`TX_BUFFER_SIZE`) - #4244 : Dyze High Temperature Thermistor support (up to 500°C) - #4271, #4279 : Add `X_DUAL_STEPPER_DRIVERS` option - #4299 : Add `NOZZLE_PARK_FEATURE` - #4305 : Drop-in custom boot screens - #4336 : Add support for BLTouch sensor (`BLTOUCH`) - #4362 : Add `DUAL_NOZZLE_DUPLICATION_MODE` - #4408 : Add support for `REPRAPWORLD_GRAPHICAL_LCD` #### Performance & Stability - #3613 : Fix an issue with sudden acceleration - #3642 : Suppress host keepalive during `M109` / `M190` - #3650 : Prevent stuck `M109` / `M190` if a target temperature is changed - #3661 : Fix handling of UTF-8 characters in SD card filenames - #3751 : Fix long `G2`/`G3` arcs blocking machine idle - #3757 : Don't allow setting auto fan pins in `M42` - #3781 : Improved performance in Delta movement - #3788 : Improvements for Dual X Carriage - #3797 : Less blocking in `G2`, `G3`, and `G5` - #3828 : Fix endstops default enabled state - #3829, #4010 : Fix position adjustment when switching extruders - #3888 : Fix issues with MAX31855 thermocouples - #3909 : Fix initialization of some arrays - #3939, #4214 : Reduce positional error, clear command queue on "Stop print" - #3955, #3958 : Fix `M428` for compatibility with Delta and SCARA - #3995, #4140 : Beeps and tones no longer stall execution - #4012 : Prevent bad watchdog timeouts - #4092 : Add reporting of SD read errors - #4095, #4097 : Fix issues with Filament Runout Sensor - #4165 : Bring RUMBA pins file up to current methods - #4167 : Add a checksum to the EEPROM to detect errors - #4169 : Fix wait-for-cooling in `M109` / `M190` - #4204 : Adjust software endstops, if needed, on tool-change - #4250 : Adjust wait-for-cooling timeout - #4253, #4257 : Broader support for filament runout sensor - #4256, #4278, #4291 : Optimizations for single-hotend setups - #4258, #4287, #4321, #4327, #4374, #4376, #4390 : Fix and improve print job timer and counter - #4280 : Fix write-to-file serial output - #4287 : Support for prints over 18h 12m 15s in the print counter - #4360 : Fix issues with `G28` when T0 isn't the active tool - #4365 : Tweak planner acceleration constraint - #4370 : Add DELTA forward kinematics (to get XYZ from ABC) - #4389 : Optimize planner code with less `float` division - #4402 : Fix bugs related to the shifted coordinate space #### Configuration - #3609 : Add versioning to the configuration files - #3632 : Simplified language setting in `Configuration.h` - #3672 : Simplified probe configuration - #3702 : Simplified pins files - #3779 : Automatic assignment of X2, Y2, Z2 stepper connectors - #3928 : Clean up Delta configuration examples - #4065 : Remove support for XY servo endstops - #4252, #4292 : Generalize options that specify PLA and ABS - #4296 : Update BQ Hephestos 2 configuration - #4306 : Replace `ENDSTOPS_ONLY_FOR_HOMING` with `ENDSTOPS_ALWAYS_ON_DEFAULT` - #4337 : Change endstop-inverting options from const bool to define - #4398, #4400 : Sanity checking of safe homing, temp sensors - #4414 : Remove all `#include` from `Configuration.h` / `Configuration_adv.h` #### Homing and Bed Leveling - #3707 : Fix curved movements in `G29` for Delta - #3775 : Report current position to host after `G29` - #3782 : Require homing of Z before `G29` bed leveling - #3798 : Allow using probe indices (`I` and `J`) with `M421` Set Probe Point - #3942 : Fix servo probe raise in `G28` and other non-leveling contexts - #4021, #4066, #4085, #4093, #4108 : Allow the use of probes without Auto Bed Leveling - #4181 : Fix curved movements in Allen Key deploy & stow - #4207 : Clean up Allen Key code, allow use on Cartesian machines - #4217, #4235 : Fix `MIN_Z_HEIGHT_FOR_HOMING` cumulative raising - #4307, #4320, #4323, #4342, #4356, #4358, #4361, #4368, #4373, #4381, #4387 : Major cleanup of homing and leveling - #4308, #4330, #4378, #4379 : Improved logging of homing and leveling #### Mesh (Manual) Bed Leveling - #3760, #3903, #3911 : Improved Mesh (Manual) Bed Leveling - #3802 : Add MBL resting position after homing (`MESH_G28_REST_ORIGIN`) - #3956, #4199 : Keep Mesh Bed Leveling active when homing X, Y, or Z alone - #4146 : Allow Mesh Bed Leveling to work when homing to max Z - #4154 : Use `Z_RAISE_BETWEEN_PROBINGS` for Mesh (Manual) Bed Leveling - #4202 : Fix position adjustment for MBL when switching tools #### LCD Controllers - #3110, #4001 : Improved axis movement from the LCD controller - #3670 : Use directional buttons on controllers that have them - #3739 : Option to reverse the encoder wheel (`REVERSE_ENCODER_DIRECTION`) - #3740 : Add individual axis homing to the LCD menu - #3762 : Don't display heated bed on Graphical LCD if no heated bed - #3914, #3944 : Fix LCD contrast adjustment range for different panels - #3936 : Support for SAV_3DGLCD OLED LCD controller - #4025 : Fix manual LCD movement with multiple extruders - #4057 : Show millimeters (not steps) moved in LCD babystepping - #4168, #4277 : Support VIKI2 display with RAMPS and MKS 1.3 / 1.4 - #4188, #4201 : Add Printer Info and Printer Statistics to the LCD menu - #4243, #4309 : Improve static/scrolling LCD screens - #4254 : Show full kill screen (not just message line) - #4265 : All new beeper / speaker / buzzer code and tone queue - #4285 : Remove delay for small manual encoder axis moves - #4357, #3957 : Improvements for the RepRapWorld Keypad #### Languages - #3712, #3746, #3785, #4185, #4341 : Updated Japanese language - #3748, #3976, #4228, #4259, #4415 : Updated Czech language - #3754 : Updated Portuguese language - #3787, #3952 : Updated Galician language - #3805 : Updated Polish language - #3932, #3933, #3950 : Updated Danish language - #4024, #4274: Add Greek language (el, el-gr) - #4029, #4329, #4395 : Updated Italian language - #4055, #4069 : Add Croatian language - #4078 : Updated Spanish language - #4229 : Updated German language #### For Developers - #3224 : Fix Makefile for Melzi and Arduino 1.6.x - #3631, #3643, #3660, #3671, #3681 : Stepper, Planner, Endstops, Temperature as singletons - #3715, #3803 : Clean up the `buildroot` folder - #3922, #3923, #3924, #3925, #3926, #3947 : Optimize singletons with `static` data & methods - #4043 : Add a non-blocking delay function - #4023, #4049 : Add macros for moving servos - #4034 : Allow the use of a custom image to display at startup - #4080, #4081, #4096, #4100, #4134, #4162, #4183 : Cleanup of probing / leveling functions - #3567, #4056 : Add helper scripts to make working with Marlin and Git easier - #4064, #4074 : Additional patterns added to `.gitignore` - #4186 : Add generalized macros to initialize variable-size arrays - #4245 : Simplify `thermistortables.h` - #4272 : Fix M100 issues (`M100_FREE_MEMORY_WATCHER`) - #4286 : Make it easier to do formatted debug output - #4319 : Specify units (`mm_s` or `mm_m`) in feedrate variable names - #4355 : Rename ultralcd implementation files - #4397 : Cleanup to EEPROM read/write code - #4404 : Cleanup to stepper indirection code - #4232, #4234, #4335, #4340, #4353, #4349, #4355, #4359, #4369, #4372, #4383 : …and more code cleanup

[Roxy-3D]

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]

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]

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

[Roxy-3D]

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]

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]

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]

So RC7 wont be the final 1.1 release?

[thinkyhead]

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]

I like that. Will surely help test the RC7 on my delta. :+1:

[jackshi618]

When publishing RC7?

[Blue-Marlin]

When ready! Still too much to do.

[jackshi618]

Waiting for a long time.

[adamfilip]

Feel free to help out to make things faster..

[jbrazio]

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

[thinkyhead]

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]

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]

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

Let's fix the bugs. Then freeze.

[Roxy-3D]

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]

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]

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]

@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]

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]

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]

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]

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]

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 https://github.com/AnHardt/Marlin/pull/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]

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]

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

[GreatGrizzly]

This seems like a lot of this is semantics, release candidate this, and golden that. You all have done an incredible job with features and bug fixes, more than enough to be considered a milestone for the project.

Marlin is made for a very small specific market. This market, by its nature, has consumers that are more tech savvy than most people. This means that bugs are less of an impediment to progress because the same consumers can work around them. Bugs will never go away, ever, ever, ever.

Pick a milestone and stick to it. From my 3rd person perspective, you all have exceeded a milestone.

[thinkyhead]

Bugs will never go away, ever, ever, ever.

@GreatGrizzly We have known, confirmed, glaring bugs, and we are going to fix them before we do another release. We could use help in testing.

Pick a milestone and stick to it.

We didn't get hung up on "milestones" for 1.1.0 because we never really set any except "make it not broken." I'm sure we will make use of them more formally in future, because we have a more concrete set of goals for 1.1.1 and 1.2.0.

[Roxy-3D]

I personally would advise to branch out UBL and Roxanne 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 @thinkyhead I finished the Mesh Validation Command today. That was the one that was killing me. I now have the information (and a way to verify) the changes made by the Mesh Editor. I'm guessing I will be ready to create a fork in a week. Are you both OK with me 'releasing' it prior to us getting all of the bugs fixed in the Release Candidate?

[thinkyhead]

@Roxy-3D Release away. We'll do our best to keep it up-to-date with git rebase as needed.

[Roxy-3D]

I don't think I can do what I want to do with the GitHub Web Interface. I want to fork the version of RC-6 that existed on 07-04-2016 (on July 4th). Can you create a branch in the MarlinFirmware/Marlin domain that is derived from that? I will get all of my stuff put into that branch. If this can be done, it probably would make sense to give it a reasonable 'Unified Bed Leveling --- Development Branch' type of name. (I have no idea how we should name this kind of stuff!)

(Alternatively, I could fork today's version of RC-6 and just erase any changes that have happened since July 4th, but my guess is the first idea is cleaner)

I need to finish up the Mesh Editor, but that is not going to be difficult. All of the support routines are already in place for other reasons. The only other big thing outstanding is Grid Based Leveling, but I know how to do that. The messiest part of doing that is I want to make it selectable whether the original QR_SOLVE is used or the 10KB smaller iterative version is used. I'm committed to getting the Grid Based Leveling going, but the honest truth is, it isn't needed. When it comes to Auto Bed Leveling, the High Resolution Mesh approach really is the Cat's meow! @epatel pioneered an important new technology with Mesh Leveling!

Oh! And right now Delta's have never been tested. (My Delta is still apart but getting it going on Delta's shouldn't be too hard once I have a machine to test on.) It probably makes sense to do a staged release with Cartesian being done first. They are so much easier to debug.

[jbrazio]

@Roxy-3D here you go: https://github.com/MarlinFirmware/Marlin/commits/devel-ubl

The last commit on that branch is:

commit e48502866b23909eca7d21d8f0d4d1e33402135e Merge: d70197f 840e13f Author: Scott Lahteine thinkyhead@users.noreply.github.com Date: Mon Jul 4 01:19:31 2016 -0700

You should update your personal fork of Marlin and use PR to publish to this new branch, please do not commit directly to it !

[Roxy-3D]

You should update your personal fork of Marlin and use PR to publish to this new branch, please do not commit directly to it !

Oh? I don't have a personal fork. I have a Marlin directory with all of the files in it. I was going to cut & paste every file into the new branch. Can I fork this July 4th branch (to make a personal fork of Marlin) and do direct commits to that without screwing things up? If so, maybe we can merge the two branches back together again?

The only things that are going to show up as 'different' are the things it takes to get UBL in its launch (and working) state.

[thinkyhead]

After you make a fork of Marlin under your account and clone it to your local machine, you can use the git command line (!) to create the branch you need from any point in time. For example, July 4 at noon. I believe that your local timezone applies.

git checkout 'RCBugFix@{2016-07-04 12:00:00}' -b my_july_four_branch

[Roxy-3D]

Can I fork this July 4th branch (to make a personal fork of Marlin) and do direct commits to that without screwing things up? If so, maybe we can merge the two branches back together again?

Will this work to get everything into the system? Does it screw up anything important (like the audit trails or who knows what) if I do this? Every time I've tried to use git from a command line, I've had to reload the operating system (and all my programs). So I really don't want to do that until the source code is safe up on GitHub.

[thinkyhead]

Gosh. Fix that OS so you can use the command line. It is pretty vital. And there's no reason for humble command-line git to have any crazy effect on your system.

[thinkyhead]

fork this July 4th branch

You don't fork branches. You fork repositories. The branches in your repository are separate from those in the main repository, and you can modify them all you want without any effect on this repository.

[Roxy-3D]

Thank you for the the comments! I'll re-read them in the morning (twice). I agree I need to learn how to use Git. But that can wait a few weeks. Right now, I'm focused on getting the new development branch ready to launch.

@thinkyhead @jbrazio You both have Prusa i3 type machines, right? Do you both have Ultra 20x4 LCD Panels? I'm hoping the answer to both questions is a "Yes!"

[jbrazio]

@Roxy-3D I have both LCD, a full graphical one and a 20x4. Why the question ?

[Roxy-3D]

I've tried to be clean and correct how I did things. But first, I'm almost positive the code won't work on a Delta just because they are such a pain in the butt to get to move right. Almost for sure I've over looked something. It won't be hard to get the code running on a Delta, but it will have to be done by somebody that has a Delta. (My Delta is not running at the moment. If nobody beats me too it, I'll get my Delta put back together and get the code running there next. Realistically... That is several weeks from now.)

The same thoughts apply to the 20x4 LCD Panel. I've tried to cut into the LCD Code in a precise and surgical manner. But I only have a 20x4 LCD Panel to test against. Almost for sure I've missed something. So what I was hoping was you both had Prusa i3 like machines with 20x4 LCD Panels. If you make the minimum number of changes to the Configuration.h file, such as bed size and homing direction and inversion of stepper directions.... (That kind of stuff) It is going to work for you. And you will be able to see it run.

If you can see it work, then it will be less difficult to know what is supposed to happen on a machine type where it doesn't (quite yet) work.

[thinkyhead]

… have Ultra 20x4 LCD Panels?

I do, but currently the graphical display is connected because I was focusing on code for that.

LCD Code in a precise and surgical manner

If you only modify ultralcd.cpp and not the ultralcd_impl_*.h files then you should be fine.

[thinkyhead]

need to learn how to use Git. But that can wait

@Roxy-3D Seriously, don't wait. You can't do any of what you want to do without command-line Git. You can't copy a branch from upstream without it. You can't even create a reference to upstream (this repository) without it. You can't create a branch from a specific date without it. You can't get into the flow and produce decent pull requests without it.

To get this ball rolling, please zip your copy of Marlin and send it to me. I will create a UBL branch in this repository (or my fork), which you can later copy to your own fork. Is it still correct that the best starting-point is the last commit from July 4? In other words, that is where your UBL code started from?

I will start with the given date, then drop in your updated files and try to parcel them out into commits by theme. After that I will attempt to rebase these commits on the latest code. With any luck it won't be too difficult. This might take me a couple of hours. I would rather you spent those hours to learn some basic Git, then I would have time to do other things!

• Git tutorial videos (Windows): https://www.youtube.com/watch?v=j1oFazXrzN4
• A great written tutorial: https://www.atlassian.com/git/tutorials/using-branches/git-branch
• A great interactive tutorial: http://learngitbranching.js.org/

[Roxy-3D]

… have Ultra 20x4 LCD Panels? I do, but currently the graphical display is connected because I was focusing on code for that. If you only modify ultralcd.cpp and not the ultralcdimpl*.h files then you should be fine.

Yes, I've only needed to make a few tweaks in ultralcd.cpp. Right now I'm fighting with it to get the Mesh Editor fully working. But my changes are very simple and only in a few places. So who knows? Maybe it will work with the full graphics controller? I guess we will know soon enough.

need to learn how to use Git. But that can wait @Roxy-3D Seriously, don't wait. You can't do any of what you want to do without command-line Git. You can't copy a branch from upstream without it. You can't even create a reference to upstream (this repository) without it. You can't create a branch from a specific date without it. You can't get into the flow and produce decent pull requests without it.

Yes. I know I'm handicapped without it. And I do want to learn it and become proficient at it. But Joao made me the July 4th branch I needed and I've forked that over in my repository. As soon as I get the Mesh Editor fully running and checked out, I'll put all of my changes there. At that point, the Grid Based Leveling won't be in the code yet, but I know how to do that. It shouldn't take long to get that in place. Check out the Readme file: https://github.com/Roxy-3D/Marlin/blob/RC/README.md

To get this ball rolling, please zip your copy of Marlin and send it to me. I will create a UBL branch in this repository (or my fork), which you can later copy to your own fork. Is it still correct that the best starting-point is the last commit from July 4? In other words, that is where your UBL code started from?

If you want, I can do that. But I think I have everything I need to get my changes into a fork of the July 4th branch. I was tracking your changes pretty closely, but at July 4th, I started just focusing on my code. So, currently there are some changes you have made since July 4th that I do not have.

I will start with the given date, then drop in your updated files and try to parcel them out into commits by theme. After that I will attempt to rebase these commits on the latest code. With any luck it won't be too difficult. This might take me a couple of hours. I would rather you spent those hours to learn some basic Git, then I would have time to do other things!

The problem is the changes are all over the place. Without all of the changes, nothing is going to work. So the question I have is: Does it make sense to break the package apart into smaller commits ?

I'll try to watch those videos as soon as I get the Mesh Editor running right.

[thinkyhead]

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]

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]

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

I look forward to taking it all in.

[Roxy-3D]

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]

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 git@github.com: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.