In retrospect, this seems like an obvious solution. But in the heat of a workday, when most people don't have time or simply don't want to watch a few cycles, I can easily see how this could happen. It's why engineers and troubleshooters have jobs.
The common assumption is to always blame the most complicated component. Auto mechanics seem to blame the "Brain Box" before looking for a vacuum leak. I had a new car that was running rough and several controls were replaced while the car continued to run poorly. Out of frustration I opened the hood of the two week old car and found that a wire harness had been burned clear through vacuum hoses and other wires. I informed the dealership that I would perform the repair myself, rather than have their ham-fisted blacksmiths crimp a handful of butt splices to the harness. I used new wires and solder.
From another thread, I had that car for 170K before giving it to a nephew who drove it for another 90K.
@Charles, I agree. Although it is not expected from an engineer to come up with a complain so quick. One can expect this from a technician whose job is only to run the machine. But an engineer is suppose to carefully see the pattern of the robot and figure out the discrepency in it.
I find it interesting that many posts suggest that the Engineer is the person that supposedly knows or finds the root cause. As an Automation Technician, I have often been in the position of having to troubleshoot to find the actual root cause, often having to prove the Engineer's guess to be wrong. And that annoys the Engineer.
As is usually the case, it is the individual with the greatest insight into the system who is able to solve the problem most effectively. Sometimes other get lucky and happen to arrive at the correct answer, and on rare occasions the solution is so obvious that a manager could see it. But usually it is the individual with the most accirate and complete insight who comes up with the solution.
I agree William, actually that insight is a product of both education and experience and comes with time. So it is actually quite normal as well for the technicians to come up with the solution or debugging the problem better then engineer who has just joined the company. We can not just put a label directly based on the rank of the profession.
Since the robot is not running on adaptive control, It will just run the commands it has been fed, it is definitely necessary that all of the inputs that are given to the robots at different times are carefully timed and accurate. Otherwise the error will keep on accumulating and then it will seem like that the robot is malfunctioning.
@taimoortariq – Well explained the input instructions and on time component is vital for the robot to perform its task successfully. We cannot blame the robot because it's just another machine and cannot think by its self.
My experience has been that once you connect a computer to something, it is percieved that only the computer can fail.
I used to do computer controlled conveyor systems. My programming partner had to fly halfway across the US because one of our installations had stopped working.
Nobody bothered to check the fuses.
And to go off on a mini rant, the computers were expected to overcome all hardware deficiencies. For the most part, we did, but when things failed, we got the blame.
I can relate to the programmers getting the blame for Denver airport, I knew all along it had to be a hardware problem even though the press was full of failed software design stories. Just because the motors start and the product moves, does not mean it is a control issue.
@Braniac, I agree, but It is because generally people have the tendency to point at that place, that requires minimal amount of time and effort to solve the problem. And computer requires you to sit at your desk and figure out the problems in the code. It is just the natural way of things. If there is no problem found in the code then people shift to hardware problems, because they require more time and effort to deal with.They may even require disjointing the robot or unwiring all of the circuitory. So, I guess its justified people turning to the code first and then after that, to the hardware.
On one conveyor installation, a diverter would fail every once in a while. The hardware manager was blaming my code. I told him it had to be hardware because if it had been code, all of the diverters would be having the problem. It blew his mind that only one subroutine controlled all 60 diverters. And strangely, that made him suspect the software even more. We eventually traced it to a set of conveyor segments (it looked like a giant tank tread) that would not trigger the proximity switches he had installed as a gate against my control signal.
At another company, the QA manager complained that her keyboard was generating gibberish after she had installed a new version of our code. I traced the problem to being the keyboard by demonstrating that I could unplug the keyboard and plug it into another computer, and the problem followed the keyboard. At this point she admitted that she had spilled a drink on the keyboard earlier. But still unwilling to accept it was a hardware problem, said the problem didn't occur until our software had been loaded. I tried to explain that it may have taken a little bit for the liquid to seep into circuitry. I don't think she accepted that explanation.
I agree on that as well, the curiosity is in our nature. The thing which is not apparent or not accessible to us always seem to be liable to error to a common person. I can understand the rough times a programmer might have to face in their service.
BrainiacV; Isn't it amazing: Problem description: "I spilled a glass of soda into my keyboard, and now it is misbahaving - the problem must be your software update." Reply: "Don't you think pouring a glass of soda into a keyboard could cause a problem ?" Response: "Why can't you admit your software could be the problem ?" Conclusion: "Give your head a shake. I think your brain is stuck."
Sometimes it's just voodoo. I once commissioned a vision system to assist a robot in placing some odd-form parts. Without it, the robot would mis-insert about 20% of the parts. Prior to conditioning the line engineer pronounced 'this will never work'. Once the system was commissioned the mis-insertion rate dropped to zero. After several hours of running and passing an acceptance test, the line engineer said 'see, I told you it wouldn't work' and then turned off the power. The robot promptly went back to misinserting 20% of the parts but the line engineer was happy.
The other end of voodoo is great expectations leading to common questions like: "how come the robot didn't know these are parts for another product line?", "how come it didn't know the part was out of tolerance?", "why doesn't the system know we feed a lot of scrap parts on Friday?" and from the more technically inclined "Why doesn't the robot know we changed the design" and "Why doesn't it know when I move a fixture to a new location" while from knows just enough to be dangerous': I didn't know if the sensor did anything so I just forced it on in the PLC.
In my experience (and am sure you have experienced this too if you engineer in any field) the simplest flaws are always the most difficult to spot in a great design. I think its because we are never quite sure that we got everything as we hoped and when we do so and the design doesn't work we never spot the most obvious problems
That is correct, another way to look at it is that we overlook our minor flaws because we would like to believe that we cant be that dumb. Generally, most of the problems that arise are due to the basic syntax error in case of programming or a loose connection/solder in hardware. And ofcourse they can be very annoying.
When the problem is a system that had been working as required for some time, and then all at once is not, about the second question is "What has been changed", which often will narrow the area of search quite a bit. The first question is " just exactly what is happening, or not happening, that is a problem". Having an accurate description of the failure is usually a very good starting point in the diagnostic process.
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.