History based...I dont think so.

"Craig" wrote:> Hello Group,

Might be a cycle in your dependencies, through an equation or circular in-context dependencies. Try cadDOC

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!

"Edward T Eaton" wrote in news:c6o8sc $e6vue$ snipped-for-privacy@ID-139356.news.uni-berlin.de:

I thought that setting forced SW to rebuild all the features on every rebuild. After looking it up in the help, I see that's not quite correct.

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"

consistently

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.

Craig wrote:

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

..

Jerry Steiger wrote:

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.

..

Craig wrote:

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!

..

Jerry Steiger wrote: