PCB_GCode and tool change positions

Unsupported
1

I’m trying to machine a PCB using Eagle and PCB-GCode. All is working well except the routher position during tool changes. I’m running the “Drill” TAP file, and instead of stopping at 2"/50.8mm above my XY origin, it’s stopping at 0.1"/2.54mm when I finally get the Carbide Motion tool change prompt.

I have explicitly set the Z-height for tool changes @ 2"/50.8mm and I see the code to position there, yet it’s not doing what I need it to do so I can change bits for the larger holes I need.

Here’s the tool-change code snippet below. I’m a G-code hack and I’m hoping our expert user base might assist in figuring this out. Thanks in advance.

M05
G00 Z50.8000
G00 X0.0000 Y0.0000
M06 T02 ; 1.6000
G00 Z2.5400
M03

2

Bump…

I thought there might some insight among our pro group, especially those G-code guru’s who frequent this forum. I’m going to post over on the Shapeoko forum to see if I can gain any insight.

Anyhow, I thought I’d run the G-code thru the Camotics preview tool… I have snapshot two images, effectively the end of tool-1/drill-1 path and the start of tool-2/drill-2 path. It appears that the G-code is correct. The spindle goes to 0, 0, 50.8 mm with tool-1/drill-1 and then transitions to tool-2/drill-2.

So, I’m still left with the question of how the Carbide Motion v2.3 controller (GRBL 0.9i?) should operate with the tool change codes? When I finally get the tool change prompt the spindle is just above the work piece and there’s inadequate vertical space to change the bit.

I do realize I could just hack up the G-code into 2 files, but that’s a hack… it would sure be nice to run a multi-tool job with my system.

Any help or suggestions appreciated.

Tool1_End.png1311×615 49.1 KB
Tool2_Start.png1311×615 48.8 KB

3

Well, I can only tell you what should happen on a Nomad since I don’t have a ShapeOko. But there is one thing both of them have in common: Grbl. Grbl doesn’t know anything about M6, it’ll barf if you send it directly to the Grbl board. However, Carbide Motion knows what it is and turns it into other g-code that it sends to Grbl. On the Nomad, it looks something like this:

M05
G0Z-5.0
G0X-120.0

; Here there’s a pause with a prompt in Carbide Motion

M05
G0Z-5.0
G0X-2.5Z-5.0
G0Z-35.0
G4P0.005
G0Z(current)+3 ; carbide motion actually computes an absolute coordinate to do a relative move of up 3mm
G38.2Z-180.805F200
G0Z-5.0
G0X-8.0
G4P0.005

You can’t just run that as a gcode script because Carbide Motion reads the resulting positions from the Grbl responses and uses that to compute subsequent moves. Also, it waits for Grbl’s queue to be empty at several points.

Also, a thing to note here is that CM always works in machine coordinates and does the work coordinate translation itself (on the Nomad at least). That’s why all the coordinates are negative off of the 0,0,0 that is the homed position.

So on a Nomad, the script you gave would work, but it would have unnecessary movement because it would first move 50.8mm up off of the Z-zero, then move to the X0 Y0 coordinate of the work piece (often lower left corner of the stock) but then raise Z all the way up and center it left-to-right and ask you to change the tool to “#02”.

On a Shapeoko, I would guess it could do the same except for two problems. One, it could only really move in absolute terms if it knows that you have homing switches and where those are, so you have to make sure your Grbl settings reflect this. Second, after the tool is changed, it needs to measure the tool to maintain the Z zero, but the ShapeOko doesn’t have a tool measurement probe, so really it’d have to ask you to re-zero Z, but I don’t think that’s hooked up to anything yet (maybe when they produce the Z-probe?).

What I don’t understand is that your G0 Z50.8 should move you up 50.8mm from your work zero regardless of the M06 tool change. Why doesn’t that work?

4

Mark -

Thanks for the informative post and taking the time to reply. It makes sense that there’s a CM pre-processor for GRBL, and your content has actually given me some ideas to try.

I am gonna go shake down the Wiki for some background info on what you’re talking about as well. Any suggestions on other applicable CM/GRBL references?

The Z-carriage does raise as instructed, but when CM finally prompts for the tool change the carriage and bit is sitting just above the work piece…

As far as Z-Height of tool #2, it’s not uber critical. I’d simply set the exposed tool length from the collet base and be totally in the ballpark as all these operations are drilling (yes, the Shapeoko does drill holes using PCB-Gcode).

I’ve also over compensated in the hole drilling Z depth setup to ensure I’m all the way through my G10 and into my wasteboard.

5

There are a number of G-code pre-processors listed — the name G-Sharp comes to mind, and I believe one was recently added into bCNC — I think that it includes the tool change stuff already.

6

Maybe CM is trying to do you a favor by positioning it such that it is easy to get the tool to have the same stick out. I wonder if CM supports any other pause like M00. It’s host support you need because you need it to stop sending gcode and prompt for continue.

7

This thread: Carbide Motion Dwell (G04) time units are unclear seems to think that M0 is supported, so if you use that instead of M6 you should be able to pause where you want. Unless it does the same favor then too.