material variants

[Ely23]

Good morning,
very often we realize components with same geometry but different material, for example fixing elements in aisi304 or s235jr.
the codes with which they are registered are different (a code for the iron and one for the inox) but the table could be the same (same measures, same processing etc.) since it is all equal to less than the material.

is it better to make two different articles with two different inventor models (unless the material) and two different boards?

Do you have any other alternative?

manage the two objects through two models and two tables obliges us to review them both whenever a change is required.

Hi.

 

[PIETRO2002]

I would keep two tables and two separate models, one tomorrow you can only perform a change on one type and not on another, a different surface treatment etc. etc.
In this way mistakes are avoided, even if in the short term it seems the most expensive solution, but one non-conformity is enough to zero the advantages that would be in choosing the easiest way.
another way maybe it can be to manage variants not with the design but with the management system, depends on the company of what resources it has and how it is structured.

 

[TETRASTORE]

you could manage in the bom the two separate codes, e.g. 123456_a and 123456_s, associating them with a father code equal to design 123456 at level 1 (as is generally done in the management of the crude) on which the distinction will be reported: "usable for: 123456_a, material aisi304 and 123456_s, material s235jr".
Obviously only if you do not expect future changes only on one of the two codes.

 

[DrBarde]

in my experience I would keep two separate tables and two separate models.
rather, if the company for which it works allows it, it could make an encoding ♪, with the code equal to less than desinence, but thus allowing future changes on the two codes independently.
Unfortunately, the changes are unpredictable.

 

[Ely23]

you could manage in the bom the two separate codes, e.g. 123456_a and 123456_s, associating them with a father code equal to design 123456 at level 1 (as is generally done in the management of the crude) on which the distinction will be reported: "usable for: 123456_a, material aisi304 and 123456_s, material s235jr".
Obviously only if you do not expect future changes only on one of the two codes.

using the 3d inventor to generate the distinct ones we are obliged to realize the model for each material variant in such a way that the 123456_a or 123456_s codes are used according to the model loaded in the axieme. I'd have to run everything through cad2d, like you say, a code with the dwg table "neutra", but with the 3d I'm in trouble. I'm not sure if your strategy can be applied to 3d.

 

[Ely23]

I would keep two tables and two separate models, one tomorrow you can only perform a change on one type and not on another, a different surface treatment etc. etc.
In this way mistakes are avoided, even if in the short term it seems the most expensive solution, but one non-conformity is enough to zero the advantages that would be in choosing the easiest way.
another way maybe it can be to manage variants not with the design but with the management system, depends on the company of what resources it has and how it is structured.

we have a plm to manage the distinct and currently associate an article code to each model or together 3d.

 

[DrBarde]

we have a plm to manage the distinct and currently associate an article code to each model or together 3d.

exactly as we do from us, unfortunately with a rigid system the only way that does not generate subsequent problems is the double code with double model. encoding (e.g. 001a for inox and 001b for iron) only serves the part of the technical office to quickly find the files equal to less than the material. have the same code with two components that, to the reality of the facts, are different (the material), in the subsequent stages of the pdm could lead to problems related to the price and cycle of work.

edit: Also, if there is a consolidated historian, you have to be very careful to change the code.

 

[Catafratto]

inventor 2022 (which I still haven't installed and so I just read the manufacturer's info) introduces the model states, which could be a solution... I hope so, I have similar problems. for now in the case of ely23 we make two models, two codes and two tables for each piece. Alternatively you could experiment with iparts, a table but many codes... I tried but then I converted to the other system not to confuse me with the table and for an irrational basic apathy with iparts.

 

[Zac69]

inventor 2022 (which I still haven't installed and so I just read the manufacturer's info) introduces the model states, which could be a solution... I hope so, I have similar problems. for now in the case of ely23 we make two models, two codes and two tables for each piece. Alternatively you could experiment with iparts, a table but many codes... I tried but then I converted to the other system not to confuse me with the table and for an irrational basic apathy with iparts.

subscribing everything

 

[TETRASTORE]

I am sorry, I know quite well the creation and management of distinct bases but not just their management in the 3d, so I ask you:
you can apply to the case @ely23 the solutions proposed in the debate: raw-finished management?

 

[Ely23]

inventor 2022 (which I still haven't installed and so I just read the manufacturer's info) introduces the model states, which could be a solution... I hope so, I have similar problems. for now in the case of ely23 we make two models, two codes and two tables for each piece. Alternatively you could experiment with iparts, a table but many codes... I tried but then I converted to the other system not to confuse me with the table and for an irrational basic apathy with iparts.

Yes, iparts within pdm/plm create more problems than anything else! There is little documentation about it. for 2022 we cross fingers!!!