- Don't underestimate the importance of program architecture.
Setting up the best architecture for the application requires a lot of advance planning. Instead of implementing the application right away, the development team should define the application's requirements and outline its various elements, such as motion control, supervisory control, and HMI, and then define how those elements interact. Even in this early stage of development, developers should think about future upgrades.
Planning should also include test and validation scenarios. During development, most developers spend insufficient time on the simulation and validation of the application's individual parts and tasks. Development tools that allow digital prototyping offer the possibility to validate motion profiles by applying them to 3D CAD models. This gives designers the possibility of validating the motion application before applying it to real hardware. This vital step not only prevents damage to expensive equipment, but also delivers critical information about product performance early in the design phase, and helps developers evaluate different design concepts.
- Choose software that easily interfaces to other tools.
A common mistake is picking proprietary software tools that lack interfaces to other development environments. Be aware: Hardly any software tools provide all the functions needed to implement a custom application. For example, there are specific development tools for creating HMIs. However, if those tools do not provide an open and flexible interface to motion-control development tools, developers end up spending more time connecting the different applications than working at the tasks they are trying to solve.
- Avoid breakdowns in communication.
Improve communication within your design teams. Motion control systems usually require mechanical and electrical engineers to work closely together. Unfortunately, those two groups speak different languages. Integrated design tools and digital prototyping can help to improve communication as well as the reuse of development efforts throughout the design process.
Tips 1 through 3 provided by Christian Fritz of National Instruments
- Take time to plan and test.
The time pressures of modern system integration often make engineers “dive straight in” to design work. The result is often prolonged debugging of code that evolves, rather than forms around a predetermined architecture. Another problem is that developers may use hardware from multiple vendors, migrate to new platforms, or simply fail to leverage new features or capabilities. Failing to understand functionality often results in pursuing an approach to motion control that is limited in its results. Take the time to study new products and keep up to date with newer functionality: It can save time and advance product performance.
Testing is by nature one of the last activities in any project, and as such, the one that is most squeezed by deadlines. Defining a test program, or at least a test strategy to be employed in each project, not only saves time at the end, but also is more effective. In addition, testing and qualifying of software can and should be done incrementally during the project.
- Carefully design the code structure.
Planning and forethought simplifies code development, providing structure and allowing project segmentation within the design team. This also encourages the design of reusable code. Modularity and structure naturally lend themselves to code reuse. Even where code is not directly portable, when it is well structured, it can provide guidance or the basis for new code that is similar in function.
- Know the importance of documentation and coding standards.
Poor coding approaches, such as improper variable names, functions, and tasks for example, not to mention lack of commenting, artificially make software more complex. Remember: There is no such thing as “too many comments.” Properly defining a coding standard makes code more readable. What's more, defining and adhering to a coding standard not only makes the code more readily understood by the development team, but also reduces mistakes. Note that this should also include naming and notation standards for variables, constants, functions, procedures, and tasks.
Tips 4 through 6 submitted by David Greensmith of Baldor Electric Co.
- Pick the right control paradigm.
Usually the challenge of motion-system software design results from the “real time” nature of control problems. This means that at any given point, anything can happen, and often does. A suitable control paradigm can adapt to these problems. To illustrate: A typical linear coding sequence may proceed, “A starts, A finishes; B starts, B finishes.” Instead, programmers may want to choose a state/event driven paradigm, in which all possible events are used as entries on a large branch tree or case statement. For example, if sequence A from above completes normally, the event handler could mark the current state of the machine as “A finished,” and trigger the start of sequence B, and so on.
However, if an event is not part of the normal linear sequence (as in a motion error or emergency stop) the associated event handler is executed from the branch tree. This makes it easier cover all machine conditions, because all actions associated with a particular event — whether part of the linear sequence or something unusual — are handled by one section of code tree.
Make sure that your code can handle all possible machine conditions at any moment in time. Whether the cargo is as inexpensive as cardboard sheet, or as expensive as a nearly complete silicon wafer, choosing the right architecture saves time, money, and aggravation.
- Keep it simple.
It's tempting to create wonderfully complicated multitasking, multithreaded structures, but this can make tracking down problems a nightmare. Object-oriented programming in the context of machine control typically tries to create structures that mimic a particular portion of the machine or a particular sequence. This is a good place to start. Designing control objects (and their possible states) in a straightforward and intuitive way makes diagnosing problems and accommodating new conditions much easier.
Tips 7 and 8 provided by Chuck Lewin of Performance Motion Devices
- Know that motion programming takes time.
Many software developers enter motion projects not realizing that unlike other coding, programming for motion takes significant amounts of time. The software modules that plan motion sequences and compute the equations for target motion have an interesting and curious relationship with the underlying algorithms that execute motion. The high-level routines typically must place data containing the equations in some sort of queue for low-level routines, and then monitor the execution of these routines to see when more equations are needed.
The details depend greatly on the type of motion required. Complex motion sequences that do not stop between sections are much more difficult than point-to-point moves. Sequences that must be computed “on the fly,” whether to react to real-time conditions or save storage, are more difficult than those that can be fully computed ahead of time. Many applications also require a multi-stage pipeline of information between the original high-level move specification and the actual move execution.
- Programming of motion offers a steep learning curve.
When creating motion software, developers should recognize that this is a specialty area of software development with a steep learning curve and no academic preparation available. The ability to log and plot commanded as well as measured trajectories is invaluable for tracking what a system is doing — likely to be very different from what you want it to do for at least the first several attempts. The ability to override programmed speeds easily and interactively (and run at a small percentage of actual speed) also allows understanding of what is happening on the machine just through observation.
Keep the programming environment for high-level move specification as independent as possible from the underlying algorithms that execute the moves. This way, users can put high-level specification to work and focus on the application — and not worry about supporting technology or handshaking and pipelining of low-level algorithms.
Tips 9 and 10 provided by Curt Wilson of Delta Tau Data Systems
National Instruments Corp.
Baldor Electric Co.
Performance Motion Devices Inc.
Delta Tau Data Systems Inc.