Marlin: UBL->RCBugFix? Comments/Thoughts/Discussion?

[bgort]

After spending a few hours over the weekend looking through the commits to devel-ubl and RCBugFix (pursuant to adding BLTouch support to devel-ubl), it seems that it's likely easier to bring all of the devel-ubl changes into RCBugFix than to bring all of the RCBugFix changes into devel-ubl. Thoughts? Comments?

Though I know Roxy has mentioned bringing RCBugFix changes into devel-ubl several times, and I know this is a bit 'early', I'm willing to work on sync'ing the branches (and have already started, even) if this is an acceptable way to get UBL features into the mainline.

Not trying to jump the gun, of course, but thought opening an issue would stimulate discussion that could yield a direction for the 'merge'.

@thinkyhead? @Roxy-3D? Anyone else?

(Apologies if this has been or is already being discussed elsewhere - I didn't see it.)

[Roxy-3D]

I think it is very possible you are correct that it is easier to move the UBL functionality to RCBugFix instead of the other way around. Most of the UBL changes are in big sections all grouped together. Especially things like the G26, G29, and the Mesh_Buffer_Line code. The one big exception to this statement are the little changes done to the LCD Panel code. The good news is those changes are well commented and should not be difficult to identify when doing a 3-way merge. (I'm thinking a 3-way merge of RC-7, RCBugFix and UBL would be a good way to proceed.)

The other place where some careful consideration is needed is the Configuration.h file. There are some various Auto Bed Leveling items that are not used and should be cleaned up. And also, the way I've tried to group things is different than how they are in RCBugFix's Configuration.h file, so that may take some extra care. It maybe the 'right' answer is to just take the few changes that have been made to RCBugFix's Configuration.h file and cross those over to the UBL Configuration.h file. (And use that with the new branch.)

It you have the time and energy to get the UBL code synchronized with the current RCBugFix, I'll switch over to your branch in a heart beat.

[bgort]

It you have the time and energy to get the UBL code synchronized with the current RCBugFix, I'll switch over to your branch in a heart beat.

That's the catch - time and energy. I can definitely work on it, but the time and energy I have to commit to it are variable (which is probably true for everyone). When do you envision the merge/RC8 occurring? Days, weeks, months?

[Roxy-3D]

Right now the agreed upon plan between myself and ThinkyHead is we would do the merge when RC-8 goes final and is declared 'Stable'. Part of the reason for that is some stuff in RC-7 is going back and forth and it is simpler to just wait and see where it ends up. And I guess that is true of the UBL code as well.

The soonest the 'Merge' to bring UBL current with RC-8 could happen would be 6 weeks out. But really, I think it will be more like 10 or 12 weeks. If for no other reason than ThinkyHead is super busy right now.

So... Even if you are busy, you would be able to beat our schedule. And it would be a big help to us to get a preliminary version done that reflected the current state of where RC-7 is at.

[thinkyhead]

Some rewriting will be required when we integrate UBL, since we've made a lot of changes to homing and leveling since UBL split off. I'll probably be a total pain in the ass about keeping to standards. But we'll cross that bridge when we come to it! I want to keep Marlin friendly for vendors who may want to customize the G28 and G29 behavior for one-button simplicity.

[bgort]

The soonest the 'Merge' to bring UBL current with RC-8 could happen would be 6 weeks out. But really, I think it will be more like 10 or 12 weeks. If for no other reason than ThinkyHead is super busy right now.

That helps. Plenty of time, then, really.

So... Even if you are busy, you would be able to beat our schedule. And it would be a big help to us to get a preliminary version done that reflected the current state of where RC-7 is at.

I'm just going to keep working through it, then, time permitting. I'll push my local work-in-progress branch - where I've already done quite a bit - to github sometime late next week (I'm out of town at the moment) and I'll just work on the 3way merge as I have time. When I'm done you can steal/refork my branch and take over, if that works for you. I may also clean up/fix some unused variables, compiler warnings, code style issues, etc.

Some rewriting will be required when we integrate UBL, since we've made a lot of changes to homing and leveling since UBL split off.

There are many, many changes in Marlin_main.cpp - some of which will take some rewriting, I think. That's where I left off. I'll do the best I can and ask questions here if/when I have them.

I'll probably be a total pain in the ass about keeping to standards. But we'll cross that bridge when we come to it! I want to keep Marlin friendly for vendors who may want to customize the G28 and G29 behavior for one-button simplicity.

Yeah, I'm generally really pedantic when it comes to standards, too. I've read your coding standards, etc.; I assume you're taking about gcode and other standards here? References?

[Roxy-3D]

Some rewriting will be required when we integrate UBL, since we've made a lot of changes to homing and leveling since UBL split off.

Actually... bgort's approach solves this issue. If he can migrate the UBL System functionality to RCBugFix, then all of those changes are included. @bgort here is something to consider: Does it make sense to move the UBL's G29 to a different number? Because that might allow the 'normal' Grid and 3-Point ABL to still be built into the firmware. And in that case, we might just turn the UBL code off. That might help the transition period by giving all options to all users.

I'll probably be a total pain in the ass about keeping to standards. But we'll cross that bridge when we come to it! I want to keep Marlin friendly for vendors who may want to customize the G28 and G29 behavior for one-button simplicity.

This isn't going to be a problem. Right now, UBL is set up with the expectation there is an LCD Panel that can be used by it. However, we should be able to easily identify the sub-commands that do not make sense without an LCD Panel and just take them away. It will be a little bit more effort for a user to get full benefit of the system without an LCD Panel, but the system can be used that way. For example, here is a simple case: G29 P0 T Will zero the entire mesh and perform a Three Point leveling on it. Doesn't that line up pretty closely with the current Three point leveling? If the user wants to adjust one corner of that 3 point leveled Mesh, that can be done also. Its just nicer to do it with an LCD Panel.

Similarly, the grid based will be the same. The code to grid level the mesh isn't in there yet, but a G29 P0 G 3 will zero the current mesh and perform a 3x3 least squares best fit on the grid. The backward compatibility will be there and should keep things close to the one-button simplicity.

[bgort]

Does it make sense to move the UBL's G29 to a different number? Because that might allow the 'normal' Grid and 3-Point ABL to still be built into the firmware. And in that case, we might just turn the UBL code off. That might help the transition period by giving all options to all users.

I was actually thinking the same thing, and I think it's do-able. If we leave the current/'normal' G29, etc., it would definitely make it easier on users and we wouldn't have to take anything away from anyone. Transition would be much smoother. What G-number do we want to use for UBL?

[Roxy-3D]

Just pick a free one. How about G25 because if that happened, G25 and G26 (which really are designed to work together) will be right next to each other in the list.

As far as leaving the old G29 stuff... I know it won't really be this easy... But conceptually, we could add an extra #ifdef NO_OLD_SCHOOL_ABL around any of the existing G29 stuff, and where the bed correction matrix gets used in the planner. (as well as in Configuration_store.cpp). If things got setup this way, it would be easy to turn on that #define if the UBL_FEATURE is enabled (in Conditionals.h).

[adamfilip]

G25 sounds good :)

[bgort]

Sorry for the delay. Trip was extended a bit and took me a while to get caught up with other projects, etc.

Just pick a free one. How about G25 because if that happened, G25 and G26 (which really are designed to work together) will be right next to each other in the list.

G25 works for me.

As far as leaving the old G29 stuff... I know it won't really be this easy... But conceptually, we could add an extra #ifdef NO_OLD_SCHOOL_ABL around any of the existing G29 stuff, and where the bed correction matrix gets used in the planner. (as well as in Configuration_store.cpp). If things got setup this way, it would be easy to turn on that #define if the UBL_FEATURE is enabled (in Conditionals.h).

I'll look into this as I get back into things, which will be over the next few days, now that I'm caught up...

[Roxy-3D]

Please keep us informed on your progress! We are all cheering for you to be successful!

[bgort]

Will do!

[psavva]

Any updates on the progress to bring UBL into RCBugFix?

Please notify me as well to help with testing.

[Roxy-3D]

I'm on my way home right now. When I get home, I'll have a few distractions but my plan is to start moving the UBL code base onto RC-8 (or RC-8's RCBugFix). There have been so many changes since the original fork, I'm guessing it will take several weeks to get everything up and running. But I could be surprised either way.

I will be using a gMax 1.5+ as the development platform to do the migration. So, there will be a new Configuration.h file showing up in the Examples folder. And I'm going to use this effort to see if we can find some good work arounds for the BL-Touch issues we have seen.

[psavva]

Hi Roxy, is there any chance to still have this taken into RCBugFix?

[Roxy-3D]

Hi Roxy, is there any chance to still have this taken into RCBugFix?

Yes. Up until a couple of days ago, I was still trying to get RC-8's RCBugFix changes moved to UBL. But I can't keep up with all the changes. I'm thinking if I add one more entry to the Configuration.h file, I only need a few hooks in Marlin_main.cpp. And a few additions to ultralcd.cpp and configuration_store.cpp. If we were to go that way, life becomes much simpler for me and any changes or bug fixes that happen to RCBugFix are immediately available to UBL users.

/**
 * Select one form of Auto Bed Leveling below.
 *
 *  If you're also using the Probe for Z Homing, it's
 *  highly recommended to enable Z_SAFE_HOMING also!
 *
 * - 3POINT
 *   Probe 3 arbitrary points on the bed (that aren't collinear)
 *   You specify the XY coordinates of all 3 points.
 *   The result is a single tilted plane. Best for a flat bed.
 *
 * - LINEAR
 *   Probe several points in a grid.
 *   You specify the rectangle and the density of sample points.
 *   The result is a single tilted plane. Best for a flat bed.
 *
 * - BILINEAR
 *   Probe several points in a grid.
 *   You specify the rectangle and the density of sample points.
 *   The result is a mesh, best for large or uneven beds.
 *
 * - UBL - Unified Bed Leveling
 *   Experimental high resolution mesh leveling system that includes 3-Point and Grid leveling
 *   of the mesh.   Also included is an integrated Mesh Validation Pattern command and easy
 *   interactive editing of the mesh.   
 */
//#define AUTO_BED_LEVELING_3POINT
//#define AUTO_BED_LEVELING_LINEAR
//#define AUTO_BED_LEVELING_BILINEAR
#define AUTO_BED_LEVELING_UBL

[bgort]

Sorry I disappeared. I started merging several times (lots of changes between the times I had to work on it, and it was easier to just start over), then life happened and I got pulled into another project. Haven't had time to use my printer in months, but wanted to circle back/follow up here (though obviously I should have done so sooner).

Looking at the open issues, I see that UBL is being/has already been merged by @Roxy-3D, so I'll go ahead and close this issue. Hopefully I get a chance to try it out soon. Apologies again.