Amen I agree with you I love that onefinity get there are more than a few things that can be improved on that’s one of them.
Since Onefinity uses open loop stepper motors that can move while the machine is off, the big challenge after power off or power loss will be having a reliable zero point to start from that you can then apply your stored offset. This will be influenced by the required level of precision, stall homing in my testing was +/- 0.005" which may be good enough. I’ve moved to homing switches which are in the +/- 0.0002" realm (realistically there seems to be less error but my most accurate dial indicator is limited to 0.0002")
I also use fixtures for many operations where the corner of the fixture is my zero point, after power loss or when making another one of a part I use that as my work offset in CAM and on the Onefinity
I have a small white board stuck to the side of my touch screen the white board is permanently marked with X,Y,Z, Job thickness Z Datum & Cutter
At the start of a job or tool path I use a dry maker pen to fill in the blanks
X offset, Y offset, Z offset, Job Thickness in mm, Z Datum meaning is Z zero on the spoil board or the top of the material, Cutter diameter up or down or compression.
Its simple but it works, I was taught it in the 80’s during my engineering apprenticeship we used it on pretty much all manual machines and 100% on CNC’s which were a whole lot different back then
I have been asking for this since the onefinity came out.
What if the corner of the stock where its zeroed no longer exists because it had been cut away.
I would love to actually save the last gcode location so you could just pick up where you lost power.
Some jobs take a VERY long time and restarting them without being able to zero them is impossible.
I understand there may be work arounds but Im a programmer and these things are not all that hard to incorporate.
Yes it is easy, you must, once you have set your zeros, make a note or take a picture of your offsets. Then if you want to get back to the set position after you have shut down your machine follow these steps;
1 restart and home your machine.
2 open the MDI tab
3 type, g01x… y… The dots are your offsets that you made a note of.
4 press enter.
You should now be within 0.0002 of your last settings.
Hope this helps
I have a connected PC and use a web browser for controller screen. Hence, I have a text file where I store G code commands to enter as MDI code. Just copy and paste for start points. Example:
Lower Left Corner
G01 x7.014 y9.866
G02 X0 Y0
Copy G01 line and paste in the MDI window, click the run arrow.
Copy the G02 line and paste, click the run arrow. This sets the offsets. Alternate click the X set and Y set buttons (not the home buttons). Still have to set Z.
As far a I know you can only run one G code line at a time.
I have several “Starting Locations” for different setups stored in the text file.
Still have to home the machine once when the machine is first turned on.
Brilliant! Thanks for posting this, I used this today on an epoxy inlay project in progress. I leave the piece mounted, but can now turn off my OF and get back to my XY origin between pours.
How is this simple instruction NOT in a 1F beginners guide? There are so many job situations where returning to the same position would be required. Many are asking in vague ways about it, and many are giving bad answers that only confuse the issue.
+1 for G28. I’d like to set “home” to the corner of my waste board rather than true home.
I’m having a devil of a time tiling. I noticed when cutting 96mm dog holes (these are my reference points) in my spoilboard that the 1F likes being just a tad off from session to session, and so would love to know your homing switch solution with your 1F.
I had 3D printed mounts for NC proximity sensors on both Y axis rails and the Z axis rail and the Z axis and used sensors similar to this one (the specific ones I ordered no longer appear to be listed):
The main challenge was the sensors needed 12v or more to operate correctly and the Onefinity controller works with 3.3v logic levels so I used optocouplers between the 2. I have since moved to a Masso controller which works natively at 12v (or more) and has integrated optocouplers for isolation which simplified the setup. I’ll see if I can dig up some pics of the mounts but I don’t think I have anything saved on the 1F controller configuration.
The proximity sensor setup was well worth the time and effort to implement, I am able to power off the machine, power on, re home and pick up where I left off on a project.
Moved to a Masso controller? NC proximity sensor and mounts? Unless/until the upgrade path is available from 1F, I am extremely interested in any solution to the lack of session repeatability from my 1F J-man.
If I weren’t already bald, I’d be pulling my hair out in frustration with the open-loop stepper motors and stall homing on my 1F.
If you would expand on your solution, I would be grateful.
1F non-Masso controllers use Buildbotics, which is based on LinuxCNC.
I cannot find G02 documentation anywhere on that website, and don’t know if the interpreter would equate that with G2 (which has completely different functionality).
I’m wondering if I can manipulate my J-man’s workable area via G28.1. To be more specific, I’m contemplating a doghole-with-metal-dog-combination centered at (96, 96) to tell my machine where its workable area is via the G28.1 MDI command.
Buildbotics is not based on LinuxCNC, as Buildbotics is the own work of its creator, but its g-code syntax is patterned after the LinuxCNC g-code syntax
G2 (Clockwise Arc Move) is identical to G02, just as M3 is identical to M03.
The numbered parameters #5161 – #5169 store the machine coordinates of the home position for the axes X, Y, Z, A, B, C, U, V & W, therefore after homing, G28 moves to machine origin (aka ‘home’)
G28.1 sets these parameters to the values of the current position, but the position is in absolute machine coordinates.
You can check the values at any time with the g-code command:
M0 (debug, G28 settings: X=#5161, Y=#5162, Z=#5163)
I don’t know if you rather are interested in the G52 and G92 commands. After probing your workpiece in XYZ, the G92 command sets the new workpiece zero as the X,Y,Z zero position of the workpiece coordinate system. Any subsequent G0, G1, G2 and G3 motion commands will then take the workpiece zero as coordinate system zero. E.g.
G0 X0 Y0 Z0 will then move to the workpiece zero. You can still move to machine zero (‘home’) with
G53 G0 X0 Y0 Z0 when a workpiece coordinate system is in effect.
The G52 command is useful if you have multiple identical pieces to be milled at different positions.
Tomatoe/tomato. The distinction might be pedantically pure, but it doesn’t do much to add to the conversation.
As I suspected. So
makes no sense to me.
This is the confirmation I was seeking. It seems to me that getting the gantries really close to snug (rather than letting the 1F BB do its stall thing) is much more likely to result in a larger machine working area, and should be a more reliable machine zero to boot.
I don’t think you can say Buildbotics “is based on” LinuxCNC. You can say the Onefinity Controller is based on the Buildbotics Controller, because the Onefinity Controller is a software and a hardware fork of the Buildbotics Controller (bbctrl-firmware, bbctrl-pcb → onefinity-firmware, onefinity-pcb).
But the Buildbotics Controller is a new CNC Controller written from scratch and not based on LinuxCNC. It would be rather correct to say, the Buildbotics Controller is based on the knowledge that its author → acquired when he was writing the Camotics 3D Simulation Software (Ref.: History of the Buildbotics Controller).
So you could only say Buildbotics is based on LinuxCNC the same way you would say that LinuxCNC is based on the FANUC CNC Mill Controller. In software, usually if you say “based on”, you mean that you somehow took the software and recycle some of the code. But the softwares mentioned here are not based on the other, the developers just tried to pattern their g-code dialect after the other.
Probably a typo by the original poster.
Debian is a form of Linux, but not all Linux is Debian.
Buildbotics is a form of LinuxCNC, but not all LinuxCNC is Buildbotics.
But what did we just accomplish?
Yes, “G02” is a typo.
G92 X0 Y0 is the correct version
I think I got the G92 code from
Debian is not a form of linux, but an operating system that, among other kernels, can use the Linux.org kernel as kernel. The Hurd kernel is another kernel that Debian uses.
As explained above, Buildbotics is not a form of LinuxCNC, just as LinuxCNC is not a form of FANUC CNC mill controller.
At the moment, it seems I did not accomplish explaining well enough