All My Best Ideas are Stolen
Physicist and star of educational TV during the 1950s and 1960s, Dan Q. Posin was fond of quoting Isaac Newton: “If I have seen further it is by standing on ye shoulders of giants.”
Designing control systems may not be on the same level as Newton’s contributions, but “standing on the shoulders of giants”—that is, learning from others’ experience—is always the fastest and most reliable way to solve difficult problems.
For example, in the early 1980s, I was presented with the problem of how to automatically insert a plastic plunger into a syringe on a production line. The syringe was part of a package that dispensed and mixed a two-part epoxy glue.
The difficulty was that, while a person could put the piston in place for a pneumatic ram to drive home, they couldn’t do so without trapping a large air bubble that made accurately dispensing the right amount of glue impossible. We had to first draw that bubble out of the syringe, then position the piston, and finally drive it home without breaking vacuum.
I solved the problem by stealing ideas from the Schmidt-Rubin straight-pull bolt-action rifle adopted by the Swiss army in 1898. The Schmidt action has a tang fixed on the bolt that rides in a spiral groove cut into the receiver. The groove rotates the bolt to lock it in place as the handle moves along a straight path.
|Based on a late 19th century repeating rifle action, this design "loads" a plastic piston through a breach in a receiver, closes the breach with a vacuum-tight seal, waits while a pump evacuates the "chamber," then rams it home.|
I copied the design, having a double-acting pneumatic cylinder pull a bolt back, opening the breach, which was just the correct size for the piston to drop into. Next, the pneumatic cylinder forced the bolt forward. As the bolt went forward, it rotated to close the breach and make a vacuum seal.
The ram, however, had to stop short of pushing the piston into the syringe until a suction pump pulled trapped air out of the syringe body. When the vacuum level reached a set point, a solenoid valve triggered the ram to drive the piston the rest of the way into the syringe.
Today, I would probably use a microprocessor to sequence the action, and might use electric motors instead of pneumatic rams, but at that time it proved an elegant solution based entirely on “repurposed” ideas.
The four contributors to this article present “hot” ideas, as well as the Control Engineering staff, encourage you to “steal” and apply to your own work.
|C.G. Masi is senior editor with Control Engineering. Reach him at email@example.com .|
Dynamically calculate motion profiles to improve fault recovery
Multi-axis coordinated motion applications typically use motion profiles designed to replicate mechanical cams. An uncontrolled stop can result in a slave axis deviating from the cam profile. If the desired slave position cannot be calculated relative to the current master axis position after stopping, then the slave cannot be moved to realign itself with the cam profile.
A possible recovery method would be to rebuild a cam profile that contains the current master and slave positions as a point in the profile. The designer should evaluate whether starting motion at the new cam point could cause any unacceptable velocity, acceleration, or jerk of the slave axis. If it does, the new recovery cam profile might result in an undesirable path being taken. Additional cam points and segment type selection (linear vs. cubic) can be used to correct the recovery path. In the example shown (above right), the slave axis was not able to reach the position required by the cubic segment following the current position, so a linear segment was utilized with slower master-axis speeds to provide the required recovery.
|Patrick Gallagher, managing partner, Millennium Control Systems. Millennium is a Rockwell Automation Solution Provider with expertise in developing solutions for complex motion control applications.|
Prepare for good control-program design
I have observed a discrepancy between hardware and software development practices. For hardware, the design phase is a given. Schematics always precede the soldering of circuits. Block diagrams and CAD drawings precede the fabrication of mechanical assemblies, fixtures, and equipment racks. Design documentation is essential for hardware. Why should software be any different?
Many developers are tempted to skip straight from the requirements specification to software coding. The more overall planning there is, however, the better the coding will be.
Start with a search for resources that will expedite design and development while positively influencing style. Search online for products, references, examples, drivers, toolkits, colleagues, and consultants. Many software-tool vendors provide online forums for developers to help each other, sharing articles, example code, and support.
Do not overlook the many available offline resources and media as well. The LabView software-development environment, for example, contains hundreds of example virtual instruments (VIs) that developers can use as a starting point for their application modules.
Next, develop a proof of concept to evaluate each specific instrument, hardware component, or software module. Design a test that will simulate the critical acquisition and analysis algorithms, and benchmark the execution speed. Then use the results to validate your design; seek alternatives, such as higher-performing instrumentation or faster data processing algorithms; or relax the requirements in your specification as necessary. When the proof of concept is complete, make sure you save it. You might be able to reuse all or portions of it in the final application.
Alternatively, you might find that the performance of your completed application differs from the proof of concept. In this case you should return to your proof of concept as a troubleshooting tool. If it still functions properly, you can begin to isolate performance issues to other areas. If the proof of concept suddenly stops working, the hardware, system configuration, or other conditions might have changed since the last successful run.
When the design phase is complete and the critical requirements have been evaluated via proof of concept, revisit the specification. Changes are inevitable. Conflicts might exist between several of the requirements, and tradeoffs and adjustments might be necessary. The specification is a living document. Be sure to revisit the specification on a periodic basis, and make any revisions needed.
Finally, code reuse is an essential technique in all modern programming environments. It can save the developer days of time versus starting each application from scratch. Every developer should maintain a software reuse library containing useful code modules. Moreover, every organization that employs multiple developers should maintain a reuse library in a networked repository under source control. The potential benefits include faster development time, greater commonality, and higher-quality applications.
|Peter Blume, president of Bloomy Controls. Bloomy Controls is a National Instruments (NI) Select Integration Partner, NI Certified Training Center, and a member of the Control Systems Integrators Association (CSIA). This article is excerpted from Blume’s new book The LabView Style Book from Prentice Hall Publishers. The comments here represent good programming practices, no matter what language you use.|
End users can be the best information sources—or not
Sometimes a robotic application is brand new—something nobody has ever done before. Most of the time, however, the client already makes the product or implements the process, but now they need to do it at a lower price, in higher quantities, or with a smaller footprint. Most of the time, it’s a manual process that some change has driven the user to turn into an automated process.
The end user most likely has a good idea of the final solution he or she envisions. That makes the end user the best source of information to the integrator.
That business owners know their processes way better than we, as an outside system integrator, can ever know it. They may have been making their product for 20 years, or even 50 years. They know the things that are hard to do, and the things that are easy, and they know things to watch out for.
So, listen very carefully to what users are saying, and understand what their problems are. As you design an automated solution, take into account the huge wealth of knowledge that users have amassed from many years of experience.
What they might not have is a wealth of knowledge of how to do it in an automated fashion. And, sometimes that’s a bit of a challenge. Often, they do it the way that they do it because they’re doing it manually. If you have a robot doing this job, you would have a different set of factors to consider. So sometimes you’ve got to just say: “It’s not going to be that way anymore.”
|Roger Richardson, president of Delta Sigma Corp. The company began operations in 1990 supporting the R&D efforts of the low observables (stealth technology) community. They reapplied some of those technologies and lessons-learned to other industrial applications. Although still involved with many radar cross section applications, the company has developed assembly and inspection machines for other industries as well.|
Look for open, modular architectures
There are several reasons to avoid “black box” or proprietary hardware or software packages. Most importantly it comes down to service and support issues. Utilizing proprietary hardware and software typically locks you into a single supplier for support and upgrades.
Most major control-hardware manufacturers support modular, open architecture packages that are capable of the speeds and advanced motion functions required by today’s most demanding applications. With larger manufacturers, you inherit a larger support network. This provides wider options for support and upgrade needs.
In today’s automation landscape, there are fewer and fewer applications that require any type of specialty controller. As an automation customer, you should demand an open-architecture system that can be locally supported. Similarly, your customers should be asking for copies of the source code, allowing them to maintain and troubleshoot their own systems. Suppliers can protect their code with software licenses while not impacting the customer’s ability to view, maintain, and troubleshoot the systems they purchase.
We get involved in many servo retrofits every year that involve replacing proprietary hardware and/or software that is no longer supported, is difficult to maintain, or is obsolete. These proprietary systems put tremendous pressure on the maintenance department. Just finding parts becomes difficult, let alone finding people with the ability to troubleshoot these legacy systems.
Users become precariously handcuffed by these systems In many cases, just losing a single individual means the entire support network is gone. In addition, if someone is available to support the system, the user often ends up paying an exorbitant amount for “specialty” knowledge.
In every such case, we have been able to replace these proprietary systems with open-architecture alternatives that are globally supported. Often these replacement systems are programmed via ladder logic, which is well known to maintenance personnel. The result is a modular system with built in flexibility, that can be supported locally via a variety of channels.
|Michael Gurney, co-owner and principal engineer at Concept Systems. Concept Systems is an independent system integrator with a focus on advanced motion control applications, including hydraulic, pneumatic and electric servo systems. Services include system design, development, and startup — everything from mechanical design and retrofit analysis, to hardware selection, fabrication, programming, and acceptance testing.|