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

It's All in the Robot's Timing

NO RATINGS
View Comments: Threaded|Newest First|Oldest First
Rob Spiegel
User Rank
Blogger
A silly millisecond slower
Rob Spiegel   10/11/2013 10:54:07 AM
NO RATINGS
This is funny, Glenn. A fraction of a second is lost by the improvement. Gees, over a month, the cumulative loss is probably half a minute.

GTOlover
User Rank
Platinum
Re: A silly millisecond slower
GTOlover   10/11/2013 1:36:33 PM
NO RATINGS
Know what is even funnier Rob, look at the location and the project. I doubt a few milliseconds mattered compared to other time issues at this plant (if union know what I mean).

Rob Spiegel
User Rank
Blogger
Re: A silly millisecond slower
Rob Spiegel   10/14/2013 8:35:42 AM
NO RATINGS
I suppose that if you watch the milliseconds, the seconds will take care of themselves, but this is ridiculous.

GlennA
User Rank
Gold
Re: A silly millisecond slower
GlennA   10/11/2013 9:11:24 PM
NO RATINGS
Rob Spiegel;  I really don't think any time was lost.  The robot usually got back to the Cycle Start position at least a couple of seconds before the line was ready for the next floor pan.  So instead of waiting for 2 seconds, it may only wait for 1.7 seconds.  The robot with the hot servo motors also was usually back at the Cycle Start position a couple of seconds before the line indexing.  The issue there was to let the brakes hold the robot position after the robot was idle for 5 minutes, instead of keeping the servo motors on even if the robot is idle for several hours.

taimoortariq
User Rank
Gold
Re: A silly millisecond slower
taimoortariq   10/13/2013 8:53:35 PM
NO RATINGS
That is pretty interesting. And it makes alot of sense as well, specially the solution where you proposed to use breaks in idle time. Pity sometimes people in higher management don't use their heads.

RBedell
User Rank
Gold
Re: A silly millisecond slower
RBedell   10/14/2013 10:31:06 AM
NO RATINGS
It may not be realistic to expect higher management to make good decisions for lower levels.  They see a different picture than the lower levels do.  Perhaps the lower levels should try to see things differently and explain solutions in a manner that higher levels would understand.  If the higher levels are focused on operations and cost then:  Using the brakes instead of the motors saves power and that save money.  It also saves money by reducing downtime, repair costs and restocking of spare parts.

The entire structure of business, design and production requires different views of the same goal.  Inter-communications between those views are not always easy nor simple.  Explaining in terms they understand but might seem erroneous to us.  One hint, the farther up management, the more money plays the role.

bob from maine
User Rank
Platinum
Re: A silly millisecond slower
bob from maine   10/14/2013 12:10:43 PM
NO RATINGS
I'm reluctant to side with the engineer however I can see several scenarios where NOT making the change would be appropriate. First, apparently the dented floor pans were not a critical problem and the assembly process was able to operate without changes. Second, every program controlling a robot should be fully documented and when 'minor' changes are implemented they should be verified to assure they don't cause other errors elsewhere. This verification is often more difficult than dealing with an upset line worker. Lastly, undocumented changes make future troubleshooting or analysis really difficult. It easily could have changed Sherlock Ohms into Made by Monkeys. I'd say some enhanced communications from the engineer would have gone a long way here.

taimoortariq
User Rank
Gold
Greed gets to us
taimoortariq   10/13/2013 8:22:20 PM
NO RATINGS
Being cautious and careful with the machinery is more important than just blindly maximizing the efficiency. More production although very important might be reckless and cause damage to the parts and the machine as well.

Tool_maker
User Rank
Platinum
Re: Greed gets to us
Tool_maker   10/23/2013 1:05:23 PM
NO RATINGS
@taimoortariq: Your comments about production vs reckless reminds me of a situation that occured some years ago. We had a die that ran great at 160 strokes per minute in a particular press. We could fire it up at the start of the shift and run trouble free all day. However, the press was capable of 180 spm and it drove the owner crazy when we ran at less than max. So he would go out in the pressroom and turn the speed up. Shortly the die would misstroke and the operator would have to fish out a tangled mess and restart the whole process. He would always set the press at 16o spm and all would be well until the owner came around again.

  We fought that battle for a couple years and then I changed jobs. Several years later I ran into another toolmaker who still worked for that company. He assurred me that the same battle was still being fought. It makes no sense to fight with the man who signs your paycheck. Nomatter how wrong he was, he was always right.

taimoortariq
User Rank
Gold
Re: Greed gets to us
taimoortariq   10/27/2013 2:01:36 AM
NO RATINGS
Couldn't agree more on the last statement. It always ends up saying yes to your boss.

TJ McDermott
User Rank
Blogger
Re: Greed gets to us
TJ McDermott   10/25/2013 1:59:53 PM
NO RATINGS
I don't know if I'd call it greed.  Sometimes, it's an engineer seeing just how fast the system can go.

taimoortariq
User Rank
Gold
Re: Greed gets to us
taimoortariq   10/27/2013 2:05:15 AM
NO RATINGS
@Tj, for testing purpose there is no harm in tuning a machine but when the plant manager asks to speed things up for high production and risks the machine itself, then there is a problem.

RBedell
User Rank
Gold
Which efficiency
RBedell   10/14/2013 9:59:22 AM
NO RATINGS
As pointed out already, a few milliseconds may not matter.  The answer would depend on: Is the line waiting on the robot or is the robot waiting on the line?  If the line is waiting on the robot then does a few milliseconds really matter?  But, if the robot is waiting on the line then a few milliseconds is irrelevant.  As engineers, we can sometimes let our designs integrate into our egos.  Possibly, the engineer rejected the suggestion because it would slow down the robots cycle time.  And the engineer was proud of that quick cycle time.  While the pan got dented, the line didn't shutdown because of it and the engineer could keep his cycle time (and ego).

An alternate view:  Only suggesting a solution may not work well.  In the end, the solution has to be evaluated as to the impact it will have on the situation.  The engineer would have to take the time to evaluate it.  But, providing the solution and how it might affect the situation gives the engineer more information to make a decision and saves him time.  If the robot was waiting on the line then; reporting that because the robot is waiting on the line for 'X' amount of time, the extra time allowed for reduced acceleration would not affect the line.  The engineer might have approved the solution or at least took a closer look.  In terms of ego, he could slow the acceleration and keep the line speed and few would know, thus preserving his ego.

Ron C.
User Rank
Iron
Re: Which efficiency
Ron C.   10/14/2013 11:10:27 AM
NO RATINGS
I wonder if this may also have been a case of how the change was presented. "I can fix the problem by lengthing the cycle time" as oposed to "I can solve the problem by shortening the wait time".

 

Same result but could be looked at very differently by management.

Tom-R
User Rank
Gold
Re: Which efficiency
Tom-R   10/14/2013 12:05:59 PM
NO RATINGS
I like your point Ron-C. It doesn't assume the Engineer didn't want the problem solved the way it was. The first thing I wondered was when did the denting start? If it didn't do it when first installed, then maybe the grippers were wearing. I've seen entire machine speeds adjusted by maintenance for similar reasons. Then I get called back because the line is slowing down. The worst experience I had was commissioning a line, and as we brought the speed up the controls wouldn't work as planned. Turned out a supervisor kept overriding sensors by taping coins onto the proximity switches. Ya it kept conveyors running and product moving at that moment, but try debugging accumulation cycles or just getting cycle stops to work properly. We finally explained it was costing us more time finding and correcting his "fixes" than we gained in any production he forced through by overriding controls. When I read this story it made me wonder if the line had not reached the final design speed, and the Engineer didn't want the unit ultimately limiting that top speed. I've seen a line designed to run 900 units a minute being run at 600 units a minute for much the same reason. Yes everything is running smoother, but the owners have also been denied 1/3 of their investment's capacity because slowing things down was an easier fix than replacing worn parts or doing a proper change over between unit types. I wonder why we always assume upper management doesn't know what they're doing?

GlennA
User Rank
Gold
Do it right vs. do it over ?
GlennA   10/14/2013 10:54:36 AM
NO RATINGS
The original complaint was that the robot was denting the floorpans.  Reducing the acceleration while carrying the floorpan prevented the denting.  If your choice was to transfer a floorpan in 15 seconds, or transfer a dented floorpan in 14.8 seconds, while overall cycle time does not change, which would you choose ?  Transfer time may be important, but aren't un-damaged parts and eliminating repairs and rework important too ?

Another point:  the engineer that 'investigated' the dented floorpans, and rejected the suggestion to reduce the acceleration, didn't notice when the problem was corrected.  Shouldn't he have noticed, and investigated why the problem went away ?

RBedell
User Rank
Gold
Re: Do it right vs. do it over ?
RBedell   10/14/2013 12:12:32 PM
NO RATINGS
Glenn, my second post, ': A silly millisecond slower', tries to touch on the things you are mentioning.  My counter response is: Why should the engineer notice the problem went away? 

In that situation, what is the engineer's job duties?  I am simplistically assuming to keep the entire line running.  If so, the engineer will not monitor every detail at all the stations down the line.  He is likely monitoring the overall operation of the line and supplies feeding the line.  The details of a dent in a floorplan is below the horizon on his radar unless it caused the line to stall or stop.  Then it would rise above horizon and he would see it.  The task of monitoring the details of each station is given to the people at each station. 

The job you had was to determine if the issue at hand was a 'normal' failure or an 'operational' failure.  'Normal' being - failures not necessarily due to design or usage issues.  'Operational' being - failures that will continue to occur if equipment continues to be used the same way; like using the motor rather than a brake to hold a robotic arm in position for hours.  In other words, that engineer needs to know about operational failures not normal failures.  But, the engineer's definition of operational failure is not the same as yours.  A dent in the floorpan was not an operational failure to the line and there was (assuming) no issues being feedback from the line output so there was no failure.  If the dent in the floorpan caused problems down the line, then the engineer has an operational failure.

It is a matter of perspective.  You are seeing the problem from your angle and the engineer is seeing it from his angle.

 

Thinking_J
User Rank
Platinum
Great points...
Thinking_J   10/14/2013 5:29:17 PM
NO RATINGS
Many valid observations about the role of the different players (engineer, tech, operator, management)

It is obvious the author didn't believe his suggestion was given an appropriate merit. Also obvious the author believed his "solution" was the best solution (I can't see any problem with his conclusion - less wait time, slightly longer robot motion time).

His detective work (techincal) .. was commendable.

However, the real lesson (as suggested by other's observations) of this story is much more.

The engineer didn't explain his reason for dismissing the suggestion. Bad idea.

Perhaps he assumed the cycle time of the machine was equal to the work station cycle time? Perhaps he wanted the station to fail - to communicate HIS concerns to management on a related issue? Perhaps he was just lazy. Many excuses... all poor.

The "solution" was put into place without the engineer's blessing. Not a good indication of a real team working to a common goal. He may have done the "right thing" but a more complete solution of total cycle time reduction on the line was not (could never be) put into place. Why accept 1.7 seconds of wait time on 2 minute cycle time? - 1.4 % improvement could be significant on a ROI. Maybe not an issue at the time, but could indicate best place to spend money on improvements on the line.

Which leads back to management falling down on the job..  making sure everyone communicated and worked toward a common goal. Perhaps they too were just to lazy to do their job. Or did they assume it was someone else's job? Certainly it cannot be considered a good work environment if the tech believed the only way to do the "right thing" was to be deceptive to the engineer (no other course of action available?).

Unfortunately, a common theme in many of these "detective" stories.

The real issues are often human.. not technology based.

 

Rob Spiegel
User Rank
Blogger
Re: Great points...
Rob Spiegel   10/17/2013 12:27:38 PM
NO RATINGS
Thinking J, good points. So many of the Sherlock Ohms and Made by Monkeys problems hinge on good communication. Again and again we see examples of the damage that can be done when communication breaks down.

Ann R. Thryft
User Rank
Blogger
Re: Great points...
Ann R. Thryft   10/23/2013 7:30:34 PM
NO RATINGS
This entire example makes me think of the metaphor "the left hand--the engineer--doesn't know (or care) what the right hand--the line electrician--is doing" in large organizations. Or, apparently, what the right hand really needs.

Rob Spiegel
User Rank
Blogger
Re: Great points...
Rob Spiegel   10/24/2013 12:25:18 PM
NO RATINGS
Yes, that's right Ann. One hand doesn't know what the other hand is doing. And thus we're receiving an endless supply of Sherlock Ohms and Made by Monkeys stories.

William K.
User Rank
Platinum
Dented floor pans annd why it is a problem
William K.   10/14/2013 8:20:15 PM
NO RATINGS
There have been a few comments about why did the distortion of the floor pan around the holes even matter. I have an answer as to why the distortion of the edges of a 2 inch hole matter,  and it does matter a lot. Those holes are usually in the bottom surface, and they get plugged and thus sealed, by snap in plastic plugs. But if the edge of the hole has a wave, or a ripple, or some other similar damage then the seal will not be waterproof, and water that gets splashed against the bottom of the truck will gget in and be soaked up by the undercarpet cushion, or the noise deadening material, if the vehicle has a rubber floor mat. The result would be a rusted through fllor pan in a very few years, and also a smelly vehicle for quite a while before that. Both would be strong indicators of poor quality in the construction, which would be true.

As for the engineer who would not accept the change, it is quite likely that he was not the one in charge of making the whole line work, but instead an individual assigned some small part of the process, such as the floor pan transfer section of the line. That is how some plants used to work. I know. We had some testing machines for throttle bodiy calibration back a few years, and we constantly had to battle with an engineer who believed that running the servo gain up so high that the servo that set the downstream vaccuum would be unstable was making the process better because it was faster. But it was not able to hold the vacuum steady while oscillating, and so we were critisized for not having our machine performing correctly. Eventually we made strip chat recordings that showed that it was accurate with our settings but inaccurate when he changed them. That got US off the hook.

Kedojo
User Rank
Iron
Missed the point (ACCURACY & CLEARANCE
Kedojo   10/24/2013 9:03:25 AM
NO RATINGS
THIS IS A MECHANICAL, NOT ELECTRICAL PROBLEM. 3/4" PIN IN A 2" HOLE? a DENTED HOLE MEANS THE PART SHIFTED 5/8". THAT SEEMS TO BE THE BIGGER PROBLEM. I HAVE ALWAYS USED O.5MM CLEARANCE ON A LOCATE PIN TO STOP THIS PROBLEM, THEN PARTS SHIFT, PICK/SET ACCURACY AND CYCLE TIME ARE NOT AN ISSUE. YOU CAN'T ALWAYS "SOFTWARE " OUT OF A PROBLEM.

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
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.
Aug 4 - 8, Introduction to Linux Device Drivers
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