hexagon logo

Offline to online runtime calculator

Has anyone else ever tried to create a runtime calculator for programs created offline?

I'd like to offer more confidence in time management when it comes to requesting time on a workstation and I thought about trying to build something like this. If anyone else has tried, what things have you run into for roadblocks or success could you site?

I realize this is a daunting task to take on, but I can see a lot of benefit if it is worked out.
  • I got asked this when I worked for Hex but it's a minefield.

    You need to take into account...

    You'd need to calc distance between hits, and all moves
    Take into account acceleration and deceleration over given distances (think calculus & differential equations)
    Dwell at movepoints / clear planes / avoidance moves / before and after hits etc (don't know if you noticed but they're not consistent)

    Do you use search routines like find hole? have fun calculating that.


    Much better to do it statistically I reckon

    Take 20 progs, run offline and time, then run online and time, and see if there's any kind of correlation.
  • Ninja,

    I will say, I did not even think about acceleration/deceleration. Clearplanes, avoidance moves and other forms of time occupying travel I had thought of. We use a similar area of our surface plate so I was going to make a 'hard' number for the travel to/from the probe rack. Estimate average clearance move times and time for a 'hit' to take place.

    Fortunately for me, I don't have to contend with search routines (yet:confusedSlight smile

    I tried your last part, and I had a range from about 4.5###### to 19.###### in multiplier value. I deal with a variety of parts that are pretty similar with exception to 100 more of this or 50 less of that for feature counts.

    I think with some thought over the calculus and differential equations I may be able to get somewhere closer.
  • I've spent about the last year and a half writing an application library for our estimating software to do the same, except for lathe cycle times.

    Consistency in your inspection methods is hugely important if you want to go this route for cycle time estimates. Our lathe programs are written using a .Net application, so the rules that are always in effect in our lathe programs were easy enough to extract and put into the estimating code: we always rapid to .2" then .04" in 'Z' in front of the part, we divide stock to be removed into the fewest number of passes that don't exceed a depth-of-cut limit, we break the finish profile into certain movements, etc.

    Personally, I would investigate the animation settings in the PC-DMIS setup options (F5) to see if these can be tuned to match the performance of your CMMs. We used the simulation capabilities of our CAM software, Esprit, as a baseline to test my estimating library. Because of the focus of our product line and the volume a part numbers we quote, it was beneficial for us to write a piece of standalone code to do the same thing.