I agree with your assessment about documentation gsmith120. It pervades all aspects of industry. One of the secrets to my success as a test engineer was that I documented my code (lots of comments). Whenever I needed to troubleshoot or upgrade a system I had built three years prior - I could very quickly determine how to accomplish the task. Documentation is very painful up front but it sure can solve a lot of potential problems in the future!
Nancy, don't get me started about poor technical documentation. I must admit I'm a stereotypical engineer and don't like documenting but it is a necessary evil. Getting my masters in systems engineering really trained me in creating good documents as well as taught me how to proof them. Creating good documentation is very difficult, time consuming and really hard to get a lot of engineers to do. Believe it or not most of my clients do a really really poor job and most of the time it isn't even on the list of important things to do. So the fact that the reset switch wasn't documented isn't a surprise. In some cases companies do this intentionally so the customer is required to return the product so they can be charged a fee. On the other hand, companies don't find it important enough to have documents reviewed and/or the reviewers don't take the necessary time to ensure the appropriate information is in the specific document.
I think the difference is the fact that the engineer could put it back together. Also interesting that taking something apart often is exactly what voids the warranty. Still neat to see it get put back together and working.
Sometimes I wonder in cases like this if the company isn't banking a little bit on service dollars. So they don't want it to be fixed by someone at home. kind of annoying, really. I'm glad that the service line you called gave you the little hint to help you out. But that doesn't always happen.
You could be right. Something added after everything was set to go to market. However, a little sheet of paper could have been added in the back of the manuel to help out savvy tech-EEz like this gentlemen.
It sounds like the documentation was poor to begin with. I am also wondering how many other features for servicing are generally hidden from the public. I have noticed on other products that have a reset function available through a small hole that is placed unobtrusively somewhere that it is not always documented. An older computer comes to mind where the CD drive would not eject. A phone tech support guy directed me to the fix. I agree that an after-design add on for all the reasons you stated is very possible for this scenario - how hard would it have been to add it to the accompanying documentation as an insert and institute a documentation revision? Poor planning at its best...that church is certainly blessed to have a savvy engineer!
So was the resettable overload switch added to the build after the original design was sent to the manufacturing line to assemble some prototypes for testing? I suspect this is an "after the deadline" modification that was added either after review of initial tests, after a few failures in the field, or just as possibly, added for distribution in the US in order to comply with U.S. electronic device certification. If it was not part of the original design, it is possible that this little feature was added after the original manual was sent to the translators to generate the English version...
PTC will offer a virtual desktop environment for its Creo product design applications, potentially freeing engineers to run them from remote desktops on a variety of operating systems and mobile devices.
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 radio show will show what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.