Selecting Features for Sharing

The Share Selected Entities command enables you to pick individual entities in your model and share them with some or all of the members of the workspace. This command is useful when you need to send different parts of your model to different members or if you only want to share specific entities in your model.

You can select specific entities either from the model or by picking them from the Specification Tree. When you share selected entities, the application adds to the briefcase all parents information with the update. Sending the parents information ensures that the entities are merged correctly into the models of recipients. For more information about sharing bodies and other type of entities, refer to the paragraphs below.

Inserting GSD Features into a Briefcase

It is possible to insert GSD features into a briefcase. The Instant Collaboration is performed at the feature level. It means that each feature can be shared without its aggregating body.

Two designers can divide the initial geometrical body in 2 parts (blue and yellow curves).

Then each one will be able to create his own features (blue and yellow surfaces).

And finally, the created specifications can be merged together into the initial body (green surface).

Collaboration and "Geometrical set"/"Ordered Geometrical set"

When merging features into a different type of set, the behavior is identical to the creation: The result is similar to a manual creation of the involved features.

When merging a feature that does not exist already in the part, the following rules are used when applying a briefcase: if the destination part does not already contain the Geometrical set to which the feature belongs, the set will be created before inserting the  feature. If the Set already exists, the feature will be added to it.

Collaboration and "In Work Object"

In an ordered geometrical set, merging is based on the "In Work Object" concept.

Inserting Part Design Features into a Briefcase

It is possible to insert Part Design features into a briefcase. Instant Collaboration is performed at the hybrid body level, because Part Design features are historic dependent.

Only sketches can be shared and merged explicitly without the aggregating hybrid body if it does not depend on other part design features.

Boolean operations:The body(ies) involved in the Boolean operation can be shared explicitly by the user.

Datum features: Results of a paste as result and imported V4 models cannot be shared and merged.

Examples

Sketch.1 can be shared explicitly because it is based on a reference plane. Sketch.2 cannot be shared explicitly because it is built on Pad.1. Body.2 can be shared explicitly. To share Pad.1, Assemble.1, Sketch.2 or EdgeFillet.1, the user should select PartBody.

Note that:

• When a hybrid body is shared, it is merged with the PartBody of the destination part only if this PartBody does not aggregate any feature and has never been used for collaboration.
• The dependencies of a shared hybrid body are composed by its aggregated features that implement the Collaborative interfaces and recursively their dependencies.
• If a sketch can be explicitly shared by the user (i.e. if it is not built on another Part Design feature), the only dependency embedded in the message is the support plane (reference plane or GSD plane…).
• A Part cannot be shared.

Inserting Functional Design Features into a Briefcase

It is possible to insert Functional Design features (created in the Functional Molded Part workbench) into a briefcase. Instant Collaboration is performed at the functional specification feature level. It means that a briefcase can contain functional specifications without any functional body or functional solid. If a sketch built on the result of a functional specification is shared, this functional specification and recursively its dependencies will be embedded into the message.

Functional Body: If this feature is shared, the dependencies are made up of the aggregated features (and recursively their dependencies) and by the functional solid.

Functional Specification: The father is embedded into the briefcase (without the other features aggregated below the father).

Part body aggregating a functional solid: The functional solid and the functional body are embedded into the briefcase.

Inserting Knowledgeware Features into a Briefcase  

Parameters and formulas can be shared. If you share formulas, the geometry on which those formulas are based will also be embedded into the briefcase when creating it. (This geometry will be tagged as Automatic in the Briefcase window.) Other Knowledgeware features (Reactions, Macros with Arguments, Optimizations, ...) cannot be shared.

Inserting a Datum Feature into a Briefcase  

Datum features based on V4 geometry and V5 geometry are supported.

Sharing a datum feature means sharing "frozen geometry" without design specification and without links to the entities that were used to create this element (History mode deactivated). A Datum is always made up of a feature (a proxy), and of geometrical elements.

Note that:

• A datum feature cannot recreate its geometry. Therefore, the associated geometry should be included into the briefcase when selecting a datum feature.
• There is no way to share only geometry without its associated proxy feature. When a datum is merged, its specification is updated and the geometry is replaced.
• Collaboration "share" action never converts (on the fly) specifications into datum while streaming collaborative messages.

Inserting Features Linked to External References

Sharing features containing links to external references, such as contextual links, copy with links and copy as result with link, the result of the link is inserted in the briefcase and the external reference is ignored. On the merge side, a datum is created. This method for sharing external references is referred to as deprecated share.

To protect the information about external references in a bi-directional exchange of briefcases, the following rules apply during the merge:

• A feature resulting from a deprecated share cannot overwrite its source.
• A feature “shared deprecated” (the source) always overwrite the version of the datum existing in the destination part.

To better understand this rules consider the following example:

1. User Ann wants to share feature F1 with user Bob (who has not the feature F1). F1 is linked to an external reference.

• The external reference is ignored during Ann's share operation.

• When Bob merges the briefcase in his part, a datum is created on the merge side with the resulting geometry.

2. Bob now wants to share with Ann with user A. F2 is pointing to the datum F1 generated during step 1.

• Datum feature F1 is embedded in the briefcase as a dependency of F2.

• On the merge side F2 is retrieved on user’s A model but will not be merged because a feature resulting from a deprecated share cannot overwrite its source. This way Ann does not loose the original external reference.

3. Finally Ann updates the external reference pointed by F1 and shares F1 again.

• The external reference is ignored again.

• On Bob's merge side, the datum F1 is overwritten by the newer version coming from Ann because a feature “shared deprecated” (the source)  always overwrite the version of the datum existing in the destination part.

Overwriting the content of a functional or geometrical set 

Normally when a briefcase containing a geometrical set or a functional set is merged in to a part that already has a copy of them, the list of features of the two versions are combined. For instance, if the briefcase contains a Geometrical Set named My Sketches that contains the sketches Sketch.1, Skecth.2 and Sketch.3 and the part contains the same set with the sketches Sketch.2 and Sketch.4, after the merge part will contain Sketch.1, Skecth.2, Sketch.3 and Sketch.4. More precisely: Skecth.1 is added to the part; Skecth.2 and Sketch.3 are replaced with the version form the briefcase; Sketch.4 is left untouched.

You can modify this behavior using the Share Assistant.