Interstitial Firmware Releases

I’ve been working on a major PR for the WebUI to replace gulp from the buildchain (because it is ‘abandonware’) with something up to date, for which I chose bun.

To the extent that I could, I’ve pulled out little PRs from this work, which have been merged in progressively, and are somewhat backward compatible, you could say they are ‘gulpible’.

However, the main PR is a massive change, which means that we wouldn’t be able to throw a PR from Maslow-Main back up to the github repository that it is forked from. AKA this would be a ‘hard fork’.

Considering that so much in that code base is ‘abandoned’ in some way or other (even though the rest of it is still being worked on) it can be easily argued that ‘moving on’ is the correct thing to do. Having poked around everywhere in that code base I would argue that we’re better off just focussing on moving forward. The significantly reduced number of pain-points makes it easier to maintain.

And with all of that, here’s one metric I’d like to show off:


That’s 99KB for index.html.gz

5 Likes

Here’s Bun — A fast all-in-one JavaScript runtime for those who would like to explore for themselves.

Note that their bundler is still not that mature. But in comparison to what you had to use with gulp, let’s just say that it is more than mature enough.

2 Likes

I think that this is 100% the direction that we want to move in.

How are you feeling about the current state of Maslow-Main? Should we try to fix the issues there (it feels like we’re close), or should we jump straight into the new Bun system and move forward from there?

I think that a top priority should be getting to baseline stability quickly so that we can keep making regular updates and releasing bug fixes (hopefully without introducing new bugs :joy:)

2 Likes

There’s a spectrum of issues here, although I would kinda class them three ways:

  1. M4 specific stuff, more people know that part of the code, it has more focus, and yes we’re getting closer.
  2. Other bugs and issues in other parts of the code base. AKA ‘legacy code’, Fixing bugs out here is fraught with problems. In general it is better resolved by asking “what was the intent of this code?”, “is that still relevant?”, figuring out answers to those two questions you can then ask; “if we don’t seem to need this function any more should we just remove the associated code?”, “if we do need it, how would this code be written today?”
  3. Finally there’s dependencies on other code bases and where they are at. In the case of WebUI, there’s no dependencies in the code that gets deployed. But there are significant dependencies on code used in the build process (gulp and friends).

  1. Fix in place - would be the right choice
  2. If legacy code is impacting stability - then we’re probably better off cutting our losses and moving on, but this is a gut-feel kind of thing
  3. Move on, gulp is abandonware, there are significant security issues with the build chain as it is, we cannot fix it ourselves.

Fix everything that is M4 specific and prioritise on this.

Anything in the rest of the code base that is causing us significant stability issues then becomes the trigger to switch over, but if there aren’t currently significant issues, then by definition switching over becomes a lower priority.

‘gulp’ is holding us back, that’s a fact. I’ve just about finished getting a fully working version based around using bun for the build chain instead. So that work is done. Now the decision to switch can be made in a more considered fashion.

Ultimately we will be increasingly less stable by sticking with gulp, but at least we can choose when to change now.

My Maslow 4.0 PCB has an ESP32-S3 with 8 MB of Flash memory, but the firmware currently maps only 4 MB. I’m not sure if this applies to all PCBs, but if it does, it’s a trivial change to make the extra 4 MB available:

@bar I’d be happy to submit a pull request for this change. Let me know if you’re interested!

2 Likes

Calibrated with 0.88 today, starting with 1900mm extension which is way too high. you can see the fitness evolution at each step 3x3, 5x5, … ,9x9 in bold (1000mm height and 2000mm width) and the comparison with older firmwares. I put the ‘stiffness values’ at the right of the table, but I didn’t take the time to think about their meaning yet.
I achieved my best fitness score so far (so close to 1 : )

3 Likes

That looks like the highest fitness yet! Nice! :+1: :+1: :grinning:

Thank you :slight_smile:
Is there some doc where I could learn more on :

  • How to correlate the fitness with the quality of corners location estimations (I know about GA, but how do they are applied within the calibration phase)
  • What are the ‘stiffness talues’ TLBR & TRBL representing

Also, another point (not in the right forum section, sorry) : it becomes more and more difficult to retract belts, I have to press the button dozen of times now to fully retract, and while doing so I can hear noises sounding like some plastic parts are difficultly moving. Is that a classic issue over time ?

gwen wrote:

Is there some doc where I could learn more on :

  • How to correlate the fitness with the quality of corners location estimations (I know about GA, but how do they are applied within the calibration phase)
  • What are the ‘stiffness talues’ TLBR & TRBL representing

short answer, no :slight_smile:

longer answer. we don’t know what exactly these things mean yet.

the fitness score is an estimate of how accurately the anchor locations are. It
is not used for anything other than reporting to the user at the end of
calibration.

the stiffness value is just a measurement of how much the frame flexes when it’s
pulled.

How much this matters will depend on how hard the sled pulls during cutting.

The faster you go, the harder you have to pull.

An upright frame will pull harder (because it has to fight gravity) than a flat
frame

The more friction between the sled and the workpiece, the harder you have to
pull (are you sliding on OSB or a laminate coutertop)

the duller the bit you have, the harder you have to pull

and the bottom line is that we don’t know how accurate you need the machine to
be. Bar does most of his cutting on a frame that’s “too small” and “too
flexible”, but it’s good enough for the things that he makes. If you are making
something with interlocking notches, you will probably need more accuracy than
Bar does.

Also, another point (not in the right forum section, sorry) : it becomes more
and more difficult to retract belts, I have to press the button dozen of times
now to fully retract, and while doing so I can hear noises sounding like some
plastic parts are difficultly moving. Is that a classic issue over time ?

The maslow 4.0 has a couple known issues (fixed in the 4.1 parts)

  1. there is a c-clip on the motors that can rub on the arm, creating plastic
    dust that can get into the works

  2. the nuts on the inside of the arms can rotate slightly and rub against the
    spool, causing friction and plastic dust.

  3. the idler gears can wear and take more force to turn.

As this dust interacts with any lubrication it turns into a paste and gums
things up. Take your arms apart, clean them, look for wear, and reasseble them.

David Lang

1 Like

I reran the config with this version (index.html.gz : Jan 15) after running V88 index.html. No improvement. Did note it’s version number is 0.87.