August 30, 2017

Could you tell me the time?

Hi! Welcome once again to our blog  J

Here’s an observation that I hope you will find interesting.

CAM Software CNC program estimated cycle times.

My use of an image of a mechanical stopwatch is no accident. Back in the day, when I started out as a CNC programmer - which is more years ago now than I care to mention and before the digital timer age - I felt really important but a little intimidated and embarrassed to go down to the machine shop with the stopwatch ( it belonged, of course, to the department ) to time the cycle on first prove-out of one of my well-crafted programs.

We had no means of accurately estimating the cycle time, and had to go and time it so that the job could be accurately booked.

I reckon that little has changed in all these years.

Throughout my CAM software support and selling career working with various CAM system products, the question of cycle time calculation accuracy has arisen regularly.

I’d bet that I’m not alone as a CAM salesperson who couldn’t comfortably look my customer in the eye and say to them that “oh, don't worry it’s spot-on, you won’t have any problem at all”. I just can’t and won't do it. If I were to do so then I’d possibly be in for a whole load of trouble down the line.

Instead, I always tell my customer how it is.

In any CAM system there are, as you might expect, many settings that can be used to influence the cycle time. In ours there is even a ‘fudge factor’ that can be automatically applied to the result, because often the estimated time will prove to consistently be ‘n%’ out.

But these things cannot really be guaranteed to be accurate. I wouldn’t bet money on it, I just know that I’d lose out. There are just too many intangibles, too many synthetics.

But ..

Here comes my mention-of-SmartCAM bit.
My boss expects it. No; he demands, it.

There is some neat stuff in SmartCAM that can be used to help deliver an accurate cycle time calculation.

It’s like most things: if that cycle time is critically important to you then it’s worth spending some time in trying to get it as accurate as is possible. If you’re not bothered about the output cycle time, then why bother wasting time on setting it up.

Anyway, let’s have a brief look at what is available in SmartCAM.

The Code Generator ( the SmartCAM community term for ‘post processor’. I’d like a $, £ or a € for every time I’ve stated that ) Machine Define tool has settings for machine tool linear and rotary rapid traverse rates, tool index times, that adjustment factor I mentioned above, and more.

These settings are used to create a cycle time when graphically verifying toolpath and also when generating code by running the post processor code generator.

Those time estimates may well be sufficient for a given need, but as I have said I’d not bet my hard-earned money on them being highly accurate. A good application-use example of them is a when experimenting with one toolpath / production method over another, the difference in the resulting cycle times can be helpful.

Cycle times can be output according to needs; as a message block in the code file or in a setup document, to mention but two examples.

SmartCAM Customizable Job report

Fine Tuning
Now, if I were tasked with creating accurate cycle time calculations from SmartCAM and the system-generated time didn’t cut it, then I could do more.

The Code Generator toolkit also uses a template ( *.cgt) file, which controls how and when addresses are output and oh so much more.

CGT files have sections; the code generator and code generator writer ‘knows’ when code for key events such as start, end, line, arc, rapid, tool change ( and other events, too many more to mention here ) is being generated.

Here’s about the most basic example, a linear move section:

// Linear feed move.

CGTs can also contain logic programming. It is very feasible and actually quite simple for a Code Generator creator to add logic to his CGT file that manages cycle time output ( and most stuff, for that matter ) to high levels of accuracy, adhering to standards that are uniquely theirs or those of the company.

The CG ( I’m now fed up with typing Code Generator every time ) has a variable for the length of the linear move ( meaning that you don’t even have to include logic to work that out using previous and next positions ), and it can get to the feedrate being used for the move. Counting the incremental time for a linear move is very simple. Something like:

// Linear feed move.
#EVAL ( #mycycletime = #mycycletime + #LNLEN / JOS( feedupm1 ) )

( we are using CG commands there, but since this isn’t a training lesson, it isn’t appropriate that I describe that stuff here. Suffice to say that the explanation is pleasingly technical, simple and logical )

And we might want to output a message block containing our cycle time at the end of the CNC code output:

< #MOV>< #DCOMP>
 ( My Estimated Cycle Time is: #mycycletime minutes )

I hope this gives just a small insight into some of the possibilities.

In addition to managing cycle time at a ‘user level’, when it comes to CNC code requirements CGT logic can be used to output all manner of different things. We never cease to be amazed and impressed by the outputs from SmartCAM that our customers achieve using their preferred CAM system functions.

I like to say that the possibilities are only really ‘limited by the imagination’. But that’s just me being smart.

Good Timing
Whoa! Look at the time. I’ve talked at you about cycle time and our Code Generators for a little longer than I had intended to. But hey, I hope you found my observations of interest, and I hope also that my manager will be pleased.

Take care.
Have a great day / evening / weekend.

We're at:
+1 (541) 344-4563

No comments:

Post a Comment