Is the laser/fan issue fixed?
Not that I’m aware.
No, it is not very different from the current V1 release. It looks like new features are going to get added into a new branch and there will probably be a few minor bugfixes in the current branch. The laser stuff is one of the few PR’s that are currently still being worked on. Most of the rest is of the changes have been board and trinamic specific.
I imagine there ill be releases like 2.0.1, 2.0.2… Hopefully the existing set of features will get solidified. Ideally, Ryan’s firmware would follow those. That way someone setting up a new MPCNC has a stable base of software.
The problem is, as soon as 2.1.x has a feature we want (or just as likely a new board supported) we will have to decide if we want to have those new features, along with the instability.
Maybe Ryan’s ‘releases’ can follow 2.0.x and his live branches can follow 2.1.x, but I don’t know how much more git foo Ryan can handle. He’s a mechanical engineer after all 
.
1 Like
As long as the next release is not 15 months or whatever they said this last one was. So Many features got introduced. After this next one I hope not to do much with it for a while hoping to figure out the dual extruder = 0 issue and just sit on it for a while.
I guess I should finally look in to updating my MPCNC. The thing’s still running the original firmware from when I bought the RAMPS from v1 years ago.
HAHAHa, well if you waited this long you might as well wait for one more update. I will try to do some more extensive testing before releasing it.
I’m hoping it will finally fix the one stuck bearing I have that I have been reluctant to replace 
It’ll be nice to have a supposedly stable version to use. 
Also I can gain back the servo pins I moved E0 to so I could use double xy drivers, since I read they allow 0 extruders to be set in marlin now.
There’s a thread about EXTRUDERS=0. Seems like there are still some lingering issues, especially when using the E0 port.
You should be able to move all of E0 pins to one pin.
That’s handy. I could also just get a 2mm nozzle and 20kg rolls of filament and 3d print stuff with my MPCNC. 
does this include the firmware for Archim boards with duel endstop, the one shared on your google drive?
The regular archim’s work now you just need to remove the u8glib from your libraries, Ultimachine backed in the LCD stuff into the package they provide until Arduino can handle larger commands.
1 Like
Given the amount of testing effort that will go into an update to a stable release, we should take an opportunity to streamline the git-fu and release process.
At a minimum there should be some CI jobs that build all of the branches and publish these as nightly builds. Ideally it should be possible to set everything up in such a way that upstream updates are mostly automatic as well unless there is a conflict.
Looking at the history, it seems the current process uses a merge strategy. This has its pros and cons. Another popular way to work is a rebase strategy. I took this approach with my boards and I’m updating via rebasing. It works best if the fork is shallow and the number of commits limited. Here’s my current short history:
- MPCNC base config
- Dual endstop config
- EXTRUDERS = 1
- pins.h hacks (one commit per board)
- Board flip
Different branches for different boards can be easily cut by just branching from points in this history and adding a board flip change on the top. These can be updated via rebasing as well. The nice thing about the rebase strategy is that customizations will always be at the top of Marlin commits which makes it easy to find and manage them.
However this strategy will not work well if change history of the configs is important and will irk some people who have checked out your branch and made changes on top because rebase strategy pretty much requires a force-push to update the branches.
@vicious1 what git process are you using now, do you have any scripts that help to automate things?
I predict we may want 2.1 sooner rather than later. If they do switch to FreeRTOS for 2.1 as it’s been rumored, the code will be reorganized and simplified as a result which makes backporting new features to 2.0 hard.
1 Like
I am all for a rebasing strategy. There about 12 configs currently, and they are not all mpcnc. Zenxy, MP3DP, and many of them aren’t dual endstop.
The differences from the main are pretty straightforward. It should be possible to rebase each one. My fear is that there will be upstream changes that will cause conflicts and that will cause stress and errors. Ryan ultimately has to do it, because he’s the only one guaranteed to be there when it has to be done. So that means we need to teach him how.
1 Like
Does popcorn and Dr. Pepper count as a script?
I am all for making it easier, but as it is that part is the easiest. I update one, Ramps, that takes care of any conflicts, then I just merge the rest from that branch. 10-15 minutes tops/ The hardest part is testing, all the boards and all the machines. Before the git stuff I would rather set up some sort of testing gcode or procedure…but each new feature means all that needs to be updated every time and then the test is done by eye, no other way I can think of.
I only really like to update when something significant happens, We have a ton of users that will not flash the boards they own. So constantly updating firmware kinda leaves them behind. I updated when we got new motion equations and any new CNC features, and only when enough people got irritated we didn’t have them, like workspace offsets (but who really uses them).
There are a ton of people that are extremely intimidated that the current firmware is only linked on github. I am pretty sure I need to add the direct links back to the firmware page. Adding daily’s is okay if we have solid links to the current stable branch. Tags are not working.
Chasing the bleeding edge is brutal on my end. Every firmware issue that comes up is an irritation for you guys but potentially hundreds or thousands of people I need to help that have bought my stuff. Stability is far more important that “newest” for me. As an example I have a 100% complete new MPCNC center that I had a solid three days to test then had to bench it, and honestly I started it a year and a half ago. We started the community docs, and then back into firmware updates and Archim issues from there. Even this extruders=0 is awesome for new boards but for the user means nothing and on my end doesn’t mean much because my firmware all already have the pins changed. That being said, I love to help, I love the feeling of contributing to Marlin but I really need this next update to stick for a while. If I dig into the firmware Arcs, junction deviation, and s-curve seems more important than the ease of extruders=0 right?
This is not meant to be negative at all. I am really looking for some advice on how to manage my time on the projects. So wise guru’s, with that being said, I trust your opinions and knowledge on this side of things. What is your opinion for going forward with the firmware on my end?
1 Like
To some extent 
While test plans and methods are important, I strongly believe nightly builds and pre-compiled binaries should be a next step. There are a few reasons why I think this way.
-
Firmwares are hard to test as it’s difficult to replicate the different configurations in the wild. Unless you want to lock down everything to a single board, roping in community members is the way to go. Frequent (often nightly) builds are one of the practices in the OSS world that expands the user base who can test your latest bleeding edge version. Compiling is a hassle and pre-built binaries bring down the barrier just enough to get people interested. This is especially true for the new 32bit boards that take FW updates via an SD card which means all you need to do is download a file and drop it onto a card: Zero development tooling to fuss with.
-
Early access to new features just for the users who need them makes them happy. Sure there is a caveat that it is unstable and maybe broken but hope is a wonderful thing. It also breeds valuable feedback and real-life testers.
-
Catch issues with upstream early. Updates are a lot easier if done frequently in small increments. Yes updating to bleeding edge all the time is not pleasant but it’s a lot easier than doing one big-bang migration that changes everything and then dealing with multiple things that broke at once.
This doesn’t mean releasing a bleeding-edge as stable more often. I agree that stable release cadence does not need to be very frequent and is probably driven by the value-add more than the timeline. Although there is some value in perceived “freshness”. Websites are sometimes redesigned not because they didn’t work before but because an update creates an illusion of progress …
1 Like
There are a bunch of orthogonal things going on, and they don’t need to be combined.
Regarding the git/rebase issue. If nothing else, I was thinking the 2.0 release would be a good time to clean out the history a bit. What you’re doing looks the same in the checked out version, but the history is a mess (if you don’t mind me being blunt) and if we were rebasing, it would be easier to tell what version it was based off of. What Anttrix is suggesting is, the history for one specific version would look like this:
- MPCNC-Ramps-32T-Dual Endstop
- Marlin 2.0.0
- … All the other Marlin stuff.
So you could easily see what Ryan was changing from 2.0.0. Then, when 2.0.1 comes out, you would “rebase” the MPCNC-Ramps-32T-Dual Endstop to point to 2.0.1, so it would look like this:
- MPCNC-Ramps-32T-Dual Endstop
- Marlin 2.0.1
- … All the other Marlin stuff.
Doing it this way would make the process less error prone, and it would help advanced users be able to apply exactly the CNC changes they like to their boards.
What would probably be best is to just check out a fresh 2.0.0. And manually, very carefully copy/paste the configurations you have for those branches, and then force that to be the current branch for those versions. That’s as much as you’d have to do for now. Then when/if we want to poke at a new version, we would rebase those clean commits to a new version.
If you really wanted to get fancy, we could break up the commits, similar to how Anttix did, in a logical way so they would be useful individually, and we could cherry-pick them to make a specific version.
Separate from that is testing, and this is multiple topics. What you’re (Ryan) describing is a end-to-end system test, with motors installed. That’s all great, but it’s labor intensive. You really should only do that test if you’re already pretty sure it’s going to pass. Any mistakes, you want to find earlier, in easier to run tests. But a good system test is still going to be less stress for you than manually poking at it, and hoping that you’ve tested it enough.
I think the testing Anttix was suggesting was, putting as much logic into circleci as possible. I am thinking (now that I’ve dipped a toe in circleci) that you could do things like if 'Ramps' in branch: checkMotherboard(RAMPS_14_BLAH). That would just keep you from having silly errors later. You can add things like making sure eeprom is enabled, or whatever, and it will check every one of your branches. Having circleci compile it is also a pretty easy step, and again, it would just save you some time before you got to the system test.
I think you’ve been following bleeding edge even a little more than I’d like with the bugfix-2.0 tracking. Hopefully, from now on, it will just be tracking releases, or even a subset of releases, which don’t come as often.
Another completely different way to do this would be to have some kind of script that would take a Marlin version 2.0.0 and edit the configs for each of your different versions. At one point, I had talked about a python script to do that.
1 Like
This doesn’t really apply to any of the 8 bit boards though, which is what Ryan sells. You can update from a .hex file, but that’s even more complex. Also, most of the people who want the software want it because they want to change something from what is on it already (Ryan ships preflashed boards).