Carbide Motion - Extend "Initialize Machine" capabilities

It would be nice if the 'Initialize Machine" sequence could be modified to support individual preferences. After Homing, it would be nice to be able to do things like:

  • Move to location (X, Y) (give co-ordinates to move to) (Edit - changed from “Specific Point”)
  • Move to a Rapid location
  • Retract on Z (may be unneeded, does homing always end with Z retracted?)
  • Zero (X,Y) to current location

So, for example my usage would be to Retract on Z, go to Rapid SW, zero to current, Rapid to S (where I do my tool changes).

I think this would be a good modification.

I think “Move to a specific point” and “Move to a Rapid Location” are basically the same thing - you would rapid first and then nominate that point as the post-homing location.

I would also like the tool change location to be specified independently and used when BitSetter tool changes are required. It’s too far forward for me and as others have mentioned, bits fall on the floor.

1 Like

So we can also add

  • Move to tool change location

By “specific point”, I meant you could specify the X and Y co-ordinates, not that there was just a single point that you could move to. I’ll edit.

Hehe… with all these suggestions, CM will be CNCjs in no time :slight_smile:

1 Like

Machine origin which is where the machine is when first initialized will always have Z fully retracted (well, at that distance from the switch the pull-off is set to in Grbl).

If one has a BitSetter the machine will move to the tool change position automatically.

Not sure if Zero XY is worth the added button as opposed to just requiring pressing two buttons — that would be a UI query for the developers.

I would actually like to see the whole intialisation process re-engineered, where a BitZero and BitSetter are installed.

I don’t like the fact the spindle homes then immediately moves to front and centre, prompts for the bit, does the BitSetter thing, then returns to front and centre - before you even load a file! And then it does the BitSetter thing all over again.

Surely there must be a better, more efficient way to do this?

I’ll need to think about this a bit more, but surely it should home, wait there until a file is loaded, run to front and centre to change the bit it it doesn’t already have the correct bit installed or go directly to the BitSetter workflow if it does (does the Shapeoko ‘remember’ which bit is installed?), then prompt the user to run the BitZero workflow, manually zero or no zero required.

That’s all :thinking:


The Shapeoko really has no way of knowing what bit is installed - obviously it could assume. I think it just knows the Z-zero (machine coordinates), and needs the related tool length offset so it can be used for the next tool change. With the BitSetter workflow you get an option to swap the tool at the start of every job, so this is necessary at the moment.

I agree with most of the other suggestions, the current initialization workflow is a little awkward in that I have to sequence loading material around the head, or switch screens to rapid jog it back out of the way since it wants to sit in front. Not a big deal, but great points to raise if we want to see improvements!

I appreciate that, but CM maybe could ‘remember’ that, with a bit of programming, in the same way it remembers X, Y and Z zero points, BitSetter settings, etc?

Then, when a file is loaded into CM, it could compare the ‘last known’ with the ‘to be used’ bit, and go frm there.

Just a thought!

Couldn’t agree more. There’s a long carriage dance that happens at the beginning of each startup. I need a feature that will let me “Run Again” with the same cutter, but a fresh workpiece, to gain some productivity. There should be no need to do all of that if just the stock is changed out, and you want to re-run the same code again to make a duplicate.

Bloody hell, Jeff, were you saving up for all that? :rofl: :rofl:

I wonder if the limitation is hardware, rather than software, as both the BitSetter and BitZero run from the same header? But maybe not.

I understand the reason for initialisation process, as the machine does need to have a known datum point to start from, but I that should also the user’s starting point, too. The router’s out of the way, and there’s space to locate and secure the workpiece (and any guides).

Load the *.nc file and start the process…

From this point there should be several options depending on configuration (and I maybe complicating things too much) but you all know the workflows, so I’ll just name them:

If neither device is installed, CM should prompt for manually zeroing the cutter to the workpiece, followed by Go to start the cut.
If both are installed, CM should prompt for the cutter, do the BitSetter workflow, return to front/centre, prompt for zeroing (I appreciate there are several types and a v1 and v2 BitZero, but maybe the latter could be configured in the Settings?)
If just the BitZero is installed, CM should prompt for zeroing.
If just the BitSetter is installed, CM should prompt for the cutter and then do the BitSetter workflow, but it might not need to return to front/centre.

Then click Go to start the cut.

I think that makes sense?


It looks like this thread is starting to wander into “What should the start of a JOB do?” territory. I don’t have any useful opinions on that myself, so maybe split that into another thread?

I think these comments are kind of relevant, and if they’re considered by @Jorge and the team, that might help, but I’m not worried either way - I can’t split the thread for you though, sorry.

Good comments, all.

Wait, you can do this? I didn’t think you could load the *.nc file before connect/intialise!

I’ll check next time I’m out there…

Well, it was about 2:30am you wrote it!

Me? No…

But I think we’ve now definitely hi-jacked this thread, though. Sorry @mhotchin

I can fork it for you, but I wouldn’t know exactly where to cut/fork. Let me know.

1 Like

This topic was automatically closed after 30 days. New replies are no longer allowed.