These logs do not show the automatic grid generation kicking in. please double check your maslow.yaml
in the past both mm_x and mm_y needed to be zero, now any one of mm_x, mm_y, points_x or points_y = 0 should trigger it
Initially the config grid was X width 0 & y width 0. After the last interrupted run it is set x width 100, y width 100. Previously when X and Y were set, it immediately came back with configuration OK and didn’t proceed any further. Will test again with settings as is. then 0 one and go again.
Ian Abbott wrote:
Initially the config grid was X width 0 & y width 0. After the last
interrupted run it is set x width 100, y width 100. Previously when X and Y
were set, it immediately came back with configuration OK and didn¢t proceed
any further. Will test again with settings as is. then 0 one and go again.
Thanks, one huge frustration with working with the AI is that it occasionally
reverts unrelated code (I’ve seen it revert the entire PR). I try to watch for
it, but don’t always catch it. ESPECIALLY when I have to start a new issue
because copilot gets into a state on a PR that it can’t do even trivial
things in an hour. I am now on the 5th issue/pr for this effort 
It has been instructed to not change the maslow.yaml file if it’s doing
automatic calibration. I suspect that it’s still going to change the x/y points
values, but I’m holding off on cleaning that up until we get it working.
I did see small movements at one point in my testing yesterday, so it still may
be an issue, but I need logs to show it
David LAng
I restarted the config without resetting the x & y values. It did the basic set 1st 6 then went to waypoint 6 and steadily unwound the belts, slowly. at 1st I didn’t realize anything was happening except the belts went slack. I killed power and set the X value to 1100 and the Y value to zero via the menu. Powered down again then looked up settings. The X value was now 100. About to start another attempt.
Weird stuff again, this time extremely short movements in the X direction “normal” movements in the Y direction until it finished waypoint 54, then it headed for the cliff at the righthand end. I hit the power again. with the X set to 1100, and 100 I expected the short steps (if any) would be in the Y direction. Not what happened.
Maslow-serial - 2025-10-09T075749.039.log (18.3 KB)
ConfigRunSerial - 2025-10-09T0757.txt (12.1 KB)
Ian Abbott wrote:
I restarted the config without resetting the x & y values. It did the basic
set 1st 6 then went to waypoint 6 and steadily unwound the belts, slowly. at
1st I didn¢t realize anything was happening except the belts went slack.
This is exactly the behavior that I experience once and why I started the thread
do you have serial logs from this by any chance?
David Lang
No I didn’t save that one, but it was normal, no action reported. It was the same as the last 2 logs I have sent you, except the last entry was
Measured waypoint 6]
which is where I powered down.
The only thing I did differently was I had changed the Maslow.yaml settings via the menu just prior to running the config, and had not then power reset the Maslow.
Weird stuff again, this time extremely short movements in the X direction “normal” movements in the Y direction until it finished waypoint 54,
Ok, I think I we have two separate problems.
- the return to home isn’t happening correctly. I think it’s storing that in the waypoint array but we just fixed the sizing of that array so that it just contains the waypoints. If it is trying to use the next point to move to, that would be the problem.
- the problem with short X moves. I’ll have it log the array of desired locations to identify if that’s the problem
I’m more worried that it doesn’t respect the maximum sizes you have set for the width and height. If it goes “over the edge”, I suspect it would break belts and smash the Maslow, and possibly the router as well.
darn, I was hoping that the logs via USB would have a bit more data to show what’s happening.
I have a PR pending that will log Z axis moves and log a warning if the motors are running but the encoders aren’t detecting movement. we may need to see that in action to catch this.
I think that what’s happening is that it’s finishing the grid and some other
instruction is telling it to go the wrong place, and that invalid instruction is
using garbage data
David Lang
Last couple of lines suggest it is going on with the calibration
[MSG:INFO: Requesting state change from Calibrating to Calibrating]
[MSG:INFO: Cannot start calibration until the belts have been extended]
Can we get a debug message which tells us when and what it is writing to maslow.yaml. not time, but sequence in log file.
I expect this to still have issues, but it should log to tell us what’s going on.
after point 5 before point 6 (at the point where it figured out the grid size), it should dump all the points it’s intending to move to
after the last waypoint, it should dump the belt lengths from all the waypoints (similar to what it sends to the browser for each round of fitness calculations)
If it goes off to nowhere before it logs those belt lengths, that will be very important information.
Ian Abbott wrote:
Can we get a debug message which tells us when and what it is writing to maslow.yaml. not time, but sequence in log file.
I will do so, but I’m also chasing another issue that I’m seeing.
If I reboot my machine, it looks like it’s switching between two maslow.yaml
files.
there are two partitions that it puts the firmware on, it’s almost as if the
maslow.yaml is only being saved on one and each boot switches which one it’s
using.
David Lang
which log file is that in?
in the last one I see (unless I missed something) it says
[MSG:INFO: Measured waypoint 54]
[MSG:INFO: Requesting state change from Calibrating to Calibration Computing]
[MSG:INFO: Succeeded]
[MSG:INFO: Current stat$/Maslow_tlX=-160.600
$/Maslow_tlY=4017.900
$/Maslow_trX=4537.200
$/Maslow_trY=3966.500
$/Maslow_brX=4562.100
CLBM:[{bl:3016.75, br:3099.51, tr:3008.20, tl:3101.53},{bl:3127.77, br:2993.79, tr.55, tl:3212.64},{bl:3227]
[MSG:INFO: Requesting state change from Calibration Computing to Calibrating]
[MSG:INFO: Calibration starting in HORIZONTAL orientation mode]
[MSG:INFO: Setting z-stop p
[MSG:INFO: Center coordinates updated in MaslowKinematics: X=2249.247 Y=1967.038]
G:INFO: Setting motor positions from hardware readings:]INFO: TL: 2500.402 TR: 1560.651 BL: 2273.355 BR: 1486.625]
[MSG:INFO: Succeeded]
[MSG:INFO: Current state: 6]
MINFO: { "homed": true,"calibrationInProgress": true,"tl": 2504267,"tr": 1557.570,"br": 1484.414,"bl": 2276.200,"etl": }
Serial port disconnected - waiting for reconnect
Type Ctrl-] to quit
I do not expect the CLBM line (unless that’s the dump I just asked for, badly truncated)
but going from the calibration computing to calibrating is normal.It should then detect that the waypoint (55) is no longer < number of waypoints and exit to ready-to-cut (but that’s the point the connection is lost)
David Lang
just tried to run config again after setting x to 2000 and y to 1000, get the following from serial port:
[MSG:INFO: All belts extended to 2000.000mm]
[MSG:INFO: Requesting state change from Extending Belts to Belts Extended]
[MSG:INFO: Succeeded]
[MSG:INFO: Current state: 4]
[MSG:INFO: Requesting state change from Belts Extended to Calibrn mode]
[MSG:INFO: Calibration grid generated with 55 waypoints:]
[MSG:INFO: Grid size: 7x7]
[MSG:INFO: X spacing: 333.333 mm, Y spacing: 166.667 mm]
[[MSG:INFO: Waypoint 1: X=1.605 mm, Y=0.000 mm]
[MSG:INFO: Waypoint 2: X=1.605 mm, Y=0.000 mm]
[MSG:INFO: Waypoint 3: X=2.016 mm, Y=0.000 mm]
[MSG:INFO: Waypoint 4: X=0.000 mm, Y=1.598 mm]
[MSG:INFO: Waypoint 5: X=0.000 mm, Y=1.605 mm]
[MSG:INFO: Waypoint 6: X=0.000 mm, Y=0.000 mm]
[MSG:INFO: Waypoint 7: X=0.000 mm, Y=-166.667 mm]
[MSG:INFO: Waypoint 8: X=-333.333 mm, Y=-166.667 mm]
[MSG:INFO: Waypoint 9: X=-333.333 mm, Y=0.000 mm]
Maslow is doing nothing, belts are loose, not even the blue LED is flashing, just a steady blue. Any ideas?
Tried refresh of browser Nothing Powering off
very much not what it is supposed to be doing
David Lang
here is one that is supposed to fix logging and restore the behavior of the
first 6 points at least.
I’m going to drive to the hackerspace, it will take me about 40 min, and then
I’ll have about 90 min before they close to try things myself.
I’m geting close to starting a new issue from scratch rather than continuing to
try and fix this one (so many problems so far, but I thoguht we were really
close before this one…)
David Lang
well, that was a disaster. I told it to back up a few versions and add logging, so we’ll see what happens
This one did the first 6 waypoints and then started quietly winding out belts I killed it.
ConfigRunSerial - 2025-10-09T14.53.txt (6.4 KB)