Carbide Motion, BitSetter & Sweepy Pro

[coastline]

Hi team-

It would be great if Carbide Motion had an option to be aware of the Sweepy Pro (and maybe other Sweepies?), and would slightly modify the BitSetter-based tool change workflow accordingly.

Currently the tool change workflow starts by moving the cutter to the tool change location. With the Sweepy Pro I no longer have to remove the base of the Sweepy to do the tool change, since it’s accessible above the Sweepy Pro. Upon resuming, the machine moves to the BitSetter to measure the new tool, and I inevitably forget that I haven’t pulled the Sweepy Pro base off, which then collides with the BitSetter and I assume throws the machine out of position. I then re-initialize the machine and do the whole dance again, possibly having to pick up the program mid-stream somehow.

Assuming that I get the Sweepy Pro base off in time and successfully measure the new tool with the BitSetter, Carbide Motion then moves back to the tool change location, pauses a beat, turns on the spindle, and then goes to the next work position to start cutting. I manually have to pause the machine, ideally before the spindle turns on but after the Z-axis has cleared away from the BitSetter enough, re-install the Sweepy Pro base, and then “start” the job again in Carbide Motion’s weird stateless parlance for “resume”.

My ask is for an additional checkbox in the Carbide Motion settings alongside “Enable BitSetter” called “Enable Sweepy Pro”. This would modify the BitSetter workflow by adding an additional note to the “Insert Whatever Bit” dialog to say “Insert Whatever Bit and Remove Sweepy Pro Base”, and adding a reminder that the “Resume” will then go to the BitSetter as the next action. After the BitSetter measurement is complete, the workflow would then pause again as soon as the cutter has moved away from the BitSetter to request user intervention to re-install the Sweepy Pro base. Only after the base has been re-installed should the spindle start and the machine move to the next work position.

In general, it would be great if Carbide Motion was more explicit in describing what is going to happen next when user actions are completed.

Thanks for considering!

[Tod1d (Tod (with 1 'd'))]

Ideally, the toolchange command should be in an editable macro like many other machine controllers. Then you could set up the toolchange to do whatever you want/need.
Same with the pause command in CM, and the M0 M01 M02 M30 commands in gcode.

[coastline]

Agreed @Tod1d! I haven’t gotten into macro development yet as too much seems to be baked in to fixed gcode that is executed by the app, but having pre/post hooks on all of these commands would be amazing.

[CMA45 (Colt)]

Just found this post as I was looking for a solution or how others deal with the sweepy pro and bit setter. I’m normally pretty good at making the adjustments but forgot last night and it ran into the bit setter and threw off the machine. It would be nice to have a couple more stops for the adjustments before and after the bit zero.

[coastline]

Couple of other recent notes:

• Triggering a Z-zero goes immediately to the BitSetter, I guess as the modal suggests. Do not collect $200, do not pass go, hope you’ve got your sweepy pro boot removed at that point.
• If you’re debugging a test program and want to stop things at a tool change to go futz with the programming, clicking the OS window chrome “close” button on the “please change your tool” modal dialog box is shorthand for “resume”. This is super sketch UX IMO. Since when in the history of windowed GUIs does “close” ever mean anything other than “stop what you’re doing and get rid of the window”? Modal dialogs should pretty well always come with a cancel option, especially ones that are going to move something physical.