Announcement

Collapse
No announcement yet.

Railings: Distance from Previous

Collapse
X
Collapse
 
  • Page of 2
  • Filter
  • Time
  • Show
Clear All
new posts
Previous 1 2 template Next
    #1

    Railings: Distance from Previous

    All,
    I am looking for a simple description of how Distance From Previous works with regards to Baluster Placement in a railing. Especially when dealing with a baluster and a panel between. The logic escapes me, and I know it is just me not thinking in an appropriately Revitish way.
    Ah, someday Stairs, Railings and Site Tools will all be lovely. In the meantime... :banghead:

    Gordon
    Pragmatic Praxis
    Tags: None
    #2
    For what it is worth I am trying to get this railing to give me a simple 4' spacing on the baluster, with the 3'-10" panel actually between the balusters. Very sure I am about to have a DOH! moment.

    Gordon
    Attached Files
    Pragmatic Praxis

    Comment

      #3
      You could create a baluster on each side of the panel, and set it´s type to "none" - Would have figured that those "none" existing balusters should both have a 1" offset, but for some reason that´s not the case. See the attached :whiskey:
      Attached Files
      Klaus Munkholm
      "Do. Or do not. There is no try."

      Comment

        #4
        But what are those phantom balusters even doing? I would think I could relate the panel to the real baluster just as easily (or hard) as to a phantom baluster. My head hurts.

        Gordon
        Pragmatic Praxis

        Comment

          #5
          I´ll be the first to admit that Railings are still done by trial & error here

          But, I don´t believe that you can control the gap the way you´re trying to accomplish it. The way I see it, you have two options:
          1. Create the phantom balusters as mentioned above
          2. Create the gap within the panel family
          Klaus Munkholm
          "Do. Or do not. There is no try."

          Comment

            #6
            Ive always believed distance from previous to be Origin distance, baluster to baluster. So if your panel is 3-10", and the balusters on each SIDE of it are supposed to be 4'-0" apart, it would be something like:

            Family: Dist. from previous:

            Post 2'-0"
            Panel 2'-0"

            Assuming, of course, that the origins of both are down the centerlines...
            Aaron "selfish AND petulant" Maller |P A R A L L A X T E A M | Practice Technology Implementation
            @Web | @Twitter | @LinkedIn | @Email

            Comment

              #7
              Yes, balusters are defined on center, are 2" wide, and should be 4' center to center. The panel is 3'-10", and also defined on center. So, seemingly the panel should be 2' from the previous baluster, and the end of the pattern 2' from the panel. But somewhere there is a 1/2" error sneaking in. The panel to panel dimension is correct, 4', as is the post to post dimension. But the panel starts 1/2" inside the post, and for the life of me I can't find any explanation.

              I am getting seriously close to a bunch of in-place families for the panels. The things we do to cobble together some work.

              EDIT: Well, here is something interesting. I just added end posts, with the Space set to -1", so pull the 2" wide post back into the railing properly. Guess what, the post sits exactly 1/2" proud of the end of the rail. Gotta be something wrong with that baluster post I think.

              Gordon
              Pragmatic Praxis

              Comment

                #8
                I ran into a similar problem with my current project. My half-ass fix was to use two separate railing systems on top of each other.

                Comment

                  #9
                  Oh, well now is a good time to bring this up: With some families, the "origin" isnt always where the reference planes are that say *defines origin*. If you want to test this, go in a family (Section heads work well), grab everything in the family INCLUDING the Reference planes that define the origin, and move it a whole bunch. Since the origin moved too, NOTHING should move when you load it in the project. Buttttttt, it does sometimes.
                  Aaron "selfish AND petulant" Maller |P A R A L L A X T E A M | Practice Technology Implementation
                  @Web | @Twitter | @LinkedIn | @Email

                  Comment

                    #10
                    And yet, arguable this is so not worth fixing. Right Autodesk?
                    Rhetorical question, dripping with sarcasm.

                    So Aaron, do you have a sense of what situations this happens in? Certain family types? Perhaps a bogus template? Or perhaps only when modifying certain OOTB families and starting fresh from a template solves the problem? If you have some sense of where to look, I would love to help document the issues. We could post here and make RFO even more helpful to people. And perhaps provide the list to Autodesk in hopes that the offending families/templates could actually get fixed.

                    Thanks,
                    Gordon
                    Pragmatic Praxis

                    Comment

                    Previous 1 2 template Next

                    Related Topics

                    Collapse
                    Working...
                    X