OK. If I’m following along properly, that means I should have been able to do “$H” in the Console and see the Machine Position reset to 0,0? I just tried it and got this output but the Machine Position readout didn’t change.
$H
B08
Left: 2076.00mm
Right: 2076.00mm
position loaded at:
-1.11
0.10
Message: The machine chains have been manually re-calibrated.
ok
>Ahh. I found out what’s going on. If you use the Define Home / Set Chains after you’ve calibrated once, the process will not work correctly. The leftChainTolerance and rightChainTolerance (in settings) need to both be zero when you run this step. You could simply set these values to zero and restart calibration at this step. However, I have a way to fix this (so you can run it again safely) in the next version.
The changes described above are in build #208, such as:
OK, I’m running #208 and have chain tolerances set to 0. When I do “Set Chains” in Calibrate, the X reset to 0 but Y is set to -0.01. While close to zero, it still seems like something isn’t quite right.
That’s fine. It’s normal for there to be some small errors in position computation. This is because the Maslow is continuously re-computing its position, and realistically the accuracy of the chains is not that high.
TBH, I think I should round the numbers for the Maslow a bit. Three digits (0.000) of precision is too much. It would be appropriate for a 3DP perhaps, but is not within the Maslow’s tolerance. Note, for example, that Web Control always uses whole numbers, IIRC.
I made progress tonight. With the latest software (108) I was able to calibrate within tolerances. I still don’t have it dialed in tight, a 50mm rectangle is coming out about 47.5mm, but it is close.
At this point, a lot of my feedback would probably come in the “accessories” - for example, my setup has an Amazon Fire as my shop tablet. I’d love to run the shop tablet widget, but I don’t know how to install it in the current Docker based deployment. The current UI doesn’t handle the smaller form factor well at all. And I have a Z-axis probe setup, but the Probe widget’s Probe button is disabled always and I don’t know why.
Also, one small issue with the Precision Calibration… If the z-axis is at 0 (i.e, touching) when the Precision Calibration starts, it doesn’t retract the z-axis for travel and instead drags it across the surface to the first cut point. Beyond that, it does retract before moving on to the next cut.
So glad to hear it. I know it’s been a lot of back-and-forth 
Great point. I had a brainstorm previously for a way to make it easy to find & install widgets. I’d like to do that, but one step at a time 
Very true. I have been able to use the “Shopfloor Tablet” widget, but it would be hard to install for others right now. As soon as I can get to making widget installation easy, it should only take a day or so to polish this widget so that it looks nice on various tablets and small screens. Maybe even a mobile specific version, as well 
Ah, nice catch. Funny how I always notice stuff like that when I use others’ software, but still manage to make the same bugs myself. Anyways, I have a fix for the next release.
A couple of things from my night’s calibrations. I’ve updated to 205.
I am still running into the issues of the frame height changing to 16 mm. I don’t see a pattern… other than it is consistent ~75% of the time in any calibration run.
I am also noticing that return to center is 6 mm above the defined home - 100% of the time.
Hope this helps.
I too have found that returning to Center is missing the mark rather consistently. I chalked it up until now to messed up calibration. I’ll watch for it going forward, now that I think I’ve got a rough calibration, to see if I see a similar pattern.
Any idea why the Z probe button always stays disabled?
208 was released a few hours before you wrote that and was meant to address several issues around this 
I’m having a hard time understanding this. If the 6 calibration positions (which make a box around the center) are all accurate, there should be no mathematical possibility that the center would be wrong. Are you 100% certain that the calibration is not off by the same amount?
I saw the same thing. The center I marked was not the center after calibrating. I took it to mean that my center was wrong and after calibration that spot was the new center. Each successive iterative calibration went from each new center. Is that “the way?”
I don’t have one and therefore haven’t tested it yet. But I looked at the Makerverse widget code and it’s just a switch to enable it for the Maslow. This is no guarantee that it will work yet, but here’s what I see (will be included in next release):
Issue: rebooted rpi, restarted MV and it does not load completely:
Hm, I’d try updating bin/launch. If you’re running an older image, I believe this will correct some of the permissions as well:
sudo chown -R pi:pi ~/makerverse
cd ~/makerverse/bin
rm -rf launch
wget https://raw.githubusercontent.com/makermadecnc/makerverse/master/bin/launch
chmod +x launch
… and then restart.
Hmmm, your Probe widget UI looks completely different than mine…
I was showing a screenshot of what happened once I pressed the (newly enabled) probe button.
It seems to be telling us exactly what gcode it will run for the probe. Because I don’t have probes on any of my machines yet, I haven’t actually taught myself the related gcode yet. However, I do plan to do so as soon as I get the time to build my probe.
I think this might go back to my original question. When the 0,0 is define, it computes a chain length based upon the current calibration values at the time you define zero. If the calibration values change, the kinematics formulas won’t calculate the same chain lengths for 0,0 and therefore, the sled will be offset from the previous 0,0. The worse the calibration was when you defined zero initially, the bigger the shift will be. I thought that’s why the iterative approach was necessary (i.e., calibrate, jog to 0,0, define home and then repeat calibrating/jog/define home process until a move to 0,0 actually gets to 0,0).