Hey Nick,
that is not true. The buildbotics-derived Onefinity Controller implements a full RS-274 and even more, a LinuxCNC G-code implementation. What you probably mean, is that it lacks some comfortable pages on its user interface for a number of functions.
That it looses its values on e-stop is something that I can’t understand. Why? This is the most strange thing. But I have discovered that every offset is in fact still there, in the log file. With a bit of programming, you could get your values back immediately, and also the values of the last years, because it uses logfile rotation and the logfiles are never deleted. So what I believe (and what I wrote in some postings) is I think the Buildbotics.com CNC controller and its fork, the Onefinity Controller, would need some further developing. As it is a free and open source object, it is waiting for the community to contribute too.
That’s why I would never put a Onefinity into operation and service in the state it was delivered. Specifically the lack of shielding of all cables and the lack of a serious cabling solution (both on Original X-35/X-70 and Elite Series), in combination with the lack of strain relief on moving cables and the connectors that are only made for internal use and are wrongly used on the outside of an electronics device (inherited from upstream Buildbotics.com) is what I would consider as a danger for my workpieces and my bits and my nerves.
I never used ugs. Are there any specific features that you had there that you would mention here, that the buildbotics-derived Onefinity Controller lacks?
It does not clear any of the offsets when you home the machine. EDIT: This is wrong, it looses the offsets /EDIT. What it looses, is the accurate position of the home itself because of unreliable Stall Homing, that is true. Therefore I recommend to either never click on any of the “home” buttons except once after startup of the machine, but instead enter G53 G0 X0 Y0 Z0 into the command entry field of the MDI interface, which will simply drive to the machine origin, but without the bumping to re-establish home that stall homing does, or to Retrofit Hardware Limit Sensors, which can easily be attached to the buildbotics-derived Onefinity controller, as shown in many posts in this forum (search for ‘inductive proximity’), as the buildbotics controller is able to use them if you connect them to the 25-pin I/O port, to get rid of unreliable stall homing. Then you have excellent homing repeatablity.
For the case that you are forced to re-home, because the machine suddenly stopped and lost its values or after a power outage, there is a method with the Touch probe and a clamped block permanently on machine bed, somewhere away from the workpiece, instead of homing that ensures accurate position repeatability. I hope if you have such frequent errors due to EMI, that you use this method in order not to loose your workpiece every time.