Resolve Mode or No Resolve Mode?

[JWayman]

Now that the dust has settled, how do you find the option regen_failure_handling no_resolve_mode?

Do you find people save stuff with regen failures and check it in for someone else to put right, or is it a welcome release from the drudgery of having to fix every minor problem before being able to continue?

I have misgivings that I might find people encountering regen failures and either not noticing, or just deciding to leave them for the next poor soul to deal with.

How do you prevent this scenario, whilst still allowing users the freedom to use the no_resolve_mode option?

Or do you simply neglect to tell them the option exists?

I'm interested to hear your experiences.

John

[IceDog]

There was a period of about 1 year when the group of people I worked with didn't know about resolve mode. We unknowingly had errors which were not resolved. So at the time we were checking in models which had errors. We then upgraded from Intralink to Windchill. The decision was made to toggle the resolve mode. It made it so our models were awful to open since the software wanted to address each error. A special icon was created for "no resolve mode" which we now use sparingly. Luckily we stoped developemnt of the product which had all the errors and put our efforts towards a new product. So while we maintain our legacy product data in "no resolve mode", we maintain our current product development with "resolve mode".

I would strongly suggest you use resolve mode to keep the models pure and usable for other users.

[JWayman]

Thanks, Jim,

I wondered if that might be the case.

I wonder whether there is anyone out there (who works in a group, I suppose it's not so bad if you work alone) who does maintain the default behaviour of 'no_resolve_mode'.

John

[TomD.inPDX]

I don't know about the mode so I am not sure what the default mode is. All I know is that when you start messing with Mechanism, you get failures all the time due to the state the assembly is in when you run the Analysis. It took longer to figure out how to minimize these problems than anything I've had to clean up from this.

But all too often, Creo decides at a later stage that it has problems. Just ran into one where the exploded view made the assembly constraints fail (huh?)... I was certainly not at a stage where I could go address it right there and then, but the persistent error on the message line made me go back and fix it.

What's worse is the multitude failures when you work with advanced assembly states in drawings. Regen errors abound when you have many models in the drawing in many stated of explode, flexible models, and sections. If these errors stops me at every turn, I'd be buying new laptops on a weekly basis.

So yes, I believe a model should be "verified" by whom-ever is expected to sustain it and if someone checks in a file that is full of errors and holes, they would either get a very stern talking too or find themselves looking for new employment... in the case of contractors.

[RV_5434567]

We don't use resolve anymore since we went to Creo2, and I'm very glad for that. Especially in big asm it can be really annoying, have to suppress every little failure. Now you can just leave it till you get to the end, or just do what you have to do knowing it will fix itself after the next few steps.

As for people who leave their mistakes in for somebody else, that's just a matter of discipline. Give them b°sterds a kick in the rear...

[dschenken]

It would be interesting to capture the ratio of forced errors due to PTC software flaws and self-inflicted wounds due to bad modeling decisions. I'm guessing 95/5 for better users to a low of 80/20 for average ones.

These are two underlying causes for failures:

One is the result of failed algorithms in the PTC software, such as being unable to find intersections even though items clearly (by eye) should and do intersect, even though item intersections were previously found. Accuracy changes, extents changes, small dimensional changes can lead to these. There is little on the user side that can be done to predict or avoid these failures. Anyone else play accuracy Wac-a-mole**?

The other is users failing to build models or use models correctly. Most of the sneaky ones begin in Sketcher with it's automatic prevention of failures by adding whatever whacky constraints seem easiest to patch over problems. Overloading the horizontal and vertical operators with shared horizontal and shared vertical constraints are high on my list of antagonizers. Others, like CRCs, are just like programming errors. Package a component, add a cut at the assembly level to make a hole for the component referencing the component, redefine the component with the hole as a placement reference. Instant CRC. Or just deleting a feature that other features or assembly components are linked to without checking other/higher level parts.

**Yes, that's the way it is spelled by Creative Engineering, Inc. who claims to be the originator of a one-off. It was apparently taken over by Bob's Space Racers and renamed Whac-a-mole(tm).