# FOLLOWUP on "macro system for G code"

• posted

My thoughts are solidifying a little bit regarding a "G code macro system". I think that I will roll my own, since I am a computer programmer.

I started writing perl code to perform standard milling tasks. For example, I wrote a function to print G code that would move to a given location, both for G00 as well as for G01 (trivial).

Then I wrote a perl function that would print G code to drill a hole, with optional pecking (drill to pecking depth, quickly withdraw, quickly return to drilling depth, and repeat until proper depth is reached).

For every standard type of task, like drill a bolt hole pattern, mill out a blind hole, mill out a through hole, etc, I will write a function to do that. I will build on functions, e.g. the bolt hole function will use a drilling function, etc.

I am sure that this will not cover "True 3D" curvy surfaces, like milling a statue of a naked woman in 4 axis machining, like on YouTube, but it will cover most of the actual projects that I will encounter.

I am attaching a function to drill a hole with pecking, and the resulting G code (all untested).

Code to drill, say, three holes of depth (-1) in points (0, 0), (2,3), and (3,3) at speed 5 and pecking depth of 0.3, would look like this perl code:

g_set_clear_height( 0 ); g_drill_hole( 0, 0, -1, 5, 0.3 ); g_drill_hole( 2, 3, -1, 5, 0.3 ); g_drill_hole( 3, 3, -1, 5, 0.3 );

This is much more understandable than many other alternatives.

I am sure that I do not really know how to use G codes, but I know that this is a good approach in general.

If it works well for me, I will release it under GPL.

i

###################################################################### function sub g_drill_hole { my (\$x, \$y, \$z, \$speed, \$pecking_depth) = @_; die "For drilling application, you need to do g_set_clear_height first" unless defined \$_clear_height;

die "Drilling depth Z=\$z should be LESS THAN safe height=\$_clear_height." if \$z > \$_clear_height; Print "(Drill a hole in [\$x, \$y] depth of \$z.)\n"; deeper; { Print "(withdraw to safe height)\n"; g_goto( undef, undef, \$_clear_height ); Print "(go to starting point)\n"; g_goto( \$x, \$y ); if ( \$pecking_depth ) { Print "(Drilling with pecking)\n"; my \$cur_z = \$_clear_height; my \$i = 0; while( \$cur_z > \$z ) { \$i++; print "\n"; if ( \$cur_z - \$pecking_depth > \$z ) { Print "(Peck \$i -- drill, clear chips, go back)\n"; deeper; { g_millto( undef, undef, \$cur_z - \$pecking_depth, \$speed ); g_goto( undef, undef, \$_clear_height ); g_goto( undef, undef, \$cur_z - \$pecking_depth ); } lower; \$cur_z = \$cur_z - \$pecking_depth; } else { Print "(Last drilling step)\n"; g_millto( undef, undef, \$z, \$speed ); \$cur_z = \$z; } } } else { Print "(Drilling)\n"; g_millto( undef, undef, \$z, \$speed ); } Print "(Returning to safe height)\n"; g_goto( undef, undef, \$_clear_height ); } lower; }

###################################################################### G Code

(Drill a hole in [3, 4] depth of 0.) (withdraw to safe height) (Go to point Z1 ) G00 Z1

(go to starting point) (Go to point X3 Y4 ) G00 X3 Y4

(Drilling with pecking)

(Peck 1 -- drill, clear chips, go back) (Mill to: Z0.7 at speed F5 ) G01 Z0.7 F5

(Go to point Z1 ) G00 Z1

(Go to point Z0.7 ) G00 Z0.7

(Peck 2 -- drill, clear chips, go back) (Mill to: Z0.4 at speed F5 ) G01 Z0.4 F5

(Go to point Z1 ) G00 Z1

(Go to point Z0.4 ) G00 Z0.4

(Peck 3 -- drill, clear chips, go back) (Mill to: Z0.1 at speed F5 ) G01 Z0.1 F5

(Go to point Z1 ) G00 Z1

(Go to point Z0.1 ) G00 Z0.1

(Last drilling step) (Mill to: Z0 at speed F5 ) G01 Z0 F5

(Returning to safe height) (Go to point Z1 ) G00 Z1

• posted

Gee, I haven't written a MACRO since the IBM 1440 and 1401 autocoder days. Are you writing MACROs or function prototypes?

Paul

• posted

I call them macros, but they really are just perl functions.

i
• posted

Depending on the control, you may need trailing decimal points after whole numbers.

• posted

EMC is cool with numbers.

i
• posted

Pretty cool that your programming your own "macros" but why not use the canned cycles that are included with EMC?

• posted

Yep, great point, I will use all those where appropriate.

• posted

EMC2 has canned cycles for several modes of peck drill cycles, I think it is G82? You are at the point you need to seriously get into the EMC manuals, they are now getting quite good. There's also Chris Radek's "cheat sheet" with tons of info on a single page. He handed out laminated copies of it a few years ago.

Jon

• posted

Yes, I have no objection to that sort of stuff, like canned cycles. Next thing I will do is hook up the Z axis. Then I can do two things. One is writing and testing scripts, and another is servo tuning.

After this is done, I will try to get my mill's original controls to work.

i
• posted

That is good, I put something in like z22 in once on a AB8400 control. Watched the waterjet nozzle drive down into a visor hole in the waterjet buck. I managed to estop it in time to avoid damage. Z22 = Z .022 on that control. Whoops.

Wes

• posted

That is really intriguing, Jon. Can you tell me where I can download a copy?

Thanks!

--Winston

• posted

or, in PDF
and, soory, Jeff, I gave the wrong attribution, in the Wiki i see this was done by Jeff Epler, not Chris. (They work together, I have a lot of trouble keeping separate what they have done.)

So, this is linked to on the Wiki, but not real easy to find, under "Using EMC"

Jon

• posted

to estop it

This is scary and outright stupid, kind of shocking really.

On my system, G1 x2 means go to X=2.

i
• posted

Much appreciated. Thanks!

--Winston

• posted

to estop it

On that 80's era machine, with a whopping 64K of 8bit memory, things were cut to the bone.

Since I was profiling headliners, the programs tended to be big. I wrote a couple qbasic programs to take the g and m code and strip out any .0's and replace with ., Z7.421 became X7.42 .

I also looked to see, since the profiles were taught in following a sample with a pointer in the nozzle, for any move where an element of a previous move matched the current position.

For example if one point was X120.2 Y34.1 Z12. and the next one was X120.9 Y34.7 Z12. I changed it to X120.9 Y34.7

Back when working light without overbyte mattered. Life is so much easier now.

Wes

• posted

managed to estop it

to the bone.

Sounds like my Emco-Maier Compact-5/CNC. Stepper motors, 5" swing. Quite slow rapids. And the CPU was a 6502 (Apple-II/Commodore PET anyone?). The 64K address space had to hold the firmware, the RAM for program storage and stack, and the various I/O ports.

Decimal point was implied -- a different place in inch vs metric mode.

25.4 mm was entered as "2540", and 0.001" was entered as "1", so 1" was entered as 1000". (And for Y-axis, since it accepted input in diameter not radius, but was sill limited in step size, diameters came out in steps of 0.002" or 0.02mm.)

Also -- because there was so little memory, there was no provision for comments.

I wrote a pair of programs in C which would copy from the machine to the companion Sun computer and back which would end each line with a '#' (comment symbol) on the way from the machine (so I could edit in comments safely) and strip off everything including and following the '#' on the way back to the machine.

The system did not have the ability to accept axis indicators in the G-code -- it was purely dependent on the column in which the numeric data *ended* -- with leading zeros suppressed and replaced with spaces. Lose one space and the meaning of *everything* in the remainder of the line changed. :-)

But -- I'm still using this machine for certain things. It is nice and small -- and it *is* CNC.

[ ... ]

Now there is a quote from the early days of _Dr. Dobb's Journal_. :-)

• posted

to estop it

I'm guessing his machine was actually controlled by an A-B 7320, their last control that suppressed decimal points. That is an accepted option to the RS274-D standard that defines "G code". I still have my 7320, but made the change to EMC about 12 years ago. I'm pretty sure the 8400 supported decomal points, but maybe they turned that off for compatibility with other machines. But, it did lead to unpleasant surprises.

Jon

• posted

managed to estop it

You used EMC 12 years ago, OH MY GOD!

i
• posted

I use macros all the time in AVR programming. Functions too, but the macros get handled by the preprocessor and turn readable code into bit- shifts and masks.

• posted

I think you're going down the right path having prepackaged functions will probably go a long way towards fewer busted tools.

This reminds me of a project that I did years ago that's actually close to being the opposite of what you're doing. My job was to take Gerber code (a subset of 274D) that was meant for photoplotters and convert it to outlines of printed circuit board traces to be plotted on an HP pen plotter.

Once I got the basic shapes done, the rest was pretty straightforward and saved a LOT of plotting time. Of course, now I just print to the

36" inkjet...

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.