WF3 strange behaviour with curves copied

I'm working with a network of curves in a part and building style feature
snapped on them.
Those curves are comming from an other part and have been copied in an
assembly.

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'm working with a network of curves in a part and building style feature
snapped on them.
Those curves are comming from an other part and have been copied in an
assembly.

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.

 

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.