PDA

View Full Version : Writing gcode....the easy way



Rif
01-25-2012, 02:58 PM
Hello,

Is there any program that simplifies the writing of gcode? I have some projects for which I'd rather not hand code the gcode. (I've done that.) However, the cheap CAD programs don't seem to be too useful and I am not going to pay for, nor require, a large cad-cam solution.

Basically, whatever it is needs to have the capability to handle the coordinates as variables, do loops, and execute subroutines. I am using Mach3 and discovered that it doesn't handle gcode loops. (I do understand that I can use VB scripts; but, would rather keep all of the code in the same file.)

i.e.

x = 5
y = 1
go

repeat 5
x = x + 0.5
cut
y = y - 1
cut
x = x + 0.5
cut
y = y + 1
cut
repeat end


I guess what I am really asking is: Is there a more modern way to write this stuff?


Thanks!

Brian

macona
01-25-2012, 04:40 PM
Some cnc machines have different implementations of motion control like Heidenhain. And others have loops and parametric. Mach does not and it is not a big deal.

Its not that hard to program by hand, just learn the codes. Gcod works very well and will not be replaced anytime soon.

And something like "cut" will never cut it, whats the depth, feed, rpm?

Best thing is to just buy a cheap cam package and go with that. I almost never program by hand. Just not worth it and infinitely greater chance of a screw up.

If you deal with the guys at bobcad you can get their package for around $300. It not terrible but not the greatest. There is also Cut2D which can do almost all basic mill ops.

djc
01-25-2012, 04:51 PM
Is there any program that simplifies the writing of gcode?... the cheap CAD programs don't seem to be too useful

An intermediate step is to draw your tool centreline path in CAD and save as a dxf. Google will show you lots of dxf to G code convertors (e.g. Ace convertor by DAK Engineering, makers of TurboCNC).

TurboCNC handles parametric stuff and loops but is clearly not as fancy as Mach.

Rif
01-25-2012, 04:54 PM
Hello,

I know I missed a lot with an example. (Spindle speed, spindle direction, coolant, tool offsets, etc.) But, I was just wondering if there is anything more modern and through that out there to see if anybody would look at it and say "hey I've seen something that works similar to that."

I don't have a problem writing code (i.e. gcode) as I was a software engineer at my former job. It's just that the job, that I need to get done, needs a lot of repetitious features and I'd rather not have to hand-code all of them. On the other hand, while I would purchase the software if it was required, I'd rather not purchase a complete CAD-CAM solution. I was just wondering if there is an "intermediate coding solution", of some sort.

I'll have to checkout the Cut2d and see if that would meet my requirements.

Thanks,

Brian

macona
01-25-2012, 04:58 PM
Its not uncommon for software engineers to see g-code and say "gee, this could be better"

Read this thread over on PM:

http://www.practicalmachinist.com/vb/cnc-machining/innovation-needed-cnc-178059/

Rif
01-25-2012, 06:07 PM
Hello,

Reading through some of that thread I can understand the sentiment. Between the concept of "if it's not broken, it doesn't need fixed" (which I agree with in many cases) and the lousy reputation computer programmers have earned, via all of the bad code out there, it is understandable.

I was just thinking along the lines of a program that creates gcode from an easier to use language as opposed to writing raw gcode. (The resulting gcode could always be edited of course.) If you can generate gcode from a CAD drawing wouldn't it be useful to generate gcode from an easier to use language as well? I was not thinking about having the machine automatically measure tool offsets, having colorful user interfaces, etc.

One analogy, that I would think is pretty accurate is to state that web pages can be written in assembly language. However, nobody would use such a language as, among other reasons, it is very difficult to understand.

On the subject of programming languages, if possible, a language is considered a tool and selected as it is the best tool for the job. (Company politics may disagree.) In this case, gcode has been the best tool for the job and I am not suggesting that it be changed.

Regards,

Brian





Its not uncommon for software engineers to see g-code and say "gee, this could be better"

Read this thread over on PM:

http://www.practicalmachinist.com/vb/cnc-machining/innovation-needed-cnc-178059/

macona
01-26-2012, 12:16 AM
I rarely even look at the Gcode so it really does not matter. I don't personally know anyone who write more than a few lines in gcode for something simple like drilling holes.

Using cam means I don't need to think about arcs or stuff like tool diameter compensation. And it a whole lot more than just converting a drawing to gcode, there is a lot to think about like where you might want to remove material first and things like to use a pocket tool path or contour.

I used one of the wizards in Mach tonight and it does look like there is a loop command and there are subroutines. "L" and the number of time to do it. I just found a little here:

http://www.cnczone.com/forums/mach_software_artsoft_software/43211-loop_mach_3_question_help.html

Its just something I never do...

Tony Wells
01-26-2012, 01:01 AM
Up until we hired a guy with MasterCam experience, one outfit I worked for used exclusively G-Zero, by Rapid Output. Thousands of part numbers. I don't remember the cost, but I don't believe it was terribly expensive.

http://www.g-zero.com/

I'm no programmer, but I sat in with them a bit and wrote a few programs for lathe and mill. I didn't find it too intimidating. But I'm sure it has changed. That was about 1988-89.

moldmonkey
01-26-2012, 01:18 AM
I don't personally know anyone who write more than a few lines in gcode for something simple like drilling holes.

FWIW,I have only worked in one shop with CAM in 15 years. Currently, I'm running a Hurco but will still use Gcode for certain things. For everyday parts (3 axis or 3+, not full on 4 or 5 axis) writing G-code can be tedious but isn't difficult with experience with whatever control you are using.

For the OP, can you use Macros,? That is programming with variables. You can set-up macros to do rountine things like bolt-circles, mill circles, etc. It can be a very powerful tool. I have done things like engraving a sine wave or milling a profile with the corner of the endmill in the XZ plane. If so I highly recommend Peter Smids Macro book. It is written for Fanuc but the principles apply. I can't imagine a Gcode control that won't do loops and subroutines.

As far as taking some of the tedium out of long-hand G-coding, here are some things I do:

-write programs on Notepad on a computer and transfer to the machine. Programming at the control sucks.

-Use template programs. They are set-up with all the routine things. I copy the template and just have to change the geometry, tool number, etc. That way I don't have to type out all the stuff that doesn't change.

-Use copy & paste as much as possible. For example, I will write a block to spot all the drilled holes. Then I copy it for the drilling & tapping. It's just a matter of changing which G8_, speeds & feeds and z depths.

-Use subroutines. For profiling a part, the actual profile goes into the subroutine. Then all the roughing passes, the finish pass and chamfering call up the same sub. You just have to have the initial starting pointmove,d Zdepth moves, and subprogram call in the actual program. Copy & paste this as well and all you have do is change the Z. Same concept for mill circles.

-If you have helical interpolation, you can can use incremental mode and either a loop or subprogram to repeat all the passes with just a couple of lines. Just don't forget to change back to absolute.:o

Personally, the programming and set-up is the challenging & fun part. The rest of it is boring as hell.

John Stevenson
01-26-2012, 05:54 AM
I personally don't see the attraction nowadays in running sub routines.
OK years ago when you were limited to 999 lines of code or similar but with CAM and memory storage I can't see the point.

Very hard to understand where it is in a program and if you have to pause for any reason, broken tool ?, it's impossible to pick up from that point.

Also don't overlook Excel for writing the odd repetitious program, easy to get excel to work out formulae in columns away from the input parameters and a quick copy / paste into notepad gives you a working G Code.

Mach can understand formulae to generate a sub routine

#1=[30] ;BAR
#2=[15] ;PCD
#3=[10] ;PIN
#4=[18] ;Passes
#5=[0] ;A
#6=[1] ;Pass


G0 G21 G49 G40.1 G17 G64 G80 G50 G90 G98
M6 T1
M03 S4000
G00 G43 Z10.0
G00 A0.0 Y0.0 X5
M98 P003 Q#4
A0.00
M5 M9
M30

O003
#5=[0.0]
G00 Z2.0
G00 A0.0
#1002=[[#2/2]*SIN[#5]]
#1003=[[[#1/2]-[#2/2*COS[#5]+#3/2]]*[#6/#4]*-1]
G01 Y#1002 Z#1003 F100
M98 P004 Q358

This is a program [ don't run it - it's missing 7 lines due to copyright ] that machines a crankshaft by keeping the tool on centreline as a rotary axis [ A ] rotates and it co-ordinates Y and Z so it finishes up with an off set pin.

http://www.stevenson-engineers.co.uk/files/crank2.jpg

The first 6 lines set the parameters, just change them for a different crank.

moldmonkey
01-26-2012, 07:12 PM
I personally don't see the attraction nowadays in running sub routines.

I use them for repetitive things like running the same profile with different passes or running multiples of the same feature such as counterbores. For me it makes the program a lot shorter to write and easier to read. Nothing to do with memory. I am talking local subrountines contained in the program and specific to a feature.


Very hard to understand where it is in a program and if you have to pause for any reason, broken tool ?, it's impossible to pick up from that point.

:confused: I've never had a problem with restarting.

I guess everyone devolps their own style.

Rif
01-27-2012, 10:19 AM
Hello,

I too was wondering what the problem is with subroutines. From a programming perspective, subroutines are great. Once the subroutine has been written, tested, and debugged you can repeat that function just by calling it and don't have to worry about making a mistake typing a value in the subroutine.

Regards,

Brian

rowbare
01-27-2012, 10:21 AM
OP, you might want to check out D2NC http://www.d2nc.com/. It uses a simple shape description language to define paths etc... If it fits the way you think it can be very useful. It also does dxf import. It is fairly cheap as these things go and there is a 15 day free trial.

bob

macona
01-27-2012, 03:49 PM
Hello,

I too was wondering what the problem is with subroutines. From a programming perspective, subroutines are great. Once the subroutine has been written, tested, and debugged you can repeat that function just by calling it and don't have to worry about making a mistake typing a value in the subroutine.

Regards,

Brian

The problem with subroutines it say you have one that repeats 20 times doing part of a 3d contour. Something happens half way though and you have to stop the program. There is no way to start part way though a subroutine.

moldmonkey
01-27-2012, 11:15 PM
Maybe some of the disagreement is jargon differences. When I say subprogram I mean "normal"point to point programming.

This could be as simple as drilling a bunch of holes in tubing and not wanting to use G81 because you will be drilling a lot of air. Lets say 3/4"square, .063" wall with a 1/8 drill every inch:

...
g00 z.1
g00 x1. y-.375
m98 p1000
g00 x2. y-.375
m98 p1000
g00 x3. y-.375
m98 p1000
g00 41. y-.375
m98 p1000
...
m30
o1000
go1 z-.15 F5.
g01 z-.650 f200.
g01 z-.825 f5.
g00 z.1
m99

To relate this to the OP when I wrote all those location and call lines, I wrote them once and then copied & pasted and just had to edit the x location.

Any looping including stepping over like Macona's example or variables, I call a macro. And yes to start something like that over you have to start over or edit the program for a new start point and then edit it back to the original for the next part. Typically I would put this in the main program unless more than one tool was being used.