HOME  |  NEWS  |  BLOGS  |  MESSAGES  |  FEATURES  |  VIDEOS  |  WEBINARS  |  INDUSTRIES  |  FOCUS ON FUNDAMENTALS
  |  REGISTER  |  LOGIN  |  HELP
Blogs
Sherlock Ohms

Robot Servo Errors Were Only Human

NO RATINGS
View Comments: Oldest First|Newest First|Threaded View
Page 1/2  >  >>
notarboca
User Rank
Gold
Engineering communication
notarboca   7/31/2012 8:47:54 AM
NO RATINGS
Wow, sounds like a lot of hardship could be avoided by a conference between Ladder I and Ladder II as to coordinating build orders.  Sort of reminds me of "how spec'd vs. how built".

naperlou
User Rank
Blogger
Re: Engineering communication
naperlou   7/31/2012 8:58:26 AM
NO RATINGS
Agreed.  It also sounds like there could be more automation in the coordination of the "Ladders".  Another alternative is to tag each assembly so that the stations can get the data from a central repository.

GlennA
User Rank
Gold
Re: Engineering communication
GlennA   7/31/2012 9:33:36 AM
NO RATINGS
The coordination was in the build order documents.  Each van was listed in order, and from Ladder I, through all of the Body Shop, Paint Shop, and Final Assembly, the build order document was the 'bible'.  The problems happened when the 'bible' was not followed exactly.  The spacing between frames was about 90 seconds.  It took about 150 seconds for a crew to build a frame in Ladder I, so there were 2 build crews.  If those 2 crews got out of sequence, either by skipping a frame or building a duplicate, problems happened.  It was easy to spot a long frame / short floor or short frame / long floor mismatch, but others were not so easy.

Tim
User Rank
Platinum
Data
Tim   7/31/2012 9:44:19 PM
NO RATINGS
It is interesting to see that the engineer came to you with the question about the robots. The engineer seemed to only pull some data from a server and did no real root cause analysis. Data is not always the only answer.

Rob Spiegel
User Rank
Blogger
Re: Engineering communication
Rob Spiegel   7/31/2012 11:13:12 PM
NO RATINGS
Systems like this are very literal. We human beings are not always literal. 

kf2qd
User Rank
Platinum
Only half the automation was completed...
kf2qd   8/1/2012 9:34:58 AM
NO RATINGS
Sounds like this plant needed to tag/code every sub-part as it was made so that the next station could read that tag and confirm tha the correct pieces were in place before beginning the next step in the welding process. A bar code tag in a known spot on every piece that would have to be read before the welding operation could be started. Could easil be done as the assembly was being moved into the first welding station. Make sure the correct parts are in place before slamming the robot into things and slowing down the process.

 

Hopefully thy did something like that on the next version of the line. Would really speed things up because there would be a record of the wrong parts being placed on the line, and the corresponding effort to ruduce the human errors and improve quality.

GlennA
User Rank
Gold
Re: Data
GlennA   8/1/2012 7:02:26 PM
NO RATINGS
Tim;  My experience with robots is that the robot is usually blamed first for any problem.  Since I was usually the robot tech, I had to find the real problem, which usually was not the robot.  It was not unusual for a problem investigation to be cursory, and stop at blaming the robot.

GlennA
User Rank
Gold
Re: Only half the automation was completed...
GlennA   8/1/2012 7:18:00 PM
NO RATINGS
kf2qd;  The Scarborough Van Plant built the 'G' van until 1993.  Then the equipment was dismantled and moved to Flint Michigan.  I think the 'G' van was discontinued entirely in 1995.  The Scarborough plant had painting robots in the Paint Shop, and welding robots in the Body Shop - CarTrac.  The rest of the plant was primarily manual assembly operations.

Every part had a part number, but that number was on the box or bin of many individual unlabeled parts.  The parts were manually selected and positioned for assembly, and initially manually welded.  The robots then welded the assembled frame to the assembled floor.  The build information was in the PLC and was shifted to the welding stations as the carrier advanced into the station.  There was no inspection capability to automatically identify the assembly to verify the manually selected parts.

warren@fourward.com
User Rank
Platinum
Re: Data
warren@fourward.com   8/2/2012 5:48:42 PM
NO RATINGS
I am sure the robot is at fault most of the time, because my vast experience tells me tha humins don'g maik mistooks.

Ralphy Boy
User Rank
Platinum
Re: Data
Ralphy Boy   8/2/2012 7:06:28 PM
NO RATINGS
"The engineer presented the numbers to me, and wanted to know what was wrong with the robots that they had so many servo errors, and what needed to be done to fix the problem."

The numbers the engineer presented should have included the number of times the crash was related to an incorrect bracket having been present... Ya think? At which point that becomes the issue.

And my experience with robots has given me this as a starting point as to their 'intelligence'... they are as dumb as a box of rocks.

Where a human would side-step the inconsistent configuration 99% of the time; the robot will crash into it 100% of the time.

So when a human puts on the wrong bracket and the robot trips over it... no surprise.

As much as possible sensors/identifiers could help. Idiot proofing applies to robotic assembly lines just as it does to human assembly lines. It depends how much you want to spend to achieve zero-error production.  

We do a lot of fixturing that restricts against incorrect assembly, and some of our assemblies lines have vision, bar code scans, or checklists to keep both the robots and the humans on track... i.e. if they had scanned the brackets as they were applied, and that info when into that frames live tracking info...

So the process "allow" human error to create robot error.

The lesson learned, but the fix is not discussed. Can we assume a better computer tracking regimen was implemented?  

Page 1/2  >  >>
Partner Zone
More Blogs from Sherlock Ohms
Building a prototype of a car is a tough way to find the optimal balance between efficiency and comfort. the Sherlocks at Ford are finding the balance using simulation.
Sherlock Ohms highlights stories told by engineers who have used their deductive reasoning and technical prowess to troubleshoot and solve the most perplexing engineering mysteries.
Sherlock Ohms highlights stories told by engineers who have used their deductive reasoning and technical prowess to troubleshoot and solve the most perplexing engineering mysteries.
Sherlock Ohms highlights stories told by engineers who have used their deductive reasoning and technical prowess to troubleshoot and solve the most perplexing engineering mysteries.
Sherlock Ohms highlights stories told by engineers who have used their deductive reasoning and technical prowess to troubleshoot and solve the most perplexing engineering mysteries.
Design News Webinar Series
12/11/2014 8:00 a.m. California / 11:00 a.m. New York
12/10/2014 8:00 a.m. California / 11:00 a.m. New York
11/19/2014 11:00 a.m. California / 2:00 p.m. New York
11/6/2014 11:00 a.m. California / 2:00 p.m. New York
Quick Poll
The Continuing Education Center offers engineers an entirely new way to get the education they need to formulate next-generation solutions.
SEMESTERS: 1  |  2  |  3  |  4  |  5  |  67


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.
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