Continue to Site

Welcome to MCAD Central

Join our MCAD Central community forums, the largest resource for MCAD (Mechanical Computer-Aided Design) professionals, including files, forums, jobs, articles, calendar, and more.

Merge Failures... Chronic

Mithrandir

New member
This has plague'd me for years... and prolly I oughta' asked years ago how to fix....
this is my problem.... I create a bunch of datum curves for creating surfaces.... I am very careful to
make sure there are no disconnections....

I create the surfaces using the curves and when I go to merge the surfaces... it will error and tell me
there are overlaps..... or sometiimes the surfaces will merge... and then I adjust a curve and the merge fails...
these are adjacent surfaces who's common edge is the same curve!!

I have fussed with the accuracy with inconsistant and marginal results...

anyone got a fix for this???

tnx
 
Not exactly sure of your specific issue, but here are a couple of ideas that can help get you started.

- As a try, make your primary surface using the curves. Then your subsequent surfaces can use the edge of your primary surface instead of the curve (I cringe to suggest this as it's less parametric and it could poop out if you remove the primary surface, but it's one way to run a check to see if it's an issue with the curve or if it's an issue with another process in the tree).
- Directions of a merge. Use the buttons in the edit definition section and not the arrows in the model - sometimes one arrow will be hidden behind others. There are generally 4 total ways to define it (0-0, 0-1, 1-0, 1-1) using 0 and 1 as directions of the merge.
- I doubt this is affecting you, but remember that the way you select surfaces will affect things down the line. So select your primary surface and then hit CTRL and select your second surface. And then merge. That will keep the feature number to your primary surface.
- There are limits to how many surfaces you can merge at the same time depending on how they're interconnected. When it doubt, just merge 2 and then in a new feature, merge the 3rd to that new bigger surface.

Hope those make sense and that they fix your issue. If not, try to provide some more detail and we'll help you out.
 
Typically.... when I use a common curve to create adjacent surfaces, I select fromt the "Option" menu, "Join".... this has no arrow selection.... and when things go as they should, even if you don't select the Join option, if the surfaces have a common curve defining their adjacent surfaces... there will be no arrow......

The problem that too often pops up is when I use a single common curve to define two adjacent surfaces...and then I go to merge'em, there are arrows.... when there oughta not be.... and doing a minor tweak or modification to the curve will sometimes result in the arrow NOT being there (or being there when previously there weren't any) when the merge is redefined.... and this will sometimes cause a regeneration error..... Changing the accuracy also fuss'es this up....
 
Good point...that arrow doesn't always show up. Are you using any constraints between the surfaces (tangent, curvature)?

Is this a part you could upload? I've never seen that issue, so maybe it would help to play with the part...

(also may be a moot point as I'm on WF4 because my company prefers the archaic)
 
I've seen the issue. It's almost as if there is an issue with accuracy. I found that often simply redefining the merge w/o actually changing anything often works.
 
I really need 8 hrs with the surfacing lead Paul. I have begged him to get a few days in Chicago.


Mithrandir: Howz the weather in Cali?
 
Set accuracy to:

First:

absolute = 0.0001 (if units are inches)
absolute = 0.00254 (if units are mm)

Relative accuracy = 0.012 is a recipe for disaster if your overall part size is large compared to small levels of detail.

Second:

Note that since there is not longer forced repair when you have features fail on a redefinition - often features will fail, but when you go to redefine them everything looks good, and then the feature regenerates without issue.

Often there will be a failed feature buried in a GROUP that you can't see.

Expand All in the tree.

Fix the earlier failed feature, and suddenly all of those "failed features" are good to go.

Am I the only one who preferred forced fix for failed features?
 
Setting accuracy to .0001 results in long regeneration times. Your accuracy should only be set to the level required by THAT model.
This is also an old post.
 
Having an accuracy too low and then trying to tighten it up only to have regeneration failures takes long regen times.

I don't just pull these numbers out of the air dross.

There was as a time when I wrote a little bit of 3D CAD software.

I have parts with feature counts in the thousands, and with modern computing power I rarely have an issue with regen times. The occasional mega hex pattern with full draft, rounds, and sink wells not withstanding.

Posts are like people. They're young for a little while, and then they're old for a long time. Doesn't mean they aren't useful though.
 
I dont see any reason to set the accuracy that low when it´s not needed? i agree with dross about using the proper accuracy for your part. (that is when you cant use default )

Regarding finding failed features in gorups. when you "expand all" in your modeltree you see...all. If you got a modell whit , let say "a lot/1000" of features you will have a lot to seek thru. An easy way to find failed features burried in groups is to use the SEARCH googles. Just "look for" - "features" , and in the status tab set the "value" to "failed" , and when you click on your result, the modeltree expand the group that got a failed feature in it.

Regading force failure fixing.... if your in creo1 or creo2, isn´t there an config option where you can get the old way of fixing problems back? The failure diagnostic box?

//Tobias
 
regen_failure_handling is the config.pro setting you mentioned. default is no_resolve_mode and the other is resolve_mode it will force you to fix them.

Interesting discussion. Thanks Tobbo
 
Thanks for the config.pro setting.

I'm assuming we're talking about parts that are of the size that a single person could typically carry it if it were light enough. If you're building on a mega-structure scale or a nano-scale then we need to have an entirely different discussion. Yes?

As for accuracy - I understand the argument for keeping Creo regeneration times down, I do. I held that same view for a long time. When working in a Creo only environment, and if creating simple shapes then yes the default accuracy is probably fine. If you are in a Creo only environment and doing any surfacing work I would at a minimum increase the accuracy to a relative value of 0.006. This will make your quilt merges more robust and will have a minimal impact on your regeneration times.

If on the other hand you have to work with vendors and customers who have a mix of CAD systems then I would set the accuracy levels as noted earlier.

Do you ever have issues with imported and exported parts not solidifying? Coming in with gaps? Vendors complaining about Pro/E (uh...er... Creo) data not coming in clean? This will make most if not all of that go away.

What I am surprised at is the fact that my time studies show that regeneration time difference is not really significant. What nobody has brought up - and what is a significant issue (if you have actually investigated and explored accuracy in Creo and not just parroted other's arguments) is the fact that your file sizes goes way up. Big time.

I'm willing to live with it knowing that my CAD data (particularly surfacing work) is of high precision, and works well with others. Memory is cheap. That wasn't always the case.
 
Do you ever have issues with imported and exported parts not solidifying? Coming in with gaps? Vendors complaining about Pro/E (uh...er... Creo) data not coming in clean? This will make most if not all of that go away.

I can say same thing backwards - SW, NX, SE creates export trash, I must clean later on.

I keep working on 0.01 Absolute among part and assies.

Until you work with one part - relative tol is not an issue. Bringing couple of parts into assy, is the place where problems could occur.

I try to avoid to make every detail in one part, having "complex surfaced part in mind".

I create first skeleton with my basic shape, and publish it.

I create separate parts for outside geom, for TPR areas, for inside geometry, and even sometimes I create separate parts for rounding of mentioned before "areas/geometry".

I could do the same dividing the model tree in such seperate areas and keeping the referencens in proper maner, but it is too much cumbersome to earch it through.

So instead of one big model, I create couple of small ones.
 
Last edited:
What I am surprised at is the fact that my time studies show that regeneration time difference is not really significant. What nobody has brought up - and what is a significant issue (if you have actually investigated and explored accuracy in Creo and not just parroted other's arguments) is the fact that your file sizes goes way up. Big time.
.
Your time studies apparently don't involve the types of models that some of us create.
Regen times can go from 30 seconds to 30 minutes just by increasing accuracy. If that's not significant, I don't know what is.
File size is of no issue with terabyte drives and 24 gigs of RAM.
Now who's the parrot?
 
BROCK! Polly wants a cracker!

30 seconds to 30 minutes is significant. An order of magnitude even. I'd like to see one of those models. Sounds impressive.

File size is not as big of an issue anymore - you are correct. Back when they decided on a default value of 0.012 (relative) memory was very expensive.

You're right I should have qualified my statement with regard to level of fine detail in the part.

Sorry if I upset you again dross.

My intentions are pure.
 
Loose accuracies are a recipe for disaster if one uses top down and Copy geoms....

I use Absolute .0005...if I have problems I try to change the accuracy to .0001 starting in the skel....

I use "MVA's" so my assemblies are lean and regen quickly...

Only the integration of Mathcad files with the Creo model has shown significant regen times in my experience....
 

Sponsor

Articles From 3DCAD World

Back
Top