Move G7 to G421

[bgort]

Tested & working.

Ref #6777

[Roxy-3D]

Incidentally... The reason for G421 is it is a movement command, so G is more appropriate. But it will be used with M421 doing Mesh Edits, so it makes it easier for the user to have a similar number as this.

[bgort]

Yeah, I probably should have explained.... Sorry about that.

[thinkyhead]

Everything between G30 and G38 is probe-related. So how about using the next in line, G39? Since we'll probably start encroaching on the 40's soon, I'm also not opposed to G40. But G421 is not a reasonable association, simply because M421 happens to have ended up as the leveling options setter.

[thinkyhead]

Or… G41 — G40 is already defined for a CNC-specific function.

G40: Compensation Off (CNC specific)

[bgort]

I think G421 is pretty logical, overall, but in the end I don't much care what it is.

[thinkyhead]

Too logical. Let's just use the next number in succession, G39.

[bgort]

I'm going to be tied up for a while. Feel free to pull down the .patch and make the change.

[thinkyhead]

Went for the middle: G42!

[fiveangle]

I think we all know why M420 was chosen ;)

From my Configuration.h:

// The height can be set with M420 Z<height> // M420 Z<FADE height> #iseewhatyoudidthere

[thinkyhead]

I plead the fifth.

@bgort So, this new command moves the active nozzle to align with a grid intersection point. For added value, we should add a flag to align the probe to the grid point. I'm going to propose P.

[thinkyhead]

#6833 has the completed M42 with support for all 3 mesh leveling systems. Also patched it up so it will be compatible with workspace offsets and added that P argument. It's also documented on the RepRap wiki, and shortly I will post it on the marlinfw website also.

[bgort]

Looks great! Had one thought:

Couldn't we up-scope this (or something similar):

 +      #if ENABLED(AUTO_BED_LEVELING_BILINEAR)
 +        #define _GET_MESH_X(I) bilinear_start[X_AXIS] + I * bilinear_grid_spacing[X_AXIS]
 +        #define _GET_MESH_Y(J) bilinear_start[Y_AXIS] + J * bilinear_grid_spacing[Y_AXIS]
 +      #elif ENABLED(AUTO_BED_LEVELING_UBL)
 +        #define _GET_MESH_X(I) ubl.mesh_index_to_xpos(I)
 +        #define _GET_MESH_Y(J) ubl.mesh_index_to_ypos(J)
 +      #elif ENABLED(MESH_BED_LEVELING)
 +        #define _GET_MESH_X(I) mbl.index_to_xpos[I]
 +        #define _GET_MESH_Y(J) mbl.index_to_ypos[J]
 +      #endif

...so those functions are available everywhere? Those are pretty commonly used, I believe. I might be able to do it later today, if it's something worth doing.

[Roxy-3D]

All of the mesh schemes now have look up arrays for the X & Y mesh points (lines).

To your point... Can we get them all to use the same indexing and names??? Because if we did that, we cut out a bunch of #if's and #ifdef's

[bgort]

Yeah.. that's where I was going. Would be nice to start consolidating...or at least heading in that direction by upscoping things like this.

[thinkyhead]

If the code in those macros could be scoped up, I would do that. But bilinear leveling doesn't use the coarse grid like this anywhere else, so it's a one-off. Meanwhile, MBL is deprecated and slated to be removed in Marlin 1.2, because BILINEAR with PROBE_MANUALLY does everything MBL used to do.

Anyway, UBL's grid is permanently fixed, while the bilinear leveling grid can change position and size. So it can't share the same technique as UBL.

Right now I think it's good to keep these things separate from one another while we work on a higher-level design for a bed leveling class that will be worthy of 1.2.x. Apart from fixing bugs and making things work better, let's not do too much within the 1.1.x codebase. I really (really, really) want to get on with 1.2.x and the new file layout before we dive into the higher level design and bed leveling class.

[bgort]

Didn't know MBL was going to be removed, but it surely makes sense. UBL does what it does now, and better/more.

Is there a roadmap with these kinds of things anywhere? 😁

[thinkyhead]

The roadmap is "in my head," but awaiting an appropriate period of relative quiescence to dive in. I figure right now we should be focusing on complaints about bugs in 1.1.1 and on making the current release solid.

So: code cleanup, refinements, optimizations, adding language translations for UBL's LCD strings…. all that finishing and polishing work is what we should be focused on at this time.

I'm using this time as an opportunity to look closer at the issues we hear about more often, like screen glitches and so on, to do some refactoring in preparation for the 1.2 layout, and to start preliminary work on a redesign of ultralcd.cpp menus to make the code smaller and easier to work with. — A proper user interface events API that command handlers can use.

It also falls on me to make sure that all the open PRs are refreshed and ready for the latest code-base, so if they aren't merged into 1.1.x then they will be ready for 1.2.x.

The "roadmap" up to the present time (and this still applies) was to neaten the code's readability and make it more standard, to examine every corner of the code and ferret out bugs and bad ideas, and to bring in all those half-started or long-requested features that had been sitting around. It took us over 2 years to accomplish that much.

So now we are at a great point to do these high level redesigns and think things through, but the time is not yet fully ripe. We really need to get to a "stopping point" where we can pause, refactor the code into the 1.2 file layout, publish a 1.2.0 release, and go on from there.

I'd like to get to that point soon, because the flat file layout is long overdue for retirement.

[Roxy-3D]

From another perspective:

The only way we would get a well defined 'Road Map' is to have a Project Manager dictating and controlling things. There are a lot of volunteers for that position. But there doesn't seem to be a lot of developers that want to 'anoint' those people. And in fact... It is some effort to keep those people out of the mix.

As a much smaller example, just for the sake of discussion, consider the 32-Bit stuff. Marlin needs to run on 32-Bit platforms. There are people asking for a 'Road Map' of the 32-Bit development plans. Here for example: #6373 (comment)

Things are not structured like that. About all I can say is "We really do want Marlin running on a 32-bit platform. But we also want a shared code base with the 8-bit AVR stuff. We will do what we can to help the development of the 32-bit code base. I'll even go so far as to merge bits and pieces of the 32-bit work into the main branch IF IT DOESN'T BREAK THE AVR code to help it make progress. " #6373 (comment)

But ultimately... The Open Source world and especially the RepRap part of that world are chaotic. That chaos drives a lot of people bat shit crazy. It is what it is...

[bgort]

The roadmap is "in my head," .. snip

Understood, and it's good that you have a roadmap in your head, though I do think the sooner you have a one in writing (that others can look at, comment on, add to, etc.), the better. For probably ~half a dozen reasons.

A few:

• Coding time is being wasted (yours and ours) because others don't know what's next, where you plan to go with things, etc. If this were more of a group project it wouldn't matter so much, but as things are now (where it's mostly you directing things), it'd be better if you outlined your goals and communicated more wrt direction;
• Time is being spent talking about things that don't make sense because people don't know better (the last few comments of this topic, for instance);
• Having a roadmap can add discipline and rigor to work and ultimately improve the end product, sometimes dramatically (as long as things aren't too restrictive/strict);
• You're applying the standards, plans, etc. that you have in your head to the work of others, and when you override what they're doing (or have done) based on something they don't/can't know anything about, it can be frustrating, demotivating, and makes their efforts feel like (at least a partial) waste of time, which ultimately pushes people away; and,
• Having things written down and watching them get checked off is pretty motivating for most people.

Take the above for what it's worth, of course...

[bgort]

The only way we would get a well defined 'Road Map' is to have a Project Manager dictating and controlling things. There are a lot of volunteers for that position. But there doesn't seem to be a lot of developers that want to 'anoint' those people. And in fact... It is some effort to keep those people out of the mix.

I really don't think that's necessary or wise (which is what you're saying, I think). I think we can collectively create a 'project roadmap' that developers can refer to/review, contribute to, and/or ignore, as necessary. Nothing needs to change about how things get decided on, incorporated/merged, used, etc. Having some kind of rough guide / plan for efforts like this is nearly always a good thing.

...

Obviously I'm still relatively new to this project, but I know there have already been occasions where I've felt my time could have been better spent (or my code better structured or optimized) if I'd known X, Y, or Z, etc. I'm sure others have felt that way, too.

For instance, now that I know MBL is going to be removed in the not-too-distant future, I won't bother including anything to do with it in the 'mesh allocation table' code I'm still working on (hopefully done sooner than later) ... I don't know much about how MBL works, and I would have been irritated if I'd spent time (maybe hours?) figuring it out so I could implement things properly, only to see it all removed a month later. I hope that makes sense.

But ultimately... The Open Source world and especially the RepRap part of that world are chaotic. That chaos drives a lot of people bat shit crazy. It is what it is...

Understood. I guess I'm just arguing for a little less chaos and a little more structure (which is something I used to get paid pretty well to help with) .. I think you'd have more (maybe significantly more) engagement from developers, and the end product would really benefit.

[Roxy-3D]

Understood. I guess I'm just arguing for a little less chaos and a little more structure (which is something I used to get paid pretty well to help with)

Yeah... I actually am sympathetic to your points up above. The key is to get the core group bought into and in general agreement of the direction. And that requires more discussion than what has been going on. I don't know that it takes a lot more discussion... But as the development group grows larger, time does need to be spent on communications. If for no other reason than to make sure people can see the same vision and are at least some what in agreement.

That is the big difference between doing a small piece of code that can be done by one person and doing a large software project. Ideas, interfaces, support routines, etc all need to be communicated (and at least somewhat agreed upon).

[thinkyhead]

@Roxy-3D @bgort @Bob-the-Kuhn

I think as long as the devs with merge privileges —Owners— are aware of where we are, it will coordinate better. I've expressed here and there the story with MBL and my hope to move quickly to the 1.2 layout, but of course this isn't being transmitted to every Contributor. Rather, the Owners can just apply triage since we control what ultimately goes in…

• Address issues that relate to bugs and shortcomings first and foremost.
• Mark new features with the 1.2 milestone and ask contributors to be patient.
• Restrain all further self-driven work on our favorite focus areas till we have the new file layout.

I'd enjoy some discussion in a hangout about the next steps for Marlin (1.2). Personally, I have two areas I want to focus on for 1.2.0: A new ultralcd events/menus/screens API that also encapsulates the LCD code into a singleton, and more integration of bed leveling with the Planner class. Of course, before all that the new file layout.

How possible do you think it is for us to staunch the flow of new code, keep patching up the existing code, and give ourselves a 2 or 3 day break (weekend) to move over to the new file layout and do a 1.2.0 release? If we were to do that sooner rather than later, then I don't mind taking the existing PRs and bringing them over into the new file layout as well, as much work as that may be. It will be a good opportunity to get used to the flow of working with a lot more smaller source files.

[Roxy-3D]

How possible do you think it is for us to staunch the flow of new code, keep patching up the existing code, and give ourselves a 2 or 3 day break (weekend) to move over to the new file layout? If we were to do that sooner rather than later, then I don't mind taking the existing PRs and bringing them over into the new file layout as well, as much work as that may be. It will be a good opportunity to get used to the flow of working with a lot more smaller source files.

The answer is "Very easy!" We just get concensous from everybody with check in priviledges that that is the plan. But if we are going to move to a new file hierarchy, can we also include the 32-bit files in the work? Specifically #6228 ? And give them a place in the hierarchy where it is clear the 32-bit work can continue????

If we were to do this... I think we FREEZE all changes (except emergency bug fix type things) in bugfix_v1.1.0 and we start a new branch that won't work initially. And we focus on getting that new branch up and tested... Realistically... I think if we worked hard at it, we are really talking more than a week of time (especially with the testing on the back side of the work). Personally, I don't think this has to be done over a weekend. People have bugfix_v1.1.0 to use while this work happens. And really... This work is going to span several weekends!!!!

[bgort]

I think as long as the devs with merge privileges are aware of where we are, it will coordinate better.

That's what I'm arguing for more of, at base.. '(more) devs knowing where we are' ..

I've expressed here and there the story with MBL and my hope to move quickly to the 1.2 layout, but of course this isn't being transmitted to every contributor.

Yeah, I hadn't caught it until now. I did know about the coming layout changes, however.

I'd enjoy some discussion in a hangout about the next steps for Marlin (1.2). Personally, I have two areas I want to focus on for 1.2.0: A new ultralcd events/menus/screens API that also encapsulates the LCD code into a singleton, and more integration of bed leveling with the Planner class. Of course, before all that the new file layout.

Why move the discussion to somewhere other than here? Having everything in one place, where anyone can access it, is better overall, in my opinion. (Also, I don't like the 'evil empire' and am opposed to using their 'free' services, generally speaking.)

How possible do you think it is for us to staunch the flow of new code, keep patching up the existing code, and give ourselves a 2 or 3 day break (weekend) to move over to the new file layout? If we were to do that sooner rather than later, then I don't mind taking the existing PRs and bringing them over into the new file layout as well, as much work as that may be. It will be a good opportunity to get used to the flow of working with a lot more smaller source files.

Very possible, in my opinion. I think all you need to do is make sure the core devs are okay with it, then announce that that's where we're going and tell everyone there'll be a 'new feature freeze' starting on X date, with only bug fixes until Y date, and then a hard freeze after Z date until the changes related to the new layout are finished. Or something along those lines.

Personally, I think doing the layout changes sooner is a good idea, and I'm happy to help with that. Then after the change, maybe we can let it bake for a few days or a week with only bugfixes and the feature freeze still in effect, then tag it 1.2.0 once we know it's going to work for the majority of users? And then things can pick up where they stopped?

FWIW, all I'm working on right now is the MAT (mesh allocation table) code, which is and should be mostly contained to configuration_store.cpp, and some changes to G26 (adding new patterns that enable faster validation of a mesh). Both of these can wait - things are working pretty well as they are now, in my opinion - and I don't mind rebasing/moving things over later.

Anyway, what do you have in mind for the layout changes, specifically? What will go where? Separate directories for configuration, pins files, languages, therm tables, etc. ?

I'm also happy to help transition other outstanding PRs to the new layout, too, after the change is made.

[Roxy-3D]

@bgort @Bob-the-Kuhn @thinkyhead

I'd enjoy some discussion in a hangout about the next steps for Marlin (1.2). Personally, I have two areas I want to focus on for 1.2.0: A new ultralcd events/menus/screens API that also encapsulates the LCD code into a singleton, and more integration of bed leveling with the Planner class. Of course, before all that the new file layout.

I think I agree. I think the plan that makes sense is we discuss and agree on the new file layout... Get that up and running and fully debugged. And we call that v1.2.0 And then we build on that to get the callback stuff working in ultralcd and what ever else needs to be done to the planner. (And obviously... (at least to me) It would be easier to re-organize the file structure if there was a code freeze while that was happening.)

Why move the discussion to somewhere other than here? Having everything in one place, where anyone can access it, is better overall, in my opinion. (Also, I don't like the 'evil empire' and am opposed to using their 'free' services, generally speaking.)

In general I agree. I would prefer to error on the side of full transparency to the user base. But in this case I believe it makes sense to get closure in a hangout session and then fully communicate the direction and thinking to our users. I believe I have everybody's email addresses. So I can set up the invite. Mid afternoon works best for me but I'll give up a Friday Night of darts if that is what it takes to get the required overlap. Thinky is probably the hardest one for us to work around. How about I send out the invite to everybody and we just hold off on any serious discussion until everybody is there?

UPDATE: Bob, do I have your email address? I can't seem to find it...

I think as long as the devs with merge privileges are aware of where we are, it will coordinate better.

That's what I'm arguing for more of, at base.. '(more) devs knowing where we are' ..

Thinky and I have had a hangout conversation box for a year. We hardly ever use it. But if we get this organized... It would make sense to just leave this chat box alive and never totally kill it. It is a good way to communicate important issues or get a quick answer to an question....

[bgort]

While I think it's good to have a design/architecture/development-related conversation, I do still think it should be public and easy for anyone to join. If there are disruptive people, etc., they can be asked to leave, removed, silenced, blocked, or whatever.

I can't in good conscience use a Google service. Don't mean to be difficult, but I'm not interested in being the product, feeding their AI, or facilitating whatever else they do with whatever information people pump into their databases.

I'm fine with IRC (freenode?), XMPP (federated, so virtually any network), or virtually anything that isn't a social network or data aggregator.

[thinkyhead]

if we are going to move to a new file hierarchy, can we also include the 32-bit files in the work?

I think so. It would be easier to do the HAL integration onto bugfix-1.1.x first —especially since we already have that in working (or very near working) shape— and then afterward split up the remaining source files into the new hierarchy. That way all the distributed changes will be present as the code is being reorganized.

[Roxy-3D]

I'm not sure I fully understood that. But here is how I see it: What ever 32-Bit stuff gets moved over to the new file system, it doesn't even have to be perfect. It just has to be good enough the 32-bit guys can use it. Because one of the first things they might do is submit a Pull Request to re-layout the HAL files how they want it done....

But at that point... They are always working with the current code base.