Sweet! I've never been summoned here by name before. Pressure to perform...
I'll start with a couple of general statements:
1) In my opinion, MPC truss design has evolved, in Darwinian fashion, to just the right level of complexity. It's working.
2) In a typical building employing MPC trusses, those trusses are usually the most thoroughly engineered components of the structure by a considerable margin.
Now for the cast of characters:
The engineer that the EOR wants designing his trusses
This is a knowledgeable, grey haired fellow with a graduate engineering degree and an SE license. He sits around skillfully designing your trusses one by one. He doesn't exist, and he never did. Back in the pre-computer era, fabricators had big books of canned designs that they adapted to specific situations. It was almost unheard of for a fabricator to have a P.Eng. on staff. I can tell you, with absolute certainly, that MPC trusses have never received more PE attention than they're getting nowadays.
The truss fabricator's engineer
In years gone by, this was almost unheard of. Nowadays, most good sized truss manufactures will have at least one PE on board. However, that PE is not designing your trusses. Rather, he's implementing QC and dealing with non-standard design issues. Even with a PE on board, most of the drawing stamping will still be done by an engineer working for the plate supplier.
The plate supplier's engineer
This truly is the guy that you'd want designing your trusses. he's as educated as you are and is the Fazlur Khan of his realm. Trouble is, he's way too valuable to be designing all of your trusses one by one. Instead, he stamps hundreds of MPC trusses every day that are sent to him already designed by the fabricators truss technicians. This engineer's primary responsibility is to check that truss design input has been entered correctly. As an EOR, I like this. Garbage in, garbage out is our usual software complaint. The plate supplier's engineer is the final gatekeeper preventing the garbage from getting in.
The truss fabricator's technician
This is the guy that takes a lot of flack around here. And he may be just as scary as you think. When I first started being this guy, I was an education major working part time at a truss plant. I started working in the shop where the 3:4:5 rule was a useful tool for squaring the jigs. With my arcane knowledge of SOH-CAH-TOA, I was able to dazzle my colleagues by extending the 3:4:5 rule to other situations like 5:8:9.43. It was great. I felt like Ender in Ender's Game. This is how I got the design gig when it opened up.
From the EOR perspective, the design technician does not usually know as much engineering theory as you'd like him to. However, in conjunction with the other professionals involved, he gets it done. More importantly, the technician is an invaluable member of the team. Among other things, he knows:
1) All of the code provisions applicable to MPC trusses.
2) How to optimize MPC trusses for fabrication.
3) How to manipulate software to address the important engineering issues associated with MPC trusses.
4) How to anticipate the needs of framers in a way that your average EOR does not.
A good truss design technician is an essential bridge between the EOR and the framers who will put the building together.
The software
Modern truss design software is very sophisticated. Truly, it's almost dummy proof. The important part is obviously the data input. The software is set up to carefully guide the user through the required input for environmental loads etc. Working through the input screens isn't all that different from reading ASCE7, just with better, more targeted formatting.
The real issue with most EOR concerns about the MPC truss industry is that the truss designers rely very heavily on their software. Personally, I'm fine with it. As I mentioned above, there are check and balances built into the system. And, on a more fundamental level, I think that's it's naive to think that our entire industry will have any choice but to rely heavily on our software.
Either we're able to trust our software or we'll have to stop using it altogether. Most of the output checking that gets done in practice is either fictional or woefully simplistic. I expect you'll object to that last statement CEL. You're one of the few engineers that I'll concede probably is checking computer output carefully. You're not a very representative data point however.
At many premier firms that crank out a lot of high-rise concrete work, you'll find a cadre of people who basically just run shear wall ETABS models all day long. I've worked with several that had graduate engineering degrees and years of experience but couldn't detail an unconventional concrete connection to save their lives. These people are also technicians. And like all technicians, they're efficient, useful, and require some supervision. My point is that the EOR world is every bit as plagued by the technician / software dilemma as the MPC truss world.
The greatest trick that bond stress ever pulled was convincing the world it didn't exist.
