estimated machine times

[twelchPTM]

it seems to me that the estimated machine times in Partworks or completely off. Is it because it estimates the time off of the feed rates assigned to the bits but doen't compensate for ramping?

[garyc]

Thomas...
Thats correct. Ramping and the rapid speeds are actually unknown to the design software. Plus ramping virtually ensures that no rapid move ever actually happens at the design speed.

To get more accurate estimates try setting your rapid speed to 1 ips (for small parts) and use a scale of about 1.8. Then as you cut projects of a similar nature fine tune the scale factor. For larger parts adjust the rapid speed up to about half of what your actual setting is.

And remember... it will only be an estimate based on the toolpath lengths. Only cutting will get you accurate numbers.

[Brady Watson]

Yes. Install SB3 on your design computer and set the VR the same as the control computer. Then look at the elapsed time when you run it in Preview on the design computer. Even running it in preview will not always give you an accurate estimate. 2D stuff, no problem - it's pretty close. 3D tends to be a bit off for a number of reasons.

-B

[dana_swift]

The inability to accurately predict run times makes no sense to me. As a society we can predict with extreme accuracy the motion of moving objects elsewhere in the universe, flight simulators, molecular chemical reaction simulators, the motion of everything celestial, cars, motors, engines of all types, and the behavior of some "boson" that was recently shown to move just as expected. The uncertainty of most of these things is less than 1%.

However the "ShopBot" seems to not follow physics or mathematics? Isn't ramping the same thing as acceleration with bounding conditions? That is hardly a new phenomenon. Yet it seems to be completely unpredictable. When the USB link is running a solid 70+ the motion of the machine should be exactly predictable, thats what stepper motors do when they don't lose counts.

So why are we accepting uncertainties in cut times of 50%? Why cant ramping be defined more concisely so the motion is exactly predictable?

As long as the control box has a continuous stream of move commands, the execution of those commands should be subject to almost no randomness. If so.. where does it come from? Temperature? Humidity?

This is even more mysterious than why a USB hub helps. If it does there is a concrete reason any decent electrical engineer should be able to articulate.

For the same reason the run time for a cut file should be predictable to 1%, or something near that. If not, that reason should be articulate-able also. I would love to participate in a mathematical propagation of certainty study..

As it is - is grossly substandard.

D

[dana_swift]

Follow on thoughts-

Run times have very little variation according to the log. Which shows the machine behaves predictably. One minute or so variation in an hour long cut. So.. that shows the machine itself is consistent to around 1 minute in 60. Which is 1.6%. Why it varies this much is not clear.. but perhaps comm variations? Does it change if a hub is present?

If the motion model is 1% accurate, the cut time estimates should be accurate to:

Certainty = 1 - (1 - .016) * (1 - .01)
Certainty = 1 - .984 * .99
Certainty = 1 - .974
Certainty = .026
or 2.6%

That would be a huge improvement... now as users we need to insist on getting that kind of time estimate accuracy. The preview for certain should be at least accurate within 3%. Its not.

Why?

D

[garyc]

Dana...
There is no sensible or economical way that all the variables in motion control could be relayed or transferred from a control software back to a design software, especially when, by design, they are separate systems.

Due to dozens, maybe hundreds of variations in motor specs and gearing, compounded by wear and use variables, ramp and speed settings, pull up heights (not in the movement total), heat and duty cycles all result in varying actual cut times for the same given cut file.

I have seen the same production file, cut on the same machine have noticeable differences in them. This is most likely why the design software developers have user input boxes to allow tuning the estimated time to the machine. You may want to notice that the icon is labeled "estimate machining time"

To think that anyone could predict, using linear data of cut and/or rapid dimensions and assign an accurate time to tens of thousands of machines, comprised of hundreds of brands and specs, with dozens of control software variations is beyond what I would consider reasonable.

[Brady Watson]

It is impossible for SB3 to predict how long it is going to take to fill the command buffer each time it is refreshed (on longer files), and this depends entirely on your processor, RAM and COM speed. There are other little things like this that are not considered or could not be considered by SB3 with any level of accuracy.

The 'percent complete' on the SB3 screen when running a live tool, is just the percentage of file lines out of the total number of lines that have been executed. It does not go by time...

-B

[dana_swift]

gary- SB3 has ALL the parameters a machine is running with. And should know what the controller is doing with them. I can understand Vectric not getting it right, but ShopBot running in preview should estimate the times very accurately. The ramping values, move speed, jog, etc are KNOWN to SB3 for any given ShopBot.

Every measurement involves error, and every estimate involves uncertainty. How to handle these is well known. The margin of error, or standard deviation measures the certainty of a value.

SB3 should get it right every time. A display of something like "Estimated Time xxx +/- nnn". Where nnn should be no more than 3% of xxx based on my earlier estimate of error. xxx and nnn should be verifiable using log files of the cuts.

<quote>There is no sensible or economical way that all the variables in motion control could be relayed or tranferred from a control software back to a design software, especially when, by design, they are separate systems.</quote> Yes- I agree, but now when no transfer occurs. SB3 has the data. It needs to be fixed.

D

[garyc]

Dana...
I was assuming we were talking about estimated machining time in PartWorks, so my comments were geared to that end. As far as SB3 goes, like Brady says, the previewer or even when using a simulator (powered controller card with no hub) dont return the same times as a live machine, especially when 3D motion is involved.

QUOTE " It needs to be fixed. "

Once post processed, our cutting files are sent to the machine as text, SB3 does not quantify the linear motion, only the involved axes and lines of code.

My preferrence, and hopefully that of most users that depend on these tools to make a living, would be to apply development resources to those operations that involve dependable, accurate motion of the tools.

[shilala]

My two cents, and that's about how much it's worth...
For many years I figured job costs and labor in my line of work. The only time I was ever off by any significant margin was when I missed a variable. Period.
Our estimators who had no real field experience, relying on software, destroyed estimates on a regular basis. I, as well as most other superintendants or foremen, could look at a job in five minutes and know that they missed it, and ask what in the world they were doing when they bid a particular job. Why their egos wouldn't allow them to lean on all the experience around them for input beforehand, I'll never know.

I would FAR rather lean on someone's personal experience to estimate how long a project should take rather than acquiesce to an emulator that can never take into consideration all the variables of a job. It certainly can't estimate smoke breaks, coffee breaks, different men on the machine, or dozens of other actuals that Gary and Brady mentioned.
If I truly had to know how long a part will take, I'd run it in the air. If for some reason that was cost was prohibitive, I'd ask someone with untold hours of real-world experience, because that's something I haven't got in this arena.

I've used the estimated times as a "guide". They're a tool to help me see that my toolpaths aren't screwed up, and help me to go back in and make adjustments. I noticed almost immediately that they were wildly inaccurate, but they were consistent. It's that consistency that I use to my advantage, not the numbers. That's a big help.

[billp]

" that they were wildly inaccurate, but they were consistent. It's that consistency that I use to my advantage, not the numbers. That's a big help."
Scott, THAT is exactly the way many of us " old timers" use the estimates! For example after a few runs I could tell that my machine estimate would be 20% off of what the REAL cutting time would turn out to be when carving 3 D files. SO if I HAD to give a quick and dirty estimate I would automatically tack on 25% ( fudge factor) and I'd be pretty close to the final cutting time.
As pointed out in earlier threads each and every machine,software, ( and operator) has it's own set of variables. If you do the same type of cutting you can pretty much dial in the "correction factor" to get you in the game.