RSS
Origin Story: How Standards Start
July 14, 2022
[starbox]
Today I have t
he pleasure of attending an AGMA Helical Gear Rating Committee meeting. On and off for the past 35 years I have been able to observe a great group of gear engineers debate the big issues and the minutia of helical and spur gear capacity. It isn’t always pretty, but it's educational. Standards writing has been compared to sausage making; we all enjoy the results even if we don’t want to know the ingredients in great detail.
The same can be said for gear rating software. In a previous post I related my sudden promotion to “gear expert.” Part of the job description in 1979 was writing your own software; commercially available gear rating software didn’t exist. Large companies had custom software for use on mainframes via punch cards but for everyone else it was manual calculation according to the standards book or, if you were lucky and had a generous boss, a homemade program on one of the just emerging personal computers.
You learned a lot about standards when you wrote your own program. Like just how tough it was to calculate an accurate J factor for bending strength – especially if your geometry wasn’t completely “standard.” It was frustrating to labor for hours on your code and have the program fail for a single misplaced symbol. Eventually I got my programs to run and produce results I had confidence in.
As soon as commercial software became available, I stopped writing my own, but, mindful of the errors possible through programming defects, I validated the results against previous methods, both manual and computer. Each generation of software takes us further from those individually tested methods, however, and increases the risk of problems going undetected. All the sophisticated analysis routines in the world can’t make up for faulty reasoning or misapplied logic. Pretty output screens and lots of figures to the right of the decimal point do not absolve the engineer of his or her duty to verify the results against real-world experience.
The late Don McVittie was fond of saying “In God we trust; all others bring data.” Computer calculations are not “data” unless there are physical test results to back them up. Beware of software that promises to make testing unnecessary. Well-known aerospace projects have been publicly humiliated by glitches real-world testing would have caught.
Department of Corrections: An earlier posting incorrectly identified Al Swiglo as head of the AGMA metallurgy committee. While he admits to being a “senior” member in terms of years, Al is “only” the committee secretary. I apologize for the error.
he pleasure of attending an AGMA Helical Gear Rating Committee meeting. On and off for the past 35 years I have been able to observe a great group of gear engineers debate the big issues and the minutia of helical and spur gear capacity. It isn’t always pretty, but it's educational. Standards writing has been compared to sausage making; we all enjoy the results even if we don’t want to know the ingredients in great detail.
The same can be said for gear rating software. In a previous post I related my sudden promotion to “gear expert.” Part of the job description in 1979 was writing your own software; commercially available gear rating software didn’t exist. Large companies had custom software for use on mainframes via punch cards but for everyone else it was manual calculation according to the standards book or, if you were lucky and had a generous boss, a homemade program on one of the just emerging personal computers.
You learned a lot about standards when you wrote your own program. Like just how tough it was to calculate an accurate J factor for bending strength – especially if your geometry wasn’t completely “standard.” It was frustrating to labor for hours on your code and have the program fail for a single misplaced symbol. Eventually I got my programs to run and produce results I had confidence in.
As soon as commercial software became available, I stopped writing my own, but, mindful of the errors possible through programming defects, I validated the results against previous methods, both manual and computer. Each generation of software takes us further from those individually tested methods, however, and increases the risk of problems going undetected. All the sophisticated analysis routines in the world can’t make up for faulty reasoning or misapplied logic. Pretty output screens and lots of figures to the right of the decimal point do not absolve the engineer of his or her duty to verify the results against real-world experience.
The late Don McVittie was fond of saying “In God we trust; all others bring data.” Computer calculations are not “data” unless there are physical test results to back them up. Beware of software that promises to make testing unnecessary. Well-known aerospace projects have been publicly humiliated by glitches real-world testing would have caught.
Department of Corrections: An earlier posting incorrectly identified Al Swiglo as head of the AGMA metallurgy committee. While he admits to being a “senior” member in terms of years, Al is “only” the committee secretary. I apologize for the error.
