Marlin Web Configurator?

Software / Firmware
1

Half-baked idea: web version of MarlinBuilder for making custom configurations, but limited to defining the configurations and not building them.

The idea is a Web UI where a collection of radio buttons and check boxes are used to set up a configuration. Ideally there would be some means to take multiple partial configurations and “layer” or “compose” them, similar to MarlinBuilder, rather than specifying every option individually. The UI for this would need some careful design for it to be intuitive.

Then press “Generate” and it produces a zip file containing platformio.ini, Configuration.h, and Configuration_Adv.h. (Maybe eventually it could also include updates to pins.h but for now let’s say no pins.h updates.)

Then you build locally with VScode (not as GitHub action or WSL or Docker or any of that).

The configuration can also be specified as a URL with with a long query string, so if someone is asking for help with a configuration, it’s possible to direct them to a specific custom configuration.

The UI with check boxes and radio buttons could also have documentation (expand/collapse) to describe the functionality.

Nothing would change as far as the supported versions. It might also be very helpful to highlight the differences between a specified configuration and the supported version.

Is this crazy? What am I not thinking of?

3 Likes
2

That is dreamy!

In some ways it could be easier, some things a little harder. Could be possible.

Pins… unfortunately are not all defined the same way. Some are in the configurations though.

1 Like
3

Doable for sure.
I have something like that for my own firmware here.

In my case I have 2 additional .h files that allow overhall override over almost all options.
It reads the default values of the repository using regex.

I did it in old AngularJS because it was the thing that I could learn the fastest (faster then React or Vue at least). The coding is ugly as it gets (again I’m a major noob with those tools) but kind of works with some limitations.

4

If you’re tied to VS Code (I prefer platform.io) - possibly consider Webview UI Toolkit for Visual Studio Code ??

1 Like
5

Wow! Nice!

I’m definitely going to draw from that where possible.

I am so out of touch I am still rocking hand-crafted HTML like it’s 1997, but with jquery sometimes.

I think I am aiming for beginner/intermediate customization that offers a narrow or medium set of options, and for unusual stuff you are back to digging in the config files. There is definitely a balance to be struck between completeness and simplicity, so collapsing or hiding the advanced options is going to keep the UI sensible for the beginners.

When I said VS Code I meant with platformio as the build tool. (platform.io appears to be something completely different?).

I don’t think a VS Code plugin helps much in the cases I’m thinking of. I’m wanting to replace the practice of sending config files around. And if it’s a convenient home for documentation of firmware options, all the better.

6

How many LR, MPCNC and MP3DP machines get built each month? How many people with existing machines would like to customize and tweak their configurations, and/or get Marlin updates, without the hassle of compiling software?

How many people don’t build V1E machines because they don’t have time/interest in compiling firmware?

Wondering whether there’s enough existing demand, and/or potential to unlock demand that makes sense to have a VM and/or onprem worker server that builds configurations on demand. Or, manipulate GitLab/GitHub actions into generating the builds, adhoc branch creation and build automation, async build and notify via email with download link to blob stored firmware.

Ideally non coders shouldn’t be forced to install, upgrade and sustain VSCode, platform.io, Marlin, etc… How many people are turned off and decline to build because of this barrier?

Ideally, most people would be happy visit a one stop download/shop website, most would go through a wizard for vanilla setup, some would select custom options.

At the end, most would get a link to download the existing prebuilt firmware on github for common build configs.

The custom folks that endure/like compiling get the opportunity to download config files and self build.

Custom build folks that don’t like to code can sponsor a build of their desired config. (executed by VM, cloud/basement compute), am thinking low cost just enough to have the convenience service be self supporting. Potentially cached (MRU capped/bounded storage consumption) config firmware set, and serve again… Payment stuff could come in later, may not be needed even given firmware’s tiny size and expected traffic/usage. A free to use MVP/POC could use very cheap barely good enough VM to execute on-demand config and compilation.

7

There was a tool by thinkyhead that basically did this. It was a pretty basic UI with a big input form and it would spit out the config files to load into the builder.

The big issue is that it has to track changes in Marlin, which are common and always come with updates to the configuration files. Focusing on only a few config parameters, or higher level features (like combining all the auto squaring into one toggle) could make the job easier.

I do think there is a lot of value in making a server do the compilation. For one thing, it is a constant verification that the configuration is done sort of correctly. For another, building the code is trivial, but setting up the build environment can be complicated.

We have quite a few configurations in github. There is probably a way to automate the result of a configuration to kick off a build in github actions.

The other issue is that the real work is testing. If everyone ends up with a different version, we won’t know if the issue is in that configuration, or in wiring or something else. Testing all the configurations is many hours of work. People who are not willing to configure Marlin are probably also not who you want to give untested software to.

I would much rather people create configurations in MarlinBuilder and push those configs into the main branch as “community” builds. Maybe we should even put a name on each config. That would mean that these configs would be built on each release, and you could judge how reliable they were by checking who was supporting them.