If you can’t describe it you can’t control it. And control is what its all about. So we need to get better at describing what it is that our control system projects are going to do.
This has some serious implications.
First, if the programming language is not well suited to the task this will create a number of issues. Ladder logic was never intended to deal with real time control. So blending Ladder logic with motion control, which can be the most demanding of real time control applications, doesn’t alway turn out well. The precise coding of the control system processor now becomes an element of the control system behavior. And often anomalies occur that are difficult to diagnose and which may be impossible to modify to achieve the desired results.
Maybe this is why embedded controls are gaining in popularity. The computing power and connectivity of embedded controls has increased at least 10 fold in recent years making real time applications relatively straightforward. But embedded controllers involve complex programming languages and require very exotic programming capability, often with expensive supporting “tool chains” are needed to develop and debug applications. These costs make developing embedded applications suited to high volume products and not to one-of-a-kind machine control systems.
Control systems have become more interactive with data intensive applications like Excel Spreadsheet and higher level resource management applications. So network connectivity and precise transaction capability with Windows applications becomes more appealing. It sounds more and more like a computer and not a control system. And Windows isn’t really suited to the real time control or the hardware specific I/O that goes along with motion control applications.
PID as a control language for motion seems equally unsuited. Its a great way to manage current and voltage relationships dynamically between motor and amplifier, but poorly equipped for managing the mechanical relationships between axes or mechanical properties like time and momentum.
In the mechanical realm of describing motion control, there is a similar problem. Describing the mechanical task as a time-displacement trajectory seems an incredible understatement of the real work that needs to be done. And there are no descriptive languages that do this well, at least, not yet.
But we are seeing the beginnings of a more comprehensive approach. 3D modeling software would seem to be the ideal environment from which a better description of the actual machine would be able to inform a control system program with valuable information about the performance of the actual mechanism.
Where could you get more perfect information about the changing nature of the reflected load of an actuator from a dependent axis as it creates changes in momentum of a primary axis. As in a pick-and-place system. The actual momentum as it changes over the entire motion profile can be extracted directly from the 3D model of the actuator and used as a filter to modify the commanded motion with incredible precision. And this information can be used over and over, regardless of which location the actuator has to move to.
So we still don’t have the ideal solution. But maybe that’s coming, soon. The tools are there.