History based...I dont think so.

Hello Group,

Im so confused I dont even know how to discribe my problem so it doesnt
sound like nonsense.

I am editing a fairly complex multibody part model and am rolled about
halfway back in the tree. When I ctrl Q rebuild (while still rolled back) I
end up breaking features backwards in the tree...what is going on...is this
possible? What types of things can cause this to happen? What am I not
understanding about SWx besides basically everything.

Ughhh,
CJ

 

Might be a cycle in your dependencies, through an equation or circular
in-context dependencies.
Try cadDOC (http://www.dynabits.com/caddoc/index.htm) to obtain a graph of
your dependencies which might make things clear.

 

I have noticed this a lot.
My theory? - In the old days, SWx would rebuild everything every time you
opened the model or rolled it forward. Now it does not (see thread from a
couple of days ago called 'is2K4 bloatware')

What I know for a fact is that I roll forward and back a lot, work on the
model for days, and all of a sudden errors pop up in stuff I haven't touched
in a long while. I almost never us equations, and linked values are not
probable cause based on the way I use them and where the errors pop up.

I work with verification with rebuild on (which could be another cause of
your problem, if you do not work with it active!) and take about a 20%
performance hit in order to insure that all errors are theoretically caught.
But verification on rebuild is only going to work on features that are
rebuilt. To increase performance, SWx (I think) is using the parasolid
copies of everything to skip rebuilding stuff, and errors aren't getting
caught! I hadn't thought about the multi-body ramifications of this until
your post, but I strongly suspect it has something to do with it because
multi-body parts would have many separate parasolid snapshots and most of my
parts are multi-body at some point

I don't know if my conjecture on the behind the scenes stuff is accurate,
but I do know that I can no longer rely on a regular workflow to find
errors. I have resigned myself to the new field of battle and have been
trying to train myself to hit Ctrl+Q frequently - otherwise I face a lot of
rework when the tree starts bleeding up towards the top when all I've worked
on is the bottom.

One more thought - if you use surface trim, just expect errors to
spontaneously pop up. SWx still hasn't been able to get it to consistently
remember which pieces are selected, and the selection sets often flip.
Fortunately, the bug is consistent - more than once, where I could find no
alternative, I just put a note in the feature name to remind me on the steps
to fix it!

 

Good thought! I've seen the feature scope go wrong on other parts. Craig and
I are thinking that maybe the feature scope is getting confused, so forcing
a rebuild breaks the part. He is going back and setting the feature scope
instead of relying on auto select to see if the part becomes more stable.
Sof far it seems to help.

Jerry Steiger
Tripod Data Systems
"take the garbage out, dear"

 

I've seen the same problem with mutual trims. I have one with four surfaces
that fails every time it rebuilds. I was thinking of turning it into a
series of single trims. Have you tried that or come up with any other
workarounds?

Jerry Steiger
Tripod Data Systems
"take the garbage out, dear"

 

Been there. Done it. It works to split into stages.

 

I ended up fixing my problem, but hey... I dont know how exactly. There
seemed to be a problem where the feature scope would lose bodies I assigned
to it somehow...not sure why. Also, and this is a big one, I got rid of one
of my surface 'delete/fills' which I then was 'extending' to make cutting
surface (yes this is real dumb and probably the 'root of all evil' in my
part). Still have the extend (damn zero thickness errors) and cut ...but the
whole thing is a lot healthier now. For the life of me I cant remember why I
had that 'delete fill' in there, but it must have had a purpose at one point
;-)

Anyway the summary is...hey I dont know what the hell happened but its
better now (10 hrs later, tks SWx).

Thanks for all the suggestions ( I did turn on verification)
CJ

 

There is a simple explanation for this. I see it quite a lot.

SW is set up so that in normal work it only rebuilds from the last change.
Things can appear OK when they are not. My guess is that if you CTRL Q even
without being rolled back you may see the same failure.

When I work on complex geometry I leave verification on rebuild on and only
do CTRL Q rebuilds. I rebuild after creating every feature just to be safe.

This goes back to the performance problem in parts. Since the performance of
features hasn't really improved greatly (and in some cases has slowed) SW
has avoided the issue by simply defering rebuilds in ways that appear to
the user to make it faster. Unfortunately this avoids checking as well.

 

I agree. My theory on this is that the selection of surfaces to throw
away or keep is a screen based pick which I can't imagine they (SWX
developers) are capturing parametrically. Other systems do trims but
don't use the view to select, and don't have this problem. Perhaps
this is why it fails so often.

 

Craig, you might want to get in the habit of doing a <cntrl> Q every
once and a while during your sessions. Cntrl key + Q is a force
rebuild.

 

In addition to parametrics, As you probably know, since 2004, its also
deferring the "true" graphic rebuild in many cases. You'll see this in
that surfaces don't quite line up and look correct. This feature does
make a big difference, and I do appreciate it. It does seem that is is
optimized for analytic and not B-rep (surface features).

 

Maybe I'm slightly O/T but has anyone used any 3rd party model
verification software (eg Solibri Modelchecker(??) or is this not
intended for this application?

PS alpologies if the question is ill-informed but I'm not (yet) a SWX
user

 

This does not seem to have been the issue.

I could fix everything, ctrl-Q (everything's still OK)...roll down one
feature, ctrl-Q again and it breaks my tree backwards. Then I would roll up
any number of features (sometimes not all the way up to the first broken
feature) and wala...everythings OK again (after rebuild).

The fix was a combination of re-applying bodies in the feature scope, and
getting rid of some tempermental surfaces. The problem is that Im not sure
what was going on...after about 8hrs of trying to fix this thing my
attention to detail was waning a bit...sry.

Tks for the suggestions!

Craig

 

Jerry,

Every SP is different with this issue. Sometimes a mutual trim with say
10 surfaces works great and other times.. you have to take baby
steps,... breaking the trims into 2-3-4 for it to work.

One thing I noticed lately are the faces seem to be flipping so the
directions change.
Selection location and orientation of earlier feature a
selection/creation does seem to effect this.. and you really have to pay
attention to this.. I personally think this is one of there weaknesses.

There are too many implied values in the features from the above which
can change your whole intent if you start selecting a sketch on a far
end or changing the vector of the sketch or selecting the order of the
faces slightly different can change the whole mutual trim.
We know there is a reference internal to that feature but there are no
visual clues, like a selection point reference, about those earlier
selection locations.
So.. you're sol if you don't know the model well or if it's not your
model.

...

 

Yeah, from what I've experienced, it's not as linear as most people
think it is or some of the cherry warnings do not follow or highlight in
the order which makes order sense.
There are many times I've seen child features fail in the feature tree
which are many generations down or dependent on earlier features which
should have also gone cherry red.. but they don't until you roll to
them.

And, yes, I've seen earlier resolved features later go cherry red when I
roll to the child features.
And, there were NO circular references.
From experience, it's usually a model tolerance problem.. some features
may change the model tolerance and earlier features fail in the check..

I would guess that sure some of the data is in memory, like a child
feature 3 gens down and a flag is created for that feature because it
may have been easier to access and flag that data at that point in
time? So the other earlier features may need to be resolved or access
parts of the program before a flag can be sent?

BTW, I've been using verification on rebuild for the past 2 months now
and I still have to force a ctrl-q because my surfaces do not update 20%
of the time. This is a definite bug! The system is not checking
changed features and skips the changed features, it's become very
common. It's a major PITA.

...

 

A rule of thumb I like to follow is to try (whenever possible) to always
make sure each feature immidiately follows it's sketch.

Often times you will make several sketches, planes etc. before making
the first feature. I believe it is best to roll back the FM right below the
sketch you are about to turn into an extrude, loft or whatever and create
the feature. If you forget to rollback, simply drag the new feature up
the tree where it's supposed to be.

Doing this will keep the history from getting convoluted.

Mike Wilson

 

Has anyone figured out any of the rules for getting the feature tree back in
the correct order when this rule isn't followed? Sometimes you can just drag
the features around, but at other times it seems like SW still remembers the
"old" locations.

One particular problem I've seen is that quite often you can't just drag a
feature or sketch directly above another feature and then gain access to the
now "older" information. Sketches will still be grayed out. But if I drag
them two or three places above the feature that I want to reference them,
then they become available. Very curious!

Jerry Steiger
Tripod Data Systems
"take the garbage out, dear"

 

No, and I'm having more problems with moving sketches, which have no
parents, up the history tree.
SW2004 is doing things where the sketches are now more dependent on the
history tree.

It's very inflexible and very unproductive!

...