group operation, sharing etc

[TECNOMODEL]

I would need some clarification on the logic of operation of this cad.

I have a group 1 containing x parts. inside the group I create group 2 that contains y parts.
I share group 2, it creates group 2.1,2.1 etc.
the parts within group 2 and shared are themselves shared, if I change one the change is reflected on all. Good.

Now, for basic distinct requirements, I want to bring all parts of group 2,2.1.2.2 etc under group 1.
and here the pains begin. if I move only those of group 2 the others disappear, same thing if I move those of group 2.1,2.2 etc.
If I move all together jump out of conflicts with names, he says that it renames them but then does nothing, the parties remain under their groups (2,2.1,2.2) and are not renamed.

What am I wrong with approach?

 

[Kaji]

if two groups are shared and loaded at the same time, no matter whether in the same parent group or in different groups, in general they always remain identical, so if you empty one of the two automatically empty the other.
to make the play of bringing to the parent group the details of the shared subgroups, you should have used for the original group the command "copy to a level" instead of the convided command. with the command copies a level applied to a group is generated a new apparently equal to the original, containing all the same details, but that is actually a different object. in fact if I add a particular in the group copied to a level, the original one does not vary because they are two different objects with different id, while if you deform one of the details within the group copied to a level it deforms similarly also the particular correspondent within the original group, precisely because copy at a level means exactly that you copy only the first level, while all that is recurring is used is not shared and therefore it is not
if in your specific case you want subgroups to be shared always and you need not be only when filling out the separate, then simply the operations to be carried out are:
- save the parent group also outside the pdm as simple pgk
- undo all subgroups containing the details you want are read in separate
- drag all the details shared in the subgroups that are now shared are no longer shared
- save the distinct base
- cancel the parent group and reload the one previously saved when the groups were still shared.

if you do not want to use these bombs, there is also the possibility to create groups of objects that are not real and just subgroups and therefore are not read in the compilation of the distinct, but that you can move, edit, create grids as real patterns and are the groups parts face but are a bit more complicated to use and now not the software under hand; at the beginning it is important to understand the use of sharing, copy, copy, copy

 

[TECNOMODEL]

I did some evidence, but something doesn't come back.
I have to align myself with a client's working method. they always operate in pkg, then they have subgroups called "normalized" which are loaded to the necessary in the assemblies and modified, thus creating each time the piece with its design. I was explained that to create more equal parts in different positions the command should be shared, so that if I change one of them also all the others are modified. if I need that any of the initially shared parts do not apply changes cancel sharing. In this way, the parts are renamed by adding to the name a final .1 and in separate leaves the total number of pieces with that name.
everything ok if I do these operations with single parts, but since we talk about equipment with a set of equal subgroups I wanted to facilitate the work by keeping the parts of these subgroups "lit" right in a group.
I then tried to copy to a level as suggested, the group is renamed .1,.2 etc. but the parts retain the same name.
when I move them to the main group (the equipment) the software sees conflict of names and renames in p1,p2 etc. vanifying the work.
It seems to me that on their pcs the operation is different, is it possible that they have configured some parameters that change this mode of operation?

 

[Kaji]

I have never worked for outdoors and without pdm so many things escape me, but I think to compile a distinct something like a database even if it is not managed by pdm. assuming that it is so, if you click on the symbol to the left of the fvista1 in the tree structure you extend the tree structure showing other fields type model name, db status etc.
at the same time when saving a new object in the database is attributed to it a model name which by default is given more or less equal to the original name of the tree structure but then remains "freed" unless you go to change it directly in the database.
probably your customer set by default that in the structure tree appears the model name and not the name that you or the software changed at will and then when the software comes into conflict for the names in the structure list the name always remains that of the model name the same for all the shared elements and is the name that is read at the time of compilation of the distinct.
the messed name reappears if you cancel the sharing and then the object is new and no longer exists a database model name.

 

[TECNOMODEL]

I return to the subject after a confrontation with the client to align myself with his modus operandi.
in essence he wants the equipment (we talk about robotic and manual welding equipment) to be constituted by a single group containing inside all the details, the commercials etc.
I x my comfort and habit create subgroups of the equipment so as to have a manageable tree and do not waste time and search for such component in a tree of 200 details, without counting the convenience of turning on/off a whole group at a time instead of going to look for the individual components.
The problem arises when there are more similar subgroups. It would be simple to share the entire subgroup and to have in the table of the equipment indicated how many subgroups of that type there are and from the table of these having the details, unfortunately the customer is not of this notice.
the only solution I found is to share the details within the subgroup to create the same subgroups, then eventually bring everything into the equipment group. improves management a bit but not much, if the same subgroups are numerous you risk having a kilometer tree again though inside a subgroup.
Finally, if one of the same subgroups I have to change it and cancel the sharing I have to lose more time to create a new subgroup, look for the parts and bring them into the same.
I mean, I feel like I spend more time looking in the tree than what I'm shaping.
Any suggestions?

 

[cacciatorino]

I return to the subject after a confrontation with the client to align myself with his modus operandi.
in essence he wants the equipment (we talk about robotic and manual welding equipment) to be constituted by a single group containing inside all the details, the commercials etc.
I x my comfort and habit create subgroups of the equipment so as to have a manageable tree and do not waste time and search for such component in a tree of 200 details, without counting the convenience of turning on/off a whole group at a time instead of going to look for the individual components.
The problem arises when there are more similar subgroups. It would be simple to share the entire subgroup and to have in the table of the equipment indicated how many subgroups of that type there are and from the table of these having the details, unfortunately the customer is not of this notice.
the only solution I found is to share the details within the subgroup to create the same subgroups, then eventually bring everything into the equipment group. improves management a bit but not much, if the same subgroups are numerous you risk having a kilometer tree again though inside a subgroup.
Finally, if one of the same subgroups I have to change it and cancel the sharing I have to lose more time to create a new subgroup, look for the parts and bring them into the same.
I mean, I feel like I spend more time looking in the tree than what I'm shaping.
Any suggestions?

The reason why you are asked to operate this way is that "base" modeling is capable of creating distinct or only first level or exploding everything, but cannot make a selection based on filters created by the operator. to do as you say, that is to use "ghost groups" unfortunately serve additional modules for a fee. It seems incredible given what the competition offers, but it is.

 

[TECNOMODEL]

The reason why you are asked to operate this way is that "base" modeling is capable of creating distinct or only first level or exploding everything, but cannot make a selection based on filters created by the operator. to do as you say, that is to use "ghost groups" unfortunately serve additional modules for a fee. It seems incredible given what the competition offers, but it is.

So the only solution is to resign itself to losing a tide of time?
it would be enough to find a good method to be able to model without going crazy, then at the end of the job bring all the details in the main group and deliver the whole.

 

[Kaji]

The problem arises when there are more similar subgroups. It would be simple to share the entire subgroup and to have in the table of the equipment indicated how many subgroups of that type there are and from the table of these having the details, unfortunately the customer is not of this notice.
the only solution I found is to share the details within the subgroup to create the same subgroups, then eventually bring everything into the equipment group. improves management a bit but not much, if the same subgroups are numerous you risk having a kilometer tree again though inside a subgroup.
Finally, if one of the same subgroups I have to change it and cancel the sharing I have to lose more time to create a new subgroup, look for the parts and bring them into the same.

As first I didn't realize that version you have software, I suppose you have the 19 and that your customer still has a module that encodes the details, make the distinct, that has a company that follows it like the cdm etc.
as regards suggestions:

- try to use the groups parts face (I don't remember if they are called so) but in fact they are sets of 3d objects both parts, and groups, that faces etc that can be managed as pattern, moved in block, illuminated, modified individually, all together or only some of them using the excludi command, positioned along a grid, both linear and polar, editable in direction and number

-use less the structure tree and select the monitor objects directly via the fv select window command if you want to select them by cluster, you can choose either the partial or complete selection mode, or through the selector choose the items to select, start the selection and then by end it. also to illuminate and turn off singles, parts or groups it is best to use commands with the torch symbol: turn off torch -, torch alone, turn on torch + to use especially if you want to turn on a whole group and see one part.

- If you have many massive objects try to use the command advances and select yellow arrow with a list in this way you can select any object or element 2d or 3d "traced" from your pointer at the time of activation of the command.

- if you want to change an object and it seems too "massed", you just share it, you pull it away, you make all the changes of the case on the shared one turned away and you also have it on the shared one mounted in its place.

- if you find ostico the use of the parts groups face and prefer the classic groups, create them through the owner edit command and not dragging objects into the structure tree.

- if at some point one of the fictitious subgroups is no longer equal to others, use on it the unshared command at a level, it is not necessary to remake it from scratch.

-I have not yet understood the problem of the names because it seems strange to me that the distinct functions with the names of the tree structure and not with those of the database, but you can use simple lisp to rename in one blow only all the shared, groups or parts that are and should have it who provides assistance to your client, or in the annex there is a German lisp to rename in a blow all the selected parts.
if you want to use it only for shared, first apply the shared structure tree (imbuto) filter, turn on only those and then select them and rename them all.

- if the problems arise from the fact that you want to manage groups and subgroups differently from how they have to appear in distita, just save everything as you want, bring all the details to the desired level from the separate and recharge the group as you had previously saved, so much the distinct remains "freeze" and when you go to do the 2d will read the details even if at the time of the pallination you will find inside a subsite and not set.

 

[TECNOMODEL]

Thanks again for the answers.
I realize that in the company the software is used in a very superficial way, without taking full advantage of the various commands/instruments.
Unfortunately I have to adapt to their method, but I would like to understand better the operation.
do you know whether there is a manual, text or anything? in Italian because the software is set with our language.