CQ: Relative accuracy and datum features

C(uriosity) Q(uestions):

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)
surface geometry?

Is there a way to, other than manual calcs, to determine
the effective tolerance being used at any given time in the
model?

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.

TIA

=======================================
=======================================

 

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
scaling factor.

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
places.

 

Thanks for taking a look, David.

From TPI 32869
(regarding relative accuracy, it is ...)
Stated in equation form:
A < F * s / d
Where
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
calculations.
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
STEP (uncertainty_measure_with_unit)
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. <g> Or frames or brackets
or ...

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
not

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
of accuracy.

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.

David Janes

 

Interesting observations and questions, David.

Tried it, no difference.

No, nothing beyond some mild pondering. I've assumed it plays the same role as
part accuracy (intersection curves, trim edges, etc.) for assembly level
features. I would not ~think~ it will affect or bias part level accuracy
settings; i.e. if working a part within the context of an assembly you create a
plane / surf intersection curve the accuracy of the curve will be governed by
the part's accuracy setting.

There's an interesting quirk. (I've never seen any of this documented but don't
think I've ever seen anything contradictory.) Accuracy settings do not govern
the accuracy of the chamfered cube's geometry. Analytic entities are created to
floating point accuracy minus a few decimal places lost to rounding errors and
noise. This means that a cylindrical hole in, and normal to, a plate is
accurate in size and position to the degree floating point calculations allow
even though part accuracy may be only .01 absolute or inferred by relative
accuracy. If the hole is angled relative the planar face (? assuming the conic
result is treated as a spline?) or punched thru a spline surfaced face then part
accuracy settings govern the ~maximum~ edge deviation at the cyl face / spline
face intersection. It's worth noting that deviations are typically an order of
magnitude+ finer than accuracy settings dictate. Depends on the surfaces
involved, how complex or simple, 'dirty' or 'clean', who knows what else.

Back to the chamfered cube. The chamfer creation, using the previous
parameters, fails because of an indirect effect of changing accuracy; shifting
of a 'dynamic range'. The term comes from some ACIS documentation:

Within object space, the model world is characterized
by the magnitude of the numbers on the entities being
modeled; e.g., the smallest and largest coordinates
existing on the model and the smallest and largest
difference between any two coordinates. All object
space numbers are represented in ACIS as double
precision floating point numbers which contain roughly
14–16 significant digits. ACIS considers four of the
least significant digits to represent numeric
round-off errors that occur during calculations. Thus,
there are roughly 10–12 digits to represent the
dynamic range of numbers (smallest and largest numbers)
within object space.

It goes on to state that the dynamic range cannot be expanded but it can be
shifted by changing the model resolution (changing the range lower bound).

I've never seen the equivalent term in Pro/E but guess some equivalencies can be
assumed.
_ Attempting to create a .05 chamfer results in an
"out of range" (0.0550 to 1,000,000) error.
_ Change the default .0012 rel acc to .0001 rel acc.
_ Want to see a failure, so try to create a .001 chamfer.
_ Out of range (.0050 to 1,000,000)


That pesky "factor"...
Solving for "F" using the offset cube parameters and model resolution from
export (.055, note the correlation to lower bound above):

F = Ad/s = .0012 * 500 / .055 = 10.909

Moved the cube back (500") to coincide with default datums and exported that.
1.732E-4 is the stated export resolution.
1.7621 bounding box.

F = Ad/s = .0012 * 1.7621 / 1.732E-4 = 12.208

I can only guess that the ".8" is totally mis-remembered. I also don't remember
seeing that much deviation but I had it in my head that it was dependent on
geometry types (analytic vs spline) and probably never varied model size
greatly.

Rambling on ...

There is a Short Edge Model Analysis function that will find edges shorter than
input value.

Yes, it is complicated and often incomprehensible. It's interesting (in a
masochistic sort of way) seeing how varying accuracy affects things like round
transitions or other complicated geometry and imports.

intf_in_external_accuracy uses neutral file resolution values.

 

Good and informative discussion gentlemen, I enjoyed reading it.