I’ve got two nearly identical 3D printers (home-built Prusa i3 MK2 clones running Marlin on RAMPS boards). They have different extruders and different steppers, so e steps per mm, velocity, acceleration, jerk, PID values, and the bed extents are different (due to different extruder shapes). So far, I’ve been editing the config files manually with two sets of settings, tracking which settings go with which machine with manually managed comments.
The original plan was to send one printer to my brother, so I didn’t expect to be maintaining firmware for both indefinitely. Now it looks like they’re both going to be with me for a while. Incorporating my changes in new versions of the config files and flipping the comments to rebuild firmware is getting to be a big enough pain in the neck that I’m looking for a better way.
I’ve been using Arduino IDE on Windows, but recently installed PlatformIO and was able to build and push it to one of the printers at my “office” desk. I’ve also got a Linux Mint machine in the workshop next to the other printer where the Arduino IDE is still working fine, but would not be averse to putting platformIO in there too.
I have a github account but have no experience with actual source control mechanisms. I used to be a server and network admin, wasn’t ever a developer. Can someone point me to a primer that will let me get my brain wrapped around a way to use the Marlin releases a common starting point then easily track my printers’ idiosyncrasies in a way that keeps me sane?
Do I want two forks, one for each printer? What’s the build process like for that?
You’ll probably want to wait for @jeffeb3, @anttix, and/or @vicious1 to drop some better knowledge, but my recommendation would be to fork the Marlin source, then create your own branches to maintain your config changes. That way, you can always pull down changes from the upstream repository, and then merge those changes up into your branches. Which is all great in theory, but I’d have to spend more than a couple of minutes delving into the git manpages to tell you how to do all that…
Jeff convinced me to take some time and figure out a little about git. I was previously maintaining all the firmware by hand. I had a list of changes. I would download marlin, edit it all by hand…many times, zip it and upload it.
We now have the Marlin builder thanks to Anttix and Heffe.
How I did it previous to the marlin builder and for all my other public work…and my suggestion if you need a GUI. If you are command line comfortable do not bother with this. I use Sourcetree to do all my Github stuff. It lets me have a gui…and a terminal. So far I have not found a huge downside but know I will hopefully use the GUI less and less now that I am starting to understand how GIT works.
I have my repo all set up in sourcetree, and a branch for each machine. When it is time for an update I pull the marlin bugfix in and then merge my branch into each one. Now the real issue I used to have was what happened when there was an issue…enter kdiff. So rarely will you have issues with config and config adv…but when you have a conflict you need to be able to resolve it or you break your branch.
99% of the time my previous marlin branches can be updated in minutes
So what happens when the Marlin developers change the name of a setting so that active settings in my current configs no longer matches the new default config files? Does the merge process highlight these differences?
Git actually knows somehow…kinda. That is not usually an issue at least. Kdiff would come into play there…but more like if you have therm 5, and for some reason they add a second setting (Therm 5, 8), kdiff would let you look at them side by side make a single edit, save and be on your way.
It is actually really smart somehow. If things get deleted or moved from config to config adv I believe your changes will move as well or get deleated. At least if feels that way.
Worst case scenario you get a warning about a conflict, right click, resolve conflict (kdiff), look at it and save. That used to be where I failed, now it is fairly simple to fix.
What you need to track isn’t the settings, it is the difference between two text files. If you apply that difference to a new base file, it should end up with a new config file, but with your settings applied on top.
This is a git “commit”. One commit is just a difference from its “parent”. You can give useful names to these commits, and it is called a “branch”.
The tricky part is, when you have your commits applied to 2.0.6 and then you want to instead apply them to 2.0.7. In that case, you want the same commit, but applied to a different parent.
There are a lot of strategies you can use for that.
You can fork the marlin github. You would then make your changes in a branch and whenever you wanted to update, you would need to rebase (change a parent) to a newer version.
You can keep detailed notes about what you change. This is what Ryan used to do. Every line he changed had a // allted at the end.
You can make a script that checks out whatever “clean” version of Marlin, and then applies your changes one at a time. This is what MarlinBuilder does. You could probably fork that and change a few small files to get exactly what you want. But if you’re not familiar with bash and linux, it might just frustrate you to no end.
You can keep a lot of the settings in a gcode file and not worry about setting them in eeprom. Just run the gcode script to set everything and then save it to eeprom.
There is a significant cost to all of those options. Part of what you should consider is how often you need to update or change things. I suspect there is very little difference between 1.1.9 and 2.0.7 for a ramps board.
Git is, IMO, an amazing tool and once you know it, you can apply it to all sorts of problems. For this one particular task, you may not be taking the most effective route to a solution if you choose git. But it will pay off a lot of you use it for 1-2 more things.
Github isn’t the same as git. It is just a convenient server to upload and share git repos. There’s no reason you even have to put your code to any server, and there are many options other than github.
For me it is worth the effort. I like Git so much, and the ease of github for sharing. I try to do too much with it. Jeff has to keep slowing me down and keeping me from trying use git for everything and sharing on Github.
I got in trouble with my classmates in grad school when I said a good stage manager has to be a bit lazy. There’s just so much they’re responsible for they can’t get it all done unless they’ve got a commitment to the most reliable, repeatable (and therefore labor saving) methods.
To paraphrase Gordon Gekko, “Lazy is good. Lazy works.”
Thanks everyone for your guidance. Sounds like an investment in git is worth the time. Command line doesn’t scare me, I just don’t use it often enough to think of myself as proficient. Will probably generate myself a checklist until the process becomes ingrained.
Sounds like I need to generate a few branches. A “parent” that has the config,h and config-adv.h settings that are identical for both my printers (drivers, # of axes and extruders, Z align configuration), then one “child” per printer that manages that printer’s specific parameter settings (home offsets, parking, PID settings, eSteps per mm, velocity, and acceleration). Once that’s in place, I can chose to rebase depending on specific features. If the new feature applies to both, I put that commit in the parent branch. If it requires settings specific to one printer, the commit goes in that printer’s branch.
Sometimes I don’t care about new features (lukewarm about Junction Deviation over Standard Jerk), but other times I can’t wait to get them going (UBL, Z AutoAlign).
I think I’m going to try and keep the settings in the firmware configs for the most part rather than in gcode files at this point. I like knowing that “restore failsafes” should put me in an operable state if an experimental setting goes wrong. But I can also see that if I want to shift gears on that choice, it’s just another set of branches, this time as GCode files that won’t be based on the Marlin config files.
This will work well. I would definitely choose rebasing over merging in that case. It is a bit “intermediate git”, but it will keep the history cleaner and what is the point of git if not the history?
I do use some gui tools with git. Even in Linux. I use git gui to make commits. Mostly because the hunk and line commits are hard to do on the command line. I also use qgit to browse the branches the history.
