Marlin 2.0!

Software / Firmware
21

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
22

To some extent :stuck_out_tongue:

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.

  1. 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.

  2. 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.

  3. 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
23

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
24

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).

25

I am willing to bet $20 that the cheap 32bit boards will overtake the hobby world within 6mo. $100 that it will happen within a year. 32bit MCUs are actually cheaper than Atmel Megas.

Seriously, I just ordered an SKR v1.3 from aliexpress (the one I had before was a loaner): $15 shipped to my door. Even RAMPS boards are more expensive now.

2 Likes
26

Many of the users of the MPCNC aren’t buying stuff from aliexpress. They also don’t flash the boards themselves. They buy ultimachine boards from Ryan because a) They are supporting Ryan, b) They are getting hearty boards with lots more reliability than a ramps and c) They are getting it ready to go, not having to install arduino.

The fact that the 32 bit boards require platform.io is a bit obstacle, IMO. The fact is that right now, the 8 bit boards are the standard, de facto, and they should be the focus. I’m not trying to get in the way of 32bit, but it’s not a good selling point.

1 Like
27

I’m simply pointing out that the cheapest 32bit board is now cheaper than the cheapest 8bit board ever was and more expensive boards are following suit. I just checked ultimachine.com, RAMBo and Archim boards are priced exactly the same. I’m willing to bet money that Ultimachine will stop manufacturing and selling 8bit boards soon.

Users of 32bit boards expect a precompiled firmware that is easy to update. Compiling Marlin is a tall order for most people, whether one needs to fuss with platform.io or Arduino IDE doesn’t make much of a difference in that.

28

They do for a while then they jack them up. The longer you are around it the more you see it happen. Ramps and drv’s are the perfect example. The just keep trying to shave another penny off then one day you realize a 50% failure rate is only valuable to people that have a lot more time than money. There are no returns and shipping takes more time. The fake Ramps were great at first, within months they got bad, two years later I will never buy one again.

29

I have actually spent a lot of time this morning with ultimachine trying to figure out a strategy for next year, the boards I will carry and the prices. I sell kits without boards, and have no issues with the import boards, but I found more than half of my customers just want to know it will work. Those of use that like to experiment do, the ones that will pinch pennies will, but from a product standpoint I would rather know the issues I need to solve are project based not product based for my customers. On the back end I am doing everything I can to offer things for a price that has only gone up once in almost 5 years, yet the quality has improved drastically. People paid the same price to get ramps kits from me because teh failure rate was so high and I had to test every aspect, assemble, adjust pots and trouble shoot so much. Time is expensive. Since the better Ultimachine boards we are no longer a ramps troubleshooting forum, now we discuss projects and features most the time. So for the end user they actually do not cost any more.

1 Like
30

I am not questioning the value of good tested boards. However the market for MCUs is such that 8bit chips are more expensive than 32bit ones. The only reason for manufacturers to buy these chips is to support an old design. Chip makers know that and prices reflect it. The competion is in 32bit, nobody will swap out an 8bit chip in an old design.

From V1 customer satisfaction standpoint, 32bit is a lot easier to update for end-users so if Marlin is finally stable on Archims, I would not bet much on 8bit any more. Even 8bit champion Prusa caved and their new Mini has a 32bit board.

1 Like
31

Just sticking this here for the good of the order. In case there are folks (like me) who are just dipping their heads into flashing firmware and doing special tweaks. This is more geared to 3D printing, but it is a good overview.

2 Likes
32

Just for the record, all of the v1 machines that started from Ryan’s firmware in some way in the last year, at least, are running 2.0. There’s no need to flash your board to 2.0. But good to share this video anyways.

2 Likes
33

Currently it is not. I can not get platform.io to flash a board. To counter this Ultimachine has updated the arduino file for their boards so we can flash them using my preferred LCDs just as always. But they are not stable. The 32 bit boards get knocked out all the time during updates and the 8 bit boards do not, there may be minor issues but you can always work around it. Not the case with 32bit.

It is a little different for us. We use 3 axis and most of the stuff in Marlin is to no use for us. A lot of the extras we use, we put in there.

The MCU is only one component, 32 bit boards take more hardware and a more expensive board as well.

32bit is probably going to start getting a larger share of the market but for our purposes and most, honestly, it is more than is needed. We are not running a touch screen or any advanced features. I know it feels like they are taking over but but I still think there are far more people still asking about ramps boards they just bought than all 32bit boards combined.

34

A few send in their boards to get them flashed. You can tell by this thread how many people are actually exited about new firmware. To us it is a huge thing, we enjoy looking under the hood. A extremely large margin of the daily CNC user are probably scared to mess with anything that is making them money. If it ain’t broke…

So I am completely in to automate the updates. With circle CI I might even be able to figure some of it out. If I link the current stable releases it is no big deal as I can ship boards with that.
I just think I would rather spend that time on trying to get arcs to work or maybe figure out some real tests to set the numbers for junction deviation and any other acceleration related numbers. This is real world results for the majority. I am best at working on the actual hardware but enjoy getting better results using software and firmware. In the end I think I am just jonesing for new hardware and keep getting side tracked with software that takes me an uncomfortably long amount of time to fix and figure out. I made the first LR in 2 days, the new docs took us weeks I did not do much of that.

So maybe we wait to mess with the firmware for a new milestone. 2.0 has not added anything for us at this point so I do not see a reason to update. If we get arcs back or extruders=0 it would be a good reason to spend some time on it but I think those of use that want to try the bleeding edge have the ability to easily do so, fetch, flash, done.

1 Like
35

Indeed, we are not, but that could really be useful. Think about all the possibilities that would offer.
Draw an simple shape on the screen or select a few often used shapes, set the dimensions in a few clicks, then cut it using pre defined tools and feed/speeds.
I can see a lot of times that would have been useful to me, sometimes I’m just lazy to go over all the 3D drawing+Esltcam path setup and manually cut stuff just because it’s faster.

That’s actually one of the reasons I made my remote control, this way I can manually cut some easy stuff without having to set up too many things.

Could be useful for many simple operations, some simple cuts, simple pockets, surfacing…

36

None of that exists currently. I would love it, and it would certainly be a reason to switch but now we can use V1pi for all sorts of crazy advanced stuff but not many do. Most just want to run the gcode and know it works, even more it that they would prefer to cut faster…so testing some motion equations would be a better use of time? To date I think me and Jamie are the only ones that have done any Junction deviation testing but even then both of us kinda set it aside as it either does not work or we are not understanding it correctly.

37

FWIW, the touch screens just interact with Marlin through serial and they generally take less CPU than the rep rap full discount one we are using. They don’t do all that CAM through the screen though (they are meant for 3D printing, and it takes some doing to cut all that stuff out).

38

I know it doesn’t exist, I’m just saying that would be cool!

1 Like
39

Can it be done with v1pi and an octoprint plugin though? It must be out there already.

40

Octoprint has a plugin system. So you can do anything! You can even do magic, if you’re a wizard!

2 Likes