If I create a datum point far removed from model surface
geometry is the effective tolerance for all subsequent
features markedly increased? Creating the point will expand
the (Info / Model Size) part bounding box. Is it this same
bounding box that's used for tolerance calculations or
another that's determined by (and not exposed to the user)
Is there a way to, other than manual calcs, to determine
the effective tolerance being used at any given time in the
There is a 'geometry dependent factor' involved in
effective tolerance calcs. I ~think~ (really don't remember)
that ~.8 is a number I've come up with based on export
resolution values. It seemed to be constant for simple
prismatic parts or spline surf parts. Is there any known
documentation available to explain the factor?
And finally, regarding export tolerances; the effective
accuracy applied to a feature depends on model parameters
at the time of creation (if I understand the process
correctly). When geometry is being processed for
translation is the same 'at that time' tolerance applied or
is the tolerance in effect at the model's final feature
used? And, this is the value recorded in the translation?
Trying to get a handle on some of the concepts.
I think, what you are talking about Jeff is part accuracy ~ ratio of
smallest edge to part size (which must contain your imaginary datum point)
which is, AT THIS PARTICULAR SCALE, a scaling factor for relative volumes
(LxWxH). 'Info>Bounding box' will give you this info. But, withiout running
this little routine, that doesn't seem to be available. Is this diagonal
capturable in a parameter? I'm not sure. But, if you knew its relative size,
you could scale a microbe into a galaxy, simply by its proportions and its
I'm not sure, in Pro/e, what corresponds to 'effective tolerance being
used'. Pro/e knows relative and absolute tolerances. Neither is easy to
understand and neither, for the unitiated, has anything to do with precision
or decimal places. Not directly, anyway. But, as to the automatic part, use
an analysis feature; capture the model size info and smallest feature info
in a relation. That will give you a realistic part accuracy.
Never heard of 'effective tolerance' calcs. Or any such obscure 'factor'.
Don't believe any such thing exists. Tolerance is a parameter that is not
communicated externally through any export format that I'm aware of. Nor is
precision or accuracy. Pro/e exports raw data with no decimal places
stripped and no additional information included. A dimension is a real
number in Pro/e, out to however many decimal places, no additions,
subtractions or qualifications. It's just a raw number to 10 or 12 decimal
Thanks for taking a look, David.
From TPI 32869
(regarding relative accuracy, it is ...)
Stated in equation form:
A < F * s / d
A = recommended relative accuracy
F = a factor based on part geometry
s = smallest distance which the system
will consider entities to be separate
d = diagonal of box whose sides are
parallel to default coordinate system
axes and which just encloses the part
From an article "Relative versus absolute accuracy" by Oleg Los
(E.E.R.N. article, I can't find a link to it again.):
It is important to notice that Pro/ENGINEER determines
this accuracy value for each step of a part's creation.
As soon as a part's limits are changed (increased),
Pro/ENGINEER calculates a new value for local accuracy
and uses it from that point on for all geometry-related
My term "effective accuracy" would be the local accuracy, expressed
in units (equal to "s" accepting the generalization A = Fs/d).
Model resolution (by some definition variant) is written to exports
IGES (header field #19)
SAT (header third line, second value)
I assume it's also written to Parasolid and Granite neutrals.
Well, I think I've answered the first question by conducting a simple test.
It appears that the Info / Model Size bounding box is not the one used in
relative accuracy calculations; e.g. a datum point off in space has no
effect on accuracy (at least as stated in an export of that part).
It does appear that another practice I've heard of does affect accuracy; so
called "modeling in body position"; e.g. when geometry features are far removed
from default datums. So don't model that cotter pin in the tail of a 737 "in
postion" with a CS0 constrained to body origin. Or frames or brackets
The problem can be demonstrated by trying to place small chamfers on a small
cube created a large distance from default datums (1" cube, 500" offset,
.05 chamfer, default .0012 rel acc).
Sorta makes me wonder what happens if I add features to a component of an
imported assembly or .... never mind.
(I don't typically use rel acc so these are just curiosity issues for me born of
other discussions re accuracy, translations, etc. The body position thing
should be of interest to those that follow the practice for whatever reason.
For auto body dimensions it might not be a consideration, or it might if
translating for use where .005" to .01" or so edge deviations mean the
difference between a 'good' or 'bad' translation.)
I wonder if that changes depending on whether points/curves are exported or
Do you have any experience with 'assembly accuracy'? Could the above be its
application? Or does this apply to parts created in assembly and referencing
other parts ('use edge', activated parts with axes created referencing holes
in another part)
That's an interesting experiment. I wonder why the 1" cube didn't fail! You
must have offset it in only one direction. If you'd offset it in x and y, I
think it just might, depending on what you use for the value of 'F'. If you
used .8, the calculated accuracy would be .0011 so I wouldn't be surprised
if even the sketch failed.
Okay, but the idea of doing these experiments to find out, in a controlled
way, how the accuracy business works is a very good and sound one. Here's
another one that I've done: put a small hole in a sheetmetal part. I'm not
sure if the position on the part matters but from what you said above, it
could. Then, keep increasing the size of the sheet until the hole fails. In
fact, the sheet may fail to 'thicken' because the thickness is so small in
relation to the overall size that it can't be calculated at default
accuracy. The other reason I can see for doing some experiments and getting
a good handle on the accuracy business is that it's hardly ever obvious that
an inadequate accuracy setting is behind some problem or outright failure.
When you do a cutout or a merge that fails with some vague, obscure error
message, you might not even guess that this could be attributed to accuracy
settings or even the use of relative vs absolute accuracy. And you might not
guess that accuracy was behind import errors except that when you change
accuracy, the geometry heals by itself. Same with geom checks going away
just because part accuracy was increased. Or, as you pointed out earlier,
that the additive style of modelling is directly affected by accuracy
because it is constantly recalculated as the model grows by adding features
so that finally, small features, which were okay to begin with, will start
failing but for NO APPARENT REASON. Makes you wonder why there's a formula
but that Pro/e doesn't use it internally, quietly, behind the scenes,
without a lot of fuss and mystery, to just reset accuracy to what it
requires. It is its own accuracy function; why bother me with it!?!
Especially when I'm missing information that's needed for the formula, i.e.,
how am I supposed to find out what the smallest edge or distance or feature
is? There's a 'model size' function; where's the 'smallest edge' function!
Don't tell me it's been there all these years and I never knew it. But if
Pro/e is, in fact, keeping a running inventory of feature/edge sizes, all
the more reason for it to use this information internally to just take care
I barely have a handle on how Pro/e handles calculations filtered through
the accuracy visor. It's a complete mystery how other programs handle part
size/feature size considerations, much less through the agency of neutral
files which themselves get implemented differently between software
publishers. And I'm still looking for one that translates parametric
information from Pro/e to Solidworks to Catia.