sketcher_rel_accuracy: why?

Anyone know what the config option sketcher_rel_accuracy is for, what it does? The
"description" just says 'Enter value for sketcher accuracy'. I could find no
reference to it in any of the "Help" files. Sounds like a good thing ~ accuracy
control at the feature/sketch level.

This isn't a trick or academic question. I've spent months trying to track down
the cause of an intermittent loss of snapping to references in sketcher. In the
last month, I tracked it to a config.pro option by preventing the usual
config.pro(s) from loading by renaming, so using all default values.

Since then, I've gone periodically and not very systematically through a default
config.pro file, moving settings from the 'bad' one to the inoffensive one, for
customization purposes and to see if any had the effect of causing the sketcher
anomaly.

Well, I finally found it last night, the mysterious sketcher_rel_accuracy. I
commented out the option (highlight it, RMB 'Comment') and finally got back the
default value of '1' and got the sketcher snapping going properly. But, beware, if
you set it to a value, like .1 or .01, you'll probably lose snapping to references
in sketcher. Maybe it was meant as a handy way to turn if off with 'Intent
manager' still on, who knows.

David Janes

 

David,

I have an idea about the possible intent behind this variable that I am
going to check next week when I'm back in front of my Pro/E. Have you ever
tried to make a small feature in a large sketch, only to get a message
'Section regeneration failed, highlighted entity is too small', or something
along these lines? That has happened to me several times when trying to
create a sketch by using edges of another feature(s) as a loop: the parts of
the loop created by small corner fillets on the 'parent' feature were
refusing to regenerate. The workaround was to zoom in very close on a
portion of a sketch. Then the sketch regenerated without a hitch. Maybe PTC
has created this variable to allow proper regeneration of sketch features
which are too small in relation to overall sketch size and fail to
regenerate under default sketcher accuracy setting?

 

: "David Janes" wrote...
: > Anyone know what the config option
: > sketcher_rel_accuracy is for, what it does?
:
: Well, the documentation on that one slipped thru the cracks; one hit in Help
: that tells you nothing and one hit in KB that says it was added for WF.
:
: What it appears to do is set a "snap aperature".

Hey, that would have been a great name ~ sketcher_snap_aperature. I would have
been looking for a *bigger* number, not going for something like .01 or .001,
which is what relative accuracy LEADS you to believe that this option controls.
Talk about stuff that could qualify for an "Eschew Obfuscation" Award!! But, if
it's just an aperature, why wouldn't the pick_aperature_radius cover it!?! Maybe
they wanted to separate the two? Why?

: In a test part with a bounding box of a few units try setting it to a large
number, i.e. 10, and
: create a sketch with a few reference projections (points and curves).
:
: If that's all it is a little more thought could have gone into naming.
:
Thought, yes, *any* would have helped. As opposed to deliberate attempts to
mislead.

David Janes

 

:
: : > Anyone know what the config option sketcher_rel_accuracy is for, what it
: does? The
: > "description" just says 'Enter value for sketcher accuracy'. I could find
: no
: > reference to it in any of the "Help" files. Sounds like a good thing ~
: accuracy
: > control at the feature/sketch level.
: >
: > This isn't a trick or academic question. I've spent months trying to track
: down
: > the cause of an intermittent loss of snapping to references in sketcher.
: In the
: > last month, I tracked it to a config.pro option by preventing the usual
: > config.pro(s) from loading by renaming, so using all default values.
: >
: > Since then, I've gone periodically and not very systematically through a
: default
: > config.pro file, moving settings from the 'bad' one to the inoffensive
: one, for
: > customization purposes and to see if any had the effect of causing the
: sketcher
: > anomaly.
: >
: > Well, I finally found it last night, the mysterious sketcher_rel_accuracy.
: I
: > commented out the option (highlight it, RMB 'Comment') and finally got
: back the
: > default value of '1' and got the sketcher snapping going properly. But,
: beware, if
: > you set it to a value, like .1 or .01, you'll probably lose snapping to
: references
: > in sketcher. Maybe it was meant as a handy way to turn if off with 'Intent
: > manager' still on, who knows.
: >
: > David Janes
:
: David,
:
: I have an idea about the possible intent behind this variable that I am
: going to check next week when I'm back in front of my Pro/E. Have you ever
: tried to make a small feature in a large sketch, only to get a message
: 'Section regeneration failed, highlighted entity is too small', or something
: along these lines? That has happened to me several times when trying to
: create a sketch by using edges of another feature(s) as a loop: the parts of
: the loop created by small corner fillets on the 'parent' feature were
: refusing to regenerate. The workaround was to zoom in very close on a
: portion of a sketch. Then the sketch regenerated without a hitch. Maybe PTC
: has created this variable to allow proper regeneration of sketch features
: which are too small in relation to overall sketch size and fail to
: regenerate under default sketcher accuracy setting?
:
:
: --
: Alex Shishkin
:
: http://home1.gte.net/res025wf/index.htm
:
:
Yeah, that's exactly what I was hoping this option was meant to address. But,
apparently, it was misnamed. It has nothing to do with addressing that situation.
Since I was mislead into applying a *smaller*, relative accuracy type value,
instead of the larger (1 or higher for a sketcher pick aperature), I found out the
hard way that it has nothing whatsoever to do with accuracy. Not in typical
English language, engineering/science/math parlance, anyway.

David Janes

 

: "David Janes"wrote...
: > ......if it's just an aperature, why wouldn't the
: > pick_aperature_radius cover it!?! Maybe
: > they wanted to separate the two? Why?
: > .................................................
:
: Dunno, but the functions probably don't overlap and it might be speculated
: that the developers for one module don't overlap with another. (Wonder if
: D-Cubed has anything to do with the sketcher development?)
:
: There's a strange behavior that I didin't mention before because it's
: difficult to describe, or even to figure out what's happening. If you have
: an unconstrained sketch entity (in a datum sketch, for instance) and set the
: option to a large value, when you modify the datum sketch (add a curve) the
: solver moves the existing curve trying to solve some constraint for each end
: point (I guess if there's a valid constraint that can be applied within the
: limits of the variable). It's weird, I sure not an intended workflow...but
: my point is that there's more to the workings than would be satisfied by the
: normal pick aperature.
:
Granted, two very different applications of an "aperature", the sketcher 'snap'
behavior being the more active of the two. But, is the aperature code doing that
or something underneath, fed by the aperature input?

In any case, do you know if the value represents the same units as in
pick_aperature_radius, one one-thousandth of screen size? So, if your screen
resolution were 1024 x 768, a sketcher_relative_accuracy value of 10 would make a
'snap' zone about 10 pixels wide. Or is some other unit of size used, in other
words, how big is 2 or 20?

David Janes