I definitely had the latest this time. Managed to do a full Configure, but only by moving the table under the Maslow as it went through the las iteration, else it would have gone over the edge, on bottom and top
Maslow-serial (74).log (27.4 KB)
Ian Abbott wrote:
I definitely had the latest this time. Managed to do a full Configure, but
only by moving the table under the Maslow as it went through the las
iteration, else it would have gone over the edge, on bottom and top
makes sense, I’ll have to shrink the max from 4x8 to 3x7 to give 6" on each edge
I’ll go through the log after I get some sleep.
David Lang
latest version, it sets the grid size after the initial 6 points, so you should be able to run it with existing anchor coordinates set to 0
it also sets the max grid area to 7x3 to give 6" of room to keep from going off the edge.
it’s not doing the asymmetric grid size, so I’ll have to look into that next
for those wanting to test, you can get this version from: Implement automatic calibration grid sizing with safety constraints and adaptive validation · BarbourSmith/FluidNC@18fab56 · GitHub
Successful run without moving table. I have a 100mm skirt on the sides and it was partially on those (as expected) but not at risk of falling off. See log file
Maslow-serial (75).log (24.3 KB)
Ran a test file after this. It completed, but Maslow would not return to home position and I can’t jog anywhere. Z is unaffected. Maybe unrelated. Have to go to work now, will try again later
maslow (8).yaml (6.8 KB)
It overwrites any info regarding max grid size entered manually
1 Like
the latest version of this is available at
now tested by a couple people on multiple runs, so it’s looking pretty good.
1 Like
@ian_ab looking through the config, you have belt end extension set to 1000 exactly, that seems a bit unlikely and you may want to double check it.
This should be the distance from the flat end of the belt end to the center of the pivot hole.
If you started with 1m square tubing, I don’t think it’s going to be off by a lot, but figuring it out exactly may produce a better calibration.
If these values are set, I don’t think the Find anchor points routine should overwrite them. If they at the default of 0, then they should.
1 Like
Ian Abbott wrote:
If these values are set, I don¢t think the Find anchor points routine should overwrite them. If they at the default of 0, then they should.
I believe that just after you initially reported this, I changed it so that the
automatic calculations did not affect what was in the file.
David Lang
1 Like
Ian Abbott wrote:
If these values are set, I don¢t think the Find anchor points routine should
overwrite them. If they at the default of 0, then they should.
responding to the 2nd part, if it’s set to automatic, then after running it on
automatic, I would argue that it should still be set to automatic.
(the hope is that the automatic is good enough that we don’t have to have people
set it manually, or reset it if they use the maslow on a different frame)
David Lang
1 Like
Where is it set to automatic?
Ian Abbott wrote:
Where is it set to automatic?
if the grid size is set to 0 it does the automatic grid calculations.
David Lang
While you are testing, could you test this UI patch? It should have no interaction with the firmware changes
This shows a bounding box (which I’ve verified is sane) but also should provide a button to run the router around the bounding box and then back to where it started. (which I have not been near a machine to test)
part of this PR: Implement bounding box visualization and boundary tracing for GCode jobs by Copilot · Pull Request #192 · BarbourSmith/ESP3D-WEBUI · GitHub
Changed X to 2200mm and ran. All good, did not update yaml file for Calibration Grid X.
1 Like
@ian_ab continuing this testing here
This would be the next one to test:
it looks like the spacing parameter got lost, let me nag the AI
Compile Firmware on MaslowBot Review Request #609
Maslow-serial - 2025-10-07T070611.574.log (4.4 KB)
USB_Serial_Configuration.txt (6.8 KB)
Just used existing didn’t attempt to move. Trying again with grid set to zeros
2nd attempt no change.doing the dance to force re-read maslow.yaml
the next test will have Maslow_calibration_grid_spacing in the maslow.yaml, but we have to first get past the error in starting calibration (caused by the refactoring and changes in memory allocation to have the calibration grid calculated after the first 5 waypoints)
Tried again after power down with zeros set for calibration grid. Came straight back with ready to cut.
Tried a jog and it pushed out belt from all 4 arms. Hit power before I got a tangle logs follow.
USB_Serial_Configuration.txt (8.2 KB)
here is the next version to try
I haven’t looked at your last logs yet (I think that is a different problem)
Tried again after power down with zeros set for calibration grid. Came straight back with ready to cut.
Tried a jog and it pushed out belt from all 4 arms. Hit power before I got a tangle logs follow.
do you have a copy of the maslow.yaml from this point?
unfortunately, ending calibration this fast is the result of the bug that is fixed in the newest test I just posted (at least hopefully, it’s the third time it claimed to find the root cause)
but several people (including me) have run into the problem of all four belts slowly spooling out on stock firmware. I have an open issue for that, but it is claiming the problem is communications with the encoders and sets up a way to alarm if the motors are moving but the encoders aren’t reporting any changes. that is addressing the symptom, but not the cause imho…
maslow (2).yaml (6.9 KB)