Too Late - it works
Too Late - it works
good to hear, this means that this version should be even better.
saving the belt position and restoring it has turned out to be FAR more complex than expected 
check this one, the prior one assumed that these were just incrimental encoders, so it could just restore the encoder count, but if there was any movement at all (belt stretch, stray magnetic field, etc) this would produce wrong results.
the new version takes advantage of the fact that these are absolute encoders and so it now saves the encoder position along with the belt length and when it restores, it checks that the encoder hasn’t moved more than a 1/4 turn (if it has, it treats the data as stale and you need to retract), if it has moved a little, it assumes that movement is legitimate and accounts for it.
so it should be much more robust.
1 Like
Works fine and it adjusted for minor discrepancy across power reset. serial log this time
Serial_Dump_Save_Restore.txt (15.3 KB)
[MSG:INFO: Validity check: ret=0 validityMarker=1]
[MSG:INFO: TL encoder moved -1 counts (0.011mm) since save, adjusting position]
[MSG:INFO: TR encoder moved -30 counts (0.322mm) since save, adjusting position]
[MSG:INFO: BL encoder moved 0 counts (0.000mm) since save, adjusting position]
[MSG:INFO: BR encoder moved -1 counts (0.011mm) since save, adjusting position]
[MSG:INFO: Belt position load: Set currentState directly to READY_TO_CUT]
[MSG:DBG: Set Calibration extended* variables to true (belts are extended)]
[M
FANTASTIC!!!
David Lang
@ian_ab could you check the calibration area patch again:
I had to do major work on it to have it work properly starting after the first 6 points and handle lots of points.
besides just trying it with your existing anchors, try setting the anchors in the maslow.yaml to something wildly off
also, please test with setting the space between grid points small so that it creates many more than the 81 points that were the prior max (it now supports up to 99x99, but that would take a long time to go through and measure
I’ll have look tomorrow
Retore after power down
It would be great if we could resume after powering down in release tension state then power up and apply tension and resume without doing the dance. I am reluctant to leave the belts stressed when not in use.
1 Like
I would suggest you have a separate job for each patch, bundling them in the same place gets confusing.
Loading the patch now
1 Like
How do I set these?
Ian Abbott wrote:
Retore after power down
It would be great if we could resume after powering down in release tension
state then power up and apply tension and resume without doing the dance. I am
reluctant to leave the belts stressed when not in use.
I agree, but the problem is that when the belts are lose, the encoder values may
change and therefor not be valid. It may be that the latest fix that allows the
encoders to move up to ~10mm is good enough???
David Lang
Freezes before even starting the calibration process, log file attached
Ian Abbott wrote:
I would suggest you have a separate job for each patch, bundling them in the same place gets confusing.
Loading the patch now
separate topic for each patch? yeah, I was thinking about that. I’ll probably do
that this week.
David Lang
1 Like
Yes topic a better word. Maslow just tensioned the belts, did not move, sat there saying Calibrate, but nothing happening.
1 Like
Worth a test
Ian Abbott wrote:
How do I set these?
There is a maslow.yaml config item calibrationPointSpacing or something like
that, defaults to 400mm
David Lang
I’ve reported the ‘in the green’ patchset problem, we may end up needing serial logs for this as well, it looks like what you sent is the UI logs, but the serial logs give a little more detail about state transitions (which could be our issue here)
can’t find anything like that
maslow (8).yaml (6.9 KB)
I’m getting confused in what’s what. can we do this in another topic