Likely Change to Carbide Motion

UPDATE: Beta release is available. Read more here

I wanted to share a change we will likely roll out to Carbide Motion soon. It’s something we’ve had on the drawing board for a long time, but we never wanted to make a breaking change to the workflow.

  • CM will begin measuring the tool using BitSetter after you set a Z zero, whether by touching off or using a probe.
  • It will no longer be necessary to load a tool and measure it when you initialize the machine.
  • It will no longer be necessary to load a tool only when you press the “Load Tool” button.
  • There will no longer be popups before jogging to tell you not to change the tool.
  • You will not be able to download CM without clicking OK to an obnoxious popup pointing to a blog post summarizing this.
  • There is no change if BitSetter is disabled.

This is a deep change, so we were also able to go into the BitSetter and initialization code to remove some of the delays that give the spindle time to spin down. (They’re not removed; we now track the time of the movement and only dwell for the remaining time)

Why are we doing this?

We’re moving the moment that we use the tool measurement closer to the moment that we measure it, which makes it harder for someone to change the tool at the wrong time.

Again, this is something we’ve wanted to do for a long time, but people don’t like change, so we kept putting it off. (I’ll skip the straw that broke the camel’s back)

When does the tool get measured now?

The tool is going to be measured with BitSetter every time you set a Z zero:

  • With a BitZero
  • By clicking “Zero All”
  • By clicking “Zero Z”
  • By entering an offset and pressing “Enter”

The spindle will then return to the prior X/Y position, with the spindle retracted to the top.

What does this mean for normal use cases?

1- If you start the machine, set a zero and run a CM project

  • Initialize the machine. There is no need to measure the tool.
  • Go to jog, set zero, tool is measured.
  • Run the program, tools are measured normally.

There is no real change here; the initial tool measurement is deferred until the zero is set. Some popups are avoided.

2- Set the zero once, then never again. Start the machine and run a CM project

  • Initialize the machine. No need to measure a tool.
  • Run the program, tools are measured normally.

This should be a net win, with the initial “Load Tool” process eliminated. Some popups are avoided.

3 - Start the machine, set a zero, and run a custom program without an M6 tool change

  • Initialize the machine. There is no need to measure the tool.
  • Go to jog, set zero, tool is measured.
  • Run the program, no tool is measured.

No real change here; the initial tool measurement is deferred until the zero is set. Some popups are avoided. (We’d call this a “Winston Workflow” that is not frequently used)

4 - Start the machine and run a custom program without an M6 tool change

  • Initialize the machine. There is no need to measure the tool.
  • When you click the “Run” button, CM mandates that you hit the “Load Tool” button to measure a tool. This only happens the first time the program is run.
  • Run the program, no tool is measured.

There is no real change here; the initial tool measurement is deferred until you try to run the program. Some popups are avoided. (We’d also call this a “Winston Workflow” that is not frequently used)

What we need

We’ve discussed this a lot internally, and we’re at the point where nobody can come up with any practical use case where this is a net negative. We’re 90% sure this is going to happen.

This is likely a one-way change to the code, so once we go any further, there’s no going back. Before doing that, we wanted to post here for feedback. Thoughts?

(I’ll take a “like” on this post as, “You guys are genius, DO THIS!!”)

PS- This is a single-issue thread, so I’ll delete off-topic replies to keep it on track.

110 Likes

I think it sounds like a good change. I am quite used to the current process, but I know it can typically be a problem for newer users.

#3 in particular sounds like my ideal workflow, looking forward to a beta

3 Likes

You’re only 3 or 4 years too late! :smiley:

2 Likes

Streamlined and clean. Always appreciate a workflow iteration.

2 Likes

While I am generally a person that fears change, I am optimistic that this will be a net positive. I’ll admit that when I first got my machine, I had several Z failures because I did not understand the bitsetter methodology and was naughtily changing bits without telling the machine because I figured probing a zero would teach the machine zero and tool length when it probed next.

Again, this seems like it will be more straightforward going forward. Sticking to the rules with the past methodology was to keep us safe, but this seems more intuitive and should keep us from snapping endmills too.

5 Likes

Decisions on whether we implement a feature or not have almost always been based on human factors- “should we” rather than “can we”, and we’ve been trapped between different groups of customers in making these decisions. We’re going to do things a little differently for a while and see what happens.

The feedback here is more positive than we expected, so we’re going to call this a “go”. Thanks to everyone who liked or posted.

git commit -m “YOLO”

15 Likes

This looks great! I run the same size acrylic stock set into a fixture most of the time and will cut the same file upwards of ten times a day so I seldom need to change the zero. The elimination of having the bit measured on initialization is a plus. Is there a possibility of reducing the start time of a file? When running the same (20-minute) file multiple times in a row the time grows on you especially since I need to stick around to initiate having the bit measured. At any rate, it appears your change is a welcomed one.

1 Like

Is it a one-bit job?

Mostly 2 bits per file (same 2)

I’m not sure what we can fundamentally speed up then. You need to measure each tool and stick around for the clicks that entails. If it was a single tool, you could remove the M6 and then you’d have no tool measurement at all.

We did work on removing all little delays that we could, since the BitSetter code had to be reworked anyway, so I would expect it to be a little quicker.

4 Likes

Thanks, not a big deal. Didn’t mention the appreciation for the removal of the popups going to jog, that works great for me as well.

1 Like

This is nice to hear. Hopefully it will be rolled out to the raspi version sooner than later.

One request I have is to make the UI a little more intuitive. Instead of a centered collection of buttons, perhaps something more streamlined like a ‘workflow’ button arrangement, so you know where you are in the process, and what should happen next. Buttons like ‘Initialize machine’ → ‘Set zeros’ → ‘Load Program’ → ‘Start’. It might help with repetitive runs, so people don’t get lost and accidently change a tool without telling the machine. Buttons can be active colors showing where in the steps you expect to be. The ‘Run’ and ‘Jog’ menus should be part of the main window, rather than top menu items.

2 Likes

For reasons I argued endlessly about In this thread this will be a win win for everybody.

Since this is related I’d like to add that when the bit change location was changed I hated the new location. Previously it was over the waste board for my 4XXL… dropped a bit and oops… now it is over the front where drop a bit and it’s well damn that WAS a nice bit. Why not make it so we can choose the location?

2 Likes

Once it goes through initial testing, we’ll do a pi build. The pi is a bit of a pain for rapid iterations, and we don’t have the build pipeline setup for separate betas.

There should no longer be opportunity to change the tool at the incorrect time with this change to CM. But, your larger point is taken. Generally speaking, we’re more open to changes that might seem “jarring” than in the past. We’ll see how this change goes and see what happens from there.

4 Likes

When is the expected roll out?

Hopefully a week or two.

7 Likes

Looking forward to it.

1 Like

Oh yeah, this will be a welcome change. Even after countless jobs the popups give me pause since I’m usually just clicking past them without an actual tool change. Excited for the new behavior!

1 Like

Hey Rob,
Thank you and the team for helping me get my machine up and running.
All is well!

With the new changes, what’s the behavior as we initialize the machine?
Jog far back right corner for S5P while reading inputs from the limit switches, then sit idle without jogging forward near bit setter?

Looking forward to the roll out! Thanks!

1 Like