Copy of a dynamic component

Hi all,
The problem I’m having: I created the dynamic component (a metal tube with weight calculation), saved it correctly, and the parameters work… until I create identical copies (i.e., I multiply it on the drawing, which has the same definition as the solid component).
At this point, changing a certain parameter only affects the selected component, and selecting all identical instances changes all calculations except the last one, the one specifically for weight.
I’ll try uploading the “test” drawing and the dynamic component file below. Perhaps you have some suggestions.
In the meantime, thank you for your wonderful work and helpful advice.
PROVE.skp (66.0 KB)

I see what you mean, the formula for peso that is set to be =(VolumeUtile*PesoSpecificoMateriale)/1000000 is removed and replaced by the current value. Seems like a bug indeed

see this thread : Dynamic Attributes formulas getting erased trimble answered it is a “common error”, apparently…

thank you so much!

you’re welcome. they also said dynamics components are not meant to be modified all at once, so I’ll rewrite what I did before erasing my answer, because I did not quite get what your problem was at first, in case other users end up on this thread. It still is a good workaround :

dynamic components don’t work as normal components, consider each copy as already unique. Changing one parameter on one of them will only affect the one copy.

If you want all of them to be modified at once, you can create a component containing the dynamic component. for example, draw a line next to one of them, select the line and the dynamic component and create a component out of them. replace the others by this newly created component and at some point delete the line you drew. that way, if one parameter is changed for the dynamic component inside the repeated component, the others will also be affected.

2 Likes

Demonstrating what Paul described. The added edge could be closer to the DC or it could be deleted after creation. As shown you’ll have to open the top level component to get to the DC.
dc

2 Likes

fantastic… thanks guys

First: DCs are an extension, they are not built on the native code, so there is considerable disconnect. However, there are work arounds.

Any exposed custom attribute in the parent will cause this effect on collections, however the info attributes will update independently.
If the item is placed one level down, with the parent used as a vehicle or shield, the attributes will not be over-ridded with a value. With your example, seems overworked, which need to be (scale definition, check rotation) then componentize, then can change the length.
PROVE.skp (60.4 KB)

Consider a different approach, DCs work within the boundary box of the object(s), so objects at the boundary with axis inward will maintain their position, fix sizes maybe required. If an object has hidden boundary line(s) then its size can be maintained with a distance from the end of the hidden line.

DCs can be reused if they are totally made unique, use Eneroth’s “deep make unique” directly after copying. (very important)
Start with basic cuboid, for beams, columns, one dimension scaling, set up with hidden “axis” and shape one level down. Any DC with a DC child will update automatically whereas a lone DC with no DC children requires Redraw to update.
Scaling is important, so for one dimensional DCs always start with same (1m) length or make sure all parts are at scale=1
Rotation should be avoided initially, then should be isolated if more than one axis. so, a column can be a beam, but parent is rotated

Compared to the native report writer, the advantages of using OCL (opencutlist extension) is very high, so best to build items with length on X-axis, etc…

another point is not to use ‘Name" attribute but activate the instance name, this updates the option and entities dialogs. With changes in the latest OCL, can "read’’ DC attributes

PROVE 2.skp (35.4 KB)

2 Likes

2 Likes