Greetings folks,

First a little about my setup.

I'm Tom and I'm new to both Mach and the CNC world. I'm an amateur loudspeaker builder and recently purchased and built a CRP-2448 from cncrouterparts. The machine went together slowly and I now have it up and running. I assembled all my own electronics including a SmoothStepper G540, PMDX-108 BOB and SuperPID. I have my Y axis defined as the long 49" axis, X as the 25" horizontal axis and Z is of course up and down. This machine uses two motors on X, they are wired as X and A on the G540. I have 6 limit/home sensors mounted on the axes. Three on Y, two on X and one on Z. Z has a "high limit/home" switch that defines zero at 5" above the spoilboard on startup. The intent is, or course, to prevent any undesirable plunging if I forget to use the tool height plate. X has two simple limit switches wired together that also serve to define home and a third "A" switch used to square the "A" side of the gantry after Y is set. I'm using the Dobutton(23,24) and recomb(9) code to set my home position and it seems to work fine. My Z zero code is listed below:
iF IsSuchSignal (22) Then
code "G31 Z-3 F20"
While IsMoving()
Wend
call SetDRO( 2, 1.9688)
code "G0 Z2.5 F60"
While IsMoving()
Wend
end iF

Problem:

I recently found the 3D samples on the Vectric forum and decided to cut a few as a test. The sample requires 4 tool changes during the run. First and second tool change went without a hitch. Third tool change I did the exact same thing but this time the Z axis plunged the bit below zero all the way to the Z axis limit destroying my piece and nearly destroying my bit. It was a 60° straight bit or it wouldn't have survived. I assumed I did something wrong and was able to recover and finish cutting the piece.

Next piece was the Vectric Fleur. First tool fine, second tool fine, third tool not so fine. This time I chucked up my brand new Amana 1045 45° V bit, the expensive one with replaceable knives. Set the Z height but didn't notice what the actual value was in the DRO. It started and again plunged the bit through the piece and before I could stop it, shattered the bit and stalled the router.

I've doubled checked the Z height code and can't seem to find any problems. It sets the Z height to 1.9866 which is exactly what it should be. Actual zero is -.002 below the workpiece so it's setting Z correctly. The code is cutting at a Z height of -0.45 for the first half of the pocket run and it runs fine a second time. I can't understand why this keeps happening. I've broken three bits now, this last one is not an inexpensive bit. It may have actually damaged the tool holder making the entire bit a waste of steel. I suspect something in the Zero height code is not working correctly but I don't know the quirks of Mach.

By my calculation the Z zero position must have been set to a large negative value in relation to absolute machine coordinates. That's the only way a plunge to -0.45 could reference below the spoilboard. I didn't think to write down the Z coordinate for debugging but I'll watch the DRO when I use the height tool from now on and see what it's doing.

Is it possible the Z DRO is not being set or being set to something other than 1.9866 by the code above?
Is there a bug in Mach?
Would it help if I were to add code to check the actual DRO against the set value to verify it was set correctly?
Help?!

Not sure exactly how you are setting your Z height but it is usual for the Z axis DRO to be 0.0000 when the cutter touches the top surface of the work. Perhaps you could check your GCode file to see if, on the 3rd pass, there is a Z command to take the cut depth below what you are expecting.

There is a slight discrepancy between your described Z height (1.9866) and that shown in the script (1.9688) - probably just a typo but it should not be enough to damage your tooling.

Tweakie.

I've read your post several times and it's not clear to me whether your tool plunged too deep during the G31 move or later when you resumed cutting or both. Can you clarify please?

I've read your post several times and it's not clear to me whether your tool plunged too deep during the G31 move or later when you resumed cutting or both. Can you clarify please?

It plunged way too deep. I don't think it was a G31. It was a G1 move. It went through my workpiece and into the spoilboard beneath. In any case it certainly jammed the axes but the bad part is that it destroyed a very expensive bit. I felt and feel the need to understand why before continuing.

I think I've figured it out. I found several bits defined in the Mach database with offsets entered for them. I think that's why it plunged. That would explain why I've been having issues with certain bits before. Sometimes it starts cutting 1" above the work surface, now I understand why. The bit number assigned by Cut2D is higher than I've ever used before. I renumbered them in categories of 10 so it was bit #22 in Cut2D. In the Mach tool database tool 22 had an offset of 1.5" entered. In my mind that would work out to 1.5" ABOVE the work surface not below it but removing all tool offsets and turning the feature off seems to have solved the problem. I need to get more experience with offsets. I don't understand how Mach applies them in some instances. I'm sure it's all logical from a machinists view but to me it's Greek until I've done it a few times.

Below is a snippet of the code. This is the third tool path of 4. As you can see it moves to .2 above the surface, starts the spindle then moves down to 0.04 (the surface where the text needs to be cut) and begins cutting.

( Profile Text 90-V )
( File created: Sunday, May 05, 2013 - 08:19 AM)
( for Mach2/3 from Vectric )
( Material Size)
( X= 9.000, Y= 12.000, Z= 0.750)
()
(Toolpaths used in this file:)
(Profile Text 90-V)
(Tools used in this file: )
(21 = Amana Signmaking V {90° 1.5"})
N100G00G20G17G90G40G49G80
N110G70G91.1
N120T21M06
N130 (Tool: Amana Signmaking V {90° 1.5"})
N140G00G43Z1.0000H21
N150S22000M03
N160(Toolpath:- Profile Text 90-V)
N170()
N180G94
N190X0.0000Y0.0000F60.0
N200G00X-1.6792Y2.0086Z0.2000
N210G1X-1.6792Y2.0086Z-0.4120F30.0
N220G1X-1.0775Y2.7066Z-0.4120F60.0
N230G1X-1.2171Y2.8269Z-0.4120
N240G1X-1.6008Y2.3818Z-0.4120
N250G1X-1.7857Y2.9859Z-0.4120
N260G1X-1.7969Y3.0215Z-0.4120


I think most of the issues I've been having can be traced to either work or tool offsets. It never occurred to me the tool number might cause an issue. Hope that's it...

Tom

I think the G43   H21 in this line is invoking the offsets

N140G00G43Z1.0000H21

you can either remove them from the table, correct them to function as intended or remove the g43...h21 from that line

John

I think the G43   H21 in this line is invoking the offsets

N140G00G43Z1.0000H21

you can either remove them from the table, correct them to function as intended or remove the g43...h21 from that line

John

I think the G43   H21 in this line is invoking the offsets

N140G00G43Z1.0000H21

you can either remove them from the table, correct them to function as intended or remove the g43...h21 from that line

John

Thanks, I think I tracked it down. I never really intended to use them. I don't have a ATC and I don't think I'll be needing to enter any tool wear so I doubt Ill ever be using tool offsets. BUT, I'll be very careful for a while until I'm sure. It's probably Mach that added the code since I had tool offsets enabled. It never occurred to me that I had tool offsets defined. I don't recall entering them but it's possible I did, it's been a long process building this thing. This isn't the first learning experience I've had and it probably won't be the last. Thankfully this machine is well built and won't be permanently harmed by a few crashes. Worst case so far has been burning holes in my new spoilbaord, stalling the router and exploding a bit. R&P drives seem to be quite resilient to running over limits or stalling an axis. They just jump a gear and make a lot of noise but don't seem to be damaged. I set the gear tension low to reduce motor stress and prevent any issues should I end up stalling an axis again. Hopefully I've figured it out.

Thanks again,
Tom