OpenBuilds CONTROL Software

yeah, CAM is available at all levels, but some CAM is not available.
free/student does not do 4th axis
free does not output rapid moves (maybe student too), which means all moves are limited to 'cutting speed' which can make some types of cuts take a very long time.

 

That means you haven't Tuned your Max Rate correctly otherwise it would never be a worry: Grbl v1.1 Configuration

Our free and beginner orientated CAM is super simple and doesn't bother with Arcs. If you need proper Arcs, use a more advanced CAM

 

Better yes, easier to implement - no. For the price, some compromises needed to be taken

 

Easier - for the development of the software yes. Its free software, so the easier option is "better". It works just FINE! But if you need proper Arcs, just use Fusion

 

you set up the machines GRBL settings maxrate numbers to rates that the machine can safely handle.
After that Gcodes G0 moves are at that maxrate, no surprises.

if you have Fusion360, you have more CAD and CAM than you will ever use, no need for anything else

I built on other peoples work, but have added a lot of functionality to the Openbuilds post, yes.

 

neither.

machine home is set when the controller turns on (can be useful, see later) and then again when the home cycle is run (best) and it finds the limit switches at the ends of axis travel, usually + ends for X and Y and absolutely must be + end of Z (up as far as it will go without crashing)

G28 and G30 are offsets from machine home. They default to 0 offset, and can be set by
1 - jog to a place, Z high (I use G28 as a toolchange position)
2 - issue G28.1 to store 'here' as an offset from machine home.
same for G30

Now, issuing a G28 will move to that offset, but if the machine is not homed first you dont really know exactly where that offset will be. So always home the machine after turn on.

Homing tells the machine to move Z toward the switch (feedrate in setting $25, when it hits it retracts a little then moves to contact it again, but slower (setting $24).
Once it hits the switch the second time it sets machien Z to 0, then retracts by the pulloff distance (settign $27)
Then it moves X and Y toward the switches, hits, retracts, hit again slowly, sets X0 and Y0 and retracts by the pulloff distance.
Now the machine knows where machine home is, and all stored offsets, which are relative to machine home, are now useful.

Now to do some work we need to tell the machine where the raw material is, since the Gcode is relative to the Work Coordinate System that we set in the CAM.
This is often the front left corner (XY) at the top of the stock (Z), sometimes in the center of the material at the top of the stock. some people like to use the table as Z zero (don't!).
For machines with a vice, the fixed jaw should be used as the Y reference.

Now you jog to the spot on the stock that you set in CAM as the 0,0,0 point and use the 'setZero' buttons to tell it 'stock zero is here'.
The 'paper method' is most often used for this, where you feel for the tool contacting a piece of paper you hold against the stock as you gently jog up to the paper.
This can also be done using a probe cycle , where the machine finds the stock using a probe like the XYZ Probe from OpenBuilds (watch the video)

These Work Coordinates (WCS) are also offsets from machine home and they are stored in the controller (and still exist after a power cycle).
There are 6 WCS in GRBL, G54 through G59, but most of us use only G54, the default.

Later: if your machine does not have home switches, you should get some Xtension Limit Switch Kit
However, there is a way to opererate with a stable machine home while you wait for them to arrive.
This is the 'fake the home' method, where you use that GRBL feature of setting machine 0,0,0 at power on to your advantage.
If the machine is AT the physical home position when the controller turns on or is reset, then you have a sensible home you can use.
much has been written, please read it

 

It is the machine controller that is responsible for movement - Openbuilds Control is just the messenger (same for UGS, etc.).

G90 / G91 are modal commands, so the machine controller will be in the state it was last set to. (This is persistent through power cycles, etc.) It is dangerous to assume that it will be in any particular state, so this sort of thing should be set explicitly at the start of your Gcode file that Control sends to the machine controller.

At the start of the examples I posted, the following Gcodes appear:
G90 G94
G17
G21

It's worth including similar at the start of all gcode files.
There's a good reference here if you don't understand them.

Jogging is relative to the current position *regardless* of the current modal settings.

 

it is in whatever mode tha tlst Gcode set it to.
G90/G91 are part of a modal group, things that once set, stay set until changed.

Gcode generated by openbuildsCAM/Fusion360 etc run in G90 mode, which is absolute mode (which is, confusingly, relative to the WCS )
G91 mode is set when needed by things like probing macros, and every Gcode program MUST set G90 is that is what it expects, do not ever 'assume' a mode, set what you need every time.

 

Relative, jogging is after all a move from "where you are now"

 

do NOT use G92
yes it creates offsets (sets your displays to 0), that may be useful in some cases, but it creates GLOBAL offsets that mess up every other offset, including tool length offsets.
Because it is global is will BITE you at some point because something unexpected (and possible expensive) will happen.

The correct way, without sideffects, is to use the 'setZero' buttons built into the OpenBuildsCONTROL program (and all other GUI programs for GRBL controllers).
These set the offsets for the current WCS and do not sideeffect tool offsets or anything else.
These are what your CAM program will be expecting to be in effect.

(the setZero buttons use the G10 L20 Pn ... command , which is the correct one to use G Codes )

 

CONTROL's Jogging doesn't use Gcode though, it uses Grbl v1.1 Jogging