|
|
The PLCopen Motion Control Library :
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Smaller footprints | |
| Faster startups | |
| Flat to lower cost per function completed | |
| Higher speeds | |
| Improved efficiency | |
| Faster changeovers | |
| Better quality package | |
| Reduced waste | |
| Improved reliability |
Such requirements are not specific to the packaging industry. Overall one could say that the goal is: Faster, Better, Cheaper.
All
these changing requirements are heavily reflected in the control
architecture. And motion control, especially servo-based, plays an ever
increasing role in this.
A
packaging control system deals with Human Machine
Interfaces, Logic and Sequencing Control Systems, Motion Control Systems
including drive technologies, Network Architectures incl. Business System
Integration, Interface technologies to drives and other actuators and
sensors.
To
cope with these new requirements in packaging effectively, from a motion
control point of view, a mechatronics design is needed. This means that
mechanics in the machine are replaced by electronic solutions in the form of
digital; motion control. For example a rigid CAMshaft is replaced by a
combination of multiple drives/motors. The control software in these
mechatronics solutions provide the flexibility here.
Motion integration issues have emerged to the forefront, along with maintainability and connectivity to automation solutions. Unfortunately, the motion control market is a fragmented market, providing a wide variety of incompatible systems. with different architectures and software tools for development, installation and maintenance. This incompatibility incur considerable costs: applying different implementations is confusing, engineering becomes difficult, and the software is not reusable across platforms. Overall there is too little harmonization. providing flexible solutions which are open to new developments. Meaning not only harmonizing the programming languages, like done within the worldwide IEC 61131-3 standard, but also the software interface towards different motion control solutions, like distributed versus integrated. In this way, the benefits of software standardization are clear:
| Less hardware dependence | |
| Higher level of reusable code | |
| Transparent programs | |
| Lower commissioning, installation and maintenance costs | |
| Wide industry acceptance | |
| And last but not least: reduction in training costs |
Motion
control gets more and more integrated with the ‘classical’ PLC
environment, creating a good basis for standardization. This vision was
shared among many different suppliers as part of the organization PLCopen,
and resulted in the definition of a PLCopen Motion Control Library.
Effectively
this standardization is done by defining libraries of reusable components.
In this way the programming is less hardware dependent, the reusability of
the application software increased, the cost involved in training and
support reduced, and the application becomes scalable across different
levels of control. As such it is based on IEC 61131-3 Function Blocks,
creating application program which are commonly understandable and re-usable
across platforms. Due to the data hiding and encapsulation, it is usable on
different architectures, like from centralized to distributed control. And
as such it is open to existing and future technologies. Overall, this
standardization is expected to cover around 80% of the motion control
market.
The definition, consisting nowadays of multiple parts,
has been done via the definition of the state machine and a basic set of
Function Blocks for single axis motion and a set of multi-axes Function
Blocks.
To
the user, the Function Blocks are crucial. These are the software equivalent
of electronic chips. They contain inputs and outputs, with the associated
names and data types. Each Function Block contains code (like a small
program) to give it its functionality (like the components in a chip), and
map it to the corresponding (motion control) environment. The user only sees
the interface, being the inputs and outputs. The code itself is hidden –
this is called data encapsulation and hiding, and is crucial to separate the
different levels of programming and maintenance. Below is a small example of
two Function Blocks operating on the same axis. Access to the axis itself is
via Axis_Ref. This is a data-structure describing the drive itself. All
Function Blocks have access to this reference. In this way the internals of
the drive or architecture are hidden to the user, providing hardware
independence: distributed, integrated, or centralized controls, for the user
all architectures are accessed in the same way.
Overview
of the defined Function Blocks
Without going into details, the following table gives an overview of the
defined function blocks in Part 1 and 2 of the set of specifications,
divided in administrative (not driving motion) and motion related sets.
|
Administrative |
Motion |
||
|
Single
Axis |
Multiple
Axis |
Single
Axis |
Multiple
Axis |
|
Power |
CamTableSelect |
MoveAbsolute |
CamIn |
|
ReadStatus |
|
MoveRelative |
CamOut |
|
ReadAxisError |
|
MoveAdditive |
GearIn |
|
ReadParameter |
|
MoveSuperimposed |
GearInPos |
|
ReadBoolParameter |
|
MoveVelocity |
GearOut |
|
ReadDigitalInput
|
|
Home |
Phasing |
|
ReadDigitalOutput
|
|
Stop |
|
|
ReadActualPosition |
|
Halt |
|
|
ReadActualVelocity |
|
PositionProfile |
|
|
ReadActualTorque |
|
VelocityProfile |
|
|
WriteParameter |
|
AccelerationProfile |
|
|
WriteBoolParameter |
|
TorqueControl |
|
|
WriteDigitalOutput |
|
MoveContinuous |
|
|
SetPosition |
|
||
|
SetOverride |
|
||
|
DigitalCamSwitch |
|
||
|
TouchProbe |
|
||
|
AbortTrigger |
|
||
|
Reset |
|
||
Example:
the same Function Block instance controls different motions of an axix
The
figures below show an example where the function block FB1 is used to
control “AxisX” with three different values of Velocity. In a Sequential
Function Chart (SFC) the velocity 10, 20, and 0 is assigned to V.
To trigger the Execute input with a rising edge the variable E is
stepwise set and reset.
![]() |
The following timing diagram explains how it will work.
![]() |
Included
in the document are the rules for compliance and certification. Basically
this is a self-certification, from which the results per supplier are
published on the PLCopen website www.plcopen.org.
Certified companies are allowed to use the PLCopen Motion Control logo, with
additional number, date and number of supported compliant function blocks:
Changing
needs at consumers put a high pressure on the consumer related industry, as
well as on their suppliers. Fulfilling these needs requires moving from
mechanical solutions to mechatronics solutions. This makes the role of
software extremely important, combined with motion control.
Standardization
in the fragmented motion control market is crucial. And such a standard is
available: the PLCopen Function Blocks for Motion Control. As such it is
changing the face of industrial control. The specification is freely
available on the website http://www.plcopen.org
as downloadable file (in pdf format).
Overall, the PLCopen Motion Control Specification nowadays consists of 6 parts:
| Part 1 - Basics | |
| Part 2 - Extensions | |
| Part 3 - User Guidelines | |
| Part 4 - Coordinated Motion | |
| Part 5 - Homing procedures | |
| Part 6 - Extensions for Fluid Power |
Through
the independent organization PLCopen a wide user acceptance is realized, and
many implementations are already available. Also, cooperation with other
organizations and workgroups, like the OMAC Motion Control for Packaging, is
continued on an on-going basis.
With
many implementations available this specification will be widely used in the
industry.