Bitsetter + Initialize Machine - probe before prompting

Software Carbide Motion
1

99.9% of the time, when I initialize the machine, there is already a bit in the router.

Instead of prompting for a tool when initializing, just try probing, and if that fails, then prompt for a tool.

2

This isnā€™t an option ā€” Grbl goes into an error state if a probe fails.

3 Likes
3

If the probe fails, just initialize again, and ask for the tool before probing. CM ā€˜knowsā€™ this is happening during initialization, so thereā€™s no state to lose.

Most of the time the initialization will complete faster and with no user interaction. If there is no tool loaded, you end up initializing twice.

4

The error has to be recovered from ā€” this means the machine must be reinitialized/homed.

1 Like
5

ā€¦and thatā€™s fine, since you are in the middle of an initialization cycle anyway! Just do it again, but instead this time prompt before probing.

6

No, it isnā€™t. Please look through the code for Grbl to understand what being in an error state results in, and what recovering from it involves.

7

Well, I just tried it. Hereā€™s the GRBL state after a successful initialization with a probe:

$$
$0=10
$1=255
$2=0
$3=2
$4=0
$5=0
$6=0
$10=255
$11=0.020
$12=0.010
$13=0
$20=0
$21=0
$22=1
$23=0
$24=100.000
$25=2000.000
$26=25
$27=3.000
$30=1000
$31=0
$32=0
$100=40.000
$101=40.000
$102=200.000
$110=10000.000
$111=10000.000
$112=1000.000
$120=500.000
$121=500.000
$122=270.000
$130=845.000
$131=850.000
$132=95.000
ok
N0 G4P0.5
ok
$#
[G54:0.000,0.000,0.000]
[G55:0.000,0.000,0.000]
[G56:0.000,0.000,0.000]
[G57:0.000,0.000,0.000]
[G58:0.000,0.000,0.000]
[G59:0.000,0.000,0.000]
[G28:0.000,0.000,0.000]
[G30:0.000,0.000,0.000]
[G92:0.000,0.000,0.000]
[TLO:0.000]
[PRB:-4.750,-385.250,-83.485:1]
ok
$G
[GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F50 S0]
ok
<Idle|MPos:-419.600,-385.250,-5.000|Bf:14,128|FS:0,0>
<Idle|MPos:-419.600,-385.250,-5.000|Bf:14,128|FS:0,0>

And hereā€™s the GRBL internal state where the probe failed, then a successful initialization happened immediately:

$$
$0=10
$1=255
$2=0
$3=2
$4=0
$5=0
$6=0
$10=255
$11=0.020
$12=0.010
$13=0
$20=0
$21=0
$22=1
$23=0
$24=100.000
$25=2000.000
$26=25
$27=3.000
$30=1000
$31=0
$32=0
$100=40.000
$101=40.000
$102=200.000
$110=10000.000
$111=10000.000
$112=1000.000
$120=500.000
$121=500.000
$122=270.000
$130=845.000
$131=850.000
$132=95.000
ok
N0 G4P0.5
ok
$#
[G54:0.000,0.000,0.000]
[G55:0.000,0.000,0.000]
[G56:0.000,0.000,0.000]
[G57:0.000,0.000,0.000]
[G58:0.000,0.000,0.000]
[G59:0.000,0.000,0.000]
[G28:0.000,0.000,0.000]
[G30:0.000,0.000,0.000]
[G92:0.000,0.000,0.000]
[TLO:0.000]
[PRB:-4.750,-385.250,-82.055:1]
ok
$G
[GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F50 S0]
ok
<Idle|MPos:-419.600,-385.250,-5.000|Bf:14,128|FS:0,0>
<Idle|MPos:-419.600,-385.250,-5.000|Bf:14,128|FS:0,0>
<Idle|MPos:-419.600,-385.250,-5.000|Bf:14,128|FS:0,0>

The only difference is the line labeled ā€˜PRBā€™, which makes sense since I used a different tool for the second round.

 <! [PRB:-4.750,-385.250,-83.485:1]
 !> [PRB:-4.750,-385.250,-82.055:1]

So, a failed initialization followed by a successful initialization seems to lead to the exact same machine state as just a successful initialization. Work co-ordinate offsets are also preserved.

8

Except that the machine doesnā€™t have a sensor to know if the failed effort at probing resulted in lost steps or no ā€” which is why reinitializing/homing is necessary to ensure that the machineā€™s physical state, and the state of Grbl are consistent.

1 Like
9

I do a lot of machining with the bit setter just turned off. Iā€™m double checking my zero after a tool change anyways, so no real point in the machine doing it.

But I just did a project with 6 toolpath files, and a bunch of tool changes. Bitsetter was nice. Change tool when it asks, sit down, hit ā€œResumeā€

4 Likes
10

Iā€™ve only ever operated with a ā€œbitsetterā€ type of deviceā€¦ first on a Nomad, then on a Shapeoko. Itā€™s brilliant and lets you create multi-tool projects where you do exactly what you suggest - sit back and wait to be told what to do.

I suggest that people that are upset by the initialization protocol actually use a stopwatch to determine the length of time they are getting upset with. In the scheme of things, for me, itā€™s trivial. And predictable. Which is better than something that may or may not happen.

4 Likes
11

This drives me nuts too.

This thing reminds me of 1000 windows error messages that you have to click through

12

Which is exactly what I suggested! Initialize without prompting (homing + probe), and if that fails, initialize with prompting (homing + prompt + probe).

99% of the time the first one completes (more quickly and without user intervention), and in the oddball case it doesnā€™t work, the second round takes care of it.

13

I also look at this machine as an introductory machine. People from all walks of life use them from newbie to professional. It is high enough quality to satisfy the professional as well as robust enough the help the newbie. It has to be able to satisfy this wide spectrum of users as it interfaces with them.

14

It also needs to be reliable enough, both hardware and software-wise that it wonā€™t generate an unsustainable volume of support tickets.

A failed probing results in an error state.

The user needs to be informed of that error state and then manually recover from it by re-initializing the machine, acknowledging that it was in an error state.

15

What happens the 1 time I leave my dial test indicator in the spindle/router? I guess I buy a new one while the rehoming is taking place? Is there an issue with a drag bit? I donā€™t know but there are definitely things people could leave in there that you donā€™t want to run into the bitsetter.

16

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