Repeating G-Code

I’ve been working on a setup to repeated drill holes in set locations on plastic tubes. I’ve got a jig to hold the tubes in place and the code is working great the only problem is with Carbide Motion I have to reopen the file each time I want to run it. This process will be repeated hundreds of times and I am wondering if there is a simple way to get the code to loop with a pause at the end of each cycle? Ideally the program will run, pause so the operator can reload a set of new tubes and then hit play again to reset the code and cycle through again. Any help would be greatly appreciated!

1 Like

@groepsch, Carbide Motion supports M0 stop, which will pause the gcode until you hit the start button again. I used this in my motion testing, where I ran several out-and-back cycles and then paused to read the dial indicator.

I don’t know if CM supports line numbering and GOTO. That would be the other thing you need. You’d just do something like

N100 (start of program)
gcode line
gcode line
gcode line
. . .
gcode line
M0
GOTO 100

You could hit “start” at the M0 line if you wanted to repeat the operation, or hit “stop” when you were tired of drilling holes.

BTW that’s a nicely lit up enclosure! :slight_smile:

Randy

Hi,

I just started reading up on CNCs and codes. @Randy could probably correct me, but maybe an M30 code would work for this type of thing?

yours,

The G code standard supports subroutines and canned cycles. Perfect for multiple, identical parts separated by position. Set location, call subroutine, set location…

This is done via M98/M99 (call/return) and the G54… G59 commands. Alas, looking at the GRBL supported G codes I don’t see that they support these. One would also need a CAM program that know how to generate such things - or hand edit.

Hand editing and tweaking using MeshCAM output is definitely possible. @Randy has that covered.

mark

P.S.

The safety standards for commercial machines forbid using delays. They must formally stop and wait for an acknowledgement. Some systems require double acknowledgement - some of them require a mechanical release, then the “continue”.

@aderienzo, the M30 acts the same as an M2 - CM dumps the program and you need to reload it.

I always use M30 to end my gcodes, but these days M2 and M30 are essentially identical. In the earlier days of physical punched tape to store programs, M2 would end the program but not rewind the tape. M30 would end the program and also rewind the tape. It would be pretty cool if M30 ended the program and ejected the thumbdrive…

I’m at lunch hour at work now but I’ll try the GOTO this evening. Looping is moot since CM doesn’t accept G54 coordinate system shifting…

Randy

There is a CM-supported gcode list here on the Carbide website but here is a copy that I’ve annonated

G0 - rapid motion
G1 - linear motion
G2 - CW arc
G3 - CCW arc
G4 - dwell (time in seconds)

G17 - X-Y plane selection (for arcs)
G18 - X-Z plane selection
G19 - Y-Z plane selection

G20 - inch coordinates
G21 - mm coordinates

G28 - return to home

G28.2 (Run homing cycle)

G40 (Accepted but ignored) - cancel tool radius compensation
G43 (Accepted but ignored) - tool height offset
G49 (Accepted but ignored) - cancel tool height offset

G54-G59 (Accepted but ignored) - work coordinate systems

G90 - absolute coordinates
G91 - relative coordinates
G91.1 - relative I,J coordinates for G2, G3

M0 - stop (press start to resume)
M1 - optional stop
M2 - end program
M3 - spindle on CW
M5 - spindle off
M6 - tool change
M7, M9 (Accepted but ignored) - coolant on and off
M30 - end program and rewind

Thanks for all the replies! I’m currently ending with a M30 and had the same thought process, thinking that I could restart after that but learned the hard way it wasn’t possible. I’ll start playing with the GOTO function as that seems the best route. I also came across a thread attempting to use a M98 to create a loop but didn’t have any luck running it through Carbide.

There are some pre-processors / programming options which might be well-suited to this sort of thing: http://www.shapeoko.com/wiki/index.php/Programmatic_G-Code_Generators

No joy. I ran the little program

N100
g0 x50.
g0 x0.
g0 x50.
g0 x0.
g0 x50.
g0 x0.
g0 x50.
g0 x0.
g0 x50.
g0 x0.
g0 x50.
g0 x0.
g0 x50.
g0 x0.
g0 x50.
g0 x0.
g0 x50.
g0 x0.
g0 x50.
g0 x0.
M0
GOTO 100
M30

When it got to the M0 it said “Press Start to continue” or words to that effect (I already knew that part worked), it executed the M30 without going back to the beginning.

So without some more GRBL gcode support it doesn’t look like looping is an option yet… :pensive:

Randy

Have you tried the old school ‘Copy-Paste’ in your g-code? It would be crude & inefficient in terms of code, but you could run the same process several times without restarting, no?

Jim

1 Like

That will work… but one has to know enough G code to remove the prolog and epilog sequences - one only wants one prolog (at the start of the job) and one epilog (at the end).

mark

Unfortunately the copy and paste method is what I had to resort to as I couldn’t find a better way to make this program work. I simply used a pause in between and kept my initial start commands at the beginning and stop command at the end. For a process that needs to occur 300-400 times this will work alright but is not a very elegant solution.

Yup, not very nice.

This is why they add subroutines to the G code specification. We can ask for support of G54 and friends and subroutines.

mark

FWIW, I thought about adding macros and subroutines to Grbl, but decided against it for the moment. The main problem is that if you stay true to the g-code macro programming language, you have to process the entire g-code program at once to catch these GOTO’s and loops. With a streaming protocol, you can’t directly do that.

So, Grbl’s options are limited to having the GUI convert the macros into straight g-code before sending to Grbl, or have Grbl do it with some strange communication protocol to stream certain sets of line on demand or have direct access to the file itself.

The end decision was that modern programming languages are MUCH more powerful than g-code macro programming. It’s possible to have a simple Python program to pre-process things like this with greater flexibility and not being that much harder to program. If I ever do get the time, I was planning on writing a pre-processor for macro translation, but I don’t foresee the time ever becoming available.

FWIW, there are a number of programming utilities and front-ends: http://www.shapeoko.com/wiki/index.php/Programmatic_G-Code_Generators

I’ve often thought it would be nice to have a front-end or comm/control program which would implement the balance of the G-code step which Grbl doesn’t, but given the capabilities of the various free options, not likely to see that happen.