It’s here!
4 Likes
Sweeeeeeet. I will update the V1 branches in a few days just in case.
Fixed the titles to less.
3 Likes
Nice!
I see a few cool new features, like the power loss recovery and backlash compensation.
What others things do you guys find interesting and could be applied to our beloved MPCNC?
AFAIK, all of these features have made it inti Ryan’s firmware already. I am just excited that it will be a stable version, which should give Ryan a less volatile foot hold.
Jamie’s joystick stuff is in there though.
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