Automatic Generation of Flowcharts

Having access to a synthetic and precise documentation is thus key to the efficiency of all contributors during the whole PLC programs lifecycle. However, manually writing is tire some and error prone. The need for a consistent format perfectly and the tediousness of the task argue for an automated tool- based approach; that’s exactly what PLC DocGen offers.

PLC DocGen generates automatically a dataflow oriented view of a PLC program (from inputs towards outputs) represented by equations and flowcharts, thus abstracting the actual sequential execution of the program. This view is a perfect intermediate formalism between the code and specifications itself.

This view is independent from the type of PLC hardware and the programming style on which the program runs, it is ensuring a consistent formatting for all documents. PLC DocGen may use a parameter any kind of documentation template such as symbols, title blocks, and then apply it to all documents it generates. It is based on approach of a sound technological valid for any PLC in the market, making it the perfect companion to any reverse engineering activity is it for new developments based on maintenance and modernization or for legacy code.

Flowchart generation is offered by Itris Automation Square as a service that follows a clear and rigorous methodology:
• The programs gathering to be documented and transfer of all files to Itris Automation Square.
• The documentation template Definition through the actual documentation generation for one of the supplied programs. The template will consist models of front pages, title blocks, pictograms, tables of content, symbols, blue- print backgrounds, numbering… The template is then formally approved.
• The documentation of actual automatic generation of with PLC DocGen according to a schedule that takes into ac count the priorities of the project.
• Documentation validation through peer proofreading.
• Formal delivery of the documents in PDF and SVG formats applying the template defined before. The documentation may be easily maintained and modified subsequently to the flexibility of the SVG format.

Undocumented PLC Program Causes Major Lost Time

A typical PLC program will be read and modified by many contributors during its whole lifecycle: development and commissioning teams, maintenance and modernization technicians and engineers, project managers, etc. All will have to easily and quickly understand a program they often didn’t develop themselves, especially if they start a new job from some legacy code. Being efficient when modifying some sophisticated and unknown code is always a challenge. Thus, any accompanying document is welcome.

The code is often only available documentation and it may be poorly commented. Also, they generally are a mere high level view and linking them to the actual program may be tricky when some specifications are available. Even if a documentation has been written properly along with the program, it has to be maintained when the code is modified which is costly and frequently neglected. The worst situation is probably when there was only a physical the documentation copy which became unreadable because it was not stored properly.

Working with an undocumented program is always a major loss of time:
♦ Commissioning teams miss a clear link between the algorithms and functional specifications in the code, thus wasting hours during setup and debugging.
♦ Maintenance technicians, working in end-user’s PLC controlled facilities, must be able to quickly fix erroneous programs so that production may restart as soon as possible. Thus, they need a documented clearly high level model of the behavior of the program.
♦ Modernization wanting to convert and potentially re- write a existing legacy program for a more current hardware shall refer to the original specification and design documentation to make sure that they stay consistent with the intended of the system behavior.
♦ Finally, project managers which have to estimate workloads based on high level specifications may not be able to fully understand the actual complexity of the job if they don’t have access to a more detailed documentation closer to the program itself.

Plant Model PLC Construction

The goal of the proposed PLC programming environment is to provide an intuitive PLC programming and verification environment by connecting the plant model to the PLC program. It is essential to develop an efficient construction procedure of a plant model to achieve this objective. The three models are a plant model, an I/O mapping model, and a PLC program. The plant model is controlled by the PLC program through the model of I/O mapping.

The construction method of a virtual device is described before explaining the construction method of a plant model given that a plant model consists of virtual devices. As explained earlier, a virtual device consists of a core part and a shell part.

The shell part, enclosing the core part (the inherent properties of a device, such as kinematics, the execution of device-level commands and the geometric shape), should allow a virtual device model to adapt to different plant configurations. This part is modeled as an atomic model of the formalism of DEVS, which is a timed-FSA (finite state automata). First it is necessary to identify the set of tasks that are assigned to the device to define the shell part of a virtual device. The each task activation is normally triggered by an external signal from either the PLC program or other virtual devices.

It is then possible to extract the state transition diagram, which defines an atomic model of the DEVS formalism once the set of tasks is identified for a virtual device. An AGV (Automatic Guided Vehicle) with two tasks, T1 (movement from p1 to p2) and T2 (movement from p2 to p1) are the two tasks should be triggered by external events, the shell part of the AGV must have two input ports, termed here as Signal_1 and Signal_2. From the set of tasks, it is possible to instantiate the state transition diagram automatically. There are four states, P1, DoT1, P2 and DoT2. While P1 and P2 take external events from the input ports (Signal_1, Signal_2) for state transitions, DoT1 and DoT2 take internal events that are the end events of the two tasks (T1 and T2).

The Layer of PLC Programming Environment

The architecture of PLC programming environment consists of two layers, a model layer, and an application layer. The model layer has three models, a PLC program (control model), a plant model (virtual factory model), and an I/O mapping model. The plant model includes all manufacturing devices of the production system as well as the corresponding device programs to perform their tasks in the production system, and the PLC program consist the control logic for the plant model. It is necessary to define the mapping between the plant model and the PLC program, which is described by the I/O mapping model for the integration of the plant model and the PLC program. The application layer provides two interfaces simultaneously to users.

The ‘PLC Simulator’ performs the control program simulation, and the ‘plant model visualizer’ shows the corresponding plant model (3D graphic models) reflecting the changing states of the production system during the PLC simulation. Thus, it becomes much easier for users to verify the PLC program though the visualizer plant model.

Among the three models of the model layer, the plant model plays a key role in the proposed environment of PLC programming. As mentioned earlier, the plant model should consist all devices as well as the device control programs. The plant model contains of manufacturing devices with their positions in the layout.

This article employs the concept of a virtual device: a digital model imitating the physical and logical aspects of a real device to represent such a manufacturing device. A virtual device needs to maintain its relationships with PLC programs or other devices as well as the inherent attributes of the device, such as the kinematics and geometric shape. To do so, a virtual device is split into two parts; a shell and a core. The shell part can adapt to the different configurations of production systems, and the core part undertakes the inherent properties of the device.

Visual Validation of PLC Programs

It is important to understand the basic procedure used to construct a PLC Program (ladder diagram) to design the architecture of the PLC programming environment. Chuang et al. 1999 proposed a procedure for the development of an industrial automated production system that contains of nine steps. They are:
1) Define the process to be controlled;
2) Make a sketch of the process operation;
3) Create a written sequence listing of the process step by step;
4) On the sketch, add the sensors needed to carry out the control sequence;
5) Add the manual controls needed for operational checks or for the process-setup;
6) Consider the safety of the operating personnel and make additions and adjustments as needed;
7) Add the master stop switches required for a safe shutdown;
8) Create a ladder logic diagram that will be used as a basis for the PLC program; and
9) Consider the possible points where the process-sequence may go astray.

The most time-consuming task for the control logic designers is the 8th step, which is generally done by the repetitive method of ‘Code writing, testing and debugging’ until the control objectives are achieved. The bottleneck of the 8th step is that the conventional PLC programming environments are not especially intuitive, particularly for the testing and debugging of a PLC program, as they show only the status of a PLC without providing any links to the target system.

Engineers need to imagine the state changes of a production line from the input and output ports of a PLC for the validation of a PLC program. That is the reason conventional PLC programming environments are often prone and inefficient to human error. There is a strong need for a more intuitive PLC programming environment as the configurations of production lines and their control programs become more complicated. It is hoped that this article will take positive steps in this direction.

PLC Simulation for Automated Manufacturing System

Industrial production lines are generally dynamic systems whose states change according to the occurrence of various events, thus exhibiting the characteristics of a discrete event system. If manufacturers remain competitive in a continuously changing marketplace, they have not to only continue to improve their products, but also strive to improve production systems continuously.

Thus, an efficient prototyping environment is crucial for production systems. A modern production line is a highly integrated system composed of automated workstations such as a hardware handling system and storage system, robots with tool- changing capabilities, and a computer control system that controls the operations of the entire system. The production line implementation requires much investment, and decisions at the design stage have to be made very carefully to ensure that a highly automated manufacturing system will successfully achieve the intended benefits.

It is necessary to create a much more detailed simulation model that can forecast not only the production capability of the system but also the physical validity and efficiency of co-working machines and control programs for a detailed design (virtual prototyping) of a production line. Various machines that operate in an industrial manufacturing system simultaneously are usually controlled by PLCs (Programmable Logic Controllers) emulates, currently the most suitable and widely employed industrial control technology. A PLC behavior is an electric ladder diagram. To emulate the workings of parallel circuits that respond instantaneously, PLCs use an input/output image table and a scanning cycle as they are sequential machines. When a program is being run in a PLC it is executing continuously a scanning cycle. The program scan solves the Boolean logic related to the information in the input table with that in output and internal relay tables. The information in the output and internal relay tables is updated during the program scan. This Boolean logic is typically represented using a graphical language known as a ladder diagram in a PLC.

Four Steps Programming PLC for Exhibit Control

1. Describe the function program in as much detail as possible from the point of view of the outside world.
2. Identify all inputs and outputs.
3. List all the states of distinct machine and indicate the transitions.
4. Write the program.

Rather than describing programming of state machine in abstract terms, let’s develop a simple control application of real-world exhibit using state machine techniques. Much more complex programs can be built using the same principals interestingly, while a more complex program will certainly have many more states, each state will likely be simple.

The example transitions program sequentially from one state to the next. This is not a state programming requirement you may jump from any state to any other. A more complex program will likely jump around based on varying input conditions.

Describe the function of the program.
The first step in a state machine program developing (and, indeed, any program) is to clearly state the functional objectives:
As a visitor walks through the display, a detector motion triggers the PLC. The PLC will then trigger a DMR (digital message repeater) to play one of several available sound effects. To prevent repetition, the sounds are selected at “random.” A short delay is provided after each effect to prevent the next sound effect triggering by the same visitor.

We will accomplish the “random” selection of the next SFX by using a look-up table that contains three sets of all available message numbers in a non-sequential order due to the inherent problems with random number generation. The next step is to analyze the functional description, and create I/O tables. We usually select a digital message repeater that has a contact that is active as long as the clip is playing thus, the program doesn’t care how long any of the individual SFX are.

Programming State Machine of PLC

PLCs (Programmable Logic Controllers) are a very useful control solution for an exhibit variety and interactive applications. These general purpose control devices can accept an inputs number from such devices as pushbuttons, motion joysticks, detectors, etc. They can have analog, multiple relay, and serial outputs to control lights, sound effects, motors, etc. A control program that determines in the middle which outputs is activated when certain combinations of inputs are received. Available resources include numerous counters, timers, and registers.

The drawback of principal to these devices has been the steep learning curve and inherent difficulty with program maintenance using their traditional Relay Ladder Logic (RLL) programming language. However, PLC programs can become very simple to create, and are easy to maintain and modify by using state machine programming techniques.

A state machine model is a paradigm programming wherein the “machine” (i.e.: the controller) can only ever be in one of a set of distinct states (conditions) at any given time. It is actually a great simplification—as we shall see while this concept may sound complex.

Programming of state machine can be done on any PLC through clever use of SET and RESET instructions and using internal contacts to direct flow. It is much simpler, however, if the PLC supports this programming type directly. The good news is that today many do. The bad news is that they seldom refer to it as “state machine programming,” nor do different manufacturers use the same term. You will see it referred to as “STL programming,” “stage programming,” “SFC programming,” and various other terms.

All of these have one thing commonly: a special internal “contact” attached directly to the power rail controls flow into each state. This contact mostly always has an ‘S’ designation for state. The key concept is that one, and only one, state can be active at any one time, and all the logic in the other (inactive) states is disconnected from the power rail.

PLC Programming State for Exhibit Control
Below is the programming PLC programming state for exhibit control:
S0—Initialization State
This state will apply to every program virtually you create it is the initial state that is always entered upon power up. It is one time executed, and is never re-entered unless the PLC is a RESET or powered down occurs.

This state is primarily used to initialize data variables. It is good programming practice to place all counter and timer data here, and then load the counters and timers from the variables.

This state will initialize the message look-up table, and setup the look-up table pointer to point to the first message number in the table. It transitions to S1 when completed. For clarity, we will not show the ladder diagram for this state.

S1—Wait for Trigger State
Monitor the input of Motion detector for a trigger from the motion detector. Upon receiving a trigger, transition to S2.

S2—Set Message Bits State
Transfer the number of current message from the look-up table to the output of Bitx relays as a five-bit binary value, then transition to S3.

S3—Strobe Message State
Wait for a 0.2S delay to allow the outputs of bit to stabilize, then pulse the Message strobe relay for 0.4S to signal the message repeater to play the message determined by the Bitx relays (i.e.: Y0 through Y4), then transition to S4.

S4—Wait for Message State
Wait 0.4S to be sure the message has started playing, then monitor the input of Message playing until the message has completed playback, then transition to S5.

S5—Get Next Message Number State
Increase the look-up table pointer to make the next message in the “random” sequence the number of current message. If it was at the end of the table, reset the pointer to the start. Then transition to S6.

S6—Wait State
Wait for a delay of programmable to prevent an immediate trigger of the next sound effect by the same visitor. The delay of value is determined by the value of a variable initialized in S0. Then transitions to S1, and start the process again.

Human Machine Interface (HMI) based on Intel Core Duo Processor

Such a trend in the industrial PC becomes very compelling when one looks at the HMI (human machine interface) as industrial PCs become more closely integrated with equipment. The graphical user interface is moving from workstations directly into industrial equipment along with the controller, making the usability of industrial devices more straightforward and bringing sophisticated graphics based control to more points on the factory floor. A wide variety of Intel based panel PCs are available.

For instance, the panel PC V from Kontron incorporates an ETX Express board with an Intel Core Duo processor along with a 12.1 inch to 17 inch analog resistive touch screen in a rugged enclosure. It also includes five USB ports high speed networking, fanless operation and two open PCI slots. It can be used for any kind of interface from a relatively simple machine specific GUI to a full blown supervisory control and data acquisition system.

The advantage of an Intel Core Duo processor in such a system is that one core can be devoted to running a soft real time operating system like Windows XP Embedded for all the most common tasks such as the Human Machine Interface (HMI) software, networking communications, data logging, etc. while another core can be completely dedicated to real time operating system performing the most time critical operations. Data exchanged between the two OSs via the mechanisms using shared memory will not interfere with the RTOS operations. Such a panel PC puts it all in one rugged box, real time control, graphical operator interface and any other needed computer operations.

Intel’s low power solutions, both in terms of Intel Ultra Mobile chipsets as well as the Intel Ultra mobile processors can extend the some powerful functionality into handheld and mobile devices for a high end human machine interface (HMI) on a small device to connect over a wireless link to a process or machine, which lets the operator use the same HMI on a smaller display.

PLC Programming by Integrators

The dealing complexity with integrators has been a surprise. Integrator companies in the market of irrigation have been quite independent, with little independent review of their work. Their documentation procedures of programming, their neatness of organizing wiring and panels, their usage of programming languages, and their exposure to PI (Programming Integrators) algorithms for canal automation are quite varied. This means that nothing can be taken for granted, even if an integrator can list numerous completed projects.

Three items are particular concern:
1. A good integrator will always understand hardware, communications, installation, and programming quite well. But it is rare that an integrator is familiar with modern canal control algorithms, and how they are tuned within a simulation model. This can be an issue if the integrators take unwarranted liberties in the programming of the algorithm control that we supply as well as with the tuning constants that we provide.
2. Sometimes integrators embed numerous checks into their code with various hidden constants that can shut down a gate or pump operation. The irrigation district operators do not know these constants exist, do not know how to access them, do not really understand how the constants should be charged, and must generally personally visit the PLC to change the constants. We believe all alarms and constants should be transparent and changeable from within the office via the supervisory control and data acquisition system. A portable PC with a copy of the HMI (Human Machine Interface) software can be used in the field to change constants if it is desired to make in field adjustments.
3. The control algorithm for a gate may only occupy 10% of the total programming that most integrators put into the PLC. The remainder of the programming handles numerous checks of sensors and equipments, consideration of gate inertia, and other factors.

From PLC to PAC based Computer System

Renowned for their reliability and robustness, the programmable logic controllers (PLCs) that have been used traditionally in factory automation have been evolving with the microprocessor control systems development. Originally oriented around the ladder logic that imitated the wiring of physical timers and relays, PLCs that have incorporated the computer control also need a way of handling more complex control tasks that can not be defined in the ladder logic. Tasks involving floating point arithmetic and PID control loops, for instance, require higher levels of processing and programming.

It has evolved into the programmable automation control (PAC) as more computing power has been added to the PLC, a computer based system, which is multi functional and can simultaneously monitor and control digital, analog and serial I/O signals from multiple sources. PACs, in contrast to their PLC ancestors, handles multiple domains like motion, logic, drives and process control on a single platform, which means they also use a single development environment with richer programming resources, a single data base and the ability to use open architectures for interfaces, networking and languages. The strength source for a PAC is its processing the power and its multiplicity of I/O capabilities. Most PAC manufacturers offer a huge of I/O variety modules for all kinds of special requirements. The I/O signals are then translated by the software. These capabilities are integrated in a rugged, industrial package.

Of course all this makes increasing demands on the processors, network silicon and chipset, including the Intel Celeron M and the low power Intel Core 2 Duo processors that integrate processor cores, PCI Express, USB 2.0, UARTs, SATA and Gigabit Ethernet. This enables the controller systems development with a scalable range of price and capabilities points but which share industry standards in terms of hardware compatibility, ease of the modularity and development.

GE Fanuc PLC Bridge to PACSystems RX7i

If there is an open slot in the GE Fanuc PLC rack and there is a GE Fanuc card or third party VME card available to make the connection, then creating a bridge between the PLC and the foreign network is not too difficult. However if there is no slot available, then the expense of expanding the current rack or adding another rack can be a costly proposition. Furthermore, some third party VME cards have a set of issues all of their own, making their inclusion into your application time consuming. The caveat was there could be no rack expansion or Profibus communication cards added to the system in the case of Sytech System’s client.

Sytech Systems can provide a bridge between Fanuc PLC family intrinsic or existing Ethernet network and almost any other industrial network using the Anybus X-gateways. PAC system RX7i Ethernet to Profibus network slave devices as in GE Fanuc’s client application, Sytech Systems can create a communications path to meet the required specifications.

Benefit 1
The Anybus X-gateway implementation does not require the use of Fanuc or third party VME communication cards. There is never a need to expand the current PLC rack size or add an expansion rack.

Benefit 2
The independently powered and remotely mounted Nybus X-gateway uses existing Ethernet communications to exchange data with the Fanuc PLC via Modbus/TCP. No other equipment is required to bridge between the PLC and any other network other than the Anybus X-gateway and a 24V DC power source.

Benefit 3
The Anybus X-gateway allows up to 125 Profibus slave devices in the PACSystems RX7i to Profibus application. The PACSystems RX7i has up to 32 Modbus/TCP channels as cited in the example. If each Modbus/TCP channel were connected to an Anybus X-gateway device, the PACSystems RX7i could potentially communicate with 4000 Profibus slaved devices.

GE Fanuc PAC800 Controllers

GE Fanuc intelligent platforms announced new control system PAC8000. This family is powerful to offer the controllers, software solution and I/O systems. PAC8000 Controllers will help you to improve your operational performance and productivity so it is good to bring you a basic overview of PAC8000 products.

MTL and its products MOST are a new acquisition of GE Fanuc Intelligent Platforms. The system can be used as independent control system or remote I/O units. PAC8000 family is integrated into Proficy Process Systems (PPS). Proficy Process Systems with PAC8000 controllers presents with a powerful and flexible Distributed Control System (DCS). As PAC in the name suggest the system is suitable for a wide range of application while PLCs could be used only for discrete application. The family offers controllers, remote I/O software and modules.

PAC8000 are designed for a hard work in rough conditions and work there where no one controller could exist.
• They survive 5G at a vibration and30G at a blow.
• Controllers are configurable inf running.
• They operate in -40oC to 70oC.
• Redundancy is a great advantage of the controllers. Redundant controller can be used for critical control applications. The pair of redundant controller operates in parallel checking status multiple times through the processing loop enabling the back up controller to monitor continuously the health of the master controller, assuring a rapid and bumpless transfer to the standby controller. Backup controller is also capable of receiving both control program and firmware updates.
• PAC8000 Controllers communicate on a peer to peer basis so that critical information can be efficiently shared between controllers.
• Controllers can pass the information of HART from smart field devices to a separate of PC workstation running asset management software applications.
• Controllers support all five IEC 61131-3 programming languages, namely LD SFC, ST, FBD, Instruction List and Flow Chart Language.
• The controllers feature serial interface RS 485 half duplex, 9 pin D type connector and transmission rates 1.2 – 115.2 kbit/s asynchronous.

GE Fanuc PLC of Anybus X-gateways

Using the existing port of Ethernet communications available on the GE Fanuc family of PLC’s and the HMS Anybus X-Gateway, it is possible to create a transparent bridge between the PLC and any used industrial network commonly via Modbus/TCP. The Anybus X-gateway family is a product line targeted to connect almost every possible combination of two industrial networks.

The product family supports 17 different fieldbus networks such as DeviceNet, Profibus, CANopen and CC Link allowing the GE Fanuc PLC family easy data transfer via ModbusTCP. The X-gateways are designed to use in industrial automation plants where increasingly many different networks are used. The X-gateways help system integrator to inter-connect easily any GE Fanuc PLC, enabling consistent information flow through out the entire plants.

The X-gateways focus primarily on the transfer of cyclic I/O data between two networks. This can be either a slave-slave combination or a master-slave combination. The user simply selects the amount of I/O to be transferred between the GE Fanuc PLC and the foreign network during the set up of the gateway. The data with least amount of I/O data determines how much data can be transferred in each case since all industrial networks support a different amount of I/O data. The transfer time between the 2 networks is typically 10 to 15ms.

The X-gateways can bring together the network world of GE Fanuc, Rockwell, Siemens, Hitachi, Omron, Bosch, B&R, Moeller, Beckhoff and many more.

All PLC systems programmer and designers, at one time or another need to communicate with devices or equipment operating on a network other than the one to which GE Fanuc PLC is attached. Creating a bridge between the two networks in order for the GE Fanuc PLC to send and receive data is usually problematic and consuming time to accomplish. Sytech System’s client needed to interface between a Siemens Simocode and PACSystems RX7i PLC.

Modbus Omron Protocols Support

The T100M + PLC supports a subset of the Omron and Modbus (both ASCII and RTU modes are now supported) compatible communication protocols so that it can be easily linked to third party control hardware or software products such as Supervisory Control and Data Acquisition software, touch panel etc. the PLC recognizes automatically the type of command format and will respond with the correct response. These were accomplished without user intervention and without any need to configure the PLC at all.

Both Omron and Modbus protocols use the same device ID address (00 to FF) as the native protocol. Since the internal variables and addresses of I/O in the T100M + PLC are organized very differently from the Modicon or Omron PLCs, we need to map these addresses to the corresponding memory areas in the other PLCs do that they can be easily accessed by their corresponding protocols. All I/Os, counter, timers, internal relays, and data memory DM[1] to DM[4000] are mapped, however, 32-bit variables and string variables are not mapped since they fundamentally quite different in their implementation among different PLCs. Internal variables which are not mapped can be still be accessed by copying the contents of these variables to unused data memory, so that they can be accessed by these third party protocols.

The rev D of the T100MD+ or T100MX+ PLCs also supports the Modbus RTU protocol. The difference between the ASCII and RTU protocols is that the latter transmits binary data directly instead of converting one byte of binary data into two ASCII characters. A message frame is determined by the silent interval of 3.5 character times between characters received at the COMM port. In other hand, the memory mapping and function codes are identical to the Modbus ASCII protocol.

The new rev D T100M+ PLC can also act as a Modbus RTU master. The same WRITEMODBUS and READMODBUS commands can be used to send and receive Modbus RTU commands. What you need to do is to add decimal (10) to the COMM port number to signal to the processor that you wish to use Modbus RTU commands on COMM1.

Omron FINS Communication Interface API

Omron FINS Ethernet Communication Interface API from DASTEC Corporation allows the user to implement bi-directional communications to exchange data between applications running on a PC based or embedded system with other peer devices supporting the Omron FINS Ethernet protocol. The peer devices can be Omron C, CV, CS1, or CJ1-Series PLC, other host computers or even other system applications using the API.

The API of Omron FINS Ethernet Communication Interface enables a system to acts as a client to other Omron FINS peers, initiating write and read operations on behalf of the system applications. The API also allows the system to emulate an Omron C, CV, CS1, or CJ1 Series PLC to respond to write and read request and thus acts as a “virtual PLC” to other Omron FINS peers. The API is available for various combinations of hardware platforms and operating systems can be used with C, C++ or Visual Basic.

The API contains of two component functionalities, server side and client side. The client side functionality is implemented with a single API library. Server side functionality is implemented with a library or executable pair. These components manage together all aspects of the protocols and data exchange including responding to peers with proper acknowledgements, error or success codes and protocol data byte ordering. The system application only need to deal with the data values exchanged in native byte order. The user can employ either the API’s client, server or both functionalities with minimal implementation of code.

A system application can initiate write and read to peers by simply calling the client library functions. The functions include the ability to create handle for the peer device and then using those handle to call client’s library write and read functions.

Client API supports:
• Defining multiple device of Omron C, CV, CS1, or CJ1 Series
• Function to read data from and write data to define device
• Flag data can be written/read as packed bits.
• Word data can be read/written as 16-bit, 32-bit, or as ASCII values
• Multiple user applications can use the API client

CAMD Control System Upgrade

Louisiana State University CAMD (Center for Microstructures and Devices) began a project to upgrade the Linac control and storage ring systems. Control systems for the linac and storage ring were DEC VAX/VMS and VME/OS9 based system respectively. The aims were to utilize free software, inexpensive hardware, and provide a flexible architecture where new projects could be easily integrated. The storage ring control system has been replaced with a PLC/Linux system based system, and the VAXes removed. A superconducting wiggler from the Budker Institute has been integrated and commissioned into this system. Now CAMD is focusing on expanding the control system to include the linac and a second RF system, and reengineering subsystems to provide more reliable control. Automationdirect PLC hardware has been chosen as the hardware platform to upgrade while PL/Linux will provide the machine interface.

Several control upgrades are recently in progress:
1. The CGR-MeV linac recently runs on a VME/OS9 platform. Several of the cards were custom made for this project, and have large silicon components which we have are unable to identify. The equipment protection interlocks are in software, and the system is loaded to the point that if the system is “ping”ed via TCP/IP, the watchdog timer expire and the linac shuts down. The software documentation only exists at the source code level, so determining program flow is difficult.
2. New protein crystallography efforts at CAMD are driving the need for a second RF system. A major requirement is to have both RF systems use identical “off the shelf” components for ease of maintenance.
3. The kicker magnet controls are provided by Allen Bradley PLCs. The PC scanner card required to communicate with the PLC has two problems. First the scanner card has acknowledged firmware problems which can cause the bus to “hang”. Second, Linux software for the card is not available.
4. An upgrade is desired for the water control system. The current controllers have proven to be unreliable, and have presented interface difficulties.

The PLC Tasks Running by a PC

The equipment protection modules run in the PLC, and check the machine status against a table of hardware limits located in the dual port memory. These tasks run in the PLC because the D4-450 CPU can start scans on a timed basis, and generate exceptions if scan time take longer than their allotted time. The PC running a multi tasking operating system can not guarantee as precise scheduling as the PLC. Failure to complete a scan on time will be reported by status bits in the dual port memory. This status can also be reported by a report on exception feature of the Ethernet module, allowing instant notification to both the PC, and any other processors performing equipment protection table driven like the input or output configuration tasks, a generic software program can caused even in cases where equipment protection is not needed: an empty table implies no work for the task to perform.

Finally the PC is responsible for man or machine interface and configuration tasks. Monitoring machine status and updating hardware set points are performed by writing and reading values in the dual port memory. Equipment protection ranges are adjusted by updating the corresponding tables. Initial input or output configuration information is handled by querying the PostgreSQL database for channel vs dual port memory location mapping, then updating the appropriate tables in the PLC’s memory. Once the PLC’s are configured by the PC, equipment protection modules are no longer dependent on the PC for operation. This frees the PC for operator control, automation, and logging functions.

One of the major benefits of the linac control system upgrade will be automated logging of linac machine limits and parameters. The control system recently keeps historical records of orbits, ramp files, beam current, power supply diagnostic tests, and channel default values. Specialized analysis programs are used to determine gradual drifts in component performance.

The Reasons to Choose Automationdirect DL405 series PLC

The Automationdirect DL405 series PLCs with D4-450 CPU’s were chosen for some reasons. First, this PLC series can be used for all of the upgrades. This reduces software development, maintenance and spare parts costs by reducing the number of separate hardware platforms that are in use at the facility. Second, the hardware is inexpensive. Automationdirect hardware is approximately half the cost of a similarly equipped Allen Bradley system. A PLC system provides greater capability at a smaller cost than a similarly equipped CAMAC system for a small number of channels. As the channels number increases, however, that saving decreases. Third, sufficient documentation is available to communicate with the hardware using Linux, including the source code and a user supplied Linux port of their software development kit. The source and documentation are a “work in progress”, but we had no difficulties in getting the system up and running. Fourth, the system can be used with either the PC or a dedicated PLC CPU as the controller. In the first case, the PLC can be used as I/O simply. In the second case, local intelligent can be provided for equipment ramping, protection or PID control. Fifth, the D4-450 CPU’s can generate exceptions if the expected scan time is exceeded, providing a watchdog against failure of the equipment protection modules. Sixth, interrupts inputs are available. These can be used for synchronization purposes, allowing the use of both the PLC and the CAMAC systems during ramping if driven by a timing signal. Seventh, PID control is locally available in the CPU.

Using PLC has some drawbacks. Analog voltage input and output modules are limited to 12-bit conversion, and are only available with up to four channels in a module. Memory of each CPU is limited to approximately 28K words, so complicated ramps may have to be used. The programming interface of PLC is Automationdirect DirectSoft Software.

PLC Software Design of Automation

The Automationdirect Ethernet communications module allows the PC to write and read the PLC memory without special code in the PLC. This led to the idea of using a “dual port” memory model, where machine status is communicated between the PLC and the man or machine interface on the PC thru the PLC’s memory, requiring no special hand shaking or communications code. This allows the same flexibility with equipment protection code by also storing equipment protection limits in the dual port memory: it can be located in the PC, the local PLC, or in a second PLC that connected on the Ethernet network. The software is therefore organized into three sections, the hardware input or output section, the man or machine interface, and equipment protection.

The hardware input and output module’s responsibility is to keep the dual port memory and the hardware status synchronized. Tables containing hardware setpoints are written to output channels, and the status of input channels are written to “readback” tables in the dual port memory. Preliminary these code versions are hardwired: the number and types of hardware channels are fixed, as well as the corresponding addresses in the dual port memory. The code will be upgraded to a more flexible architecture as long as the increase in complexity does not impact the effectiveness of the equipment protection modules.

Input and output configuration will be based on a combination of the PLC’s input and output module probing and a table driven mapping between each channel and a dual port memory location. This table would be provided by the PC, and correspond to the channel mapping as recorded in the PostgreSQL database. This would also provide the benefit of allowing all PLC CPUs in the facility to run the same code, regardless of I/O configuration or specific hardware task.

Mitsubishi FX2N Controller

The Mitsubishi FX2N controller is a Programmable Logic Controller (PLC), which combines the properties of compact and modular system one. Though its small dimensions the controller is one of the fastest PLC. The controllers installed in the laboratory are FX2N-32T type with following technical specification:
• Built in 230 VAC power supply
• 32 input and 32 transistor outputs
• Integrated serial port for communication with PC or visualization panel
• Wide range of expansion modules:
Additional I/O modules
Network modules for AS-I, Profibus DP, DeviceNet, I/O Link, CC Link, CAN Open, Ethernet
Additional RS485 board
Fast counter modules
Analog modules including thermo element inputs
Positioning modules
• Programming via MELSOFT GX Developer or GX IEC Developer package

FX series is programmed similarly to the other, bigger PLCs manufactured by Mitsubishi, so the practice with it can be a good preliminary to gain programming skills for working with ‘A’ or ‘Q’ series systems. The FX2N can be programmed in Ladder Diagram (LD), SFC, and IL languages because of use the GX Developer software. Structured Text (ST) is available only for ‘Q’ systems. There also exist special cut down versions of GX IEC Developer and GX Developer designed especially for FX series. The other dedicated software is the MELSEC MEDOC FX-PCS/WIN-E.

The variety of available programming software makes the FX series very flexible for use on different level of user knowledge. Beside FX PLC and Alpha, there are also modular controllers in the laboratory: and old ‘A’ series and ‘Q’ series. In the laboratory ‘A’ series PLC system are installed: one based on A2 CPU and the other on A4 CPU. The A4 system contains of the following:
• power supply
• CPU
• Ethernet interface module
• MELSECNET II/B module, coaxial cable
• MELSECNET II/B module, twisted pair cable
• 16 relay I/O block, 240 VAC/24 VDC, 2A
• 24 relay I/O block, 240 VAC/24 VDC, 2A

OPC Bridging Software

The OPC (OLE for Process Control) Bridging Software is to interconnect two OPC servers were Matrikon’s ODM (OPC Data Manager) and Kepware’s LinkMaster. These programs called OPC bridges or OPC routers are able to read data from one server and write it to another. Both programs are similar in operation and configuration. The functionality includes of the definition of update rates and groups, input/output pairs, dead-bands and quality checks. The LinkMaster even allows to write one input value to more than one output variables and to perform the mathematical operations between. To make bulk configuration easier, both programs allow to import and export the configuration and to CSV (comma separated values) files.

We ran both bridging programs with a fully functional, the time limited testing license provided for free by its vendor. A range of other software was used on the engineering or test system computer for setup and testing. The most important programs are specified shortly:
• MatriconOPC Explorer is a freeware OPC client allowing connecting to any compliant OPC server and displaying the value of chosen tags. It also support writing of variables and preserving settings. Furthermore, it allows measuring the maximum update rate of the OPC servers it is connected to.
• Office 1003 of Microsoft was used for day to day work and configuration tasks. Especially Excel was helpful for the variable definition in AC800M and for bulk configuring the bridging software using CSV files. Furthermore, Excel allows convenient bulk set up of Profibus devices and its variables with the Bulk Data Manager plug in.
• Microsoft’s Sysinternals Process Explorer is a freeware program to monitor system processes and their use of resources.
• Synergy was used to operate two screens and computers with only one keyboard and mouse.
• Irfanview helped with the screenshots caption.

Mitsubishi Alpha Controller

The Mitsubishi Alpha controller is a compact type PLC designed for simple control applications which does not require high speed and many inputs. The controller is equipped with a small LCD screen, on which statements, status of inputs and outputs and configuration settings can be displayed. It has also several keys acting as navigation keys through the controller menu and can also be used in program as additional inputs.

The other property of the keys and screen is possibility to edit the program written into the controller without use of a computer with programming software. The controllers used in the laboratory are Alpha XL type exactly AL2-14MR-D. They have following technical specification:
• 24 VDC power supply
• 14 inputs/outputs connectors:
8 digital inputs, which can be turned programmable into analog inputs with 9 bit resolution and 0-10 V input voltage range
6 relay outputs
• slot for EEPROM or personal computer connection
• wide range expansion modules:
GSM modem connection module
Additional input/output module
AS-I network connection module
Temperature – analog conversion module

The overall Mitsubishi Alpha PLC view, on the example of AL2-24MR-D controller has two controllers. Both controllers have the same appearance, but different input and output numbers.

The Alpha XL controllers, installed in the laboratory are supplied from 24 VDC source. The power can be brought from 230 VAC/24 VDC converters or directly from 24 VDC laboratory mains. There is no risk of electrocution during the experiments because of operating on safe voltage.

Mitsubishi Alpha controllers are programmed in Function Block Diagram (FBD) language. The FBD is a simple representation of real inputs and outputs dependence, thus the program can be also traced and edited directly on controller display. Program has the diagram structure: on the left side the inputs are represented and on the right, the outputs. In order to create a new program the block should be placed between input and output connected by lines.

Mitsubishi PLC in Student’s Preparation of Industry Realization

Automation plays great role in contemporary industries. Through the century of twentieth it has been evolved from simple sequential control to the complicated electronics systems. Now it is hard to imagine a factory without numerically controlled machines, robots and PLC (Programmable Logic Controller). Fast economic growth, searching for new, clearer technologies are the main factors of progress in the industry. Because production becomes more efficient, then controllers become faster and more complicated. Passing over the group of specialized controllers, the most of programmable logic controllers used in industry are modular. In that manner they are more flexible in application.

Contemporary industrial trends require preparation of new engineers that can cope with certain tasks from designing a system, through code development, to set the whole process in motion. Ht Engineering Processes Automation and Integrated Manufacturing Systems Institute at the Mechanical Engineering Faculty have five laboratories, where students can evolve their skills. One of these is the laboratory of sensors and industrial network. At the laboratory room several types of industrial networks, like AS-1, Profibus, CAN, CC-Link, MelsecNet and Ethernet are installed. Another meaning system is distributed control based on Profibus network, used in transportation system. Student also has to their disposal several types of programmable logic controllers manufactured by Siemens, GE, Mitsubishi and Fanuc.

Other equipment is control panel and visualization, frequency processors, network and PLC expansion modules. The laboratory is intended for individual work of scientific staff and students in following manner:
• Realization of semestral work
• Realization of BSc Eng and MSc Eng thesis
• Realization of PhD dissertations
• Individual evolve of students skills within the confines of scientific circles

A lot of laboratory equipment has been manufactured by Mitsubishi Corporation, it is mostly used by scientific staff and students. Some concepts of use of the Mitsubishi PLCs during realization are shown on the syllabus.

Specification of OLE for Process Control

OPC or OLE for Process Control is an open standardized software communication interface specification launched in 1996 by a task force of different automation companies, later forming the OPC Foundation. OPC is an adaption of Microsoft’ Object Linking and Embedding OLE to the process control business which used to be proprietary highly at hat point of time. It was almost impossible to efficiently combine products of different vendors. By providing OPC servers with their devices, software, and buses, vendors open their products to any OPC compliant client able to connect to the server for data exchange. An OPC server can handle several clients at once, while these clients, e.g. visualization or calculation applications can connect to different servers in order to obtain needed information.

The OPC Foundation has been adding eight additional specifications to the original one, therefore the name OPC was freed from its original meaning and is used as an umbrella term. Some important specifications are quickly explained in the below:
• Data Access (DA) is the original and most used widely standard of OPC. Its purpose is the cyclic polling of real time data, for instance for visualization purposes.
• Historical Data Access (HDA) specifies the access to already stored data.
• Alarms and Events (AE) describes the non cyclic, event based exchange of events and alarms.
• Data eXchange is a specification since 2002 which regulates the direct communication between two OPC servers.

It was made use both of the DA specification for the main purpose of communication as well as the AE specification in order to display and log round trip times. Unfortunately, the promising Data eXchange specification is almost inexistent in practice.

The underlying technique to exchange data is the component object model COM of Microsoft Windows, therefore OPC can run on Windows Operating system only. A new generation of OPC specification currently published is called OPC UA (OPC United Architecture and is independent of COM, thus being able to run on more operating systems as well as embedded devices.

Get Real Time Data with DCS and OPC

Many plants tend to focus on statistical averages of performance, such as average cost, reject rate, or percent uptime. These are excellent measures of process results, but in order to make improvements, we need to focus on real time measures of performance. These measured should meet the following three criteria:
• Meaningful
• Measurable
• Actionable

When measure is actionable, it helps to lead you directly to a corrective action. The key to making process improvements is to measure the right things, and then to respond with the right corrective actions.

Some of the most common real-time measures that meet these criteria are presented along with a discussion on how these measures can be made available via a PSS (performance supervision system). A PSS monitors real time data, calculate performance metrics.

With the advent DCS (distributed Control System) and open communications technologies such as (OPC) OLE for Process control, now process plant has access to wealth of real time information. A real time PSS can crunch through all the raw data and develop meaningful real time performance measures.

The process plant has already gathering real time data from instrument throughout the plant with a PLC control system or DCS. Control systems have been doing for years. More currently, control system vendors have been opened up their proprietary systems. OPC is a series standards communications that provide open connectivity in industrial automation systems.

Once the data is available via OPC, it can be shared with:
• Other control system
• Supervisory control
• Real time data historians
• Performance supervision systems

Performance supervision systems will perform many of these calculations automatically, based on the available real time data. The real time data from plant instrumentation can be transferred via OPC or historians into a PSS. Web based plant dashboards can make the data accessible to users throughout the plant or even the corporation.

Development and Functional Benefits of PAC

The characteristic that define a PAC (Programmable Automation Controller) also describe well the key advantages of deploying a PAC in an application of industry. These advantages include being able to independently meet complex requirements that PLC requires extra components to do and improve the controls system performance due to integrated tightly software and hardware.

The integrated software and hardware is also an advantage when programming: the IDE (integrated development environment) used to program a PAC includes a single tag name database shared by all development tools. PAC is using one software package to address existing and future automation needs, instead of using multiple software packages and utilities from various vendors.

Other Programmable Automation Controller benefit is how easily control systems can be upgraded. Modular processor hardware can be replaced with no need to trip out existing actuator and sensor wiring. A PAC also conserves valuable cabinet space due to its compact size.

PACs (Programmable Automation Controllers) make production information available in or near real time with their modern networking and communication capabilities. This in turn makes the data collected more timely and accurate, and thus more valuable for business use.

PACs can offer multiple financial advantages. The overall cost of the control system is lowered because hardware is less expensive and less integration and development time is needed. Buying a PAC is often more affordable than augmenting a PLC to have similar capabilities. There is also an increased return on assets, lower total cost of ownership, and reduces lifecycle costs due to extending an automation systems range of applications.

At the end, cash flow is improved because of using PAC, the ability to add as separate modules means that just the minimum number of modules needed for initial development can be used during design and the remaining modules added toward the end of the project.

PAC as based Data Acquisition

A DAQ (Data Acquisition) system is a PC based device that provides fast signal acquisition, data storage capabilities, basic signal conditioning, and limited networking. The majority DAQ systems are PC based, limiting their use in challenging physical remote locations or environments. Most DAQ systems thus find their home in the comfort of a laboratory rather than in field locations.

PACs (Programmable Automation Controllers) offer versatile and flexible signal sensing, multiplexing, and conditioning. Acquired raw data can be collated, aggregated, or otherwise processed with a PACs powerful processors and large amounts of global memory, for instance converting raw data into engineering units, before being sent to a database or other application. Alternately, the data could be locally archived because a PAC is not a PC and is not hindered by a PC’s high cost of ownership, it can be deployed in field applications with confidence.

Various industrial automation vendors now offer PAC or PAC like a product. The product is more PLC-like, while in other hand the offering is more like an industrial PC. PAC integrates capabilities from both of these devices as described earlier, so a device that emphasizes PC capabilities or PLC may or may not fit your application requirements.

Some vendors have been in the field longer than others. Many vendors have currently introduced their new PAC or PAC-like offerings, a select few companies have demonstrated a successful track record of providing PAC functionality since several years before the term itself entered into the mainstream. Opto 22 is one of the companies.

Opto 22 was first was to market with a PAC type hardware device in the form of its computer based mistic controller. Recently Opto 22 SNAP PAC systems build on more than 15 years of experience and thousands of successful mistic and other PAC installation over the world involving applications semiconductor processing, water and waste water treatment, material handling, pipeline monitoring and many more.

PAC Exchange Data with Enterprise Systems

The PAC (Programmable Automation Controller) exchanges production, manufacturing, and inventory data with an enterprise SQL database. This database in turn shares data with several key business systems, including an ERP (enterprise resource planning) system, OEE (operational equipment effectiveness) system, and SCM (supply chain management) system. Because data from the factory floor is automatically and constantly updated by the PAC, timely and valuable updated by the PAC, timely and valuable information is available continually for all business systems.

A RTU (Remote Terminal Unit) is a controller like device that installed at a remote location to collect sensor and other data. Popular for decades, RTUs are typically used as part of a supervisory control and data acquisition network, where an RTU sends data to a master. The RTU also receives information from the supervisory control and data acquisition master to operate field devices at the remote location.

RTUs are primarily deployed in distant geographic areas to acquire, monitor, and control remotely dispersed assets such as pipelines, lift stations, wellheads, or telecommunication facilities. Traditional PLCs do not natively posses the communication capabilities needed for use in these types of applications. PLCs typically do not offer the ruggedness to withstand hash environmental conditions, nor the flexible I/O configuration required in most RTU applications. RTUs were developed specifically with a focus on communication capabilities in the absence of these capabilities, with a focus on communication capabilities, suitability for harsh environments, and flexible I/O configuration.

However, legacy RTU communication capabilities are usually outdated, as they were developed in a time of private radio or leased line networks. Today’s open, IP based wireless and wired local and wide area networks are more flexible and often less expensive. Because of this retrofitting an implementing new applications or existing RTU using outdated RTU technology does not make good business or technical sense.

Applying the PAC to a Modern Industrial Application

Look more closely at how a PAC (Programmable Automation Controller) is applied to a modern industrial application using the factory application. The PAC is operating in multiple domains to manage and monitor a production line, a chemical process, a test bench and shipping activities. The PAC must simultaneously manage analog values such as temperatures and pressures, switches, digital on/off states for valves, and indicators; and serial data from inventory tracking and test equipment. At the same time, the PAC is exchanging data with an OLE for Process Control (OPC) server, a Structured Query Language (SQL) database and an operator interface. Handling simultaneously these tasks without need for additional processors, middleware, or gateway is a hallmark of a PAC.

The PAC, office workstation and operator, testing equipment, production line and process actuators and sensors, and barcode reader are connected to a standard 10/100 Mbps Ethernet network installed throughout the facility. In some examples, devices without built in Ethernet connectivity such as temperature sensors are connected to I/O modules on an intermediate Ethernet enabled I/O unit, which is turn communicates with the PAC.

The PAC communicates with remote racks of I/O modules to read or write analog, digital and serial signals using this Ethernet network. The network also links the PAC with as OPC server, a SQL database, and an operator interface. A wireless segment is part of the network, so the PAC can also communicate with the mobile assets like the temporary operator workstations and forklift.

The PAC can control, exchange data and monitor with this wide variety of systems and devices because it uses the same standard network technologies and protocol that they use. This example includes wireless and wired Ethernet networks, IP (Internet protocol), network transport, SQL and OPC. In other control situation, common application level protocols such as Modbus, Simple Network management Protocol (SNMP), Potin to point Protocol (PPP) over a modem could be required. The PAC has the ability to meet these requirements of diverse communication.

The Characteristic of Programmable Automation Controller

The manufacturers of automation have responded to the modern industrial application’s increased scope of requirements with industrial control devices that blend the advantages of PLC style deterministic process control or machine with the flexible configuration and enterprise integration strength of PC based systems. Such a device has been termed a programmable automation controller (PAC).

While the ideal combining PLC and PC based technologies for industrial control has been attempted previously, it has usually been done through the “add on” type of approach described earlier, where additional processors, middleware or both are used in conjunction with one or more PLCs. A PAC however, has advanced capabilities needed built into the design. For instance, to perform functions like counting, PID loop control, latching, and data acquisition and delivery, a typical PLC based control system requires additional, and expensive, processing hardware. A PAC has these capabilities built in.

A PAC is notable for its modular construction and design, as well as the use open architecture to provide interconnection and expandability with other devices and business systems. PACs are marked both by efficient processing and I/O scanning.

Characteristic that industrial analyst ARC Advisory Group originated the term “PAC”. ARC coined the term for two reasons: to help automation hardware users better define their application needs, and to give automation hardware vendors a term to more communicate clearly their products capabilities.

A Programmable Automation Controller must fulfill the below requirements:
• Operate using multiple a single platform in multiple domains
• Employ a single platform of development using common tagging and a single database
• Tightly integrate controller software and hardware
• Be programmable using software tools
• Operate modular architectures that mirror industry applications, from machine layouts to unit operation in process plant
• Employ de-facto standards for networks interfaces, protocols and languages, allowing data exchange as part of the networked multi vendor systems
• Provide efficient processing and I/O scanning

Industrial PC Based on PLC Application

Implementing modern industrial application can present a challenging and sometimes daunting mix of requirements. For instance, it is well understood that a typical control system must interface with signals from simple actuators and sensors, yet for many modern applications this is merely the starting point. Advanced control features, device interoperability, network connectivity, and enterprise data integration are all capabilities demanded increasingly in a modern industrial application.

These modern requirements extend far beyond the traditional discrete logic based control input/output signals handled by a PLC (programmable Logic Controller). Most PLCs are programmed using Ladder logic diagram, which has its origins in the wiring diagrams used to describe the connections and layouts of discrete physical timers and relays in a control system. Applications that expand beyond or diverge from this model become increasingly hard to program in ladder logic. For instance, mathematically complex applications such as proportional integral derivative (PID) loops used for temperature control involve floating point arithmetic. PLCs must often be enhanced with separate hardware cards.

Using a PLC to meet modern application requirements for enterprise data integration device interoperability, network connectivity presents other challenges. These type tasks are usually more suited to the capabilities of the computer. To provide these capabilities in a PLC application additional processor, network converters or gateways, middleware software running on a separate PC, and special software for enterprise systems must often be integrated into the system.

In other word, a PC packaged for industrial environments can provide many capabilities sought in modern applications, particularly those needed for the networking and data communication. Similar to augmenting a PLC to accomplish PC like tasks, however, an industrial PC that needs to perform PLC like tasks such as machine for process control. For instance, a PC may be using an operating system that is not optimized for high performance and deterministic industrial applications.

Conformity Level and Reusability Level of PLCopen

The broad range of application areas for IEC 61131-3 not all implementations use exactly the same data types. The certification according to Conformity Level (CL) implies that the PSE supplier selects the data types supported by his product matching his compliance statement. All supported IEC features are tested. This means that the test is a YES or No test, there can be differences between two certified products. These differences can influence the reusability of function blocks of user derived

The data types total number as specified in the Standard amounts to 26. These range from simple digital Yes/No to potential complex structures. Therefore, CL has 26 options, data type supported or not supported. Only the supported data types are used for testing.

Additionally Reusability Level (RL), is dedicated to making the programming units functions and function blocks reusable on a different PSE. This is done via exchange in a plain textual format of the language Structured Text (ST). A conversion tool to or from ST can be included for representation in other languages. This is a major, but natural contribution of PLCopen to the IEC 61131-3 standard.

Historically there exists a lower class which called Base Level, defining core kernel per language of the standard. It is feasible to develop applications based on it although rather restricted. Base level provides an entrance level for the suppliers, showing their commitment to the standard. It provides a normalized interpretation of the standard for the users, especially important if they have to work with systems of different vendors.

TC4 – Communications work on the relation between programming languages and communication, like the mapping of CANopen and Profibus.

TC5 – A safe software prepares recommendations for applying the standard of IEC 61131-3 to and adapting it for safety related applications, specially focused on new safety standard IEC 61411 and 61408.

TC6 – XML works on the specification schemes of XML for all languages as well as full projects.

PLCopen Enhancement of Standard

PLCopen is a product independent and vendor worldwide association supporting IEC 61131-3. By implementing the standard on many program development environments, user can move between different types and brands of control with very little training and exchange applications with a minimum effort.

The organization of PLCopen works on the promotion of the usage and/or supply of the standard as well as to enhance the standard in a technical sense. This latter includes exchange and certification. The members of the PLCopen can participate in the committees, and as such have upfront information, a stronger identity, as well as influence on the results. They can use the defined PLCopen logo’s for their promotion. The committees working within PLCopen and results are described in short form hereunder.

The technical committees (TCs) with PLCopen representative’s members work on specific items.
TC1 – Standards, PLCopen collects proposal from its member for the IEC 65B WG7 working group, develops a joint position and distributes related information. This was specifically focused to the second standard edition which was released at the beginning of 2001.

TC2 – Functions defines Function Blocks common libraries for specific application areas. For instance is the library definition of Function Blocks for Motion Control. This standardization of couple’s motion control in a logical way to industrial control. It provides a common look and feel towards the users, programmers as well as maintenance and installation people. Scaling of the control system is much easier with multiple implementations of this library, even if there are different architectures and/or controller brands used.

TC3 - Certification and Conformity testing defines a certification system for Program Support Environments (PSEs). Each PSe can be tested to show that it complies with a PLCopen specified subset of the standard of IEC 61131-3. This standard consists a large number of so called feature tables and PLCopen has defined which elements of these tables must be supported to fulfill compliancy requirements.

Implementations of Standard IEC 61131-3 Programming

The overall requirements of IEC 61131-3 are not easy to fulfill it. That’s why the standard allows partial implementations in various aspects. This covers the supported number of languages, functions and function blocks. This leaves freedom at the supplier side, but a user should be well aware of it during his selection process. A new release can have a dramatically higher level implementation.

Many current IEC programming environments offer everything you can expect form modern environments, pull down menus, mouse operation, graphical programming screens, support for multiple windows, built in hypertext functions, verification during design. Please be aware that is not specified within the standard itself, it is one of the parts where suppliers can differentiate.

The implications technical of the IEC 61131-3 standard are high, leaving enough room for differentiation and growth. This makes the standard suitable to evolve well into the next century. IEC 61131-3 will have a great impact on the whole industry of industrial control. It certainly will not restrict itself to the conventional of PLC market. Currently, one sees it adopted in the motion of control market, distributed systems and PLC/softlogic based control systems, including SCADA packages. And the areas are still growing.

Having a standard over such as a board application area, bring numerous benefits for users or programmers. The benefits for adopting this standard are various, based on the areas of application. Just to name a few for the mind setting:
• To reduce wasted in human resources such as in training, debugging, maintenance and consultancy.
• To create a focus to problem solving via a high level of software reusability.
• To reduce errors and misunderstandings.
• To program techniques usable in a broad environment, and general industrial control.
• To combine different components from different projects, locations, programs, companies and/or countries.

Function Blocks and Sequential Function Chart Program Organization

Function Blocks are equivalent to Integrated Circuits (ICs), representing a specialized control function. They consist data as well as the algorithm, so they can keep track of the past which is one of the differences of Functions. They have a well defined interface and hidden internals, like a black box or IC. In this way they give a clear separation between different levels of maintenance people, or programmers.

A temperature control loop, or PID, is an excellent sample of a Function Block. It can be used over and over again once defined in the same program, different programs, or even different projects. This makes them highly reusable. Function Blocks can be written in any of the IEC languages, and in the most cases using C language programming. They can be defined by the user. Derived Function Blocks are based on the standard defined FBs, but also completely new, customized FBs are possible within the standard. It just provides the framework.

With the above mentioned basic building blocks, we can say that a program is a network of Functions and Function Blocks. A program can be written in any of the defined programming languages.

Sequential Function Chart (SFC) describes graphically the sequential behavior of a control program. It is derived from Petri Nets and IEC 848 Grafcet, with the changes necessary to convert the representation from a documentation standard to a set of execution control elements.

SFC structures the program of internal organization, and helps to decompose a control problem into manageable parts, while maintaining the overview. SFC contains of steps, linked with Action Blocks and Transitions. Each step represents a state of particular of the system being controlled. A transition is associated with a condition, which, when true, causes the step before the transition to be deactivated, and the next step to activate. Steps are linked to action blocks, performing a certain control action. Each element can be programmed in any IEC languages, including SFC language.

SIMATIC WinCC Version 6.0 Innovation

One of the particular impressive things about SIMATIC WinCC right from the start was on the one hand the high level of innovativeness, which makes it possible to recognize coming trends at an early stage and to implement them; in other word, the long term product strategy based on standards guarantees your investment.

WinCC has advanced to become the industrial standard and market leader in Europe. WinCC is the choice when you want to run machinery and plant on an optimum basis that is to say to increase productivity and availability.

There is no question that you will always get the benefit even if you already using WinCC V5 and decide to use WinCC V6 with your new project or machinery. Because the process visualization of version V6 is offering better performance, more flexible and efficient for your application and the future proof capability that you are familiar with due to the use of new standard:
• Increased performance and performance profiles significantly at process data archiving due to the new archive system based on Microsoft SQL Server 2000.
• Long term data archiving integrated with high levels of data compression and integrated export function.
• Simple configuration of script runtime using VBscript.
• Individual customizing of the graphic designer through to configuration automation using Visual Basic for Applications
• The Report System has been innovated from the bottom up with greater openness and flexibility and easier configuration.
• Control and instrumentation technology options are integrated in the base system. • User friendly display technology with planning, decluttering, zooming.
• Web client can be deployed as equivalent operator stations, with integrated user management, access to user archives and a simple print function.
• Web server can be run on a WinCC client with access to the projects of all the lower level WinCC Servers.
• Easier validation according to FDA 21 CFR Part 11 for configuration.

The Role of PLCopen for Motion Control

Motion integration issues have emerged to the forefront, along with connectivity and maintainability to automation solutions. Unfortunately, the motion control market is a very fragmented market, providing a wide variety of incompatible systems or solutions. In practice this means that the software tools and the architecture for development, installation and maintenance will differ widely. This incompatibility incur costs consideration: applying different implementations is confusing, engineering becomes difficult, and the software is not reusable across platforms. Overall this means that there is too little standardization in the market. Standardization of flexible solutions which are open to new developments. It is not only meaning harmonizing the programming languages, like done within the worldwide IEC 61131-3 standard, but also the interface of software towards different motion control solutions, like distributed vs integrated. In this way the benefits of standardization software are:
• Less hardware dependence
• Transparent program
• Higher level of reusable code
• Lower commissioning, installation and maintenance costs
• Wide industry acceptance
• 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 PLCopen organization, and resulted in the definition of a PLCopen Motion Control library.

This standardization effectively is done by defining libraries of reusable components. In this way the programming is less hardware dependent, the reusability in support and training reduced, and the application becomes scalable across different levels of control. Such as it is based on IEC66131-3 Function Blocks, creating application programs which are understandable and reusable commonly across platforms. It is usable on different architectures due to the data hiding and encapsulation, like from centralized to distributed control. And it is open to existing and future technologies. This standardization is expected to cover around 80% of the market of motion control.

A Standard Programming Resource of IEC 61131-3

IEC 61131-3 is the first real endeavor to standardize industrial automation programming languages. It is independent of any single company with its worldwide support.

The entire software is required to solve a particular control problem can be formulated as a configuration at the highest level. A configuration is specific to a particular control system type, including the arrangement of the hardware, e.g. memory addresses for I/O channels, processing resources, and system capabilities.

A configuration can define one or more resources. One can look at a resource as a processing facility that is able to execute IEC programs. One or more Tasks can be defined within a resource. Tasks control the execution of a set of programs and/or Function Block. These can be either executed periodically or upon the occurrence of a specified trigger, such as the change of a variable.

Programs are built from a number of different software elements written in any of the IEC defined languages. Typically, a program contains of a network of Functions and Function Blocks, which are able to exchange the data. Function and Function Blocks are the basic of building blocks, containing an algorithm and a data structure.

If we compare this to a conventional PLC then this contains one resource, running one task, controlling one program, running in a closed loop. IEC 61131-3 adds much to this, making it open to the future. A future that includes event driven and multi-processing programs. And this future is not so far, just look at real time control systems or distributed systems. IEC 61131-3 is suitable for a broad applications range, without having to learn additional programming languages.

IEC has defined user defined functions and standard functions. Standard functions are for example ADD(ition), ABS(absolute), SINus, SQRT, and COSinus. User defined functions can be used over and over again.

S5/S7 OPC Server

The S5/S7 OPC server gives you fast and convenient access to process data in S7-200, S7-311, S7-411 and WinAC controllers, in C7 and M7 units as well as in Pilz, S5, Saia-Burgess or VIPA controllers. The variables are addressed consistently using STEP7 resp. STEP5 semantics. You can use any OPC compliant client application to write and read all input and output data, markers, data blocks, timers and counters in the controllers. Up to 256 controllers can be simultaneously accessed. The program PLC does not need to be modified for communication with the S5/S7 OPC Server.

Access the controller is available via Ethernet of Profibus, USB or via serial communication without or with a modem. CPs from various manufacturers, Netlink PRO and gateways from Softing are supported for Ethernet communication. Appreciation need to be given to the intelligent grouping of write and read requests, the data throughput is optimized so efficiently that Softing’s S5/S7 OPC Server won the best in class award in a practice related performance comparison of seven S7 OPC servers from renowned manufacturers.

The name of OPC space is extremely quick to configure by importing symbolic names from STEP7 projects or Excel files. Existing projects can be exported from software applications like process visualization systems or process control systems to Excel, and are then loaded conveniently into the S5/S7 OPC server.

The OPC server provides a web server for diagnostics and process data visualization. This allows you to display the PLC states and data very quickly on remote or local PCs by simply using any standard web browser. Powerful remote access without DCOM, the Softing OPC Tunnel has already been integrated in the S5/S7 OPC server for safe. Using the OPC Tunnel eliminates the problems associated with DCOM configuration security settings and saves significant time and costs. It only takes few minutes to setup communication for network applications.

Supporting a Process Flow of PAC

A key PACs defining of characteristic is that the same hardware can be used in multiple domains, including logic, drives, motion, and process control, it follows that the software must be capable of programming all control and monitoring tasks that must be done in multiple domains.

That means that the PAC software must handle discrete control, motion control, process control, remote monitoring, and data acquisition. And the software must let the developer incorporate and mix these as needed into control programs, so the programs can flow as the requirements of the application dictate.

For instance the company is a microbrewery. Here are just some of the requirements to produce your end product:
• Water is piped in from a spring a couple of miles away, so you need to monitor the flow and pressure of that water as well as security at the spring, remote monitoring using digital sand analog devices.
• You measure water quality as it enters your facility, track this data overtime, and store it in your company database, data base acquisition, and data base connectivity.
• You make more than one microbrew, so recipes, temperature and processing must vary (PID loop control, batch process control, and distributed control.
• Operator interfaces the process mimic, providing secure interactive controls for technicians and operators.
• Quality control is essential to your reputation, so you test all products at some stages. Quality must meet as required by government health authorities, monitoring, more database connectivity and data acquisition.
• The bottling line requires discrete control in another building. They identified with Radio Frequency Identification tags.

Hardware of XC600 PLC

The XC600 PLC has a modular design. The basic unit consisting of the base, power supply, CPU and operator modules can be expanded with function modules for communication. Modules for the standard PROFIBUS-DP and CANopen networks are therefore provided for this purpose. They provide the controller with access to the I/O devices that log process data signals and control actuators.

The process signals can also be connected locally with XI/ON Input And Output modules. This requires the use of the power supply module with the integrated XI/ON interface and the base module with the XI/ON adapter. A module consists of a circuit board that is embedded in a frame. The special frame design makes it possible to stack the modules together, thus allowing compact functional units to be combined to suit the requirements of the task at hand.

The circuit boards of the individual function modules meet the requirements of the PC/104+ specification. In addition to dimensions, the specifications also stipulate the requirements of the PC/104+ bus that connect the modules. This bus also carries the power supplies from the power supply module to the individual function modules.

A configuration containing XI/ON input/output modules must always include the XC-ADP-XION base module with theXC-POW50-XION-UPS power supply module. The power supply module adapts the PC/104+ bus to the XI/ON module bus using the XI/ON interface. This bus is connected out from the base module. The adapter on the base module provides the interface to the XI/ON modules. The 24 V DC field power supply of the XI/ON modules is also connected to the base module.

Control cabinet design
The arrangement of components in the control cabinet is an important factor in ensuring that system and machine functions are free of interference. During the planning and design stages, as well as during implementation, it must be ensured that the power and control sections are separated. The power section includes the following components:
• Contactors
• Coupling modules
• Transformers
• Frequency inverters
• Current converters

Dividing the control cabinet into to areas with different power and interference levels is recommended as an effective prevention against electromagnetic interference. In small control cabinets, this can often be provided sufficiently by using separators in order to reduce interference.

Ventilation
A minimum gap of 5 cm between passive components must be provided in order to ensure sufficient ventilation. If active components (e.g. load power supply, transformers) are fitted next to each other, a minimum gap of 7.5 cm must be ensured. Observe the values specified in the technical data.

Switching the power supply on/off
The UPS ensures that the XC600 controller is switched off properly in the event of a power supply failure. This requires the inputs/ outputs of the UPS device and the other devices to be wired. If the supply voltage to the UPS device drops, the controller is supplied with the battery supply voltage. The contact ”C1” in the UPS device opens and the circuit at the Power Fail input of the power supply module is interrupted. This will cause the controller to initiate the PFI signal, which will cause the system to shut down. The controller requires around two minutes doing this.

By connecting the Battery off input of the UPS to contact C2, the UPS device can switch off the battery supply voltage after two minutes. The battery is then used only for these two minutes so that further battery backup protection is ensured occur. If power is restored after two minutes, the controller will start up again according to how the operating mode selector switch is set.

A different routine is followed if the power supply to the UPS returns within two minutes: while the power to the UPS device has failed, the controller is at first initially supplied by the battery voltage until power is restored. As the UPS device signals the power failure to the controller (Power Fail input), the controller starts a system shutdown (2 minutes). The following message will be shown on the display: ”PFI shut down in progress”. The operation ends with the message”TURN OFF YOUR CONTROLLER” on the display.

Single Development Platform of PAC

PACs (Programmable Automation Controllers) meet the complex demands of modern industrial automation applications because they combine features of more traditional automation technologies: Distributed Control Systems (DCs), Programmable Logic Controllers (PLCs), Remote Terminal Units (RTUs), and Personal Computers (PCs).

The software built for a PAC is not just integrated with the hardware. It’s also integrated internally: it provides not only an integrated development environment (IDE) for programming but also suite of related programs such as human machine interface (HMI) development.

The IDE is a single software program which handles everything related to control programming, such as compiling, editing, and debugging. A software suite, made up of two or more software applications, offers a similar feel and look in all of them, so that familiarity with one helps you use the others more easily.

The software application in the suite is together work behind the scenes in ways that significantly reduce development time. Common tagging means that definitions and names you setup in one of the suite applications are also used in the others. For instance, if you desire a string variable in the control development software, that same definition will be used in the HMI development software. If you name a digital I/O point in the control software, that name will appear automatically when you are configuring OPC data communications.

According to the ARC Advisory group, usually credited with coining to the term PAC, among a PAC’s defining characteristics are three elements related to software:
• Tightly integrated controller hardware and software. The software that is used with a programmable automation controller is designed specifically for the PAC.
• A single development platform, using a single database and common tagging for tasks development across a disciplines range.
• Programmability using software tools which capable of designing control programs to support process flows across several units or machines.