Enabling the customer to save face is brilliant - and probably accelerates the solution! My high schoo,l teacher used to find that errors in complex mathematical problems were usually trivial addition errors. His mantra was" Higher mathematics is never sufficient, one must be able to add and subtract". I suppose in electrical engineering, we might say "Follow the wire connections from end to end".
Been there... Doing some commissioning work on a OEM/customers site , ~ 2hr flight away. Everything would be setup up correctly, PID's all tweaked, decide to push some product through and some little niggly thing pops up ......
Get to 5:30pm and it's not quite working, frantically change the airline booking online , ring the wife, book a motel. Sometimes this would happen three days in a row! Motel is now on speed dial.
wrt to your examples:
Case1: And plugged into the correct connector! e.g. using the correct one when 2 com ports are available. And with USB ports, moving the serial dongle to another port (this changes the assigned COM port in Windows on the laptop that was being temporarily used to replace a broken HMI) . One machine has dual encoders at inlet and outlet of machine, the controller switches from one to othe r based on some algorithm, easy enough to swap the encoder plugs over, but one calibration is slightly different to other. Difficult to tell it's swapped over until the rare occasions when they attempt a roll change mid-job , then it gets really weird, (this might happen weeks after the original swapover).
Case 2: Hydraulic cylinders on left and right side, both always operate together , each has proximity switches. On about half the machines made the proximities were on the wrong cylinders, but you can't tell because they both move together, until one day when one cylinder jammed on a machine, resulting in really confusing diagnostic and self-test information from the controller, so they pull off the (wrong) cylinder - nothing wrong with it , put it back on - still faulty .... eventually they worked it out .
Case 3: Calibration menu: How about the operator stumbling into the calibration screen and pressing OK to exit rather than cancel, this then loads some default values and some zero's
Case 3: Operator does a calibration, but inadvertently loads the wrong calibration file. (they should just use the existing file, but you know how they are... and they deny everything..)
Case 3: frantic Phone call/email from operator: lengths seem to be inaccurate and getting slowly worse over several days,doing a calibrate didn't fix it. My reply: check the encoder wheel and coupling, and the spring (these cal errors are almost always related to encoder mechanical issues) . Frantic phone call second day , gave them the same advice, explaining in some detail where to find the appropriate screws to tighten. Then silence for a week, I gave them a courtesy call, and they said the encoder wheel fell off on the third day, and, after re-attaching it , everything worked perfectly.
One job of mine involved a lot of report writing for a database system installed in a large semiconductor company. In addition to writing the reports, I often had to field calls from users when things were not going well.
I can't count the number of times when the answer to a frantic call reporting "The system has bugs and it crashed" was "Turn... the printer... on"
I had a similar experience many years back involving a new dishwasher. My husband and I had just redone our kitchen and ordered new appliances in a matching almond color (this was before stainless steel became all the rage). The dishwasher was delivered and installed, and we realized that the front panel was white, it did not match the other appliances! We were freaked out, to say the least, and I had one hand on the phone ready to dial up Sears when my husband realized that the front panel could be slid out. Behind it were two other panels, in avocado and almond. So we were all set for all contingencies!
I had a similar experience with my first (and so far only) smartphone, but mine had to do with the camera. I could get good -- not great, but decent -- pictures with it sometimes, but any time the flash went off my pictures were horrible. After fumbling with the flash and camera settings for a bit, I had finally resigned myself to taking the phone back to the store when I noticed that one corner of the screen had a peculiar mark on it.
Upon checking further, I realized that the "mark" was where a bit of protective film had been roughed up a little. It turns out that when the salesman unboxed the phone in the store and put it into its case, he had neglected to remove the film. Every time the flash went off, the light was diffused through the film, which also covered the camera lens. Removing the film fixed the problem and saved me a little face.
Reminds me of a TV repairman story. Seems the picture suddenly became snowy, as the repairman was walking to the customer's door he glanced up at the antenna. There were several birds perched on it.
He told the customer the problem was possibly all those birds. Then he pulled the set away from the wall and noticed one wire of the twin-lead from the antenna had come loose (a fairly common problem). He re-attached the wire and got a nice picture. Meanwhile the customer had disappeared.
Suddenly he heard a loud BANG! The customer walked back in with a smoking shotgun and said "Got them pesky birds! Did that fix it?"
He got such a good laugh he did not even charge for the call.
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...