Tevopharm BV, The Netherlands, developed a new packaging machine, which is completely based on IEC 61131-3 and the PLCopen Motion Control Specification for logic and motion control. This certainly can be seen as a proof of concept. This article describes the origin, the implementation, and the benefits.
1.1. Introduction into Tevopharm Tevopharm
B.V. was founded in 1959 in Schiedam, The Netherlands. With a crucial patent in flow-wrapping, it quickly became a large manufacturer of high quality horizontal bag form, fill and seal machines for packaging of chocolate and bar products, biscuits, candies and pharmaceutical products. Their PACK-6 flow wrapper was seen by the market a as a de-facto standard.
In 1985 it became Klöckner Tevopharm, and in 2003 it was taken over by Bosch.
The Dutch company has about 175 employees generating annual sales of approximately 30 million Euros. With over 5,000 flow wrapper machines sold, it is worldwide active, with approximate turnover of 35% in Europe, 35% in North America, and 30% in Asia and the rest of the world. Their product range from stand alone applications with single servo systems till full servo controlled, turn-key multiflow wrappers, including distribution, storage and multilane flow wrapping, grouping, and secondary packaging systems, to serve the world’s largest food manufacturers.
Due to the changes in consumer behaviour, requiring smaller portions of food and a wider variety, and the stricter hygiene demands, an increased interest in flexible automated packaging productions lines operations will boost future demand.
1.2. Introduction of the machine
The first machine fromTevopharm that is build around the PLCopen Motion Control Function Block Library is the PACK-300CA Flow Wrapper. This machine is capable of packing up to 2,000 products per minute.
Where the PACK-300CA is the first Tevopharm machine to be equipped with the new control system, the other full servo-based machines PACK-200 and PACK-2000 will follow shortly.
Picture 1: The Tevopharm P300 CA packaging machine
Picture 2: The scheme of the P 300 CA machine
The PACK-300CA contains three servo drives steering the following functionality:
- The product infeed chain (M1)
- The film feeding and alignment (M2)
- The cross sealing part (M3)
To control these servomotors a 'virtual line shaft' is used in the controller. This virtual line shaft operates the machine just like a traditional mechanical line shaft, while adding the flexibility which the mechanical version is lacking. All servomotors are coupled to this virtual line shaft via the control software.
The infeed servo has a one-to-one relationship to the virtual line shaft, and can therefore be seen as the physical representation of the virtual line shaft. The second motor follows the virtual line shaft, while keeping the print on the film aligned with the rest of the process. The third motor is coupled to the virtual line shaft via a specially designed profile. This profile assures that the sealing and cutting of the film is done at the right place and with the right speed.
Controller & architecture
Basically all packaging machines have three basic control functions:
- HMI, the Human MachineInterface
- PLC, the logic part of the control
- MC, the Motion Control functionality
Normally each function can have different suppliers, especially on request from the end users, making a wide mix possible. With the PACK-300CA, these functions are merged. Integration into one platform, like PC based control, can be possible. However certain software constraints, as well as ability to serve different customer expectations on the HMI part, makes a preference for the integration of PLC and MC into one platform, and the HMI on another one.
1.3. Rationale of using IEC 61131-3 and the PLCopen MC
Due to their worldwide operation, Tevopharm has to support multiple platforms as requested by their customers. Support for multiple platforms results in a high cost content in the software, due to multiple training costs, multiple application developments, multiple debug sessions, and increased installation and maintenance costs. Since the resulting machine basically does the same job, these quality-related costs induce a large effect on the price of the machine, the delivery time, and the time to full production.
To reduce these costs and to create optimum customer value, a hardware-independent development of the application software is needed. With this, the relevant software can be used on different hardware platforms without much additional costs. This provides the users customers a wider choice of electrical hardware, optimised to their high value, slow moving electrical-parts-stock.
To provide this, a high level of standardization is needed, especially in the software section.
Around five years ago, Tevopharm initiated a project for the PLC software development to move to configurable elements as provided by the worldwide programming standard IEC 61131-3. This means that the functionality of the each application program for the machine was constructed from a pre-defined and tested set of building blocks. With the implementation done, they saw a large improvement in the quality of the software, and a large reduction of the associated costs. This cost reduction was not only valid at Tevopharm, but also at her customers.
The next logical step in this was to include the motion control section. At that time, their motion control consisted of two different environments, using two different languages, in this case “C” and “structured text”.
Around 2001, Tevopharm became aware of the PLCopen initiative to harmonize the access for motion control via the IEC 61131-3 programming environment. PLCopen had just released the first part of this specification, and several suppliers were in the process of converting this to real products. With this motion integration, Tevopharm would be able to use the same environment with the same language for both the logic control and the motion control. However, they wanted to make sure that the specification overall would suit their needs. To support this, they joined PLCopen and helped working on the next parts of this motion control specification.
Using the short list for compliance, as provided by PLCopen, Tevopharm could very easily specify their own requirements for their motion control environments, merge this with their additional requirements, and select potential suppliers based on this.
For the PACK-300CA machine, Tevopharm basically used a selection of the function blocks of part one, and a sub set of part 2.
1.4.Standardization and the software development process
The structured approach (see sidebar) created the basis for configurable software. This means that for the whole set of machines as provided by Tevopharm, there is basically one program developed per control hardware platform. With further standardization this can even go one step further: one software program for different (read: all) platforms.
Picture 3 - Application software development as basis for multi-level machines
In addition, the application software functions parts need only to be debugged once, while being used on multiple platforms. Higher reuse of software results in less cost and less delivery time to full production at customer’s site. This includes the higher functionality of the PLCopen MC FBS as provided.
With this approach, Tevopharm enhanced their quality of their application software, as well as the development of this. This helps them to fulfil the requirements needed to achieve CMM level 2. (CMM = Capability Maturity Model.)
1.5. Resulting benefits in training, service, support, and maintenance
This approach results in a reduction of the training costs ? both at the supplier and the user. Besides the reduction in training needed, the needed level of education is reduced. Moreover, this makes the service people more flexible.
With the commonality at a higher functional level, coupled to a better error tracing method and added debug functionality routines also to a deeper level in the HMI, the machines are simpler to operate and maintain, resulting in less need for assistance. This supports the philosophy of life cycle cost reduction. The end user easily sees these reduced service and maintenance costs, resulting in a high level of acceptance.
Overall, the usage of world wide standards offer for both the OEM suppliers as well as the users, clear benefits:
- A world wide software standard which everybody can easily learn and understand;
- The development and installation of new machines is faster, more predictable, and easier. This results in shorter installation time of the machines with less risks, meaning a quicker productive line: what used to be up to one month to check the last bugs during full size production can now be done in days, benefiting from the improved software quality;
- The software for a particular machine is no longer developed for a particular hardware type or brand. If a hardware platform becomes obsolete, or the supplier even ceases to exist, the investment in the software is largely protected as it can easily be ported onto a different hardware brand. This secures the customer investment.
Application software development more independent of the hardware
Via standardization and modularisation, Tevopharm protects their investments in software. If one of their customers needs a new functionality, the resulting software can easily be added to the standard in-house software library, if desirable.
This also means that the initial added software investment could be carried by future deliveries also, increasing the efficiency and protecting the investment, while being open to the future. And it provides their customer with more choices in platforms at lower costs and risks.
Standards used at Tevopharm:
The software application development is just one part of a complete operating machine. Other environments have to be considered. Tevopharm uses additional standards for this. These include IEC 61131-3, PLCopen Motion Control, PackProfile and PackML State Model as defined by the OMAC Packaging Working Group (see insert), Sercos as drive interface, and DeviceNet and Profibus as I/O interface.
Current investigations also include a one-CPU architecture for HMI, PLC, and Motion. This should add to the transparency of the overall system, and give access to the latest developments in the Intel architecture, now and in the future.
1.6. What was learned?
A user (customer) already familiar with the IEC61131-programming standard and the PLCopen Motion Control functionality easily can read a program. The same ‘look and feel’ principle to be achieved works in reality! When machine vendors make use of hardware specific extensions to the specified functionality, the similarity is starting to vanish, leaving customers with the need of hardware specific training for their maintenance people.
The above statement is the confirmation that it is indeed preferred to use the basic PLCopen Motion Control Function Blocks, and to neglect hardware supplier specific options.
During the work, Tevopharm experienced a contradiction between the PLCopen Homing functionality and the Sercos implementation. PLCopen states that when homing is started, the controller takes over, where the Sercos protocol denies that. The issue is solved with a separate function block, which will be brought forward to the PLCopen Technical Committee, for a change to the specification.
1.7. Future aspects
The PACK-300CA as showed here uses PC-based control. PC’s do show negative aspects on chip-set obsolescence, as well as on memory resources for their Windows software architectures, making moving parts, like hard disks, necessary. Future controller development will direct to “embedded-pc” architecture, with less vulnerable software and easier back-up media via flash cards. Benefits are expected in the maintenance field at customer’s site. Mechanical engineers with a little general knowledge of PC issues could do the job, where nowadays high level educated electrical software engineers are needed to maintain and debug high-end machines.
Where servo technology has started as a technology push market, the trend is towards commodities-usage. Increased importance of standards as mentioned above will lead to a lower price level of good quality components, even to be provided by the major suppliers of this world.
1.8 Additional information
Overview of a Packaging Production line
The packaging functionality is just a part of a whole production line. However, it is key to the quality the consumer experiences from the product.
The following picture shows a possible packaging production line. On the left side, the products are fed from a main transportation line, which can serve several packaging lines. This line can also contain buffering sections. After feeding, the products are aligned, fed into the flow wrapper, filled in a box, and finally palletised. Additional function here can be product turning, grouping, and multi packing, for instance on a blister.
Picture 4: The product flow in a packaging production line Overview of OMAC Packaging Working Groups
On December 13, 1994, Chrysler, Ford, and General Motors published version 1.1 of "Requirements of Open, Modular Architecture Controllers for Applications in the Automotive Industry." The document provides guidelines for a common set of API's for U.S. Industry controllers to better address manufacturing needs for the automotive industry. The requirements for the development are defined in the OMAC Requirements Document. The signatories of the document are: Chrysler, Ford, and General Motors.
On February 14, 1997, General Motors Powertrain Group (GMPTG) sponsored a meeting of aerospace and automotive industry representatives, proposed to form the Open Modular Architecture Controls (OMAC) Users Group, and invited the attendees to become members. One of the purposes of the group is to establish a specific set of API's to be used by vendors to sell controller products and services to the aerospace and automotive industries.
One of the activities in OMAC is the Packaging Workgroup. It deals with a common approach to future product development by the Packaging Machinery builders that will include more electronic controls from the General Motion Control (GMC) industry.
It consists of the following activities:
 | PackML ? the intra machine language (see picture 5 for an example) |
| | PackSoft ? the software environment |
| PackConnect ? the interface to the I/O?s |
| PackLearn ? providing learining material |
| PackAdvantage ? showing the advantages of it all |
Picture 5: Overview of activities OMAC Packaging Working Group
The mission of the PackSoft Working Group is to develop programming language guidelines for packaging machinery that will: ease learning, support transportability of software across control platforms and allow continuing innovation by all parties. By pursuing this mission they share the vision of a common programming language for packaging machinery based on internationally accepted open standards.
PackSoft Objectives:
- Leverage the programming knowledge that currently exists in the End User community, easing the validation, maintenance and integration efforts required to support packaging equipment from multiple vendors, enhancing the productivity of End User personnel, and thereby manufacturing operations, by reducing the technology learning curve.
- Make intellectual content control hardware independent, reducing the OEM re-engineering effort required to move developed applications across hardware platforms, allowing OEM?s to select a level of technology to match individual applications and/or make use of emerging technologies, delivering a targeted functionality at lowest cost through reuse of developed and off-the-shelf applications.
- Allow Technology Providers and OEMs to continue to innovate, creating competitive advantages for their solutions and driving technology innovations that reduce price, increase performance and/or add new functionality.
- Thorough these and the other Plug-and-Pack initiatives ultimately achieve hardware interoperability and code portability. PackSoft 2003 Goals
- Develop/present a tutorial on IEC 61131-3.
- Recommend adoption of IEC 61131-3 as the first guideline.
- Solicit more OEM presence in the PackSoft Working Group.
- Support the efforts of PLCopen by providing input to the function block requirements for packaging.
- Develop test protocol for a test machine demonstrating hardware interoperability and code portability for basic PLCopen motion function blocks for packaging machinery.
Picture 6: Example of the PackML State Model
For more information check
www.omac.org
![Reblog this post [with Zemanta]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_tn9hyWsWLr7LoPgf_IIGV5FwYGsNwG3vdMvkhSEs8wZmBCk2mjh4wxsZwVLKHaHX-hhl3fn_OSYp2D2VwOVtfmlAW6uLZdYmVxedqHK_OVY9knHHHAomTWKXPzOpmzWA4lxsuQj-lmsaKIflnd3Gkc=s0-d)
