Ok, in the last article we described the very beginning of the master part definition. In this article, we'll take the master part further, until it is defining the extents and lines of the most important components of our feature stair. Note that analysing a project in order to determine what's 'important', and what's mere 'detail' is an important skill in itself. Luckily, if you work in the same domain area, you'll find that getting the logical order right will become second nature. In our model, we're defining the nosing line, tread extents (not their innards), stringer and tread supports, concrete floor extents (defining the stairwell cavity), the stanchions, and the glass lines - in that order. The most important thing to remember in an application like Inventor is that it's important to model stuff in their logical design order. For instance, in the components mentioned above, the treads determine the lines of the stringer, not the other way 'round. This makes logical design sense, because the function of the stringer is to support the treads.
OK, enough abstract talk, let's return to our modelling exercise. The figure above shows me taking a 90x250 PFC profile block from my library, constraining the appropriate corner to my stringer line, and sweeping it down. Sweeping is very handy in architectural modelling, especially when you are using mitred joins between sections of a stringer or handrail. Don't worry about breaking up the mitred sections for fabrication at this stage - that's the kind of detail best delegated to the end of the modelling process. Note that I could well have simply swept a 90x250 rectangle along that path, and delegated the definition of the profile until later on. In fact, in another more complicated U-shaped stair in this project, I did just that. In this case, the design is relatively simple so I don't mind taking a 'short-cut' directly to the actual profile of the member.
In the figure above, you can see that I've mirrored the PFC member laterally, and combined with the tread blocks and the concrete definition, we have something that's beginning to look suspiciously like a staircase.
In the next image, we're a few steps further. I'm not going to describe the modelling in detail as to how we got here as it really would make the case-study too long and tedious. However, I'll mention a few of the key points:
- A face-fixed stanchion layout using simple rectangular cubes has been defined. The stanchion blade profiles happen to be 16x65, and they're face-fixed to the stringer and the void edge. The details of their fixing are determined by engineering requirements, and you'd better consult a structural engineer if you're interested in this kind of thing. These tutorials are not meant to imply any recommendations whatsoever on how your stairs or balustrade should be engineered!
- We're running glass centred on the stanchion lines, so the details of the stanchion fixings, combined with the stanchion dimensions, determine the offset of the glass line to either the stringers or the concrete void-edge. The handrail also has been specified to share this centre-line, as it is positioned directly above the stanchions on pins. Working out these offsets (either with a sketch or a calculator) enable us to define the balustrade centre-planes. You could easily work with some other guiding planes, but I usually find centre -lines/-planes to be the easiest to work with.
- Whenever we identify a repeating detail (such as a stanchion situated between two glass panel edges), we take care to define it using a block. If you notice a bunch of stanchions are all going to be same length, then define the length once (e.g. via a block, a parameter, or a common work plane) and re-use it. The key rule is define every measurement or detail once and only once, and then re-use it! If you define things like offsets between stanchion blade sides and glass repeatedly and haphazardly, you're more likely to be inconsistent and you'll find it a lot harder to change your mind about things later on.
This final image is just another shot of the model in the same state as it was before. You can see a few things in this screen-shot. Firstly, you can see I've taken care to line up the stanchions on the lower floor and on the flight. Whenever you can achieve some form of regularity, it's usually a good idea from an architectural point of view. You can see poking above the last stanchion some sketch lines describing a CHS handrail profile and a 150mm pin sticking up from the top of the stanchion. We haven't bothered to put the pin details on our stanchion markers, but we did need to draw these components at least once to define the top of the stanchion. This is because our starting point was the total handrail height (1080mm on the level and 900mm (measured vertically) on the rake. You can see a few reference lines as I worked this out. The length of the stanchion body is basically long enough to reach the bottom of the pin. The bottom extent of the stanchion is determined by an offset either to (a) the concrete floor (b) the bottom face of the stringer or (b) the thickness of the bulkhead on the top floor.
So at this point, we're very clear in our minds that the handrail + pin definition, combined with whatever defines the bottom limit of the stanchion, determines the length of each stanchion.
A final point is that we haven't bothered with defining the flat cut and base fixing plate definition of the stringer with respect to the concrete floor. There's no real need, as it doesn't affect any other aspects of the design. We could always define the design to include either a recessed base plate, or one flush with the floor. So this is a detail safely left to parts towards the 'leaves' of the model hierarchy.
OK, to sum up, we've added quite a lot of important information to our master part, and we've avoided introducing details as much as possible. We're well positioned to start defining many of the 'real' components by either elaborating on, or defining with respect to, this reference geometry. Because we're using solid bodies to define out much of our layout information, I guess you'd call this 'muscular modelling' rather than 'skeletal modelling' . However, I don't think it's a problem to mix and match these approaches in a single model as appropriate.
Published on: 03-Aug-2010. Topic/s: 3D design technology