Nice round-up of the technologies that are modernizing factories, making them safer, more efficient and generally more productive. I would add robotics to the list as well, especially with efforts like Rethink Robots' Baxter (http://www.designnews.com/author.asp?section_id=1386&doc_id=263186) and more autonomous and safer robotics coming into play. Perhaps it's a little early for mass adoption but I think it will eventually trend in that direction.
Sure thing, Rob. You still covered a lot of ground here. I think a story on robotics could be totally separate. In fact, I just did one a little bit similar...here's another link for you :): http://www.designnews.com/author.asp?section_id=1386&doc_id=267058
Thanks for the link, Elizabeth. The advances in plant robotics has been significant. This particular article was looking at motion control through the eyes of servo technology. Robotics is definitely a worthy subject for a coming article.
Until servo systems became more reliable, more powerful, and less expensive, they simply were not as good a choice, and they were seldom cost effective. Some machines did use a lot of shafts, gears, and chain drives, but that was often because there was no other way available to keep a bunch of motions in the proper relationship. HYdraulics were often used because there was no other economical way to provide that much foce in that small a volume.
So really, don't fault the older mechanisms, since there was not much choice.
The modern servo controllers are providing control options that did not exist before, and at power levels that were simply not available. So we do see that the new generation of servo systems does offer a way to do things thatwas not available previously. The older technologies were not a poor choice, they were the only choice.
But the new networked servo systems, while providing a lot of benefits are also bringing along a few challenges. Systems that previously were locked into the correct sequence of motions are now able to be accidently programmed to crash and destroy themselves, and in a hurry, as well. So now the motion programmer must pay far greater attention to a lot more details, and the same goes for any who would attempt to make small changes to the programs. So there are some very real and quite serious concerns when changing from mechanical systems to interlinked servo systems.
Very good point, William K. Safety systems are also becoming very sophisticated and are often programmed so that machine crashes (with other machines, with themselves, or with people) are less likely. But safety systems can't anticipate all the changes that can come through programming.
Rob, safety systems are another area altogather, and they have made some veru fundamemtal changes in the way things work. With the single-driver-mechanically -linked systems, hitting the E-STOP button halted the prime mover and things came to a fairly quick stop all in synchronization. But now with the splitting up into many diffeent segments, each driven by it's own servomotor, an emergency stop must be choreographed in order to avoid breaking the machine. So it may not provide the anticipated advantage as far as safety operation goes. Of ourse, there is none of the inertia from the linking mechanismas, which is a secondary benefit of using individual servos.
Unfortunately, from many aspects, modern machine safety requirements seem to be aimed at protecting a bunch of stupid drunks bent on self destruction. At least that is what quite a few of the rules seem to be aimed at.
William K, I'm not sure I understand your concern. Modern MCUs have multiple layers of interrupts. Couldn't the STOP button have a high priority Interrupt? Use of State Machines and Real Time Kernels could resolve the safety issue while promoting energy efficiency -- and I'm sure the plant owner would welcome the increased electric efficiency. And I don't think we have to be worried about "rules" to protect safety. Most employers welcome increased safety as a way of lowering their insurance costs, not to mention their genuine compassion for their employees.
78RPM, one of the failure modes that happens is for the controller to "wander off someplace" and ignore interrupts. Another failure is for it to simply stop executing the program, and, in the case of network connected systems, for something of greater importance to come along and take over completely, leaving the control program suspended. Of course, that last failure mode is primarily related to controllers running microsoft windows operating systems.
My point is that in order to be adequately reliable the emergency stop system must be able to do more than just request a stop, it must be able to force that stop without the assistance or consent of the software. As ajn example, consider those cars with the "unintended accelleration" situation, where pressing the big red button had no effect. A hardware shutdown would have switched off the engine no matter what, but instead the software decided to kep the engine running because "clearly the driver made an error in requesting an engine shutdown." In many plants the failure of the E-Stop button to halt machine operation would be sufficient cause to reject the machine until such a flaw was corrected. The emergency stop function is different from the "stop" request in that it need not be orderly. It is an emergency function.
So the question is about how removing that emergency function could improve a machine's efficiency.
I have been wondering about that as well, since an "instant" stop would require a huge comversion of rotational inertia into some other form of energy. But I have seen some quite fast clutches that can decouple a big flywheel from a load, and then re-connect it, very rapidly. That is a lot more believe-able. Instant decelleration is just two amazing to accept.
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.