I have to agree with your first inclination, TJ. There should have been an official warning issued and a red flag in the manufacturing system, as you suggested, so prospective buyers had the full skinny on the problem before committing to purchase the component. Just because the manufacturer responded on the up and up AFTER you found the problem doesn't absolve them of that responsibility--in my book, any way. You are right to call them on the carpet.
I agree about a warnig being issued. On a broader level, one can infer from TJ's post that this kind of stuff is much more frequent than one supposes. Here, it came to light, but in many cases it doesn't. Do this "fix it" versus "cost" issue is something many manufacturers have to deal with, and I guess we can guess where the decision often ends up, if there's not a hard failure or solid safety issue involved. So this post raises some questions well worth thinking about.
The instructor at a BISSC training class, on the subject of food recalls, the instructor quoted a nameless CEO on the question "What is your company's name worth?" The CEO's answer was "Billions".
The context was, that if a company didn't get in front of a product recall, their company name would suffer greatly; the cost of the recall would always be less than not doing anything. Ideally, a food company would have no recalls, and an industrial automation company would make perfect parts.
This company does try to keep its customers notified. They send out product advisories when they discover a problem and know you have purchased that particular product, and they have an extensive knowledgebase. The information is there, if you know to look for it. I suppose in their eyes, they've done due diligence. In this case, I don't think the actions were enough.
I've also begun to wonder how extensive a problem this is as well.
The author is absolutely right: It's an integrity issue. For some reason, manufacturers sometimes ignore firmware problems, whereas they wouldn't ignore a faulty motor. Even though a firmware fix appears to cost less, it can waste massive amounts of time and labor.
Charles, in this particular instance, fixing the firmware would have required rather extensive testing and documentation. The device was a safety relay. It would have likely affected the documentation filed with the responsible authority that approved the device (UL, TUV, CSA, etc.).
I really can see the manufacturer's point of view to not bother, since a new series was coming.
I only object to the fact that they continued to sell the defective product with no obvious warning.
Not fixing the problem is an acceptable action by the company, but ONLY if an Errata is clearly provided (either in the part's data sheet or on their web site located where it is plainly visible when looking for documentation). Chip manufacturer's do this all the time and it's a reasonable solution to component problems found late in the development cycle.
On the other hand, sweeping the problem under the rug (and hoping for the best) is clearly unethical, at best. At worst it shows a casual disregard for their own reputaion and for their customer's time.
Not sharing this companies name only rewards this kind of behavior. It's venues like this that can have positive results in getting companies to do the right thing (but only if the light shines on them, specifically).
TJ, thanks for writing this article. As a consumer, I can't count the number of junky products I've bought unknowingly--way more in recent years it seems--with no recourse because their defects didn't cause safety or health problems. In many cases, thought, it was a similar situation. Your key phrase, I think, is "Why then, did the manufacturer continue to sell (and still sell) a product with a known defect?" And also, the fact that there was no warning. Of course, a warning would dissuade a lot of people from buying it. Your other key phrase is "But how many engineers have the time to search technical support Websites for potential defects of all the components in a design before you place the order?" Exactly. That's what quality practices were supposed to be about.
This story brings out a point that most folks are not aware of, which is the paperwork and testing that are needed for a product to be a "certified safety product". It was undoubtedly the paperwork and recertification required with any change that made them refuse to correct the problem.
Now we see ads describing how wonderful it will be when the safety system is a integral part of the control system. BUT, consider what happens if the system gets into the field and a problem anywhere is discovered. Fixes would be less likely because any change woulr require a re-certification, which costs money. Keeping the safety system separate may be less convenient, but it is the best way to avoid that sort of problems.
This article demonstrates the importance of getting it right the first time. TJ is absolutely right that the company's handling of this issue was inadequate. But if the company hadn't let a defective product out the door in the first place, they wouldn't even be in the awkward situation of having to respond to a problem like this. Nobody's perfect, but attention to detail upfront can prevent a lot of heartbreak down the road.
Certification and re-certification are issues for both safety products and military products. Getting things certified for use by the military is also a gigantic pain and re-certification even more so, and all of it, of course, costly. Yet suppliers to the military know this, and if that's what it takes, that's what they do. Why should consumers have it so much worse than soldiers, and be subjected to manufacturers who can't be bothered with a certification process?
I will gladly pay somewhat more for better quality. But I find it increasingly difficult to find those better quality products.
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.
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.
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.