How does the BitSetter really work?

Software Carbide Motion
1

What’s going on when Carbide Motion uses the BitSetter? The log feature in Carbide Motion does not show everything, so rigged up a connection via an RS-232 level shifter to the serial port header on the controller board that would allow me to monitor the serial communication between the ATmega16U2 and the ATmega328P.

I can see that it does a G38.2 to to probe the button on the bitsetter, then I had assumed it was using a G10 or G92, but I don’t see that. I don’t see it doing anything to adjust the tool offset or coordinate offset.

Is Carbide Motion doing tool offsets entirely in software?

2

7221f725e518793a71eaec4da3d0d5b60fa961b374f3b33f8a83867da2dc331e

But seriously, I know enough to leave you confused.

CM switches to a different coordinate system to locate the bitsetter button height, then uses the difference of that other coordinate system to detect the difference in bit heights.

3

But it doesn’t update or switch coordinate systems using any G-code commands. During a tool change, all I see are G38.2, G0 and G4 I only captured during the initialization/jog/toolchange phase. I guess I should capture more data to see what it does when actually cutting.

Here’s what I see being run during a tool change:

G0X-2.5000Y-850.0000Z-5.0000  (rapid to BitSetter button)
G0Z-15.0000                   (rapid down a bit)
G38.2Z-155.0000F800.0         (quick probe )
G4P0.005                      (pause on button)
G0Z-66.6650                   (short retract to release button)
G38.2Z-216.6650F50.0          (slow probe)
G4P0.005                      (pause on button)
G0Z-5.0000                    (retract)
G4P0.005                      (pause)
G0X-434.5000                  (return to front center)
G4P0.005                      (pause)
4

I believe Carbide Motion does everything in software.

2 Likes
5

I captured a full job being run, and it is indeed all being done in software.

If I run a job, then change my zero, then run the job again, the coordinates are translated in the G-code sent to the controller.

Here’s the pertinent part of the original code as loaded into CM:

G0X25.000Y25.000
Z3.175
G1Z-1.270F203.2
Y-25.000F508.0
X-25.000
Y25.000
X25.000
Z3.175

This is what is sent to the Shapeoko with a zero of -400.000, -700.000

G0X-375.0000Y-675.0000                                                      
G0Z-1.8250                                                                   
G1Z-6.2700F203.2                                                             
G1Y-725.0000F508.0                                                           
G1X-425.0000F508.0                                                           
G1Y-675.0000F508.0                                                           
G1X-375.0000F508.0                                                           
G1Z-1.8250F508.0

This is what is sent to the Shapeoko with a zero of -300.000, -700.000

G0X-275.0000Y-675.0000                                                      
G0Z-1.8250                                                                   
G1Z-6.2700F203.2                                                             
G1Y-725.0000F508.0                                                           
G1X-325.0000F508.0                                                           
G1Y-675.0000F508.0                                                           
G1X-275.0000F508.0                                                           
G1Z-1.8250F508.0

I can’t decide if that is a really good idea, or a really bad idea. I guess it’s safer in that CM doesn’t need to worry about the state of the GRBL, as it’s always in machine coordinate space. Now I understand what the “To send directly to GRBL, begin line with /” text means in the MDI dialog box. Without the slash, CM is translating coordinates on the fly.

6

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