Kflop and tool offsets

I'm ready to start setting up some tools for cutting. But, I wanted to make sure that I properly understood the tool offset strategy in Kflop.

What Gcodes I will need:
After some reading, there are a couple functions that have to do with offsets: G43, G52, G54-59 and G92.

For my purposes, being a simple home cnc'r, I am most interested in just using G43 for my tool offsets and possibly G54 for when I want to replicate a part a few times on one blank piece of aluminum.

G52 is a temperary offset that I can't really image a use for yet and G92 is an obsolete command that was a predicecor to G50 (at least from what I have read on the interweb)

How G43 (on the RS274/Kflop) works for me:
The way the G43 works is that you will find 0 for the z-axis (I'll get into that later) then take each tool you want to use and find out the offset from what we are calling 0.

Since I don't have a "master" tool that I will use for finding 0 on the z-axis, I will always calibrate 0 on the z-axis with tool #1. So, I put tool 1 in the machine, run the z-axis until the tip touches the top of the piece (I use the top of the piece as 0 for my plastic molds). Then, set the axis to 0 in Kflop.

Then, I take each remaining tool and touch them to the work piece. I read the z-axis position from the screen and enter that value into the tool setup table.

What actually happens during production:
Now that I have set up the tools, all I need to do is tell the program how to adjust the tool height in order to make the tool cut at the right depth.

I put the following code in the program: G43 H[tool number]
This will cause the z-axis to move to the appropriate position. For example. If the z-axis is at 0 and the execute a G43 command on tool 3 (with an offset of .5"). The z-axis will move up .5" and assume that is the new 0.

Additionally, you can add a move command into the G43 command to take the z-axis to a starting or safe position:
G43 Z0.4 H3 //This command would offset for Tool 3 and move the Z axis to 0.4 which is my clearance height.

How to remove the offset:
Once I am done with the offset, I can either enter a new tool offset or disable the offset using the G49 command:

G49

From http://en.wikipedia.org/wiki/G-code

G43

Tool height offset compensation negative

M

Takes an address, usually H, to call the tool length offset register value. The value is negative because it will be added to the gauge line position. G43 is the commonly used version (vs G44).

G50	Position register (programming of vector from part zero to tool tip)		T	Position register is one of the original methods to relate the part (program) coordinate system to the tool position, which indirectly relates it to the machine coordinate system, the only position the control really "knows". Not commonly programmed anymore because G54 to G59 (WCSs) are a better, newer method. Called via G50 for turning, G92 for milling. Those G addresses also have alternate meanings (which see). Position register can still be useful for datum shift programming.
G52	Local coordinate system (LCS)	M		Temporarily shifts program zero to a new location. This simplifies programming in some cases.

G54 to G59

Work coordinate systems (WCSs)

M

T

Have largely replaced position register (G50 and G92). Each tuple of axis offsets relates program zero directly to machine zero. Standard is 6 tuples (G54 to G59), with optional extensibility to 48 more via G54.1 P1 to P48.

G92

Position register (programming of vector from part zero to tool tip)

M

T (B)

Same corollary info as at G50 position register. Milling: Always as above. Turning: Sometimes as above (Fanuc group type B and similarly designed), but on most lathes (Fanuc group type A and similarly designed), position register is G50.

Setting up the limits and interlocks with Kflop

After the machine was wired I started looking into making sure I could avoid hitting the axis limits as well as being able to halt movement asap.

The basic concept I wanted to follow is that of normally closed or safe IO. Basically the concept is that the machine will only function is power can flow through the control circuit. If anything goes wrong (wire break, estop, equipment failure) the machine will open the main contractors and bring the machine to a safe state.

Concept:
In order to pull this off I need to make sure the 3 things can kill power: Operator, Limits and Servo Failures.

Limits:
Everything needs to let power flow in a normal state. For the limits, this means that they need to be normally closed (and open the circuit when something goes wrong).

Operator (Estop Switch):
Again, this has to be normally closed

Servo Failure:
The servos are equipped with a fault circuit that remains energized until a fault occurs. Then power is pulled to ground. Since Kflop can identify a servo failure from a position output/encoder input mismatch, I will leave this one out for now.

Implementation Strategy:
When the machine is powered on, I don't want the machine to enable simply because there is no limit or estop being triggered. So, the operator will have to press an enable button on the screen. This will be the link in the limit switch circuit that allows power to finally flow when we're ready to cut some metal!

If a trip occurs, the Kflop should disable the axis in the software as well as release the "Enable" output I mentioned. This way once a trip occurs, we are back to where we started requiring the operator to acknowledged that things are ok (and press the Enable button) before the machine will reinitialize.

Not the software hitch: Because there is a delay between when the user pressed the Enable button, the circuit allowing power to the main contractor and the Kflop receiving confirmation that things are ok(and therefore allowing the circuit to remain closed). I need to add a delay in the Kflop whenever the system is being initialized. (I will post the code for this if anyone is interested).

Rip and replace of the Dynapath control system with Kflop

Here's a shot of the test bench setup for the Kflop. I have it arranged with some terminals for encoders, servo outputs, spindle and coolant. It served it's purpose dutifully. Once I tested it all out, it was time to start tearing into the Dynapath Delta 10 system.

Here's the old beast. It was actually much easier to trace out the wiring that I had initially thought since all the controls came through d-sub connectors separated by function (i.e. servo control, encoders, interlocks...).

This is the operator console. It has some functions that I'd like to migrate over to the Kflop system. Specifically, the motion start/stop buttons, pot for feed rate override and spindle speed override. I'm not sure how to pull it off yet but once I dig into the Kflop I'll post as I develop.

Here's the panel over I mounted the Kflop and set up some terminals. On the left is the encoders and servo output (+/- 10v) then the 5v and 24v power supplies. On the right, is all of the discrete inputs, outputs and interlocks.  Above the horizontal panduit is the 3-phase power and the baldor DC servo controller. It's amazing how much smaller the Kflop is than the Dynapath! I could rent out a room in this panel:)

My next challenge was the power supply panel. It was equipped with multiple contractors for motor rotation, external power as well as the 24vdc power supply. Since the machine is equipped with a VFD and I don't have any plans for external 3-phase devices, I was able to pull it all out and start over.

And, in a flash, the panel is done (it took a bit longer in real life).

For all the current devices I just needed a couple small relays, fuses and terminals. Ahhhh, clean....

I accommodate for a 24vdc work light, 24vdc z-axis limits, 120vac air solenoid, 120vac lube system and a 240vac coolant pump.

 Once all the wiring was complete I started some moves and interlock tests which I put in another post.

Tree 310 Kflop replacement - introduction

Well, I finally bought a Kflop to retrofit my Tree 310 CNC machine.

It currently has a Dynapath Delta 10 CNC control. The current controls operate correctly but, they're circa 1991. The biggest issue with that is the limitations on memory. I can input about 2000 lines of Gcode into the unit...total. So, I always clear the memory and then load a program. But, even with that, I can't do anything more than simple moves. This is a huge limitation when using Cam software to create letters or curves. The curve is separated into an uncountable amount of tiny curves and takes up a ton of lines of code.

I've gotten to the point of powering up the unit and attaching it to my spindle. It works flawlessly!! I'll submit some pictures of the initial setup later.