I think that is the right behavior because if you run it again we want it to stay in automatic mode
Here is a test version for the 1.16 release. It includes changes to the firmware, the UI and to the maslow.yaml.
Any feedback or testing is very very much appreciated.
firmware.bin (1.9 MB)
index.html.gz (129.5 KB)
maslow.yaml (6.4 KB)
are the maslow.yaml changes transparent to the user? (i.e. does the new version
create new entries if they aren’t there? or does it require a manual change to
the files and copying over the old anchor positions)
if maslow.yaml transitions are handled by the UI, they generate error 3
messages, if they are handled by the firmware, they are handled silently.
One change that will probably need to happen is to look for the old value of the
auto-update release location and change it to the new location.
David Lang
Nothing should break if the maslow.yaml file isn’t updated, but it’s worth doing the update of the .yaml file to make sure that everything that has changed in there is set to the correct value. In particular we want the grid size to default to 0mmx0mm to make everything automatic unless someone really wants to do something custom
Ok, so this is more a matter of a new set of defaults than new fields in the
file?
If someone has good anchor locations (not expecting to need to run find anchors
again) they should not need to replace their existing file?
David Lang
Loaded index and firmware files, not maslow.yaml (set to 2000x1000)
Full serial log below.
Note: Error after waypoint 82, clicked on Release Tension and Configuration continued to completion without further fault: Relevant part follows
[MSG:INFO: Measured waypoint 82]
[MSG:WARN: Encoder I2C error -102 on Bottom Left]
[MSG:WARN: Bad connection on Bottom Left encoder, failed to read 1 times in the last second]
[MSG:ERR: Emergency stop. Update function not being called enough.1002ms since last call]
[MSG:WARN: Encoder read failure on Bottom Left]
[MSG:WARN: Bad connection on Bottom Left encoder, failed to read 4 times in the last second]
[MSG:ERR: Emergency stop. Update function not being called enough.1001ms since last call]
Release Tension
[MSG:INFO: Requesting state change from Calibrating to Releasing Tension]
[MSG:INFO: Cannot release tension from state Calibrating]
[MSG:INFO: Measured waypoint 83]
Maslow-serial - 2025-12-18T091134.090.log (29.1 KB)
I note it does not include David’s updated version for tracing boundaries files, this version could send Maslow off work area if a user misinterprets the boundaries
Could this actually be a lose encoder wire? Triggering an error there seems like the right behavior
Great catch!
@dlang Do you know why that change might not be in there? This was built off of main so it should have the fix
Possibly, but i have noticed this occasionally, not always on the same encoder. Makes me think it might be a timing problem somewhere. If it is a loose wire, why isn’t it consistent, it should not have been able to continue.
That is a good point and something that we should keep an eye out on for sure.
I’d still unplug all the wires and dust them off and plug them back in too just to be safe
It could also be a bit of both. Maybe a timing change is making us less robust to connection issues
I ran the find anchors again, without powering down. As it progressed the belts got tighter and tighter, until the Maslow was rearing up. I had to power off, and then it took 3 Release Tensions before I could release the TR & BR belts. The belts were really tight.
Hmmmm this update shouldn’t have any changes to that part of the code.
Basically each time it recalculated it was getting tighter?
Did updating the .yaml file change your retraction force by any chance?
Yes, belts were getting tighter as it progressed.
I didn’t change the maslow.yaml file, it’s a pain to do with my setup. I am going to set the grid size to 0x0 & confirm that works without going too close to the edge.
I do like that the XY home position is now shown correctly and the cross hairs reflect the values saved. Much needed improvement.
Bar wrote:
@dlang Do you know why that change might not be in there? This was built off
of main so it should have the fix
No, #592 was included in #606 which was included in the big merge one.
David Lang
Still was overlapping on the Width after running Find Anchors with 0x0 configuration.
Like it was getting too close to the edge and needed to be supported?
Bar wrote:
Like it was getting too close to the edge and needed to be supported?
rather than allowing the full workpiece size, you need to add a 4-6" area for
support on all sides.
David Lang
That should be how it works now, it should be adding a 100mm padding inside the work area, but as always more testing is needed
