Results 1 to 10 of 13

Thread: Making those pesky constraints behave

Threaded View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Member
    Join Date
    2009-07
    Posts
    5
    Login to Give a bone
    0

    Default Making those pesky constraints behave

    MAJOR UPDATE
    =============
    I have edited this post from its original form to update a major discovery I have made.
    =============

    The constraint system in Revit isn't the best, nowhere on par with Solid Works, and it was constantly driving me nuts telling me that my constraint system was invalid when it clearly was not.

    So I set out to figure out how to tame this problem, and this is what I have found so far:

    Rules to make parameterized constraints "behave":

    1. Always attach parameterized constraints to planes. Just do it. Things are complicated enough without doing so.

    2. You cannot LOCK a dimension between two planes if those two planes already have dimensions relative to each other, even if those dimensions are ALL unlocked and even if they exist in other views.
    (Exception: if those dimensions are of the 'equal spacing' type, and equal spacing has ALREADY been enabled.) Error: "Locking this dimension would overconstrain the sketch." You should therefore avoid unnecessary dimensions.



    3.When a dimension is assigned a parameter, or when an assigned parameter changes value, Revit always tries to move the "preferred plane" of that dimension, UNLESS that plane is DIRECTLY PINNED. What "preferred plane" means I'll explain presently.

    If you dimension two objects, then assign a parameter, revit will always move the preferred plane, unless you PIN it, in which case the other plane will move, as expected.

    If, however, you lock the preferred plane to another object that is pinned, Revit is unable to detect that the preferred plane has been pinned by proxy and gives a "Constraints not satisfied" error, even though it could move the other plane to solve the constraints. You have to be careful with the "pinned by proxy" concept, because you may need to go back quite far in your constraint system to find out that a certain plane is actually pinned in place.

    Be VERY careful about adding pins, because it is easy to break your design simply by adding a pin. Try to decide on one and only one plane to pin in each axis, pin it early, and stick to it. If you do have to add or move a pin, carefully check each and every parameterized constraint to be sure it behaves as you expect.



    A good example of when this crops up is when you want to have two planes equidistant around a pinned center plane. (This is exactly what you very often do first, before doing anything else.) If you have the two movable planes drawn around the center pinned plane, then dimension them equally, then draw a dimension from the center plane to one of the outer planes and attempt to assign a parameter to that, the assignment will fail if the preferred plane of that dimension is the center plane. The solution, or course, is just to change things so that the preferred plane an outer plane (which may be complicated to do). Now it is the outer plane that moves when the dimension changes, and the entire system behaves as expected.

    So how do you know which plane is the "preferred plane"? Many times I thought I had this figured out and each time I was proven wrong. The best way to test is simply to create two planes, set a parameter, and see which leg moves. Here are some things you can try:

    a) In many views only either the left or right (top or bottom) leg will move, no matter what you do. If this is the case you have to dog leg. (See below.) This was originally the way I thought all views worked, but... nope! It's true about 90% of the time.

    b) Try connecting the planes in reverse order. (That is, click the right plane first when creating the dimension instead of the left leg first.) Sometimes works. Usually not.

    c) Try erasing one of the two planes (if you haven't already drawn dimensions to it -- otherwise you're just making more work for yourself), recreate it, but this time draw it from bottom to top instead of top to bottom. (Again, rarely works, but sometimes does.) You can try this in combination with #2.

    d) Switch to the opposing view. Normally you should draw all dimensions in one view, but sometimes you get the other leg to work by switching views -- left to right, front to back, etc.

    e) Draw a pentagram on the floor, don a black hat, and perform some black magic.

    If you can't get the leg you want to move, you can create a "dog leg."

    By a "dog leg" I mean creating a loop-back and adding an extra dimensioning plane. In our example, we want the right leg to move, not the left leg, so we create an extra leg to which we attach a new parameter, and attach that plane to the original plane at some fixed distance (larger than our parameter will ever become.) In this case, our parameter is 1'2" ... I'll pretend the parameter will never get larger than 2' and put a use 2' as my offset. Create a new parameter (legnth2 in this case), and give it the formula length2=offset-length. In this case, length2 = 2' - length. Then lock the dimension between the new plane and the plane you want to move to 2 feet. Now when you assign the parameter "length2" to the dimension, the left leg of that dimension moves, but it is attached permanently to the right most plane we originally wanted to move. Presto, problem solved.



    Finally, when you do your flex testing, it is better to flex each individual parameterized constraint by changing WHICH parameter variable controls that constraint and then changing it back. (Be sure you change it to a variable with a different but reasonable value.) Why? Flexing the design using the types box can actually hide some more obscure problems that you can otherwise catch.

    4. Constraints cannot be assigned parameters that have negative values. These will always fail because Revit will reverse the direction of the leg, measure it, find it to be positive (going the other way), and complain because that distance is not negative.

    The solution to that is to use a round-about extra plane as shown above. Simply dimension a plane far out in the negative direction, then create a new variable "newvar=offset-oldvar", and assign that to the distance between the extra plane and whatever it was you wanted to move. So long as the offset is larger than the magnitude of the most negative value oldvar will ever attain, you are OK. Notice that the factory does this in many of their framing families: the extensions on framing members can be negative, and they use a 10' offset. If you try to assign an extension more negative than 10', those factory families will fail.

    5. If you want to align an extrusion to something else in your family, you usually cannot do so if that extrusion contains constraints or has curved sides. The reason is that revit tries to resize the extrusion instead of simply moving it, and it never seems to correctly resolve the restraints internal to the extrusion. Curved sides will not snap to anything anyway.

    The solution to this is to place the extrusion in a group and place a few reference planes in the group editor mode along with the extrusion. When you draw the extrusion, draw ANOTHER SET of reference planes in that mode too. When you are done, align the reference planes in the extrusion path mode to the reference planes in the group, BUT DO NOT LOCK THEM. If you lock them, Revit will complain. You do not need to lock them in place anyway, because the entire system resides in a group that will move as a whole.

    Now when you exit the group, you can align the entire group using the reference planes in the group, as they will be visible outside the group editor. (The reference planes in the extrusion are not visible from outside the group editor.)

    6. Do not directly parameterize model lines in extrusions. This probably applies to groups as well, but I haven't tested it. Instead, parameterize planes and lock model lines to the planes. If you don't do this the worst possible nightmare may befall you: the parameter may appear to work in the family editor, but when you attempt to load the family for actual use, loading types may fail! This has happened to me and it was very frustrating to diagnose.

    7. When creating arrays, place the objects to be arrayed into a group first, add some reference planes, and then align using the references planes to the project. If you do not do this you may also have a family that works in the family editor but not in the project.

    With this information I have had MUCH more success building families. I hope it helps you too. Maybe the factory will work on the constraint engine and make it a little more robust. (Maybe they can steal that part from Inventor?)
    Last edited by confirm2; 2010-03-05 at 04:17 AM. Reason: Found how "up" is determined

Similar Threads

  1. Making Revit Behave... Possible Wishlist Item?
    By ronsarlo in forum Revit Architecture - General
    Replies: 7
    Last Post: 2012-01-12, 07:08 PM
  2. 2011: pesky radius
    By fwaldropii in forum Revit Architecture - Families
    Replies: 4
    Last Post: 2011-07-08, 06:43 PM
  3. "Constraints are not satisfied" message when making grid lines equal
    By rachaelferrill in forum Revit Architecture - General
    Replies: 1
    Last Post: 2009-09-04, 09:13 AM
  4. Making Rope and driven constraints
    By stalljeffman in forum Inventor - General
    Replies: 2
    Last Post: 2006-10-11, 01:21 PM
  5. Help reassigning that pesky F1 key
    By BrenBren in forum AutoCAD FAQ (Read only)
    Replies: 0
    Last Post: 2006-08-31, 01:06 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •