Agreed. We have fixtures, optimized code, and some dedicated tooling for our repeat work.

Well done, Heinz. It was a fair test indeed.

These are not problems with the English language nor trick questions, they are problems with our assumptions. I'm a software engineer by trade, and this is the biggest pitfall. You assume the problem is one thing and that assumption prevents you from seeing a much better other thing. Always try to get out of the box.

I suspected something like this was coming up when I wrote:

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.

Cheers,

BW

G-Wizard: http://www.cnccookbook.com/CCGWizard.html

You have to read the rest of it.

"The first key is keeping the spindle cutting, Once that's mastered then its worth searching for seconds on your program.
Edit/Delete Message"

Most do prototype work and its just not worth spending an hour extra on a program thats going to run for an hour. Its more important to get it on the machine and make chips. While the spinde is running you can watch your program and see where you can cut time off of it. take notes and adjust accordingly. This is assuming you will be making more widgets. Plunge rates and air cutting waste more time than 15 seconds (5 extra) tool changes. Most don't catch the air cutting on the first go around. YMMV..

We do some prototype and some production. I spend allot of time on the production side setting up the horizontal with very efficient tooling/fixtures. Today i start running a program that i have been working on for a month. Cycle time will be 6 hours with both pallets. I guarantee the first time i run it i will find a few things that i can do to make it more efficient.

Now that we're all reading the same book....

Yes, you would assume... just the same as most others and myself would as well. It's problamatic on ultra fast controllers or ones with an extreme amount of look ahead. It could related to how these "fast controllers" are built up on the hardware to work with the imbedded logic. I can't say that I've seen it happen with straight code.. no matter how tightly crunched the code is or subs and jumps (internal or external M98 related). But a macro is something else. The best way I can describe it is this: straight code can be "mapped" completely. It's not conditional therefore, the road you're shown is the road you take to the machine. This requires very little processing by perspective. Macros however are always conditional. In otherwords, you might see a clear path, but there are many road signs that become possible other paths as well. But, you don't have to deal or see those signs until you get to it. Well, neither does the controller. And when you have some guy by behind you named "Look ahead" always pushing on you, at some point, you might trip. I realize this is a "human" trait but the logic does the same thing. Specifically "why" I'm not sure without spending time mapping the logic through the hardware. I just know what I need to do to get it back on track.

IMO, the overlays added on by MTBs will seemingly make this problem more apparent. Like they're overclocking something that really can't take it. But I've had the same issues with straight up FANUC machines as well (for example Robodrill). Other controllers do this as well... Mitsubishi, Yasnac, Siemens... whatever... But I wouldn't necessarily see this as a cause for worry. The majority of macros will never see a problem. It's generally associated with extreme number crunching, deep nesting and vast branches. (Although I did write a short counter logic for a 310i that needed a dwell). Argument II also can have some problems on internal branching as it gets "complicated".

Depends on what other demands you have on your time.

I do not understand this.

If I save time on one job then I can do more jobs in the same length of time.

If I don't have any other jobs to do then I can use the time I save to get out and hustle for more work.

And if I don't want to do other jobs or hustle I can spend the time I save playing golf.

If you have one machinist/programmer for each machine then yes take an extra hour to save a couple mins per piece even if its only a short run,,But if the programmer is the bottleneck and a machine has to sit idle while tweeking the program for another machine then its not always the best way to spend your time,,

Only one here thinks beyond the one man / one machine / always manned concept...



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

Think Snow Eh!
Ox

Folks, on general purpose CPUs (which modern controllers seem to have inside) deciding whether to unroll inline, or to loop tightly, has become a complicated question driven by things like processor look-ahead units, look-back caches, parallel execution, parallel retirement (won't see THAT on your mill anytime soon) and so on.

CNC controllers seem to be mostly very far behind, at least in how they treat G-code (which is hard problem) and so figuring out whether interpretation is faster or slower when code is rolled-up or unrolled requires a per machine experiment.

Of course, ideally, the controller should be so fast at interpretation that the physical motions called for by the program and the physical limits of the machine are the what set the cycle time.

And in the programs I've seen, other things like waste motion, cutting air, overly conservative feed rates and the like dominate anyway.

So, hang on a second. Let's look at this.
Much of the program "tweeking" that has been talked about so far is low hanging fruit in my opinion. These are really the easy ones. To program a part according to a multiple set up whether it's simply duplicated or a multi step/single op, is not new or rocket science or anything. It's simply a discipline at the programming stage.

When I set up for programming, I'm already thinking about clamping, how many parts, VMC/HMC, how many stations, etc. Then I lay out my tool operations or at the very least, tool change order. This is while thinking of optimized format at the same time. I don't think this necessarily should be considered a bottle neck if it's already part of the ingrained thought process.

However, looking at it from your example, specifically "But if the programmer is the bottleneck and a machine has to sit idle while tweeking the program for another machine then its not always the best way to spend your time,, "

This is assuming the programmer is a 'bottle neck' simply because a machine is idle. But is he really? I think the circumstance has to be further understood. Here's a vantage point: Say that programmer spent 2 hours tweeking machine 2's program, meanwhile machine 1 is idle. At first glance, you're right... you have a bottleneck. Now, say that what he did was removed a couple operation set ups and a number of toolchanges which at the end of it yeilds a 15 hour improvement of the original process. Now, say he does the same thing for machine 1 and spends another couple hours and yeilds a 10 improvement.

Collectively, you have machine 1 idle for 4 hours and machine 2 for 2 hours. That's a 6 "shop hours" loss or bottleneck as you say. However, in doing so he improved the process by a total 25 shop hours. Taking out the loss time, both machines now have a collective of 19 hours extra time to go make more money that you didn't have before. That's 2-3 extra money making days depending on your work shift. And this is only from 2 jobs. Work that out over a period of a year and figure on how much can be improved. Another bonus to this is what happens the next time these jobs come up? Instead of counting the "old" leadtimes, you now have new improved lead times.

So, some situations will certainly yeild a ton of saved time. As well, some will yeild miniscule amounts of time that makes it seem not worth the effort. However, my point is, take a moment to think about it. A machine not running doesn't necessarily mean you're not making money or you have a bottleneck. This is called "investing" IMO with a potentialy huge ROI that's easy to attain.

I can agree if the jobs are long running or a steady repeater that the extra time can be justified,even if a machine sits idle,,
Most of the work I`m used to is short run only,,so unless I have extra time available for tweeking I prefer to keep the spindle running,,
As with everything the line has be drawn somewhere depending on the situation,,

I think im just having a hard time explaining myself...been working way too many hours..

Obviously if its a repeat job at all its worth the time spent setting it up perfectly the first time. If its a one off and not coming back then just get it on the machine. with a good cam program and programmer it will be just dandy the first go around. At least mine are..thats the scenario i hear most about (prototypes with no return) and those are something you can afford the extra 2min cycle time on and not spend an extra hour optimizing. UNLESS its coming back at some point in the near future. most of the time when it does come back there are changes and your extra program time is lost. At least that's what usually happens for us.

Production parts or parts that will run a decent qty get set up as sub programs and they are broken down for each tool. With my macro that tool will run on all offsets i select. then its onto the next "program" and tool, then repeat..I also optimize the tool path, plunge rates, minimize cutting air as much as possible and make some kick butt fixtures that are easy to swap parts on and easy to set up again. Offsets are stored with the program and good job/setup sheets are made.

Right now i am programing at the machine (favorite way to do it) breaking my program down for each section and running just that section. I watch and see where i can improve it, then i do and go onto the next section. When i am done i have a program that is optimized as much as i can. I break it up into sub programs it and run..

Lots of programmers have responsibilities and commitments that have little or nothing to do with programming. For me, tweaking was either something that could be done very quickly or it waited for some free time.

I think we can all agree that there is a right time, right place and right job. The idea is just to keep it in mind at all times so that at the stage of initial programming, the ideas and process are mostly in place. (makes the tweeking later simpler and much less time involved).

Being a short run is irrelevant if its a repeating job. It now warrants a "looksy".
Agreed...