IEC Standard 61131: the benchmark for industrial controllers, Part 2

As we saw in Part 1, the IEC 61131 standard has had a profound effect on the industrial controllers market, particularly in the area of programming. In this part, we’ll look at how an additional standard promoted by PLCOpen relating to motion control has dovetailed into IEC 61131-3 and enhanced the overall usefulness of industrial controllers.

Motion control is the ability to control motion devices such as servos and, to a lesser extent, variable speed drives (VSDs). These have traditionally been controlled by dedicated controllers, which have limited facilities for interfacing with the rest of the control system that they need to interact with. End users are therefore increasingly demanding that motion control functionality be fully and seamlessly integrated into a single industrial controller, like a PLC, which already controls the rest of the line or machine. Having a single program simplifies both commissioning and maintenance and centralises data for easier collation. However, as we’ll see, this has presented a number of significant challenges for vendors.

The PLCOpen motion control standard

With growing user demands, PLCOpen saw the need to expand the family of industrial standards they promote (see Table 1). They formed a task force to create Technical Committee 2 (hereafter TC2) to develop a standard for motion control - releasing part 1, ‘Function Blocks for Motion Control’, in 2005. TC2 now has six parts, each dealing with different aspects of motion control and freely downloadable from the PLCOpen website.

The focus of TC2 is on defining a series of standard function blocks (FBs) to establish commonality for users, regardless of the underlying hardware. The FBs must strictly adhere to the IEC 61131-3 standard defined previously and, when implemented properly, must operate like any other FB, thereby integrating motion control functionality.

Apart from FBs, TC2 also requires a PLC to support a series of multi-level data structures, most notably the _sAXIS_REF and _sGROUP_REF structures, which hold the system parameters for a particular axis or group of axes respectively. As there may be multiple axes within a project, it must be possible to create arrays of such data types. Better implementations also support features such as unions and even enumerated data types to clarify meanings and self documentation.

Technical committees (TCs)		Promotional committees (PCs)
TC1	The 61131 standard suite	PC1	Promotional activities, including Europe
TC2	Motion control, specifically the FBs used to implement it	PC2	Common training, including certification guidelines
TC3	Certification. Three levels: base, conformity and re-usability	PC3	Promotion in North America
TC4	Communication, particularly OPC UA (Unified Architecture)	PC4	Promotion in Japan
TC5	Safety	PC5	Promotion in China
TC6	XML

Table 1: PLCOpen’s activities fall into two categories: overseeing the production of standards through its technical committees and promoting them through its promotional committees.

PLCOpen also created a certification scheme (technical committee TC3) whereby vendors, although not needing to comply with all aspects of the standard, gain certification once a prescribed level of compliance has been accomplished. PLCOpen’s motion control logo can be promoted by vendors once they attain certification.

Function blocks beyond the standard

TC2 specifies certain FBs that the vendor must provide for compliance. However, in the interests of nurturing development and product differentiation, vendors are allowed to produce FBs additional to the standard. For example, the FBs MC_MoveRelative and MC_MoveAbsolute are specified in the standard and therefore need to be supported to remain compliant. However, an additional FB like MC_Move, which combines both move modes and stipulates an input parameter to specify which is to be used, can also be provided. This not only increases the choice available to the programmer but also helps overcome one potential downfall of standards generally - that they freeze technology. Figure 1 shows an FB inserted into a program.

The need for speed

Another requirement of motion control systems that becomes immediately apparent is the increase in speed. When multiple servos need to work in a coordinated fashion (ie, as a group, such as when performing interpolating operations), update times of 1 ms or less are required to achieve reasonable accuracy.

PLCs, on the other hand, were never designed for dealing with such speed-intensive operations. They had always used a cyclic scan to perform their required tasks. A scan consisted of several parts: update of I/O, execution of the program, servicing of peripheral devices (eg, communication units) and internal diagnostics. Each cycle ran as fast as it could be executed and was asynchronous to the rest of the operation, most notably the control network. Interrupts were used to handle irregular time-critical operations. Scheduling facilities were also limited. A scan was also heavily program dependent but operated in time frames of around 10-20 ms.

Figure 1: A motion control function block in use - this one is additional to the PLCOpen standard.

As venders soon discovered, for a PLC to properly integrate motion functions and produce reasonable results, not only did the scanning mechanism need to be addressed, but the whole underlying PLC system needed to be completely revised as well. Most notably:

• The CPU itself had traditionally been an application-specific integrated circuit (ASIC) to ensure reliability. However, commercially available CPUs such as the Intel Atom and Core series are considerably faster and support multi-core parallel processing.
• The operating system must be well tested but also fast, highly reliable and support true multitasking. It also can’t be subject to viruses and other malware.
• The program needs to be fully compiled rather than semi-compiled or interpreted code. It needs to support multiple IEC languages, which all need to support online editing. This will require significant advances in the development software for the controller.
• The system needs to be capable of synchronisation with the network. All devices in the control network should be updated concurrently with the PLC program so that the entire system works in synchronicity and produces an outcome that’s both consistent and high speed.

Networking

It has been said a control system is only as good as the devices that can be connected to it. After all, the control system itself can be thought of as the ‘brains’ of the overall system; it’s the attached devices that provide the ‘limbs’ that do the actual work. Similarly, vision systems are considered the ‘eyes’ of the system. These devices are nearly always distributed around the plant floor or machine and must therefore be networked.

But, as we’ve seen, networks must be extremely fast for motion devices such as servos to maintain performance, so as to make synchronisation a reality. Motion networks have achieved this in the past by being dedicated networks that limited the number of nodes and restricted services. They also tended to be proprietary, which goes against the modern trend of being ‘open vendor’ so as to allow users to select best-of-breed technology.

EtherCAT (Ethernet for Control Automation Technology) however fulfils the prerequisites for a control network very well. It uses standard ethernet hardware for its high performance and low cost. Nodes link together in a daisy-chain topology, with each containing two ports for upstream and downstream connections. Messages are sent from node to node and frames are modified on the fly at each node. EtherCAT has a distributed clock working at a predefined synchronisation rate to enable highly precise synchronisation of remote devices. It has jitter of under a microsecond.

The synchronisation rate setting is important; it sets the update rate of the entire network. For effective control, the user program should also synchronise off this rate.

Information/data network

However, EtherCAT is only a controller network. Its architecture is not really designed for inter-controller use; or for connection to HMIs or higher-level computers. For this reason, and so as not to downgrade EtherCAT’s performance, other open-vendor networks like Ethernet/IP are often used in parallel with EtherCAT. Ethernet/IP is a well-established, deterministic industrial protocol. It uses standard ethernet architecture and is administered by the ODVA (Open Device Vendors Association) and is now widely supported by many makers of industrial products.

A new way

When designing an integrated logic/motion program with distributed devices on a network, the most important consideration is the network update time. Realistic expectations are between 500 µS and 4 ms, with 1 ms considered average. Within this time frame, all networked motion devices need to be updated, and at least some user programs (including motion instructions) executed. These demands require a very modern processor, something ASICs have hereto been unable to achieve.

As programs can vary considerably in length and in the types and intensity of instructions they execute, program segmentation and time slicing are essential to ensure regular updates of motion functions. The ability to fragment a program and apply priorities to them is also a requirement of the IEC 61131-3 standard. Once a program is segmented, each segment is assigned to a periodic task, which specifies the order in which segments are executed. Each task also has a task period setting, which regulates the maximum time allowed between executions. It can be difficult to segment a program without knowing how long it takes to execute, but having a simulator built into the development environment will assist with this, as well as with debugging.

One task, called the primary task, always has the highest priority as it contains the motion-control functionality, including the updating of networked axes. Its task period, called the primary period, is set to the network update time. The primary task is always run in its entirety every primary period; other tasks are paused when the primary task is scheduled to execute. Data concurrency is supported by assigning exclusive control of variables by selected tasks.

Two final considerations are I/O updates, which can be done in either the primary task or the highest priority periodic task - and the frequency and maximum time allowed for system servicing also needs to be set.

Figure 2: A user program segmented across three periodic tasks, for Omron’s NJ series controllers.

Putting it all together

Figure 2 shows a program segmented into three different periodic tasks, each with a different task period. The primary task (4) handles motion updates, some user program and motion control instructions. The first and highest priority periodic task (16) processes the I/O updates and executes more of the user program. In this example, it is able to execute its program at a greater rate than its task period because the user program in the primary task is executed relatively quickly. A lesser priority periodic task (17) is run at the completion of the higher priority one and system servicing is executed after it. However, scheduled execution of the primary task at the primary task period occurs throughout (because of the motion component), causing other executing tasks to pause. With this structure, motion updates down to 0.5 ms can be guaranteed.

Conclusion

Throughout this two-part article, we’ve seen the enormous contribution standards have made on PLC offerings. In the case of motion control, it has necessitated a complete redesign of the whole PLC system from the ground up. But the resultant advantages that come from having a single, fully integrated controller, such as a single point of data, simplified commissioning and ease of maintenance have made the effort well worthwhile.

Reference: http://www.plcopen.org/pages/tc2_motion_control/ Lewis, RW, 1996, Programming Industrial Control Systems Using IEC 1131-3, The Institution of Electrical Engineers, London.