WF3 strange behaviour with curves copied

I noticed several very strange behaviour of proe WF3 (currently M060), offently a shut-down...

For example : I have 3 curves that are functions 50, 51 and 52 They have been copied from an other part in an assembly that is in memory or not (produce the same behaviour).

I have a style feature that is the function 60. This function is made of some curves that are snapped on the previous curves.

All is OK but, for example : - when I want th move the style feature in the tree I have a "shortcut icon" a very short time and then a proe crash. - when I make a group with the style feature (60), it moves just before function numbered 50 ! (style is child but before in the tree...) so I have : num 50 : group that contain functuon 61 num 51 : first curve (previously 50) When I ungroup, my function come back to it's place.

I have this phenomenon with several functions, not just one. I delete 2 of them and buid them again and the problem is still there.

In few words, my method is below : - I have an assembly made of several parts (source parts and one working part) - several "source" parts contain scanning datas (stl import) - in thoses parts, I've made curves snapped on the scanning datas within a style function. - in the assembly, I copied thoses curves into my working part. - the problem I've just explain is in this working part (when I snap a style function on those copied curves). I could completely rebuild this part from a blanked one but is this method safe and secure ?

Well, I have strange behaviours and don't know why : - Is my copy method very bad ? - Is my part file corrupted (but method ok) ?

Before continuing to work, I have to know what I have to change.

Thanks for any advices, I really don't know what to do, GB

I can't really tell what your problem is, nor can I even tell from your post, what you're trying to accomplish. But, knowing that you are working with scan data (stl?) and that you are working in a "working" part from "source" parts, from my experience, numerous problems can arise. Some relate to dependencies created in assembly, others relate to misunderstandings of where a (even what kind of) feature is being created (think of all the tims someone has created an extruded cut thinking they were creating a solid protrusion whuich is not possible in an assembly. So, let me ask a couple questions: when you created the copied curves, was the assembly active or was the part active? also, when the curves were created, was there any option that governed whether they were dependent or independent? And just one suggestion: open the "working" part and confirm that the curves actually exist in that part. Sounds like you could be creating assembly curve features. (Sorry, all the grouping and reordering business has me totally lost; what are you trying to do!?! Thank you for all the details; we hardly ever get that here, but I can't tell, from the welter of detail, if this has a happy ending because I detect no plot to the story!) And one last question: you mention "Style feature" ['Insert>Style''] in conjunction with scanned data when it seems more appropriate that you might be doing 'Edit>Restyle' ~ which is it?

David Janes

This is an interesting problem.

As I understand it, you are trying to design a part that references several other parts, in an assembly. Some of those parts contain scanned data. You've created curves in your part, while in an assembly, referencing geometry from other models. You're now applying surfaces to your reference geometry using style.

"- Is my copy method very bad ?"

No, in my opinion you're taking an intelligent approach to this.

"- Is my part file corrupted (but method ok) ?"

I suppose that is possible. It is more likely a bug in the software. Something you might try is forcing every feature to regenerate by slightly changing something early in the model tree. The advanced surfacing techniques you're using are not as well "shaken out" as the more mundane Pro/E functions. At some point along their development, they changed Pro/E to skip regenerating features that are not effected by something you've done early in the model tree to speed up regen time. But it doesn't always work. I have seen the software fail to notice changes in curves and surfaces (in models with no external references) and fail to take them into account in regen. This can create paradoxical situations. So my advice is to force the software to reevaluate some of the features to help stabilize your model. That's a real long shot though, not likely to work...

You could try creating the curves in the assembly. And then copying the curve geometry onto your part file, though that would likely make the problem worse...

I have observed the curve copy is not as robust as the surface copy, for whatever reason.

You might try copying whatever features you're referencing for curve creation into your part file, that way the curves you're creating in your part file are referencing internal geometry.

Nope, I'm pretty much at a loss. What you're trying should be working. Good luck with that. Let us know what you end up doing.

Thanks for your response,

I've made some other trails and now I can be much precise.

It seems the copy method to produce strange behaviour.

So, I'v tried this with new empty parts. Assembly A contains parts B and C. In part B, I make somes curves and simple sketchs. In the Assembly, I activate part C. Then I make a Copy and past for copiing a curve from B to C. Whenever Assembly is in memory, the curves are fully associatives. In the C part, I make something very simple just like make a datum point on the middle of the copied curve.

All works fine but if I want to make a group with the point fucntion, it goes just before the copied curve (And this should be impossible).

I have the same problem in Wildfire 2 or 3.

"Polymer Man" a écrit dans le message de news: snipped-for-privacy@k79g2000hse.googlegroups.com...

I have one more idea. Try setting everything to absolute accuracy, rather than relative. What happens is, as the models grow, the accuracy is reduced because everything is relative to the physical size of the model. So, something you create referencing scanned data works at one size, but changes into something different at another scale. If set to an absolute accuracy, this problem of "moving targets" goes away.

And a final thought, a clean model is important with iffy geometry like this. If you have geomcheck errors, it might help to address them before moving on.