Rho offset check

One more photo...

What your photo shows is a very small offset. This offset is usually due to small variation in the Rho home sensor (which senses a small magnet as it passes above the sensor). We are working on a software solution to finesse this. The other possibility is that the arm holding the main magnet (moving the ball) is not exactly centered. It is affixed by two small screws, which can be loosened to allow adjustment of the arm and re-tightened. 

Thank you. To check the arm screws, would I need to empty the table of sand and/or flip it over on its face? It’s not a big deal. I imagine it just makes some designs a tiny bit off?

I haven't done it, but I think you'd leave the sand alone and drop the bot down by taking out screws where the rubber mounts are.

I imagine it just makes some designs a tiny bit off?

Correct. And from your pic, emphasis on "tiny". The main "off-ness" will be a tiny mound of sand in the center. The tracks themselves, whether algorithmic or representational, will not be altered appreciably. However, if you ever do want to adjust the mag-arm, here are the directions of getting at it:

https://sisyphus-industries.zendesk.com/hc/en-us/articles/360004786291-Sisbot-Replacement

Bruce, somewhat related, but for the first time ever my table started leaving a little mound of sand in the middle. A reset fixed it. So it seems like either accumulated error or a one-time set of missed steps (we do have cats, although they don't usually admire the underside). So you might consider still doing a sensor-based recalibration every now and then.

Thank you. I think because this issue is so minor I will leave it well enough alone. Too many foolish weekends have been spent in my life trying to tweak the last 2% of some project. ???? 

It is possible for position errors to accumulate with stepper systems (our metal table versions), though I've only seen this when running at higher speeds. Sensored homing will correct any errors - but this now only happens at bootup. We changed from sensored homing for all homing, because it requires each axis to home slowly, and Theta first, then Rho - and instead use "dead reckoning" for all homing after the bootup sensored homing, because it is far more efficient (quicker). If you do see a central mound increasing over time, power cycling the table will force a sensored home, and should fix it. A full reset is unnecessary. We plan to add a "Do sensored home" function to our GUI in the future.