HOME  |  NEWS  |  BLOGS  |  MESSAGES  |  FEATURES  |  VIDEOS  |  WEBINARS  |  INDUSTRIES  |  FOCUS ON FUNDAMENTALS
  |  REGISTER  |  LOGIN  |  HELP
Comments
View Comments: Threaded|Newest First|Oldest First
Rob Spiegel
User Rank
Blogger
Too Quick to Blame
Rob Spiegel   8/30/2013 11:56:24 AM
NO RATINGS
This story is essentailly a jump-too-quick-to-conclusion problem. This story shows that it pays to think everything trhough before pointing the finger.

Ann R. Thryft
User Rank
Blogger
Re: Too Quick to Blame
Ann R. Thryft   8/30/2013 1:29:52 PM
NO RATINGS
I agree, Rob. It reminds me of the old adage GI, GO (garbage in, garbage out).

notarboca
User Rank
Gold
Re: Too Quick to Blame
notarboca   8/30/2013 2:35:18 PM
NO RATINGS
I don't think I would even attempt to blame the robot controller functionality.  After all there are probably a lot of them out there, and yours is the only one acting up?

shehan
User Rank
Gold
Re: Too Quick to Blame
shehan   8/31/2013 11:50:59 AM
NO RATINGS
@notarboca – True it's not correct to blame the machine for giving your wrong results if you gave the incorrect instructions or data. 

Charles Murray
User Rank
Blogger
Re: Too Quick to Blame
Charles Murray   8/30/2013 5:39:06 PM
NO RATINGS
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.

tekochip
User Rank
Platinum
Re: Too Quick to Blame
tekochip   8/30/2013 6:02:27 PM
NO RATINGS
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.

shehan
User Rank
Gold
Re: Too Quick to Blame
shehan   8/31/2013 11:54:57 AM
NO RATINGS
@tekochip- yes sometimes we don't see what the problem is, instead we just start fixing and replacing components. Whereas like you said the problem might be quite small.

taimoortariq
User Rank
Gold
Re: Too Quick to Blame
taimoortariq   8/30/2013 6:34:51 PM
NO RATINGS
@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. 

shehan
User Rank
Gold
Re: Too Quick to Blame
shehan   8/31/2013 11:56:28 AM
NO RATINGS
@taimoortariq – yes an engineer has more knowledge then a technician hence we expect the engineer to understand the problem before coming to a conclusion.

GlennA
User Rank
Gold
Re: Too Quick to Blame
GlennA   9/1/2013 10:16:08 AM
NO RATINGS
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.

William K.
User Rank
Platinum
Re: Too Quick to Blame
William K.   9/3/2013 10:06:36 AM
NO RATINGS
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.

taimoortariq
User Rank
Gold
Re: Too Quick to Blame
taimoortariq   9/7/2013 12:25:37 AM
NO RATINGS
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.

Larry M
User Rank
Platinum
Re: Too Quick to Blame
Larry M   9/10/2013 5:02:12 PM
NO RATINGS
My son likes to say:

Good Judgment comes from Experience.

Experience comes from Bad Judgment.

shehan
User Rank
Gold
Re: Too Quick to Blame
shehan   8/31/2013 11:52:59 AM
NO RATINGS
@Charles- it's always good to have certain function within your control than giving everything to the robot. This will help you identify errors and correct them as soon as you discover it.

 

Rob Spiegel
User Rank
Blogger
Re: Too Quick to Blame
Rob Spiegel   9/3/2013 3:47:43 PM
NO RATINGS
Good point, Chuck. On first appearance, it would seem the robot is messing up -- after all, that's where the trouble is occurring.

shehan
User Rank
Gold
Re: Too Quick to Blame
shehan   8/31/2013 11:48:59 AM
NO RATINGS
@Rob – It's all about the instructions you give in that decides the result you get. As the always say GIGO (Garbage In Garbage Out).

taimoortariq
User Rank
Gold
Error Accumilation
taimoortariq   8/30/2013 6:38:45 PM
NO RATINGS
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.

shehan
User Rank
Gold
Re: Error Accumilation
shehan   8/31/2013 11:58:00 AM
NO RATINGS
@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. 

BrainiacV
User Rank
Platinum
Computers get the blame
BrainiacV   9/3/2013 2:54:46 PM
NO RATINGS
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.

taimoortariq
User Rank
Gold
Re: Computers get the blame
taimoortariq   9/7/2013 12:40:16 AM
NO RATINGS
@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.

BrainiacV
User Rank
Platinum
Re: Computers get the blame
BrainiacV   9/9/2013 9:34:07 AM
NO RATINGS
I think it is because software is invisible.

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.

taimoortariq
User Rank
Gold
Re: Computers get the blame
taimoortariq   9/9/2013 4:55:18 PM
NO RATINGS
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.

GlennA
User Rank
Gold
Illogical Logic
GlennA   9/11/2013 12:59:31 PM
NO RATINGS
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."

apresher
User Rank
Blogger
Blame Game
apresher   9/3/2013 3:19:35 PM
NO RATINGS
BrainiacV, I agree that the most complex (or what is viewed as complex) always seems to get the majority of the attention when something goes wrong.

BrainiacV
User Rank
Platinum
Re: Blame Game
BrainiacV   9/9/2013 5:40:42 PM
NO RATINGS
I don't think it is complexity, I think it is lack of visibility.

The computer is a magic box that you can't see what it is doing.

Even when plugged into some circuit, you don't know the rhyme or reason it is generating signals the way you can by tracing a circuit.

GeorgeG
User Rank
Platinum
Re: Blame Game
GeorgeG   9/13/2013 4:25:00 PM
NO RATINGS
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.      

Cabe Atwell
User Rank
Blogger
Re: Blame Game
Cabe Atwell   10/23/2013 6:13:28 PM
NO RATINGS
Robots always get the blame when something goes wrong even though its programmed to perform a certain function. In this case, it was only doing its job.

AnandY
User Rank
Gold
Re;perfect designs, simple problems
AnandY   9/4/2013 2:32:11 AM
NO RATINGS
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

taimoortariq
User Rank
Gold
Re: Re;perfect designs, simple problems
taimoortariq   9/7/2013 12:31:25 AM
NO RATINGS
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.

William K.
User Rank
Platinum
Effecting a restoration to correct functioning
William K.   9/7/2013 7:47:09 PM
NO RATINGS
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.



Partner Zone
Latest Analysis
From pitchers and forwards to quarterbacks and defensemen, we offer a peek at some of the more memorable engineers in sports history.
IBM announced it is dedicating $3 billion of funding over the next five years to research and development of new processor technologies.
A soundproofing invention called Acoustiblok recently won a television challenge to silence an air horn with only a fraction of an inch of polymer material.
Rethink Robotics has upgraded Baxter the Robot so it can be easily trained by co-workers who simply show the robot how to move.
Robots came into their own in the 1970s. Gone were the low-budget black-and-white B movies. Now robots roamed in full-color feature films with A-list actors.
More:Blogs|News
Design News Webinar Series
7/23/2014 11:00 a.m. California / 2:00 p.m. New York
7/17/2014 11:00 a.m. California / 2:00 p.m. New York
6/25/2014 11:00 a.m. California / 2:00 p.m. New York
5/13/2014 10:00 a.m. California / 1:00 p.m. New York / 6:00 p.m. London
Quick Poll
The Continuing Education Center offers engineers an entirely new way to get the education they need to formulate next-generation solutions.
Jul 21 - 25, Design Products With Bluetooth Low Energy
SEMESTERS: 1  |  2  |  3  |  4  |  5  |  6


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.
Next Class: August 12 - 14
Sponsored by igus
Learn More   |   Login   |   Archived Classes
Twitter Feed
Design News Twitter Feed
Like Us on Facebook

Sponsored Content

Technology Marketplace

Copyright © 2014 UBM Canon, A UBM company, All rights reserved. Privacy Policy | Terms of Service