PLCopen and CiA 402

What it is

PLCopen is both an organisation and a specification: it defines standard function blocks so that motion control software can be written independently of the hardware underneath. The framework builds on the IEC 61131-3 standard. In the organisation's own words: the PLCopen motion standard provides a way to have standard application libraries that are reusable for multiple hardware platforms, which lowers development, maintenance and support costs while eliminating confusion.

The problem it solves is concrete. If the same axis move has to be written from scratch for every piece of hardware, a machine builder rewrites the same logic on every project, every new engineer learns every platform separately, and code proven in the field cannot travel to the next machine. PLCopen breaks that repetition by defining a common interface.

The specification today consists of a set of parts: Part 1 and 2, basics and extensions, combined into one; Part 3, user guidelines and examples; Part 4, coordinated motion; Part 5, homing procedures; Part 6, extensions for fluid power. Basically every specification contains three sections: definition of the state machine, definition of a basic set of function blocks for single-axis and multi-axes motion control, and compliance rules with a statement procedure.

How it works

At the centre of PLCopen is the axis state machine. In the organisation's words, the axis is always in one of the defined states; any motion command is a transition that changes the state of the axis and, as a consequence, modifies the way the current motion is computed. The state diagram normatively defines the behaviour of the axis at a high level.

Eight states are defined: Disabled, Standstill, Homing, Discrete Motion, Continuous Motion, Synchronized Motion, Stopping and ErrorStop.

A normal procedure starts in Disabled. In this state the power can be switched on per axis via the command MC_Power, which transfers the relevant axis to the state Standstill. From there one can access the Homing state by issuing the Home command per axis, which after normal completion returns to Standstill. From here an axis can be transferred to either Discrete Motion or Continuous Motion. A coupling to a master axis can be realised for instance by issuing MC_GearIn; the resulting state for the slave axis is then Synchronized Motion. Issuing a single axis move command brings the axis back to either Discrete or Continuous Motion. Via the state Stopping one returns to Standstill. ErrorStop is the state an axis transfers to in case of an error; via a reset command one returns to Standstill, from which the machine can be brought back to an operational state.

The motion commands are standardised too. MC_MoveAbsolute, for example, commands a controlled motion at a specified absolute position, with inputs including the axis reference, Execute, Position, Velocity, Acceleration, Deceleration, Jerk, direction and buffer mode. That the same block carries the same inputs across platforms is exactly what makes application logic portable.

Access to an axis goes through the derived datatype AXIS_REF, which in the organisation's words is supplied by all manufacturers. The technicalities of the real interface stay hidden inside that structure and the function block, so that centralised, distributed and networked architectures all look the same to the user.

How it relates to CiA 402

PLCopen and CiA 402 are not competitors; they are two ends of the same chain. PLCopen standardises the application side: how you address an axis in the controller program, which function blocks you call, which states the axis passes through. CiA 402 standardises the drive side: as the CANopen device profile for drives and motion control, it defines the drive's own state machine and its operating modes.

The practical value of that split is this: a drive implementing the CiA 402 profile and a controller offering PLCopen blocks meet in the middle. Application software is written against standard blocks rather than a drive's internal register map, so when the drive or the fieldbus changes, most of the application survives.

At SMB

SMB controllers are programmed in CODESYS: the IEC 61131-3 languages with integrated motion, gathering machine logic and the axes into a single project. On the drive side, SMB servo drives implement the CiA 402 drive profile, with the same state machine and the same operating modes over both EtherCAT and CANopen.

When the two layers come together the result for a machine builder is that even as axis count and fieldbus change from project to project, the motion logic in the application layer stays largely the same. To see the whole system architecture at once — controller, drive, motor, cable and protocols — have a look at our system page.

Common questions

Is PLCopen a product? No, it is a specification. Controller vendors ship function block libraries that conform to it, and you write your application program with those blocks.

Why not write to the drive's registers directly? You can, but that application is then tied to that drive. An application written with standard blocks largely survives a hardware change; in the organisation's words, the point of the standardisation is precisely to define libraries of reusable components.

Do I need to know the state machine? Yes. Most debugging comes down to “why did the axis not accept that command”, and the answer is nearly always which state the axis was in at the time. The states define the functionality of the function blocks.

Is coordinated multi-axis motion covered as well? Yes: Part 4 of the specification deals with coordinated motion, and Part 5 with homing procedures.