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?
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.
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. 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.
PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.