You can’t trick me you know wizard’s can not reveal themselves to mortals…
1 Like
Octoprint doesn’t have a plug in like the one described yet but yes it could. The coolest plugin I saw uses the web cam and sends images to a cloud based AI to search for Spaghetti. If it is detected it will pause the print. That’s cool.
1 Like
The ask for on-machine drawing / shape selection is not actually that far fetched. The handheld Shaper Origin has a feature like this. It can also access a shape library over wifi that one can pick stuff from.
Not all of them. MKS Robin Nano has a touch screen that connects directly to the on-board STM32 chip. Marlin even has limited support for it that basically looks like the regular menu with tappable buttons drawn underneath it … 
Really? Their boards don’t have a bootloader that can just take a firmware update from an SD card so you have to still mess with some uploader program?
Okay I am done for the night, but in hopes of coming to a solution of sorts. Like I said I trust all your opinions. What should I be working towards?
I can link the current “stable” firmware like we used to do. I can then update the current branches all the time and spend no time testing them. At some point work on automating that to do it daily or something. OR just leave it until there is a specific reason to work on testing a new update?
Update the firmware from the SD on the LCD I heard it was a possibility but if it can actually be done why the heck have we been using arduino all this time?!
Looks like @jeffeb3 and @anttix agree that rebasing strategy may be worth trying out 
So I’d start with getting the history cleaned up. From there it should be fairly easy to rebase to update. Next step is to automate this so we can react quickly if upstream breaks the build. Then from there move on to publishing nightly binaries once there is a solid firmware update process that doesn’t require compiling Marlin.
That is a good question 
8bit boards can’t do that but 32bit sure should be able to because there is a separate program area for the bootloader.
EDIT: I’m actually referring to the micro SD slot on the board itself, not the one attached to LCD.
I am just not seeing what that accomplishes. If we get extruders=0 then why bother keeping anything up to date and clean, why not just the config and config advanced like the other marlin example builds built into Marlin already.
Then we can skip all the, me maintaining my own marlin, and we can all just concentrate on the actual marlin issues?
I have only sold a handful of archims. it is only on my priority list because I would rather use them than rambos for the price.
That would be the ultimate goal. But you may still need to keep some changes in your fork like the laser fixes etc. I’m not sure if the config files is better than a bunch of branches. I think given Marlin does support a set of “example” configs this mode it may be worth exploring.
EDIT: I mean a config file for each machine/combination and a CI job that builds them may be easier to maintain than a ton of branches.
Now we are getting somewhere. Skip the short term fix. I do not maintain laser fixes and such for that exact reason. I put instructions on how to do it, but maintaining it is too much work for me. I would rather just help fix it in marlin. Just like the dual I made it work once then me and heffe pushed hard for weeks (months?) to just get it into marlin.
1 Like
Next steps:
- Get a sleep or two in.
- I would advise against merging in 2.0.0. Instead, get a clean 2.0.0, and create your changes on top of it. We can help get the diff (git knows) so this shouldn’t be an effort in “finding” all of the changes.
- Test 2.0.0, and then make this the new stable.
- Breathe.
- Have unstable versions that follow bleeding edge. Rebasing our changes onto the latest. Releasing a new stable is easy, because we rebase.
1 Like
Agreed. However a CI setup is still good for testing that the configs build with each Marlin update and for producing binaries for a handful of boards sold at V1 shop and maybe for some popular cheapo options like SKR v1.3. From the interest towards this board during the last few months, I’m willing to bet that this one is going to be the new RAMPS.
The point of producing binary builds is to rope more community members into testing the firmware.
Yeah, this is basically what I did. I can redo it to make sure I didn’t miss anything and post to my github.
1 Like
OHHHHHhhh, that actually matters. I guess that is why thinkyhead always makes us rebase. I thought it was a tabs vs spaces programmer voodoo thing.
3 Likes
It is voodoo - branching is evil!
Most high-traffic projects want you to rebase so they can keep history clean and neat. Unlike tabs/spaces this pattern has some proven logic behind it. Alternatives like gitflow work too but rebase is often preferred if “private branches” which a PR basically is, exist.
1 Like
Spaces have a proven logic behind them…
1 Like
Agreed, this is the moral equivalent of a rebase, just has to be manual if they have done serious refactoring.
Then in the future, assuming they are no longer renaming variables all over the place, it should be easy to transfer the changes to an updated underlying version.
Yes, that’s exactly the kind of things I’d like to see on our CNCs.
Pretty sure it’s easy for us to do hardware wise, we probably already have everything and don’t really need the fancy camera system, so it should work without any hardware mods in our case, except of course a nice screen and a more powerful board than the classic Arduino/Ramps. The only real mods to do are to create a firmware that would be able to do that (easy to say, I know…)
That would really be awesome, I can think of a lot of things that would beneficiate from it:
-Some manual CNC work for simple operations like pocketing, simple straight cuts, surfacing, precise drilling…
-Possibility to quickly draw and cut some not too intricate designs
-Automatic waste board surfacing
-Possibility to download and directly cut some designs from the community
-Having a default tool bank, so if you select a tool from it the machine already has all the correct setups for feeds, speeds, etc.
-Basically guide the user through the process, with some alerts and reminders at each step, little videos of how to, stuff like that (“did you secure your material”, “set your origin”, etc.)
That would really lower the bar for most beginner users. No idea if this is actually difficult to code though.