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

Bad Timing Made a Bad Robot

NO RATINGS
View Comments: Threaded|Newest First|Oldest First
naperlou
User Rank
Blogger
Was it tested?
naperlou   8/12/2013 9:59:33 AM
NO RATINGS
Glenn, your analysis of and solution to the problem were really good.  You indicate that the robot had been reporgrammed site.  Was this the only robot of this type in use at that site?  What prompted the reprogramming?  From your description it seems that the customer had people who were not qualified programming the robot.  Is this the norm?

Debera Harward
User Rank
Silver
Re: Was it tested?
Debera Harward   8/13/2013 7:25:11 AM
NO RATINGS
Glenn thats really very nice ,i am highly impressed with your analytical and problem detection and solving skills.According to me a good engineer is not the one who just manufactures objects and products but he should have good analytical skills as well .

GlennA
User Rank
Gold
Re: Was it tested?
GlennA   8/13/2013 8:54:52 PM
NO RATINGS
Naperlou;  This was probably a Motoman - this story is several years old.  Most of the robots were Motoman, either L100's or K100's, and one K6, but there were also two ABB IRB 60's, a Miller, a GMF S-420-F, and an ACMA.  The robot had been moved from one building to another, and the workcell had been modified to allow 2 tooling fixtures.  The 'programmer' (and this is a sore point) was a manager who fancied himself a 'robotic welding expert'.  I had several disagreements with the 'experts' during my (short) tenure at Matsu.  It is not unusual to have marginally qualified people program robots - one of the selling 'features' is how easy a robot is to program.  Robots are easy to program, but not easy to program well.

Dave Palmer
User Rank
Platinum
Random vs. pseudorandom
Dave Palmer   8/12/2013 1:50:04 PM
NO RATINGS
In manufacturing, any defect that's described as "random" just means "I haven't figured out the pattern yet," or maybe "I haven't taken the time to look for a pattern yet."

Charles Murray
User Rank
Blogger
Re: Random vs. pseudorandom
Charles Murray   8/12/2013 6:48:12 PM
NO RATINGS
Indeed, Dave. This looks like choice #2 -- "No one has taken the time to look for a pattern yet."

Ralphy Boy
User Rank
Platinum
Bad Timing...
Ralphy Boy   8/13/2013 5:21:00 PM
NO RATINGS
Glenn... When working with CNC code generating software is common to have a 'post processor' that takes the general instructions from the GUI CAM screen and writes it as machine/controller specific code.

It looks like this is what you are referring to, or was it the onboard machine code that reads that that was modified?

Either way, I've done some post processor writing and I know that it is easy to miss something such as what you described... and not always easy to debug it later. It's the randomness of the problem you were up against that makes it tough puzzle.

Good on you for picking it out.

GlennA
User Rank
Gold
Re: Bad Timing...
GlennA   8/13/2013 9:03:00 PM
NO RATINGS
Ralphy Boy;  ABB called their robot programming language ARLa; A Robot Language.  I don't remember what Motoman called their programming language.  Early robots used G-code, which I think is now entirely replaced by plain language type programming languages.  Instead of a G-code move command, the syntax is usually something like  'MoveL' for a linear move, or 'MoveJ' for a joint move. 

Thinking_J
User Rank
Platinum
trouble shooting on the shop floor...
Thinking_J   8/13/2013 6:51:22 PM
NO RATINGS
Glen did what I have always advocated... spend the time observing the machine AND the operator before taking any other action(s).

Often taking time to review the situation with a good knowledgeable operator is the best usage of time. Bad operators on the other hand...

 

 

GlennA
User Rank
Gold
Re: trouble shooting on the shop floor...
GlennA   8/13/2013 9:14:54 PM
NO RATINGS
Thinking J;  I agree that asking the operator, or previous technician, why they think there is a problem, what they think the problem is, and what they have done to diagnose, or to fix, the problem, is time well spent.  Sometimes the 'problem' is an attempted fix to a non-existent problem.

TJ McDermott
User Rank
Blogger
Re: trouble shooting on the shop floor...
TJ McDermott   8/16/2013 3:38:01 PM
NO RATINGS
That works only if you can get on site.  When a ship in the middle of the Pacific calls for troubleshooting advice, you have only what is relayed to you with which to work.  That makes diagnosing much more difficult.

William K.
User Rank
Platinum
Re: trouble shooting on the shop floor...
William K.   8/17/2013 7:27:37 PM
NO RATINGS
TJM, "been there and done that". Troubleshooting via email one time certainly was better than a service call to a shop someplace about 200 miles north of Quebec. So I had the customers tech take voltage readings and after only two exchanges the failure diagnosis was positive. We sent the replacement parts via super-rush delivery and they got them in only a week. The tech put in the new parts and the machine played perfectly and the customer was very happy. My boss was peeved because we didn't get to charge for our in-shop repairs. Some folks have strange priorities, especially about supporting customers who pay a lot for support contracts.  But Delpi-Diesel had strange attitudes about a lot of things.

rkinner
User Rank
Iron
Plant staff knows a lot
rkinner   8/16/2013 3:22:35 PM
NO RATINGS
There is great knowledge in the plant personnel, it's how you ask the question that can make a big difference.  They often have a different langauge or "lack of formal training" but the info is really there.  They may not know the exact word to use but with a observant engineer, you can determine so much of what is happening.

Russ

taimoortariq
User Rank
Gold
troubleshooting
taimoortariq   8/17/2013 6:00:49 AM
NO RATINGS
When there is no obvious solution that you know of, Its always better to observe the machines under the repeated experiments with similar conditions and recognize the pattern. This will ultimately make things quite easier to diagnose. 

taimoortariq
User Rank
Gold
Re: troubleshooting
taimoortariq   8/17/2013 6:04:04 AM
NO RATINGS
And if there comes a situation where the error is too random, and there is no such problem you can think of then its best to change the controlling variables one by one (Hit and trial) and observe that how does the machine react under the controlled set of commands. And thus, a correction factor can be applied.

roborli
User Rank
Iron
Bad Timing Made a Bad Robot
roborli   8/17/2013 2:15:05 PM
NO RATINGS
The problem described is a common issue that seems to occur with the way Motoman interfaces Fronius welding systems at the factory. I've seen the same problem occur on several different systems. Motoman writes macro programs that change the weld schedule and settings on the Fronius welder immediately before starting the arc.  The weld settings for previous weld don't always take effect before the arc starts. This works OK if the settings are the same as used for the previous weld. However if the previous weld was using spray transfer at a high voltage and the next weld is a small CMT weld on thin material, it will blow a hole in the part exactly as described by the author.  I suspect that variations in the length of the wire stickout may determine why this problem occurs randomly. If the wire stickout is short, the welding conditions may have time to change while the wire is running in to the joint. If it is long the wire may already be touching the work and arc start may occur before the welding conditions change.  

The authors fix for this problem is correct. Insert instructions that select the weld schedule and settings before the robot reaches the arc start position. 

GlennA
User Rank
Gold
Re: Bad Timing Made a Bad Robot
GlennA   8/17/2013 2:29:48 PM
NO RATINGS
Roborli;  That is an interesting MIG welding glitch.  This robot was doing spot welding though.

William K.
User Rank
Platinum
The sequence is the solution
William K.   8/17/2013 7:40:29 PM
NO RATINGS
Very early in robot programming, and in PLC programming, it was pointed out about the sequence of operation, where the lines are executed in  sequence. So before giving a command it is always needed to define what that command will be, and what all of the variables will be. That works for timers and counters also, in addition to analog outputs and drive position/speed commands.

So the person who changed the program broke a very early programming rule.

Jim_E
User Rank
Platinum
One of my favorite programming quotes
Jim_E   8/19/2013 8:38:02 AM
NO RATINGS
I saw this somethwere:

I don't test my code often, but when I do, I test it in production.

 

Cabe Atwell
User Rank
Blogger
Re: One of my favorite programming quotes
Cabe Atwell   8/27/2013 1:55:43 PM
NO RATINGS
Programs, especially subroutines, can sometimes be finicky when executed through robots. This gives them a personality of sorts, which isn't always a good thing, especially when it comes to surgical robots. 

Partner Zone
More Blogs from Sherlock Ohms
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.
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
9/25/2014 11:00 a.m. California / 2:00 p.m. New York
9/10/2014 11:00 a.m. California / 2:00 p.m. New York
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
Quick Poll
The Continuing Education Center offers engineers an entirely new way to get the education they need to formulate next-generation solutions.
Oct 20 - 24, How to Design & Build an Embedded Web Server: An Embedded TCP/IP Tutorial
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: October 2
Sponsored by Altera
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