Features requests for Carbide Create and Carbide Motion

Hi,

I have been using Carbide Create and Carbide Motion for a few years now, and I am very happy with them. I am also pleased to see new features being added regularly.

I have a few feature requests for both software:

Carbide Create:

  1. Allow users to create their own machines and materials (currently, this is only possible by manually creating the corresponding CSV file in the user directory, which is very annoying);
  2. Enable the ability to delete or hide default tools (current workaround: I use a custom machine);
  3. Add a “tool queue diameter” field, because metric and imperial measurements are very similar (3mm vs. 3.175mm, 6mm vs. 6.35mm), making it sometimes difficult to know which collet to use;
  4. Fix the validation when the system language is not set to English (for example, in French, we use a comma as a decimal separator. It is nice to be able to enter 3,175, but it is also impossible to validate the “edit tool” window, as the uneditable field “included angle” uses a dot 0.0, which is not a valid number in French);
  5. Warn if multiple tools with different geometry parameters have the same number (if tool numbers are equal: ensure that diameter, “type” (end mill, ball, vee…), vendor, and model are the same, but don’t check speed settings, as they may depend on material/machine). This way, you don’t have to manually keep track of which numbers are used or not.

Carbide Motion:

  1. Display the tool name and not only the tool number. From this discussion, I understand it could be difficult to integrate it into the GCode, but would it be possible to read it directly from the tool database of Carbide Create? (This way, you can even display all the information: tool name and geometry information, so you can easily check that you have grabbed the right tool. With the “tool queue diameter” field, you can also quickly confirm that you are using the right collet);
  2. Add a “trace contour” option: when clicking this button, the machine goes all the way up on the Z-axis and does a slow path around the contour of what you plan to cut. This way, adding a small laser to the machine will make it easy to ensure that everything fits well, even if your stock is not square (for example, a “not very round” wood log or using non-square stock…). My current workaround is to add a custom toolpath in Carbide Motion;
  3. When doing the tool measurement, add a maximum movement: sometimes I use very short tools, and I need to add something on top of the sensor to be able to measure tools. But if I forget, the machine goes all the way to the bottom and starts skipping steps. As you know exactly how many steps there are on the Z-axis, a cool feature could be to raise an error: “Failed to reach the tool measurement probe, did you insert a tool? Is the tool too short?”

For me, the most important are 6. and 4. The rest are “nice to have”, and the software are already very nice!

Thanks a lot, and keep up the great work!

This is already implemented to some degree:

https://carbide3d.com/blog/carbide-motion-bounds-checking/

The problem when probing is that we have to yield control to Grbl with a Probe command and wait for the result. It might be that we could calculate the maximum safe probe distance for each instance of machine and Z-axis, but even if we did, the result would be the same: the machine would be in an error state from which the only possible recovery is to re-initialize.

Just to be sure, when you say “the machine would be in an error state”, it means that if the probe sequence fails, the machine is in a “must reset” state, even if no steps were skipped?

Currently, you always have to reinitialize, which is annoying, and sometimes impossible to recover easily (for example, when doing 3d and zero on top).

By adding this kind of check and a “retry” button, you avoid re-initialization when:

  • you forgot to put a tool (yes, it already happened to me during a job…)
  • you put your tool a bit too far in the router
  • you forgot to add the “spacer” before measuring tools that are too short

Correct.

If a Probe operation fails the machine triggers an error.

This is a consequence of not having any positional feedback — the software can’t know in what way the Probe operation failed.

The Z-axis zero should be preserved after the re-initialization.

Oh, okay, thanks!

Is there no way to reinitialize just the Z axis? This way, in case of a failure, you wouldn’t have to go through the entire ‘machine initialization’ process (which completely resets the software, requiring you to re-upload your gcode, and, there is no quick way to “go to the next tool change” to restart exactly at the same point).

No. There is a single command for homing and it does all three axes.