mating condition problem from nx5 to nx7.5

[spantik]

hi to everyone, I tried to take a look, but I did not find anyone (if I'm wrong well come) who opened a post on the new system of assembly of nx5 to nx6, still allows to use the old system of assembly, but now that I use 7.5, I can not understand the logic of assembly in the mats: are all listed without references, it is a mess to understand which are the mates of a piece. am I not arivo (possible) or is there a new logic that escapes me?
Thank you very much to all for any help.
Hello!

 

[fcorallo]

go to the part navigator, select the component that interests you, then go under the dependence tab (it seems to be called so) click on the lens and appear only those related to the part you selected

greetings

 

[IPdesign]

I can tell you how it works on nx8, the 7.5 by now I uninstalled it . but I think it was the same with the 7.5

in addition to seeing the constraints in the assembly navigator, there is a specific navigator for the constraints.
in this specific navigator constraints you have the possibility to have a grouped view of the same according to the associated component

 

[ceschi1959]

in nx8 the specific resource bar was implemented that until 7.5 did not exist, greatly improving the management of constraint assembly.
the main problem, which I could see on several occasions, was the 'automatic' conversion of mating conditions in constraint assembly due to the lack of correspondence of the fix bond in mating conditions.
I explain better: being the unidirectional mc was customary to place without constraints and in absolute the main detail. the axieme depended on that particular unsold but was not labile. see image mc, while with assembly constraint the assembly, with the same constraints, is labile (see image ac) as the constraints are bidirectional.
with 'old' assemblies it is necessary to go to fix that first element to make the system manageable otherwise strange things happen.

 

[fcorallo]

in nx8 the specific resource bar was implemented that until 7.5 did not exist, greatly improving the management of constraint assembly.
the main problem, which I could see on several occasions, was the 'automatic' conversion of mating conditions in constraint assembly due to the lack of correspondence of the fix bond in mating conditions.
I explain better: being the unidirectional mc was customary to place without constraints and in absolute the main detail. the axieme depended on that particular unsold but was not labile. see image mc, while with assembly constraint the assembly, with the same constraints, is labile (see image ac) as the constraints are bidirectional.
with 'old' assemblies it is necessary to go to fix that first element to make the system manageable otherwise strange things happen.

I confirm, strange things happen, let's say, "cases"

 

[Pizza3d]

In addition to the suggestion of fcorallo, in nx 7.5, to search the constraints between 2 components, a very convenient command is the "show hide constraints" or "show and hide costrain"
Selected 2 components also allows you to isolate the constraints that are in common with these 2 components. you can find it in the toolbar of the assemblies to the right of the command of the costrains.

in nx8, using the appropriate filters, the axiemi navigator is really useful.

my experience about conversion from mc to assemblies costrain I never had prolemas I noticed that if the axieme was wrong and had errors previously the conversion leads to behind the same errors, regarding the fix on the main component, it always converted it correctly.
Good job

 

[ceschi1959]

..... about the fix on the main component, it has always converted it correctly.
Good job

non esiste il fix nelle mc, il problema è quello. riporto quanto mi hanno scritto dal gtac:

i think we should have a look at this assembly.
as far as i know (and this is my feedback from ps guys) with the new assembly constraints method one should be much more careful with assemblies management: for instance you should always define at least one base component with a fixed constraint
that works as a reference component for the rest of the assembly, avoiding to have unconstrained components (fixed didn't exist with mating); translating the old matings cannot always define a robust contraining scheme with assembly constraints.

 

[Pizza3d]

non esiste il fix nelle mc, il problema è quello. riporto quanto mi hanno scritto dal gtac:

i think we should have a look at this assembly.
as far as i know (and this is my feedback from ps guys) with the new assembly constraints method one should be much more careful with assemblies management: for instance you should always define at least one base component with a fixed constraint
that works as a reference component for the rest of the assembly, avoiding to have unconstrained components (fixed didn't exist with mating); translating the old matings cannot always define a robust contraining scheme with assembly constraints.

Of course there is no... the main component (the one without constraints in the mc) is recognized in the mc-ac conversion and during the conversion the fix bond is placed in the ac.

 

[Utente NX]

the main problem, which I could see on several occasions, was the 'automatic' conversion of mating conditions in constraint assembly due to the lack of correspondence of the fix bond in mating conditions.
I explain better: being the unidirectional mc was customary to place without constraints and in absolute the main detail. the axieme depended on that particular unsold but was not labile. see image mc, while with assembly constraint the assembly, with the same constraints, is labile (see image ac) as the constraints are bidirectional.
with 'old' assemblies it is necessary to go to fix that first element to make the system manageable otherwise strange things happen.

symptom/problem
---------------
when converting mating conditions to assembly constraints, how does nx decide which components are given a 'fix' constraint?

solution/workaround
-------------------
mating conditions are one-directional: component a is constrained to component b. so the mating condition will never move component b, whatever happens.
assembly constraints are two-directional: components a and b are constrained together, and when the constraint solves, either constraint can be moved by it.

therefore, when a mating condition is converted to assembly constraints,
component b is given a fix constraint (if it was not mated itself). this gives
the best representation of the pre-conversion behavior with the new
constraints.

the user can always delete the fix constraints if they are unwanted. however, this will mean that the assembly has update behavior less similar to the unconverted behavior than before.

note that the message "you are trying to move a fixed component. are you sure you want to move it?" does not prevent you from moving the component. it is merely a warning message, and replying "yes" to it allows the component to be moved.

 

[spantik]

thanks to all boys

 

[ceschi1959]

symptom/problem
---------------
when converting mating conditions to assembly constraints, how does nx decide which components are given a 'fix' constraint?

solution/workaround
-------------------
mating conditions are one-directional: component a is constrained to component b. so the mating condition will never move component b, whatever happens.
assembly constraints are two-directional: components a and b are constrained together, and when the constraint solves, either constraint can be moved by it.

therefore, when a mating condition is converted to assembly constraints,
component b is given a fix constraint (if it was not mated itself). this gives
the best representation of the pre-conversion behavior with the new
constraints.

the user can always delete the fix constraints if they are unwanted. however, this will mean that the assembly has update behavior less similar to the unconverted behavior than before.

Thanks, I didn't know that. I checked with a well-made set in nx5 by clearing components and the result was great. the gtac response, to which I addressed myself for a client who passed from nx4 to nx7.5, misled me. probably the axioms of this client were in the beginning badly done.