Communication Choices of MicroLogix 1500 Programmable Controllers

All MicroLogix 1500 programmable controllers provide some communication options to fit into a variety of applications. The second full-function RS-232 communications port addition is enable two communication devices to be connected to the controller simultaneously such as ASCII device, operator interface device, modem or programming device.

The DF1 Full-Duplex protocol allows the MicroLogix 1500 to communicate directly with another device, such as a personal computer or an operator interface device. The protocol of DF1 Full-Duplex (also referred to as DF1 point-to-point protocol) is useful where the RS-232 point-to-point communication is required. The multi-drop of DH485 communication capability allows you to network up to the 32 MicroLogix or SLC 500 Controllers, Human Machine Interface (HMI) devices and/or the personal computers using peer-to-peer messaging.

And, the MicroLogix 1500 can communicate on a DeviceNet network as well. DeviceNet digitally links push buttons, sensors, actuators, PLCs and other industrial devices on an open network. MicroLogix 1500 controllers also support the DF1 Half-Duplex Slave communications for use in SCADA systems as a Remote Terminal Unit (RTU). This open network protocol is enable MicroLogix controllers to communicate as responder (slave) nodes on DF1 master/slave networks. DF1 supports up to 254 responder devices with a single master. Additionally, the MicroLogix 1500 supports the Modbus Slave, a SCADA/RTU protocol.

Features:
• One RS-232 port (available on all base units)
• Additional RS-232 port
• 300, 600, 1200, 4800, 9600, 19,200, and 38,400 baud rates
• RTS/CTS Hardware handshake signals – the channel 0
• RTS/CTS/DCD Hardware handshake signals – the channel 1
• Connection to DH485 and DeviceNet networks through the 1761-NET-AIC and 1761-NET-DNI, respectively
• Connection to the modems for remote communications
• ASCII messaging provides dial-out capability
The MicroLogix 1500 allows you to choose the network that best meets your needs.

Micrologix 1500 PLC Expansion I/O Modules

The Compact I/O of High-density Bulletin 1769 rackless expansion modules offer superior functionality and high value at a competitive price. With a variety of modules, they complement and extend the capabilities of the MicroLogix 1500 controller by maximizing flexibility of the I/O count and type. (Up to eight expansion Compact I/O modules can be connected to a MicroLogix 1500 controller.) Compact I/O provides an excellent platform for future enhancements, so you can easily choose the level of control as your application needs grow.

Compact I/O’s analog modules provide 14-bit plus sign maximum resolution, making them an excellent choice in applications where the need to detect small changes in the analog input is vital. Similarly, Compact I/O analog modules can be used in applications where accuracy is crucial. The modules share a high accuracy rating of ±0.35% of full-scale accuracy in the current mode. In the voltage mode, the 1769-IF4 provides ±0.2 and the 1769-OF2 ±0.5% of full-scale accuracy at 25°C.

Features:
• Modular system, allowing mixing modules to suit the application
• Feature-rich I/O functionality to address a wide range of applications
• Rackless design is eliminating added system costs and inventory
• Small footprint, shrinking panel space requirements
• Front insertion and removal, reducing assembly and replacement time
• Unique tongue-and-groove interlocking case design, ensuring a strong, mechanical connection between modules
• Integral high-performance I/O bus
• Software keying, preventing incorrect positioning within the system
• Analog I/O, AC/DC relay, 24V dc, and 120/240V ac voltages

Currently available modules include:
1769-IA16 16-point 120V AC Input Module
1769-IA8I 8-point Isolated 120V AC Input Module Individually
1769-OA8 8-point 120/240V AC Output Module
1769-IM12 12-point 240V AC Input Module
1769-IQ16 16-point 24V DC Sinking/Sourcing Input Module
1769-OB16 16-point 24V DC Sourcing Output Module
1769-OV16 16-point 24V DC Sinking Output Module
1769-OW8 8-point AC/DC Relay Output Module
1769-OW8I 8-point Isolated AC/DC Relay Output Module Individually
1769-IQ6XOW4 Combination 6-point dc Input and 4-point Relay Output Module
1769-IF4 4-channel analog current/voltage Input Module
1769-OF2 2-channel analog current/voltage Output Module

Allen Bradley PLC MicroLogix 1500 System

The MicroLogix 1500 is a completely new packaged controller platform with world-class features and performance. Many of these new features allow this packaged controller to be used in applications where much larger controllers were required in the past.

The MicroLogix 1500 controller features an innovative two-piece design with a small footprint. The processor and base slide together form the complete controller unit. The processor is independently replaceable from the base, allowing you to maximize your embedded I/O options while minimizing inventory stocking costs. An independently replaceable processor unit also means replacements can be made without disturbing existing wire connections. The MicroLogix 1500 uses Compact ™ I/O, a high-performance modular and rackless design that provides front access, removal and insertion for lower system cost and reduced parts inventory. And, the MicroLogix 1500 system also utilizes Rockwell Software RSLogix 500 ™ programming software and features a common instruction set to the MicroLogix 1000, MicroLogix 1200 and SLC families of controllers.

A flash upgradeable operating system makes it easy to upgrade operating systems without having to replace PLC hardware. Program portability allows user programs to be uploaded, downloaded and transported via Memory Modules. The RTC (Real-Time Clock) capabilities allow time scheduling of control.

The optional Data Access Tool (DAT) plug-in device offers you the ability to digitally monitor and adjust 48 integer and 48 bit locations. Two additional MicroLogix 1500 MicroLogix 1500 System The MicroLogix 1500 is a completely new packaged controller platform with world-class features and performance. Many of these new features allow this packaged controller to be used in applications where much larger controllers were required in the past. The MicroLogix 1500 controller features an innovative two-piece design with a small footprint. The processor and base slide together to form the complete controller unit. The processor is independently replaceable from the base, allowing you to maximize your embedded I/O options while minimizing inventory stocking costs. An independently replaceable processor unit also means replacements can be made without disturbing existing wire connections.

The MicroLogix 1500 uses Compact ™ I/O, a high-performance modular and rackless design that rovides front access, removal and insertion for lower system cost and reduced parts inventory. And, the MicroLogix 1500 system also utilizes Rockwell Software RSLogix 500 ™ programming software and features a common instruction set to the MicroLogix 1000, MicroLogix 1200 and SLC families of controllers.

Lock Unlock Door For Home Automation

Simulation Lock Unlock Door For Home Automation


Simulation Lock Unlock Door


Download all the Simulation, Click : Lock Unlock Door


Detail for Home Automation
Detail for Lock Unlock Door
Information on Numbers for Detail the Lock Unlock Door For Home Automation :
1. KeyPad with 10 Numeric and 1 Enter (Numeric KeyPad)
2. Lock Indicator using Green LED (Light Emitting Diode)
3. Electromagetic Lock using DC Source
4. Door closure Sensor
5. Door Exit Button
6. PLC (Programmable Logic Controller)
7. Relay With Relay Coil using 240 Volt AC Source
8. Battrey
9. Automatic Battery Charger

For wiring Numeric KeyPad, click : Password PLC

Relay Diagram for Lock Unlock Door Note: For PLC Output using PLC Output Units Relay

Number Of Inputs and Output PLC applied :
1. Number Of Inputs PLC is 13 Input :
--- 11 Unit Input from Numeric KeyPad
--- 1 Unit Input from Door closure Sensor
--- 1 Unit Input from Door Exit Button
--- Total Number Of Inputs PLC is Minimum 13 Input Unit.

2. Number Of Output PLC is 1 Output :
--- 1 Unit Output to Relay Coil (Used for Electromagetic Lock and Green LED)
--- Total Number Of Outputs PLC is Minimum 1 Output Unit.


Sequence PLC Programming for Lock Unlock Door :

1. Keypad and Password
For workings of keypad and password,
click : Password PLC

OUTDOOR
2. Correct Password (Password OK) and Wrong Password
Unlock Door
a. If Password OK then Relay Coil = ON ( Electromagetic Lock = OFF AND Green LED = OFF ).
Lock Door
b. If Wrong Password then Relay Coil = OFF ( Electromagetic Lock = ON AND Green LED = ON ).

3. Open Door
Unlock Door
a. If Relay Coil = ON Then Door can be opened.

4. Lock Door by Door position
a. If Door position from OPEN to CLOSED AND Door Closure Sensor = ON Then Relay Coil = OFF ( Electromagetic Lock = ON ).
b. If Relay Coil = ON AND Door Closure Sensor = ON Then Activate the Timer for 30 seconds.
c. If Timer = ON Then Relay Coil = OFF ( Electromagetic Lock = ON ).

INDOOR
5. Exit with Door Exit Button
a. If Door Exit Button = ON Then Relay Coil = ON ( Electromagetic Lock = OFF AND Green LED = OFF ).

Can You make Program Ladder PLC ?

If Can't :

Lock Unlock Door Using Siemens PLC

Lock Unlock Door Using Allen Bradley PLC

Lock Unlock Door Using Omron PLC

Lock Unlock Door Using Mitsubishi PLC

Lock Unlock Door Using Keyence PLC

Other PLC

MicroLogix 1500 Controller of Allen Bradley PLC

Since 1903, Rockwell Automation’s Allen-Bradley has earned a worldwide reputation as the most trusted brand name in industrial automation. It’s a reputation built on a very simple strategy: providing customers with products of uncompromising quality and reliability. The MicroLogix 1500 family of controllers demonstrates that commitment to high standards of product dependability, technological innovation, and performance.
More importantly, because your absolute satisfaction is important to us, we back our products with the highest levels of customer service and support in the industry. Your local Rockwell Automation representative is your source for expert sales and order support, as well as:
• Product technical training
• Warranty support
• Service agreements

MicroLogix 1500 Controllers:
Expanding Your Choices for Greater Control, There was a time when a large controller was needed for applications requiring 100 or more points of I/O. Not any more. The MicroLogix 1500 is a more powerful and expandable addition to the MicroLogix family. This controller of dynamic packaged can handle many applications that used to require larger, more expensive controllers.

World Class Features for Many Applications
The MicroLogix 1500 has more robust features than you might expect complex application programs. For a controller this Additionally, the controller’s size. It supports terminal blocks are removable, more than 7K “finger safe” NEMA-style of onboard blocks. And because it can non-volatile user be either DIN rail or panel memory to mounted, the MicroLogix 1500 accommodate takes up a fraction of the space.
Half-Duplex Slave is perfect for SCADA applications. Ethernet® and ControlNet™ connectivity is available via a wide range of bridge products.
Finally, as with all MicroLogix controllers, the MicroLogix 1500 is programmed using the RSLogix 500™ programming environment. The instruction set is compatible with all MicroLogix as well as SLC ontrollers.

High-Speed Performance
As many large manufacturing applications occur at a fast pace, the MicroLogix 1500 is built for speed, for of larger controllers while reducing overall application costs.

Selecting IO Modules of PLC-5/40L and PLC-5/60L

Use the extended-local I/O link when you need I/O updates more quickly than is possible from remote I/O link. A local I/O link offers faster update time and scan than a remote I/O link. The extended-local I/O link is limited to 30.5 cable-m (100 cable-ft). The distance between controller and chassis of I/O can not be put more than 30.5 m, otherwise you have to use an I/O link remote.

The controller of PLC-5/40L or PLC-5/60L and the local adapter of I/O module for 1771-ALX create the extended local I/O link. You can delete a module adapter from a chassis on the local I/O link because of the cabling design without disturbing communication to other chassis on the extended-local I/O link.

Selecting I/O Modules

Select I/O modules to interface your PLC-5 controller with machines or processes that you choose while analyzing the operation of your plant. Use the following list and table as guidelines for selecting I/O modules and operator control interfaces.
• How much I/O is required to control your processes?
• Where will you concern to I/O points for portions of an entire process
• When the process is spread out over a large physical area?
• What type of I/O is required to control your processes?
• What is the required voltage range for each I/O module?
• What is the backplane of current required for each I/O module?
• What are the distance and noise limitations for each I/O module?
• What isolation is required for each I/O module?

Guidelines for Selecting I/O Modules

Choose this Type of I/O Module: Discrete input module and block I/O module
Types of Field Devices or Operations: Many kinds of selector and contact switches, and also relay and breakers.
Explanation: Modules sense input opened/closed or on/off signals. The signals of discrete involve ac or dc.

Choose this Type of I/O Module: Discrete output module and block I/O module
Types of Field Devices or Operations: lights, alarms, horns, fans, valves, control relays, solenoids or motor starter.
Explanation: signals module output of interface with opened/closed or on/off devices. The signals of discrete involve ac or dc.

Choose this Type of I/O Module: Analog Input module
Types of Field Devices or Operations: Many kinds of transducers.
Explanation: Change the signals analog to the input values of PLC controller.

Choose this Type of I/O Module: Analog Output module
Types of Field Devices or Operations: actuators, chart recorders, analog meters, motor drives, valves.
Explanation: Interpret PLC controller output to analog signals for field devices.

Choose this Type of I/O Module: Specialty I/O modules
Types of Field Devices or Operations: EMany kinds of encoders for communication, tag readers, weigh scales, bar-code readers, display devices.
Explanation: Are generally used for specific applications such as position control, PID, and external device communication.

Selecting I/O Module Density
The density of an I/O module is the number of controller input or output image-table bits to which it corresponds.

Use these guidelines for selecting I/O module density:
I/O module 8-point
• Presently it is using 8-point modules
• It requires integral, fused outputs separately
• cost down per module

I/O module 16-point
• Presently it is using 16-point modules
• It requires a special wiring arm of outputs fused separately

I/O module 32-point
• Presently it is using 32-point modules
• minimize modules number
• minimize the chassis I/O space requirement
• cost down per I/O point
Place I/O modules in a chassis depending on the electrical characteristics of the module. The placement is made left to right, with the left-most position being closest in the chassis to the PLC-5 controller or the I/O adapter module.

General information of SPC Component

• The SPC component is a PLC (Programmable Logical Control), which can be integrated in any PC.
• The PLC communicates with higher-level host PC via a dual-ported RAM. In this dual-ported RAM, the process image is provided.
• One of the two serial interfaces of the SPC is used for programming the PLC. This offers the possibility to program the PLC not only with the host PC, but also by means of an external laptop or a Siemens programmer. The AS511 (optionally an IBH Softec protocol as well) is used as a protocol at the serial interface.
• The PLC disposes of the capacity range of a SIEMENS 945 CPU, regarding the command set.

The SPC consists of several components
A base board containing the following components.
a. 8 KB dual-ported RAM for communication with the ISA bus
b. Two PC-104 slots
c. Plug for two serial interfaces
d. Integrated lightbus connection
e. Integrated CAN bus connection
f. Interface to an NPS power supply unit
g. Parallel interface for offset switches and display
h. 7 segment displays for displaying the status
i. Switch for Run/Stop
j. Switch for normal/special operation
k. Key for Reset
l. Key for Load
m. 4 MB FLASH EPROM
n. Optionally up to 1 MB SRAM

A PC (IBM-compatible) which is plugged in either of the two PC-104 slots and which contains the following components.
a. CPU 586 / 133 MHz
b. 4 MB RAM (extensible)
c. 800 KB Flash Eprom as drive "C:"
d. 4 MB Flash Eprom as drive "D:" (extensible)
e. Two serial interfaces COM 1 and COM 2
f. One parallel interface
g. Connection for floppy drive
h. Connection for keyboard

A second PC-104 slot which can be used for expansion boards.
a. Profibus DP connection
b. Interbus-S connection
c. CAN bus connection (unless the integrated one is used)
d. Any other boards such as VGA controller, etc.

Next Generation CX-Programmer Ver. 4.0

Programming, Debugging and Maintaining of Omron PLCs
CX-Programmer version 4.0 leverages the latest improvements in Omron CS/CJ series PLCs. Only a few of the important changes are shown below. A full list of improvements is in “CX-Programmer Ver.4.0 Version Upgrade Information” available on Omron’s. This high performance, 32-bit Microsoft Windows-based software program continues to simplify PLC program development, network commissioning and system diagnostics.
Key Features and Benefits
a. Easier Team Program Development
Enhanced task programming features
b. Develop and download individual tasks
c. Check for duplicate addresses between tasks
d. Allows for separate comment files per task
e. Intellectual Property Protection & Security
Protect programs from being changed
Protect programs from being copied
Write protection mode for “Monitor-only” to prevent data from being overwritten
f. Expanded Networking
“Auto” on-line connections with the PLC from Ethernet
Now supporting up to eight layers of networking
Supports the new 100Base-TX Ethernet Modules: CS1W-ETN21 and CJ1W-ETN21
Supports the new Controller Link hardware: CS1W-CLK21-V1, CJ1W-CLK21-V1, 3G87F-CLK21-V1, and CS1W-RPT01. Increases number of available CLK nodes to 62.
g. New Hardware Support
CJ1M-CPU11 and CJ1M-CPU21
h. Easier Connections to CX-Simulator
Now directly launch CX-Simulator from icon on CX-Programmer toolbar.
Take advantage of all CX-Simulator’s testing/debugging features.
CX-Simulator is sold separately

Selling Strategies
CX-Programmer v4.0 is a significant enhancement to v3.2. The enhancements are highlighted in the Key Features and Benefits section of this document, and a detailed list of all changes is available on the Omron website. Other things that should be considered are:
a. CX-Programmer is the foundation of the CX-Automation Suite of software tools that include an OPC Server (CX-ServerOPC), an activeX interface (CX-ServerLite), a PC-based HMI (CX-Supervisor), along with motion control configuration and protocol communication programming software tools.
b. SYSWIN applications will no longer be revised; therefore, it is in the best interest of your customers to migrate to CX-Programmer.
c. Version 4.0 offers direct import for SYSWIN programs and new improved utilities for converting Omron’s previous PLC programming software tools. CX-Programmer objective is for the IEC 61131-3 specification compliance with the release of Function Block, Structured, and Sequential Function Chart (SFC) support occurring within a 1-11/2 year time period.

Creating and Editing a Program of Logicmaster 90-70 Software

“Program Editing,” describes how to create and edit programs. The basic elements of a program are displayed when the programming screen is first selected. Editing functions include rung insert/edit, select, cut, delete, paste, include, and write. In addition, search and go to functions allow you to position the cursor on a particular rung or element. An optional feature of the search function is the replacement of the search target with a user-specified element and/or reference address. “Program Annotation,” describes how annotation can be added to a program to make the program easier to read and understand. Three types of annotation (nicknames, reference descriptions, and rung comments) are supported by Logicmaster 90-70 software.

Displaying Tables of Reference Values
“Reference Tables,” explains how to use the reference tables feature to display the current values of program references. If the programmer is connected to a PLC and in ONLINE or MONITOR mode, the values shown in the table are from the PLC. In OFFLINE mode, they are from the current folder. There are separate tables for each type of program reference; for example, all discrete inputs (%I), all discrete outputs (%Q), and all registers (%R). In addition, there are 99 user-defined tables called mixed reference tables. The format of individual items or an entire reference table can easily be changed to units that are suitable to your application. You can also return a standard reference table to its default format and fill the table locations with zero.

Starting/Stopping PLC Execution
PLC program execution is started or stopped from the Run/Stop PLC screen, or by pressing ALT-R from any screen.

Fault Display and Clearing
When the programmer computer is monitoring an operating PLC system, any faults that have occurred are displayed in one of two fault tables. PLC faults are listed in the PLC fault table. Faults from the I/O system are listed in the I/O fault table. All faults are identified by time, date, and location. Additional information about each fault can be displayed by positioning the cursor on the fault in the fault table and pressing the Zoom (F10) softkey. Faults can be cleared from the fault table displays.

Logicmaster CPU Configuration

Configuration software is used to display and modify the characteristics of the CPU (such as the time-of-day clock, SNP ID, memory configuration, and fault category). “CPU Configuration,” explains how to complete the CPU configuration for your system. This will set up or change the system features described below.

PLC Time and Date
The PLC maintains the current time and date. These settings can be displayed and changed using the CPU configuration function.

SNP ID
For multidrop configurations, each CPU connected to the system must have a unique identification name. The current SNP ID can be displayed and changed using the CPU configuration function.

PLC Memory Configuration
You can show the recently memory allocated to both discrete references and register references. In addition, you can change the amount of program logic memory used for analog I/O and register memory.

System Response to Faults
To ensure safe operation of the Control System, the PLC must be able to respond appropriately to certain types of faults. Fatal faults cause the CPU to set fault references and then go to STOP mode. Diagnostic faults cause the CPU to set fault references, but the PLC keeps operating. For many faults, the default action (fatal or diagnostic) can be configured to suit the needs of the application.

I/O Configuration
The I/O configuration function is used to describe the modules that are present in the PLC racks, to assign logical addresses, and select options for individual modules. These addresses of logical are independent of physical location or function. “I/O Configuration,” explains how to complete the I/O configuration for your system.

The I/O configuration rack screen represents the appearance of the Series 90-70 I/O rack. Use the Next and Previous page keys, or the Up and Down cursor keys, to display another rack. Then, use the Right and Left cursor keys to move the cursor to the slot to be displayed or configured. To complete the I/O configuration:
1. Select the module present in each slot.
2. Assign each module a reference address. The configuration software automatically supplies the next highest reference address for each module; however, you can change this address.
3. For some modules, you can also select options, such as the configuration mode for a Programmable Coprocessor Module. Editing features make it easy to copy, move, replace, delete, or undelete configurations.

Requirement to Run Logicmaster 90-70

Logicmaster 90-70 programming software is used to configure and program the Series 90-70 programmable controller. Configuration is the process of assigning logical addresses, as well as other characteristics, to the hardware modules in the system. It may be done either before or after programming, using the configuration software; however, it is recommended that configuration be done first.

Programming consists of creating an application program for a PLC.
What You Will Need
To run Logicmaster 90-70 software, you will need:
• A computer with a hard disk:
• A Workmaster II industrial computer with a 101-key keyboard, or
• A personal computer with an Intel 80386 or higher processor and a minimum of 2 Megabytes of memory, or
• A Zenith_ Mastersport_ SL notebook computer or other laptop computers with an Intel 80386 or higher processor and a minimum of 2 Megabytes of memory.
• At least 4 Megabytes of free disk space.
• The Release 5 WSI version of Logicmaster 90-70 software requires a minimum of 545K of available conventional RAM memory to run and at least 1024K of Lotus/Intel/Microsoft Expanded Memory (LIM EMS 3.2 or higher).
• The standard serial communications version of Logicmaster 90-70 software requires either a minimum of 590K of available conventional RAM, or 545K of available conventional RAM plus an additional 49K of Upper Memory Blocks (UMB), High Memory Area, or Expanded Memory (EMS) for the communications driver. At least 1024K of Lotus/Intel/Microsoft Expanded Memory (LIM EMS 3.2 or higher) is also required.

Some folders may require additional memory. If additional memory is required, system software error ID: 0000 EX: 0000 will be displayed. Check the AUTOEXEC.BAT and CONFIG.SYS files to remove any device drivers and Terminate and Stay Resident (TSR) programs in order to free more RAM. Logicmaster 90-70 software does not require the ANSI.SYS device driver.

The Features of Logicmaster 90-70

The following features are available only with CIMPLICITY Control:
• Ethernet Global Data: This feature allows a PLC CPU’s memory (PLC memory) to be shared with the other PLCs and HMI devices on an Ethernet network. It also allows the PLC to collect data from other PLCs on a periodic basis.
• Increased Program Size: Using a Release 7.2 or later 90-70 PLC, you can store larger LD or SFC programs than previously to Series 90-70 PLC CPUs with expansion memory boards larger than 512 kilobytes.
• I/O Scan Sets: The I/O Scan Set feature allows the scanning of I/O points to be more closely scheduled with its use in user logic programs. This feature removes the need to scan all I/O on every sweep, thus reducing sweep time and increasing throughput. FIP, IC660/661, and Release 7.2 or later Series 90-70 I/O points can be assigned to groups called Scan Sets.
• Selective Synchronous FIP Programs: This feature allows the execution of a user program to be synchronized with the scanning of a scan set, where at least one input variable in the set is assigned to a FIP Bus Controller (FBC).
• VME 3rd Party Interrupts: The Release 7.2 or later Series 90-70 PLC currently allows interrupts from discrete and analog modules to trigger LD interrupt blocks and Standalone C programs in the PLC. Release 7.20 of the Series 90-70 PLC extends this capability to include interrupts from 3rd Party VME modules. Please refer to GFK-0448E, the User’s Guide to Integration of 3rd Party VME Modules for more details on VME 3rd Party interrupts.
• Name Resolution Files: Release 7.20 of the Series 90-70 PLC supports the storing of Name Resolution Files from Windows programming software to Network Adapters capable of Name Resolution. Naming Resolution involves resolving a symbolic name to its necessary address information required for communication. This feature provides users with a means to use a Symbolic Name to reach the remote destination.
• Store/Load/Verify Genius Block Configuration: PLC Release 7.20 supports the storing of Genius Device Configuration. Windows programming software Release 2.00 or later is required to configure the devices. The configuration is stored to the PLC, and is then passed on to the GBC/NBC for eventual storage in the Genius devices. In addition, load/verify of device configuration will be supported.

Applying the PAC to a Modern Industrial Application

Let’s look more closely at how a PAC is applied to a modern industrial application, using the factory application.
Single Platform Operating in Multiple Domains
The single PAC is operating in multiple domains to monitor and manage a production line, a test bench, a chemical process, and shipping activities. To do so, the PAC must simultaneously manage analog values such as digital on/off states for valves, temperatures and pressures; switches, and indicators; and serial data from inventory tracking and test equipments the PAC is exchanging data with an OPC (OLE for Process Control) server, an operator interface, and a SQL (Structured Query Language) database. Simultaneously handling these tasks without need for additional processors, middleware, or gateways is a hallmark of a PAC at the same time.

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

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

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

PLC Code for Automatic Translation

A prototype automatic translation utility was developed and demonstrated. The translation capabilities of the utility will be expanded upon as more and more translation points are identified, translated manually, and then turned into additional PLC code libraries. The simplified process flow for translating a single “send_command” line from tabular spec to PLC code. The spreadsheet that contains the application software in tabular spec format is exported to plain text and is used as input to the translation utility, along with the PLC code library. The translation utility processes these input files, using program transformation steps. This creates an output file that can be imported by the PLC coding IDE.

This work successfully demonstrated that a process and a software tool can generate executable PLC code from a high-level specification representation of a safety-critical control system. This process includes some manual work to find translation points and to create PLC code libraries, but that up-front and one-time manual effort is overshadowed in the end by the automatic generation of repetitious and tedious functionality that would be difficult and error-prone to perform manually and tool increase the quality, reliability, maintainability, and verification/validation pedigree of the PLC code over code that is generated manually. It also provides a high level of PLC Code consistency and could even reduce operations and maintenance costs for the control system after it is deployed.

Follow-on phases of development of the automatic translation utility should include most, if not all, of the following tasks:
• Represent as much LCS application software in the tabular spec format as possible without overcomplicating the tabular spec format,
• Manually implement the remaining translation points and any newly discovered translation points, along with the matching PLC code libraries,
• Add code to the translation utility to recognize and handle the new translation points, along with the new PLC code libraries, and
• Test and certify the translation utility for automatic generation of safety-critical PLC control logic in the LCS at KSC.

Safety-Critical PLC Code

The benefits of automatic-application code generation are widely accepted within the software engineering community. These benefits include raised abstraction level of application programming, shorter product development time, lower maintenance costs, and increased code quality and consistency. Surprisingly, code generation concepts have not yet found wide acceptance and use in the field of programmable logic controller (PLC) software development. Software engineers at Kennedy Space Center recognized the need for PLC code generation while developing the new ground checkout and launch processing system, called the Launch Control System (LCS). Engineers developed a process and a prototype software tool that automatically translates a high-level representation or specification of application software into ladder logic that executes on a PLC.

All the computer hardware in the LCS is planned to be commercial off the shelf (COTS), including industrial controllers or PLCs that are connected to the sensors and end items out in the field. Most of the software in LCS is also planned to be COTS, with only small adapter software modules that must be developed in order to interface between the various COTS software products. A domain-specific language (DSL) is a programming language designed to perform tasks and to solve problems in a particular domain, such as ground processing of launch vehicles. The LCS engineers created a DSL for developing test sequences of ground checkout and launch operations of future launch vehicle and spacecraft elements, and they are developing a tabular specification format that uses the DSL keywords and functions familiar to the ground and flight system users. The tabular specification format, or tabular spec, allows most ground and flight system users to document how the application software is intended to function and requires little or no software programming knowledge or experience.

The LCS developers needed a mechanism or tool to translate application software from tabular spec format into PLC Code to execute on the PLC platforms out in the field. The functionality of some representative samples of tabular spec was manually coded into PLC ladder logic and tested with a field item simulator to verify the proper operation of the manually coded ladder logic. This manual process of conversion or translation from tabular spec representation to PLC ladder logic demonstrated that translation points or patterns existed between portions of the tabular spec and portions of the PLC ladder logic.

Meet the Modern Industrial Application

A modern industrial application implementation 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 increasingly demanded in a modern industrial application.

These modern requirements extend far of the traditional discrete-logic-based control of input/output (I/O) signals handled by a PLC (programmable logic controller). Most PLCs are programmed using ladder logic, which has its origins in the wiring diagram used to describe the connections and layout of discrete physical relays and timers 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—and separately programmed— hardware cards to perform these calculations.

Making a PLC More Like a PC
Using a PLC to meet modern application requirements for device interoperability, network connectivity, and enterprise data integration presents other challenges. These tasks types are usually more suited to the capabilities of a computer (PC). Additional processors, converters or network gateways, “middleware” software running on a separate PC, and special software for enterprise systems must often be integrated into the system to provide these capabilities in a PLC-based application.

Making a PC More Like a PLC
An industrial environments PC packaged can provide many of the capabilities sought in modern applications, particularly those needed for data communication and networking. Similar to augmenting a PLC to accomplish PC-like tasks, however, an industrial PC that requires performing PLC-like tasks, such as process control or machine, also requires expansion. For instance, a PC may be using an operating system that is not optimized for deterministic industrial and high-performance applications. Additional I/O special extensions or expansion cards may need to be integrated into the PC’s operating system to provide the high-performance, deterministic or near-deterministic operation.

DCS based Industrial Automation

A DCS is a system of controllers linked by a data network, as a single system in traditional industries. Functionality and physical location, or both separate these controllers. Typically the DCS is used in complex process applications where large amounts of I/O and data are required, such as oil refineries or chemical plants. They are well suited to batch processes and have an ability to handle complex timing and interlocks between operations. DCS are multitasking systems able to handle great common databases. A DCS is able for various control loops, using graphical representation of function blocks, and is easier to program than ladder logic-based PLCs. Scan rates can be more predictable than the PLCs. PLCs have scan rates dependent on the amount of I/O.

A DCS has redundancy, safety features, and even diagnostics built into its control philosophy to be more robust with less down time. The current system has the integrated system of hardware and software reduces engineering time, process simulation and advanced control applications are available and it can be designed for ease of future expansions.

Automation control can be applied to small or large processing plant such as chemical plants, waste water purifying plants, power plants etc in modern industries. Vehicle Spare Parts Manufacturing Plant is one of the manufacturing processes. The goal of this system is to produce qualified spare parts of automobile. Other processes are ignored.
Software Components of DCS
The same software types of components should be used for all the different DCS partitions. They are the following:
• A distributed SCADA or Supervisory Control And Data Acquisition system
• Control applications using the supervisory control and data acquisition tools
• Interfaces to the front-end
• Interfaces to the external systems
• Non- supervisory control and data acquisition front-end control applications

The overall process is used to control by Supervisory Control and Data Acquisition system and Front End System such as Distributed Control System (DCS), in the vehicle spare parts manufacturing plant . It can control in various control system. But most of modern industries use DCS system because of reliability and security of the system. DCS system includes master station including server and client computers.

DCS and PLC Application in Turbine Automation

Turbine automation is a specialized segment within the automation business that is still not dominated by mainline DCS or PLC systems, but remains the domain of more specialized systems. This situation persists for both business and technical reasons. Turbine OEMs prioritize new turbine business over automation system retrofits from the business standpoint. Yet because turbines last lounge than automation systems, older machines inevitably need replacement automation systems sometime during their operating life.

When the time comes to retrofit, turbine owners must decide if they will restrict their supplier choice to just the turbine OEM or will accept systems and services from other providers. They must give priority to selecting high-reliability equipment, high-performance, and a service organization with an excellent track record and deep expertise in this very specialized application, if they consider other suppliers. This ARC Brief discusses the experiences of cogeneration plant and a major energy services provider working with RTP Corporation’s automation equipment in demanding turbine control applications.

Medium and large turbines have been a niche application for automation, one that is not suited perfectly for either DCS or PLC-based automation systems. Most large turbines are still controlled by specialized automation systems designed specifically for turbo-machinery control, instead of general-purpose DCS or PLC systems. The DCS and PLC power system has mushroomed in the years since they were introduced. Why have they had trouble penetrating into automation of turbo-machinery?

There are a number of good reasons. First of all, turbine control is a quite specialized application that requires special components. For instance turbine speed sensors are often redundant, magnetic speed sensor inputs used for both speed control and over speed protection. In addition to more conventional sensors, turbine automation systems must interface with flame scanners, vibration sensors, and linear variable differential transformers (LVDTs), as well as magnetic speed pickups, all of which must be scanned rapidly.

Single Database Functionality and Powerful Software Tools of PAC

The significant differences between PLCs and PACs are the way they handle input/output functions. PLCs constantly scan all the I/O in their systems continuously at a very high scan rate. While this enables very fast I/O response, it also limits the number of I/O points a PLC system can handle. PACs use a logical address system and a single tag name database very similar to traditional DCS and supervisory control and data acquisition systems. Thus, a PAC can identify and map I/O points as needed.

The fact that PACs handle I/O and data in the same manner as traditional supervisory control and data acquisition and DCS systems means they can more easily be interfaced directly with those systems. PACs are often used as substitutes for supervisory control and data acquisition RTUs (remote terminal units) and DCS field controllers, just because they work in a logically similar manner with data.

The IEC has created programming software standards, IEC 61131-3 and others to extend the capabilities of field automation controllers. These standards take the programming ability in about twenty ladder-logic commands and replace it with a full featured programming capability. There is the concept of function blocks. A late addition to the world of PLCs, function blocks come directly from the DCS (Distributed Control System) world. PACs are designed to utilize function blocks and function block programming rather than the more limited ladder-logic programming of the PLC.

They are capable of being programmed in a variety of higher order programming languages because PACs are in essence PCs. Suppliers of PACs have produced complete suites of programming software tools to enable very sophisticated operations to be controlled by PACs. For instance, Advantech produces software for HMI creation, PAC programming, supervisory control and data acquisition, and distributed control architectures, and an OPC server for connection to other control systems and even to MES and enterprise integration systems.

Programmable Automation Controller Determinism

Powerful processors drawn from the PC world and more sophisticated operating systems have made it possible for PACs to operate in various modes and with different deterministic speeds. PACs combine Real-Time Operating Systems (based on Windows CE 5.0 or its successors) with the ability to conduct multiple loop operation, and handle execution priorities in a much more sophisticated manner than a PLC, but with all of the deterministic reliability and safety by means of built in system triggers and a more useful and complex way of handling I/O and system timing. This makes it possible to have both deterministic safety, reliability and speed of the PLC combined with the reliance and power on COTS and standards-based products of the PC. The automation applications of modern controller have emerged as the PAC.

Many end users and OEMs of automation systems and controls work in more than one domain. For instance, even a highly process oriented plant such as a pharmaceuticals manufacturer or a fine chemical manufacturer has requirements within the plant for motion control, inventory management, packaging, and automated identification systems, as well as continuous and batch process control requirements.

The need to integrate LIMS (Laboratory Information Management Systems) and PAT (Process Analyzer Technology) Initiatives, and sampling initiatives around the plant have made it necessary to network multiple domains. In addition, increasing emphasis on conformance and quality management systems as well as the need to conform to increasingly detailed requirements for records and validation, such as the U. S. government's 21 CFR Part 11 and the Sarbanes-Oxley Act, have made companies' desire for fewer and more networkable systems grow in intensity.

A PAC can be used as a wide variety of applications in a wide set of domains within the manufacturing enterprise from inside the facility management system, in the environmental monitoring and handling system, in the factory automation systems themselves, and in the networks necessary to transfer the data from the plant floor and auxiliary control systems to the automation software and control centers and from there to the enterprise management systems themselves.

Powerful and Hybrid Programmable Controller

In the beginning there was the timer and the relay, There was the hardwired controller and in the process industries. Some decades ago, digital electronics made the hardwired relay and controller obsolete in favor of the PLC, the programmable logic controller. Have limited control functions and made to be fully deterministic, PLCs were able to sweep hardwiring into the dustbin because they were easy to program in the "ladder" style of electrical wiring diagram, and they were easily reprogrammable so that they can accommodate changes on assembly lines and in batch processes.

But PLCs are limited. Ladder-logic programming can not be used for complex formula of mathematical, such as the basic PID algorithm found in every single loop controller in a process plant. Along came the PC. Inexpensive computing power became easily and ubiquitous affordable. PCs were tried early on in industrial control, but early operating systems and hardware were not up to the standards and stresses of the industrial workplace.

The biggest issues were determinism. In many industrial automation environments, especially in other discrete automation applications and motion control, it is absolutely required that an instruction get where it is supposed to go, when it is supposed to get there. PC operating systems are non-deterministic and have variable latency, depending on processor loading or the requirements of the operating program.

Several companies have produced a powerful and useful hybrid of the programmable controller and the PC. This device is usually called a PAC, or Programmable Automation Controller. ARC Advisory Group is generally credited with coining the name PAC, and analyst Craig Resnick defines a PAC as having these characteristics:
• Multi-domain functionality, including motion, logic, drives and process on a single platform
• Common tagging and a single database
• Software tools that allow design by process flow across several machines or process units
• Mirror industry applications in open modular architectures that from machine layouts in factories to unit operations in process plants
• De-facto standards for languages and network interfaces, etc. allowing data exchange as part multi-vendor systems networked

Process Automation and Computer System Validation

It is well established that process automation systems need independent validation of the computer system to meet GMP requirements. With good planning, testing, procedures, and documentation, almost any computer system can be validated. The DeltaV value proposition is a lower cost of initial system validation by virtue of its integrated batch automation design. The DeltaV system lowers the computer systems validation cost by offering a single integrated system rather than a component-based architecture highlighted by a “class-based” configuration technique. Class-based configuration reduces the overall amount of documentation and engineering that needs to be done. Below are the specifics on how the DeltaV technology offers advantages in the area of validation.
Most automation systems of PLC technologies are component-based and require the configuration, installation, testing, and documentation of separate packages. This includes the engineering required to interface / link the various software applications to each other.

In the area of validation, less is better, Less engineering = Less validation.
The DeltaV system reduces validation cost by eliminating the need to interface and configure different software packages to each other. The following items are specific areas where this advantage is realized:
• Human/Machine Interface. The DeltaV system’s HMI shares a common database with the control modules and I/O. This eliminates the need to define tags at the HMI and map them to the controller tags and I/O. `
• Batch History. The DeltaV Batch History requires NO CONFIGURATION. Since the DeltaV Historian was designed as an integrated capability, once a recipe is executed with the DeltaV Batch Executive, the Batch Executive generates events. The events are then stored in the Batch Historian and are organized by batch ID according to the S88 model. Many batch history packages have to be extensively configured to recognize when batch events are occurring from triggers in the process. The DeltaV approach provides less configuration, less documentation, less engineering, and, hence, less validation.
• Continuous History. The DeltaV Continuous Historian was designed as an integrated feature. DeltaV Continuous History configuration requires selection of the DeltaV attributes for history assignment. A separate tag database would need to be mapped and configured to other system tag databases with component-based system historians. As stated before, less engineering, less configuration, less documentation all result in less validation.

Benefits of an Integrated Batch Automation System

The GMP manufacturing facilities regulatory nature requires a high degree of focus on product quality, system validation, and manufacturing records. A multi-unit batch recipe control approach based on the S88 model using an integrated system including data management provides highly significant benefits over the unit-based PLC approach while these objectives can be met with manual operations or unit-based automation using PLCs. The Emerson Process Management DeltaV digital of automation system can result in dramatic improvements in the way batch automation is implemented, executed, and validated.

Multi-unit recipe control can be implemented with a component- based or with an integrated batch automation system architecture using PLCs, MMI software, batch packages, and historian packages. The PLCs component-based architecture is a highly engineered specific solution to a project. It requires integration and selection of a variety of software packages. Each package is designed to be an independent product with a minimally designed, generic linkage to other 3rd-party software packages.

Each software system has to be installed, interfaced, and configured to the other software components. These hardware/software purchase price of components appears to be low. However, the cost to configure, validate, interface, and document the implementation of a component-based architecture significantly increases the total installed cost for the solution. The total maintained cost is higher. It must be configured, interfaced, validated, and documented, every time a change is made to the system. Also, since the configuration of the automation system has been declared to be a GMP record by the FDA, any changes made to the solution must be made under careful change control.

The more functional areas that require manual changes, the more complex the change management implementation will be. Regarding integrated design, the DeltaV system has all components designed to use a single configuration database. All DeltaV functional areas and applications are designed to work together such that the need to interface/link components and manually map data between applications is eliminated.

Multi-unit Recipe Control Implementation

A decision needs to be made if multi-unit S88 batch automation will be implemented when planning automation for a life sciences project. It is often saw as a simpler proposition to implement unit-based automation using PLCs only that are delivered with the equipment skids. The following benefits should be evaluated when considering whether a process should include full recipe automation:

• Product quality: Operations that base on people for executing manual recipes are subject to human variability. Processes that sensitive to variations in processing will result in quality variation. Full recipe automation that controls most of the critical processing operations provides repeatable, very accurate material processing. This leads to very highly consistent product quality.

• Improved production: Many biotech processes extremely have long cycle times (some up to 6 months), and are very sensitive to processing conditions. It is not uncommon for batches to be lost for unexplained reasons after completing a large the batch cycle time portion. The more sensitive production and the longer the batch cycle time is to processing conditions, the more batch automation is justified.

• Process optimization: Increasing the product yield can be done by making small changes in processing conditions to improve the biological growth conditions or chemical conversions. Manual control offers a limited ability to implement finely small changes to processing conditions due to the inherent lack of precision in human control. Conversely, computers are precisely very good at controlling conditions. In addition, advanced control capabilities can improve process optimization greatly. This results in lower production cost and higher product yield.

• Recordkeeping: A multi-unit recipe control system is capable to collect detailed records as to how a batch was made and relates all data to a single batch ID. This nature data can be very valuable for QA reporting, QA deviation investigations, and process analysis.

• Safety: Operators spend less time exposed to chemicals when the process is fully automated as compared to manual control. Less exposure to the process usually results in a safer process.

GMP Pilot Plant Automation Strategies

Recently, most major GMP manufacturing plants will include DCS-class automation because the benefits stated previously can clearly justify the costs. Small manufacturing and pilot plants facilities should also consider value propositions for full recipe control and data management.

• The Automation Investment Economics Have Changed. One of DCS perception is that it is expensive and hard to justify in a smaller facility. Times have changed. The starting price of a typical DCS software and hardware package was $300,000. Smaller applications can be much more economically addressed with the introduction of scalable technology like the DeltaV system. Digital systems are now available starting at $25,000 and can be economical for pilot plants small manufacturing, and even research facilities.

• Reducing Capital requirements. Many of the new biotech companies are currently bringing their first products through regulatory approval and into manufacturing. Initially, pilot plants are often used to meet these production requirements and manufacturing is required to support clinical trials. One advantage in adopting data management and batch automation capabilities in the pilot plant is that the facility will be better able to meet manufacturing needs after the new drug is approved and introduced to the market. A pilot plant’s production capacity may not be an important consideration during clinical trials. But if the pilot plant is used to satisfy production demands after the drug is approved, maximizing the equipment's capacity will be strategic and can delay the requirement to invest more capital for a new major manufacturing plant.

• Improving time to market. Once the new drug production requirements outgrow the capacity of the pilot plant, the product will have to move from the pilot plant to the manufacturing plant. Adopting the same automation strategy in the pilot plant and the manufacturing plant can reduce the cost and time of the transition from the pilot plant to the manufacturing plant. The batch recipes and control strategies will have been developed in the pilot plant, and the cost and time for developing automation for the manufacturing plant will be greatly reduced.

The Convergence of PLC and DCS

Many suppliers are touting their capabilities to provide both PLC and DCS functionality in their system to make their offerings attractive to the hybrid industries. As we have known, the technology difference between PLC and DCS is quickly disappearing, leaving only the domain expertise and experience of the supplier as a key differentiator. However, gaps in domain expertise are not closed overnight; significant knowledge has been accumulated by suppliers over the last 30 years, so beware of suppliers who are just recently claiming DCS or PLC capabilities in their portfolio. Users who want to ensure that their requirements can be addressed should consider selecting a supplier who has a long and proven track record for delivering both PLC solutions and a full-blown DCS for hybrid applications.

Many of the stereotypes at the past are being replaced, thanks to the convergence of PLC and DCS. This convergence has opened up hybrid applications of a new set options and for those process plants that used PLCs traditionally to control their electrical infrastructure such as Motor Control Centers (MCCs), motors, drives, and while utilizing DCS for regulatory control. Remember, it is not about the technology. Most importantly, it is about the application requirements and what supplier has the best solution, experience, heritage, and breadth of knowledge to meet your requirements, today and tomorrow.

Whatever you choose, we hope that you can feel like you have made a better and wiser informed decision based on the information in this paper. You may find that a traditional DCS or PLC no longer meets your requirements. If you have a hybrid application, then you may need a process control system which combines the best of the DCS and PLC, and a supplier who can provide a full offering of both discrete and process capabilities, all based on a common platform.

Password Using PLC Omron

PLC Type CP1L, Name Input / Output PLC :

INPUT PLC :
0.00 ; Numeric 0 from KeyPad
0.01 ; Numeric 1 from KeyPad
0.02 ; Numeric 2 from KeyPad
0.03 ; Numeric 3 from KeyPad
0.04 ; Numeric 4 from KeyPad
0.05 ; Numeric 5 from KeyPad
0.06 ; Numeric 6 from KeyPad
0.07 ; Numeric 7 from KeyPad
0.08 ; Numeric 8 from KeyPad
0.09 ; Numeric 9 from KeyPad
0.10 ; ENTER Key from KeyPad

OUTPUT PLC :
100.00 ; Output to Green Light for Correct Password
100.01 ; Output to RRed Light for Wrong Password

PLC Programming for Password using PLC Omron

Reading Ladder PLC Programming for Password using PLC Omron :

Step 1 :
Password Data using D20
a.If 11.00 = OFF (Always ON) Then D20 = 5500 (can be modified and 4 Digits Decimal)

Step 2 :
Numeric 0 to 9 is pressed
Using D0 for temporary data storage
a.If 0.00 = ON (Numeric 0) Then DIFU 10.00 = ON AND D0 = 0
b.If 0.01 = ON (Numeric 1) Then DIFU 10.00 = ON AND D0 = 1
c.If 0.02 = ON (Numeric 2) Then DIFU 10.00 = ON AND D0 = 2
d.If 0.03 = ON (Numeric 3) Then DIFU 10.00 = ON AND D0 = 3
e.If 0.04 = ON (Numeric 4) Then DIFU 10.00 = ON AND D0 = 4
f.If 0.05 = ON (Numeric 5) Then DIFU 10.00 = ON AND D0 = 5
g.If 0.06 = ON (Numeric 6) Then DIFU 10.00 = ON AND D0 = 6
h.If 0.07 = ON (Numeric 7) Then DIFU 10.00 = ON AND D0 = 7
i.If 0.08 = ON (Numeric 8) Then DIFU 10.00 = ON AND D0 = 8
j.If 0.09 = ON (Numeric 9) Then DIFU 10.00 = ON AND D0 = 9
Note : DIFU = Single-scan of target relay ON at rising edge of previous state

Step 3 :
Count the number keypad is pressed
Using D30 for Count data storage
a.If 10.00 = ON Then ++(590) D30 (Binary Increment)

Step 4 :
Enter Released for Value D30 = 0 (Count data RESET)
a.If 0.10 = ON (ENTER key is pressed) Then DIFD 10.01 = ON (Single-scan of target relay ON at falling edge of previous state)
b.If 10.01 = ON Then Value D30 = 0

Step 5 :
Password from the KeyPad
Using D12 for Password from the KeyPad
a.Keypad is pressed first, multiplied by 1000
(10.00 = ON) AND (= &1 D30) AND (*U &1000 D0 D1)
b.Keypad is pressed second, multiplied by 100
(10.00 = ON) AND (= &2 D30) AND (*U &100 D0 D2)
c.Keypad is pressed three, multiplied by 10
(10.00 = ON) AND (= &3 D30) AND (*U &10 D0 D3)
d.Keypad is pressed four, multiplied by 1
(10.00 = ON) AND (= &4 D30) AND (*U &1 D0 D4)
e.Sum all the data
(10.00 = ON) AND (+ D1 D2 D10)
(10.00 = ON) AND (+ D10 D3 D11)
(10.00 = ON) AND (+ D11 D4 D12)

Example :
Keypad is pressed :
first : Numeric 4 => 4 multiplied by 1000 = 4000
second : Numeric 4 => 4 multiplied by 100 = 400
three : Numeric 2 => 2 multiplied by 10 = 20
four : Numeric 2 => 2 multiplied by 1 = 2
Sum all the data = 4000 + 400 + 20 + 2 = 4422
So,Password from the keypad is 4422

Step 6 :
Check the number of digits
a.If D30 = 4 (4 times the keypad is pressed) Then 10.02 = ON

Step 7 :
Correct Password
a.If 0.10 = ON (ENTER key is pressed) AND 10.02 = ON AND Value(D12 = D20) Then SET 10.03 = ON
b.If 10.03 = ON Then 100.00 = ON (Correct Lamp)

Step 8 :
Wrong Password and Not 4 digits
a.If 0.10 = ON (ENTER key is pressed) AND 10.02 = ON AND Value(D12 not same D20) Then SET 10.04 = ON
b.If 0.10 = ON (ENTER key is pressed) AND 10.02 = OFF AND 10.03 = OFF AND 10.04 = OFF Then SET 10.05 = ON (Not 4 digits)
c.If 10.04 = ON OR 10.05 = ON Then 100.01 = ON (Wrong Lamp)

Step 9 :
Green Light = OFF OR Red Light = OFF
a.If 10.00 = ON AND 10.03 = ON OR 10.04 = ON OR 10.05 = ON Then RSET 10.03 (10.03 = OFF) AND RSET 10.04 (10.04 = OFF) AND RSET 10.05 (10.05 = OFF)

Please Download Programming for CX-Programmer version 9.1 :
Password Using PLC Omron

See : Password PLC

Process Control System for Hybrid Applications

Recently that we have reviewed the key criteria for selection of a PLC or DCS, you may be thinking that your application needs capabilities from both a PLC and a DCS. If this is TRUE, then you may need a process control system for hybrid applications.

What is a "hybrid?"
• The discrete functions marriage, which PLCs handled so simply and economically, with the sophisticated analog continuous control capabilities of the DCSs
• Defined based on the industries in which the systems serve and work, like fine chemicals, pharmaceutical, food and beverage, and others"
• The PLC architectural marriage simplicity and cost with the sophisticated alarm management, operator displays, and easy but sophisticated configuration capabilities of the DCS.

This article has described the key attributes and differentiators between classic PLC and DCS systems. This same information can be used to identify the key requirements for a process control system that would be ideally suited for hybrid applications, such as those in the fine chemicals, pharmaceutical, and food & beverage industries.
• Controller – Can execute fast scan logic (10- 20 msec), such as that required for motor control, and slow scan logic (100 - 500 msec
• Engineering Configuration Languages – Provides function block diagram, ladder logic, and a powerful programming language for creation of custom logic from scratch
• Flexible Modular Redundancy – Offers the tailoring option of the level of system redundancy to deliver the required system availability by balancing up-front cost versus the cost of unplanned downtime
• Modular Batch from Simple to Complex – Provides modular batch capability to cost-effectively address the simple continuum to complex batch applications
• Alarm Management – Offers power alarm management tools to help operators effectively respond to plant upset conditions
• Asset Management and System Diagnostics – Provides both a rich set of built-in system diagnostics, as well as asset management of all critical assets in the plant (valve positioners, transmitters, heat exchangers, motors, drives, MCCs, etc.)
• Scalable Platform – software, hardware, and licensing supports smooth and economical scale up from small all-in-one systems (10's of I/O) up to large client/server systems (10,000's of I/O)

Engineering Expectations to DCS and PLC

Manufacturing automation engineers want customizable control platforms, which offer the individual components that can be programmed quickly together to accomplish the task at hand. Often engineers and integrators open the PLC toolkit, roll up their sleeves and start programming. Typically the tools provided by a PLC are optimized to support a bottom-up approach to engineering, which works well for smaller applications.

On the other hand, DCS engineers are typically most effective using a top-down approach for engineering, which forces them to put significant effort into the upfront design. This focus on upfront design is a key to compressing the project schedule, and minimizing costs, creating an application that can be maintained by plant personnel over the long term. Since DCS applications are larger and plant wide in scope, the ability to propagate libraries and templates throughout the application is very important to minimize rework and promote the use of standards.

Think about it this way, the PLC is controlling a machine, while the DCS is controlling the plant. For instance, pencil manufacturer is producing an incredible amount of pencils at an extremely rapid speed using a PLC. Engineers could be able to squeeze another 10 milliseconds out of the machine by programming in machine code, which is now capable of punching out even more profits and pencils.

The PLC engineer demands that kind of open architecture and flexibility. The process engineers are controlling entire plants with a DCS require more intuitive programming platforms, which utilize pre-tested and predefined functions to drive repeatability and save time.

Getting the right tool for the job is also critical. Ladder logic is the preferred and ideal configuration language for many discrete control applications, such as the control of motors and drives or high-speed interlocking. On the other hand, function block diagram is preferred for continuous control and for implementation of alarming schemes.

PLC and DCS System Performance

The logic execution speed is a key differentiator. The PLC has been designed to meet the high-speed applications demands that require scan rates of 10 milliseconds or less, including operations involving motion control, interlocking, high-speed or control of motors and drives. It is necessary fast scan rates to be able to effectively control these devices.

The DCS does not have to be that quick most of the time. The regulatory control loops scan normally in the 100 to 500 millisecond range. It should be detrimental to have executed of control logic any faster possibly causing excessive wear on final control elements such as valves, resulting in premature maintenance and process issues.

The insurance policy of sorts, an extra cost for redundancy, may be well worth it in the case of the typical DCS system, where high availability is mission critical. It is often not cost justified to make a PLC system fully redundant.

Taking the PLC system offline to make engineering changes and configuration may have less impact, since the platform is not running continuously or because the process can be restarted easily. In contrast, engineering changes and configuration changes to the DCS system are done online, while the process is running virtually non-stop. Many process applications may only shut down once or twice a year for scheduled maintenance, while others, such as a blast furnace, are planned to stay on-line continuously for 5-7 years.

The analog control issue is important, but confusing. DCS was designed originally for delivering analog control, but to say the DCS has a lock on the analog control market reiterates the problem with traditional thinking. The PLC is capable of delivering simple to complex PID control, but the DCS is clearly the choice for applications with a large amount of advanced analog control, including model predictive control, cascade loops, ratio, and feed forward loops.

These are advanced solutions for process control that are driven as much or more by a vendor's domain knowledge and experience as the different platform capabilities. It's that expertise and heritage, which comes from meeting customer requirements for decades, that differentiates the systems, not the technology. If a company can not explain to you how their feed forward loop works, for example, they probably do not offer true "DCS" control.

System Performance of PLC and DCS

The logic execution speed is a key differentiator. The PLC has been designed to meet the high-speed applications demands that require scan rates of 10 milliseconds or less, including operations involving high-speed interlocking, motion control, or control of motors and drives. Fast scan rates are necessary to be able to control these devices effectively.

The DCS does not have to be that quick most of the time. The regulatory control loops scan normally in the 100 to 500 millisecond range. It should be detrimental to have control logic execute any faster, possibly causing excessive wear on final control elements such as resulting in premature maintenance, valves, and process issues.

The extra cost for redundancy may be well worth it in the case of the typical DCS system, where high availability is mission critical. But, it is often not justified the cost to make a PLC system fully redundant.

Taking the PLC system offline to make engineering changes and configuration may have less impact, since the platform is not running continuously or because the process can be restarted easily. Configuration tweaks and changes to the DCS system are done online, while the process is running virtually non-stop. A lot of process applications may only shut down once or twice a year for scheduled maintenance, while others, such as a blast furnace, are planned to stay on-line continuously for 5-7 years.

The analog control issue is important, but confusing. DCS was designed originally for delivering analog control, but to say the DCS has a lock on the analog control market reiterates the problem with traditional thinking. Increasingly, the PLC is capable to deliver simple to complex PID control, but the DCS is clearly the choice or applications with a large amount of advanced analog control, including model predictive control, cascade loops, ratio, and feed forward loops.

PLC and DCS to Increase Manufacturing Value and Cost Down

If the each independent product value being manufactured is relatively low, and/or downtime results in lost production, but with little additional cost or damage to the process, the PLC is the likely choice. If the value of a batch is high, either in market value or raw material cost, and downtime not only results in lost production but potentially dangerous and damaging conditions, the selection should be DCS. A plant that has a $10 million batch of a cancer drug in production that relies on strict and continuous temperature control, for instance, has a lot at stake in the event of a glitch. In some chemical manufacturing, maintaining the process at steady state is critical, because if the system goes down, the product could solidify in the pipes. If the cat cracker in a refinery lower down it could be days before it can be brought back on line so that production can resume. This means lots revenue lost for the refinery. The DCS system is probably worth the additional upfront investment for these applications.

In contrast, the brewery bottling operation that only needs to run 10 hours a day to meet production schedules, and which can be shutdown for system maintenance, troubleshooting, or upgrades with very little impact on the bottom line, it is a classic PLC application.

Downtime is one of the gremlins you try to avoid at all cost in process applications running 24/7/365. And money is not only the deciding factor. Dangerous downtime is clearly another deciding factor in the process of system selection. For instance, a refinery has flares that are continuously burning off gas. The system controlling those flares simply can not fail, because if the gas is not burning, it's collecting and pooling, causing an extremely dangerous situation. The more volatile the application, the more it may need a solution with lots of redundancy to ensure that the system is available when needed.

The Factory Automation Application

This may seem like a very basic question, but it is basic to determining the requirements of the application and, therefore, the best fit automation system. The way a product is manufactured, the performance needed, along with any physical limitations of the process, all influence the system selection.

Factory automation applications typically for which the PLC was originally designed, involve the manufacturing and/or assembly of specific items things. These PLC applications may employ one or more machines and a fair amount of material movement from machine to machine. A typical of this type of process characteristic is that the operator can usually monitor the things visually as they progress through the manufacturing line. The process is, by nature, very logic control intensive, often with high-speed requirements (throughput = profits). This type of process is often controlled by a PLC and Human Machine Interface (HMI) combination.

Typically, process automation applications involve the transformation of raw materials through the reaction of component chemicals or the introduction of physical changes to produce a new, different product, stuff. These applications may be built of one or more process unit operations piped together. The operator can't see the product is one key characteristic. It is usually held within a vessel and may be hazardous in nature. There is usually a large amount of simple to complex analog control (i.e., PID or loop control), although the response time is not that fast (100ms or greater). This type of process is often controlled by a DCS, although the analog control capability of a PLC may be more than adequate. A factor of determining in the selection process is often how large in scope the control application is (i.e., plantwide versus single unit and number of I/O points).

There may also be sequential (or batch) control needs. A PLC can be effectively used for simple batch applications, while a DCS is typically better suited for "complex" batch manufacturing facilities that require a high level of flexibility and recipe management.

Benefits of Selecting the Right Automation Technology

In this era of global competition, manufacturers in the process industries are being driven to achieve operational excellence to secure their place ahead of their competition now and in the future. Selection of new automation technologies impacts this goal. Consequently, the selection process is more important to a company's staying power than ever before. In fact, the importance of the selection of technology far outweighs the cost of the automation investment itself.

Selecting the right technology and the right supplier can help your company:
• respond quickly to changing market conditions in a way that creates a sustainable competitive advantage
• minimize Total Cost of Ownership (TCO) over the life of your plant
• create a system which is easily maintainable/upgradeable for the long-term
• achieve its future goals and vision

Selecting a system of automation based on a review of available products is the typical course of action for someone in the market for a new automation system. The problem approach is that your perception of which systems "make the cut" is often based on old stereotypes or influenced by the claims of the first salesperson in the door. Let's look at the components of a DCS or PLC based system to see how different (or similar) they really are.

At first glance, the pictured system architectures look very similar. Both systems share the following components:
• Field devices
• Input/output modules
• Controllers
• Human Machine Interface (HMI)
• Engineering
• Supervisory control
• Business integration

As you look at the following system architectures, you should note that the technologies used in each system are in fact, very similar; the difference becomes more apparent when you consider the nature and requirements of the application.

For example, in the DCS architecture diagram, redundancy is often employed for I/O, controllers, networks, and HMI servers. Since redundancy adds complexity and sometimes cost, DCS users must carefully evaluate their need for redundancy in order to achieve their required system availability and to prevent unplanned downtime.

The Seven Questions before Choosing a System

Now we will get to the core of this article the seven questions you should ask yourself before choosing a system. You should realize that we will be using the broad generalizations in the following analysis, and that every individual application will have exceptions to these rules; however, the logic is still sound. While the authors work on different sides of the PLC or DCS fence for a supplier that has delivered both DCS and PLC solutions to the market for over 25 years, we feel that we are in a unique position to deliver both sides of the story.

The seven questions are designed to make you think about your company's operating philosophy and application requirements, taking into account the point of view of all the major stakeholders in your plant (engineering, operations, maintenance, etc.).

1. What are you manufacturing, and how?
2. What is the product value being manufactured and the cost of downtime?
3. What do you view as the "heart" of the system?
4. What does the operator need to be successful?
5. What system performance is required?
6. What degree of customization is required?
7. What are your engineering expectations?

Note that a consolidated list of the questions and possible responses are presented at the back of this article the tear off page. One simple method for the gauging whether you should be using a PLC or DCS is to go through this survey form, checking all of the responses that apply. If all of your responses are in one column, then your application clearly calls for this one type of system. If you have multiple selections from both the PLC and DCS columns, then maybe you have a hybrid application which requires a process control system capable of delivering both PLC and DCS functionality.

Selecting Programmable Logic Controllers or Distributed Control Systems

The convergence technologies of PLC and DCS has created a situation where it is more challenging than ever for process manufacturers to select the best technology for their application, especially in manufacturing industry. An evaluation should start by developing a clear picture of the requirements of your application and the needs of your engineering, maintenance, and operations personnel.

For selecting the best automation technology procedure is not as easy as it once was, for manufacturers in the process industries. In the past it was fairly easy to determine whether a PLC or a DCS was right for your application, because they have own strengths and weaknesses were well understood. In current years this has become more difficult, thanks primarily to the advancement of the microprocessor, which has allowed the technologies to merge. Many of the applications in the manufacturing process industries now share the requirements traditionally thought to be exclusive to either DCS or PLC with the trend toward flexible manufacturing in the industry. Typically these hybrid applications are requiring process control system that can deliver both the PLC and DCS capabilities. Thus understanding of the merging of PLC and DCS functionality is important for selecting the best system for your company.

We will shift away from some of the classic stereotypes of DCS and PLC in order to explore seven key criteria, which will help your company select the system that best meets your goals. It will also demonstrate why having a clear picture of the requirements of your application and the needs of your engineering, maintenance, and operations personnel is paramount to finding the right automation technology for your company.

One can see that PLC and DCS are not that different, which has paved the way for them to merge from a technology point of view. Therefore, we must look beyond technology to the domain knowledge and application expertise that is built in to these systems by the supplier, so that we can better understand the sweetspots where each is best applied.