A much better solution would be to screw a separate block that you can zero off of onto the spoilboard. A block that doesn’t get machined. When you create your g-code it’s offset from your work position would be included. The other option is to just not shut off the controller.
Zero is based off of home. With stall homing is very close I don’t think it’s exactness is repeatable enough. You could try something like the “stock to leave” option in 360 so when you stop for the night there’s enough material left so if the new zero is a little bit off there’s enough material left.
As Alex already mentioned, you could use a block of wood that is permanently fixed somewhere on your workarea, but away from your work, where you can put the probe on, or you could also use a jig for the same purpose, like shown here.
1 Like
Aiph5u
(Aiph5u (not affiliated with Onefinity))
24
Hey GregZo,
The Elite/Masso G3 Series don’t rely on stall homing, but have limit sensors (infrared in this case), and if you have limit sensors, you get a good positioning repeatability (when rehoming), even after powerdown.
However limit sensors are supported by the buildbotics-derived Onefinity controller of the Standard Series as well, you can retrofit inductive proximity sensors to the Onefinity Standard Series, people have already done that (usually with 3D-printed parts to hold the sensors) and it works absolutely reliably then.
The reason why the zeroed values are not made available on the Buildbotics/Onefinity Controller after an estop or a reboot, does not seem clear to me, as all zeroing values are recorded in the bbctrl log file and can be found there after a reboot. And as the bbctrl logfile is subject to logfile rotation, all these values remain there for a very long time. As for now, they are not directly made available to the user.
