Interstitial Firmware Releases

Bar wrote:

Like while finding anchor point locations?

keep in mind that (especially early in the process), the location is a guess,
putting a dot in place will be implying more accuracy than we have.

David Lang

Hi Bar,
Decided to run it with the default maslow.yaml file.
Not ideal. After adjusting for the things unique to my setup, Extensions 1000, Zs set 10mm, I didn’t change the other MaslowKinetics

After 45 minutes didn’t even look like it was ever going to find the anchors.

Maslow-serial - 2025-11-10T091532.538.log (88.7 KB)

Dang I’m just sitting here lurking this thread wondering when the release will be stable enough to risk my rock solid v0.86 firmware for the benefit of all the new features :joy:

Sounds like not quite yet.

For those reading running between v0.86 - v1.13, what’s your fav stable release version?

3 Likes

I think that 1.12 was quite stable. We added a lot of features in 1.13 it seems like we broke some things along the way :confused:

I’m planning to try to do a 1.14 which is just bug fixes for 1.13 this week to hopefully smooth things out a bit

1 Like

Thank you for testing that!

[MSG:INFO: Orientation detection results:]
[MSG:INFO:   TL extension: 0.000 mm]
[MSG:INFO:   TR extension: 0.000 mm]
[MSG:INFO:   Average extension: 0.000 mm]
[MSG:INFO: Detected HORIZONTAL orientation (extension <= 35.000 mm)]
[MSG:INFO: Orientation set to: HORIZONTAL (Maslow_vertical=false)]

It looks like it detected horizontal orientation, is that right?

The 0.0mm seems strange to me because I would expect some amount of extension just smaller in horizontal mode

Yes. But it didn’t seem to relax belts at all.

Hi,

I think that 1.12 was quite stable.

On my 1.12, the belts were unwinding so much that they were loose and got tangled…

I’m planning to try to do a 1.14 which is just bug fixes for 1.13 this week to hopefully smooth things out a bit

I’ll be happy to wait for that :slight_smile:

DanVinar

For those reading running between v0.86 - v1.13, what’s your fav stable release version?

1.07 works for me so-so, but I’m also waiting for newer features and stability without unexpected problems

J.

most of the problems are related to calibration. If you have a set of anchor
coordinates that work for you, record them and enter them in the new maslow.yaml
(new place in the file, or via the web UI)

David Lang

Quick question on V1.15, I just installed it on a clean build and am rerunning calibration. I’m trying out the new “Find Anchor Locations” feature and am immediately noticing that it is detecting an orientation of Horizontal, even though I have it set up as vertical (although on a pretty steep incline, 25 degrees off vertical or so).

Is that ok? Is that expected? Can/Should I override it?

1 Like

That is really interesting! Can you post a log of when that happens?

Does it detect horizontal every time?

Yep, every time.

Here’s what I think the relevant output was from the log file:

[MSG:INFO: Requesting state change from Belts Retracted to Extending Belts]

[MSG:INFO: Center coordinates updated in MaslowKinematics: X=1332.292 Y=1332.292]

[MSG:INFO: Succeeded]

[MSG:INFO: All belts extended to 2000.000mm]

[MSG:INFO: Requesting state change from Extending Belts to Belts Extended]

[MSG:INFO: Succeeded]

Calibrate

[MSG:INFO: Requesting state change from Belts Extended to Calibrating]

[MSG:INFO: Calibration starting in HORIZONTAL orientation mode]

[MSG:INFO: Frame dimensions from kinematics: TR_X2664.584 TL_X: 0.000 TL_Y: 2664.584 BL_Y: 0.000]

[MSG:INFO: Frame size: 2664.584 x 2664.584 mm]

[MSG:INFO: Computed grid size: 1332.292 x 532.917 mm]

[MSG:INFO: Automatically selected grid size: 7x7]

[MSG:INFO: Setting z-stop position]

[MSG:INFO: Center coordinates updated in MaslowKinematics: X=1332.292 Y=1332.292]

[MSG:INFO: Machine Position found as X: 0.520 Y: -366.993]

[MSG:INFO: Setting motor positions from hardware readings:]

[MSG:INFO: TL: 2008.711 TR: 2006.359 BL: 2009.849 BR: 2009.709]

[MSG:INFO: Succeeded]

[MSG:INFO: Measured waypoint 6]

[MSG:INFO: Measured waypoint 7]

[MSG:INFO: Measured waypoint 8]

[MSG:INFO: Measured waypoint 9]

[MSG:INFO: Measured waypoint 10]

[MSG:INFO: Measured waypoint 11]

[MSG:INFO: Measured waypoint 12]

[MSG:INFO: Measured waypoint 13]

[MSG:INFO: Measured waypoint 14]

[MSG:INFO: Requesting state change from Calibrating to Calibration Computing]

[MSG:INFO: Succeeded]

Encoder fail
1.Had a problem with encoder: Read failure on top right. I have noticed this on various encoders when I have done a serious of jogs without waaiting until one stops before implementing another. This is not consistent, sometimes no problem others I loses position. Has been on all encoders, although only one at a time (Top Left, Top Right Bottom Left, Bottom Right). It seems to be the direction it is travelling in that reports the failure E.G. moving right, Encoder fail on Topp right encoder. I suspect its not an actual failre of the encoder, or connection, but a timing issue where the system can’t keep up. Relevant extract here"
Set Z-Stop
[MSG:INFO: Setting z-stop position]
JogTo: $J=G91F2500Y200 (mm)
JogTo: $J=G91F2500X200 (mm)
JogTo: $J=G91F2500X200 (mm)
JogTo: $J=G91F2500X200 (mm)
error:9
JogTo: $J=G91F2500X200 (mm)
JogTo: $J=G91F2500X200 (mm)
error:9
error:9
error:9
[MSG:WARN: Encoder read failure on Top Right]
[MSG:WARN: Bad connection on Top Right encoder, failed to read 23 times in the last second]
[MSG:ERR: Emergency stop. Update function not being called enough.1001ms since last call]
[MSG:WARN: Bad connection on Top Right encoder, failed to read 4 times in the last second]
[MSG:ERR: Emergency stop. Update function not being called enough.1002ms since last call]
[MSG:WARN: Bad connection on Top Right encoder, failed to read 74 times in the last second]

1 Like

Was going to combine these 2 but they show separate effects.
Ran Find anchors for V1.15 with 0x0 Calibration grid and 9x9 Calibration size after encoder failure (As I had to do a Retract, Extend anyway)
Summary of result
Calibration values:
Fitness: 1.0307216907134038
Maslow_tlX: -162.5
Maslow_tlY: 4008.3
Maslow_trX: 4537.4
Maslow_trY: 3964.5
Maslow_blX: 0.0
Maslow_blY: 0.0
Maslow_brX: 4567.6
Maslow_brY: 0.0

Observations:
In The Y direction (Height) Maslow stayed within the confines of the Waste board with a safety margin of approx 50mm
In the X direction (Width) the Maslow was right on the edge and had to be physically supported on the last pass. May need to limit this to 50mm safety margin.
This was the best Fitness I have achieved with a 9x9 matrix.
Maslow-serial - 2025-11-29T082259.915.log (49.8 KB)

1 Like

it detects horizontal vs vertical by feeding out some belt and seeing how far
the encoders move. you should see this happen at the beginning of the ‘find
anchors’ movement.

If the sled does not move (bottom not slick enough) it will detect the layout as
horizontal.

mostly this just means that it pulls itself in all directions instead of
expecting gravity to move it down during calibration (I don’t think there’s any
practical difference once it’s in operation)

David Lang

Interesting! I could see it being the sled not sliding enough. Thanks!

So why the need to have orientation as an issue if it will use all belts in calibration and operation. Or am I missing something. Seems to me that it would be butter or at least a little more stable for all belts to pull during calibration anyway (all way points).

bday wrote:

So why the need to have orientation as an issue if it will use all belts in
calibration and operation. Or am I missing something. Seems to me that it
would be butter or at least a little more stable for all belts to pull during
calibration anyway (all way points).

there are many points during calibration when belts are let out. If you are
vertical, if you let out on the top belts, the sled will move and the belts stay
tight.

if you are horizontal and let out on the top belts, the sled doesn’t move, the
belts get loose and move a small amount, and then the spool unwinds with no
movement and no way for the maslow to know how much it’s moving.

once you know where the anchors are, you can power all 4 belts to move and know
they will be right.

before that (all 4 belts in horizontal mode, bottom 2 belts in vertical moce),
you have to let out belts for a given time (because you can’t do it for a given
distance), then tighten some belts, then tighten the belts you fed out (in
horizontal mode, the order that you do this is different for each quadrent of
the machine)

David Lang

1 Like

Tried setting 0x0 grid and running Find Anchors (version 1.15). It worked, but on the width the Maslow overlapped the ends of the waste board, so I had to manually support the Maslow to prevent it tilting over the abyss on the last pass. This is a potentially a problem if you are not aware of the possibility.

On another note @bar do you intend to put the next version here to let it be tested prior to release? Is it time we moved to releasing a “stable version” and a “development version”?

1 Like

I agree, I think that is an issue. I just made an issue for it here: Apply work area settings when generating the calibration grid · Issue #615 · MaslowCNC/Maslow_4 · GitHub

Yes, but I think that we need to do it after this release. Immediately after this release I am going to make a “Stable” branch which only will get bug fixes. Maslow-Main will continue to be the dev version (since the AI likes to make it’s pull requests there)

1 Like

One other thing, after running this the grid size remained at 0x0 in the maslow.yaml file. I had to manually change it to 20x10

1 Like