Bitsetter probing during initialization

[Croy9000 (Steve Easley)]

Curious what the reasoning is for having the machine go through the load tool, probe tool routine when you first connect? It does the same process again when you start a job, so seems redundant. Also I really don’t like the machine taking off on me from the home position to the front center position when I connect since it could crash into something if I wasnt prepared. Any way to disable this feature? Or is there a solid reason for letting it do this?

[MadHatter]

I just had this issue yesterday. I had the spindle running (I manually turn it on and off) and I almost put a 1/4" hole in my bitsetter.

If you want to avoid the bit probing when you start a program, you need to edit out the M6 gcode command.

I use Makercam.com, so the tool change command is:

T0 M6

I also edit out the M30 command at the end of the program to keep the spindle from running to the back of the machine.

EDIT: Sorry, not explaining why it does it, just explaining what I do to avoid the second bit probing.

[Croy9000 (Steve Easley)]

Yeah I guess I was wanting the opposite, avoid the bit probing on initial connect. At least when I start a new job, I am expecting the gantry movement then. But your tips are good for tweaking the job specific actions.

[fenrus (Arjan van de Ven)]

so this may sound totally insane…
but the location of the bitsetter itself is totally configurable.

I’m pondering putting the bitsetter at the homing position… I’m not going to cut there anyway

[Julien]

FYI, this topic came up before (several times), and then:

@robgrz

With BitSetter, or the Nomad for that matter, we depend on having a valid tool offset all the time so if the machine has been off we assume that it’s changed and the tool needs to be checked again. This is both a safety issue and a potential for a lot of support problems so this behavior is not going to change for the foreseeable future.

I know there are a lot of workflows that people can come up with as a compromise. We understand them and we’re not going to implement them. This comes off much more harshly than I intend but I want to be very clear about this behavior in particular so that nobody is under the impression that we’re flexible on the topic. (My wife accuses me of hedging everything so at least she’d be happy about me being definitive on this one.)

It’s been part of the user feedbacks from day one, BUT it’s also quite understandable that C3D now has a very large user base to manage, and, how do I put this gently, some of the users want to use their machine like it’s an iDevice, so the workflow needs to be foolproof.

Considering Rob’s answer above (again, perfectly understandable), if this is a problem for you, you may want to consider using another G-code sender to use a specific workflow that will best suit your habits.

[Croy9000 (Steve Easley)]

Thanks for the reference to Rob’s response, my searching failing me. Figured there was a sane reason for the behavior, I just wanted to understand it. I’ve usually always used another g-code sender, but wanted to give CM5 a shot again since I just got the Bitsetter. I totally understand CM needing to close as many of the gates to the pasture as possible.