Interstitial Firmware Releases

Some folks have noticed that we’re running out of memory to store the index.html file and that is leading to unexpected behavior so I’ve been working to compress the index.html file to be smaller.

I believe that the relievant threads are here:

and

I found that we were storing some unexpected and unnecessary language data in the final result which was making it bigger than it needed to be so I’ve removed that and now we should have quite a bit more free memory to play with.

Any feedback and testing would be greatly appreciated. Here is the updated index.html.gz file:

index.html.gz (110.7 KB)

just a note that the big pile of commits that I have submitted will reduce the
firmware size (by eliminating multiple versions of essentially identical
functions).

I don’t know if it’s noticable overall, but it’s a bit.

David Lang

2 Likes

Unfortunately I think that the firmware is a different memory pool, but also one that we want to reduce.

What is the status of those PRs? Are they ready to merge?

I’ll re-calibrate again soon now that this sheet/project is “finished” (didn’t turn out that well) and I can test the new version.

1 Like

Bar wrote:

Unfortunately I think that the firmware is a different memory pool, but also one that we want to reduce.

I think it’s stored on the same storage.

What is the status of those PRs? Are they ready to merge?

Yes, you were holding off to wait for the renaming work to settle, but each one
is compile tested, so you can merge as many or as few as you want in any update.
Each commit should provide som improvement (if only in code clarity)

David Lang

2 Likes

I’m still working on the ‘de-gulping’ PR for the front-end. It’s turned into a complete rewrite, but that was always a possibility. I’ve kept it up to date with Maslow-Main, so any updates to that will be straightforward for me to merge in.

Currently I’m getting the actual build process to work properly, the bit that specifically replaces gulp. This is the one area where bun is still a little immature. It is an area of focus for their devs right now. But I’ve got my head around the outline of it and I’m progressing through the work arounds.

A criticism that should be made about the front-end code base. Very, very, bad decisions were made in an effort to maintain backward compatibility with older browsers, eg. IE. The approach taken is one that experienced developers (at that time) simply would not have chosen.

Shuffle forward to today, and those past decisions should not, under any circumstance, be honoured. They significantly impact ongoing development. The path forward is to migrate away from those poor decisions as fast as is possible.

1 Like

That sounds like a good plan to me, what kinds of things did they do?

Here is an updated index.html which should fix calibration on 0.86.

index.html.gz (110.7 KB)

This can best be seen from some of the files from other packages that were pulled into the code base, rather than referenced as dependencies in package.json.

This opening comment from simple-toolpath.js for example

// This file was translated from
//   https://github.com/cncjs/gcode-toolpath/blob/master/src/Toolpath.js
// by Babel (http://babeljs.io/repl), with preset "stage-2"
// The import and export statements were first removed from Toolpath.js

And this from simple-parser.js

// This file was derived from
//    https://github.com/cncjs/gcode-parser/blob/master/src/index.js
// by extracting just the parseLine() function and using Babel to
// translate that to older Javascript

At that time the best decisions would have been to go straight to TypeScript, because the TypeScript transpiler (even back then) would have allowed you to target any version of Javascript you wanted. And it would do all of this work reliably.

But perhaps the opening comment from simple-interpreter.js really spells it out

/* eslint no-continue: 0 */
// This file was derived from
// https://github.com/cncjs/gcode-interpreter/blob/master/src/Interpreter.js
// as follows:
// a) Removed the import and export sections, and manually translated from
//    class syntax to prototype syntax, for compatibility with old browsers
// b) Removed all of the load* methods, replacing them with a single method
//    loadFromLinesSync().  Since we know that the interpreter will be called
//    twice, first to determine the bounding box (for sizing the canvas) and
//    then to render onto the canvas, the gcode string can be broken into an
//    array of lines once and that array reused for both passes.  This also
//    eliminates the need for a parseStringSync() function in simple-parser;
//    the only necessary function is parseLine().
// c) Replaced const with var
// d) Replaced arrow functions with real functions
// e) Replaced let with var

Everything, apart from perhaps item ‘b’, was a bad decision.

How to support older browsers is an important question. And when that browser is too old, the correct decision is genuinely; “don’t support it”.

So what is too old? Does the browser have significant security issues? Can it meet what’s considered baseline as at about 2 years before now? Does it have its own way of doing things that no other browser does? Answer yes to any one of those questions, then it’s too old, and you need to specifically call it out for people. They need to be helped to upgrade, rather than everyone else be held back.

1 Like

I need to find someone to work with for testing patches. My maslow is a 30 mile drive away (plus setup/teardown time) across Los Angeles traffic, so it’s hard for me to do testing.

1 Like

Here is 0.87.1

firmware.bin (1.9 MB)

0.87.1 adds an extra measurement at the beginning of the calibration process where the will take a second measurement in the same place as the first measurement but pulling harder the second time.

In theory if the frame has no flex we should see no difference between the two measurements. The result is presented like this:

[MSG:INFO: Flex measurement: TLBR: 0.199 TRBL: 3.619]

The TLBR is the amount of flex between the to left and bottom right anchor points and the TRBL is between the top right and bottom left anchor points.

I would love feedback on what kinds of numbers folks see so we can get a sense of what a “good” measurement is and how well the system works.

3 Likes

[MSG:INFO: Flex measurement: TLBR: 5.331 TRBL: 5.281]
The final calibration was 0.5313458448276723

I have been having minor issues with the bottom left arm not retracting all the way and have had to up the force on it. I am not sure if it has been the cold or the idler gear, I was doing some cuts in an uninsulated space in sub freezing temps.

It was fun watching the unit shift and hearing the creaking in the frame when the higher tension was applied. Note mine is a torsion box with two slide on wings for the anchor points, similar to the hour glass design.

2 Likes

Excellent feedback! Thanks for the numbers :smiley:

1 Like

@bar TLBR: 1.144 TRBL 3.605
First calibration failed, second gave me TLBR: 0.918 TRBL: 4.029

Going to test with a lower belt tension later and I’ll post here again with those numbers. This is with the stock 1300 retraction force.

1 Like

Roughly 0.5 and 3.1 with a retraction force of 1000 on a vertical frame.

Here is 0.87.2 which is a significant re-write of the calibration system. This removes the need to enter an initial guess for the frame dimensions you now just simply enter how long you want the belts to extend. As long as the belts are long enough to connect to your frame (no need to be centered or anything like that) the calibration process should be automatic from there.

This update requires updating both the index.html file and the firmware.bin file

index.html.gz (113.6 KB)
firmware.bin (1.9 MB)

It still doesn’t do a perfect job and occasionally won’t converge on the correct solution. I’m going to work on making it automatically try again if it fails, but hopefully this is a step towards making calibration more reliable.

As always I would love to hear feedback and thoughts!

3 Likes

Initial feedback on the Extend Dist field. It took a few guesses of extend/retract to get enough belt length. It would be nice if you could start with an initial number and then hit a button for more belt length so you don’t need to retract and extend again.

Calibration went really weird, starting at y -100, I was not sure what pattern it was following for the first few locations and then failed after the first set of points with a 0.13. It is around 38f in the space where the machine is, which might be too cold. Will try again when it is warmer.

1 Like

I’ve seen this before too. I’m working on making it automatically try again when that happens. Starting with less information means that the system is more likely to fail to find an answer. The good news is that it can just try again without needing to re-do any measurements.

Thank you for trying it out!

Here is an updated index.html file which will make the calibration process automatically recompute if it fails because the value is too low.

Interestingly while testing I found that I was able to actually get higher calibration values using this system by bumping up the requirement threshold for what makes a “successful” calibration. Since the system now recovers if it doesn’t hit the threshold the first time we can set the threshold higher and force it to try harder.

index.html.gz (110.8 KB)

For anyone interested in testing I would recommend skipping the earlier index.html and just using this one. Feedback is super welcome!

1 Like

I would suggest (at least as an option) that you just put the belts in comply
mode and let the user run them out as far as they want to until they tell you to
tension them.

for vertical mode, you need to have the belts stop so that you can hang the
machine, but for horizontal mode, there is no reason to only feed out a specific
amount (other than setting a max amount to avoid going past the end of the belt)

and there is especially no reason to fuss about a belt not being fully extended
if a user tells you to tension the belts.

David Lang

2 Likes