Subroutines with Path Pilot

The manual talks about putting subroutines in a separate file and there is a folder named Subroutines in the directory. Questions: since subs have to be defined ahead of the program, how do they need to be declared if they are in a separate file? Do the subroutines need to be in the same folder as the program, or does Path Pilot automatically look in the Subroutine folder?

I use subroutines in most programs, but have never had a machine set up for macros. Is calling a sub from another folder the same as a macro? I do production runs of engraving. When a program is set, it may run 500 to 2000 parts. There are sets of about 25 characters on each part and from run to run, some changes with part numbers, revisions, etc mean that there is occasional reprogramming. This has always meant going back to CAD and generating the Gcode for each run. I use 0 thru 9 and about 10 letters in the engravings. I'm thinking that I can do the Gcode subroutine for each character referenced to origin, then just do a G52X~Y~ and a sub call for each character. Once the programming is done the first time, any changes would be to simply change the character call.

OK, I found the answers so thought I'd post for others to learn. Thanks to Daniel Rogge at Tormach and Bob Yellin at Zbot for the help and explanations.
The test program is named o101 test.txt

G90
G0 X1. Y1.
o<101> call (must contain the <> symbols)
X2. Y2.
o<101> call
M30

Here's the subroutine:
The file name is 101.ngc. It must use the bracketed call name, have the .ngc extension and reside in the Subroutine folder.

o<101> sub

G91
G1 F30.
X.1
Y.1
X-.1
Y-.1
G90
o<101> endsub

Not complicated, but the syntax has to be exact. Now I can get on with reprogramming all my engraving jobs. One setup for each series of parts and any future changes in the engraving will be quick and easy!

Quote:

---

Originally Posted by dbren

The manual talks about putting subroutines in a separate file and there is a folder named Subroutines in the directory. Questions: since subs have to be defined ahead of the program, how do they need to be declared if they are in a separate file? Do the subroutines need to be in the same folder as the program, or does Path Pilot automatically look in the Subroutine folder?

I use subroutines in most programs, but have never had a machine set up for macros. Is calling a sub from another folder the same as a macro? I do production runs of engraving. When a program is set, it may run 500 to 2000 parts. There are sets of about 25 characters on each part and from run to run, some changes with part numbers, revisions, etc mean that there is occasional reprogramming. This has always meant going back to CAD and generating the Gcode for each run. I use 0 thru 9 and about 10 letters in the engravings. I'm thinking that I can do the Gcode subroutine for each character referenced to origin, then just do a G52X~Y~ and a sub call for each character. Once the programming is done the first time, any changes would be to simply change the character call.

---

Or you could pass the X, Y coordinates to the subroutine as arguments.
o<eng_A> call [1.5] [1.0]
o<eng_B> call [1.6] [1.0]
etc.
Or you could pass the size, the X, and the Y to the subroutine as arguments.
Or you could define global variables #<_engraveScale> to define the size and #<_engraveX>, #<_engraveY>, #<_engraveOrientation>
Then each of the engraving routines would modify engraveX and engraveY so that the next letter would be changed to the origin for the next letter.
If you want, engrageOrientation could be an angle. So you could engrave text on a diagonal. If you wanted you could have different variables to define letter orientation and line orientation. So you could have upright text that is written from top to bottom. Or sideways text that is written from top to bottom.

A neat thing about using global variables to maintain setup and state is that each letter (or glyph) can then be engraved with a single line of gcode.
o<UC_T> call
o<LC_e> call
o<LC_s> call
o<LC_t> call
The above engraves the word "Test" in whatever size, orientation, line direction, font, ... (you can have a font variable if you want)


-- Note -- I'm assuming that Path Pilot supports all of the subroutine and variable functionality that is in LinuxCNC.

-- I don't run Path Pilot, but I am the guy that "invented" the subroutines and variables for LinuxCNC.

Regards,

Ken

Quote:

---

Originally Posted by lerman

-- I don't run Path Pilot, but I am the guy that "invented" the subroutines and variables for LinuxCNC.

Regards,

Ken

---

Always nice to get info on a subject from the root!
:)

Thanks so much for the information lerman.

I would like to get more familiar with using subroutines in my programs so this is great information.

I want to double the thanks! Your post was super helpful. Although, with parenthesis being the comment identifier, sub-routines with parameters become a little awkward from every other language =)

I am definitely going to look into subroutines in order to do things like automated consecutive serial numbers! The control structure (looping / conditionals) in LinuxCNC looks pretty nice too.

Quote:

---

Originally Posted by lerman

Or you could pass the X, Y coordinates to the subroutine as arguments.
o<eng_A> call [1.5] [1.0]
o<eng_B> call [1.6] [1.0]
etc.
Or you could pass the size, the X, and the Y to the subroutine as arguments.
Or you could define global variables #<_engraveScale> to define the size and #<_engraveX>, #<_engraveY>, #<_engraveOrientation>
Then each of the engraving routines would modify engraveX and engraveY so that the next letter would be changed to the origin for the next letter.
If you want, engrageOrientation could be an angle. So you could engrave text on a diagonal. If you wanted you could have different variables to define letter orientation and line orientation. So you could have upright text that is written from top to bottom. Or sideways text that is written from top to bottom.

A neat thing about using global variables to maintain setup and state is that each letter (or glyph) can then be engraved with a single line of gcode.
o<UC_T> call
o<LC_e> call
o<LC_s> call
o<LC_t> call
The above engraves the word "Test" in whatever size, orientation, line direction, font, ... (you can have a font variable if you want)


-- Note -- I'm assuming that Path Pilot supports all of the subroutine and variable functionality that is in LinuxCNC.

-- I don't run Path Pilot, but I am the guy that "invented" the subroutines and variables for LinuxCNC.

Regards,

Ken

---

How do you actually declare the values that you pass into a subroutine as arguments? Say I wanted to pass a parameter like feed rate into a subroutine. From my understanding, I could declare it in the main program as:

#<1>= 20 (set parameter 1 to a value of 20)

o<some_function> call [#<1>] (pass the value into function. Alternative, I could have just written [20] )

What would my subroutine for this look like if I wanted to use that value?

o<some_function> sub

G01 x2 F<#1>
...
o<some_function> endsub

When I try it this way, I get an error message saying I need to declare the variable. I've tried lots of different combinations and still haven't gotten it.

I put some code together to demonstrate a couple of options. This should give you some pointers.
See also linuxcnc.org_docs_subroutine-parameters

The g-code:

Code:

---

%
OTestTriangle

N10 (TurboStep example: move along a triangular path across the x axis)
N20 G90 G54 G64 G50 G17 G40 G80 G49
N30 G21 (Metric)
N40 #<feed_rate> = 300 ; to demonstrate passing a local parameter
N50 o<test_triangle>call[5][10][#<feed_rate>]
N60 o<test_triangle>call[5][10][#<feed_rate>]
N70 o<test_triangle>call[5][10][#<feed_rate>]
N80 o<test_triangle>call[5][10][#<feed_rate>]
N90 o<test_triangle>call[5][10][#<feed_rate>]
N100 M30
%

---

and the subroutine:

Code:

---

o<test_triangle> sub
; test_triangle.ngc move along a triangular path across the x axis
; input parameters:
;  #1        = step size in X direction
;  #2        = step size in Y direction
;  #3        = required feed rate

; save initial Y position for later use
#<yStart> = #<_y>

; first move
;  #_x = global system parameter representing the current X position
;  #_y = global system parameter representing the current Y position
G1 X[#<_x> + #1] Y[#<_y> + #2] F[#3]

; continue to step in X but return Y to original value
X[#<_x> + #1] Y[#<yStart>]

o<test_triangle> endsub

---

Some of the square brackets aren't strictly necessary but we regard them to be good practice when programming Unix scripts so I like to use them here too.
Step

Say I just want to run a specific number of parts, is that done the same way? I have a bar puller on my lathe now and figure I can get 22 parts out of the half bars I will use. I need it to start over from the top completely. Not just like a bar pull routine. I just need the program to loop a specific amount of times.
Thanks.

Take a look at the repeat control structures:

O Codes

You should be able to define a repeat (bounded loop) construct around your code and have it look any number of times. You probably don't necessarily need a subroutine as they are more for a set of code you want to repeat, perhaps with different parameters (ie: Drill a hole and a given position that you are going to call 50x throughout a program).

Edit: I haven't tested any of this with PathPilot, but it is straight from the LCNC docs. I will try to test out some of this stuff later today and report back.

Thanks a bunch for the help.
Sometimes to do the simple things is not very simple when it really should be. Engraving single line text in SolidWorks and Fusion 360 both involve convoluted work arounds. Both handle normal text with ease. Just not single line stuff. ;)

I just checked it out. This time it is that simple. I put

o103 repeat [22]

right under the date at the top of the G code.
Then

o103 endrepeat

at the end right before M30.

Now I did not have a full bar in there for the full 22 count. Does the repeat code need to be after M30 to keep track of the counts?
Hmm. Where can I see on screen how many cycles it has ran?
That may be a good addition to the lathe module for Path Pilot.

After a few tries, it works like I mentioned above. It stops after the requested amount of cycles. I initially had it set to 22 cycles on a full bar. I stopped it often though to optimize the G code. It seemed to loose track of counts. So let it ride. If not, keep an eye on it. Exactly what I was wanting though. Thanks.

Awesome! Thanks for reporting back so we know that it works in PathPilot.

If you need to change the amount of cycles, it certainly could not be easier either. It is in brackets right at the top of the G code. :)

Here is a little video showing it run.

https://www.youtube.com/watch?v=FFaejP7vqjk

Very nice! Are you using Tormach's prototype automated collet closer or something home-brewed?

Edit: Nevermind, I see your Youtube video on the closer. Again, nice work =)

It's one I figured out using parts from Automation Direct and McMaster Carr.
It starts at post #46 in this thread.
http://www.cnczone.com/forums/tormac...tormach-2.html

Well done!
Looks like it works pretty good. Nice to read and follow the setup of a well accessorized lathe system.
Thanks for posting!

Quote:

---

Originally Posted by TurboStep

I put some code together to demonstrate a couple of options. This should give you some pointers.
See also linuxcnc.org_docs_subroutine-parameters

The g-code:

Code:

---

%
OTestTriangle

N10 (TurboStep example: move along a triangular path across the x axis)
N20 G90 G54 G64 G50 G17 G40 G80 G49
N30 G21 (Metric)
N40 #<feed_rate> = 300 ; to demonstrate passing a local parameter
N50 o<test_triangle>call[5][10][#<feed_rate>]
N60 o<test_triangle>call[5][10][#<feed_rate>]
N70 o<test_triangle>call[5][10][#<feed_rate>]
N80 o<test_triangle>call[5][10][#<feed_rate>]
N90 o<test_triangle>call[5][10][#<feed_rate>]
N100 M30
%

---

and the subroutine:

Code:

---

o<test_triangle> sub
; test_triangle.ngc move along a triangular path across the x axis
; input parameters:
;  #1        = step size in X direction
;  #2        = step size in Y direction
;  #3        = required feed rate

; save initial Y position for later use
#<yStart> = #<_y>

; first move
;  #_x = global system parameter representing the current X position
;  #_y = global system parameter representing the current Y position
G1 X[#<_x> + #1] Y[#<_y> + #2] F[#3]

; continue to step in X but return Y to original value
X[#<_x> + #1] Y[#<yStart>]

o<test_triangle> endsub

---

Some of the square brackets aren't strictly necessary but we regard them to be good practice when programming Unix scripts so I like to use them here too.
Step

---

Thanks so much. Works perfectly.