Years ago, on RCA's studio television cameras, which had dozens of adjustments for all the analog controls, we in the lab were having reports of "drift" of some cameras at a trade show. We'd tested all the cameras before they were sent to the show and they held their adjustments well for long periods of time. An engineer at the show was asked to look into it more closely, and he found that one of the managers had a "diddle stick" (small adjustment tool for the minature potentiomenters), and would periodically tweak things to see if he could improve the picture. This became known as "pot drift," and the fix was to disconnect all the front-panel adjustment pots for trade-show units, and replace them with internal ones. It was a lot easier to do that than to retrain the managers (often former engineers) to leave the adjustments alone!
We supplied a control system for dental ovens used to fire ceramic false teeth. It was surprisingly complex as we had to control temperatures up to around 1100 degrees C and also manage the vacuum level in the furnace chamber to ensure the correct colour and glossiness of the finished tooth. Getting the digital PID algorithm tuned correctly took a while and the customer was delighted with chart-recorder traces showing negigible overshoot. However, his service engineer complained that the read-out "showed lots of over-shoot". He was bothered that it might read one or two degrees more than the target for a few seconds. I promised to investigate, within a day came back with a software fix and the service engineer was delighted. I never told him that I had simply fixed the display so that it would never show a value higher than the target temperature. "What the eye doesn't see the heart cannot grieve over!"
We subsequently supplied several hundred sets of these controllers with no complaints and the business only stopped when their parent company went broke for totally unconnected reasons.
I had a disagreement with a programmer about what I decided was poor programming and a false error message. The machine had jammed, and stopped with a servo drive error. After reviewing the wiring, and failing to determine if the fault signal was active-high or active-low, I then decided to review the PLC program to find the logic for the error message. The trigger for the servo error was two cylinders being not-retracted at the same time - not the fault signal from the servo drive. And the cause of the jam was a race condition; instead of using a set of conditions to call the drive to index the machine, a timer was used. The two cylinders that created a servo error message when extended, were also driven by timers. The logic caused the machine to extend and retract the two cylinders AND index the machine almost simultaneously on Cycle Start, i.e. by pressing the Cycle Start button. The original programmer would not believe it when I tried to explain the situation. I decided to document the problem and submit it to my manager, and let the managers fight it out.
Quite s few yers back we had a machine that calibrated throttle bodies, and we delivered about three of them to the production area of a major US automaker. But the engineer in the plant was constantly playing with the servo parameters and often reached a point where the vacuum servo was either too slow or not accurate enough. After about 20 service calls to reset the servo parameters we decided to add a software servo digital control system, which we also calibrated. Unfortunately the same engineer could now play with the servo calibration from his office computer. So now he could disrupt the calibration without anybody knowing what was happening.
Our solution was to connect a stripchart recorder and record a demonstartaion of the system meeting all the specifications for accuracy and cycle time. With this evidence in hand we were able to be paid for the project's completion, and the twiddling problem was no longer our responsibility.
This is symptomatic of an all too common problem - customers all too often ask for levels of control that are beyond their capability. On the one hand they hire professional integrators to implement and commision their equipment, presumably because of their superior expertise, and then request an equivalent level of authority to modify the equipment. In some cases this is just plain dangerous although even when the result is simply damage to the machine, erratic operation or excessive process defect operations are at variance with SOP and therefore also dangerous. In some cases, a good defence is to ask the customer to sign a waiver against injury or warrantee costs where deep user access is to be provided - more often than not the customer folds at this point. Many's the time that equipment has been restored to normal operation by either restoring a known good set of recipe parameters or worse reloading control software with a known version.
I have faced even deeper situations where customers requested controls in the HMI even though they were not even relevant to the equipment or process merely because some other equipment in their factory lacked that particular control (which only serves to reinforce the point that the customer may request levels of control which they are not competent to employ). I always make it a rule to avoid unnecessary user adjustments because they will be adjusted but rarely in the way intended. I'm sure many integrators have dealt with the case where the equipment was performing badly because of inappropriate user adjustment - it's never seen as pilot error: it's always a 'problem with the equipment'. Twice I flew across the continent to a particular customer site where the machine was said to be 'broken', performed the documented setup and calibration procedure and had it up and running in less than half an hour - in both cases the machine had been 'adjusted' by engineers using priveledged access. The cover story was that I 'must have done something', the obvious cause of lost production being unpalatable.
True enough on that TJ! I did a similar thing to a peice of automation. One of the maintenance guys became suspicious and started experimenting. However, I noticed and added some additional logic that set off a warning notice that management was being informed of excessive changes to a critical parameter. Seems no one changed the placebo parameter again!
On a side note, I quickley realized that hidden buttons/sequences on an HMI are soon discovered as well. I am not sure, but it seems that some people like to touch these things for no good reason. It is like a game of find the "Easter" egg button?
It's a dangerous approach - eventually you'll encounter a maintenance person with some skill. When that person begins adjusting the placebo value and perceives no change, they will begin testing it systematically. An interesting phone call will result when they describe changing the value by orders of magnitude for no change of operation.
Festo's BionicKangaroo combines pneumatic and electrical drive technology, plus very precise controls and condition monitoring. Like a real kangaroo, the BionicKangaroo robot harvests the kinetic energy of each takeoff and immediately uses it to power the next jump.
Design News and Digi-Key presents: Creating & Testing Your First RTOS Application Using MQX, a crash course that will look at defining a project, selecting a target processor, blocking code, defining tasks, completing code, and debugging.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.