CODERS needed...... yep again

[boelle]

We have one very active coder in @thinkyhead have done a lot of work lately and been very active in general

That said i don't mean that others have not been active also, but we could use more coders that could focus very narrowly on the issues in the milestones.

8 issues left and we can go for a code freeze and test the hell out of it.

After that i think its cleanup time and code reducing and then another test.

After that again i think its time to look at the feature request issues :-D

[thinkyhead]

I count @AnHardt, @alexborro, @fmalpartida, @MagoKimbra, @clefranc, @Wurstnase and @galexander1 among the other very excellent contributors, especially as they keep catching all my bugs!

[boelle]

hehe,

what i was thinking is that you almost do all the work... a shame i cant code or i would have helped out :-/

but yes people catching bugs and testing is also a great help

now over to my endstop wodo and see if i cant get it working so i can start testing the hell out of the dev code

[Roxy-3D]

ThinkyHead: I see you moved the #define for TOPO_ORIGIN to the Configuration.h file. I'm certainly willing to help out on the code changes and bug fixes, but I need clearer guidance on what needs to be done. There does not seem to be agreement on the direction of the code base.

For example Alex Borro in that thread clearly wanted the code simplified. He felt one extra #define for TOPO_ORIGIN was too much extra complexity. And in a different thread I suggested the 3-Point Bed Leveling had served its purpose to get Auto Bed Leveling proven and up and running. I argued it should be removed because it didn't really serve a purpose any more and added a lot of code and complexity. (And in fact, it was causing compile and build issues for people because they didn't have it set up right). Boelle argued it was already in the code base and should be left there.

Perhaps you can see my point? To an 'outsider', the direction of the code base is not clear. I'm willing to spend days to write code and help out! I love Marlin. But I don't want to be involved in a project where I spend days of time writing and debugging code just to find out the effort wasn't pointed in the right direction and the work gets ignored.

PS. I really do like the way you simplified the G29! If the 3-Point Auto Bed Leveling ends up getting pruned out of the code base I would suggest we put in a few lines of comments to explain it was there at the start (and who did it). But also have those comments explain it was just laying the foundation for what ultimately replaced it and why.

[boelle]

https://github.com/MarlinFirmware/Marlin/milestones

is the list of bugs we work on... you dont have to follow any order, but oldest bugs are mainly in first milestone..

2015-03-20 15:14 GMT+01:00 Roxy-3DPrintBoard notifications@github.com:

ThinkyHead: I see you moved the #define for TOPO_ORIGIN to the Configuration.h file. I'm certainly willing to help out on the code changes and bug fixes, but I need clearer guidance on what needs to be done. There does not seem to be agreement on the direction of the code base.

For example Alex Borro in that thread clearly wanted the code simplified. He felt one extra #define for TOPO_ORIGIN was too much extra complexity. And in a different thread I suggested the 3-Point Bed Leveling had served its purpose to get Auto Bed Leveling proven and up and running. I argued it should be removed because it didn't really serve a purpose any more and added a lot of code and complexity. (And in fact, it was causing compile and build issues for people because they didn't have it set up right). Boelle argued it was already in the code base and should be left there.

Perhaps you can see my point? To an 'outsider', the direction of the code base is not clear. I'm willing to spend days to write code and help out! I love Marlin. But I don't want to be involved in a project where I spend days of time writing and debugging code just to find out the effort wasn't pointed in the right direction and the work gets ignored.

PS. I really do like the way you simplified the G29! If the 3-Point Auto Bed Leveling ends up getting pruned out of the code base I would suggest we put in a few lines of comments to explain it was there at the start (and who did it). But also have those comments explain it was just laying the foundation for what ultimately replaced it and why.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1648#issuecomment-84024989 .

[alexborro]

I agree with Roxy.

Does someone see any reason to keep 3 points leveling in the code? I don't.

And about the bed topology.. I think the right orientation is Front Left. Anything else is not standard and pointless. I don't like to keep a complex code for 0.1% of people who are off standard for no reason. I'm implementing an improvement for Topology and will do it Only for Front Left orientation. Otherwise I will need 4x more time and effort..

Cheers.

Alex. Em 20/03/2015 11:17, "Bo Herrmannsen" notifications@github.com escreveu:

https://github.com/MarlinFirmware/Marlin/milestones

is the list of bugs we work on... you dont have to follow any order, but oldest bugs are mainly in first milestone..

2015-03-20 15:14 GMT+01:00 Roxy-3DPrintBoard notifications@github.com:

ThinkyHead: I see you moved the #define for TOPO_ORIGIN to the Configuration.h file. I'm certainly willing to help out on the code changes and bug fixes, but I need clearer guidance on what needs to be done. There does not seem to be agreement on the direction of the code base.

For example Alex Borro in that thread clearly wanted the code simplified. He felt one extra #define for TOPO_ORIGIN was too much extra complexity. And in a different thread I suggested the 3-Point Bed Leveling had served its purpose to get Auto Bed Leveling proven and up and running. I argued it should be removed because it didn't really serve a purpose any more and added a lot of code and complexity. (And in fact, it was causing compile and build issues for people because they didn't have it set up right). Boelle argued it was already in the code base and should be left there.

Perhaps you can see my point? To an 'outsider', the direction of the code base is not clear. I'm willing to spend days to write code and help out! I love Marlin. But I don't want to be involved in a project where I spend days of time writing and debugging code just to find out the effort wasn't pointed in the right direction and the work gets ignored.

PS. I really do like the way you simplified the G29! If the 3-Point Auto Bed Leveling ends up getting pruned out of the code base I would suggest we put in a few lines of comments to explain it was there at the start (and who did it). But also have those comments explain it was just laying the foundation for what ultimately replaced it and why.

— Reply to this email directly or view it on GitHub < https://github.com/MarlinFirmware/Marlin/issues/1648#issuecomment-84024989

.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1648#issuecomment-84027513 .

[nophead]

3 point uses far less code because it is a simple matrix rotation. The grid version pulls in code to do the least squares fit, which is large.

On 20 March 2015 at 14:40, alexborro notifications@github.com wrote:

I agree with Roxy.

Does someone see any reason to keep 3 points leveling in the code? I don't.

And about the bed topology.. I think the right orientation is Front Left. Anything else is not standard and pointless. I don't like to keep a complex code for 0.1% of people who are off standard for no reason. I'm implementing an improvement for Topology and will do it Only for Front Left orientation. Otherwise I will need 4x more time and effort..

Cheers.

Alex. Em 20/03/2015 11:17, "Bo Herrmannsen" notifications@github.com escreveu:

https://github.com/MarlinFirmware/Marlin/milestones

is the list of bugs we work on... you dont have to follow any order, but oldest bugs are mainly in first milestone..

2015-03-20 15:14 GMT+01:00 Roxy-3DPrintBoard notifications@github.com:

ThinkyHead: I see you moved the #define for TOPO_ORIGIN to the Configuration.h file. I'm certainly willing to help out on the code changes and bug fixes, but I need clearer guidance on what needs to be done. There does not seem to be agreement on the direction of the code base.

For example Alex Borro in that thread clearly wanted the code simplified. He felt one extra #define for TOPO_ORIGIN was too much extra complexity. And in a different thread I suggested the 3-Point Bed Leveling had served its purpose to get Auto Bed Leveling proven and up and running. I argued it should be removed because it didn't really serve a purpose any more and added a lot of code and complexity. (And in fact, it was causing compile and build issues for people because they didn't have it set up right). Boelle argued it was already in the code base and should be left there.

Perhaps you can see my point? To an 'outsider', the direction of the code base is not clear. I'm willing to spend days to write code and help out! I love Marlin. But I don't want to be involved in a project where I spend days of time writing and debugging code just to find out the effort wasn't pointed in the right direction and the work gets ignored.

PS. I really do like the way you simplified the G29! If the 3-Point Auto Bed Leveling ends up getting pruned out of the code base I would suggest we put in a few lines of comments to explain it was there at the start (and who did it). But also have those comments explain it was just laying the foundation for what ultimately replaced it and why.

Reply to this email directly or view it on GitHub <

https://github.com/MarlinFirmware/Marlin/issues/1648#issuecomment-84024989

.

Reply to this email directly or view it on GitHub < https://github.com/MarlinFirmware/Marlin/issues/1648#issuecomment-84027513

.

Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1648#issuecomment-84033771 .

[Roxy-3D]

3 point uses far less code because it is a simple matrix rotation. The grid version pulls in code to do the least squares fit, which is large.

3 Point is inherently 'weak' because any error gets magnified in the unprobed corner. And while it might appear this thread is going way off topic, this is a useful exercise to work through because it highlights the point I was trying to make.

[nophead]

The points should be two corners and the mid point of the opposite side, or as near as the probe can get to that. If the bed is flat then that is all that is needed.

[JustAnother1]

To attract more coders IMHO two things are needed: 1.) road map and direction of where marlin should go (Just having a list of Bugs basically means Marlin is at the end of development and now in maintenance phase, not very attractive to developers) 2.) good documentation of the code. This means not only comments in the code and good readable code, but also documents that explain how things like bed leveling, step generation, PID,.. work. And some overview document that explains which part of the code does what. This is a lot of work. (also no coders can contribute here) but it will also help the people involved to better understand the projects. So this should be a worth wile effort.

The question that remains is how to get this organized. here again non coders are invited to help with Ideas. It does not make sense if one coder does this. Because then only he will understand the documentation, and it will be his road map. The other point is that this can not be something destined for a milestone. This has to be an ongoing thing that never finishes.

A trick to get something like this going it to make organizational changes. So requesting that before someone comes around with a pull request he should start with writing the documentation for the feature he want to add. Then others (here also non coders) can look at it and give feedback. This way the first version has the chance to be even better. Than the pull request with the feature would be the next step.

But then again perhaps Marlin is in the maintenance phase, then just do nothing and continue as before,..

[Roxy-3D]

To attract more coders IMHO two things are needed: 1.) road map and direction of where marlin should go (Just having a list of Bugs basically means Marlin is at the end of development and now in maintenance phase, not very attractive to developers)

Agreed! But right now the Marlin code base has grown to the point where it really makes sense to clean up the code and do a bug fix phase. I think most serious developer types that are interested in Marlin would agree. And in fact, I'm impressed with how much 'cleaner' the code is since this phase started.

As far as being perpetually in a maintenance phase, I don't think most coders would see it that way. The whole purpose of the maintenance phase is to get solid ground to build on later. As well as get rid of flakey crashes and problems that people are seeing in their printers today. Development is much funner than bug fixing, but my guess is any serious developer knows the importance of clean code bases!

2.) good documentation of the code. This means not only comments in the code and good readable code, but also documents that explain how things like bed leveling, step generation, PID,.. work. And some overview document that explains which part of the code does what.

...

A trick to get something like this going is to make organizational changes. So requesting that before someone comes around with a pull request he should start with writing the documentation for the feature he want to add. Then others (here also non coders) can look at it and give feedback. This way the first version has the chance to be even better. Than the pull request with the feature would be the next step.

This level of process might be a turn off to a lot of good coders. But with that said, I think it would be perfectly reasonable to say "if you add any new feature, it needs to be fully commented along with a description of the parameters and how it works." For example, here is the comment block in front of the M48 Z_PROBE_REPEATABILITY_TEST I did. I think I would argue any new code should have this and probably it would make sense to go back and update the rest of the GCode commands too.

/**

• M48: Z-Probe repeatability measurement function. *
• Usage: M48 [n#] [X#] [Y#] [V#] [E] [L#]
• n = Number of samples (4-50, default 10)
• X = Sample X position
• Y = Sample Y position
• V = Verbose level (0-4, default=1)
• E = Engage probe for each reading
• L = Number of legs of movement before probe

• This function assumes the bed has been homed. Specifically, that a G28 command has been issued prior to invoking the M48 Z-Probe repeatability measurement function. Any information generated by a prior G29 Bed leveling command will be lost and need to be regenerated.

  The number of samples will default to 10 if not specified. You can use upper or lower case letters for any of the options EXCEPT n. n must be in lower case because Marlin uses a capital N for its communication protocol and will get horribly confused if you send it a capital N. */

But then again perhaps Marlin is in the maintenance phase, then just do nothing and continue as before

I think Marlin is going to live for many years and continue to evolve. There are so many new developments in 3D-Printing and the fact that it is a good, solid Open Source code base to leverage almost guarantees that it will continue to grow and evolve. Doing a serious bug fix and maintenance phase makes sense to insure this can happen. Bug fixing and maintenance phases aren't as much fun as developing new code, but it is a necessary fact of life!

[scotty1024]

Isn't 3 points what Printrbot is using? Plus an aluminum bed machined flat to 6 microns across its entire surface? That combo sounds pretty strong to me.

To attract more coders I suggest a recruiting page on http://marlinfirmware.org wiki with beer background wallpaper. Maybe some meet ups? Meet ups at conferences? T-shirts: I'm a Marlin Stud? etc....

On Mar 20, 2015, at 8:41 AM, Roxy-3DPrintBoard notifications@github.com wrote:

3 point uses far less code because it is a simple matrix rotation. The grid version pulls in code to do the least squares fit, which is large.

3 Point is inherently 'weak' because any error gets magnified in the unprobed corner. And while it might appear this thread is going way off topic, this is a useful exercise to work through because it highlights the point I was trying to make.

— Reply to this email directly or view it on GitHub.

[alexborro]

@scotty1024 , how many people do you think have access to an "aluminum bed machined flat to 6 microns across its entire surface"? I'm struggling a few days to source one and I could say so far money is not the problem.

About the 3 Points Leveling, the point raised by @nophead is important. I could not compile right now a fresh version with 3 Points Leveling enabled - the code is broken... but the configuration.h says the Grid leveling increases the code in about 10K.. I don't know if this is a price to pay... How many boards over there have only 128K of Flash??

What if we move the 3 Points Leveling call (G29) to another file?? So we have completely separate codes.. I guess no one will still maintain the 3 Points Leveling..

@Roxy-3DPrintBoard , @JustAnother1 you guys are right about attractives to new coders. I usually implement stuffs I need.. I'm fixing a lot of bugs related to CoreXY bots - (Roxy's M48 is still not working properly ;-) . I'm finishing right now a feature to use 2 endstops for Z_Axis with 2 motors, so both sides can be homed and aligned. And I have a list of new features to be developed, like chamber temperature control... Those are feature I need in my bots and I think it is fair make them available.

Cheers.

Alex.

[scotty1024]

Anyone using a metal Printrbot.

Me for one. :-)

They sell the beds if you want one.

Http://www.printrbot.com

If we made up some with etched Marlin Firmware around one edge could those be nice rewards for new code contributors?

On Mar 20, 2015, at 5:06 PM, alexborro notifications@github.com wrote:

@scotty1024 , how many people do you think have access to an "aluminum bed machined flat to 6 microns across its entire surface"? I'm struggling a few days to source one and I could say so far money is not the problem.

About the 3 Points Leveling, the point raised by @nophead is important. I could not compile right now a fresh version with 3 Points Leveling enabled - the code is broken... but the configuration.h says the Grid leveling increases the code in about 10K.. I don't know if this is a price to pay... How many boards over there have only 128K of Flash??

What if we move the 3 Points Leveling call (G29) to another file?? So we have completely separate codes.. I guess no one will still maintain the 3 Points Leveling..

@Roxy-3DPrintBoard , @JustAnother1 you guys are right about attractives to new coders. I usually implement stuffs I need.. I'm fixing a lot of bugs related to CoreXY bots - (Roxy's M48 is still not working properly ;-) . I'm finishing right now a feature to use 2 endstops for Z_Axis with 2 motors, so both sides can be homed and aligned. And I have a list of new features to be developed, like chamber temperature control... Those are feature I need in my bots and I think it is fair make them available.

Cheers.

Alex.

— Reply to this email directly or view it on GitHub.

[thinkyhead]

Code cleanup is definitely a high priority. See, for example, my recent PRs moving g-code handlers into functions, breaking up pins.h and language.h, fixing up temperature.cpp, optimizing the LCD menu, adding a configurator utility, shrinking the size of the Configuration*.h files (#1651), and cleaning up the planner (#1658). There is method in the madness of this initial effort to clean up the codebase!

I've also drafted documentation on coding standards which you can find on the wiki. And I definitely would like to write up a document giving a high level overview of the code, discussing the "direction" of Marlin, and explaining why legacy code (e.g., three-point triangulation) should remain in the codebase as an option. (To provide a light-weight option for older, more modest electronics.)

I've been scrubbing through Marlin for several months now, so I've come to appreciate some elements of the code and to loathe others. The cleanup I've focused on so far has not had the aim of rewriting Marlin in any fundamental way, but just to polish up and optimize the code within the existing structure. That's an important first step to get acquainted with the code, to get to know its structure and flow, and to begin having some idea about how it might be better structured. And small rewrites in that general direction are happening all the time.

As for things like integrating @Roxy-3DPrintBoard 's Enhanced G29 feature, my approach is first to get as close to the original intent as possible, preserving all the options that were originally implemented. So the first draft has TOPO_FLAG, the second draft moved TOPO_FLAG to Configuration.h, and in the next draft the consensus will have TOPO_FLAG removed altogether.

The codebase will never be exactly beautiful but it's not terrible. The use of conditional code blocks within functions is a necessary evil to squeeze out the fastest performance and the smallest code size. It isn't always possible to make features in such a way that they can live in separate files. Moreover, depending on how a feature is implemented, trying to separate it into its own file is liable to produce a lot of redundancy, making it harder to maintain the code. Some features do add their own functions, and these provide a better case for encapsulation.

Bed leveling is one area where you could possibly make each of the different G29 methods into their own functions to make the code cleaner. But many (if not most) configured options are scattered in many places, altering the behavior of various functions. See COREXY or DELTA for example. While it is technically possible to encapsulate such features by defining a slew of macros that are either full of code or empty (if the feature is off), and inserting them into appropriate spots in functions, that would harm maintainability for obvious reasons.

I see the "direction" of Marlin as being towards constant refinement and improvement. There are some ARM versions in the works which are basically complete rewrites, no doubt using classes more liberally. There are plenty of candidate elements in Marlin 1.x which can be encapsulated in classes (the planner block structure, for example), and we will do those on case-by-case basis. I'm totally behind any effort that cleans up the global namespace and encapsulates elements in classes. The best way to go about this (in my view) is to start modestly by moving global variables that go together into small classes that embody their common functions, and little by little convert functions that work with this data into class and instance methods.

[thinkyhead]

I could see a compromise option with triangulation. Instead of requiring the user to define 3 points of their own in Configuration.h they can just choose the direction that the triangle should point to – front, back, left, right – and the firmware will figure out the 3 points.

[Natealus]

I wish I could help out more but I don't quite understand how to manipulate the code to make it more efficent and quicker. I can...help diagnose if its issues I can reproduce.

[nophead]

How many boards over there have only 128K of Flash??

I think many, possibly the majority.

2 years ago Marlin fitted into 64K and people were just starting to upgrade to 128K. All Sanguinolu and Melzi are 64 or 128K. Plus a lot of RAMPS have Arduino Mega with only 128K as well. And didn't somebody mention all the chips with on-board USB are limited to 128K? So I guess there are probably more with 128K or less than there are 256K.

[fmalpartida]

Yep, all AVR with on-board usb are limited to 128K: 90USB1286 or 87.

I would love to be able to support the coding effort but I have so little time right now...

[boelle]

FWIW we also have a list of features people have suggested... so we do have more than just a list of bugs

[Roxy-3D]

FWIW we also have a list of features people have suggested... so we do have more than just a list of bugs

Understood! But I was under the impression that right now only bug fixes and things to clean up the code are being accepted???? I guess that raises a couple of questions.

If that is true, how long until new features and functionality can be absorbed into the code base?

And a second question: Is there a list of these requested features similar to the list of bug fixes at https://github.com/MarlinFirmware/Marlin/milestones ?

[boelle]

hmm... we will have to ask @thinkyhead was is the best way to go arround it

as for list of requested features i have not made a list yet, so far the only way is to look here: https://github.com/MarlinFirmware/Marlin/issues?page=4&q=is%3Aissue+is%3Aopen

that link gives the oldest issues flagged as feature requests... but as you click page 3, 2 and 1 you will see the issues i have put in milestones....

could maybe make milestones for the feature request later...

[thinkyhead]

I would say go for the code-freeze if we want to restrict contributions to fixes and cease features. Under a code freeze concept, basically any feature PRs will be held off for a period of time, say a month. During that time other PRs will be considered if they don't add new features, and especially if they fix bugs.

[boelle]

anyways for those who want to do the feature requests i have set up 4 milestones with all the feature requests starting with the oldest ones first

[Drayson80]

May I add a suggestion based on a famouse model in product configuration

In the KANO-model, there are 3 levels of functions in every product/service which are relevant to make something interesting:

• base functions
• performance functions
• excitement functions

I would sugget to cluster all function requests like this model to make sure to safeguard all relevant base functonalities to allow a safe operation (nobrainer - they HAVE to work... e.g. start/stop/safety/...) before working on excitement stuff which is - of course - the most interesting stuff for coders...:-)

Just my two cents...

[thinkyhead]

I like that model. Of course I am weird in finding housekeeping strangely exciting.

[eboston]

While this may not be exactly on target, it is about code development. I have been working on getting a graphic display made based on Adafruit ST7565 display. I have it up and running, but want to do some more tweaking before submitting it. However, I have someone else interested in it wanting to help test it out. So I have some question about using git and github and need someone to talk to about it. Where should I go with these questions?

[thinkyhead]

@eboston You can post your questions on my Marlin issue queue, if you like. If needed we can chat on IRC or elsewhere.

[clefranc]

Is delta Marlin flavor broken? I'm using the same configuration parameters than last week (using the new cleaned config files), the coordinates are way off, like if a multiplier is applied to all size. I can't calibrate my delta with the latest dev.

Is there a new paramater I'm not aware of?

[thinkyhead]

@clefranc There could certainly be a new bug. But which version of Arduino are you using to compile? There are some strange issues with some versions.

Can you determine a pattern to how much off it is?

[thinkyhead]

Hey coders and testers, let's get your time zones and it will be easier to coordinate. Mine is PDT (GMT-7).

[AnHardt]

GMT+1 2:00 in the morning now.

[emartinez167]

GMT+8 over here. 09:30am at the moment (Western Australia).

Regards,

Ernesto

On 27 Mar 2015, at 08:30, Scott Lahteine notifications@github.com wrote:

Hey coders and testers, let's get your time zones and it will be easier to coordinate. Mine is PDT (GMT-7).

— Reply to this email directly or view it on GitHub.

[clefranc]

EDT (GMT-4) @thinkyhead Compiled with 1.6.1, dev from last week was ok. It looks like the steps/mm have a multiplier. I'm burning the lastest dev on my Prusa i3 right now, will let you know.

[thinkyhead]

@clefranc So, does your machine's display, or print monitor, report a Z position that is totally incorrect, or does it report the true Z position?

[clefranc]

@thinkyhead This is on my delta: on the display and host, the coordinates are correct. You're right, the Z height seems spot on, so the DEFAULT_AXIS_STEPS_PER_UNIT must be right. When moving the nozzle 50mm X or Y, I get about 70mm, the display shows 50mm. 100mm on display = ~150mm on bed.

BTW, latest dev on Prusa i3 works great.

[thinkyhead]

@clefranc I'm glad to hear it's working well on the cartesian i3. That's what I have, so of course that's the most important thing.

The difference in movement for your delta has me troubled. We'll have to work on isolating that ASAP. I assume you've already checked all the obvious stuff, like steps/mm settings and all that.

[EDIT] Oh, I see. Your Z movement works out correctly, if you just move in Z, but your X-Y movement is way off. Truly, this will be easiest just to compare old vs new code and see what recent changes would affect this.

[fmalpartida]

GMT+1 El 27/3/2015 1:30, "Scott Lahteine" notifications@github.com escribió:

Hey coders and testers, let's get your time zones and it will be easier to coordinate. Mine is PDT (GMT-7).

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1648#issuecomment-86769642 .

[clefranc]

@thinkyhead Re-downloaded the latest dev, the X-Y is definitively resolve. Thanks!

[github-actions[bot]]

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.