How does Mastercam round numbers?

[randymcdermott]

Anybody know how Mastercam rounds numbers when posting? It looks like if the output is to be 4 decimal places it is only concidering the 5'th decimal as to wether the 4'th is incremented or not.

 

The NCI gives a value of 1.54534652 for Y in line 31 of the following code:

 

29 L X+3.7077 Y+1.6436

30 CC X+3.0369 Y+1.3082

31 C X+3.7484 Y+1.5453 DR-

32 L X+4.2372 Y+.0791

 

When rounded, that value should be 1.5454 not 1.5453. This is probably what is giving my Heidenhain control a hard time. All other values checked out ok.

 

Any thoughts/explainations/suggestions?

 

Randy

[JG]

1.54534652 - 1.5453 = .00004652 rounding error

 

vs.

 

1.54534652 - 1.5454 = -.00005348 rounding error

 

?

[Jack Mitchell]

If I was to program a 1.000” hole then the radius would be exactly .500”. A value differing would not be mathematically correct and therefore a machine tool cannot cut anything that is not mathematically perfect or correct – correct?

 

Not so; a typical Cnc will accept a variance of .4998 ~ .5002 depending on the parametric settings on a particular control. It has been my experience that numerically speaking, a control has the ability to realize a plus/minus error of .0002” when vectoring.

 

Just my thoughts.

 

Regards, Jack

[Allan]

Check yer version of mp.dll see if you are up to date, there was a version awhile back that would sometimes display the trouble you speek of.

 

You can get the latest from Mastercam.com

 

HTH

Allan

[Jimmy Wakeford from Barefoot CNC]

I have seen some rounding issues in the post, not so much incorrect rounding as when/what it rounds. In some posts I have went in and added:

 

fs 20 0.6 0.6 #in the fformat statents

 

then:

fmt x 20 x

fmt y 20 y

fmt z 20 z

...

 

what happens is that it rounds the nci value as it brings it in then makes calculations from that rounded number.

 

I have seen it affect 5ax angles ever so slightly and have seen it "egg" small holes.

 

To check what values the post sees you can add:

~x,~xnci~x_cen,"HHHHHHHHHHEEEEERRRRRRRRrEEEEE",e

 

to a common post block (plin,pcir,etc.)

[Jimmy Wakeford from Barefoot CNC]

The only way I could round the 4th numer considering the 6th number was to set up dummy variable to 5dec places and:

 

x_dum = fmtrnd(x) #x_dum = 1.12345 x = 1.123446

xabs = fmtrnd(x_dum)#xabs = 1.1235 x_dum=1.12345

[Jack Mitchell]

Another interesting thing for consideration is the mantissa display on a calculator. Some will show 8 places after the decimal and some will show 10 places. The processor actually floats with sixteen places but can only echo the maximum of the mantissa display.

1.4444444444444445 should actually round off at 1.4445

I’m not too sure about 32bit and 64bit processors though.

 

 

Regards, Jack

[Paul Decelles]

Starting with MP 9.18 internal calculations are performed using a new tolerance setting in the post called 'mtol'.

The problem has always been that the NCI data is at a different precision than the NC data. Attempting to determine when motion existed or the validity of data without knowing the NC precision proved to be impossible.

'mtol' was introduced to give MP that information. Besides being a tolerance, it implies the formatting to be used internally to duplicate the NC output formatting.

'mtol' does a lot. It is used internally to format X, Y, Z with motion tests and arc checking. In theory, this allows MP to see what is going to be output to the machine step values. It is very important that the implied 'format' matches the format (FS & FMT) of the actual output variables.

Setting 'mtol' to match the NCI tolerance makes MP blind to what the NC formatting is. This makes arc checking, motion tests, angle calculations, etc… unreliable.

The default value for mtol (if it is not defined in the post) is .0001 for inch values and .001 for metric. This means that for many individuals, nothing needs to be done in their post. Individuals that need 5 place output for inch or 4 place output for metric simply add an initialization for mtol at the top of their post.

 

mtol .00001 #Machine tolerance initialization

 

Without this initialization, a format statement for 5,6 or more places will only output 4 places or 3 places (inch or metric).

 

I hope this explains a bit of what is happening 'behind the scenes' in the post. There is a lot more to tolerancing, arc checking, etc... in MP. I'd suggest picking up a copy of the Post Processor Guide cd from your reseller if you want to know more of the if's, and's and why's...

[Jack Mitchell]

Great explaination Paul

 

Regards, Jack

[Allan Brown]

We use

 

mtol : .000001

 

to combat the new default and get back to 6 decimal places.

 

Certainly send you example into the post guys @ CNC Software - they're looking to solve all of these issues internally in Mp.

[John Summers]

Here's something to look out for. If a value has been output, that value is stored back in the original place (say X) as well as prv_x. If you output that value a second time before that coordinate is updated or refreshed, then the rounding algorithm works on the already-rounded value. FYI, the rounding algorithm ONLY looks at the next digit.

[HevyMetl]

I am not complaing, just questioning.

 

Just last year I paid to have a post developed for a new Makino SNC64. The post outputs 5 decimal places and I have been having problems on complicated surface tool paths with the machine drastically slowing down the programmed feed rate to maintain accuarcy. Makino says it is the rounded values in the post. I just checked the MTOL statement in my post to see what it is set to and it is not even found. What do I need to do to get this into the post and get it working properly. The post was developed from the genereic Fanuc. Just a disclaimer I can find my post and make simple changes, but that is about as far as it goes.

 

Sorry to hijack, but I feel this might help me out with irritating problem.

 

See ya Monday morning

[Paul Decelles]

John,

If you need 5 place output you need to initialize mtol in the post as I explained above. i.e.

mtol .00001 #Set machine precision - 5 place output.

 

quote:

---

We use

 

mtol : .000001

 

to combat the new default and get back to 6 decimal places.

---

As explained above, this is not recommended. Setting 'mtol' to match the NCI tolerance makes MP blind to what the NC formatting is. This makes arc checking, motion tests, angle calculations, etc… unreliable. We have run across a few situations where there will be a .0001 rounding error, setting mtol to .00001 usually fixes this. If you run across issues, please send them (a copy of your post and the .mc9 with the operation exhibiting the error) to your reseller or [email protected] and we'll have a look at your settings and determine the best solution.

[HevyMetl]

Thanks Paul, I will give this a try and see if it adresses the lag I am seeing.

[randymcdermott]

Gees you guys have been busy this weekend!

 

It's going to take me a bit of time to digest this.

 

Thanks, Randy

[HevyMetl]

Paul,

 

Does vtol have anything to do with this. My vtol value is set to .0001".

[Roger Peterson]

I also use mtol : .000001

 

This cures the output of some helical arcs that should not be output. Very important for a fadal, if you have a helical arc with too small of an incremental Z moves it makes a straight line move to the endpoint of the arc (NO GOOD).

 

 

HTH

[Paul Decelles]

John,

vtol has been eliminated. It is only used to set chord_tol if chord_tol (chordal deviation for arc break up and line break up) is not initialized in the post. This insures that old posts breakup the same.

[HevyMetl]

OK I see that I have to get the CD on posts and start learning some of these things for myself.

 

Will having both in the post cause any kind of conflicts?

[randymcdermott]

Hey JG,

 

If memory serves me correctly, when rounding a decimal number you consider the value of the last digit and if it is 5 or greater, the digit to the left is incremented by 1 and the right digit is dropped. The process is continued untill the required number of decimal places is reached

 

Therefor:

 

1.54534652

1.5453465

1.545347

1.54535

1.5454

 

Yes it is an error but not a rounding error. If both Mastercam and the control use the same rounding process to calculate X,Y,Z,I,J and K then no error will be trigered.

 

Dave and Paul;

 

If Mastercam rounds by only considering the 5'th decimal (if the required number of decimals is 4) then Mastercam and the control get conflicting results to the same calculation and the control has to "forgive" the error.

 

I forget exactly what parameter I changed in our Heidenhain 407 control but I do remember it was originally set at .003mm which should have been an adaquite sized window for a .0001" error (.0001"=.00254mm) however it gave me "Circle End Position Incorrect" error untill I increased the parameter setting to .005mm (.0001968)

 

This is certainly never going to affect the the quality of our machining as the closest tolerance we work to is +-.001" but shouldn't Mastercam think about altering their rounding algorithm to give the correct result?

 

Allen;

 

I have MP.DLL V9.1.9.19

 

Thanks to all

 

Randy

[JG]

quote:

---

If memory serves me correctly, when rounding a decimal number you consider the value of the last digit and if it is 5 or greater, the digit to the left is incremented by 1 and the right digit is dropped. The process is continued untill the required number of decimal places is reached

---

I'm under the impression that you only go one place further out to round, each additional place has only 1/10 the "weight" of the previous place.

 

Jg

[randymcdermott]

Hey JG,

 

Let me see...I'm 53 and could be suffering from CRAFT (can't remember a f&%$*#g thing). Math was never my forte but I think I'm right.

 

Can you (or anybody else) disproove me? I'd certainly be glad to be corrected.

 

Randy

[JG]

randy,

I can't quote anything either way, however try your example (1.54534652) in excel or a calculator and see what you come up with.

 

thanks,

 

Jg

[Paul Decelles]

John,

Having both vtol and chord_tol in the post is not a problem, vtol will simply be ignored.

 

Randy,

The idea behind mtol is to get MP to process in the same way the machine control processes by allowing MP to work at the specific machine's precision. This is why we recommend setting mtol to match the output format statements from your post. The default value of 4 places for standard units is due to the majority of machines running to 4 place precision. The same holds true for machines running in metric (with the exception of wire machines which seem to run at a higher precision).

Rounding does indeed work as you explain above. If we tell MP to round to 4 places it looks a the 5th place. If the value is 0-4, the 4th place remains the same. If the 5th place value is a 5-9, it rounds the 4th place up. Your machine control also works in the same fashion. Rounding up from 6, 7 or more places would most likely increase the end point mismatch rather than decreasing it.

Your explanation of the parameter setting in your Heidenhain shows exactly why we added mtol. Setting mtol to .00001 in this case would have ensured that the rounding was done to meet the precision needed by the control (keeping it less than .0001).

One thing that is being missed here is that there are many other tolerances in MP that effect the output that you see in the end. Settings for arccheck, arc_tol, helix_tol (which may apply to Roger's problem above), minarc, minrad and even ltol (which is only used in the default arccheck routine) can and do effect the values output.

 

As you can see, there is more to generating arcs than simply setting mtol to six places. This is why we request to see situations where you folks run into problems so we can recommend a solution. Especially seeing as we are working on MP for X. Now is the time to review the issues that end users have, so we can determine if a change needs to be made prior to release.

[randymcdermott]

Paul,

 

Thanks for putting so much effort in trying to educate a stick. It's fortunate for me that things are a bit slow around here right now and I can take some time to try and figure out whats going on.

 

Where it comes to the post and Mastercam settings it reminds me of the days of DOS 3.1 with config.sys and autoexec.bat (gag).

 

I got a copy of V9 MP Post Processor Online Reference Guide a few months ago and up untill now, havn't been able to make much sense of it even though I have considerable experience in Visual Basic programing.

 

Where is mtol and what setting should I use for number of decimals for NCI?

 

JG,

 

My calculator seems to work the same as your's (12.4537 rounded to 2 places = 12.45) but if that's true, knowing that 1mm/25.4 = .039370079", one could round the result to 5 places (.03937) and multiply that by 25.4 and get 1mm when in fact you get .999998000 (is there a smiley for "tongue in cheek?)

 

http://mathforum.org/ says when rounding a decimal number GENERALLY only the number to the right of the required number of decimal places is to be considered (which agrees with what you are saying).

 

My boss (peng) agrees with me but an aerospace eng student here agrees with you. I can't seem to nail this thing down. Beginning to wish I had something to do here! Wait a minuit! Did I just say that?