Marlin firmware fork for MakerFarm i3v w/ auto bed level & Roxy's enhancements

[Roxy]

I looked through a bunch of documents about G-code and "standards" and I don't feel that multi-letter parameters is in the spirit. I would propose I, J, K, and L. These are clearly an array but not overly misleading in specificity (e.g. L,F,R,B). Each of these followed by a value in mm.

I understand your thoughts! And I 3/4 agree. The big problem is these one letter variable names cause all kinds of problems. And given the code cost is so minimal to support long parameter names, I'm actually thinking it makes sense to make a transition. After all... If somebody doesn't want to have a longer, clearer variable name in the G29 command, they don't need to use it. But with that said, I'm perfectly fine moving to some parameter names that mean nothing and add no confusion. It will be easy to document that I is the minimum X-Axis coordinate to probe. J is the maximum X-Axis coordinate to probe, etc, etc. What we really are trying to do is set this up so people aren't pulling their hair out trying to get it working. (and longer parameter names would do that just as going with I,J,K & L will do it. )

And perhaps we are worrying too much about the confusion. Anybody that uses this feature is going to be using the slicer (either Cura or Slic3r) Post Processors. The Post Processors will know the correct parameter name for each of the values. So everything will magically work for the user. Right???? (I think and hope so!)

Can you PM me your github username? I'll add you as a collaborator so your commits give you the recognition you deserve!

Thanks! Mostly I do this just for fun and I don't need credit... However, being able to make updates is helpful. I sent you a Private Message. But isn't all that stuff public anyways? Anybody that is using a fork in the tree can trace it back to every change that is made and who made it, right?

What are your thoughts on the Post Processors? The problem is even though I'm back proponent of Open Source, I do use MSVC Studio for most of my C code when I'm playing around. I put the whole 'MSVC Solution' into your PlugIn folder. I deliberately made the thing very straight forward C code that uses nothing but generic library functions. It doesn't even have a header file. So it will compile with just about anything. But with that said... I'm wondering if the Open Source fans are going to be hostile about that? I guess if they don't like it, they can spend the time to take the single .C file and set up a GCC environment for it.

[dacb]

I understand your thoughts! And I 3/4 agree. The big problem is these one letter variable names cause all kinds of problems. And given the code cost is so minimal to support long parameter names, I'm actually thinking it makes sense to make a transition. After all... If somebody doesn't want to have a longer, clearer variable name in the G29 command, they don't need to use it. But with that said, I'm perfectly fine moving to some parameter names that mean nothing and add no confusion. It will be easy to document that I is the minimum X-Axis coordinate to probe. J is the maximum X-Axis coordinate to probe, etc, etc. What we really are trying to do is set this up so people aren't pulling their hair out trying to get it working. (and longer parameter names would do that just as going with I,J,K & L will do it. )

I totally understand your frustration about the parameters. I think your approach of using solid documentation like you have done in the past will be the way to signal the correct usage of more generic parameters like I, J, K, L.

Thanks! Mostly I do this just for fun and I don't need credit... However, being able to make updates is helpful. I sent you a Private Message. But isn't all that stuff public anyways? Anybody that is using a fork in the tree can trace it back to every change that is made and who made it, right?

Yes. I am a big proponent of github, but with this instance I was very frustrated. I spent a good half an hour trying to search through the master Marlin pull requests and I couldn't come up with your github username. I know you had the repeatability pull request accepted, but I just couldn't find a good way to search the history. WTF github?!!? I'd love for someone to tell me how to make that search work.

What are your thoughts on the Post Processors? The problem is even though I'm back proponent of Open Source, I do use MSVC Studio for most of my C code when I'm playing around. I put the whole 'MSVC Solution' into your PlugIn folder. I deliberately made the thing very straight forward C code that uses nothing but generic library functions. It doesn't even have a header file. So it will compile with just about anything. But with that said... I'm wondering if the Open Source fans are going to be hostile about that? I guess if they don't like it, they can spend the time to take the single .C file and set up a GCC environment for it.

Emphatically: no problem. If you put your stuff in a repo, you are tacitly agreeing to the license that is already in place? I see now reason why your solution can't be considered open source. Open source is about making the source open, not about making it compile on everyone's OS. Can't wait to have your commits!

[Roxy]

Yes. I am a big proponent of github, but with this instance I was very frustrated. I spent a good half an hour trying to search through the master Marlin pull requests and I couldn't come up with your github username. I know you had the repeatability pull request accepted, but I just couldn't find a good way to search the history. WTF github?!!? I'd love for someone to tell me how to make that search work.

I have TortoiseGit installed and I can see changes in Windows Explorer to the files. They seem to track the status in the Git help as I commit and do things. But when I try to Push the changes (I'm right clicking on the top directory of your cloned branch in Explorer, selecting TortoiseGit and then saying Push) I get this window:

pict1.jpg

And when I say 'OK' it does this:

pict2.jpg

But it depends on the way I try to do the Push. Other paths produce a box saying this message:

fatal: Unable to find remote helper for 'https'

And of course... searching on the web doesn't really help. It seems like everybody getting this message is on a Linux machine and I'm using Windows. They want me to rebuild Git. They want me to switch to a different version of Ubuntu Linux. They want me to run a configure script and then do a Makefile with some options. Aaaargggghhhhh.....

This Git stuff is *NOT* easy to use!


And one more thing.... I did a revision graph of your fork. Can it be 'Re-Based' off of something higher up so it doesn't fall behind?


pict3.jpg

[dacb]

I really wish I could offer more support for using the git clients. I am mostly on the command line, but I have found the "official" github clients work well, I know there is a windows one: https://windows.github.com

...And one more thing.... I did a revision graph of your fork. Can it be 'Re-Based' off of something higher up so it doesn't fall behind?...

I will periodically pull against the upstream master and resolve conflicts, but for right now we should be current. Is that what you mean?

[Roxy]

I really wish I could offer more support for using the git clients. I am mostly on the command line, but I have found the "official" github clients work well, I know there is a windows one: https://windows.github.com

OK! That sort of worked. I think I got the memory leak update pushed up. And I think I got the Slic3r Plug-In uploaded. But I'm not sure they are 'Committed'. I can view them on GitHub's web page and it shows your name in the fork so I think they are there. But then going any further up the list of changes I get conflicts and can't resolve them. There isn't anything that is worth resolving... I just made a couple of changes to the Configuration.h file to test if I could sync and commit this morning.

Maybe the thing to do is have you check if everything is still good and working... If you publish a link I'll re-clone starting at that point? That would get rid of all my conflicts and let me start fresh.

I will periodically pull against the upstream master and resolve conflicts, but for right now we should be current. Is that what you mean?

Well, it looks like Erik Zalm has made a couple of releases since you branched off. I was mostly wondering if I interpreted that right, and was curious why you didn't branch from a higher level.

[dacb]

OK! That sort of worked. I think I got the memory leak update pushed up. And I think I got the Slic3r Plug-In uploaded. But I'm not sure they are 'Committed'. I can view them on GitHub's web page and it shows your name in the fork so I think they are there. But then going any further up the list of changes I get conflicts and can't resolve them. There isn't anything that is worth resolving... I just made a couple of changes to the Configuration.h file to test if I could sync and commit this morning.

* The memory leak fix committed fine: https://github.com/beckdac/Marlin/co...46120e33f10927
* as did the Slic3r script: https://github.com/beckdac/Marlin/co...87c5bb8b292614
* It looks like you didn't do a git pull before starting the changes to Configuration.h and the termistor table stuff reverted: https://github.com/beckdac/Marlin/co...87c5bb8b292614
I dropped your changes to Configuration.h (too hard to discern from the log, sorry) and reverted to the type 1 thermistor: https://github.com/beckdac/Marlin/co...21af567a295c68
Maybe you can do a git pull and then restore you Configuration.h changes?
* Finally, I noticed that your awesome missing free fix referenced the wrong variable name, I fixed this and it compiles great. I'm testing this on my machine right now. Commit: https://github.com/beckdac/Marlin/co...306c106ceaf9b6

Well, it looks like Erik Zalm has made a couple of releases since you branched off. I was mostly wondering if I interpreted that right, and was curious why you didn't branch from a higher level.

I've pulled all those and incorporated them so we are good to go there.

If you publish a link I'll re-clone starting at that point? That would get rid of all my conflicts and let me start fresh.

That is certainly a possibility. In your web browser, click the fork link on my repo and get started. Issue a pull request when you have something to incorporate. Personally, I'd rather we were all operating on the same repo vs. another merge set, but open source works many ways and a fork of a fork is absolutely fine. Let me know which way you choose.

Thanks for all your hard work.

[Roxy]

* The memory leak fix committed fine: https://github.com/beckdac/Marlin/co...46120e33f10927
* as did the Slic3r script: https://github.com/beckdac/Marlin/co...87c5bb8b292614

Great! I'm starting to figure out the process! The Slic3r one has more stuff in it, right? It has the both the Memory Leak fix and the Slic3r G29 Post Processor stuff? If so, that will be the one I should start from next.

* It looks like you didn't do a git pull before starting the changes to Configuration.h and the termistor table stuff reverted: https://github.com/beckdac/Marlin/co...87c5bb8b292614
I dropped your changes to Configuration.h (too hard to discern from the log, sorry) and reverted to the type 1 thermistor: https://github.com/beckdac/Marlin/co...21af567a295c68

I don't understand. I got the whole code base. Can't I just make changes to test stuff and send it back when it is right? I guess I don't understand this Push and Pull stuff. When I did the clone, doesn't that 'Pull' everything from the branch so I have it too? Or is the problem the fact that other changes were made in the mean time? If that is the case, my guess is there is a way to merge the two divergent paths back together again. But right now... I'm not advanced enough to do that.

Maybe you can do a git pull and then restore you Configuration.h changes?

I'll do a diff but I suspect there is hardly anything there to preserve. I was unable to make the Push work so I wanted to just have a simple change to the Configuration.h file to see if I could make it happen. I cleaned up some wording on a comment. It was a worth while fix but nothing that will be noticed if it isn't done.

* Finally, I noticed that your awesome missing free fix referenced the wrong variable name, I fixed this and it compiles great. I'm testing this on my machine right now. Commit: https://github.com/beckdac/Marlin/co...306c106ceaf9b6

Oooops! I went back and looked at my post. (And I cut and pasted that into the cloned image I grabbed.) I didn't have any way to compile it or I probably would have found that mistake. Sorry!

I've pulled all those and incorporated them so we are good to go there.

That is certainly a possibility. In your web browser, click the fork link on my repo and get started. Issue a pull request when you have something to incorporate. Personally, I'd rather we were all operating on the same repo vs. another merge set, but open source works many ways and a fork of a fork is absolutely fine. Let me know which way you choose.

I certainly don't need to Fork! The reason I said that is that is the only experience I have for getting a code base. Is a Clone and a Pull the same thing? If so, then I understand why you said what you did. It would make sense to just Pull the current code base and use that as a new starting point. But I still don't understand why I needed to Pull the Configuration.h file to make a small change when I already had it. Maybe the answer is I didn't have the most recent version. The code base had already moved on from what I had???

[dacb]

I don't understand. I got the whole code base. Can't I just make changes to test stuff and send it back when it is right? I guess I don't understand this Push and Pull stuff. When I did the clone, doesn't that 'Pull' everything from the branch so I have it too? Or is the problem the fact that other changes were made in the mean time? If that is the case, my guess is there is a way to merge the two divergent paths back together again. But right now... I'm not advanced enough to do that.

You know, the lingo takes some getting used to. Here are my simplified thoughts... When you clone a repository, you make a local copy. As you work in there, you can commit changes to your local copy. Periodically, you can push those changes back up to the main repository from where you cloned the repo. Periodically, while working with your local copy, you want to pull down any changes from the main repository to your local so that you are current. I almost always do this before a commit on a group project so that I can resolve any conflicts beforehand. The idea of a local copy that only syncs with the main when you do a push is different from other source control tools.

When I fork someone's main repository, we branch off on separate development paths. When the repository that I forked from changes in, I can do an upstream pull where I sync changes in the main repository to my fork. You can also do this on a commit by commit basis so that you can test out each change from the main in the context of your fork. If I think I have some good changes in my fork that the main repository could use, I can issue a pull request. This is one thing that confuses people because you think of it as a push request from your fork, but the logic is the main repository maintainer has to issue the pull, not the fork maintainer issuing a push which could wreak havoc on the main repo's possibly unwilling recipient.

There are some canonical names (that can be overridden) for different pieces of a source tree. One of them is master which refers to the main branch that I sometimes call trunk because I also use subversion, sorry for that. There are also branches which can be given a name, e.g. RoxysAwesomeFeatureBranch. This is sort of a mini fork within a repository. One way to manage multiple people working on the same repository is to give them each a branch for development and then periodically after code review, the branches are merged back into the master.

For good software hygiene, I try to monitor commits and pull early and often. This way I can be proactive about dealing with conflicts, before I commit.

Hurray for software jargon!

I don't know if that helped or was just telling you stuff you already know.

[Roxy]

Hurray for software jargon!

I don't know if that helped or was just telling you stuff you already know.

Yes! Thank You for spending the time to explain that. That helped a lot. I need to get this latest code working with my printer so I can test out (and probably improve) the Slic3r Post Processor.

Note to DACB: I'm swamped with other things... But I'm going to be working on this when I get some time. The Slic3r Post Processor needs to be shaken out before it gets checked in.

[AbuMaia]

Roxy, in the Mechanical Calibration section of your firmware, for the hobbed bolt, which part is the measurement? The bolt itself, or the hobbed part?