HOME  |  NEWS  |  BLOGS  |  MESSAGES  |  FEATURES  |  VIDEOS  |  WEBINARS  |  INDUSTRIES  |  FOCUS ON FUNDAMENTALS
REGISTER   |   LOGIN   |   HELP
Comments
View Comments: Oldest First|Newest First|Threaded View
Page 1/2  >  >>
Nancy Golden
User Rank
Platinum
Error Codes
Nancy Golden   9/23/2013 12:13:44 PM
NO RATINGS
"While the machine ran production, I was watching the pressure gauges for a couple of hours. I happened to notice the unloading valve LED come on to indicate it was energized, but the pressure gauge still showed no pressure. That's when the machine failed on the oscillation encoder error." Great job finding the root cause. I guess it would have been nice to have an error code for "no pressure detected when unloading valve is energized" rather than an LED indicating the valve had been energized when in reality it was defective. Of course it is often difficult to know what the failure modes will be and how many sensors are needed and where...

OLD_CURMUDGEON
User Rank
Platinum
Re: Error Codes
OLD_CURMUDGEON   9/24/2013 9:22:22 AM
NO RATINGS
Nancy, I hate to sound like the OLD_CURMUDGEON that I really am, but I suspect that the lack of additional feedback via a pressure sensor was a cost-saving move.  No doubt the unloader valve design had proven itself to be extremely reliable & durable, so a decision was made to use ONLY the LED to indicate that an electric signal was present, and let it go at that.  There comes a time in the design cycle when you can add so much redundancy or observation implements that the machine becomes a monster of its own.  I've seen examples of that in the past where a basic machine concept grew to almost unlimited bounds because of overzealous thinking, sort of on the lines of, "since we can, LET'S......!"  and that ain't gudd engineering......

ADIOS!

Nancy Golden
User Rank
Platinum
Re: Error Codes
Nancy Golden   9/24/2013 1:05:34 PM
NO RATINGS
That was my first thought too, OLD_CURMUDGEON = WISDOM_FROM_EXPERIENCE about it being both a cost-saving move and also to reduce redundancy...

As a test engineer, one of my tasks when building a test set for the production floor in Mexico was to try to envision possible failure modes (both hardware and software) and come up with a reasonable way to flag them, without being "overzealous." Often, a strategic LED indicator or software error code had much the same job and we would have to depend on reasonable troubleshooting expertise when an unusual failure occured. Visual confirmation of pressure is not a stretch, but depending on how complex the system is, it can take awhile to find - such is the nature, and challenge, and fun, (if a million dollar dealine is not involved) of electronics...

We usually get to a point where those are bells and whistles and while they can be fun to add in - budgetary constraints limit them to the ones deemed most necessary.

OLD_CURMUDGEON
User Rank
Platinum
Re: Error Codes
OLD_CURMUDGEON   9/24/2013 2:56:19 PM
NO RATINGS
You're absolutely correct.  I've designed & built a lot of sophistcated production machinery in my career, and I can attest to your sentiments.  I was once part of a team that repurposed a series of web presses for a totally different process.  While the project was a lot of fun & interesting, the owner of the company's nephew was the chief programmer.  These presses featured industrial-grade 486/nn PCs, housed in a standard 19" rack cabinet.  All the control electronics, including the servo-amps, etc. were contained in this cabinet.  the "bells & whistles" never seemed to stop coming.  As the project progressed, we saw more & more interface control hardware being added, etc.  The control programs of course expanded exponentially as a result, since there were all kinds of "tie" lines from one system to another.  And, the upshot of the whole thing was that the machines never worked to expectation early on.  The mechanicals were OK, but the control was always off.  Finally, the programming "genius" left on his own accord, and we revisited the project.  By the time we were finished, a couple of weeks later, we had a pile of scrap wire, pile of scrap redundant sensors & control relays, and a considerably less cluttered control cabinet, AND, the machine ran like a buzz saw, producing about 4,000 items per minute, which was over specification by a good margin.  Of course, the machines could be throttled down to any respectable running speed, and the quality of finished item remained exceptional throughout the production runs.

Nancy Golden
User Rank
Platinum
Re: Error Codes
Nancy Golden   9/24/2013 3:16:53 PM
NO RATINGS
Thanks for sharing that story - I have seen that type of scenario a couple of times myself...and the sigh of relief when that person moves on and real work can be accomplished.

I will take good, solid basic functionality over bells and whistles anytime!

OLD_CURMUDGEON
User Rank
Platinum
Re: Error Codes
OLD_CURMUDGEON   9/24/2013 3:42:59 PM
NO RATINGS
In this particular case, all was not lost since the contract called for several of these machines, and this event, as I described, was with the first two carcasses, so the piles of "scrap" got used on the later four machines, as my memory serves, with very little waste at the end of the project.  And, since this was a custom-designed machine, we kept all the "leftovers" in case they were needed for spare parts and/or repeat build contracts.

But, in essence, this phenomenon can become a disease amongst engineering types.  Things that once seemed quite difficult to achieve, especially in hardware, all of a sudden become trivial exercises in software.  Some of this is good for the end-user, some becomes "bloat", and we all know how we handle bloat with our canine pals.......

 

GlennA
User Rank
Gold
Fix it in the software ?
GlennA   9/24/2013 4:57:32 PM
NO RATINGS
I had to write a PLC program for a machine designed by mechanical engineers.  Several of the glitches were in the sensors.  The mechanical engineer specified normally open sensors for the end-of-travel sensors.  I tried, unsuccessfully, to explain that the end-of-travel sensors should be normally closed.  Another glitch was sensor locations.  One of the end-of-travel sensors was re-assigned to double as a home position sensor, and the machine had to move past the home sensor.  The standard answer to the sensor problems was to 'fix it in the software'.  Some mistakes cannot be fixed in the software.

Ratsky
User Rank
Platinum
Re: Error Codes
Ratsky   9/24/2013 5:13:46 PM
NO RATINGS
Well, I'm not in the machinery area, but rather in telecom. For many years i was Chief Engineer (remember that glorious title!) for a smallish maker of specialized switching systems.  Our key markets were mostly call centers of various kinds.  These had to be extremely reliable/highly available (think about 911 centers, or inbound telemarketing/order centers where time was literally equal to money); the traditional central-office architecture depended on multiple layers of redundancy to achieve that goal.  As the systems architect, I was faced with trying to meet the true availability numbers (many 9s) without getting overly complex (and expensive).   Since I was quite familiar with MTBF analysis, I decided to try to use those tools to evaluate architectures.  I found that once redundancy passed a certain level, availability actually DECREASED because the increasing complexity made non-recoverable failures MORE likely.  Any redundancy scheme depends on failure detection; if there are failure mechanisms that require a highly complex "umpire" (e.g. for majority-logic failure detection), I actually proved by failure analysis that having a single point of failure (a "no-no" in the orthodox reliability world) could actually provide greater availability (the true goal) than a complex system along with the necessary mechanisms to switch out the failed unit.  With the help of my analysis, we were able to convince the customer that our approach provided better availability than the competition's mega-redundant version (and at less than half the cost).  Thus we won the contract to provide ALL of the California Highway Patrol 911 call centers (back in early '80s), and had a VERY satisfied customer base with the resultant availabilty demonstrated in the field.

William K.
User Rank
Platinum
Re: Fix it in the software ?
William K.   9/24/2013 8:25:34 PM
NO RATINGS
GlennA is certainly correct about there being things that simply can not be fixed in software. The worst ever that I came across was where the sense of a valve was reversed in installation, and then changed back in software. The result was that the action of the macjhine started when the air pressure came on and was not corrected until the computer controls and software were running. And hitting the "E-Stop" switch would cause the valve to go to the wrong position. It was a vary bad condition made much worse by "fixing it in software."

Nancy Golden
User Rank
Platinum
Re: Fix it in the software ?
Nancy Golden   9/29/2013 10:16:56 PM
NO RATINGS
I have certainly "fixed it in the software" on numerous occasions and it was a good call for that specific scenario. This is especially true with using software time delays to solve problems. I have also had to invert a 0 or 1 because of a replacement part that operated the opposite of the original - or some such thing. As others have already said, software can't fix everything and in an ideal world the hardware will function properly so that the software just orchestrates its functions in a logically flowing program. Software fixes can often be done quickly and do not require buying additional parts so it makes the test engineer out to be a hero at times. The important thing with software fixes is to document them. I would always comment my software so three years later when something needed to be troubleshooted or changed, I knew what I had done previously - and anyone else working on that test set behind me would know also.

Page 1/2  >  >>


Partner Zone
Latest Analysis
Eric Chesak created a sensor that can detect clouds, and it can also measure different sources of radiation.
Festo's BionicKangaroo combines pneumatic and electrical drive technology, plus very precise controls and condition monitoring. Like a real kangaroo, the BionicKangaroo robot harvests the kinetic energy of each takeoff and immediately uses it to power the next jump.
Practicing engineers have not heeded Yoda's words.
Design News and Digi-Key presents: Creating & Testing Your First RTOS Application Using MQX, a crash course that will look at defining a project, selecting a target processor, blocking code, defining tasks, completing code, and debugging.
Rockwell Automation recently unveiled a new safety relay that can be configured and integrated through existing software to program safety logic in devices.
More:Blogs|News
Design News Webinar Series
3/27/2014 11:00 a.m. California / 2:00 p.m. New York / 7:00 p.m. London
2/27/2014 11:00 a.m. California / 2:00 p.m. New York / 7:00 p.m. London
12/18/2013 Available On Demand
11/20/2013 Available On Demand
Quick Poll
The Continuing Education Center offers engineers an entirely new way to get the education they need to formulate next-generation solutions.
Apr 21 - 25, Creating & Testing Your First RTOS Application Using MQX
SEMESTERS: 1  |  2  |  3  |  4  |  5


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: April 29 - Day 1
Sponsored by maxon precision motors
Learn More   |   Login   |   Archived Classes
Twitter Feed
Design News Twitter Feed
Like Us on Facebook

Sponsored Content

Technology Marketplace

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
Copyright © 2014 UBM Canon, A UBM company, All rights reserved. Privacy Policy | Terms of Service