I've created routines in my post to calculate distance travelled and time.  Time = distance/feedrate.  Rapid feedrate is adjustable, and the post knows what the current condition is, and adjusts accordingly.  Testing it against Catia with a VERY large file, and the runtime difference between my post and Catia's calculation (just selecting all the MO's and replaying) was only about .04 seconds...so I'm satisfied that I'm calculating correctly for GOTO's and Circles.  However, I've had difficulty in the past with giving customers a good runtime when there's a lot of drilling.  The latest job I programmed had 100 tool changes and 69 tools.  Most of them were drill-type tools.  Here's my current sub to calculate cycles.  It should be pretty clear, and I admit, it's kind of lazily thrown together.

 

'************************************************************************
'Sub GetCycleDistTime returns the distance and Time in a Cycle
'************************************************************************

Sub GetCycleDistTime
    Distance = RNext - CycleZVal
    Runtime = Distance/TimeFeedrate
    Distance = Distance/CycleStep
    Runtime += Distance/RapidFeedrate
    TotalDistance +=Distance
    TotalRunTime += Runtime
End Sub

Basically, it determines the total length of the hole.    It divides the distance by the cycle feedrate to get the time in the hole at cycle feedrate. 

Then it sets the distance as distance/cyclestep  and divides it by the Rapidfeedrate to get the time in the hole at RAPID.  CYCLE's without a step set the step value default at 1.

Then it just then adds the two runtimes to get the runtime for the specific line.

Then it adds the distance and time to the totals.

To me, this seems pretty logical?  However, I have the feeling I might be missing something, because my runtimes aren't very close to Catia's when drilling.  Though, Catia's haven't been very close to the actual machine feedrate.  I'm not sure who's right!

So....if any of you guys like a puzzle, and can create a better algorithm to calculate runtime of drilling CYCLES (just in English...I can translate it to code), I offer to the guy who finds the answer first, a 3-axis generic/fanuc  post-processor which in every other way tests identical to proven posts that I have.  It includes TRANS, CLEARP, RETRCT, processes CYCLES from Catia with very easily WYSIWYG logic, and every APT standard command that I could think of, and has a pretty nice interface, and also creates a listing file for debugging.  Any errors found are printed with details as to the type and  how to  repair the error.

I just could use some help on this one.  Maybe my algorithm is right, and Catia's is wrong.  If this is inappropriate for the forum, let me know and I'll delete this post.

Bryan,

Try outputting aptsource, with the output cycles off, so CATIA sumulates the cycles, with GOTO's. Look at the fedrates. they may not be what you expect.

Dave

I think some rough model of the machines dynamics must be implemented in the algorithm. My machine accelerates at 0.5G and has a max rapid of 0.5m/s, in theory it will do zero to RAPID in about one inch of travel. Then RAPID to zero is PID-regulated so it will probably start to slow down two inches or something before full stop with average speed for the last inch done at a fraction of RAPID. Not considering this will lead to like 1s of calculated total rapid time on a hole in which you peck 50 times.

Put a stopwatch in a machine and make a program that will push the start/stop button and make rapids of differnt lenghts and you can make a nice diagram witch then can be translated into a simple matematical function that will give you close to real world rapid times for different lengths of moves.