Control anchored elements prior to equalizing dimensions

[jkidder]

Often when I want to equalize elements (especially a single modeled element) between two points either an element I don't want to move moves.  When I have a single item in the middle of two elements I expect the item in the middle to equalize.  Oddly enough, Often I have to draw detail lines for all the pieces, equalize those (which always works as I expect), then align the item to the line and then delete the lines.  

The anchor button, which sounds ideal for stating which items move, is only available after equality constraints have been set, and only allow one anchor, when a basic equality constraint would demand two. I see two components to a solution:

Main solution

Whenever an equality constraint is set make it behave as it does with detail lines, equalizing the items between those at the borders.

Provide control

Provide a way to specify what moves and what doesn't when equalizing.  Right clicking and specifying on a witness line point might work, but would be time consuming.  Ideally there would be a (well documented) way to do this when setting up the dimension string, such as:

The first and second click set the borders of the dimension string that will be used as the equality constraint, additional clicks identify the items to be aligned by the constraint. All items within the borders will be a equal fraction of the items, items outside those borders will be distributed at the same fraction.

[lionel.kai]

Could you provide an example where you see the end moving instead of the center? I wouldn't expect that behavior unless you pinned the left two (oddly enough, I tried pinning the center only and it moved the left one OUT instead of the right one IN, but that may vary based on a number of factors).

EDIT:

BTW, the "anchor" seems to be more of a temporary dimension thing (which is why there's only one).

and a related idea:

http://forums.autodesk.com/t5/revit-ideas/dimensions-that-equalize-setting-out-in-a-single-dimension...

[jkidder]

It's hard to define exactly what causes it not to to work as expected, but I'll give some examples of where I've had it occur.  It doesn't happen every time I try to do those things, and happens in other situations, enough to be annoying:

• The one that caused me to write this request was a plumbing element that needed to be centered between two pieces of equipment in a linked model.  Revit won't let you constrain things to a linked model, so I drew some quick detail lines to represent the center of the equipment, then tried to equalize the dimension to center the plumbing element.  One of the border lines moved instead.  I used a third detail line to represent the plumbing fixture, equalized it as expected, then had to move the plumbing fixture to that line.
• Spacing opening center lines: Since I use curtain walls for windows I don't have a center alignment.  Detail lines get drawn to represent the windows, then dimensioned between walls at either ends and the lines.  Sometimes, a wall moves instead of the lines.
• Centering equipment over a curtainwall: Both sides of the storefront are selected as well as the center line of the family.  The curtain wall extends or, if grouped, Revit will give an error because it can't modify the group outside of group edit.

[lionel.kai]

When you say it doesn't happen every time, does that mean if you undo and try to create the equal constraint again, you see a different behavior? Just wondering if you could do a screencast and/or an example model with a condition where the aberrant behavior occurs consistently...

[jkidder]

It's always consistent for the condition I'm trying to achieve, it just might work on one location and not in another similar location.  I haven't done screencasts before, I'll look into it.

[lionel.kai]

So could you purge down a model to the elements & views in question and have the two dimensions there, ready to be EQ-constrained - one that shows good results & one not.? Then I'll see if I can verify the results on my machine to make sure it's not machine-specific. Could try upgrading the model also, to see if it's version-specific... but the ideal situation would be to come up with a step-by-step procedure that could be reproduced (from scratch, using the OOTB template or "None") to cause the behavior, which would determine if it's model-specific (or even related to your template).

BTW, Screencasts are awesome for in-house training videos as well as illustrating issues for Autodesk Support - sometimes I can write the most detailed description of the problem, but the tech doesn't understand until I make a screencast. Also, we used to do in-house Revit meetings where I would go over concepts and various tips, but not everyone could always attend, and my after-meeting summaries aren't always easy to read, or I'd forget what I wanted to show by the time the meeting came around. Now I just make a Screencast when something comes up & publish a link to our users! It's a very useful utility:

https://knowledge.autodesk.com/community/screencast

[jkidder]

I made a screencast.  It doesn't happen consistently enough to provide steps from scratch.  This particular model is in 2017, but I've had it happen in older versions and different models too.  Every time resorting to detail lines to represent every element works as intended.

[sasha.crotty]

Thanks for taking the time to submit your idea. Unfortunately, this idea did not get the support of the community over the last 6 months and as such we will not be pursuing it at this time. Please feel free to rework (titles and clear descriptions are really important) and resubmit this one down the road.

[sasha.crotty]

Thanks for taking the time to submit your idea. Unfortunately, this idea did not get the support of the community over the last 6 months and as such we will not be pursuing it at this time. Please feel free to rework (titles and clear descriptions are really important) and resubmit this one down the road.

[Anonymous]

This bug is driving me insane and still present today in 2020. I get that as a "feature" this doesn't have community support, but this is not a feature. This is a bug. When Revit gives us no option to snap to fractions (archicad allows you to snap to 1/3 or 1/anything of any element) or even to divide a simple detail line, which would suffice as a workaround, we are forced to use the equal in dimensions for a lot of things we shouldn't. And when it doesn't work as it should it is absolutely maddening. Why on earth would equal move the outer-most element? That's not how the tool is supposed to work. Please fix this annoying bug!

[Brandon.Stevens.SG]

I'm currently experiencing this behavior in 2021. A fix would be appreciated.

[zwebber24]

Apparently, at least in the case of detail lines and angular dimensions, the direction you draw your line in makes a difference. I was running into this issue while attempting to segment an arc into equal parts and discovered this by accident. It does not appear to make a difference for linear dimensions. If you draw all the lines you intend to space equally in the same direction the tool works as intended. If one of your lines is drawn in revers things get all catawampus. I only tested this work around with drafting lines so I'm not sure if the same behavior occurs with other model element like reference planes or not. Hopefully this screencast works. I've never used one before. 

Equality Dimension Bug with Angular Dimensions R2020 

[paulMDarc]

Has this been resolved yet? I'm surprised we even have to ask for this. I feel pretty stupid explaining to teammates that this isn't possible. Kind of pathetic, to be honest.

[wschaffner]

Has this been addressed in newer versions? Currently working in 2021 and still have the issue, even with detail lines. 

Unfortunately, pinning the outer lines does not work to keep them in place. Somehow they still move.