switch from hotlinked .pln to .mod in the middle of a project?

[Mats_Knutsson]

Hi,

I have a large hospital project with lots of .pln hotlinks and I'd like to change them to .mod. Is it safe or should I avoid?

/Mats

[Anonymous]

ejrolon wrote:
Also, you can try using GOs with a rule for Dims=Static to highlight that the dimension was not to the "pink" spot.

Very interesting thought. Are you sure that dimensions are becoming static when they miss point form hotlink? I did some quick test but this prop is not available for selection tool.

Ignacio wrote:
c local shocking pink hotspot —which will not disappear when things change

By pink spot, you mean Hotspot (Active Point) tool? This approach is ok but you still have to manage changes in dimensioning. Which is in some cases harder to spot than the whole chunk of dimensions.

[Eduardo Rolon]

IIRC on a update the dimension can become static.

[Anonymous]

ejrolon wrote:
IIRC on a update the dimension can become static.

Thanks. I will do some testing. This might be a way to identify those that are modified during an update.

[Ignacio Azpiazu]

kzaremba wrote:

Ignacio wrote:
c local shocking pink hotspot —which will not disappear when things change

By pink spot, you mean Hotspot (Active Point) tool? This approach is ok but you still have to manage changes in dimensioning. Which is in some cases harder to spot than the whole chunk of dimensions.

If overall dimensions don't change, there is no need to manually update that necessarily 'static' (unlinked to module) dimension point even if the module element changes or the hotlink gets redirected. And there is no way out of having to manually manage that dimension point if you want it to allow that hotlink to get redirected or that overall dimension to change, so the question is how to best manage that situation.

Attachment shows screenshots with no GOC on the left and static highlighter GOC on the right; bright hotspot, on the same string a non-associated point without pink hotspot just for illustration, and two associated points. The very visible bright pink hotspot makes it obvious the dimension is tied to it and not to the overlapping element in the module, so it makes things easier to handle, regardless of GOCs; and it tells you which is is the point that needs to be manually managed (see attached; GOC will highlight the whole string, and will still not tell you which is the static point). That bright hotspot is a drafting element doing the job the module element cannot do on the host file, not a quality control aid such as that GOC.

Things would still work with that overall-dimension-helper hotspot in the module. But managing that would be trickier, because the person working on the module might not remember the purpose of that hotspot and delete it during cleanup. That hotspot should best be on the same file and layer as the overall dimension. One will not need that hotspot the day the AC dimension tool offers the option of assigning a custom screen-only marker to static dimension points.

[Anonymous]

Ok, I found it. The naming convention of those props is sometimes confusing

I have tried to replicate situations when we lose dimensions but I didn't succeed. However, if I deleted elements and associated dimensions stayed active anyway. I assumed that most situation like this is related to change of element GUID in the hotlinked file. It would be good to know how AC associates dimensions to element maybe there are some possibilities to avoid operation that breaks the connection between Element and Dimension (for sure Create, Delete, Split does).

I really don't see the benefit of the hotspot. I'd rather double check dimensions when 2d drawings are about to be published. Since possibilities of editing Dimensions improved you can skip hotspot's imo.

[Ignacio Azpiazu]

kzaremba wrote:
I really don't see the benefit of the hotspot. I'd rather double check dimensions when 2d drawings are about to be published. Since possibilities of editing Dimensions improved you can skip hotspot's imo.

The advantage of the hotspot is that it very visibly tells you which one is the traditionally-untraceably-static-now-associated-to-hotspot-instead dimension point, and reminds you that dimension point should tie to it and not to the module element. This is a very traditional procedure, used also say for top of wall level dimensions in sections and wall sections where you don't want your dimensions to disappear whenever a wall element gets replaced or a module redirected, stair section dimensions where you know your landing levels but will keep on changing the model elements, etc.

You might see the benefit the day you get tired of looking around for static dimension points (not strings) for which you have no visual feedback, forgetting and linking to some module element a dimension point which should remain 'static' (unlinked to module) and later discovering that it disappeared, some draftsman fixing that in a rush by adding a new dimension point to the module thus fixing nothing and creating more missing dimension points and burnt man hours for the future, checking and missing stuff. It shouldn't take long.

At least, this is the procedure I have long successfully used to avoid the problem you are having. You are free to explore any other path.

[Erwin Edel]

We use hotspots for linked dimensions that are easy to adjust too for those cases where it is easy for the link to break.

They're also great for acting as stand in for the grid with repeating modules, since you don't want the grid in your modules, but you might want a dimension string in there.