This for sure looks like there is something off in the calibration results. Basically it’s not getting a good reading on on the anchor point locations.
We came up with a series of tests to try to figure out what is going on here basically by running calibration over and over in different configurations and Anna is working through them now, but it will take a bit of time to gather the data and see if it tells us something helpful.
No edits. Again, I recommend adding the printout of all the configuration settings in the serial log at startup, or upon save action, or something like that for interacting with Support.
I finally got my M4 mounted on my garage floor and attempted to calibrate last night. I haven’t gotten it to properly calibrate yet. Initially, I realized I mixed up the width and height frame dimensions. At first, I kept getting errors that the frame dimensions were off by greater than 100.
Suggestion: Perhaps in the config menu, instead of “Machine Width” and “Machine Height” it would be better to put something like “Frame X” and “Frame Y”. Alternatively, would it be possible to have the user enter the dimensions without a reference to width, height, x, y, or whatever one wants to call them and have calibration infer which dimension is which? Ultimately though, this isn’t a big problem and is easy enough to figure out as is.
After switching the width and height, I tried to calibrate again. I believe I received the frame dimensions error again, so I re-measured my anchor points and put in values closer to true. I ran calibration again, but fitness scores were too off. (What range should fitness scores be in, anyways?) I had it directly on my garage floor and I think was getting a bit too much resistance. I don’t have a full plywood sheet right now for spoil, so I just had it on the floor at first. I grabbed the biggest plywood sheet I do have and set the calibration grid to the dimensions of the spoilboard. Re-ran calibration and it ended up tipping off the edge a bit. I think it was trying to calibrate to the edge of the spoilboard, and I need to set the calibration grid dimensions lower than the actual spoil dimensions so that the grid stays on the board.
Suggestion: (assuming the calibration grid must be smaller than the spoil board) Config could just ask for the spoilboard dimensions instead of the grid dimensions then have the program make a smaller calibration grid based on the spoilboard dimensions.
I ran out of time to run calibration again, but I think after adjusting the calibration grid dimensions down that I should be able to get it properly calibrated tonight.
I’m working on an updated calibration process which should automate most of that. All the information that the calibration process asks for is easy in hindsight, but it can for sure be confusing the first time you see it. If we can eliminate the need to ask for the user to enter any information that will solve a lot of issues I think.
And really it is the relative positions of the anchors points that define everything.
As Anna has been working on all the tests, have you guys been reproducing my abysmal post-calibration jog results? Or no matter the various frame & work areas, your test machines are jogging well and not de-spooling.
I’m trying to get a sense if this is possibly a faulty unit/assembly or something that we think can be fixed in software?
Yes… there is a book “Don’t make me think” which is all about simplified UX/UI design
We haven’t seen that issue at all 
There are generally one of two things which can lead to that.
The magnet not being aligned with the encoder. Pressing test will check to see if the magnet is detected in the correct place.
The magnet is slipping in the roller (it needs more glue). To test for that press Retract All → Extend All → Retract All. After extending the belts fully and then retracting them check to see that all of the offsets that print out are close to zero. If one magnet is slipping that will tell you.
OK, I’m updated on maslow.yaml, index.html.gz and firmware.bin as of this posting. v0.84 but the version numbers have been are a little confusing to me. honestly.
Anyway, I didn’t attempt jog yet, but everything else seems to be unchanged so far. I DO newly notice a symptom though: Top Right is easily refusing to retract all the way, though it does not seem to be jammed or blocked.
after a retract, we see it doesn’t even THINK it’s done:
[MSG:INFO: Top Left pulled tight with offset 0.000]
[MSG:INFO: Bottom Left pulled tight with offset 0.000]
[MSG:INFO: Top Right pulled tight with offset 94.080]
[MSG:INFO: Bottom Right pulled tight with offset 0.032]
Then an immediate next click to retract (no fiddling):
[MSG:INFO: Retracting all belts]
[MSG:INFO: Top Right pulled tight with offset -5.293]
[MSG:INFO: Bottom Left pulled tight with offset 0.000]
[MSG:INFO: Top Left pulled tight with offset 0.000]
[MSG:INFO: Bottom Right pulled tight with offset 0.000]
and after that no amount of clicking gets it to move any more.
The belt is left hanging out an inch or so, and the belt CAN be pushed in through the rollers freely.
When I do this, the intensity of the amber light on the ethernet jack increases and off - seems like an intentional visual indicator of the percentage of the way through an inch of belt. Is that correct?
After a soft reboot of FluidNC (that’s enough, right?) No fiddling. The spool doesn’t seem blocked and the belt is still drooped out an inch:
[MSG:INFO: HTTP started on port 80]
[MSG:INFO: Telnet started on port 23]
[MSG:INFO: Retracting all belts]
[MSG:INFO: Bottom Right pulled tight with offset -0.032]
[MSG:INFO: Bottom Left pulled tight with offset -0.064]
[MSG:INFO: Top Left pulled tight with offset 0.000]
[MSG:INFO: Top Right pulled tight with offset -0.011]
So I extend all and retract all twice immediately (no intermediate fiddling):
[MSG:INFO: Extending all belts]
[MSG:INFO: Retracting all belts]
[MSG:INFO: Bottom Left pulled tight with offset -0.011]
[MSG:INFO: Bottom Right pulled tight with offset 0.000]
[MSG:INFO: Top Left pulled tight with offset 0.000]
[MSG:INFO: Top Right pulled tight with offset 763.722] << Seems about right! Belt is totally loose, no blockage.
[MSG:INFO: Retracting all belts]
[MSG:INFO: Bottom Left pulled tight with offset 0.000]
[MSG:INFO: Top Right pulled tight with offset -3.811]
[MSG:INFO: Bottom Right pulled tight with offset 0.000]
[MSG:INFO: Top Left pulled tight with offset 0.000]
Jason wrote:
OK, I’m updated on maslow.yaml, index.html.gz and firmware.bin as of this posting. v0.84 but the version numbers have been are a little confusing to me. honestly.
Anyway, I didn’t attempt jog yet, but everything else seems to be unchanged so far. I DO newly notice a symptom though: Top Right is easily refusing to retract all the way, though it does not seem to be jammed or blocked.
after a retract, we see it doesn’t even THINK it’s done:
[MSG:INFO: Top Left pulled tight with offset 0.000]
[MSG:INFO: Bottom Left pulled tight with offset 0.000]
[MSG:INFO: Top Right pulled tight with offset 94.080]
[MSG:INFO: Bottom Right pulled tight with offset 0.032]Then an immediate next click to retract (no fiddling):
[MSG:INFO: Retracting all belts]
[MSG:INFO: Top Right pulled tight with offset -5.293]
[MSG:INFO: Bottom Left pulled tight with offset 0.000]
[MSG:INFO: Top Left pulled tight with offset 0.000]
[MSG:INFO: Bottom Right pulled tight with offset 0.000]and after that no amount of clicking gets it to move any more.
This is a problem. When you retract, it pulls until it’s applying enough force
(the retraction limit) and then it reports where it thinks it got to. the fact
that it’s not near zero is a problem (the 0.032 on the bottom right of the first
one is acceptable)
try increasing the retraction (and calibration) limits
The belt is left hanging out an inch or so, and the belt CAN be pushed in through the rollers freely.
When I do this, the intensity of the amber light on the ethernet jack increases and off - seems like an intentional visual indicator of the percentage of the way through an inch of belt. Is that correct?
an indicator of belt movement, based on the rotation of the magnet.
After a soft reboot of FluidNC (that’s enough, right?) No fiddling. The spool doesn’t seem blocked and the belt is still drooped out an inch:
[MSG:INFO: HTTP started on port 80]
[MSG:INFO: Telnet started on port 23]
[MSG:INFO: Retracting all belts]
[MSG:INFO: Bottom Right pulled tight with offset -0.032]
[MSG:INFO: Bottom Left pulled tight with offset -0.064]
[MSG:INFO: Top Left pulled tight with offset 0.000]
[MSG:INFO: Top Right pulled tight with offset -0.011]So I extend all and retract all twice immediately (no intermediate fiddling):
[MSG:INFO: Extending all belts]
[MSG:INFO: Retracting all belts]
[MSG:INFO: Bottom Left pulled tight with offset -0.011]
[MSG:INFO: Bottom Right pulled tight with offset 0.000]
[MSG:INFO: Top Left pulled tight with offset 0.000]
[MSG:INFO: Top Right pulled tight with offset 763.722] << Seems about right! Belt is totally loose, no blockage.
[MSG:INFO: Retracting all belts]
[MSG:INFO: Bottom Left pulled tight with offset 0.000]
[MSG:INFO: Top Right pulled tight with offset -3.811]
[MSG:INFO: Bottom Right pulled tight with offset 0.000]
[MSG:INFO: Top Left pulled tight with offset 0.000]
the top right arm seems to have a problem. it could be the idler and motor are
too close together, the screws holding the two halves together are too tight,
the magnet is not in the right place, the magnet is not glued solidly enough, or
something else.
David Lang