How can we save cycle time with Sub Programs?

[Heinz R. Putz]

Using subs is a convenient way for a programmer to save programming time, but how can we use it to save actual cycle time?
I have some ideas that I developed over the years and used as part of my training jobs, especially for higher volume lot runs.
Think about it and tell everyone some of your methods and ideas, I am sure that a lot of shops could benefit from being more efficient by reducing their cycle time.
I am talking mills now, lathes would be a pleasant surprise if you could do it.
Heinz.
www.doccnc.com

[DigiSnapMark]

If you have to perform an operation, it's irrelavent whether the code for the operation is in a main-line code, or subroutine. What am I missing?

[mrainey]

In applications programming, extensive use of subroutines can sometimes decrease performance.

[Rstewart]

I guess I'm somewhat with Digi on this one....

Now, I'm definately not going against Heinz all together because he is a top notch programer with more experience than I'll probably ever get.
I mostly program with CAM, which I cannot see alot of saved cycle time using subs (unless I'm missing something).
If you are just coding at the machine subs can be a Great time saver to get the part running.

This is just for mills, considering I have almost zero experience with Lathes. If you have alot of data stored in the machine and running low on memory subs can be a good way to shorten programs.

Someone enlighten me if there is something major i am missing....

[PixMan]

Originally Posted by mrainey

In applications programming, extensive use of subroutines can sometimes decrease performance.

Absolutely. This is especially critical on short-cycle lathe programs. All of the swiss-style lathes I've been working on for the last 18 years or so use them for "safety cutoff" and certain tool calls. When used for calling tools, it's usually written to check slide positions and prevent mechanical crashes.

When the machines have very minimal cycle times for a simple part, these subs can be the main reason and old Brown & Sharpe or other cam-operated screw machine will beat the pants off a $250,000 CNC machine. I've learned to take them out for the really short cycle parts.

[The Energy Rebel]

Originally Posted by Heinz R. Putz

Using subs is a convenient way for a programmer to save programming time, but how can we use it to save actual cycle time?
I have some ideas that I developed over the years and used as part of my training jobs, especially for higher volume lot runs.
Think about it and tell everyone some of your methods and ideas, I am sure that a lot of shops could benefit from being more efficient by reducing their cycle time.
I am talking mills now, lathes would be a pleasant surprise if you could do it.
Heinz.
www.doccnc.com

I'm not saying you're wrong, just that I would have to see it to believe it.
As someone who learned everything about machining backwards and the hard way, there is something to listening to how the "old school" guys do it.
I learned how to program before I learned how to run CNCs.
After running them, I had to go back and apologize to the people I had made programs for.
Subroutines are easier and faster for the programmer - not so much for the guy who breaks a drill or E/M in the middle of a 100 pocket part and has to go back and skip half the pockets and pick up where he broke it.
Yes, there are ways to do it, I'm just not sure that it decreases cycle time.
I've found that I can write a more efficient "canned cycle" than the machine manufacturer can, though.
Is this, perhaps, what you mean?
If so, then I concede your point.

The 2 examples that come to mind are deep hole peck drilling (mills and lathes) where you either retract all the way back to the original "R" plane or just a minimal amount that won't allow you to clear the chips.
So I modify it after seeing where it gets the most "clogged" and try to make it faster without making cycle time too long.
Same principle when boring a 16 finish and any "bird's nest" will ruin it.

The other is mill pockets that start the tool path perpendicular to the wall of pocket instead of going in tangent or at least at 45* into the corners. That wouldn't necessarily change much cycle time but it would improve quality of part and possibly cut down finishing or secondary ops.

[doug6949]

Originally Posted by mrainey

In applications programming, extensive use of subroutines can sometimes decrease performance.

This would particularly be the case with older (and some not-so-old) controls where the Gcode parser is slow. Control builders are notoriously conservative when adopting new technologies.

[706jim]

Subs are cool to show off how you can do something complicated with "so little code". However, they are NOT great (mentioned previously here) when you have to restart a program part way through.

And that DOES happen on occasion.

Also, with memory capacity up and cost down, there are fewer programs to "manage"with a single program as compared to a group of subs.

[psychomill]

OK... I'm with most of the consensus here... I don't see how a sub can save time in the 2 minutes I've actually thought about here. However....

There is one way a subprogram can save time and that's only if it replaces a canned cycle. Most people that are knee deep in control logic and processing functions know that in a canned cycle, there is a very small and momentary "lag" for the machine/control to switch modes of the cut. This is most noticeable in the switch between Feed and Rapid mode... the machine having to "shift gears" if you will. For example, if you long hand code a drilling cycle by staying in constant Feed mode including positioning and avoid variable usage, the cycle time will be shorter (Note: Just program a very high feerate for positioning and replace any "rapid" out moves). Of course, this is only realized when you have a part with a high quantity of holes or a high quantity of "peck count" over several holes.

Lathes can show the same effect but only on large parts with tons of roughing passes or live tool machines with boat loads of hole drilling.

That's about as close as I can think of for the moment....

[BobWarfield]

I guess I can imagine reasons why a sub could save cycle time, but it's just that, imagination. Can't wait to hear Heinz tell us what he's got!

Meanwhile, I wonder if it doesn't boil down to something larger than simply does this big long bunch of g-code run slower than this code using subs?

For example, effective use of subs might minimize drip feeding for really long programs.

Another productivity thought is whether the right collection of subs might make the guy running the machine more effective. Let's say they give him "more powerful g-codes" to call up if he needs to in order to handle various options and differences on a job.

As I say, that's all imagination.

What is striking are the comments about the older controls limitations running subs. There hasn't been a good excuse for that for a long time in the end of the computer world where I work. Certainly not in the last 20 years. Controls that still have that pain that are newer than that are obviously not very new under the covers!

Cheers,

BW

G-Wizard Machinist's Calculator: http://www.cnccookbook.com/CCGWizard.html

[SIM]

I have only found "subs" to save time when Writing or Tweaking programs that run multiple parts or multiple operations at once. You modify the operation once, in one location and its done.

A lathe I'll write a sub and loop it to run multiple parts...Bar Puller style.

The down side of SubS is having to start from the beginning at times.



Now on the other hand I have Coded Long Hand in certain operations where I did not like the Canned Cycles. Such as deep hole drilling a block, the Canned cycle would not start out with a deep enough peck, then towards the end it was too much of a peck and I did not always need a Full Retract, but yet sometimes it was required. So I found what worked and coded the cycle as needed then tossed it into a "Sub" and called at various locations. Here it's not the Sub that saving the time but the Long Hand Code.

Another example I used today, a reaming cycle. The canned cycle feeds in and out at the same rate, I find I can really goose the reamer on the retract saving a good deal of time, so I Long Hand Coded it that way, tossed it into a sub and call it several times.

[doug6949]

Originally Posted by BobWarfield

Controls that still have that pain that are newer than that are obviously not very new under the covers!

That was my point.

Originally Posted by SIM

Now on the other hand I have Coded Long Hand in certain operations where I did not like the Canned Cycles. Such as deep hole drilling a block, the Canned cycle would not start out with a deep enough peck, then towards the end it was too much of a peck and I did not always need a Full Retract, but yet sometimes it was required.

Some controls provide options for decreasing peck distance in G83. I find this extremely valuable. If I were running a machine without it I would prefer a sub over G83 for many deep holes.

[Boris]

Since I'm fairly experienced at this CNC programing lark

I use subprograms all the time although in highandpain(heidenhain) language they are called labels
Why do I write them? for 2 reasons mostly
1. I'm a write once kind of person, why bother writing out the same code 3 times for a tapped hole pattern when you can do it once and call 3 times
2. Ease of modification. if I need to move 1 hole slightly in the above pattern, then I do it once and its over, if my appentice has mod the program he can follow the code and note "oh its in a subprogram.... mod it once"

Eg I use a tool touch probe for measuring tools, and its used for checking tools while the machine is running(ever tried doing a 16mm counter bore on a broken M10 tap )
But the machines tool check cycle only moves at a maximum of 5000mm/min on rapid approach to the checking start point.
So I program
L X-200 Y+260 FMAX M9 ; Round abouts where the probe is bolted to the table
TCH PROBE 481 CAL. TOOL LENGTH ~
Q340=+1 ;CHECK ~
Q260=+100 ;CLEARANCE HEIGHT ~
Q341=+0 ;PROBING THE TEETH

But by enclosing the above in its own label
eg
LBL "TCHECK"
(above code)
LBL 0

then a simple LBL CALL "TCHECK" just before each tool change means it will pick up a broken tool before it causes too much damage.
And the advange being if I put the job up again, then I only need to tweak one bit of code to get the rapid move to the right place.

I have used sub programs in the past as custom cycle calls perhaps for drilling some 1" pipe and did'nt want the tool feeding in the fresh air too much, or a custom solid die grinding program where it was simpler for the setter to type in the size of slot the wanted and for the program to do the rest rather than re-post the entire program.
eg
N10 #500=54.05
N20 #501=12.15
N30 M98 P2010
Makes more sense than generating a 1 meg program and running it via DNC when the the night shift is in and the computers are locked in the offices....

Anyways time for my post work bath

Boris

[Ron A]

I sometimes see a slow down using sub programs and even more of a slow down when we use logic. Subs work well for saving programming time but that's about it.

[barbter]

Originally Posted by psychomill

For example, if you long hand code a drilling cycle by staying in constant Feed mode including positioning and avoid variable usage, the cycle time will be shorter (Note: Just program a very high feerate for positioning and replace any "rapid" out moves). Of course, this is only realized when you have a part with a high quantity of holes or a high quantity of "peck count" over several holes.

Psycho,
I tried this once for a guy doing a college course.
It was on a leadwell v25H (Fanuc 21M) and we replaced all rapid moves with F10000 (Max feed rate).
The leadwell had 20m rapids, so by running it at 50% rapid against 100% feed, the rate was still 10000 (10m/min).
It was a 100 holes and the rapid came out 10% faster...

[barbter]

oh and back to the original post!

Macro programming I dislike. Purely because if you lined up 100 cnc programmers/operators, 1 might know a bit about it.
So when you're trying to decipher a program, I think it's best to talk in the language that people understand...
Also, one of our customers uses them all the time for high volume production work.
And the machine will stand for a second or more doing nothing, while the program scans back to the start to read the #variabe value for a feed, and then scan back down again before it gets going.
So that's got to be longer then.

Subs are great.
Depth of cuts easy peasy to get the best out of the job by editing on the machine.
Re-starting is ok providing you start at that tool, and it has all the cancel codes/datum etc in the line. ie safe.

But for the life of me I can't see how it's quicker from a processing point of view???

[Boris]

Originally Posted by barbter

But for the life of me I can't see how it's quicker from a processing point of view???

I going to get a bit technical now and put on my software engineers head
The quickest code is whats called inline code, which is what most CAM systems spit out
Which we are all familier with.

However when you start introducing sub programs and variables you start slowing things down a lot.

The sequence of instructions called by the control when it encounters an M98 command go something like this

Retrieve current program counter (it tracks which line of code is currently being executed)
Add 1 to the counter so it points to the next line after the M98
Push the counter to the call stack
load the program counter with the address of the M98 call eg P0010 line 0
Start executing the program

when the subprogram ends with the M99
the control gets the previous address from the call stack, loads the program counter and resumes execution

All of which take far more time than just reading a bunch of X+10 Y-10 type intructions.

Reading of variables takes a shorter amount of time but still takes longer because the control has to fetch the value from the variable memory.
Doing some maths on the variable takes even more time which is why wherever possible I tend to write variable programs to do the maths while the cutter not cutting, but in certain cases eg engraving round characters on cylindrical stuff, then the control has to calculate the next position while cutting.
Hint : try calculating the movement to inscribe a 3.5 mm dia circle on a 52 dia bar. then do it 360 times for the cutter path in X and A.

Thinking about the G1 F10000 command instead of G00 though, and I have tried it and did give up on it
The reason being the mechanical performance of the machine involved
The G00 has a defined accel/decell rate curve that the control puts in to give the motors the easiest time moving a big heavy lump of iron around, but the G01 says "I want that feed rate right now" and just bangs in the power to get the table moving at the required feed rate.
Its a bit like using the clutch on a car to change gears and not using it.
which is why after a brief experiment I went back to using G00.... that and it only saved 3 seconds on a multistage drilling fixture.

Boris Dip.Comp(Open) Bsc(Hons)(Open)(dropped out)

Here endth the lesson...and I can resume non serious mode

[Hdpg]

Originally Posted by Heinz R. Putz

Using subs is a convenient way for a programmer to save programming time, but how can we use it to save actual cycle time?......

I use subs to save cycle time by fixturing several parts each with their own work zero and writing the program as a sequence of tool specific subroutines; select the work zero and call the sub for each part sequentially. The time saving derives from dividing the tool change time over several parts.

[barbter]

Nice bath Boris?

[Ox]

Also, one of our customers uses them all the time for high volume production work.
And the machine will stand for a second or more doing nothing, while the program scans back to the start to read the #variabe value for a feed, and then scan back down again before it gets going.
So that's got to be longer then.

I have a Seimens 810 that I on when I see it sit there "thinking". I am not one to use many canned cycles and that "ShopMill" software is all variables. I see it think about simple stuff too. ???

I run one part on a Fanuc 18 that spends an awfull lotta time in and outta sub (X20 per part) and I see absolutely no pause in the motion at all. It is [semi] deep hole drilling all in G0 and G1. Again - no cycles. I dislike peck drilling cycles for the reasons posted above. I bet I aint used a canned peck cycle in 15 yrs.


-------------

Think Snow Eh!
Ox