Programming Standard Specification 7x04

Scroll Assembly Programming Standard Specification
Scroll Assembly
Programming Standard
Specification
Emerson
March 2018
Document Summary
Title: “Scroll Assembly Programming Standard Specification”
Revision History:
Revision: 7.04
Version 7.0
Page 2 of 141
Quality Assurance:
Approval Summary:
Revision Date Comments Released By
1.0 3/08/2006 Initial Release D. Strength

Updated with simplified sequence
1.1 4/10/2006 structure, configuration control details, D. Strength
and other customer requirements.
1.2 4/12/2006 Updated main sequence start bit logic. D. Strength
Revised to include as-built changes to
PLC code. Removed development review
procedures. Removed general
2.0 Draft 4/1/2007 D. Strength
Configuration control interface description
to be replaced with detailed
implementation instructions.
Added Configuration Control Interface
2.1 5/9/2007 E. Herrington
section.
Revised with Post-Install Changes
5.0 Draft 12/21/2007 Requested by Copeland, Prism and D. Frey
Cinetic
Revised with post-install changes after
5.0 Draft v.2 8/6/2008 R. Fortenberry
typical revisions at the Reynosa location.
5.6 Draft 12/01/2008 Updated with latest revisions. E. Herrington
Added Documentation for Panelview
5.7 Draft 4/13/2009 D. Frey
Standards
Added expanded details on common
5.7 4/21/2009 components. Changed name of the C. Harbaugh
document.
Added documentation on station
5.8 5/8/2009 modification data and build over R. Fortenberry
configuration
Added Logic Changes from Reynosa Line
5.8 5/15/2009 C. Harbaugh
3 Install
Separated Pre-Stop into its own
6.0 01/07/2010 C. Harbaugh
sequence.
Added PLC based step and fault
6.2 06/29/2010 C. Harbaugh
descriptions. Added AOI_Step
7.0 11/5/2015 Updated with latest revisions. C. Harbaugh
Updated Scanner sections to include
7.0 3/10/2016 T. Howell
Cognex and Banner scanner routines
7.03 9/12/2016 Added Robot Programming E. Slonkosky
7.04 3/22/18 Fortress System for entry doors E. Slonkosky
Version 7.0
Page 3 of 141
Version 7.0
Page 4 of 141
Table of Contents
1. CONTROL SPECIFICATION OVERVIEW .................................................................. 9

1.1. Introduction ............................................................................................................................................. 9
1.2. Scope, Roles, and Definitions ................................................................................................................. 9
1.3. System Architecture .............................................................................................................................. 10
2. CONTROL SYSTEM SPECIFICATIONS .................................................................. 12

2.1. Control Hardware ................................................................................................................................. 12
2.1.1. Process Controllers ................................................................................................................... 12
2.1.2. Communication Networks ........................................................................................................ 12
2.2. Standard Development Template ........................................................................................................ 12
2.3. General Control File Structure ............................................................................................................ 12

2.3.1. Routine Naming ........................................................................................................................ 13
2.3.2. Tag Naming .............................................................................................................................. 13
2.3.3. Configuration Control Tag Naming .......................................................................................... 14
2.3.4. Logic and Tag Comments ......................................................................................................... 15
2.4.1. UDTs and Object-Oriented Programming ................................................................................ 16
2.5.1. Digital Inputs ............................................................................................................................ 19
2.5.2. Digital Outputs .......................................................................................................................... 21
2.5.3. Digital Output Qualifiers .......................................................................................................... 21
2.5.4. Analog Inputs and Outputs ....................................................................................................... 25
2.6. Alarm Handling ..................................................................................................................................... 26

2.6.1. Step Timeout Alarms ................................................................................................................ 28
2.6.2. I/O Faults .................................................................................................................................. 30
2.6.3. Machine Motion Faults ............................................................................................................. 30
2.6.4. Station Faults ............................................................................................................................ 31
2.6.5. Machine Alarm to PanelView Interfacing ................................................................................ 31
2.7. Operator Notification Handling ........................................................................................................... 32

2.7.1. Acknowledged Notifications..................................................................................................... 32
2.7.2. Automatically Cleared Notifications ........................................................................................ 32
2.7.3. Notification Description Text ................................................................................................... 32
2.7.4. Notification AOI Parameters .................................................................................................... 33
2.8. Constants................................................................................................................................................ 34
2.8.1. Machine Address Constants ...................................................................................................... 34
2.8.2. Step Constants........................................................................................................................... 35
2.8.3. Machine Tooling Constants ...................................................................................................... 35
2.8.4. Common Constants ................................................................................................................... 37
2.8.5. Motion Status Constants ........................................................................................................... 37
2.9. Station Scanner Interface ..................................................................................................................... 38

2.9.1. Scanner Trigger and Re-Trigger Logic ..................................................................................... 39
Version 7.0
Page 5 of 141
2.10. Sequential Logic .................................................................................................................................... 39

2.10.1. Sequence UDT .......................................................................................................................... 39
2.10.2. Sequence Ladder Structure ....................................................................................................... 40
2.10.3. Sub Sequences .......................................................................................................................... 47
2.11. Non-Sequenced Control and Safety ..................................................................................................... 47

2.11.1. Standard Asynchronous Logic .................................................................................................. 48
2.11.2 Safe Entrance into a cell ............................................................................................................ 48
2.12. Manual Control ..................................................................................................................................... 49
2.13. Configuration Control Interface .......................................................................................................... 49

2.13.1. Scan Barcode ............................................................................................................................ 49
2.13.2. Serial Model Request ................................................................................................................ 50
2.13.3. WIP Reply ................................................................................................................................ 50
2.13.4. Schedule Reply ......................................................................................................................... 51
2.13.5. Update Schedule of the Station ................................................................................................. 52
2.13.6. Check the Status of the Pre-Stop Compressor .......................................................................... 52
2.13.7. Copy Pre-Stop Data to Compressor Data .................................................................................. 52
2.13.8. Populate Compressor Results ................................................................................................... 53
2.13.9. Setting Compressor Pass/Fail ................................................................................................... 53
2.13.10. Saving Cycle Values ................................................................................................................. 53
2.13.11. Send WIP Update...................................................................................................................... 54
2.14. User Defined Types ............................................................................................................................... 57
2.15. Interface Routines ................................................................................................................................. 60

2.15.1. System_Recieve_WIP............................................................................................................... 61
2.15.2. System_Receive_Schedule ....................................................................................................... 61
2.15.3. System_Recieve_OperatorExt .................................................................................................. 61
2.15.4. System_Recieve_PassThru ....................................................................................................... 61
2.15.5. System_Receive_StationConfig................................................................................................ 62
2.15.6. System_Verify_Tooling ............................................................................................................ 62
2.15.7. System_Verify_Parts ................................................................................................................ 62
2.15.8. System_Request_Schedule ....................................................................................................... 62
2.15.9. System_Request_Security......................................................................................................... 62
2.15.10. System_Update_WIPExt .......................................................................................................... 62
2.15.11. System_Production_Data .......................................................................................................... 63
2.15.12. System_Update_Generic........................................................................................................... 63
2.16. Standard Sequence Steps ...................................................................................................................... 64

2.16.1. Pre-Stop Sequence Standard Steps ........................................................................................... 64
2.16.2. Main Sequence Standard Steps ................................................................................................. 79
2.17. Production Data .................................................................................................................................... 87
2.18. Tooling Verification .............................................................................................................................. 88
2.19. Best Practices ......................................................................................................................................... 91

1.1.1. Latched Instructions .................................................................................................................. 91
1.1.2. Jump, Label, and MCR Instructions ......................................................................................... 92
3. ROBOT INTERFACE/PROGRAMMING ................................................................... 93
Version 7.0
Page 6 of 141
3.1. Robot Communications ........................................................................................................................ 93
3.2. Robot Safety........................................................................................................................................... 93
3.3. PLC Programming ................................................................................................................................ 93

3.3.1. Control_Robot .......................................................................................................................... 93
3.3.2. Sequence_Robot ....................................................................................................................... 97
4. OPERATOR INTERFACE......................................................................................... 97
4.1. Hardware ............................................................................................................................................... 97
4.2. Standard Interface ................................................................................................................................ 97
4.3. Standard Development Template ........................................................................................................ 97
4.4. Displays .................................................................................................................................................. 98

4.4.1. Display Numbering ................................................................................................................. 100
4.4.2. Common Template Display Elements .................................................................................... 103
4.4.3. Main Display........................................................................................................................... 105
4.4.4. Machine Control Display ........................................................................................................ 105
4.4.5. Manual Control Display .......................................................................................................... 108
4.4.6. I/O Navigation Display ........................................................................................................... 110
4.4.7. I/O Displays ............................................................................................................................ 111
4.4.8. Operation Management Display ............................................................................................. 114
4.4.9. Tooling Verification Display .................................................................................................. 115
4.4.10. Live Load Display .................................................................................................................. 116
4.4.11. Schedule Details Pop-Up ........................................................................................................ 117
4.4.12. Parts Verification Display ....................................................................................................... 118
4.4.13. Verification Override Display ................................................................................................. 119
4.4.14. Operator Disposition Display.................................................................................................. 120
4.4.15. Production Data Display ......................................................................................................... 122
4.4.16. Production Events Display ...................................................................................................... 123
4.4.17. Alarms Display ....................................................................................................................... 124
4.4.18. Exit Confirmation Pop-Up ...................................................................................................... 125
4.5. Recommended Techniques ................................................................................................................. 125
4.5.1. Search and Replace Station Prefix..................................................................................................... 125
4.5.2. Object Explorer ................................................................................................................................... 125
4.5.3. Property Panel ..................................................................................................................................... 127
4.6. Typical Button Object ......................................................................................................................... 127
4.7. Tags ...................................................................................................................................................... 132
4.8. Alarms .................................................................................................................................................. 133
4.9. Parameter Files.................................................................................................................................... 135
4.10. Communication Setup ........................................................................................................................ 135
Version 7.0
Page 7 of 141
4.11. Multi-Language Support .................................................................................................................... 136
APPENDIX A - USER DEFINED STRINGS ...................................................................... 137
APPENDIX B – STANDARD ROUTINES .......................................................................... 138
Version 7.0
Page 8 of 141
1. Control Specification Overview
1.1. Introduction
The goal of this document is to define the process and specifications to which machine control systems will be
designed and commissioned within Emerson.
In developing this document, primary consideration was given to achieving a control systems specification
that provides a balance between the following concepts:
• Accurate implementation and efficient development by plant engineers, OEM’s (Original Equipment
Manufacturers,) and third-party developers.
• Robust operation within production environment.
• Standardized integration with other facility systems.
• Efficient long-term maintenance by facility personnel.
This specification attempts to achieve this by providing guidelines defining how control systems will be designed,
developed, and commissioned.
1.2. Scope, Roles, and Definitions

Within reference to this document, the developer is considered any OEM, third party, or internal personnel that
is designing, commissioning, or otherwise providing a machine or process control system. The project controls
engineer is the person or group that has been tasked with reviewing and managing the design and
commissioning of such control systems.
This scope of this specification shall include all control systems provided by any developer of any automated
machine (or station), process, or other Level 1 or 2 control system. The general intent of this document is to
assure that all supplied control systems are capable of being efficiently operated and maintained. Likewise, it is
intended to provide the developer a set of guidelines and tools that is sufficient in defining expectations, but
does not impose unnecessary restriction.
This document does not attempt to provide details concerning the design and operation of any machine or
equipment. Rather the intent is to provide a guideline of how the control for such equipment is to be
implemented. Further, this document does not relieve the developer from any responsibility to provide a
functioning system. If the developer finds a conflict in this document that will adversely affect the operation of
their equipment, then it is the responsibility of the developer to notify the Emerson project controls engineer of
the conflict.
Version 7.0
Page 9 of 141
1.3. System Architecture

The manufacturing process of a typical Emerson facility consists of a large array of discrete operations
performed by specific machines or stations. These machines are coordinated and managed by a supervisory
system. A key element of this system is the Configuration Controller: a supervisory PLC that handles part
tracking, scheduling, dynamic machine configuration, and station results logging. The Configuration Controller
interfaces with both plant configuration databases and with each station, providing a means of passing
configuration data to each station, and returning station results to plant databases.
In a typical scenario, a part arrives at a specific machine and is scanned by bar-code scanners attached to either
the station or the Configuration controller. The controller prepares a message for this specific machine including
status of the part to be processed, required tooling, and configuration parameters for the operation to be
performed.
These parameters will arrive at the station PLC via a PLC message and are mapped into a standard data
structure using User Defined Types (UDTs.) The developer will call a subroutine to request this data from the
UDT. The subroutine will automatically map all configuration data into a group of Compressor tags to be utilized
in the PLC program. Upon completion of the test, the station PLC will map results data by calling an Update
subroutine that will pack and send a PLC message back to the Configuration controller. These System
subroutines will minimize the developer’s effort required to interface with the Configuration controller.
A general overview of the general plant architecture is presented in Figure 1 below:
Figure 1 - Network Overview
Version 7.0
Page 10 of 141
Version 7.0
Page 11 of 141
2. Control System Specifications
2.1. Control Hardware
2.1.1. Process Controllers
All control systems provided shall utilize either Allen-Bradley ControlLogix or CompactLogix process
controllers. Most machines should use CompactLogix, since this processor is much more cost-effective
in small applications. Acceptable processors are listed in the most recent “Scroll Assembly Industrial
Equipment Standards” document referenced in the equipment RFQ.
2.1.2. Communication Networks
All communication must be performed via Ethernet or DeviceNet networks. Ethernet should always be used as
the plant network interface. DeviceNet communications are acceptable for DeviceNet enabled instruments that
do not have an Ethernet option.
Ethernet IP addresses, subnet masks, and gateway addresses will be supplied by Emerson. DeviceNet
networks should avoid using address 63 for any device.
ControlNet, DH485, and other communication networks should be avoided unless otherwise approved on an
exception basis.
2.2. Standard Development Template

The Standard Station Template has been created as a starting point in the RSLogix 5000 file named
Station_Template_Online_Rev7x03.ACD. The Standard Station Template is designed to provide the developer
with a set of common tools consisting of interface logic, machine control philosophy, and data definitions required
to successfully implement a station within a configuration control system.
The Standard Station Template consists of two types of routines: System routines, and Non-System routines.
The System routines are to be used “as-is”, that is, no modifications to the logic (other than station-specific tag
names, and/or message communication path configurations) are allowed without prior written approval from
Emerson, Inc. The Non-System routines are provided to the developer as a framework for development of
machine specific operations. These routines provide the structures that are to be used to develop I/O handling,
machine alarms, HMI interfacing, sequential machine control, machine tooling, auto and manual operations. As
with the System routines, any deviations from the standard practices shown in the Standard Station Template
or described in this document must have written approval from Emerson, Inc.
The template does not provide all coding elements necessary to implement a control station. It is designed and
provided as a starting point for development, and in no way, comprises an all-inclusive set of controller code.
2.3. General Control File Structure
Version 7.0
Page 12 of 141
A standard control file organization will be implemented in each control program. This standard encompasses
elements such as routine and tag naming conventions, commenting, standard User Defined Types (UDT’s) and
strings, and general program and logic flow. These elements are discussed in detail below.
All PLC code, tags, and comments shall be provided in English.
2.3.1. Routine Naming

To aid in program organization, program routines should be named utilizing a descriptive prefix followed
by an underscore. Using these prefixes keeps like routines grouped together within the Controller
Organizer in RSLogix 5000. The following general prefixes should be utilized.
Table 1 - Routine Naming Prefixes

Prefix Examples Application
Faults_ Faults_Main Alarm and Fault trigger routines.
Config_ Config_Constants Configuration Parameter logic.
Control_Async General non-sequenced and manual control of

Control_
Control_Hydraulic equipment.
HMI_Main
HMI_ HMI related message triggers and logic.
HMI_Homing
IO_MappingInputs
I/O Handling routines. Mapping of logical tags to
IO_ IO_MappingOutputs
I/O card images. Analog value scaling.
IO_ScalingInput
Sequence_Main
Sequence_ Sequential operations and control.
Sequence_Homing
System_Assign_CommonConstants System routines providing functions for other

System_
System_Receive_WIP routines. (These Are NOT to be Modified)
An effort should be made to utilize the prefixes listed above. However, if a prefix is required that is not
available; the developer can add additional prefixes with approval. All routines should be named utilized
some prefixing.
If multiple developers within one company are writing applications, the same routine naming convention
should be applied across all applications submitted by that company.
Using the above prefixes, standard routines have been created and supplied in the standard program
template for use in creating new programs. Descriptions of these files can be found in Appendix B –
Standard Routines. Please use these standard Routines.
2.3.2. Tag Naming
An effort should be made to create tags using tag names that are as descriptive and non-ambiguous as
possible. At the same time, redundant, non-essential text within the tag names should be avoided. Tag
Version 7.0
Page 13 of 141
names utilizing all capital letters should be avoided (capitals are reserved for constants, See section 2.8
Constants). Abbreviations should be avoided whenever possible.
Other than these general rules, the developer is free to choose tag names that make the most sense within
the scope of code development and machine operation. These guidelines are aimed at allowing the
developer flexibility in choosing tag names that are convenient, yet maintainable.
All tags should be created as Controller Scope Tags rather than Program Scope Tags. Additionally, auto-
generated Function Block tags are by default Program Scope, and should be left as such; however, the
programmer is free to rename the tags to more descriptive tag names. Written permission must be
obtained to deviate from this requirement.
To aid in tag organization, IO tags should be named utilizing a descriptive prefix followed by an underscore.
Using these prefixes keeps like tags grouped together within the Tag Editor in RSLogix 5000. The following
general prefixes should be utilized.
Table 2 - IO Tag Name Prefixes

Prefix Definition
DI_ Digital Input.
DO_ Digital Output.
AI_ Analog Input.
AO_ Analog Output.
If multiple developers within one company are writing applications, the same tag naming convention should
be applied across all applications submitted by that company.
Please see Section Error! Reference source not found. Error! Reference source not found. for further de
tails on tag naming with reference to Configuration Control that need to be followed.
2.3.3. Configuration Control Tag Naming
The Configuration Control Master uses a tag prefix to dynamically build the messages that are sent to
each client station. The tag prefix is defined in the Configuration Control Client web interface to. The PLC
template is programmed with the tag prefix set to “StationName”.
When starting with the Station Template it is important to replace the existing generic “StationName”
prefixes with the station name that will be used for the station being programmed. This should be done
with a search and replace from the Tag Browser. This will update ALL of the tags throughout the
program with the corrected station name without needing to search through the program and replace them
one at a time. The length of the station name chosen should be eleven (11) characters or less. Below is
a list of tag names with their associated UDTs and description.
Version 7.0
Page 14 of 141
Table 3 - Station Named Tag Listing

Tagname UDT Description
StationName_Compressor udt_Compressor Station compressor
StationName_CompressorResults udt_CompressorResults Station compressor results data
StationName_WIPData udt_WIPData Station WIP processing data
StationName_Operator udt_Operator Operator Security Data
StationName_OperatorData udt_OperatorData Station operator processing data
StationName_Parts udt_Parts Station Parts Verification Data and Control
StationName_PassThru PASSTHRU Station pass thru data
StationName_PassThruData udt_PassThruData Station pass thru processing data
StationName_Schedule udt_Schedule Station schedule data
StationName_ScheduleData udt_ScheduleData Station schedule processing data
StationName_Tooling udt_Tooling Station Tooling Verification Data and Control
StationName_CurrentCycle udt_ProductionData Station current machine cycle production data
StationName_Hour udt_ProductionData Station hourly production data collection

Station current hour production and event data
StationName_CurrHour udt_ProductionDataStorage
storage
Station previous hour production and event data
StationName_PrevHour udt_ProductionDataStorage
storage
StationName_ChangeOverEvent udt_ProductionEventData Station current change over event data
StationName_LastChangeOver udt_ProductionDataStorage Station last change over event data storage
StationName_EventHour udt_ProductionEventData Station hourly event data collection
StationName_MachineMetrics udt_MachineMetrics Station machine metrics data
StationName_GenericData udt_GenericData Station generic collection processing data
StationName_ModifyStation udt_StationConfig Station configuration data
StationName_ScannerData udt_ScannerData Station scanner processing data
2.3.4. Logic and Tag Comments
Logic and tag commenting are critically important, as they can greatly affect the efficiency with which the
code can be maintained on a long-term basis. An effort should be made to supply clear, succinct
Version 7.0
Page 15 of 141
descriptions of each group of logic. These logic comments should provide any information required for
one to fully evaluate the associated code.
Tag descriptions should not contain redundant information. Since tag names are to be chosen with
descriptive names, some tags will not require descriptions. For example, a tag named SeqMain.Run does
not need a tag description of “Sequence Main Run.”
Many of the provided UDT’s will be commented at design. Thus, many tags will automatically contain
comments. Conversely, as the use of UDT’s provides generic structures, many of the tag names are of a
generic nature and will rely on comments to associate logical meaning to the tags.
Some tags that are used for local operations within a routine do not need descriptions. For example, there
is no value in commenting a One-Shot variable for an ONS instruction that is used only in one rung.
2.4. Standard User Defined Types

The standard development template includes several User Defined Types (UDTs) utilized to implement a
specific functionality. These UDT’s fall into two groups: those utilized by system routines, and those utilized
directly by the developer in order to implement machine logic. For example, when developing a machine
sequence, the developer will create a user tag with a base type of udt_MachineSequence.
Some of the UDT’s are not utilized directly by creating a tag with that UDT’s basetype. Rather, in some
cases one UDT is inherited into another. Though slightly more complex, this approach of nesting multiple
UDT’s into a single UDT provides a compact and efficient means of implementing complex functionality
with a single tag. Note that all UDT’s are always named using the prefix ‘udt_.’ This provides a convenient
logical grouping when browsing tag base types from the tag editor.
Many of the UDT’s provided in the standard development template are utilized in messaging data between
the station PLC and Configuration Control Master PLC. As such, these standard UDT’s should NOT be
modified without written permission from Emerson. In cases where the developer needs to modify one of
the standard UDT’s, the modified UDT should be renamed with a suffix representing the station. For
example, if the Airboard PLC requires a change to the UDT udt_MachineSequence, the modified version
should be renamed udt_MachineSequence_AirBoard.
The standard for communications between processors relies on CIP messages over Ethernet/IP. The CIP
messages write directly to tags created using the standard UDT’s. To successfully execute these CIP
messages, the UDT’s utilized must be defined exactly the same in all of the processors involved. Modifying
one of these UDT’s in the station PLC will absolutely cause the MSG to fail. As such, when modifications
of these MSG Dependent UDT’s is required, it must be coordinated and redefined in the Configuration
Control Master. These changes should not be made without the coordination and express written
permission of Emerson.
2.4.1. UDTs and Object-Oriented Programming
The use of structured UDT based objects can greatly reduce the time required to develop and maintain
PLC code. This practice insures commonality of tag and file structure amongst different machines coded
by different developers. As such, an object-oriented scheme will be utilized to implement all major PLC
functions.
The set of UDT’s provided in the Standard Development Template have been designed to provide, as
much as possible, the majority the tags required to implement machine control and Configuration Control
integration. These UDTs feature general utility tags such as One-shot bits and Timers, PanelView tags
for interface control, tags for Mode and Status, as well as many implementation specific tags such as Alarm
acknowledgement bits, and current sequence step tags.
Version 7.0
Page 16 of 141
The UDT’s provided that are most often used to implement machine logic are as follows (See Error! R
eference source not found. and Error! Reference source not found. for a detailed listing of UDT’s):
udt_Machine
A tag with the name Machine of the type udt_Machine is created to provide tags for indicating and
managing the control of the mode of the machine. This tag and code to control the modes of the machine
are already created in the Standard Station Template and is only included here for reference. The tags
created with udt_Machine that are to be used to indicate the modes of the machine are:
Machine.Auto Indicates the machine is in Auto mode

Machine.Manual Indicates the machine is in Manual mode
Machine.Bypass Indicates the machine is in Bypass mode
Machine.pvAuto Connected to HMI Auto Mode Push Button
Machine.pvAutoAvail Used to control visibility of HMI Auto Mode push button
Machine.pvManual Connected to HMI Manual Mode Push Button
Machine.pvManualAvail Used to control visibility of HMI Manual Mode push button
Machine.pvBypass Connected to HMI Bypass Mode Push Button
Machine.pvBypassAvail Used to control visibility of HMI Bypass Mode push button
Figure 2 - Sample Rung with udt_Manchine type tag
udt_Output
Machine output control is implemented using tags of the data type udt_Output. For every output a new
tag of the type udt_Output will need to be created (Follow naming guidelines in section 2.3.2 Tag Namin).
ALWAYS use this UDT for creating and naming outputs. The tags created when using udt_Output are:
.Output Tag to be mapped to actual output

.pvPB Connected to HMI Manual button to control Output
.pvAvail Used to control visibility of HMI Manual Control push button
.pvIndicator Used to control text of HMI manual control multistate indicator
.SafeToInitiate Used to control the safety interlock for turning on the output
.SafeToMaintain Used to control the safety interlock for seal in of the output
.Req A DINT used to request outputs be turned on from sequences
.HomeReq A DINT used to request outputs be turned on from home sequence
See section 2.5.3 Digital Output Qualifiers for an example using this udt.
Version 7.0
Page 17 of 141
udt_MachineAlarms Alarming is implemented using a single tag, MachineAlarms, based on the type
udt_MachineAlarm. This tag is already created in the Standard Station Template and is only included here
for reference. Tags created in the udt_MachineAlarm type provide the necessary alarm components:
MachineAlarms.pvClear Connected to HMI button to clear alarms
MachineAlarms.pvSilence Currently is not used in the PLC program
MachineAlarms.pvAlarmPending Connected to alarm banner visibility so it

will flash
MachineAlarms.ActiveAlarm DINT containing the number of the active
alarm
MachineAlarms.Index Currently is not used in the PLC program
MachineAlarms.Alarm[] Nested UDT containing the Timer and
Trigger for each alarm
MachineAlarms.RecoverableFault
MachineAlarms.FaultsPending Bit used in the program to indicate that
faults are active
MachineAlarms.DisableStepAlarm Used to manually disable sequence step
faults during debug
MachineAlarms.FlasherOn Timer to have an intermittent message
displayed ON
MachineAlarms.FlasherOff Timer to have an intermittent message
displayed OFF
MachineAlarms.CopyActiveDescriptionToArrayDescription When an alarm occurs the description of
the active alarm is copied into the
corresponding array element.
MachineAlarms.CopyArrayDescriptionToActiveDescription When an alarm occurs the description of
the active alarm array description is
copied to the “Description” element.
MachineAlarms.AlarmsDescriptionCopyTime
MachineAlarms.ActiveLanguage Active language in which alarms
descriptions are displayed
GoToAlarms_pvAvail If Machine alarms are active the “Go to
Display” for Alarms becomes active
Alarms are categorized as being either a step timeout alarm, or a general machine alarm (see section 2.6
Alarm Handling for details on alarms).
udt_PushButton
Version 7.0
Page 18 of 141
An HMI button that is not connected to an output or a machine mode should be created using a tag
based on the type udt_PushButton. Tags created with the udt_PushButton type create the following
tags to be used in the program:
.pvPB Connected to HMI push button

.Output Used to turn something on if needed
.pvAvail Used to control visibility of HMI push button
.pvIndicator (Used to control text of HMI manual control multistate indicator)
udt_Step
Each time a step is created in the program sequences (see section 2.10 Sequential Logic) a tag of the
type udt_Step should be used. Using this UDT will create the following tags to be used in the creation of
the sequence:
.Description Step Description used in displaying step info on the HMI

.AOI Add On Instruction with logic for setting the Step Constant and Step Fault
.AOI.Stp INT with the constant value of the step index
udt_MachineSequence
Each time a new sequence is needed in the program (SeqMain and SeqPreStop are already included in
the Standard Station Template and do not need to be created) a tag should be created of the type
udt_MachineSequence. This will provide all of the tags necessary to implement a sequence as described
in section 2.10 Sequential Logic.
2.5. I/O Handling

Standard practices for handling Inputs and Outputs are discussed below. In some cases, multiple options are
given for implementing the same functionality. The developer should choose the best available option according
to the guidelines provided below.
2.5.1. Digital Inputs
The IO_MappingInput routine provides a centralized location for the mapping of the physical digital inputs
to user discrete input tags for use in the machine control logic. The user input tags are defined as type
AOI_DEBOUNCEDINPUT. The input mapping is accomplished by using the Add-On Instruction,
AOI_DEBOUNCEDINPUT. This instruction provides for both a de-bounce on (On Time Delay) and de-
bounce off (Off Time Delay) time. Simply changing the counts in the AOI instruction will accomplish this.
.InUnDbncd Used for cases where de-bouncing of the input is NOT required
.InDbncd Used for cases where de-bouncing of the input is required
.OnTimeDelay Time in milliseconds after input is on that .InDbncd is set
.OffTimeDelay Time in milliseconds after input is off that .InUnDbncd is reset
The .InUnDbncd and .InDbncd tags should always be used in the program. Use of the raw input tag is
NOT acceptable. Each unused or spare input is to be mapped to a No Operation (NOP) instruction. The
program developer is responsible for setting these to acceptable values to balance the safety, stability,
and cycle time of the machine. The counts are in milliseconds. Each input should be assigned to an
individual rung for readability. Debouce times are set to 0 when the AOI is inserted. The developer is
responsible for adjusting these to provide a safe machine with the best possible cycle time. Pallet present
Version 7.0
Page 19 of 141
and other like debounce requirements should be done here and not in the sequence of the machine. The
rungs should be separated using a NOP comment rung detailing the addressing and part number
information for the Input card being used.
Below is an example of the IO_MappingInput routine:
Figure 3 - Sample IO_MappingInput Routine
Version 7.0
Page 20 of 141
2.5.2. Digital Outputs
The IO_MappingOutput routine provides a centralized location for the mapping of the user discrete output
tags used in the machine logic to the physical digital outputs. The user output tags are defined as type
udt_Output. The output mapping is accomplished by mapping the .Output element of a user output tag to
its corresponding physical digital output. Simple interlocking of double solenoid valves MUST be located
in this routine. NO other interlocking is acceptable in this file. An Always False (AFI) instruction is mapped
to each unused or spare output. Below is an example of the IO_MappingOutput routine:
Figure 4 - Sample IO_MappingOutput Routine
2.5.3. Digital Output Qualifiers
The IO_OutputQualifiers routine provides a centralized location for the machine output definitions. The
results of the machine logic are qualified prior energizing a given output in this routine. This routine defines
the motion position, interlocking logic, and the automatic and manual behavior of a given output. Typically,
the automatic behavior will be the result of a sequence output request. In the Sequence_Main routine, the
step output branch will set a bit of the .Req DINT of the user defined output tag of type udt_Output (See
Section 2.10.2.2 Sequence Steps). The value of the .Req is compared to 0. If any bits of the word are set
the value will not be 0. If the value is not equal to 0 and the interlocks are satisfied the .Output field of that
tag is energized. The .Output bit is then mapped to the machines physical outputs in the
IO_MappingOutput routine (See 2.5.2 Digital Outputs).
There are three rungs associated with each output in the IO_OutputQualifiers routine: one to define the
motion position, one to define the safety conditions required to initiate and maintain an output, and one to
energize the output.
The rung that defines the motion position has a branch for each of the possible states of the motion being
controlled. (This is then used to drive the text in the multistate indicator under the push button on the HMI
see 4.6 Typical Button Object). For a motion with only one active position (Extended, Retracted, Raised,
Lowered, etc…) there should be two branches: one for the NOT of the active position (Not Extended, Not
Version 7.0
Page 21 of 141
Lowered, etc…) and one for the active position. For motions with more than one active position (Lift Raised
63Frame and Lift Raised 53 Frame) the number of branches should be equal to the number of active
positions plus one (for the NOT state). Each of these positions should be defined with logic so that only
one branch can be true at a time. Below is an example of a rung defining the state of a motion with two
active positions:
Figure 5 - Sample I/O State Indicator Routine

The rung relating to safety always comes after the indicator rung and precedes the output rung, and is
comprised of three branches. All logic pertaining to machine interlocks should be in this rung. Interlocks
should NOT be placed in the sequence of the machine or output mapping.
The first branch should contain the logic for setting the .SafeToInitiate bit. This logic pertains to defining
the safe conditions or interlocks for initiating the output in Auto or Manual, and is intended to allow the
operator to safely operate the machine and to prevent machine damage. These conditions shall only
consider if the motion is safe to initiate and should not be dependent on if the motion should occur next in
the operation of the machine. This branch should not take into account the sequence of the machine.
The second branch of the rung is used to energize the .SafeToMaintain bit. This bit is used to inhibit the
output once it has already been sealed in if it is no longer safe to maintain.
The third branch of the rung relates to the logic to energize the .pvAvail bit. This bit is used to enable
PanelView command control in Manual mode and is typically qualified by being in Manual mode, having
both .SafeToInitiate and .SafeToMaintain conditions satisfied, and NOT being in an active position of the
Version 7.0
Page 22 of 141
motion (see section 4.6 Typical Button Object). Below is an example of a rung defining the safe
conditions for an output:
Figure 6 - Sample IO_OutputQualifiers Routine
The output rung, as a minimum, contains the Auto and Manual conditions for a given output, with optional
conditions for Homing operations and Seal-In logic, if required. Below, the output rung is shown broken
down into its core components:
Auto Condition Branch – In the sequences outputs are requested by turning on a bit of the .Req
DINT. Each sequence step that requires the output to turn on will use a different bit. If one or more
steps are requesting the output to be on the DINT will have a non-zero value. A NEQ to a zero is used
in the auto condition branch to drive the output when it is safe to initiate and safe to maintain. After
the initial setup no further modifications are needed to this rung to turn on the output from a new step.
Manual Condition Sub-Branch – Manual requests to energize the output from the PanelView are
located here. This is only active when the machine is in manual mode. When using the .pvPB from
the HMI the .pvAvail should always be used as a software interlock to make sure that the motion will
not occur if it is not safe to initiate.
Homing Sub-Branch (Optional) – A NEQ is used here as is used in the auto branch to check for any
.HomeReq bits being set to request an output from the homing routine. This is only active when the
machine is in manual mode.
Seal-In Branch (Optional) – Seal-In logic is located here if the output is to remain energized through
multiple steps or if the output will remain energized after a PanelView request in manual mode. The
Seal-In branch will always be broken by a request from the opposing output. Notice that the seal is
only active in Auto mode unless the motion is in the active position. This is to break a seal in if auto
mode is lost during a motion. It also permits a seal in to remain active if a motion is in the active
Version 7.0
Page 23 of 141
position when auto mode is lost or an E-Stop is pressed. If the machine drifts out of the active position
during an E-Stop the seal in is also broken so the machine will not jump when power is restored.
Auto Conditions Branch:

NEQ Comparison to the Output
Request DINT is placed here.
Manual Conditions Branch:

PanelView requests for the manual
operation of the output are placed
here.
Homing Sequence Branch:

Optional branch to handle output
requests from the Homing Sequence.
Seal-In Branch:
Optional branch used if output is to
remain energized through multiple
steps, or through a manual
command.
Figure 7 - Illustration of Branches in Output Rung
Version 7.0
Page 24 of 141
2.5.4. Analog Inputs and Outputs
Analog Inputs and Outputs are scaled and mapped using the Add On Instructions, AOI_AI_SCALE and
AOI_AO_SCALE, respectively. Physical Analog IO points should be mapped to these instructions and
placed in the IO_MappingInput and IO_MappingOutput routines. As with other I/O logic in these routines,
the analog cards should be separated using a NOP comment rung detailing the addressing and part number
information for the card. These instructions provide the following tags:
.Raw Physical Analog IO point

.RawMax Raw Input Max Value
.RawMin Raw Input Min Value
.EngineeringMax Scaled Engineering Value at the Raw Max Reading
.EngineeringMin Scaled Engineering Value at the Raw Min Reading
.Gain Gain
.Offset Offset
.EngineeringValue Live Scaled Engineering Value of the Raw analog Input
The RawMax, RawMin, EngineeringMax, EngineeringMin, Gain, and Offset tags can be written to using
MOV instructions so that mastering/calibration can be programmed to be done automatically with known
hardware. Function Block programming should NOT be used to scale Analog Inputs and Outputs.
Figure 8 – Output Analog Scaling
Figure 9 – Output Analog Scaling
Version 7.0
Page 25 of 141
2.6. Alarm Handling

The Faults_Main routine provides a centralized location for the machine alarm definitions. Alarms can be broken
down into four subsets: Sequence Step Timeout Alarms, I/O Faults, Machine Motion Faults, and Station Faults.
There are 600 alarms provided in the machine alarm structure, udt_MachineAlarms. This structure is designed
to accommodate a machine with up to 5 sequences with 60 steps each:
Alarms 0 - 59 Are Reserved For the Main Sequence Step Timeout Faults
Alarms 60 - 119 Are Reserved For the Second Sequence (Pre-stop) Step Timeout Faults
Alarms 120 - 179 Are Reserved For the Third Sequence Step Timeout Faults
Alarms 180 - 239 Are Reserved For the Fourth Sequence Step Timeout Faults
Alarms 240 - 299 Are Reserved For the Fifth Sequence Step Timeout Faults
Alarms 300 - 349 Are Reserved For I/O Disagreement Faults
Alarms 350 - 399 Are Reserved For Station Faults
Alarms 400 - 499 Are Reserved For Motion Faults
Alarms 500 - 559 Are Reserved For Home Sequence Step Timeout Faults
Alarms 560 - 567 Are Reserved For WIP and Schedule Data Alarms
Alarms 568 - 599 Are Reserved For Emerson Use Only
Step Faults are handled using AOI_STEP. (See 2.6.1 Step Timeout Alarms)
Other Alarms are implemented by using the Add On Instruction (AOI_FAULT). The AOI_FAULT is imbedded in
the udt_FAULT user defined type. For each alarm a tag of the type udt_FAULT should be created. The
AOI_FAULT has the following requirements:
FaultTrigger Number corresponding to the Fault Trigger in the alarm array that will be used
by this fault
Description Description of the Fault that will be displayed on the HMI when the Fault occurs
MachineAlarms Machine Alarms tag that the instruction will trigger faults of
FaultTime Step Fault preset value in milliseconds
The conditions to trigger the fault should be added to the rung preceding the AOI_FAULT instruction. When
those conditions are true the fault will begin to time. After the time has elapsed the fault becomes active. When
the fault is active the .FaultActive bit of the AOI and theTrigger bit of the corresponding MachineAlarms array
position will turn on. (The trigger bits of the alarms are already preconfigured in the HMI and will not need to be
connected by the programmer for a standard machine.) The fault will remain active until a command is received
from the PanelView (“MachineAlarms.pvClear”) to clear the alarm. If the conditions for the fault are still true it
will remain active even if a reset is received.
All fault AOIs should have the description “Description” updated to correctly describe the fault being created.
Version 7.0
Page 26 of 141
The .Description tag of each udt_Fault should be set to the description that should be displayed on the
HMI when the fault is active. The description array elements are to be used as follows:
.Description[0] English Description

.Description[1] Local Language Description
Descriptions are limited to 39 characters so that they fit correctly on the HMI.
The type of the alarm does not need to be included in the description as it is already preconfigured in the HMI.
See below for the types of alarms and examples of descriptions:
I/O Disagreement Faults “Lift Raise & Lower Prox”

Station Faults “Master Control Relay Not OK”
Motion Faults “Pallet Lift Not Raised”
Version 7.0
Page 27 of 141
2.6.1. Step Timeout Alarms
Step Timeout Alarms are implemented by using the Add-On Instruction (AOI_Step). The AOI_Step is
imbedded in the udt_Step user defined type. When using the udt_Step to create a step, the AOI_Step for
that step is automatically created in the data table.
The parameters of the AOI_Step instruction should be set as follows:
AOI_STEP Set to the AOI_STEP tag created when creating a new tag using
udt_STEP. It should include the .AOI extension of the tag.
Stp Constant set automatically by the AOI_STEP Logic (.AOI.Stp)

Description Set to the Description of the Step.
Sequence Set to the sequence that the step is a part of.
MachineAlarms Set to the machine alarms tag for the machine.
FaultTimeOut Set to the time (in ms) for the Step Fault Time.
FaultTrigger Set to the fault trigger that the Step fault will use.
FaultActive Bit active if the step Time out.
DisableFault If Bit active the Step will not fault even if conditions are met
The Timeout Timer is initiated when the machine first enters the given step in the sequence. If the machine
stays in that step of the sequence for longer than is provided for by the FaultTimeOut, the machine will
fault. The fault will remain until a command is received from the PanelView (“MachineAlarms.pvClear”) to
clear the alarm.
All machine sequence steps need to have an associated step timeout alarm. It is CRITICAL that
AOI_STEP instructions be placed in the correct order as required by the sequence as these instructions
will also automatically set the value of the step constant used in the sequence file. In order for this feature
to work correctly It is necessary to place a MOVE instruction in the rung of the first step of each sequence
to set the .StepAssignment for that sequence to -1. This is only required in the first step (step 0).
Any steps that should not have an associated step fault should still be included in the logic but be disabled
(necessary when a step is operator dependent) by adding logic to the second branch of the rung to set the
.AOI.DisableFault bit. (For a step that will always have its fault disabled all logic can be removed.) Toggling
the MachineAlarms.DisableStepAlarm tag disables all step faults to allow for debug of the machine.
See Figure 10 - Sample Sequence Step Timeout Alarm for an example of a Step Time Out.
Version 7.0
Page 28 of 141
Figure 10 - Sample Sequence Step Timeout Alarm
The Description of the Step (“c_STEP_NAME”) in the tag database should also be entered so that the
instructions are commented correctly in the ladder logic (See Figure 11 – Comment AOI_Step in
Tag Database). Do not comment the .Description[2] or .AOI of the array tag individually as these will
be automatically filled in when the description for the base array tag is entered.
Figure 11 – Comment AOI_Step in Tag Database
The .Description tag of each step should be set to the description that should be displayed on the HMI
when the sequence is in that step. This will allow the correct step description to be displayed on the HMI.
The description array elements are to be used as follows:
.Description[0] English Description

.Description[1] Local Language Description
See Figure 12 – Add Description to udt_Step. Descriptions are limited to 39 characters so that
they fit correctly on the HMI.
Version 7.0
Page 29 of 141
Figure 12 – Add Description to udt_Step
2.6.2. I/O Faults
I/O Faults are faults that occur when machine sensors report an invalid condition. In the example shown
below, if the DI_PalletLiftLowered.InDbncd is active and one of the lift raised inputs,
DI_PalletLiftForShell53Raised.InDbncd or DI_PalletLIftForShell63Raised.InDbncd, is also on then the
alarm will be active. Any Input that has a logical opposite that should never be on at the same time should
have an I/O Fault associated with it.
Figure 13 - Sample I/O Fault Rung
2.6.3. Machine Motion Faults
Machine Motion Faults are faults that occur when the machine fails to complete a motion in a specified
time period. In the example shown below, the Lift Raise output, DO_LiftRaise.Output, is energized and if
neither raised inputs, DI_PalletLiftForShell53Raised.InDbncd or DI_PalletLIftForShell63Raised.InDbncd is
made within 10 seconds, a motion fault will occur. Machine Motion faults should typically only be active in
Auto mode or when homing. All machine motions that have feedback on its positions should have an
associated machine motion fault. Be sure to set the Fault Time preset lower than any step fault that may
be requesting the motion to occur. It is important that motion faults turn on quicker than the associated
step fault for debug purposes.
Figure 14 - Sample Machine Motion Fault Rung
Version 7.0
Page 30 of 141
2.6.4. Station Faults
Station Faults are faults that occur from a single input that monitors an operational condition of the
machine. Some examples of this would be E-Stop inputs, High and Low pressure monitoring, control
power, etc... In the example shown below, when the guard door is opened, input
DI_GuardDoor1Open.InDbncd is active, a station fault will occur.
Figure 15 - Sample Station Fault
2.6.5. Machine Alarm to PanelView Interfacing
Alarms are triggered in the PanelView Plus using the tag MachineAlarms.Alarm[x].Trigger, where x is equal
to the alarm number. The trigger tag is sealed within the logic of AOI_STEP and AOI_ALARM when the
conditions for the alarm are met for the given time. This seal can only be broken by pressing the Alarm
Clear push button on the PanelView (MachineAlarms.pvClear). The tag, MachineAlarms.ActiveAlarm, is
used as an index pointer that holds the integer value relating to the last active alarm found in the file. For
instance, if MachineAlarms.Alarm[12].Trigger is set, then MachineAlarms.ActiveAlarm will be set to 12 by
moving a 12. A value of 12 will be retained until the cleared or replaced by a larger numbered alarm.
AOI_STEP and AOI_ALARM handle updating the MachineAlarms.ActiveAlarm for an active fault. The
figure below shows the implementation of the logic for clearing the MachineAlarms.ActiveAlarm tag. This
can be found at the end of the Faults_Main file. No changes should be necessary by the programmer for
this logic.
Figure 16 - Rungs for Faults and Panelview Interface

Version 7.0
Page 31 of 141
2.7. Operator Notification Handling

The template provides code to make use of the standard Information functionality of the HMI. We refer to these
as Operator Notifications. Notifications will pull up a display on the HMI for the operator with information or
instructions to make the operation of the machine clearer. These notifications do NOT stop the normal
processing of the equipment. The Notifications_Main routine provides a centralized location for the operator
notification definitions.
Notifications are implemented using an AOI (AOI_NOTIFICATION) which is imbedded in the UDT
udt_Notification. When creating a Notification create a new tag with the type udt_Notification and the AOI will
be automatically created.
Notification status is stored in the structure under the MachineNotifications tag of the type
udt_MachineNotifications. This already exists in the template and does not need to be created by the program
developer. This structure is designed to accommodate up to 31 Notifications (1-32 Notification 0 cannot be
used).
Conditions for determining when a notification should be active are placed to the left of the notification AOI.
When true the notification will trigger after the NotificationTime_PRE time has expired.
The Notification AOI was written to be configurable and allow the program developer to select how it will function
based on the needs of the process. Configuration of the AOI is done by changing input parameters. The two
base types of configurations for the notifications are Require Acknowledge and Automatically Clearing.
2.7.1. Acknowledged Notifications
Acknowledged notifications use the MachineNotifications.Acknowledge.pvPB push button to clear the

notification. Pressing this button will cause the Notification Silence Timer to be enabled.
While the silence timer is timing the notification is disabled even if the conditions are still true for the
notification.
The Notification AOI is set up so that only the active Notification (MachineNotifications.ActiveNotification)
will be cleared when the Acknowledge PB is pressed. Only one Notification is cleared each time the
Acknowledge PB is pressed.
2.7.2. Automatically Cleared Notifications
Automatically Clearing Notifications are cleared when the trigger for the notification is lost. Automatically
clearing the Notification causes the Silence timer to become enabled.
While the silence timer is timing the notification is disabled even if the conditions become true again for
the Notification.
2.7.3. Notification Description Text
Version 7.0
Page 32 of 141
The program developer is responsible for entering the descriptions for each notification. The descriptions
for the notifications are located in the Notification UDT. The .Description[0] and [1] should be entered in
order for the correct Notification Message to appear on the HMI.
[0] - English text for the Notification

[1] - Local language text for the Notification
Figure 17 – Add Description to Notification
2.7.4. Notification AOI Parameters
Figure 18 – AOI_NOTIFICATION
Notification Parameters:
NotificationNumber - The number on the MachineNotifications.Notification[x] array that will be enabled

when the notification is triggered (1-32).
Description – Description Tag used for Notification.
Notification - Notification Tag used for Triggers.
NotificationTime_PRE - Preset time for notification to trigger after the Notification conditions are true.
SilenceTime_PRE - Preset time that the notification will be silenced after the notification is acknowledged
or automatically cleared. During this time even if the conditions are true the notification will not be active.
AcknowledgeEnabled (BOOL 0 or 1) - Allows the Acknowledge PB on the Notifications Pop-Up Display

to be available for pressing. When pressed the notification is acknowledged and silenced for the duration
of the “SilenceTime_PRE” even if the conditions are still true. This must be set if the “Require
Acknowledge” option is set.
Version 7.0
Page 33 of 141
AutoClear (BOOL 0 or 1) - If the conditions for the notification are not true the notification will automatically
clear itself and the pop up display will clear from the HMI. “Require Acknowledge” cannot be set if “Auto
Clear” is set. It is up to the program developer if the “AcknowledgeEnabled” option is selected. If it is not
then the only way to clear the notification will be for the conditions to clear.
Require Acknowledge (BOOL 0 or 1) - The Notification will remain triggered even if the notification
conditions are not true. Will require the operator to press the acknowledge button. After pressing the
acknowledge button the notification is silenced even if the notification conditions are still true. “AutoClear”
cannot be enabled when “RequireAcknowledge” is. “AcknowledgeEnabled” must be set when
“RequireAcknowledge” is set.
2.8. Constants
Any number or string that is being compared to or used, that does not change, should be assigned to a tag.
That tag should then be used throughout the program as a constant. Constants are used to make the program
more readable and easier to understand.
The Config_Constants routine provides a centralized location for the definition machine specific constants for
the program developer to use (user defined constants). Any constants that are used by the machine logic are
to be added here as individual tags, with the tags used in the machine logic in place of literal values. Along
with the machine constants, this routine contains the definitions for the machine address constants, machine
tooling constants, and any PanelView Plus pushbutton indicator constants.
All user defined contestants should start with a lower case “c_”. The rest of the constant should be in all
capital letters.
c_CONSTANT_NAME
2.8.1. Machine Address Constants
The machine address constants are contained in c_StationName_STATION_INDEX and

c_CONFIGURATION_CONTROL_MASTER_INDEX. The values contained in these tags define the
addressing for the station within the Configuration Control System. The values for these tags will be
provided by an Emerson representative. In the logic shown below, the station index is set to a value of
‘60’ and the configuration control master index is set to a value of ‘4’. These are set in the
Config_Constants routine.
Version 7.0
Page 34 of 141
Figure 19 - Rungs Setting Machine Address Constants
2.8.2. Step Constants
The step constant is an .AOI.Stp INT of a user-created tag of the type udt_Step. All udt_Step tags
should be prefaced by “c_STEP”, denoting that it is a constant and a step. Like other constants, all
letters beyond the initial “c_” should be capitalized.
c_STEP_LIFTPALLETOFFCONVEYOR
If the step is not in the main sequence, the sequence name should be included in the constant as well.
c_STEP_PRESTOP_WAIT_PALLET_IN_POSITION
The constant values of the .AOI.Stp fields of each udt_Step tag are assigned automatically in the
AOI_FAULT logic.
2.8.3. Machine Tooling Constants
The machine tooling constants are defined as individual tags, typically of the type DINT. There are three
types of tooling constants, tooling required, tooling correct, and tooling in error. The tooling required
defines the required tooling for a model that is processed at the station and follows the naming
convention of having a prefix of ‘c_TOOLREQ_’ followed by a description of the model, e.g.
c_TOOLREQ_FRAME53, which indicates the tooling required for a size 53 frame compressor. The
tooling correct constant is used to indicate that the correct tooling is in place for the model that is
processed at the station and follows the naming convention of having a prefix of ‘c_TOOLCORR_’
followed by a description of the model, e.g. c_TOOLCORR_FRAME53, which indicates the tooling is
correct for a size 53 frame compressor. The tooling in error constant is used to indicate the tooling is not
correct for the current model that is being processed and follows the naming convention of having a
prefix of ‘c_TOOLERR_’ follows by a description of the model, e.g. c_TOOLERR_FRAME53, which
indicates the tooling is not correct for a size 53 frame compressor. Below are shown examples of tooling
constants assignments.
Version 7.0
Page 35 of 141
Figure 20 - Sample Machine Tooling Constants
Version 7.0
Page 36 of 141
2.8.4. Common Constants
A set of constants have been created and predefined for use in indicating common statuses. The
constants include machine position, compressor status, and Configuration Control constants. They are
defined in the routine System_Assign_CommonConstants. The system tag ‘c’ of type
udt_CommonConstants has been created to store the values for the constants. These values are not to
be modified by the developer without the written permission of ECT. A full list of the common constants
can be found in Error! Reference source not found. (udt_CommonConstants). Below is an example of t
he logic.
Figure 21 - Sample Machine Tooling Constants
2.8.5. Motion Status Constants
Motion status constants are used to drive the indicators on the PanelView pushbuttons (See section
2.5.3 Digital Output Qualifiers). Most motion status constants have been predefined with the common
constants. These constants should be used whenever possible. In cases where a common constant
has not been defined for the motion status needed a user defined constant should be created and
Version 7.0
Page 37 of 141
assigned a value in the Config_Constants program file. Examples of user defined motion status
constants can be found below.
Figure 22 - Sample Panelview Pushbutton Indicator Constants
2.9. Station Scanner Interface
The Control_XXXXX_Scanner routine contains the logic associated with the triggering of the bar code scanner
when a part is detected at the station pre-stop. There are currently 2 versions of scanner logic. One is
“Control_Banner_Scanner” and is used if the Scanner type is a Banner Barcode Reader. The other scanner
routine is Control_Cognex_Scanner” and is used for Cognex bar code readers. Simply delete the routine that
you are not using. The Scanner logic will trigger the scanner regardless which routine you use. Set one of the
“StationName_TriggeBarCodeReader.Req(X)” Bits where X is an unused bit in the “.Req” word. The routine
will trigger the scanner, verify the data is valid, and move the data into the respective “.Model & .Serial”
locations in the station compressor UDT. There should be no reason to modify any of the logic in this routine.
The remaining logic is to be used “as-is”.
Version 7.0
Page 38 of 141
2.9.1. Scanner Trigger and Re-Trigger Logic
The scanner trigger logic handles the triggering of the bar code scanner. When a pallet with a part is
detected at the station and the station is in auto or bypass mode and the sequence is in cycle, the
StationName_ScannerData.Trigger flag is set. This flag will initiate a scan. If the data is not received or
is not correct the logic will retrigger a Rescan. The system will rescan “X” number of times where X is
determined by the value in “StationName_BarCodeReader.ReadFailCount_Counter.Pre”. If there is still
no valid data after “X” number of scans the Routine will generate a station fault. The fault will not trigger
until the main station stop is empty to insure it does not interrupt a part in process.
Figure 23 - Scanner Trigger & Re-Trigger Logic
2.10. Sequential Logic

The core programming applied to machine control will be conducted using a standard, structured
implementation of sequential logic. This sequential architecture is to be implemented when machine control
naturally follows any number of given sequential steps.
Care should be taken not to apply sequential logic to simple, non-sequential operations. Permission must be
received in writing from Emerson in order to not use sequential logic.
Sequential logic will be implemented using the data type udt_MachineSequence, and a formal ladder
structure.
2.10.1. Sequence UDT
The Sequence UDT, udt_MachineSequence, is designed to provide the vast majority of variables and tags
required to implement the sequence ladder logic.
A sequence tag of type udt_MachineSequence and a corresponding routine should be created for each
sequential operation. The decision of how many sequences to use in a program should be based on
dependence. If two operations always occur in the same order (a pallet is lifted then the compressor is
transferred), there should only be one sequence. However, if two operations will happen at the same time
they should be separated into two separate sequences (Loading a Bearing at the same time a compressor
is lifted and fixture for pressing). Normally there should always be a main sequence. The main sequence
file should be named Sequence_Main.
Version 7.0
Page 39 of 141
2.10.2. Sequence Ladder Structure
A formal ladder structure is to be utilized when implementing sequential control. The Standard
Development Template will provide much of this structure for the main sequence, requiring the developer
only to fill in certain rungs. The general structure includes a header section featuring general internal
control functions for the sequence itself, followed by groups of steps.
2.10.2.1. Sequence Control Header
The “Sequence Control Header” refers to the group of rungs at the beginning of the Sequence_Main
routine (as well as any secondary sequences) that control the operation and advancement of the
sequence. The Sequence Control Header contains several components necessary to the function of
the remaining Sequence_Main logic. With the exception of machine specific start conditions and
inputs, the logic contained in the Sequence Control Header should be used “as-is” with no
modifications to the logic without written approval from Emerson, Inc.
Sequence In Cycle
The first rung of the Sequence Control Header, typically Rung 1 in Sequence_Main, defines the
.InCycle bit. The .InCycle bit serves as a qualifier necessary to nearly every rung in Seq_Main. The
sequence is considered “in cycle” in the following conditions; The sequence is in automatic and
started (SeqMain.Start = 1), The sequence is in automatic and in single step mode
(SeqMain.SingleStep = 1), or The machine is in bypass mode (Machine.Bypass = 1). Below shows
the typical conditions for the .InCycle in most machines.
Figure 24 -Sequence Main InCycle Rung
Sequence Advance Control
The second rung of the Sequence Control Header, typically Rung 2, is the “Sequence Advance
Control” which involves setting the .Advanced bit. This bit serves as an indicator that the currently
Version 7.0
Page 40 of 141
active step needs to change, and it is permitted to continue to the next or Jump to another step of
the sequence. Example logic for setting the .Advance bit is shown below:
Figure 25 -Sequence Advance Control
The .ActiveStep tag is a SINT that is equal to the step number that the sequence is currently in.
The .AdvanceStep is an INT that is normally equal to the .ActiveStep, however, when a step is
complete it is incremented to the value of the next step. This indicates that the sequence can
advance to the next step.
The .JumpStep is an INT that is normally equal to the .ActiveStep, however, when the conditions are
correct for the sequence to jump to a different step (forward or backward) its value is changed to the
value of the step that is to be jumped to.
The .SingleStep branch is used when the sequence is placed into single step mode, requiring that
the “Step Advance” push button be pressed on the HMI in order to allow the sequence step to change
(advance or jump). In some cases something in the sequence occurs that requires the bypass of
the “Step Advance” push button because the conditions to advance the step would clear themselves
if the button is not pressed at the correct time. An example of this is pallet motion on the conveyor
(the pallet could move off of a prox that is needed to complete a step before the button is pressed).
In this case EQU instructions should be used to bypass the “Step Advance” push button.
Step Incrementing
The third rung of the Sequence Control Header, typically Rung 3, is called the “Step Incrementing”
rung. It is used to handle the changing of the Active Step pointer to the next or jumped to step. If
the .Advance bit is set, then either the .AdvanceStep or the .JumpStep are different then the
.ActiveStep. The one that is different is copied to the .ActiveStep in order to continue the sequence
from that step. If they are both different the logic will use the .JumpStep value. Along with updating
the .ActiveStep the .JumpStep or the .AdvanceStep are also updated. These three pointers should
Version 7.0
Page 41 of 141
always be at the same value unless a change in step is needed. Example code for this action is
shown below.
Figure 26 - Step Incrementing Rung
The top branch is used to allow a programmer to manually change the value .ActiveStep and have
the program follow correctly. This case should only occur when someone is forcing the number to
change for debug purposes.
Sequence Reset
The next rung involved in the Sequence Control Header, typically Rung 4, is the “Sequence Reset”
rung. This handles resetting the .ActiveStep step pointer back to zero when the sequence is
complete. It also resets the .ActiveStep when the machine is in auto but not in cycle and is Ok to
stop, the machine is in manual and home, or it is the first scan of the program. This ensures that the
machine never loses track of its place in the sequence, and enables a new cycle to start once the
previous cycle has completed or has been terminated for any reason. Along with clearing the
Version 7.0
Page 42 of 141
.ActiveStep the .AdvanceStep and .JumpStep are also cleared. Example code for this action is
provided below.
Figure 27 - Sequence Reset Rung
Sequence Start Conditions
The next rung of the Sequence Control Header, typically Rung 5, is the “Sequence Start Conditions”
rung. This handles the general sequence start requirements. As can be seen in the example code
provided below, for each machine there could be a set of conditions that need to be met in order for
the machine sequence to execute. Typically, the machine will remain in the Not Ready step of the
sequence until these conditions are met. The program developer should fill in these conditions based
on the requirements of the machine. These are NOT the requirements for the equipment to go into
cycle but are requirements for the sequence to continue past step 0. In the example below the Pre-
Stop Sequence is help at step zero if a machine stop has been requested.
Figure 28 - Sequence Main Evaluate Start Conditions Rung
2.10.2.2. Sequence Steps

This comprises the core of the sequence logic. Here the developer defines what outputs are
energized during a step, what actions are taken within a step, and what conditions must be met
in order to transition to the next step.
Each step shall follow the same general organizational structure. Where it is feasible, steps shall
be accomplished in a single rung.
Version 7.0
Page 43 of 141
Step Conditioning
Each rung of logic relating to a given step in a sequence should be qualified by two conditions,
the first of which being that the machine is in cycle. The second qualifying condition is an EQU
instruction comparing the Active Step to the step constant. The only step that is active is the
step that has a step constant equal to the SeqMain.ActiveStep. These are the only instructions
normally permitted on the left side of a step rung. All other instructions are included in branches
on the right side of the rung.
Output Branch
If outputs are required in a step they should be located in the top branch on the right side of the
rung. Outputs are enabled in a step by inserting an OTE coil of the output request bit. Two
Request DINTs are included in the tag created when naming an output using the output UDT
(udt_Output), one for use in machine sequences (.Req) and one for use in the Home sequence
(.HomeReq). Each step where the output is to be turned on should have a different bit of the
request word selected so that there is only one OTE instruction for each bit of the DINT.
However, it is not always necessary to include a Request Bit for each step an output should be
on. This only needs to be done if the seal in branch in the Output_Qualifiers routine is not used,
or the output is not yet in its fully active position (moving beyond the step before the motion is
complete) for the given output (see section 2.5.3 Digital Output Qualifiers).
Figure 29 - Example Sequence Step Rung with Output
Version 7.0
Page 44 of 141
Figure 30 - Example of Using .Req.x in Multiple Steps
Sequence Jump Branch
In some cases, steps contain logic additional to outputs and step completion conditions. For
instance, some steps require moving to a non-consecutive step if certain conditions exist. In
such a case, and where feasible, another branch should be added to the right side of the step
rung. This branch will always be located above the Step Transition branch and normally below
any output branches (if they exist).
In order to jump to a different step the step constant of the step being jumped to should be
moved into the .JumpStep tag. In the example shown below, if an empty pallet is detected, the
Version 7.0
Page 45 of 141
sequence will ‘jump’ to the c_STEP_PRESTOP_CHECK_READY_FOR_PALLET.AOI.Stp step

to wait for the main sequence to be ready for the empty pallet.
Figure 31 - Example Sequence Step Rung with Jump
If outputs or Jumps do not exist for that step, a NOP instruction shall be placed on a branch
above the step transition branch in order to maintain the step rung’s overall structure.
Figure 32 - Example Sequence Step Rung without Output or Jump
Step Transition Branch
The bottom branch on the right of the step rung should always contain the step transition
(complete) requirements. Step transition causes the Active Step pointer to increment to the
next step. Step transition is accomplished by adding 1 to the .ActiveStep and placing it in the
.AdvanceStep tag. Each step in a sequence will use and ADD instruction with identical
parameters.
2.10.2.3. Final Step

Each sequence contains a designated final step. The final step is used to reset the sequence in
the Sequence Reset Rung. Normally the Final Step performs no output of logic function. The only
exception to this is the Final Step of the Main Sequence. This step only performs a
Version 7.0
Page 46 of 141
RecordCycleDataReq (updates Cycle information to Configuration Control) and has no outputs.

The logic for the Final Step is shown below.
Figure 33 - Final Step
2.10.3. Sub Sequences
Secondary sequences should be linked to other sequences based on the Active Step of the sequence
being linked to, therefore, no calls from any sequence to another are needed. The program developer may
use EQU, LEQ, GEQ, LES, GRT, and LIM instructions to accomplish the comparison. In the example
provided below, the Pre-Stop sequence waits before releasing a pallet into the station until the main
sequence Active Step is equal to a step that indicates it is ready to receive a pallet.
Figure 34 - Example Second Sequence (or SubSequence) Step Rung
2.11. Non-Sequenced Control and Safety
As mentioned above, the developer is required obtain written approval to utilize non-sequential logic for any
operation. Indeed, some simple operations of a non-sequential nature are more easily managed with state
based ladder logic. Such control would be coded within a routine using the “Control_” prefix. If the non-sequential
Version 7.0
Page 47 of 141
logic does not warrant a file of its own the logic can be placed in Control_Async. Please use a comment rung
to separate rungs of non-sequential code based of function.
2.11.1. Standard Asynchronous Logic
The program developer is responsible to condition the ”StationName_WIPData.PalletInStation” tag in

Control_Async. This tag is used by the System routines to determine if there is a pallet present in the
station.
Figure 35 – Pallet in Station Qualifiers
The program developer is also responsible to replace the qualifiers for the “StationName_Ok_to_Run” tag.
This tag is normally left with just the “MachineAlarms.FaultsPending” qualifier shown below; however, there
may be times that the programmer needs to add more conditions.
Figure 36 – Ok to Run Qualifiers
2.11.2 Safe Entrance into a cell

Fortress Interlock shall only be used in work stations entrances where a person can walk into the cell.
The functionality of the Fortress Safety system shall be as follows in the AUTO and Manual Modes:
1. Operator presses the Green button to request to enter the cell, the Green light of the button will blink
until is safe to Enter. Once is safe to Enter the Green light will stop blinking and remain ON.
The cell must be designed so that the Green button acts the same as a cycle stop request. All critical
operations of the sequences should complete to avoid making a reject part.
2. Operator removes one of the keys and can now enter the cell. From now on the Cell cannot be put on
AUTO Mode. When the door opens the Red light turns on. The operator must take the key they
removed with them into the cell.
3. If a second Operator enters the cell they will need to remove a key and take it with them into the cell.
4. After everyone has exited the cell the operator(s) will replace the keys and lock the cell.
5. Once the 3 keys are in, the operator will reset the Fortress system by pressing the Red button. This
will reset the fault and power the station back up, the Red light will go out.
A second method to open the cell door is by pressing the Green button (Request to Enter) for five
consecutive seconds, at the end of the 5 seconds the machine will stop without the machine going through
a cycle stop and the door can be unlocked.
A third method to open the cell door is if after pressing the Green Button (request to Enter) and the machine
does not reach a Safe to enter state after 45 seconds of pressing the green button the door will unlock
without holding the button.
Version 7.0
Page 48 of 141
2.12. Manual Control

The logic for Manual control of devices should be handled by the manual branches of the output rungs in the
IO_OutputQualifiers routine, (See section 2.5.3 Digital Output Qualifiers). Even if the output request is generated
in a Control file because it is based on a non-sequential control, there should still be a set of rungs dedicated to
the output in the output qualifiers.
2.13. Configuration Control Interface
The production line is composed of individual assembly stations. Each station is responsible for a portion of the
assembly process, either by the addition of parts to the assembly, performing an operation on the assembly, or
performing quality tests on the assembly.
Each station receives data in the form of a WIP / Model Reply message from the Configuration Control Master.
The WIP / Model Reply message contains operational parameters and tooling configuration data from the Model
Specifications table and the current compressor assembly’s status from the WIP table. If the station is configured
as a Live Load station (Station that displays component part information), the station will also receive schedule
and parts information from the schedule table in the form of a Schedule Reply message.
A typical station consists of a Pre-Stop and a Station-Stop. These are powered conveyor stops which temporarily
prevent a compressor assembly from moving forward so that some action may be taken. In the case of a Pre-
Stop, the compressor assembly is stopped so that the assembly’s tracking label may be scanned. At the Station-
Stop, the actual processing of the assembly occurs.
In the normal sequence of events, the assembly is scanned by the fixed head scanner located at the Pre-Stop.
Data is sent from Configuration Control to a data storage location for the Pre-Stop.
As the compressor is released from the Pre-Stop into the station the Pre-Stop data is copied into a second data
storage location for the compressor being processed in the station called Compressor.
Once the assembly is processed at the station, the station sends the results to the Configuration Control Master
in the form of a WIP Update message. The Configuration Control Master uses this data to update the assembly’s
status in the WIP table. This typically occurs just before the assembly is released from the station stop.
The following is a general sequence of data handling with the Configuration Control Interface in a standard
station.
2.13.1. Scan Barcode

• Incoming pallet stops at station Pre-Stop and the station detects the pallet at the Pre-Stop
• The station PLC triggers the barcode reader by setting
“StationName_TriggeBarCodeReader.Req.0”. The code to accomplish this is already provided in
the station template and is only included here for reference.
• The Barcode data is sent to the station PLC.
• The barcode reader is communicated with in the Control_Banner_Scaner or
Control_Cognex_Scanner routine depending on the brand of barcode reader used.
• Reading the barcode is initiated in the Pre-Stop sequence by setting the
StationName_TriggeBarCodeReader.Req.0 tag.
• This data is never cleared. It is only overwritten by the next barcode that is read.
Version 7.0
Page 49 of 141
• StationName_SerialModel.Request.TrackingLabel.Serial
• StationName_SerialModel.Request.TrackingLabel.Model
2.13.2. Serial Model Request

• The barcode data is sent to the Configuration Control Master in the form of a Model/Serial
Message.
• Model/Serial Message is created and sent in the System_Request_Serial_Model routine.
• Sending this message is initiated in the Pre-Stop sequence when the
StationName_SerialModel.Req tag is set.
• StationName_SerialModel.TrackingLabel.Serial
• StationName_SerialModel.TrackingLabel.Model
2.13.3. WIP Reply

• The Configuration Control Master looks up the data corresponding to the compressor serial
number. This is not a function of the Station PLC and is only included in this sequence for
reference.
• The Configuration Control Master sends tooling and compressor WIP information (Shell frame
size, shell length, and pass/fail status, etc…) to the station PLC.
• The message is received by System_Receive_WIP routine.
• Data is received into StationName_WIPData.FHReply tag structure. This data is never cleared. It
is only overwritten by the next message from the Master PLC.
• The code to accomplish this is already provided in the station template and is only included here
for reference.
• The following are the tags where the data is first placed when received from the Configuration
Control Master.
• StationName_WIPData.FHReply.Compressor.TrackingLabel.Serial
• StationName_WIPData.FHReply.Compressor.TrackingLabel.Model
• StationName_WIPData.FHReply.Compressor.Schedule
• StationName_WIPData.FHReply.Compressor.ScheduleItem
• StationName_WIPData.FHReply.Compressor.StationResults.OverallStatus
• StationName_WIPData.FHReply.Compressor.StationResults.StationEnabled
• StationName_WIPData.FHReply.Compressor.StationResults.ResultCode[0-63]
• StationName_WIPData.FHReply.Compressor.Parameter_DINT[0-9]
• StationName_WIPData.FHReply.Compressor.Parameter_REAL[0-9]
• The received WIP message is then copied into StationName_WIPData.PSData tag structure.
• This happens when the station PLC code in System_Receive_WIP detects that this is a new
message.
• The WIP data waits here for the program sequence to check for it.
for reference.
• This data is cleared when the station is in manual and there is no part present in the station. Part
presence in the station is determined by the StationName_WIPData.PalletInStation tag found in
the Control_Async routine.
• The following are the tags where the data is copied to while waiting on the sequence:
• StationName_WIPData.PSData.Compressor.TrackingLabel.Serial
Version 7.0
Page 50 of 141
• StationName_WIPData.PSData.Compressor.TrackingLabel.Model
• StationName_WIPData.PSData.Compressor.Schedule
• StationName_WIPData.PSData.Compressor.ScheduleItem
• StationName_WIPData.PSData.Compressor.StationResults.OverallStatus
• StationName_WIPData.PSData.Compressor.StationResults.StationEnabled
• StationName_WIPData.PSData.Compressor.StationResults.ResultCode[0-63]
• StationName_WIPData.PSData.Compressor.Parameter_DINT[0-9]
• StationName_WIPData.PSData.Compressor.Parameter_REAL[0-9]
2.13.4. Schedule Reply

• If a compressor that was scanned at the Pre-Stop is a new schedule from the previous
compressor scanned a Schedule Reply message will be sent from the Configuration Control
Master containing the Long Model Number and all the component parts needed for the operation
at that station.
• If the compressor is the same schedule as the previous compressor then no schedule message is
sent from the Configuration Control Master.
• StationName_ScheduleData.FHReply.Schedule.Model
• StationName_ScheduleData.FHReply.Schedule.Schedule
• StationName_ScheduleData.FHReply.Schedule.GroupIndex
•
• StationName_ScheduleData.FHReply.Schedule.Quantity
• StationName_ScheduleData.FHReply.Schedule.LongModel
• StationName_ScheduleData.FHReply.Schedule.CustomerAlpha
• StationName_ScheduleData.FHReply.Schedule.CustomerOrder
• StationName_ScheduleData.FHReply.Schedule.PartsCount
• StationName_ScheduleData.FHReply.Schedule.PartsList[0-9]
• The received WIP message is then copied into StationName_ScheduleData.PSData.Schedule tag

structure.
• This happens when the station PLC code in System_Receive_Schedule detects that this is a new
message.
• The Schedule data waits here for the program sequence to check for it.
for reference.
• The following are the tags where the data is copied to while waiting on the sequence:
• StationName_ScheduleData.PSData.Schedule.Model
• StationName_ScheduleData.PSData.Schedule.Schedule
• StationName_ScheduleData.PSData.Schedule.GroupIndex
• StationName_ScheduleData.PSData.Schedule.Quantity
• StationName_ScheduleData.PSData.Schedule.LongModel
• StationName_ScheduleData.PSData.Schedule.CustomerAlpha
• StationName_ScheduleData.PSData.Schedule.CustomerOrder
• StationName_ScheduleData.PSData.Schedule.PartsCount
• StationName_ScheduleData.PSData.Schedule.PartsList[0-9]
Version 7.0
Page 51 of 141
2.13.5. Update Schedule of the Station

• When the Pre-Stop sequence sets the StationName_WIPData.PSScheduleCheckReq tag in the
Check Schedule Step the new schedule sent from the Configuration Control Master is updated to
the schedule of the station if a new schedule is present.
• The current schedule information of the station can be accessed in this data structure.
• The code to do this is included in a System file and should not be updated by the programmer.
• StationName_Schedule.Schedule.Model
• StationName_Schedule.Schedule.Schedule
• StationName_Schedule.Schedule.GroupIndex
• StationName_Schedule.Schedule.Quantity
• StationName_Schedule.Schedule.LongModel
• StationName_Schedule.Schedule.CustomerAlpha
• StationName_Schedule.Schedule.CustomerOrder
• StationName_Schedule.Schedule.PartsCount
• StationName_Schedule.Schedule.PartsList[0-9]
2.13.6. Check the Status of the Pre-Stop Compressor
• While the compressor is at the Pre-Stop checks are performed based on the WIP data received
from the Configuration Control Master. The results of these checks are stored in the PS Pass Fail
Code.
• StationName_WIPData.PSDataResultsPassFailCode
• If the compressor passes all of the checks the PS Pass Fail Code is left at a Not Processed status
(0). If any of the checks fail then it is set to a Bypass (3) so that when the compressor is released
into the station for processing it is “remembered” that this compressor should be bypassed.
2.13.7. Copy Pre-Stop Data to Compressor Data
• Before the pallet is released from the Pre-Stop the data is copied from the Pre-Stop tag structure
to the Compressor tag Structure (Data for the Compressor in the station).
• The program sequence sets StationName_WIPData.PSDataXferReq. This is done in the Copy
Data to Compressor step in the Sequence_PreStop routine.
• Data is copied from StationName_WIPData.PSData.Compressor to StationName_Compressor
and StationName_WIPData.DataAvailable is set.
for reference.
• The following data locations are where the data is copied to in the sequence and should be used
when referencing the compressor in the program.
• StationName_Compressor.TrackingLabel.Serial
• StationName_Compressor.TrackingLabel.Model
• StationName_Compressor.Schedule
• StationName_Compressor.ScheduleItem
• StationName_Compressor.StationResults.OverallStatus
• StationName_Compressor.StationResults.StationEnabled
• StationName_Compressor.StationResults.ResultCode[0-63]
• StationName_Compressor.Parameter_DINT[0-9]
• StationName_Compressor.Parameter_REAL[0-9]
Version 7.0
Page 52 of 141
2.13.8. Populate Compressor Results

• At the same time that the Pre-Stop data is copied from the Pre-Stop tag structure to the
Compressor Tag Structure the Serial and model information of the Compressor Results tag
structure are populated from the Pre-Stop Model and Serial data.
• The Pre-Stop compressor status is also copied into the Compressor Results Pass/Fail code so
that the main sequence will know the results of all of the checks performed at the Pre-Stop.
• After the compressor has been released into the station and processed,
• StationName_CompressorResults.TrackingLabel.Serial
• StationName_CompressorResults.TrackingLabel.Model
• StationName_CompressorResults.PassFailCode
• StationName_CompressorResults.StationMode
• StationName_CompressorResults.CycleValues[0-9]
2.13.9. Setting Compressor Pass/Fail
• After the compressor has been released into the station the Compressor Results Pass/Fail code
(StationName_CompressorResults.PassFailCode) is used to determine if it should be processed
or not based on the value from the checks performed at the Pre-Stop. If it is determined that it
should not be processed (Determine Cycle Machine Step) then it is released as a bypass
compressor.
• If the compressor is to be processed the Compressor Results Pass/Fail Code is used to monitor
(“remember”) the status of the pallet or the compressor during the cycle. It should be set by the
program developer when the status of the compressor is known.
• After a compressor has been “Processed” (Changed in any way or measured) the Compressor
Results Pass/Fail Code should be set to c.PROCESSED (6). This is used as a flag to “remember”
that this compressor has been processed so that it will not be processed a second time in the
event of cycle stoppage.
• If the compressor rejects or fails the process the Compressor Results Pass/Fail Code should
immediately be set to c.FAIL (2). It is the program developer’s responsibility to set these. It
should be done within the sequence steps and not in a different program file.
• At the end of the Main Sequence the Disposition step will change a compressor that has been
processed to c.PASS (1).
2.13.10. Saving Cycle Values

• By the end of the cycle if there are any data points to be collected (forces, measurements,
pressures, times, etc…) the program developer should copy these into the Compressor Results
Cycle Values. This should be done within the structure of the sequence.
• The data should be saved in StationName_CompressorResults.CycleValues[0-9].
• These tags are double integers. Floating point values can be saved by using a copy instruction to
copy the float into the double integer. This will cause the resulting data to not look correct
because the format of the data is not right. However, Configuration Control has been designed to
know if these values are a float or an integer and display them correctly. Do NOT used a move
instruction when saving floating point as the data will not be saved correctly.
• The location of each data point should be coordinated with Emerson.
Version 7.0
Page 53 of 141
2.13.11. Send WIP Update

• Before the compressor is released from the station the results of the cycle need to be sent to
Configuration Control. This is accomplished by setting StationName_WIPData.SendUpdateReq in
the Log Data step in the Main Sequence. Doing this sends the Compressor Results data to the
Configuration Control Master.
• The logic for sending the message is contained in System_Update_WIPExt and should not be
modified by the programmer.
• Compressor Results tag structure data is first copied to the
StationName_WIPData.Update.CompressorResults tag structure. This is done in a System File
and should not be modified by the programmer.
• StationName_WIPData.Update.CompressorResults is never cleared and can be checked to see
what data was in the last message sent.
for reference.
• StationName_WIPData.Update.CompressorResults.TrackingLabel.Serial
• StationName_WIPData.Update.CompressorResults.TrackingLabel.Model
• StationName_WIPData.Update.CompressorResults.PassFailCode
• StationName_WIPData.Update.CompressorResults.StationMode
• StationName_WIPData.Update.CompressorResults.CycleValues[0-9]
• After the WIP data has been updated StationName_WIPData.MsgCompleted is set. This is done
in the System_Update_WIP routine. This bit indicates to the main sequence that the Log Data
step is complete. The code to accomplish this is already provided in the station template and is
only included here for reference.
• After the WIP update is sent the StationName_CompressorResults tag structure is cleared and is
not available to be used in the program.
Version 7.0
Page 54 of 141
Serial
Model
Request
2.12.2
Configuration Control Master PLC

WIP Table Model Table Schedule Table
WI WIP
P Upda
Schedule te
Reply Re
ply 2.12.
2.12.4
Serial Model Request FH Reply Schedule FH Reply WIP Update
StationName_SerialModel.Request StationName_ScheduleData.FHReply.Schedule StationName_WIPData.FHReply.Compressor StationName_WIPData.Update.CompressorResults
• .TrackingLabel.Serial • .Model • .TrackingLabel.Serial • .TrackingLabel.Serial
• .TrackingLabel.Model • .Schedule • .TrackingLabel.Model • .TrackingLabel.Model
• .Quantity • .Schedule • .PassFailCode
• .LongModel • .StationResults.OverallStatus • .CycleValues[0-9]
2.1 • .CustomerAlpha • .StationResults.ResultCode[0-63]
2.2 • .CustomerOrder • .Parameter_DINT[0-9]
• .PartsCount • .Parameter_REAL[0-9]
• .PartsList[0-9]
2.1
2.1
2.3
2.4
Compressor
Serial Model PS Schedule PS Data StationName_Compressor
StationName_SerialModel.Request StationName_ScheduleData.PSData.Schedule StationName_WIPData.PSData.Compressor • .TrackingLabel.Serial
• .TrackingLabel.Serial • .Model • .TrackingLabel.Serial • .TrackingLabel.Model
• .TrackingLabel.Model • .Schedule • .TrackingLabel.Model 2.12.7 • .Schedule
• .Quantity • .Schedule • .StationResults.OverallStatus
• .LongModel • .StationResults.OverallStatus • .StationResults.ResultCode[0-63]
2.1 • .CustomerAlpha • .StationResults.ResultCode[0-63] • .Parameter_DINT[0-9]
2.1 • .CustomerOrder • .Parameter_DINT[0-9] • .Parameter_REAL[0-9]
• .PartsCount • .Parameter_REAL[0-9]
• .PartsList[0-9]
Compressor Results
PS Pass/Fail 2.12.8 StationName_CompressorResults.
StationName_WIPData.PSDataResultsPassFailCode • .TrackingLabel.Serial
• .TrackingLabel.Model 2.12.11
• .PassFailCode
Barcode Reader • .CycleValues[0-9]
Schedule
StationName_Schedule.Schedule
• .Model Messages to and from Configuration Control
2.12.5 • .Schedule
• .Quantity
• .LongModel
• .CustomerAlpha
• .CustomerOrder Internal Station PLC Data Moves
• .PartsCount
• .PartsList[0-9]
Data Only Overwritten Never Cleared

Figure 37 – WIP Data Flow
Version 7.0
Page 56 of 141
2.14. User Defined Types
The configuration control interface template includes several UDTs used to implement a specific
functionality. There are base UDTs (UDTs used to create other UDTs) and composite UDTs (UDTs that
contain base UDTs). Also used in the creation of the UDTs are User Defined Strings. The user define
strings are denoted in all capital letters. The developer should not modify these standard UDTs. A
description of each UDT is given below:
Table 4 - User Defined Types

UDT Type Description
udt_Alarm Base Data structure handling the basics of alarming
udt_AnalogIO Base Data structure for handling analog inputs

Data structure used to control audible alarms and
udt_AudibleAlarm_BeaconLight Base
beacon/stack lights
Data structure serving as the status indication,
udt_BuildOver Composite
configuration, and control of build over
Data structure containing configuration elements of
udt_BuildOverConfig Composite
build over
Data structure containing status elements of build
udt_BuildOverStat Composite
over
Data structure used to handle configuration
udt_BuildOverElementConfig Base
characteristics of individual element build over
Data structure used to handle status characteristics of
udt_BuildOverElementStat Base
individual element build over
Data structure used for holding integer values of
udt_CommonConstants Base
constant common to all machines
Used to hold Compressor results and station
udt_Compressor Composite configuration data from the Configuration Control
Master
Used to hold Compressor results to be sent to the
udt_CompressorResults Composite
Configuration Control Master
Data structure used for handling machine dry cycle
udt_DryCycle Base
conditions
Message structure containing user definable data that
udt_GenericData Composite
is sent to the server
Message structure containing user definable data that
udt_GenericUpdate Composite
is sent to the server
Data structure containing operator override
udt_GroupOverrides Base
information
udt_Input Base Data structure containing discrete input data
Data structure for handling machine modes and
udt_Machine Base
timeouts
udt_MachineAlarms Composite Data structure for handling machine alarms
Data structure for implementing basic machine control
udt_MachineControl Base
and status indication
udt_MachineMetrics Base Data structure containing machine cycle information
Data structure handling primary and secondary
udt_MachineSequence Composite
machine sequences
udt_ManualControl Base Data structure handling basic manual on/off control
udt_MES Composite
Data structure for handling station and build over
udt_ModifyStationUpdate Composite
configuration data
udt_OEE Base
Version 7.0
Page 58 of 141
udt_Operator Composite Contains operator security information.

Data structure used to store and process operator
udt_OperatorData Composite
data
Message structure for operator reply message from
udt_OperatorReply Composite
the Configuration Control Master
Message structure for an operator security request
udt_OperatorRequest Composite
from the Station to the Configuration Control Master
udt_Output Base Data structure containing discrete output data
udt_Parts Base Data structure used for parts verification.
udt_PartsOverride Base Data structure used for parts verification.

Data structure used to store and process pass thru
udt_PassThruData Composite
data
udt_PassThruReply Composite Message structure containing scanner pass thru data.
Data structure used for collecting machine production
udt_ProductionData Base
data
Data structure used for local storage of machine
udt_ProductionDataStorage Base
production data
udt_ProductonEventData Base Data structure used for collecting machine event data
Data structure used for collecting machine production
udt_ProductionHour Base
data
Data structure for handling the behavior of PanelView
udt_PushButton Base
push buttons
udt_ScannerData Composite Data structure used to control scanner operation
Message structure for triggering the fixed-head
udt_ScannerTriggerRequest Composite
scanner
udt_Schedule Base Data structure used to hold schedule information.
Data structure used to store and process schedule
udt_ScheduleData Composite
data
Message structure for schedule reply message from
udt_ScheduleReply Composite
the Configuration Control Master.
Message structure for a schedule request from the
udt_ScheduleRequest Composite
Station to the Configuration Control Master.
udt_SequenceStep Base Data structure for sequence step status and control
Data structure for station configuration data passed
udt_StationConfig Composite
down from the Configuration Control Master
Data structure containing result information from other
udt_StationResults Base
stations on the assembly line
Data structure containing step number and time out
udt_Step Base
data
udt_TimeStamp Base Data structure used for time and date information
udt_Tooling Base Data structure used for tooling verification.

Data structure containing the serial and model number
udt_TrackingLabel Base
information
Version 7.0
Page 59 of 141
Message structure for compressor results update to

udt_WIPData Composite
the Configuration Control Master.
Message structure for WIP reply message from the
udt_WIPModelReply Composite
Message structure for a schedule request from the
udt_WIPUpdate Composite
Station to the Configuration Control Master.
2.15. Interface Routines
A set of standard program routines have been developed for the implementation of the Station
Configuration Control Interface. These routines are designed to be added to the station program with no
modification to the logic contained in each routine. Below is a list of the routines and their description.
Table 5 - System Routines Listing

Routine Description
Contains Logic for Assigning Integer Values to Common
System_Assign_CommonConstants
Constants
Logic for checking if messages are currently sending.
System_CheckMessageSending
Used for synchronizing messages.
Contains Logic for Evaluating This Station, Previous
System_Evaluate_BuildOver Station, and Overall Build Over. Interacts with these
steps in the Pre-Stop sequence.
Contains Logic for the Collection of Production Data. Is
System_Production_Data driven from logic set by the programmer in
Config_Production_Data.
System_Receive_OperatorExt Contains Logic to Process Operator Reply Messages
System_Receive_PassThru Contains Logic to Process Pass Thru Reply Messages
System_Receive_Schedule Contains Logic to Process Schedule Reply Messages

Contains Logic to Process Station Modification
System_Receive_StationConfig
Messages
System_Receive_WIP Contains Logic to Process WIP Model Reply Messages
Contains Logic to Send Operator Request Messages to
System_Request_OperatorExt
Contains Logic to Send Schedule Request Messages to
System_Request_Schedule
Logic to send a WIP request message to the
System_Request_Serial_Model Configuration Control Master that contains the serial and
model just scanned.
Logic to send single barcodes scanned with a hand
System_Request_StnHandScan
scanner to Configuration Control.
System_Schedule_Change_Data Logic to keep track of Schedule change statistics.
Contains Logic for Syncing Station Clocks to a Master
System_Time_Sync
Clock
System_Translation Logic to manage language changes from the HMI
Version 7.0
Page 60 of 141
Contains Logic to Collect Overall Equipment

System_Update_OEE
Effectiveness Data
Logic to send updates in operator login activity to the
System_Update_OperatorActivityExt
Send schedule change information to the Configuration
System_Update_Schedule_Change_Data
Control Master in the form of a Generic Message
Contains Logic to Send Compressor Status Messages to
System_Update_WIPExt
Contains Logic to Send Generic Data Collection
System_Update_Generic
Messages to the Configuration Control Master
System_Verify_Parts Contains Logic Required for Parts Verification
System_Verify_Tooling Contains Logic Required for Tooling Verification
2.15.1. System_Recieve_WIP
The System_Receive_WIP routine is responsible for processing WIP Model Reply messages that
are received from the Configuration Control Master. These messages are sent automatically when
an assembly has been scanned at the Pre-Stop (Fixed Head Scanner). When a new WIP Model
Reply message is received from the fixed head scanner, the data is moved to the pre-stop data
area in the station. The data will remain in the pre-stop data area until the assembly is moved into
the station processing area. When a new WIP Model Reply message is received from the hand
scanner, the data is moved directly into the station processing area.
2.15.2. System_Receive_Schedule
The System_Receive_Schedule routine is responsible for processing Schedule Reply messages

that are received from the Configuration Control Master. These messages are sent automatically
when the Configuration Control Master detects a schedule change or when the station submits a
request schedule message. When a new Schedule Reply message is received, it is held until the
assembly is moved into the station processing area. The new schedule information is then moved
to the station data area for use in parts verification.
2.15.3. System_Recieve_OperatorExt
The System_Receive_OperatorExt routine is responsible for processing Operator Reply messages

that are received from the Configuration Control Master. These messages are sent as a response
to a request for operator information from the station. The operator security data is used to enable
tooling and parts override requests as well as logging operators into and out of the station.
2.15.4. System_Recieve_PassThru
The System_Receive_PassThru routine is responsible for processing Pass Thru Reply messages
that are received from the Configuration Control Master. These messages are sent as a response
to the hand scanner processing a bar code that is not of the serial or model type. When a new
Pass Thru Reply message is received, it is moved immediately to the pass thru data area.
Version 7.0
Page 61 of 141
2.15.5. System_Receive_StationConfig
The System_Receive_StationConfig routine is responsible for processing Station Modification

messages that are received from the Configuration Control Master. These messages are sent as a
result of new station configuration data being received by the Configuration Control Master from a
configuration interface (Configuration Control Website or PC Application). When a new Station
Modification is received at the station level, the configuration elements of that message are written
to the necessary station tags.
2.15.6. System_Verify_Tooling
The System_Verify_Tooling routine is responsible for the station’s parameter and tooling mapping,
tooling verification, and tooling verification override functions. When compressor data is received
at the station, the enumerated parameters are mapped for use in the verification process. When
the actual tooling matches the requested tooling, the tooling confirmed flag is set. This indicates
that the proper tooling is in place for the current model. The tooling verification can be overridden
by an operator if they have the proper security.
2.15.7. System_Verify_Parts
The System_Verify_Parts routine is responsible for the parts verification at the station. When a
new schedule arrives at the station, the operator will use the hand scanner to verify that they have
the correct parts at the station for processing. Once the parts have been verified, the parts
confirmed flag is set. This indicates that the parts have been verified. The parts verification can be
overridden by an operator if they have the proper security.
2.15.8. System_Request_Schedule
The System_Request_Schedule routine is responsible for requesting schedule information on

demand from the station. When a request is made, the station will create the request message and
send it to the Configuration Control Master.
2.15.9. System_Request_Security
The System_Request_Securiyt routine is responsible for requesting operator security on demand

from the station. This is typically a response to an override request which requires an operator
login. When a request is made, the station will create the request message and send it to the
2.15.10. System_Update_WIPExt
The System_Update_WIPExt routine is responsible for sending the status of the assembly that was
processed at the station to the Configuration Control Master. This event occurs typically when the
Version 7.0
Page 62 of 141
assembly is released from the station. The Configuration Control Master will use this data to
update the assembly’s WIP record in its local WIP table.
2.15.11. System_Production_Data
The System_Production_Data routine is responsible for the collection of the performance statistics
of the machine. The machine data is collected for the current machine cycle and hourly.
2.15.12. System_Update_Generic
The System_Update_Generic routine is responsible for the collection of user-defined general data
from the station. Data that is collected using the generic data collection message is sent to the
server for storage.
Version 7.0
Page 63 of 141
2.16. Standard Sequence Steps

Parts of both the Pre-Stop and Main sequences in the standard template contain standard
sequence logic developed by Emerson. The standard logic handles conveyor traffic, compressor
barcode scanning, Interface with Configuration Control, parts and tooling verification, Build Over
(station dependency) evaluation, and determining if the part is to be processed at the station.
These steps are not to be removed or modified without written permission of Emerson. These
steps may be bypassed during debug of the machine if necessary.
2.16.1. Pre-Stop Sequence Standard Steps
“Not Ready Step”
The “Not Ready Step” checks for the Start Conditions of the sequence (.StartCondOK) to be ok
before advancing onto the next step. Each sequence shall have a “Not Ready Step” as the first
step in the sequence (step 0).
Figure 38 – Not Ready Step
“Wait Pallet In position At Pre-Stop Step”
This is the sequence READY or idle step. The machine is waiting for a pallet to arrive at the Pre-
Stop in order to advance to the next step. If start conditions are lost, the sequence will jump back
to step 0.
Figure 39 – Wait Pallet at Pre-Stop Step

“Empty Pallet Check Step”
Version 7.0
Page 64 of 141
After a pallet has arrived at the Pre-Stop this step checks for the presence of a shell on the pallet.
If there is a shell the sequence will advance to the next step. If there is not a shell the Pre Stop
Pass/Fail code (.PSDataResultsPassFailCode) is set to EMPTYPALLET (5) and the sequence
jumps to the “Check Ready for Pallet” Step to wait on the Main Sequence.
Figure 40 – Empty Pallet Check Step
“Scan Compressor Step”
To scan the compressor Tracking Label the Trigger Barcode Reader request bit is enabled
(StationName_TriggeBarCodeReader.Req.0). This bit is used in another program file supplied by
Emerson in order to trigger the bar code reader to be used on the machine (a different file will be
used depending on the brand of reader used). That file will turn on the Barcode Read bit
(StationName_ScannerData.BarcodeRead) when the label has been read and the Tracking label
information has been stored in StationName_SerialModel.TrackingLabel.Serial.LEN and
StationName_SerialModel.TrackingLabel.Model.LEN. This allows the sequence to advance to the
next step. If Configuration Control is not available during debug on the seller’s floor the bit
Use_WIP_Override_Data can be toggled which will bypass this step. However, it is still the seller’s
responsibility to get the Barcode reader to scan correctly into the PLC.
Figure 41 – Scan Compressor Step
“Send Model/Serial Message Step”
Version 7.0
Page 65 of 141
The data read from the Tracking Label is sent to Configuration Control in this step. This is
accomplished by turning on StationName_SerialModel.Req. A system file will take the data stored
in StationName_SerialModel.TrackingLabel.Serial.LEN and
StationName_SerialModel.TrackingLabel.Model.LEN and send it to Configuration Control. If
Configuration Control is not available during debug on the seller’s floor the bit
Use_WIP_Override_Data can be toggled which will bypass this step.
Figure 42 – Send Serial/Model Message Step
“WIP Data Check Step”
After the Tracking Label data has been sent to Configuration Control this step waits for the WIP
reply from Configuration Control. The WIP reply contains all of the Compressor data necessary to
determine if the Compressor should be run or not. In order to check for the presence of the WIP
reply the tag “StationName_WIPData.PSDataCheckReq” is turned on. While this tag is on if there
is new data that is received a system file will turn on the “StationName_WIPData.PSDataAvailable”
tag to indicate that new WIP data is available for processing. The new data will be placed in the
“StationName_WIPData.PSData.Compressor” tag. When the
“StationName_WIPData.PSDataAvailable” tag turns on the sequence will advance to the next step.
If Configuration Control is not available during debug on the seller’s floor the bit
Use_WIP_Override_Data can be toggled which will bypass this step. Data to mimic the data that
comes from Configuration Control can be placed in the “StationName_WIPOverride.Data” tag.
This data can then be used as if it came from Configuration Control.
Version 7.0
Page 66 of 141
Figure 43 – WIP Data Check Step
“Wait Compressor Processed Step”
After the WIP data has been received the Schedule of the Compressor at the Pre-Stop is
compared to the Schedule of the Machine. If they are equal the sequence is permitted to advance.
If they are not equal then the Pre-Stop sequence waits until the Main Sequence is at a step where
the parts used in the station have been installed in the compressor before advancing to the next
step. This is done to keep the Parts information downloaded for the compressor at the Pre-Stop
from replacing the parts that were used for the Compressor that may be in the station. The Main
Sequence step at which it is ok to move to the next step can be changed based on the equipment.
Version 7.0
Page 67 of 141
Figure 44 – Wait Compressor Processed Step
“Schedule Data Check Step”
If the schedule of the Compressor at the Pre-Stop matches the schedule of the Machine then the
sequence will advance to the next step. If not match then turning on the
“StationName_WIPData.PSScheduleCheckReq” tag will cause the schedule for the compressor at
the Pre-Stop to become the schedule of the machine. After this occurs then the schedules should
match and the sequence will advance.
Figure 45 – Schedule Data Check Step
Version 7.0
Page 68 of 141
“Check if Machine is in Bypass Mode”
The mode of the machine is checked to see if it is in bypass. If it is in Bypass Mode then the Pre-
Stop Pass/Fail code is set to Bypass (3) and the sequence jumps to the “Check Ready for Pallet”
Step to wait on the Main Sequence.
Figure 46 – Check if Machine is in Bypass Mode
“Buildover Check Overall”
The compressor’s Buildover Overall (Is the Overall Pass/Fail code of this compressor ok?) must be
verified. If the test fails the BuildOverResult_Overall is returned with a
c.BUILDOVER_RESULT_BYPASS (3). (This check is done in the System_Evaluate_BuildOver
routine and does not need any modifications.) If the test fails the PassFailCode is set to c.BYPASS
(3) so that the compressor can be passed through the station without cycling. The program
“jumps” to the Lower Pre Stop Step to release the pallet into the station without performing any
more Buildover, Tooling, or Parts checks. The code to accomplish this is already provided in the
station template and is only included here for reference. See the example below.
Version 7.0
Page 69 of 141
Figure 47 – Example of Buildover Overall Check
Checking Buildover Required (previous) Stations
The compressor’s Buildover Required Stations (Have the stations prior to this station that are
required passed?) must be verified. If the test fails the
BuildOver.BuildOverResult_PreviousReqdStnResults is returned with a
c.BUILDOVER_RESULT_BYPASS (3). (This check is done in the System_Evaluate_BuildOver
routine and does not need any modifications.) If the test fails the PassFailCode is set to c.BYPASS
(3) so that the compressor can be passed through the station without cycling. The program
“jumps” to the Lower Pre Stop Step to release the pallet into the station without performing any
more Buildover, Tooling, or Parts checks. The code to accomplish this is already provided in the
station template and is only included here for reference. See the example below.
Figure 48 – Example of Buildover Previous Stations Check
Version 7.0
Page 70 of 141
Checking Buildover This Station
The compressor’s Buildover This Station (Has this station previously ran this compressor?) must
be verified. The evaluation returns a code equal to the compressor’s previous status at this
machine. (This check is done in the System_Evaluate_BuildOver routine and does not need any
modifications.) If the compressor previously passed this station the PassFailCode is set to
c.PASSED_PREVIOUSLY (11) so that the compressor can be passed through the station. If the
compressor previously failed or bypassed this station the PassFailCode is set to c.BYPASS (3) so
that the compressor can be passed through the station without cycling. The program “jumps” to the
Lower Pre Stop Step to release the pallet into the station without performing the Tooling, or Parts
checks. The code to accomplish this is already provided in the station template and is only
included here for reference. See the example below.
Figure 49 – Example of Buildover This Station Check
Parts Verification Display Change Decision
If the parts for the compressor at the Pre-Stop have not been verified it is necessary to change the
HMI display to the Parts verification display for the operator. If the parts have been verified then
the sequence jumps to the Check Tools step and bypasses the Display Changes steps. If the
Parts have not been verified the sequence advances to the next step.
Version 7.0
Page 71 of 141
Figure 50 – Parts Verification Display Change Decision
Parts Verification Change Display
If it has been determined that the parts need to be verified the display is changed to the Parts
Verification HMI display. The current display is “remembered” by moving the value of the current
display into the “StationName_HMI.Return_Display_Number” tag. The constant for the Parts
verification display is then moved into the “StationName_HMI.Remote_Display_Number” to force
the display to change. After it is seen that the current display is the display that is being forced, the
sequence is advanced and the remote display number is set to 0 in order to give the operator back
control of the HMI.
Figure 51 – Parts Verification Change Display
Version 7.0
Page 72 of 141
Check Parts Confirmation
This step waits on the parts to be verified before advancing to the next step.
Figure 52 – Parts Confirmation
Verify Parts Return Display
After the parts have been verified the HMI display is forced back to the display it was on previously
by moving the “remembered” display number into the Remote Display Number. After the current
display is equal to the “remembered” display, the sequence is advanced and the remote display
number is set to 0 in order to give the operator back control of the HMI.
Figure 53 – Verify Parts Return Display
Version 7.0
Page 73 of 141
Check Tooling Confirmation
The “StationName_Tooling.PS_CheckReq” tag is turned on in order to use the logic in

“Config_Verify_Tooling” to verify the tooling using the Pre-Stop WIP data that was sent by
Configuration Control. If the tooling is confirmed the sequence advances to the next step.
Figure 54 – Check Tooling Confirmation
Operator Change Display Decision
If the operator is not currently logged into the machine or the operator that is logged in does not
have rights to operate the equipment, it is necessary to change the HMI display to the Operator
Details display. If the logged in operator has the correct rights to operator the equipment the
sequence jumps to the “c_STEP_PRESTOP_CHECK_READY_FOR_PALLET.AOI.Stp” step and
bypasses the Display Changes steps. If the operator is not logged in, the sequence advances to
the next step.
Figure 55 – Operator Change Display Decision
Version 7.0
Page 74 of 141
Operator Change Display
If it has been determined that the operator needs to log in the display is changed to the Operator
Details HMI display. The current display is “remembered” by moving the value of the current
display into the “StationName_HMI.Return_Display_Number” tag. The constant for the Operator
Details display is then moved into the “StationName_HMI.Remote_Display_Number” to force the
display to change. After it is seen that the current display is the same as the display that is being
forced, the sequence is advanced and the remote display number is set to 0 in order to give the
operator back control of the HMI.
Figure 56 – Operator Change Display
Check Operator Login
This step waits until the operator login is completed before advancing to the next step.
Figure 57 – Operator Login
Version 7.0
Page 75 of 141
Check OMS Status
This step waits until the OMS has been verified by the operator.
Figure 58 – Check OMS Status
Check Mentor Login
If the operator that has logged into the machine does not have sufficient rights to operate the
equipment then a mentor will need to log in with them. This step waits until the mentor is logged in
if one is needed.
Figure 59 – Check Mentor Login
Version 7.0
Page 76 of 141
Operator Return Display
After the operator and mentor have logged in the HMI display is forced back to the display it was on
previously by moving the “remembered” display number into the Remote Display Number. After
the current display is equal to the “remembered” display, the sequence is advanced and the remote
display number is set to 0 in order to give the operator back control of the HMI.
Figure 60 – Operator Return Display
Verify Main Sequence Ready for Pallet
In this step the Pre-Stop sequence is waiting on the Main sequence to be ready to receive a pallet.
It is ready to receive a pallet when the Main Sequence is waiting on a pallet or when the Main
Sequence is releasing a pallet. If at any time the operator presses the “Cycle Stop” push button on
the HMI (Machine.Stop becomes active) the sequence will jump back to the Not Ready Step. This
keeps the pallet at the Pre-Stop from releasing into the station when the Main Sequence releases
the pallet in the station.
Figure 61 – Verify Main Sequence Ready for Pallet
Version 7.0
Page 77 of 141
Copy Pre-Stop Data into Compressor Data
After confirming that the Main Sequence is ready to receive a pallet and before releasing the Pre-
Stop pallet the WIP data that was received from Configuration Control for the Pallet at the pre-Stop
must be transferred to the Station Stop (Compressor) for processing. The data transfer is handled
in a System file and is initiated by turning on the “StationName_WIPData.PSDataXferReq” tag.
When the data has been transferred the “StationName_WIPData.SSDataAvailable” tag is set and
the sequence is allowed to advance to the next step.
Figure 62 – Copy Pre-Stop Data into Compressor Data
Lower Pre-Stop
After the data has been transferred the Pre-Stop is lowered by setting the request bit for the Pre-
Stop. The stop is kept lowered until the pallet reaches the pallet entering prox signifying that it is
ok to raise the stop under the pallet.
Figure 63 – Lower Pre-Stop
Check Pallet Clear of Pre-Stop
After releasing the pallet from the Pre-Stop the sequence will wait until the pallet has come off of
the pallet entering prox switch. This signifies that the pallet is completely off of the Pre-Stop.
Version 7.0
Page 78 of 141
Figure 64 – Check pallet Clear of Pre-Stop
Check Pallet in Station
After the pallet has cleared the Pre-Stop the sequence waits for the pallet to be in station before
moving on. This prevents “Looping” of the Pre-Stop sequence as the main sequence will still be
waiting on a pallet. The pallet is in position when the Main Sequence moves beyond the Wait for
Pallet step. This has been accomplished here by using a LIM instruction.
Figure 65 – Check Pallet in Station
2.16.2. Main Sequence Standard Steps
“Not Ready Step”
The “Not Ready Step” checks for the Start Conditions of the sequence (.StartCondOK) to be ok
before advancing onto the next step. Each sequence shall have a “Not Ready Step” as the first
step in the sequence (step 0).
Figure 66 – Not Ready Step
Version 7.0
Page 79 of 141
Part in Station Check
Under normal conditions there should never be a part in the station in this step. This step handles
the event in which the sequence is started with a part already in the station. If no part is detected
in the station, the sequence moves to the next step, otherwise, the part is checked to see if it was
in-process or processed when the sequence was interrupted. The results are evaluated and
sequence will jump to the Determine Machine Cycle step if there is a compressor present with
Data. If the compressor at the station stop has a Processed Code (6) then this code assumes
there was an unknown issue with the previous cycle and sets the compressor status to a Fail (2)
before jumping.
Figure 67 – Part in Station Check
Version 7.0
Page 80 of 141
Check if Machine is in Bypass Mode
If there was a pallet in the station when the sequence was started and it passed the previous step
(has a serial number with no Pass/Fail code) then this step checks to see if the machine was
placed into Bypass Mode. If it is in Bypass Mode then the Pass/Fail code is set to Bypass (3) and
the sequence jumps to the Determine Cycle Machine step.
Figure 68 – Check if Machine is in Bypass Mode
Check Parts Confirmation
If there was a pallet in the station when the sequence was started, it had a serial number, did not
have a Pass/Fail code, and the machine is not in Bypass Mode this step reconfirms the parts were
correct for the Compressor In the station when it was in the Pre-Stop.
Figure 69 – Check Parts Confirmation
Version 7.0
Page 81 of 141
Check Tooling Confirmation
If there was a pallet in the station when the sequence was started, it had a serial number, did not
have a Pass/Fail code, Parts were correct, and the machine is not in Bypass Mode this step
reconfirms the tooling is correct for the Compressor In the station. The
“StationName_Tooling.SS_CheckReq” tag is turned on in order to use the logic in
“Config_Verify_Tooling” to verify the tooling using the Compressor WIP data for the compressor in
the station that was sent by Configuration Control. If the tooling is confirmed the sequence
advances to the next step.
Figure 70 – Check Tooling Confirmation
Pallet Detection
This step waits on a pallet to arrive in the station. De-bounce should be handled in the
AOI_DEBOUNCEDINPUT in the IO_MappingInput routine. After the pallet is present the sequence
advances to the next step.
Figure 71 – Pallet Detection
Version 7.0
Page 82 of 141
Cycle Machine Decision
After the compressor is detected in the station its PassFailCode is cheked to determine if it should
be cycled. If this compressor has previously passed (PassFailCode = c.PASSED_PREVIOUSLY),
Failed (PassFailCode = c.Fail), Should be bypassed (PassFailCode = c.BYPASS), or is an empty
pallet (PassFailCode = c.EMPTYPALLET) then the “Machine.pvResumeAvail” tag is set (in
HMI_Main). After the operator presses the Resume button on the HMI (Machine.pvResume) the
sequence jumps to the wait for downstream clear step to release the pallet without processing. If
the operation should automatically release compressors through the station that should not be
processed without the interaction of the operator, the “Machine.pvResume” XIC can be removed
from the rung.
If the compressor was passed previously the PassFailCode is set to a c.PASS in order to not
change the overall status of the compressor in Configuration Control.
If there is a serial number without a Pass/Fail code the sequence advances to the next step and
the compressor is processed. All steps relating to the operation of the machine should be placed
below this one.
Figure 72 – Cycle Machine Decision
Version 7.0
Page 83 of 141
Determine Retry
This is not a required step, however, if an operation needs to have the ability to retry or rerun all or
part of the sequence, use the provided code. If the status of the compressor is a Fail (2) then a
counter will increment counting the number of retries. As long as the counter is not done the
Reprocess push button on the HMI will be available to press. If the operator presses the
Reprocess push button then the sequence will jump back to whatever step the sequence needs to
in order to correctly reprocess the compressor. It is the programmer’s responsibility to update this
move instruction with the correct step constant. The compressor’s Pass/Fail code and disposition
are also reset. In order for the sequence to resume the compressor needs to be correctly
processed (not a Fail), the retry counter is done so no more retries are possible, or the operator
chooses to press the resume button on the HMI allowing the rejected compressor to be released.
This rung can be modified based on operation requirements if needed with Emerson approval.
Figure 73 – Determine Retry
Part Disposition
If by the end of the sequence the PassFailCode is still set to a c.PROCESSED (6) then it is set to a
C.PASS in the Disposition step of the sequence footer. If it is not set to a Processed it will default
to a Fail. It is the program developer’s responsibility to make sure that the PassFailCode is set
correctly by this step in the sequence. This data tag is used when the WIP update is written to the
Configuration Control Master to indicate the compressor status at the end of the cycle (See Error! R
eference source not found. Error! Reference source not found.)
Version 7.0
Page 84 of 141
Figure 74 – Part Disposition
Wait Downstream Clear
The Wait For Downstream Clear step checks the conditions downstream of the station to ensure
that it is safe to release the part from the station. The logic for the Wait for Downstream Clear step
is shown below.
Figure 75 - Wait for Downstream Clear
Record Result Data
The Record Result Data step copies the StationName_Compressor.TrackingLabel to the

StationName_CompressorResults.TrackingLabel to make sure that the Serial and Model code of
the compressor in the station is in the Compressor Results UDT. Results of the operation are sent
to the Configuration Control Master by turning on the StationName_WIPData.SendUpdateReq.
This activates Code in the System Files to create and send the WIP update message. The
sequence will remain in this step until confirmation that the WIP update message has completed,
Version 7.0
Page 85 of 141
StationName_WIPData.MsgCompleted flag is set. The Standard Station Template includes this

rung and should not be modified without written permission by Emerson.
Figure 76 - Record Result Data
Release Pallet
The Release Pallet step controls the releasing of the pallet from the station. The station stop is
lowered until the pallet exiting station stop input is made. Dry cycle branch can be removed after
qualification if needed.
Figure 77 - Release Pallet Step
Version 7.0
Page 86 of 141
Check pallet Clear of Stop
After the pallet is released the Exiting Station Stop prox switch is monitored for an off condition.
This confirms that the pallet that was being released is completely out of the station and if the
Pallet In Position prox is still made it is a new pallet and not the one just released.
Figure 78 – Check Pallet Clear of Stop
Final Step
This is the normal Final Step that is required for each sequence, however, unlike in other
sequences it also turns on “StationName_CurrentCycle.RecordCycleDataReq” in order to
log station statistical data in a System file.
Figure 79 – Final Step
2.17. Production Data

The program developer is also responsible for setting up all the conditions and events listed in the
Config_Production_Data routine. The logic in this file is used elsewhere in the program to calculate cycle time
and provide a link to other monitoring software that will detect the state and status of the machine. The conditions
for any states that do not apply to the station being programmed should be replaced with an AFI. A guide for
this logic has been supplied in the standard code but it is still the program developer’s responsibility to confirm
that it is working correctly. The following status coils must have logic written for them based on the sequence
of the machine:
• StationName_CurrentMachineStatus.BackedUp – Downstream is blocked and the station is

ready to release a pallet.
Version 7.0
Page 87 of 141
• StationName_CurrentMachineStatus.NoProduct – The station is not currently making a part

and is waiting on a pallet to be present at the pre-stop.
• StationName_CurrentMachineStatus.Operator – The machine sequence is cycling and is in a
step that is operator dependent. All operator dependent steps should set this coil.
• StationName_CurrentMachineStatus.Manual – The station is in manual mode.
• StationName_CurrentMachineStatus.CycleStart – Must be true at the beginning of a cycle.
Normally when the data is being checked at the pre-stop. It is not important for this to be a
one shot and can remain on past the point of the beginning of the cycle.
• StationName_CurrentMachineStatus.CycleEnd – Must be true at end of the main machine
sequence. Normally the Last step. It is not important for this to be a one shot and can remain
on past the point of the point of the end of cycle.
2.18. Tooling Verification

The program developer is responsible for setting the status of the tooling verification bit,
StationName_Tooling.Confirmed. This is done in the Config_Verify_Tooling routine. This logic handles the
verification of the tooling for both the Compressor at the Pre-Stop and the Compressor in the station.
Copy Compressor Data to be used in Verification
The First two rungs copy the downloaded WIP parameters into StationName_Tooling.Required_DINT[0-9] and
StationName_Tooling.Required_REAL[0-9]. These Tooling Required Data locations should be used throughout
the remainder of the tooling verification code.
If verifying for the compressor at the Pre-Stop the “StationName_Tooling.PS_CheckReq” is turned on from the
Pre-Stop Sequence and the WIP data for the Pre-Stop Compressor is copied.
If verifying for the compressor in the station the “StationName_Tooling.SS_CheckReq” is turned on from the
Main Sequence and the WIP data for the Compressor in the station copied.
Figure 80 – Copy Compressor Data
Version 7.0
Page 88 of 141
Verification Logic
Each tooling type should have its own tooling verification rung. To verify that the correct tool is in the machine
the corresponding StationName_Tooling.Verified[x] bit should be set, where x is replaced with the Tooling
Verified array index number. Normally it makes the code simpler if the same index that was used for the tooling
parameter is used for the tooling verified array index. This is not always possible as some tooling requires more
than one parameter to verify it. Notice that in the example below StationName_Tooling.Required[0] sets the
StationName_Tooling.Verified[0] bit (both use index 0). The Tooling required parameter is compared with the
constant that indicates what tool is being requested by the tooling parameter (see section 2.8.2 Step Constants
The step constant is an .AOI.Stp INT of a user-created tag of the type udt_Step. All udt_Step tags should be
prefaced by “c_STEP”, denoting that it is a constant and a step. Like other constants, all letters beyond the initial
“c_” should be capitalized.
c_STEP_LIFTPALLETOFFCONVEYOR
If the step is not in the main sequence, the sequence name should be included in the constant as well.
c_STEP_PRESTOP_WAIT_PALLET_IN_POSITION
The constant values of the .AOI.Stp fields of each udt_Step tag are assigned automatically in the
AOI_FAULT logic.
Machine Tooling Constants). This comparison is then qualified by feedback from the machine indicating
what tool is actually installed. Each tool for this tool type should have its own branch. Each tool type should
have its own rung.
Figure 81 – Example of Tooling Verification Logic
Verification Logic HMI Status
To drive the tooling HMI display (see section 4.4.9 Tooling Verification Display)
StationName_Tooling.Actual_DINT[x] must be changed to reflect the tool that is actually installed in the machine
and if it is the correct tool. Feedback is used from the machine to indicate what tool is actually in the machine,
and then based on a comparison to what the tooling parameters are indicating should be the correct tool, a
constant is moved into StationName_Tooling.Actual_DINT[x] to drive the HMI multistate indicators. Each tool
for a tooling type should have 2 branches. One indicating that it is the tool installed and it is the correct tool and
one indicating that it is the tool installed and it is NOT the correct tool. Each tool type should have its own rung.
Version 7.0
Page 89 of 141
Figure 82 – Example of Setting the Actual Tooling for the HMI
Verification Logic HMI Status
All of the tooling verified bits are summed together to get the overall Tooling Confirmed status of the machine
that is used in the machine sequence to make sure that the tooling is correct before continuing. Depending on
what sequence is requesting the tooling verification, the confirmed constant is moved into the correct tag. See
the example below. The descriptions for the verified bits should be changed from the generic descriptions in the
Station Template to reflect what tool is being verified.
Version 7.0
Page 90 of 141
Figure 83 – Example of Setting the Tooling Confirmed Bit
Manual Tooling Selection
In some cases, it is necessary for the equipment to have the tooling manually selected when verifying motions
or running the machine in Manual mode. For this logic should be added at the end of the Config_Verify_Tooling
in order to allow for this selection. Logic should be patterned after the logic used for IO_OutputQualifiers. When
manually selecting a tool the corresponding constants should be moved into the Tooling Required tag and
Compressor WIP parameters. This data will be overwritten by Configuration Control the next time a Compressor
barcode is read.
2.19. Best Practices

The bulk of this specification concentrates on file organization and sequential logic implementation. For the
most part, the developer is free to decide how to apply ladder logic for individual machine control. However,
when developing ladder logic, the following general guidelines should be followed:
1.1.1. Latched Instructions
Latch instructions should NOT be used, and replaced with branched seal-in logic. For example, the
following logic should not be used:
Main Control Pow er

On
Main Sequence ControlPow er Main Sequence
SeqMain.Start <DigitalInput[4].Point[15].ON> SeqMain.Run
3 L
Main Sequence Main Sequence

SeqMain.Stop SeqMain.Run
4 U
Main Control Pow er
On
ControlPow er
<DigitalInput[4].Point[15].ON>
/
Figure 84 - Latched Instructions (Avoid Use)
Rather, the following method should be utilized:
Main Control Pow er

On
Main Sequence ControlPow er Main Sequence
SeqMain.Start <DigitalInput[4].Point[15].ON> SeqMain.Run
2
Main Sequence Main Sequence

SeqMain.Run SeqMain.Stop
/
Figure 85 - Seal-In Rung (Use instead of Latch Instructions)
Latch instructions should never be used to trigger any output. Latch instructions can only be used with
written permission of Emerson.
Version 7.0
Page 91 of 141
1.1.2. Jump, Label, and MCR Instructions
Code jumps using the JMP instruction should not be used, as this practice often yields code that is
problematic to troubleshoot. The desired function of not evaluating sections of code should be
accomplished using Status bits and XIC instructions at the start of each rung. Likewise, MCR instructions
should also be avoided.
Version 7.0
Page 92 of 141
3. Robot Interface/Programming
3.1. Robot Communications
Robots will be set up in PLC Ethernet I/O tree using Fanuc AOP 1.33. Fanuc AOP 1.33 is available upon
request. Robot IP address will be designated by Emerson Controls Engineer. AOI_Robot will be utilized for
mapping of all communications of robot IO/UOP.
3.2. Robot Safety

If robot is utilizing safety over Ethernet, Fanuc AOP 1.33 will handle communication of safety IO with robot. If
robot is not utilizing safety over Ethernet, then safety must be hardwired into robot cabinet. If the robot cell is
designed with the opportunity for operators/technicians to fully enter the cell and have the door closed behind
them, then the cell must be equipped with Fortress Interlock Safety Devices. These safety keys for the cell
door will be provided by Emerson. If the cell does not permit a person to fully enter the cell, then regular
safety rated door switches are permitted.
Dual Check Safety (DCS) zones will be utilized for all robots to prevent damage to the robots or any other
object that may be in the robots range of motion. DCS zones are to be inspected by Emerson Engineering
before robot start up to ensure all safety areas are thoroughly considered.
3.3. PLC Programming
The PLC program is responsible for control of all robot movement. The best analogy for
robot control is to use the PLC for the traffic cop instructing the robot what action needs to
be completed within the cell. Each robot in a cell (if there are more than one) will contain
their own individual Control_Robot routine and Robot_Sequence. The PLC programming
will be gone into detail in the section. A detailed breakdown of each routine follows.
3.3.1. Control_Robot
The Control_Robot routine is used for all non-sequenced control of the robot. The top 5 rungs of this
routine are dedicated to enabling the robot to either run in a manual mode or an auto mode. In
manual mode the robot is controlled by the operator push buttons. In Auto mode the robot motion is
dictated by the robot sequence. The 4 rungs below show the manual and auto mode logic.
Version 7.0
Page 93 of 141
Rung 5-107 contain the individual configuration of the robot AOI and all subsequent mapping. Rung
5 contains the Robot AOI. These rungs were designed with the intend of minimal programming
needs upon setup. One of the items that will need to be configured is the SafetyGatesOK bit, as well
as the ALLEStops bit. There are both bits controlled in the safety portion of the PLC, what these bits
are used for should be self-explanatory, but we will go into further detail. One should be tied to the
conditions of the Safety gates and the other should be tied to the E-stops inside the safety routines.
The creation and proper configuration of these two bits will enable the proper function of the robot
UOPs.
Version 7.0
Page 94 of 141
In rung 14, the command to run PNS_0001 is utilized. This rung makes it possible to run the robot in
both manual and auto mode. The Robot.PNS_0001 command handles strobing the PNS_0001
command into the robot.
Rungs 16 thru 55 map any DI in the robot to an output in the PLC. For example, if you wanted to
indicate to the robot that the pallet lift was raised for a 53 Frame, it would look like the rung below.
The robot would then be able to look at digital input 1 to see the status of the lift. Rungs 56-60 are
responsible for feeding integers into the robot via group inputs. Group input 1 is reserved for the
robot_command. Rungs 62 thru 100 are utilized for feeding the robot outputs into the PLC into our
AOI_Debouncedinput command. The group outputs are mapped to robot integers in rungs 103-107.
The commands following that are used to build the robot motion commands, built in the same fashion
as the PLC outputs. There are three rungs to set up a robot motion command. The first rung is used
to set the HMI indicators. The second rung is used to set the safetoinitiate, safetomaintain, and
pvAvail bits. If there are conditions which we do not ever want to have in place before commanding
robot motion, than that should be set up in the safetoinitiate rung. This keeps from duplicating logic
in the manual step and decision step in the robot sequence. The third rung in a robot motion
command is the rung responsible for entering the config constant motion integer into the
robot_command location. See example below.
Version 7.0
Page 95 of 141
Following the rungs containing the robot motion commands, there are some data handling functions.
In the event that the robot gripper is picking a part and transferring data, this can be used to handle
this functionality. Similar logic is used in several Emerson programs.
There is area in the robot control for the any robot outputs that are actuated from the PLC such as
grippers. The final rungs are dealing with the pause functions for the robot motion commands.
These rungs are built for each robot motion that has a position that would need to be retaught during
normal operations, such as pick or place positions.
Version 7.0
Page 96 of 141
3.3.2. Sequence_Robot
The sequence for the robot is intended to allow the PLC to control the robot motion. There, robot
sequence is designed such that there are two ways for the robot to begin motion, the manual step is
designed to be used if an operator or technician has decided to manually manipulate the robot motion
command. The manual step will allow the robot sequence to run without using the decision logic.
This is why it is important that the safe to initiate bit is set up properly to not allow an operator to
place a part when a part is already present.
The decision step is used to direct robot motion while in the auto mode. The decision step should
entail the traffic cop portion of the programming helping to move the robot motions in the most
efficient way possible. The reasoning for placing this programming in the PLC instead of the Robot
is it becomes easier to manipulate in the event the plant wishes to change the priority of robot
motions.
The sequence steps controlling the robot motion are primarily consisting of 3 steps, one initiating the
robot motion via an output request, one actuating any robot EOAT motion, ie closing or opening
grippers, and finally waiting for the robot motion to be completed and jumping to the final step of the
sequence.
4. Operator Interface
4.1. Hardware
All control systems provided will utilize Allen-Bradley PanelView Plus operator interface. The operator interfaces
will feature touch panels, and Ethernet communications. Acceptable models are listed in the Scroll Assembly
Industrial Equipment Standards.
Please see the RFQ for the equipment to determine what firmware revision should be used for developing all
HMI applications.
4.2. Standard Interface

A standard Operator Interface shall be implemented for all machine control systems. Standardizing the layout,
look, and functionality of the interface provides for efficient operation by maintenance and manufacturing
personnel.
This standard includes which displays are to be included, the general layout of these displays, display navigation,
manual interaction with a sequence, manual control of machine equipment, access to maintenance and
configuration parameters, and alarm and fault handling.
4.3. Standard Development Template
Version 7.0
Page 97 of 141
As with the PLC code, a Standard Development Template is provided for implementing a standard operator
interface. The template includes common design elements such as headers, buttons, labels, fonts, colors, etc.
Additionally, the template provides a series of standard displays, of which some pre-configured functionality will
be provided.
Also included will be a repository of common used display elements such as manual control buttons and standard
machine graphics. By utilizing this standard layout and pre-configured display elements, the developer insures
a final interface that conforms to the standard look and feel desired.
4.4. Displays
A set of standard displays will be available at each PanelView. The displays are provided in the Standard
Development Template. The developer will add elements specific to the machine being manufactured. Many
displays will require little to no modifications by the developer, such as the Live Load and Production Data
displays. At times, one display will not be sufficient to hold all the elements required. In such cases multiple
displays of the same type should be added and labeled accordingly: “Manual Control 1” and “Manual Control 2”,
or “Manual Control Press” and “Manual Control Conveyor” for example.
The standard displays are as follows:
Table 6 - Standard Template Application Displays

Display Number Display(s) Description
[ALARM]
[NOTIFICATION]
2 002 - Alarm Status Alarm management
Popup display confirming a request to exit

3 003 - Exit Confirmation
RSView
4 004 – Live Load Production Schedule Information Display
5 005 - Schedule Details Pop Up Popup Production Schedule Information Display
Default display. Contains elements for routine

6 006 - Main
machine operation
7 007 - Machine Control Gateway page to manual operations
Version 7.0
Page 98 of 141
8 008 - Operation Management Gateway page to all operation specific pages
9 009 - Parts Verification Parts Confirmation Display
10 010 - Tooling Verification Tooling Confirmation Display
Contains information and controls pertinent to the

11 011 - Verification Override
overriding of tooling and parts confirmation
12 012 - Production Data Machine Production Data Display
13 013 - Production Events Machine Production Events Display
Shows the status of all sequences in the

14 014 - Sequence Status
machine. Includes step control for debugging.
15 015 – Operator ACK OMS
16 016 – Operator Details
17 017 - Operator Disposition Page containing controls for disposition of a part
018 - Operator Disposition Allows user to select reject reason when rejecting
18
Reject Selection Pop Up a compressor.
019 – Language Switch

19
Conformation Language 1
020 – Language Switch

20
Conformation Language 2
021 - Message Diagnostics -

21
Main

22
WIP

23
WIP Reply

24
Compressor Results
Version 7.0
Page 99 of 141

25
Operator

26
PassThru

27
Schedule

28
Station Config
40 040 - Model Table
041 - Model Parameter

41
Enumeration Pop Up
45 045 - WIP Override Data
50 – 59 (Manual
050 - Manual Control Manual control of the machine equipment
Control Displays)
60 – 69 (Manual Servo
060 - Manual Servo Control Manual control of Servos on the equipment
Control Displays)
70 070 - I-O Navigation Gateway page to I-O Details Displays.
71 – 89 I/O Displays 071 – 089 I-O Display I/O Maintenance Displays
Chart for SPC data if SPC data collection is

90 – 99 SPC Displays 090 - SPC_Chart used. Not required if SPC data collection is not
used.
Data Display for SPC data collection. Not
90 – 99 SPC Displays 091 - SPC_Data
required if SPC data collection is not used.
4.4.1. Display Numbering
Numbers have been included as a prefix to the Display name. This is to force organization to the
Display navigation in Factory Talk Studio. The numbers assigned are also to be used as the
Display Number in the Display settings of each Display. This allows for easier organization when
using Display forcing from the PLC.
Version 7.0
Page 100 of 141
Figure 86 – Display Settings: Display Number
Please follow the Numbering found in the standard Display Table when creating new displays not
in the Template. The added zeros in the display name are to allow more than one station to be
included in the same HMI and force those displays to be together. The second station would have
display numbers of 100 – 199. The Third station would have display numbers from 200 – 299,
etc…
Version 7.0
Page 101 of 141
The figure below show the application Explorer listing of Displays included in the Station Template panelview
application.
Figure 87 - Explorer: Displays in Template
Version 7.0
Page 102 of 141
4.4.2. Common Template Display Elements
The figure below shows the Main display which illustrates many of the common elements that will appear
on most standard template panelview displays. These elements are enumerated for a detailed
description below.
Figure 88 – Main Display with Typical Elements Identified
(1) Header
The Header displays the station name and indicates active alarms with a
background that will change to a red color and active Notifications by changing
to yellow. If the machine is being built for a non-English speaking plant, the
Header will also allow the operator to select the language. The header is
implemented as a global object.
The application programmer will change the text for the header from “Station
Name” to the actual name of the machine. This text element is located on the
Main display. The Header background elements are implemented as a Global
Object because, as a group, they appear on multiple displays. The application
programmer does not need to change the global object because the tag
referenced is a standard that is specified in the PLC template.
Version 7.0
Page 103 of 141
(2) Page Change (Navigation) Bar

The Page Change Bar or Navigation Bar is a set of Goto Display buttons that
allow navigation to other displays that exist in the template application. Some
of the displays navigated to will then provide lists of other displays that may be
accessed. The same navigation choices are provided on all the standard
template displays and the Page Change Bar is thus implemented as a global
object.
The application programmer will not need to make any changes to the Page
Change Bar in the template (unless a multi station machine is being
programmed, discuss this with an Emerson engineer if necessary). If the
application programmer provides other navigation options in a machine
panelview application, these options should retain the look of the elements
found in the Page Change Bar.
(3) Footer
The Footer provides two elements that display the state of the machine. The
left-hand element is named “Machine Status” and displays Mode and other
status information about the machine. The right-hand element is named
“Sequence Status” and displays the current main sequence step number and a
description of that step.
The application programmer does not need to make any changes to the
“Machine Status” element. It references a standard template tag and the
meanings of the values are standardized.
The application programmer will not normally need to modify the “Sequence
Status” element. The “Sequence Status” element is primarily a string display
element and a numeric display element that are connected to standard tags in
the PLC. The only time this will need to be modified is if the application
developer is not using the standard tag name for the main sequence. The
footer is implemented as a global object.
(4) Part Schedule Bar

The part Schedule Bar Displays the current Schedule, as well as, the current
Serial number, model number and long model.
The application programmer does not need to make changes to the Part
Schedule Bar if the machine is a Live-Load station. If the machine will not be
a Live-Load station, then the Schedule and Long Model elements should be
hidden in the Part Schedule Bar by changing the properties. The serial and
model elements should remain because these elements are common to all
stations, both Live-Load and non-Live-Load.
(5) Operator Bar

The Operator Bar Displays the current operator login information as well as the
last cycle time.
The application programmer does not need to make changes to the Operator
Bar. The Operator Bar is implemented as a global object.
Version 7.0
Page 104 of 141
4.4.3. Main Display

The Main display is the initial graphic for the Panelview application. This display contains many of the
common display elements that will appear on most displays in the application as well as the Machine
Mode control button set, Parts and Tooling status displays, and Operator Disposition Controls. The
Machine Mode controls are used to place the machine into Auto or Manual mode and to Start the Auto
Cycle or Homing Sequence.
The application programmer only needs to change the text in the Header bar for the Main display as
described previously. No other changes are required.
Figure 89 – Main Display
4.4.4. Machine Control Display

The Machine Control Display provides Navigation buttons to the Manual Control displays, I-O displays,
and sequence status displays. The application programmer only needs to add navigation buttons to
Machine Control displays if more than one is needed based on the design of the machine.
Version 7.0
Page 105 of 141
Version 7.0
Page 106 of 141
Figure 90 - Machine Control Display
Version 7.0
Page 107 of 141
4.4.5. Manual Control Display

The Manual Control Display provides a pushbutton for the operator to actuate each motion of the
machine while in manual mode. If the machine also controls its own stops on the conveyor, then buttons
to manually lower the stops are also required.
The application programmer will have to add a Manual Control Pushbutton for each motion of the
machine that the operator can control. For opposing motions (such as Up and Down) a set of two
pushbuttons is required.
The standard pushbutton element consists of two panelview objects: a Momentary Pushbutton object
stacked on top of a Multistate indicator object. This approach is taken to allow the color coding and state
display of the output controlled by the pushbutton. The pushbutton will indicate both the current state of
the output plus whether the button is available to the operator or if it is locked-out due to the machine not
being in manual mode or some other coded interlock. The standard pushbutton element color scheme
also indicates if the motion is the normal (home) state or not for the machine.
The application programmer must be careful to satisfy the color and caption conventions for the standard
pushbutton element (See section 4.6 Typical Button Object).
Figure 91 - Example Manual Control Display
Version 7.0
Page 108 of 141
Figure 92 - Example Manual Servo Control Display
Version 7.0
Page 109 of 141
4.4.6. I/O Navigation Display
The I/O Navigation Display provides Navigation buttons to individual I/O displays for each input and
output module in the system. The application programmer will have to add one Goto Display object for
each input and output module in the machine and link it to a detailed I/O display for that module.
Figure 93 – I/O Navigation Display
Version 7.0
Page 110 of 141
4.4.7. I/O Displays
The I/O display names each I/O point on a given I/O module and shows its current state. It also
describes the location of the module and lists some addressing information for it. The display will be
used by maintenance personnel when troubleshooting the machine.
The application programmer must provide a separate display for each I/O module used by the machine.
The programmer will update the text at the top of the display to indicate the modules position in the rack,
its type and addressing in the PLC. The programmer then must address each state indicator to its
corresponding address for the input or output and provide a text description for the I/O point.
Analog I/O cards should include information as to the current count value and scaled value.
Several example displays are shown below:
Figure 94 - Example Discrete Input Module Display (0-15)
Version 7.0
Page 111 of 141
Figure 95 - Example Analog Output Module Display (16-31)
Version 7.0
Page 112 of 141
Figure 96 - Example Analog Input Module Display
Version 7.0
Page 113 of 141
4.4.8. Operation Management Display
The Operation Display provides Navigation buttons to the Standard Setup and Reporting displays. The
application programmer does not need to make any changes to this display.
Figure 97 - Operation Management Display
Version 7.0
Page 114 of 141
4.4.9. Tooling Verification Display
The Tooling Verification Display provides indicators for the operator to show the Required Tooling per
the Configuration Control system and the actual Installed Tooling as determined by the machine I/O.
Color coding on the displays indicates whether the Installed Tooling matches the Required Tooling.
There is also and indictor that will tell if the Tooling Check is being overridden.
The application programmer will provide a Required Tooling Indicator and an Installed Tooling indicator
for each tool that is to be verified for the machine. The naming convention for the tags to drive the
indicators follows a simple array index pattern (see section 2.18 Tooling Verification). The application
programmer must get the descriptions for each of the possible tooling states from the machine
programmer. The color convention should also be followed. A Red background indicates what tool is
installed but indicates it is a miss-match with what is required. A Green background indicates what tool
is installed and that it is a match with what is required. Each separate tool type should have its own
indicator. Each tool type can have many pieces of tooling indicated by the different text.
Figure 98 - Example Tooling Verification Display
Version 7.0
Page 115 of 141
4.4.10. Live Load Display
The Current Schedule display displays details and parts for the Live-Load schedule of the compressor in
the station (or last compressor to be processed through the station). The Live Load display also allows
the operator to browse upcoming or past schedules. The Live Load display is only used for machines
that are designated as Live-Load stations.
The application programmer does not need to make any changes to this display. The display utilizes
standardized tags and programming in the PLC. Some of the objects in the display connect to standard
tags in the Configuration Control Master.
Figure 99 – Live Load Display
The program developer should replace all the station tag pointers to the correct station as specified by
Emerson. This can be done with a search and replace with every item on the display selected.
Version 7.0
Page 116 of 141
Figure 100 – Replace Station Pointer on Live Load Display
4.4.11. Schedule Details Pop-Up
The Schedule Details Pop-up is a companion to the Current Schedule display. This pop-up shows parts
list details for browsed schedules.
The application programmer does not need to make any changes to this display.
Figure 101 - Schedule Details Pop-Up
Version 7.0
Page 117 of 141
4.4.12. Parts Verification Display

The Parts Verification Display displays verification status for parts of the current Live-Load schedule at a
Live-Load station. The Parts Verification Display is only used for machines that are designated as Live-
Load stations.
The application programmer only needs to replace the connection tag prefixes. The display utilizes
standardized tags and programming in the PLC.
Figure 102 - Parts Verification Display
Version 7.0
Page 118 of 141
4.4.13. Verification Override Display
The Verification Override Display guides the operator through the process of overriding either Parts
Verification requirements or Tooling Verification requirements for a station. This display also displays the
amount of time or number of cycles remaining before the override expires. This display will also allow
the operator to clear an override at any time.
The application programmer does not need to make any changes to this display if the machine is both a
Live-Load station and has verified tools. If the machine is not a Live-Load station the programmer
deletes all elements in the Parts Override frame. If the machine does not have verified tools (very rare)
the programmer deletes all the elements in the Tool Override frame.
Figure 103 - Verification Override Display
Version 7.0
Page 119 of 141
4.4.14. Operator Disposition Display
The Operator Disposition Display allows the operator to manually set the disposition of a compressor to
Pass or Fail and to navigate to the display when the operator can override the reject reason. This
display also displays Overall Status of the compressor, this station’s results, and reject reason to the
operator. The Components on this display are implemented using global objects so that they can be
used on other displays.
Figure 104 - Operator Disposition Display
Version 7.0
Page 120 of 141
When pressing fail a new display is popped up allowing the operator to select the reason the compressor
is being Rejected. The operator has the option of canceling the rejection of the compressor or scrolling
up/down to select the reason for the reject. After selecting the reason for the reject the Accept button is
pressed. The application programmer only needs to modify the reject reason list if one is supplied by
Emerson. Some machine will not require a list of reasons other than manual reject. The code for these
reasons should also be included in the list box. If desired the selection box can be replaced with push
buttons to select the reasons for a Reject. These can be tied to Bit Pack data types in Configuration
Control.
Figure 105 - Operator Disposition Display
Version 7.0
Page 121 of 141
4.4.15. Production Data Display
The Production Data Display displays standardized production metrics for a station. The application
programmer does not need to make changes to this display as it is a standardized display.
Figure 106 - Production Data Display
Version 7.0
Page 122 of 141
4.4.16. Production Events Display
The Production Data Display displays standardized production metrics for a station. The application
programmer does not need to make changes to this display as it is a standardized display.
Figure 107 - Production Events Display
Version 7.0
Page 123 of 141
4.4.17. Alarms Display
The Alarms Display displays standardized alarm information for a station. This display allows the
operator to acknowledge machine faults. Finally, this display also provides access to the operator to exit
the panelview application. The application programmer does not need to make changes to this display as
it is a standardized display. This is the only display that does NOT use the global object for the
navigation bar.
Figure 108 - Alarms Display
Version 7.0
Page 124 of 141
4.4.18. Exit Confirmation Pop-Up
The Exit Confirmation Pop-Up provides a mechanism to the operator to exit the panelview application.
The application programmer does not need to make any changes to this display.
Figure 109 - Exit Confirmation
4.5. Recommended Techniques

This section will describe some recommend techniques and tips that may allow the application programmer to
implement a station panelview display more efficiently.
4.5.1. Search and Replace Station Prefix

Each display on the HMI contains standard tags that must be connected to the machine PLC. The standard
station template uses “StationName” as the machine name prefix. When writing the machine PLC code this
was replaced with the name of the machine. All elements in all HMI displays need to also have the PLC
connecting tags modified to replace “StationName” with the station prefix. This can most simply be done by
highlighting all of the elements on a display by pressing “CTL”-“A” with each display open. After selecting all
of the elements on the display the Search/Replace option can be accessed by pressing “CTL”-“R” (Also under
the “Edit” tab “Tag Substitution”). This process needs to be done alternatively to each display separately
while it is open. Each display must be saved after it has been modified. This should be done for all displays
in the HMI including displays that the program developer does nothing else with.
4.5.2. Object Explorer

All elements on the standardized template displays have been named with descriptive names and a suffix that
will identify the type of panelview object the element is. It is recommended that the application programmer
utilize the Object Explorer to access the panelview objects on the displays. Many elements are grouped
and/or stacked and the Object Explorer provides a convenient way to select a particular object without
disturbing the position on the display or the grouping.
Figure 110 - Object Explorer below shows an example Object Explorer display. Note that the groups can be
expanded or collapsed. Table 7 – Object Suffix Naming Convention lists commonly used suffixes and their
meaning.
Version 7.0
Page 125 of 141
Figure 110 - Object Explorer
Table 7 – Object Suffix Naming Convention

Suffix Object Type
_GROUP Group
_MSI Multistate Indicator
_MSP Momentary Pushbutton
_TEXT Text
_POLY Polygon
Version 7.0
Page 126 of 141
4.5.3. Property Panel
The Property Panel provides access to a panelview objects settings. It is especially useful for changing
an elements name or caption.
Figure 111 - Property Panel
4.6. Typical Button Object
This section explains the Typical Button Object. The Typical Button really consists of a Momentary
Pushbutton stacked on top of a Multistate Indicator. The Momentary Pushbutton and Multistate Indicator
are designed to be the same size and look very similar with some subtle differences. This stacked
arrangement was chosen to allow the operator to be able to know the status of an output with the
multistate indicator while the push button is not visible (when control of the motion is not available for
operator control).
The visibility of the Momentary Pushbutton is controlled by the .pvAvail tag of a standard output. The
Momentary Pushbutton is only visible if it is available for operator control. An output may not be
available for control if the machine is not in Manual mode or if some programmed interlock for the output
is active (see section 2.5.3 Digital Output Qualifiers).
Version 7.0
Page 127 of 141
The Multistate Indicator that is below the Momentary Pushbutton is always visible. Both the Multistate
Indicator and the Momentary Pushbutton show an output’s state with their color. The Momentary
Pushbutton and Multistate indicator follow a specific color and caption scheme which must be followed.
This scheme is described below.
Dark Blue = The motion can be performed by pushing the PB (Not in the active position). The
caption will be in the verb form – object (i.e. Lower Station Stop or Extend Arm)
indicating what will happen if the output is to be energized.
Light Blue = The motion is in this position which is not the home position of the motion (In the
‘Extended’ position). The caption for the button once it reached the active position will
be in the form object –verb (past tense) (i.e. Station Stop Lowered or Arm Extended)
indicating the position of the motion.
Green = The motion is in the home position of the motion. The caption for the button once it
reached the active home position will be in the form object –verb (past tense) (i.e.
Station Stop Raised or Arm Retracted) indicating the position of the motion.
Pink = Error State or the motion. The caption should match the de-energized output condition.
A graphical example of the Momentary Pushbutton properties is shown below.
Figure 112 - Typical Button Momentary Pushbutton Properties
The Typical Multistate Indicator follows a similar color and caption scheme as the Momentary
Pushbutton with one exception. The exception is that the border color is gray with the motion is not in
the active position instead of dark blue. This will provide a “Grayed Out” look that indicates to the
operator that the button cannot be pressed. This “Grayed Out Button” will only be visible when the push
button above the Multistate Indicator is not visible (not available). The visibility of the Momentary
Pushbutton is controlled by the .pvAvail tag of a standard output (see section 2.5.3 Digital Output
Qualifiers).
Version 7.0
Page 128 of 141
Grey = Will provide the ‘Grayed Out’ look of the push button when the motion is not in the active
position of the motion but the push button above it is not visible because it is not safe to
move. The caption will be in the form verb – object (i.e. Lower Station Stop or Extend
Arm) indicating what will happen if the output is to be energized.
Light Blue = The motion is in this position which is not the home position of the motion (In the
‘Extended’ position). The caption for the button once it reached the active position will
be in the form object –verb (past tense) (i.e. Station Stop Lowered or Arm Extended)
indicating the position of the motion.
Green = The motion is in this position which is the home position of the motion. The caption for
the button once it reached the active home position will be in the form object –verb (past
tense) (i.e. Station Stop Raised or Arm Retracted) indicating the position of the motion.
Pink = Error State or the motion. The caption should match the de-energized output condition.
A graphical example of the Multistate Indicator properties is shown below.
Figure 113 - Typical Button Multistate Indicator Properties
Please use the color settings below in Figure 115 through Figure 120 for the objects in the typical
button.
Figure 114 – Grey Back & Border Color Settings
Version 7.0
Page 129 of 141
Figure 115 – Dark Blue Back Color Settings
Figure 116 – Dark Blue Border Color Settings
Figure 117 – Light Blue Back Color Settings
Figure 118 – Light Blue Border Color Settings
Version 7.0
Page 130 of 141
Figure 119 – Green Back Color Settings
Figure 120 – Green Border Color Settings
Buttons can be copied from the buttons provided in the template; however, these will then need to be
renamed to follow the example in Figure 121. Please keep button objects grouped together as shown.
Figure 121 – Push Button Naming Example
Version 7.0
Page 131 of 141
The state of the button’s text is controlled by the .pvIndicator tag for the button in the PLC See section
2.5.3 Digital Output Qualifiers).
4.7. Tags
The use of HMI tag definitions within the PanelView application should be avoided. All tags should be
referenced directly from the PLC using an RS-Linx Enterprise configured topic.
Consider the following example. A voltage sensor, LineVoltage, has a mapped tag, AI_LineVoltage.Eng,
within a PLC. A topic, [PLC], is configured in RS-Linx Enterprise pointing to the machine PLC. (It is
preferred to name the topic using the generic name ‘PLC’ as this allows copying and pasting elements
between applications without the need to modify object tag connections.) A numeric indicator is added to
a PanelView display. In the Connection tab of the Properties panel for this indicator, the tag address
referencing the PLC tag can be entered directly into the Value property. In this case, the address would
be: {[PLC] AI_LineVoltage.Eng}
Figure 122 - Example Direct Reference for Panelview
This practice avoids having to define tags within the HMI tag editor, and simplifies maintenance
troubleshooting.
Version 7.0
Page 132 of 141
4.8. Alarms
Setting up alarms for the template panelview application involves two steps: Verifying or creating the Alarm
trigger and then providing a descriptive Message for the alarm. Alarm triggers 0 – 599 for the standardized
Machine.Alarms tag have been pre-built and entered into the Triggers tab of the Alarms setup dialog box.
They can be viewed from the Triggers tab of the Alarm setup dialog as shown below. The alarm descriptions
are delivered to the HMI via PLC tags. When setting up the HMI alarms you will need only to update each of
the sequence descriptions and sequence .ActiveStep tags. This can be done by copying the column into
Excel and changing them with formulas. All alarms will be named in the PLC.
Figure 123 - Alarm Setup: Triggers
Version 7.0
Page 133 of 141
The Message for a corresponding alarm is configured in Messages tab of the Alarm Setup dialog as shown in
the figure below.
Figure 124 - Alarm Setup: Messages
Version 7.0
Page 134 of 141
4.9. Parameter Files
There are multiple parameter files included with the standard template panelview application.
Figure 125 – Parameters
The following needs to be updated in each file by the program developer.
o BrowseSchedule Files
▪ Configuration Control Station Number (Provided by Emerson)
o MessageDiagnostics Files
▪ StationName needs to be replaced with the Station tag prefix used in the PLC.
o Model ParameterPopUp Files
▪ StationName needs to be replaced with the Station tag prefix used in the PLC.
4.10. Communication Setup
The application developer must set the communication path for the Device Shortcut named “PLC”. Shortcut
“PLC” will be directed to the machine plc and this is source for the majority of the displays in the panelview
application. There is a second Device Shortcut in the standard template application named “ConfigCtl”. This
shortcut is for the Configuration Control plc. The application programmer will likely not have the information to
set this path prior to commissioning.
Note that there are two sets of shortcuts that are configured for a panelview plus application. These are
named Design (Local) and Runtime (Target). Design refers to the path used when communicating to the plc
from the development PC or laptop. Runtime refers to the path to the plc that will be used by the actual
Version 7.0
Page 135 of 141
Panelview Plus terminal. Often these paths are the same and button is provided by the dialog to copy the
Design shortcut paths to the Runtime shortcuts.
Figure 126 - Communication Setup: Device Shortcuts
4.11. Multi-Language Support

All operator interfaces will provide multi-lingual support. This will be accomplished utilizing the available multi-
lingual support in RSView ME. It is worth noting that elements of the Standard Development Template have
been designed with this feature in mind, and should not be altered.
When the panelview application has been completed, its strings should be exported using the String Export
wizard. The file generated will then be submitted to Emerson for translation. When exporting strings, be sure
to select “Export … to an Excel spreadsheet” and “Optimize duplicate strings” as shown below.
Figure 127 - Language Configuration: Export Wizard
Version 7.0
Page 136 of 141
Appendix A - User Defined Strings

Name Size Description
CUSTOMERALPHA 12 bytes Five character customer number definition
CUSTOMERORDER 12 bytes Seven character customer order number definition
LONGMODEL 24 bytes Twenty character long model number definition
LOT 20 bytes Fourteen character lot number definition
MODEL 8 bytes Three character short model number definition
OPERATOR 16 bytes Nine character operator identification definition
PARTDESC 20 bytes Fifteen character part description definition
PARTNUMBER 16 bytes Eleven character part number definition
PASSTHRU 20 bytes Sixteen character pass thru definition
SCHEDULE 16 bytes Eleven character schedule number definition
STNNAME 24 bytes 20 character station name
SERIAL 12 bytes Eight character serial number definition
Version 7.0
Page 137 of 141
Appendix B – Standard Routines
Version 7.0
Page 138 of 141
Prefix Description Reference
Contains all JSR instructions.

Program Developer must update
MainRoutine
this file to include any added
routines.
General non-sequenced and
Control_Async 2.11 Non-Sequenced Control
manual control of equipment.
Contains all Alarm and Fault
Faults_Main trigger code. Program Developer 2.6 Alarm Handling
must add all required faults.
Contains Mode control and HMI
HMI_Homing
interface related to Homing.
Contains Station Mode control
HIM_Main and HMI interface for the Main
Display.
Contains Logic for Assigning
Integer Values to User Defined
Config_Constants Constants. Program Developer 2.8 Constants
must update code to include any
added constants.
Contains Logic for mapping of
I/O card images to logical tags.
IO_MappingInput 2.5.1 Digital Inputs
Program developer must update
code to include all Inputs.
Contains Logic for mapping of
logical tags to I/O card images.
IO_MappingOutput 2.5.2 Digital Outputs
Program developer must update
code to include all outputs.
Contains Logic that defines the
motion position, interlocking
logic, and the automatic and
IO_OutputQualifiers manual behavior of a given 2.5.3 Digital Output Qualifiers
output. Program developer must
update code to qualify all
outputs.
Contains logic to define all
conditions and states of the
machine in calculating production
Config_Production_Data 2.17 Production Data
metrics. Program developer
must update code to reflect
machine.
Contains logic associated with
the triggering of the bar code
scanner when a part is detected
at the station pre-stop. Also
Control_Scanner_WIP_Interface included is the logic that initiates 2.9 Station Scanner Interface
the transfer of station data to the
configuration control master by
the main sequence or a manual
operation.
Contains logic to time events that
do not actually occur in a Dry
Sequence_DryCycle Cycle that need to happen for the
program sequence to complete
correctly.
Version 7.0
Page 139 of 141
Contains sequential logic to

move the machine back to a
home state. Program developer
is responsible to write the homing
Sequence_Homing
sequence. Sequence should be
completed with the same
structure as other sequences in
the code.
Contains sequential logic to
Sequence_Main control the operation of the 2.10 Sequential Logic
machine.
Contains Logic for Assigning
System_Assign_CommonConstants Integer Values to Common
Constants
Contains Logic for Evaluating
System_Evaluate_BuildOver This Station, Previous Station,
and Overall Build Over
Structured Text File for Setting

System_FaultsProcess
Active Alarm States
Contains Logic for the Collection

System_Production_Data
of Production Data
Contains Logic to Process

System_Receive_Operator
Operator Reply Messages
Contains Logic to Process Pass

System_Receive_PassThru
Thru Reply Messages
Contains Logic to Process

System_Receive_Schedule
Schedule Reply Messages
Contains Logic to Process WIP

System_Receive_WIP
Model Reply Messages
Contains Logic to Send Operator

System_Request_Operator Request Messages to the
Contains Logic to Send Schedule
System_Request_Schedule Request Messages to the
Contains Logic for Syncing

System_Time_Sync
Station Clocks to a Master Clock
Contains Logic to Request the

System_Trigger_Scanner Triggering of the Station’s Fixed-
Head Scanner
Contains Logic to Collect Overall

System_Update_OEE
Equipment Effectiveness Data
Contains Logic to Send

System_Update_WIP Compressor Status Messages to
Contains Logic Required for

System_Verify_Parts
Parts Verification
Version 7.0
Page 140 of 141
Contains Logic Required for

System_Verify_Tooling
Tooling Verification
Contains Logic that the Program

Config_Verify_Tooling Developer must modify to verify 2.18 Tooling Verification
the station tooling.
Version 7.0
Page 141 of 141

Programming Standard Specification 7x04

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Programming Standard Specification 7x04

Uploaded by

Copyright:

Available Formats

Scroll Assembly Programming Standard Specification

Title: “Scroll Assembly Programming Standard Specification”

Revision Date Comments Released By

1.0 3/08/2006 Initial Release D. Strength

7.04 3/22/18 Fortress System for entry doors E. Slonkosky

1. CONTROL SPECIFICATION OVERVIEW .................................................................. 9

1.2. Scope, Roles, and Definitions ................................................................................................................. 9

1.3. System Architecture .............................................................................................................................. 10

2. CONTROL SYSTEM SPECIFICATIONS .................................................................. 12

2.2. Standard Development Template ........................................................................................................ 12

2.3. General Control File Structure ............................................................................................................ 12

2.6. Alarm Handling ..................................................................................................................................... 26

2.7. Operator Notification Handling ........................................................................................................... 32

2.9. Station Scanner Interface ..................................................................................................................... 38

2.10. Sequential Logic .................................................................................................................................... 39

2.11. Non-Sequenced Control and Safety ..................................................................................................... 47

2.12. Manual Control ..................................................................................................................................... 49

2.13. Configuration Control Interface .......................................................................................................... 49

2.14. User Defined Types ............................................................................................................................... 57

2.15. Interface Routines ................................................................................................................................. 60

2.16. Standard Sequence Steps ...................................................................................................................... 64

2.17. Production Data .................................................................................................................................... 87

2.18. Tooling Verification .............................................................................................................................. 88

2.19. Best Practices ......................................................................................................................................... 91

3. ROBOT INTERFACE/PROGRAMMING ................................................................... 93

3.1. Robot Communications ........................................................................................................................ 93

3.2. Robot Safety........................................................................................................................................... 93

3.3. PLC Programming ................................................................................................................................ 93

4.2. Standard Interface ................................................................................................................................ 97

4.3. Standard Development Template ........................................................................................................ 97

4.4. Displays .................................................................................................................................................. 98

4.5. Recommended Techniques ................................................................................................................. 125

4.5.1. Search and Replace Station Prefix..................................................................................................... 125

4.5.2. Object Explorer ................................................................................................................................... 125

4.5.3. Property Panel ..................................................................................................................................... 127

4.6. Typical Button Object ......................................................................................................................... 127

4.7. Tags ...................................................................................................................................................... 132

4.8. Alarms .................................................................................................................................................. 133

4.9. Parameter Files.................................................................................................................................... 135

4.10. Communication Setup ........................................................................................................................ 135

4.11. Multi-Language Support .................................................................................................................... 136

APPENDIX A - USER DEFINED STRINGS ...................................................................... 137

APPENDIX B – STANDARD ROUTINES .......................................................................... 138

1. Control Specification Overview

• Robust operation within production environment.

• Standardized integration with other facility systems.

• Efficient long-term maintenance by facility personnel.

1.2. Scope, Roles, and Definitions

1.3. System Architecture

A general overview of the general plant architecture is presented in Figure 1 below:

Figure 1 - Network Overview

2. Control System Specifications

2.1. Control Hardware

2.1.1. Process Controllers

2.1.2. Communication Networks

2.2. Standard Development Template

2.3. General Control File Structure

All PLC code, tags, and comments shall be provided in English.

2.3.1. Routine Naming

Table 1 - Routine Naming Prefixes

Faults_ Faults_Main Alarm and Fault trigger routines.

Config_ Config_Constants Configuration Parameter logic.

Control_Async General non-sequenced and manual control of

System_Assign_CommonConstants System routines providing functions for other