Tool_maker, In a perfect world, we would document everything everytime, but it's not always practical. In a large organization, thourough documentation is necessary to handle the logistics of communication. In a small mom-and-pop shop, you can get away with a certain amount of "mental" documentation because direct communication with those who know the details is easier.
This can be taken to extremes on both sides of the continuum. I used to work for a huge multinational conglomerate. We documented ourselves to death, literally. It took seven signatures and half a day to get an ECO approved and documented. That's IF I walked it through myself. The normal lag was about two weeks.
On the other hand, if you lose your human capital who happens to be the sole keeper of odd knowledge for a given project, good luck making heads or tails of it.
You have to find that balance of productivity and proper documentation with which you are comfortable.
This is all over my head so I am way out of my comfort zone here, so if this question does not make sense just consider the source. 99% of what I do is mechanical and when I complete a design and the device is built, it is subjected to a run-off, often with the customer present. If changes are made, the drawings get updated and the alteration is logged. That way if I run into a similar design, I have a record of what did not work and how we corrected it. Is that done in your field as well or would someone else have to go through the whole trouble shooting procedure you just spelled out?
One of my co-workers is so tunnel visioned that he thinks the only important thing is to make the device work. As a result, many alterations may occur with the only record being what he retains between his ears. It drives me crazy, but his family owns the company, so I deal with it.
Good point, Greg. These Sherlock Ohms stories are famous for showing how design engineers have to dispense with all assumptions and dig into areas that could easily get overlooked. If you have any of your own Sherlock stories, please send them along to: email@example.com
Very nice fix; I like your troubleshooting methods and the way you tracked down the glitch. Your example is a valuable lesson for embedded designers who almost always have to figure out concessions with I/O.
Truchard will be presented the award at the 2014 Golden Mousetrap Awards ceremony during the co-located events Pacific Design & Manufacturing, MD&M West, WestPack, PLASTEC West, Electronics West, ATX West, and AeroCon.
In a bid to boost the viability of lithium-based electric car batteries, a team at Lawrence Berkeley National Laboratory has developed a chemistry that could possibly double an EV’s driving range while cutting its battery cost in half.
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This discussion will examine what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.