RDWorks Preview estimated time consistently less than actual laser time.

[John Kleiber]

RDWorks Preview estimated time consistently less than actual laser time.
I can change the file interval to get a more accurate time.
But the interval I input is not actually the interval ultimately used to laser.

I anyone else using this feature with any level of accuracy?

-John

[John Kleiber]

I think I'll just setup a spreadsheet based on Laser Light Time.
Convert the time to decimal, then multiply by some base amount and scale accordingly.
357222

[Keith Downing]

I was having the same issue by about 20-25%. Asked the question last year and the responses were mixed: http://www.sawmillcreek.org/showthread.php?248385-For-those-that-use-Laserworks-(or-RDworks)&highlight=

[Doug Fisher]

+1 for another person who finds the estimated time to be highly inaccurate.

[John Kleiber]

I was having the same issue by about 20-25%. Asked the question last year and the responses were mixed: http://www.sawmillcreek.org/showthread.php?248385-For-those-that-use-Laserworks-(or-RDworks)&highlight=

That's about right for most of my tests but some pushed even higher, some estimates I ran jobs that pushed 100% inaccuracy. A job was estimated to take 7.5 minutes when actually it took 14 minutes engrave time.

[Kev Williams]

My Triumph's PHCad software has a time estimator/simulator- I've watched the simulator but never actually checked the time difference.
But just watching the thing, it's easy to see why they run fast; it's because the simulator runs at the actual work speed entered all the time,
but simulator speed and actual machine speed likely aren't going to be the same, but mostly, the simulator doesn't compensate for accel/decel speed changes, actual 'dead space' speed, or overrun during rastering.
I would think vector estimates would be closer to actual than raster estimates.

All I can think of for advice is keep track of a few runs v estimate times and come up with an average difference, and start factoring it in :)

[John Lifer]

I've found that it does vary a lot, and I've not really found a good way to determine how it is calculating. Some things like my cups are close, might be 6 minutes est and run at 6min and 20 sec. I had a flat 100% raster I did yesterday, estimated just over 10 min and it took about 18.... Go figure. One thing I've noticed is that if I look at estimate based on initial settings and then change the interval distance it will not calculate nearly as accurately.

[Dave Sheldrake]

most of the Chinese software packages estimate time based on actual speeds rather than a progressive linear speed.

If you are running at 500 mm per second they don't allow for the fact it takes time to go from stop to 500 mm per second so you end up with a compounded error.

edit: oops...Kevs already got it :)