Truss or not a Truss?

Michel60 · Friday at 8:52 PM

I've lurked around the site for a number of years now, offering my $0.02 occasionally (maybe two-bits with inflation and tariff). I now have a question for the group about a proposed truss profile for a residential project where my first reaction is a "hell no", see below. Its 45' long with a maximum depth slightly over 3'-4". To be fair to the truss designer they were asked by the client (without consulting me first, I was assuming that the area would be stick framed) to generate a budget so this is still a fictitious design right now to get to a preliminary cost. The "special trusses" are for a low-slope (<1:12) membrane roof, but the "girder trusses" support about an additional 12' tributary of a 3.5:12 slate roof.

So far I've only seen the profile summary, no calcs. But even with calcs saying it works I'm not inclined to accept the results. I can't imagine that typical truss design software can really handle this problem reliably. I know some of the regulars here have a pretty strong background in plate truss design so my questions to them are:
1) Do you see this as a legitimate truss profile (either typical or girder)?
2) If you do, can the common truss programs out there adequately design something like this?

Thanks!

Ron247 · Friday at 9:48 PM

I agree, even at the 4 plys, it looks inadequate. Seeing the calcs would be a must.

BAretired · Friday at 10:03 PM

Both of the selected designs appear much too shallow, but they should be checked by calculation, taking into account the actual dead and live load.
Truss programs used by fabricators should be capable of providing a reliable answer.

KootK · Friday at 11:35 PM

Michel60 said:
1) Do you see this as a legitimate truss profile (either typical or girder)?

It certainly raises my hackles a bit. I would like to see the layout that includes these trusses.

Michel60 said:
2) If you do, can the common truss programs out there adequately design something like this?

Sort of? In these situations, a check of the design drawing usually does indicate that everything is fine. Analytically, the software is fairly bulletproof.

The trouble, in my mind, arises with the fabricator's -- or anyone's -- ability to manufacture such a truss in accordance with the drawings and tolerance limitations. I have a bit of an edge in this department in that I've built a lot of prefab trusses, including some very aggressive ones like this. Here's what I see:

1) I think that everything looks fine on the right 2/3 of the span.

2) On the left 1/3 of the span, the webbing gets so congested that it's practically solid lumber. This creates the following problems:

a) Gaps between members that are trivial in normally proportioned trusses will get uncomfortably large. Very shallow web cuts are tough to do accurately at the saw.

b) Plating will require very large plates that are often very sensitive to accurate placement for their performance.

c) Truss software uses modelling algorithms that are more product specific and less obvious than your typical EOR FEM model. Member centerlines won't actually be on member centerlines, joints will be pseudo modelled to capture eccentricity, etc. The more congested things get, the less valid this model is likely to become.

Vetoing a truss that works according to the software takes some persuasion and finesse. Use the arguments above for the purpose.

RontheRedneck · Saturday at 12:25 PM

There's no way to make an intelligent assessment based on those tiny little pictures.

The OP said: "I can't imagine that typical truss design software can really handle this problem reliably."

That's utterly ridiculous. Designing trusses is what the software was made to do.

Two suggestions come to mind. One is to ask for an "in house" truss drawing. (Unsealed) That will give you a much better idea what the actual truss design looks like.

Second is to check total deflection. Ratios are unhelpful in situations like this.

Michel60 · Saturday at 4:20 PM

KootK said:
It certainly raises my hackles a bit. I would like to see the layout that includes these trusses.

Sort of? In these situations, a check of the design drawing usually does indicate that everything is fine. Analytically, the software is fairly bulletproof.

The trouble, in my mind, arises with the fabricator's -- or anyone's -- ability to manufacture such a truss in accordance with the drawings and tolerance limitations. I have a bit of an edge in this department in that I've built a lot of prefab trusses, including some very aggressive ones like this. Here's what I see:

1) I think that everything looks fine on the right 2/3 of the span.

2) On the left 1/3 of the span, the webbing gets so congested that it's practically solid lumber. This creates the following problems:

a) Gaps between members that are trivial in normally proportioned trusses will get uncomfortably large. Very shallow web cuts are tough to do accurately at the saw.

b) Plating will require very large plates that are often very sensitive to accurate placement for their performance.

c) Truss software uses modelling algorithms that are more product specific and less obvious than your typical EOR FEM model. Member centerlines won't actually be on member centerlines, joints will be pseudo modelled to capture eccentricity, etc. The more congested things get, the less valid this model is likely to become.

Vetoing a truss that works according to the software takes some persuasion and finesse. Use the arguments above for the purpose.

Very useful, just the kind of insight I needed. Thanks KootK.

Michel60 · Saturday at 4:44 PM

RontheRedneck said:
There's no way to make an intelligent assessment based on those tiny little pictures.

The OP said: "I can't imagine that typical truss design software can really handle this problem reliably."

That's utterly ridiculous. Designing trusses is what the software was made to do.

Two suggestions come to mind. One is to ask for an "in house" truss drawing. (Unsealed) That will give you a much better idea what the actual truss design looks like.

Second is to check total deflection. Ratios are unhelpful in situations like this.

I do appreciate the imagines are inadequate but they are what I have at the moment. Ultimately there well be a full design package produced and the suppliers that I work with are usually very good about getting me a pre-stamp version to review. This one just came in out of the blue when I had barley started looking at the possible layout and loading. Seeing that profile triggered that I needed a bit more background support here. My concern with software capability is based on my own limited knowledge of what underlying assumptions for geometry, member type definition, etc. that are baked into them. But hearing that they can potentially analytically address the problem is helpful. Now I just need to get that analysis married with the reality KootK describes and we'll see where that leads me.

Thanks Ron.

RontheRedneck · 2025-04-14T00:55:16+0100

KootK, I want to address some of your comments:

"Gaps between members that are trivial in normally proportioned trusses will get uncomfortably large. Very shallow web cuts are tough to do accurately at the saw."

I suspect saws have changed a lot since you were in the business. They're much more capable than when I started back in the 1980s. And we have the option of using a linear saw. (CNC saw, Single blade, board can be moved as the blade is cut)

We also change the webs to single cut in tight spaces.

"Plating will require very large plates that are often very sensitive to accurate placement for their performance."

The webs near the low end will likely require plates that are larger than average. But there are position and angle tolerances built into the software. And a 3X safety factor. So I don't see that as being an issue.

"The more congested things get, the less valid this model is likely to become"

If that were the case, I'm sure I'd know about it.

The software has undergone endless upgrades over many years. The modeling is based on full scale testing. It's light years ahead of the old pin joint modeling of 30+ years ago.

So I don't agree with much of what you said.

KootK · 2025-04-14T18:56:56+0100

RontheRedneck said:
So I don't agree with much of what you said.

Yes, I picked up on that. And that's wonderful. It warms my heart to see someone mounting a spirited defense of the metal plate connected wood truss industry. Historically, that role has often been mine on this forum. And that has somewhat deprived me of opportunities to wear my skeptical, EOR hat in these types of threads. We'll come back to your latest post but, for now, let's start with this.

RontheRedneck said:
That's utterly ridiculous. Designing trusses is what the software was made to do.

It's not ridiculous at all. In fact, I would argue that:

1) OP's skepticism of the software here is valid. There are reasons to fear that software purposefully built for the design of conventionally proportioned trusses will be inappropriate where [NOT [ Ix_truss >> Ix_chord]] as is the case with OP's truss.

2) OP's concern for the validity of the software here is the very hallmark of an EOR bringing real value to this kind of project. @Michel60 stands to do the very best kind of problem solving here: the kind that prevents problems before they become problems.

RontheRedneck said:
There's no way to make an intelligent assessment based on those tiny little pictures.

I contest that as well. The problem with these trusses, if indeed there is one, has to do with the ratio of Ix_truss to Ix_chord that I mentioned above. And that problem will not be ameliorated by the details of the innards of the trusses, whatever they are.

In a way, the tiny little pictures may serve a useful function here: they allow one to not lose sight of the forest for the trees.

Michel60 · 2025-04-14T20:51:16+0100

Thank you, I do greatly appreciate the encouraging words.

To elaborate a bit more on my initial questioning of the profile and it's analysis, I can understand completely the design concept of an assembly of metal plate connector- truss member - metal plate connector. It's when the boundaries of discrete elements start to blend and disappear that I begin to lose my understanding of what is happening in the program. The web elements start to blend, being both diagonal and solid filler between truss chords. There is probably some design analogy here with more conventionally proportioned trusses with raised heels where we get filler blocks placed and connected, but with this geometry are we out on the bleeding edge or beyond it? Is there something in the program's member/connector definition that is fundamentally different when the truss members merge?

KootK · 2025-04-14T21:19:23+0100

Michel60 said:
but with this geometry are we out on the bleeding edge or beyond it?

This will come down to judgment: yours. I would love to tell you that, at an [Ix_truss / Ix_chord = 4.719], now there's a problem. Unfortunately, as with most natural phenomenon, this will tend to operate on a continuum.

Nature usually favors a messy, analog dial over a binary on/off switch.

Ron247 · 2025-04-14T21:26:53+0100

I am more familiar with software design and debugging in general, than I am Truss software specifically. So, as they say, I don't have a dog in this fight. While I really value software and both use and write programs at times, there are some common issues I have seen multiple times.

I do get nervous when my model exceeds the "norm". There are so many simplifying assumptions, items not checked because under the norm, they do not control and other programming habits that can bite you and bite you hard. Here are 3 simple examples from real highly used software:

Structural analysis of loads in the Z and then in the X directions being drastically wrong (or vice versa). This was the first seismic model I ever ran. The net of my applied loads was in one direction but so were the net of horizontal reactions. Why? All the proofs used to check the program always did X first and then Z. If you input a model in reverse, the common array was not being cleared and it was one where you add your new value to one already present. Simple fix, but was wrong for a long time.
They had part of a calculation wrong. A value that was cubed was in the numerator but should have been in the denominator. (or vice versa). A guy I worked with discovered that. Why was it not caught? The proofs used all had the value to be cubed to be 1. 1 to any power is 1. Poor choice of the value to use in the proofs. Proofs should never be simple.
I was recently told an item I questioned is not checked at all by the design software because it never controls. I have already had 5 instances of proper use of the product but that item did control. Under "normal" circumstances, it never controls. These were not normal circumstances, but they are allowed circumstances for the product.

These are just 3 of many examples I know of, but in the end, I am sure all software has the "If we are wrong, it's YOUR problem" disclaimer." Now I am getting more concerned about the single ply one. While the truss software may be fine, I doubt it was ever tested to this limit but if it was, that speaks very highly of them.

Oh yeah KootK, if I remember from 7th grade English correctly, you cannot use 'ameliorated and innards" in the same paragraph, let alone the same sentence. I had to get out my Thesaurus and I hate doing that because it is hard to get him back into his cage.

KootK · 2025-04-14T21:27:47+0100

Michel60 said:
Is there something in the program's member/connector definition that is fundamentally different when the truss members merge?

Nope, not really. And, fundamentally, that's the problem.

This will be painfully familiar to anyone who's attempted to model and design a vary shallow truss with big chords as shown below. One will observe the following in the shallow truss:

1) Lots of shear in the chords rather than shear expression as axial force in the webs (similar for moment). The truss software ware will pick this up.

2) The webs, and more critically the plates, will pick up moments not reflected in a model where the webs are pin-ended. Truss plates are not great with moment. tension perp to grain and all that jazz. The truss software will not pick this up.

3) Small amounts of shear slip in the web to chord joints will push things further in the "bad truss" direction and begin to invalidate traditional deflection estimates. The truss software will not pick this up.

Ron247 · 2025-04-14T21:51:31+0100

Kootk, could you clarify what you mean by Ix_truss and Ix_chord. I assume they are Upper case "eyes" and not lower case "ells". I am assuming the ">>" indicates "much greater".

I assume there is some Span/Depth ratio that works handily but severe deviations may not be so as predictable.

KootK · 2025-04-15T03:07:31+0100

Ron247 said:
Kootk, could you clarify what you mean by Ix_truss and Ix_chord. I assume they are Upper case "eyes" and not lower case "ells". I am assuming the ">>" indicates "much greater".

Correct on all counts.

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

Truss or not a Truss?

Michel60

Structural

Recommended for you

Ron247

Structural

BAretired

Structural

KootK

Structural

RontheRedneck

Specifier/Regulator

Michel60

Structural

Michel60

Structural

RontheRedneck

Specifier/Regulator

KootK

Structural

Michel60

Structural

KootK

Structural

Ron247

Structural

KootK

Structural

Ron247

Structural

KootK

Structural

Similar threads

Part and Inventory Search

Sponsor