FactoryTalk Batch PCD Programming (Publication# BATCH

Publication# BATCH-RM004B-EN-D - May 2022 Supersedes Publication# BATCH-RM004A-EN-D - October 2020

Reference Manual Original Instructions

FactoryTalk Batch PCD Programming Reference Manual FactoryTalk Batch 15.00

FactoryTalk Batch PCD Programming Reference Manual

2 Publication# BATCH-RM004B-EN-D - May 2022

Important User Information Read this document and the documents listed in the additional resources section about installation, configuration, and operation of this equipment before you install, configure, operate, or maintain this product. Users are required to familiarize themselves with installation and wiring instructions in addition to requirements of all applicable codes, laws, and standards.

Activities including installation, adjustments, putting into service, use, assembly, disassembly, and maintenance are required to be carried out by suitably trained personnel in accordance with applicable code of practice.

If this equipment is used in a manner not specified by the manufacturer, the protection provided by the equipment may be impaired.

In no event will Rockwell Automation, Inc. be responsible or liable for indirect or consequential damages resulting from the use or application of this equipment.

The examples and diagrams in this manual are included solely for illustrative purposes. Because of the many variables and requirements associated with any particular installation, Rockwell Automation, Inc. cannot assume responsibility or liability for actual use based on the examples and diagrams.

No patent liability is assumed by Rockwell Automation, Inc. with respect to use of information, circuits, equipment, or software described in this manual.

Reproduction of the contents of this manual, in whole or in part, without written permission of Rockwell Automation, Inc., is prohibited.

Throughout this manual, when necessary, we use notes to make you aware of safety considerations.

WARNING: Identifies information about practices or circumstances that can cause an explosion in a hazardous environment, which may lead to personal injury or death, property damage, or economic loss.

ATTENTION: Identifies information about practices or circumstances that can lead to personal injury or death, property damage, or economic loss. Attentions help you identify a hazard, avoid a hazard, and recognize the consequence.

IMPORTANT Identifies information that is critical for successful application and understanding of the product.

Labels may also be on or inside the equipment to provide specific precautions.

SHOCK HAZARD: Labels may be on or inside the equipment, for example, a drive or motor, to alert people that dangerous voltage may be present.

BURN HAZARD: Labels may be on or inside the equipment, for example, a drive or motor, to alert people that surfaces may reach dangerous temperatures.

ARC FLASH HAZARD: Labels may be on or inside the equipment, for example, a motor control center, to alert people to potential Arc Flash. Arc Flash will cause severe injury or death. Wear proper Personal Protective Equipment (PPE). Follow ALL Regulatory requirements for safe work practices and for Personal Protective Equipment (PPE).

Rockwell Automation recognizes that some of the terms that are currently used in our industry and in this publication are not in alignment with the movement toward inclusive language in technology. We are proactively collaborating with industry peers to find alternatives to such terms and making changes to our products and content. Please excuse the use of such terms in our content while we implement these changes.

Publication# BATCH-RM004B-EN-D - May 2022 3

Table of Contents

About this manual ....................................................................................... 11 Document organization ............................................................................. 11 Legal Notices ............................................................................................... 11 Additional resources .................................................................................. 12

Chapter 1 Batch manufacturing system .................................................................... 15

FactoryTalk Batch ................................................................................. 16 Phases .................................................................................................... 16

PLI ................................................................................................... 17 Phase logic ...................................................................................... 19

Basic control ........................................................................................ 20 HMI ...................................................................................................... 20

Chapter 2 Design philosophy ..................................................................................... 21 FactoryTalk Batch requirements of the phase (PLI and phase logic)..... 22

Function of the PLI .............................................................................. 22 Function of the phase logic................................................................. 22

Chapter 3 State transition diagram ........................................................................... 23

Phase states........................................................................................... 24 Active states ................................................................................... 24 Quiescent states ............................................................................ 26

Communication protocol states ........................................................ 27 State transitions ........................................................................................ 27

Chapter 4 Phase logic API tags ................................................................................... 29 FactoryTalk Batch commands................................................................... 29

Chapter 5 Obey the state transition diagram ............................................................ 33 Support the command handshake protocol ............................................ 33

Command handshake protocol ........................................................... 34 The command tag’s high byte.............................................................. 35

Example - No command ID in high byte ...................................... 35 Example - Command ID in high byte ........................................... 37

Summary of the command handshake protocol .............................. 40 Tags used in the command handshake protocol ........................ 40

Preface

FactoryTalk Batch and PCD phase logic introduction

The FactoryTalk Batch – PCD interface

State transition logic

Tags and commands

PLI communications protocols

Table of Contents


Follow the phase logic request protocol .................................................... 41 Phase logic request protocol ............................................................... 42

Example - Request tag immediately reset to zero ...................... 42 Example - Request tag receives intermediate value ....................45

Abort phase logic requests ................................................................... 47 Tags used in the phase logic request protocol ............................ 48 Miscellaneous ................................................................................ 49

Support for Semi-Auto functionality ....................................................... 49 Semi-Auto functionality ..................................................................... 50

Tags used with the Semi-Auto functionality ............................... 51 Support for the NEW_PARAMETERS command ................................... 52

NEW_PARAMETERS command ........................................................ 52 Tags used with the NEW_PARAMETERS command .................. 53

Support for the Program/External attribute ............................................ 53 Program/External attribute ................................................................54

Tags used with the Program/External attribute.......................... 55 Support for the failure protocol ................................................................ 55 Support for the watchdog protocol ...........................................................56

Standard watchdog protocol ...............................................................56 Standard watchdog protocol problems ....................................... 58

Enhanced watchdog protocol ..............................................................59 Watchdog period ................................................................................. 60

Tags used in the watchdog protocol ............................................ 62 Tags used for state transitions .................................................................. 63 Optional PLI Boolean communication with the phase ........................... 63 Tags used in the Failure protocol ............................................................. 64

Chapter 6 Download parameters ............................................................................... 66

Phase parameter tags array ................................................................. 67 Types of Download Parameter requests ............................................. 68 All phase parameter values ................................................................. 68 Range of phase parameter values ...................................................... 68 Range of phase parameter values - Indirect ..................................... 68 Single phase parameter value ............................................................ 69 Single phase parameter value - Indirect ........................................... 69 Single phase parameter value - Specify location .............................. 70 Single phase parameter value - Indirect/specify location ................ 70 Subset of parameter values ................................................................. 71 Subset of parameter values – Download on Start .............................. 71 Subset of parameter values – Download on TOC .............................. 71

Download report limits ............................................................................. 72

Request data from the FactoryTalk Batch Server

Table of Contents


Types of download Report Limits requests ....................................... 72 All report limits information .............................................................. 72 Download single report parameter limits configuration ................. 73

Upload report values .................................................................................. 73 Report array .......................................................................................... 74 Electronic batch record entries ........................................................... 74 Types of upload report requests .......................................................... 75 All report values .................................................................................... 75 Range of report parameter values....................................................... 75 Range of report values - Indirect ........................................................ 75 Single report parameter value.............................................................76 Single report value - Indirect ..............................................................76 Single report parameter value - Specify location .............................. 77 Single report parameter value - Indirect/specify location ................ 77 Subset of report values......................................................................... 77 Subset of report parameter values - Upload on Terminal State ...... 78 Subset of report values - Upload on TOC .......................................... 78

Send messages to the operator and clear messages ............................... 78 Send message .......................................................................................79 Send a message - Indirect....................................................................79 Clear message .......................................................................................79

Acquire resources .......................................................................................79 Types of acquire requests ................................................................... 80 Acquire a single resource .................................................................... 80 Acquire a single resource - Indirect ................................................... 80 Acquire multiple resources ................................................................. 80

Release resources........................................................................................ 81 Types of release requests ..................................................................... 81 Release a single resource ..................................................................... 81 Release a single resource - Indirect .................................................... 81 Release multiple resources ................................................................. 82 Release all currently acquired resources ........................................... 82

Send messages to other phases ................................................................ 82 Completion of messages ..................................................................... 83 Process Send and Receive messages .................................................. 83 Types of messages to other phases .................................................... 83 Send a message ................................................................................... 84 Send a message - Indirect................................................................... 84 Send a message and wait .................................................................... 84 Send a message and wait - Indirect ................................................... 85 Send a message and wait for one receiver ........................................ 85 Send a message and wait for one receiver - Indirect ....................... 86

Table of Contents


Cancel messages to other phases ............................................................. 86 Types of cancel message requests ...................................................... 86 Cancel a single message...................................................................... 86 Cancel a message - Indirect ................................................................ 87 Cancel all messages ............................................................................. 87

Receive message from linked phases ....................................................... 87 Receive a message from a linked phase ............................................. 87 Receive a message from a linked phase - Indirect ............................ 88

Abort request ............................................................................................. 88 Download batch data ................................................................................ 88 Generate an electronic signature request ............................................... 89

General Signature request - Indirect ................................................. 89 Download material-based data ................................................................ 90

Chapter 7 Standard attributes.................................................................................... 91

Material standard attributes ............................................................... 91 Lot standard attributes ........................................................................ 92 Container standard attributes ............................................................ 93

Custom attributes ...................................................................................... 93 Material custom attribute fields ......................................................... 93 Lot custom attribute fields ................................................................. 94 Container custom attribute fields ..................................................... 94

Write a material phase ...............................................................................95 Upload data constraints ......................................................................97

Material server requests.............................................................................97 Use the enhanced phase logic requests ..............................................97

Requests for data from the recipe execution environment ................... 98 Download data from container currently in use – 7801 request...... 99 Download data from material in container currently in use – 7802 request................................................................................................ 100 Download data from lot in container currently in use – 7803 request ............................................................................................................. 101 Upload container data into container currently in use – 7811 request .............................................................................................................102 Upload material data into material in container currently in use – 7812 request ........................................................................................ 103 Upload lot data into lot in container currently in use – 7813 request ............................................................................................................. 104

Identify the lot .............................................................................. 104 Download the current binding’s container selection priority – 7821 request................................................................................................. 106

Request data from the Material Server

Table of Contents


Upload a container selection priority for the current binding – 7822 request................................................................................................. 107 Download sufficient material data – 7831 request ........................... 107

Requests for data from the material database ...................................... 108 Download one attribute of a material - 80NN request series ........ 108 Download lot attributes – 81NN request series ............................... 109 Download container attributes – 83NN request series ................... 110 Download container priority assignments – 84NN request series 112 Upload material attributes – 85NN request series .......................... 112 Upload lot attributes – 86NN request series .................................... 114 Upload container attributes – 88NN request series ........................ 115 Upload container priority assignments – 89NN request series...... 116

Chapter 8 About process modules ............................................................................. 119

Unit...................................................................................................... 120 Phase ...................................................................................................120 Control module ..................................................................................120

Define tags ................................................................................................120 Define resources .......................................................................................120 Modularization criteria............................................................................ 121

Purpose ............................................................................................... 121 Use ....................................................................................................... 121 Portability ........................................................................................... 121 Flexibility ............................................................................................ 121 Independence ..................................................................................... 122 Expansion ........................................................................................... 122 Isolation .............................................................................................. 122 Physical process constraints ............................................................. 122

Identify the phases in the selected process ............................................ 122 P & ID drawing example .................................................................... 123

Unit #2 phases .............................................................................. 124

Chapter 9 Allocate phase memory tags .................................................................... 125

Steps to allocate phase memory tags ................................................ 126 Phase memory tags ............................................................................ 126 Parallel vs. sequential programming for phase logic ...................... 127 Semi-Auto ........................................................................................... 128 Pause ................................................................................................... 129 Treat modules as objects .................................................................... 129

Modules of code ........................................................................................ 130

Modularize the process

Program phase logic

Table of Contents


Obey the state transition diagram .....................................................131 Project-specific phase logic ................................................................131

Phase logic modules ................................................................................. 132 Running logic ..................................................................................... 133 Holding logic ...................................................................................... 135 Aborting logic ..................................................................................... 136 Stopping logic ..................................................................................... 137 Restarting logic .................................................................................. 139

Chapter 10 Communications interface ...................................................................... 141

Required phase tags ........................................................................... 142 Communication from the FactoryTalk Batch Server ............................ 143 Communication from the phase logic .................................................... 143 Watchdog communication ...................................................................... 145 PLI variables .............................................................................................. 145 Phase logic variables................................................................................. 147 PLI configuration parameters ................................................................. 148 Program the PLI ....................................................................................... 149

PLI response to watchdog event ....................................................... 149 Process non-state commands and events for a phase ..................... 150 PLI response to a CLEAR_FAILURE command ............................... 150 PLI response to a REQ_COMPLETE command ............................... 150 PLI response to a REQ_ABORTACK command ............................... 150 PLI response to a REQ_ABORTFAIL command ............................... 150 PLI response to a REQ_RESET command ....................................... 151 PLI response to a REQ_FAILED command ...................................... 151 PLI response to a SEMI_AUTO command ....................................... 151 PLI response to a RESUME command ............................................. 151 PLI response to a NEW_PARAMETERS command ......................... 151 PLI phase state processing ................................................................ 152

ABORTING ................................................................................... 152 HOLDING ..................................................................................... 152 STOPPING .................................................................................... 154 RESTARTING ............................................................................... 154 RUNNING .................................................................................... 156 HELD ............................................................................................ 157 COMPLETE .................................................................................. 157 STOPPED ...................................................................................... 158 ABORTED ..................................................................................... 158 IDLE .............................................................................................. 159

Phase Logic Interface

Table of Contents


Appendix A SFC graphical structures .......................................................................... 161 SFC execution........................................................................................... 162 Rules for building an SFC ........................................................................ 163 Benefits of an SFC .................................................................................... 163

Appendix B Commonly used tag names ......................................................................165

Appendix C Structured text phase template ............................................................... 167

Appendix D Full PLI example ........................................................................................ 171

Build a sequential function chart

Tag naming conventions

Structured text phase template

Structured text full PLI exampleIndex


Preface

This manual provides information and instructions about the FactoryTalk Batch PCD interface design. It is intended to be used as a reference guide. This manual is one of a set of related manuals that describe installing, programming, and operating the FactoryTalk Batch system.

To review FactoryTalk Batch release notes and latest information regarding product compatibility refer to the Product Compatibility and Download Center (PCDC).

The following subjects are presented in this document:

• PCD phases and interface• State transition logic• Phase tag and command definitions • Communication protocols • Communication with the FactoryTalk Batch Server• Steps to program phases or phase logic• Phase logic interface• Sequential function charts (SFCs)

Rockwell Automation publishes legal notices, such as privacy policies, license agreements, trademark disclosures, and other terms and conditions on the Legal Notices page of the Rockwell Automation website.

End User License Agreement (EULA) You can view the Rockwell Automation End User License Agreement (EULA) by opening the license.rtf file located in your product's install folder.

The default location of this file is:

C:\Program Files (x86)\Common Files\Rockwell\license.rtf

Open Source Software Licenses The software included in this product contains copyrighted software that is licensed under one or more open-source licenses.

You can view a full list of all open-source software used in this product and their corresponding licenses by opening the oss_license.txt file located your

About this manual

Document organization

Legal Notices

https://compatibility.rockwellautomation.com/Pages/home.aspx

https://compatibility.rockwellautomation.com/Pages/home.aspx

https://www.rockwellautomation.com/global/legal-notices/overview.page

Preface


product's OPENSOURCE folder on your hard drive. This file is divided into these sections:

• Components Includes the name of the open-source component, its version number,and the type of license.

• Copyright Text Includes the name of the open-source component, its version number,and the copyright declaration.

• Licenses Includes the name of the license, the list of open-source componentsciting the license, and the terms of the license.

The default location of this file is:

C:\Program Files (x86)\Common Files\Rockwell\Help\<product name>\Release Notes\OPENSOURCE\oss_licenses.txt

You may obtain Corresponding Source code for open-source packages included in this product from their respective project web site(s). Alternatively, you may obtain complete Corresponding Source code by contacting Rockwell Automation via the Contact form on the Rockwell Automation website: http://www.rockwellautomation.com/global/about-us/contact/contact.page. Please include "Open Source" as part of the request text.

Following is a comprehensive list of documentation for the FactoryTalk® Batch products from Rockwell Automation.

Installation, Quick Start, and Getting Results Guides Resource Description

FactoryTalk Batch Components Installation and Upgrade Guide (BATCH-IN002)

Provides information and procedures for FactoryTalk Batch system installation. Includes information for FactoryTalk Batch Material Manager, FactoryTalk Event Archiver, and associated FactoryTalk Batch Client and Server components.

FactoryTalk Batch View Quick Start Guide (FTBVS-QS001)

Provides information about using FactoryTalk Batch View to create, view, and command control recipes, acknowledge prompts and signatures, view equipment phases and diagnostic information, and view profile information.

FactoryTalk Batch View HMI Controls Quick Start Guide (BATCH-QS001D)

Provides a general overview of FactoryTalk Batch View HMI Controls.

FactoryTalk Batch eProcedure® Getting Results Guide (BWEPRO-GR011)

Explains the basics of FactoryTalk Batch eProcedure.

FactoryTalk Batch Getting Results Guide (BATCH-GR011)

Introduces the basics of automated batch manufacturing and the FactoryTalk Batch product components.

Additional resources

http://www.rockwellautomation.com/global/about-us/contact/contact.page

http://www.rockwellautomation.com/global/about-us/contact/contact.page

Preface


Resource Description

FactoryTalk Batch Material Manager Getting Results Guide (BWMTR-GR011)

Introduces the basics of FactoryTalk Batch Material Manager.

User Guides Resource Description

FactoryTalk Batch Material Editor User Guide (BWMTR-UM001)

Provides access to information and procedural instructions required to configure materials and the containers to hold them. The material data is stored in the material database, which is used to create material-based recipes. This information is intended as a reference for formulators.

FactoryTalk Batch Equipment Editor User Guide (BATCH-UM004)

Provides information on creating and maintaining an equipment database (area model). The area model is available to all other FactoryTalk Batch programs, including the Recipe Editor, Batch View, and Phase Simulator.

FactoryTalk Batch PhaseManager™ User Guide (BATCHX-UM011)

Describes the integration of the FactoryTalk Batch software with the Studio 5000 Logix Designer® application and the Logix 5000™ family of controllers. The integration simplifies the configuration and maintenance of the FactoryTalk Batch automation system, provides better communication between the FactoryTalk Batch Server and the Logix 5000 controller, and significantly reduces the programming effort required to develop the phase logic code that resides in your Logix 5000 controller.

FactoryTalk Batch Recipe Editor User Guide (BATCH-UM006)

Provides instructions on using FactoryTalk Batch Recipe Editor to create and configure master recipes for use in batch automation. The interface is based on IEC 61131-3 sequential function charts to organize recipes graphically into procedures, unit procedures, operations, and phases. Build recipes using either the SFC format or a table-based format.

FactoryTalk Batch View HMI Controls User Manual (FTBVS-UM003)

Provides details about using FactoryTalk Batch View HMI Controls to monitor and interact with the production process within a FactoryTalk View SE Display Client.

FactoryTalk Batch View User Manual (FTBVS-UM002)

Provides information and procedural instructions for using FactoryTalk Batch View in a modern and intuitive portal into a comprehensive batching solution for effective operations, leveraging its own web server using HTML5 technology to provide connectivity into a FactoryTalk Batch Server.

FactoryTalk Event Archiver User Guide (BATCH-UM012)

Provides information and instructions specific to the FactoryTalk Event Archiver. Intended for use by system administrators and production supervisors.

Administrator Guides Resource Description

FactoryTalk Batch Administrator Guide (BATCH-UM003)

Provides instructions for configuring security and services, and implementation and use of components not typically accessed or used by batch operators, such as the FactoryTalk Batch Server.

FactoryTalk Batch eProcedure Administrator Guide (BWEPRO-UM011)

Provides procedures specific to FactoryTalk Batch eProcedure, such as implementing security and configuring the user-defined area Active Server Page. Included are instructions for tasks specific to FactoryTalk Batch, such as configuring security and services to support FactoryTalk Batch eProcedure. Provides instructions on the implementation and use of components not typically accessed or used by batch operators, such as the FactoryTalk Batch Server.

FactoryTalk Batch Material Manager Administrator Guide (BWEPRO-UM011)

Provides information and instructions specific to FactoryTalk Batch Material Manager. Intended for use by system administrators and database administrators.

Preface


Reference Guides Resource Description

FactoryTalk Batch Material Server API Technical Reference (BWMTR-RM001)

Provides access to information regarding the interface between the FactoryTalk Batch Material Server and the FactoryTalk Batch Material Editor and FactoryTalk Batch. It is intended to be used as a reference information by custom interface developers.

FactoryTalk Batch PCD Programming Reference Manual (BATCH-RM004)

Provides information and instructions about the FactoryTalk Batch PCD interface design. It is intended to be used as a reference guide for PCD programmers.

FactoryTalk Batch Server API Reference Manual (BATCH-RM003)

Provides information regarding the interface between the FactoryTalk Batch Server and FactoryTalk Batch View — the Server Application Programming Interface (API). It is intended to be used as a reference guide by custom interface developers.

FactoryTalk Batch System Files Reference Manual (BATCH-RM005)

Provides the technical information for configuration and maintenance of a FactoryTalk Batch system. It can be used as a reference information for implementation engineers and system administrators.

FactoryTalk Batch eProcedure Instruction File Design Reference Manual (BWEPRO-RM001)

Includes information about the building of instruction files for use in equipment database creation and recipe development. This information is intended to be used as a reference by instruction file authors.

View or download publications at http://www.rockwellautomation.com/literature. To order paper copies of technical documentation, contact your local Allen-Bradley® distributor or sales representative.

Rockwell Automation recognizes that some of the terms that are currently used in our industry and in this publication are not in alignment with the movement toward inclusive language in technology. We are proactively collaborating with industry peers to find alternatives to such terms and making changes to our products and content. Please excuse the use of such terms in our content while we implement these changes.

https://www.rockwellautomation.com/literature


Chapter 1

FactoryTalk Batch and PCD phase logic introduction

IMPORTANT The information in this guide only applies to programming phase logic for OPC and FactoryTalk Live Data phases. For information on developing phase logic in PhaseManager phases assigned to a Logix5000 CIP data server, see the FactoryTalk Batch PhaseManager User Guide or the Logix 5000 Controllers PhaseManager User Manual.

FactoryTalk Batch is an automated batch processing application that allows for control of batch process by communicating with process-connected devices (PCD). Communication is enabled when a PCD contains phases that meet a specific set of criteria. First, phases must have a phase logic interface (PLI) that complies with a specific set of protocols. Second, phases must contain project-specific logic that communicates with the FactoryTalk Batch Server through the PLI using a standard set of data items.

This document provides an overview of the FactoryTalk Batch-PCD interface and the specific information used to develop that interface.

A typical batch system includes the FactoryTalk Batch software, HMI software, a phase logic program, basic control for plant hardware, and an interface program that allows the FactoryTalk Batch software to interface with the phase logic. The figure below depicts the relationships between these system components in a sample batch manufacturing system:

Batch manufacturing system

Chapter 1 FactoryTalk Batch and PCD phase logic introduction


FactoryTalk® Batch is the most powerful solution available for batch automation. Developed around S88.01, the ISA international standard for batch control, FactoryTalk Batch uses modular batch automation to make jobs easier for all types of process professionals. FactoryTalk Batch is an open system that lets you choose the hardware, software,and control system required to create a complete batch automation solution.

The following describes the main components of FactoryTalk Batch:

• FactoryTalk Batch Recipe Editor: Used to organize and configurerecipes. You can graphically construct recipes using sequentialfunction charts (SFCs).

• FactoryTalk Batch Equipment Editor: Used to configure the areamodel and create a graphical representation of the processequipment. The components defined in the area model to interfacewith the process-connected devices in the facility.

• FactoryTalk Batch Server: The core of the system, using a View/Serverarchitecture. The server allows for integration with process-connecteddevices and other software packages.

• FactoryTalk Batch View: Used to create batches from master recipes,execute the batches, and review batch-related information. It isdesigned to work in conjunction with a Human-Machine Interface(HMI) application.

• FactoryTalk Batch View HMI Controls: Used to monitor and interactwith the batch production process within a FactoryTalk View SEDisplay Client.

Phases are programmed with the following two components:

• Phase logic interface (PLI)• Phase logic

FactoryTalk Batch

Phases



The figure below depicts the relationship between the FactoryTalk Batch Server, the PLI, and the site-specific phase logic. The PLI should reside in the project-specific controller and provide a standard interface to FactoryTalk Batch.

The Phase Logic Interface (PLI) is a layer of software and a previously-defined data structure between the phase logic and FactoryTalk Batch. The PLI contains the state transition logic that directs the project-specific phase logic.

The PLI may have multiple instances that communicate with multiple phases, or a single PLI subroutine may be reused for every phase.

PLI



Multiple instances This figure illustrates the use of a dedicated PLI structure for each custom phase.

Single instance This figure illustrates a single PLI residing in the controller that can be used as a common subroutine for servicing all of the PCD’s phases. In this configuration, the PLI subroutine is called once for each instance of a phase. This reduces the amount of code in the controller as well as commissioning time.

PLI

Add A

PLI

Add B

PLI

HeatReactor A

PLI

DischargeHeat Reactor

Computer

PLC orProcessController

BatchServer

Add A Add B HeatReactor A

DischargeHeat Reactor

Computer

PLC orProcessController

PLI

BatchServer



A batch PLI consists of two components:

• Communications Interface: The data structure necessary for movingcommands and requests between the FactoryTalk Batch Server, the PLIand the phase logic.

• State Transition Logic: Code that defines the sequence of states andtransitions in the project-specific phase logic.

Phase logic is responsible for sending messages to phases and control modules (CM) to perform a process-oriented action. Phase logic is the project-specific code that contains the control steps; for example, open a valve, start a pump, or stop a totalizer.

The project-specific phase logic contains small modules of code that implement the operating sequences and a failure detection module for each phase.

Modules of code The following six modules of code must be programmed:

• RUNNING• ABORTING• RESTARTING• STOPPING• HOLDING• FAILURE DETECTING

Execution of the code modules is controlled by tags that are set by the state transition logic, a component of the PLI. When these modules of code terminate, a tag is set that indicates completion. This tag is read by the state transition logic in the PLI, allowing it to transition to the next state.

The figure below illustrates the relationship between the project-specific phase logic, the FactoryTalk Batch PLI and basic control. The project-specific phase logic resides in the process-connected device (PCD).

Process-ConnectedDevice

BatchPhase Logic Interface

Basic Control

Product-SpecificLogic

Project-SpecificLogic

Project-SpecificBasic Control

Phase Logic

Phase logic



Basic control consists of software modules that provide control of the equipment in the facility. This includes EMs, CMs, and interlocking logic. For example, a pump CM would control the starting, stopping, interlocking, and alarming for a pump device.

The Human-Machine Interface (HMI) is the process control software that allows the user to view the graphical representation of all the automated devices in the selected plant. The HMI displays each configured piece of equipment and enables the interaction with the plant environment. The HMI also offers the user the ability to manually control the devices displayed on the screens.

Basic control

HMI


Chapter 2

The FactoryTalk Batch – PCD interface

Communication between FactoryTalk Batch and the process-connected device (PCD) is accomplished using a set of protocols that are built into the FactoryTalk Batch Server. The protocols were developed around a general set of rules that enable the server to communicate with virtually any PCD. The design ensures extremely reliable communication and substantially reduces the effort required for phase logic programming.

Generally, FactoryTalk Batch requires a phase logic interface (PLI) in the PCD to enforce specific rules, such as the state transition diagram and the handshaking protocols. Phase logic handles project-specific requirements.

This section defines the philosophy behind the FactoryTalk Batch-PCD interface design, including the primary functions of the PLI and the phase logic.

The FactoryTalk Batch-PCD interface design was kept simple, allowing for the reading and writing of integer values to and from tags. It allows for two-way communication between FactoryTalk Batch and the PCD. FactoryTalk Batch can give commands to phase logic and phase logic can make requests from FactoryTalk Batch. A robust handshaking protocol between the FactoryTalk Batch Server and the phase is built into the interface to ensure the reliability of this two-way communication.

In general, phase logic has control over application-specific events. FactoryTalk Batch starts the phase logic, but after that the phase logic takes control over all other events. The phase logic accomplishes this by performing application-specific actions, such as requesting the server to upload reports and download parameters. There is a limit of 998 parameters and 998 reports that may be used by a phase.

The FactoryTalk Batch Server has a relatively sophisticated set of services it can provide to the phase. These services allow phase programmers to write encapsulated code. This dramatically simplifies the programming effort required for phase logic development. Furthermore, it allows separate phases to be resident in separate PCDs, even those that cannot facilitate peer-to-peer communication.

Finally, the interface generally expects a PLI to be used as the means of communication between the server and the phase logic. The PLI may reside in the PCD or on a personal computer (for example, PC-based phases). The PLI is

Design philosophy

Chapter 2 The FactoryTalk Batch – PCD interface


expected to enforce the state transition diagram and the handshaking protocols.

FactoryTalk Batch requires phases to conform to specific criteria. The following is an overview of these requirements:

• Phases must follow the state transition diagram (STD).• Phases must have a set of tags.• Phases must follow the FactoryTalk Batch-PCD interface protocols.• Phases must use the request protocol to access the services provided by

FactoryTalk Batch.

Generally, a PLI is expected to be used as the interface between FactoryTalk Batch and the phase logic. The PLI functions as a standard part of the phase logic, handling the FactoryTalk Batch protocol concerns and making it possible for the project programmer to focus more on the project-specific requirements of the code. The PLI should be written to include the following functions:

• Expose a set of Application Program Interface (API) tags that theFactoryTalk Batch Server can write to and read from.

• Implement and enforce the state transition diagram.• Handle ownership issues between FactoryTalk Batch and an external

device. • Execute communications verification and timeout logic. • Handle the failure protocol. • Handle the watchdog protocol.

Phase logic, which is designed to interact with FactoryTalk Batch, must meet specific requirements. The phase logic should be written implementing a user-defined sequence set for direct control of process equipment to accomplish some process-oriented task (for example: add, mix, heat). These sequences will perform normal logic as well as abnormal and shut-down logic. Finally, the phase logic should include logic that allows for failure detection and reporting of the step sequence.

FactoryTalk Batch requirements of the phase (PLI and phase logic)

Function of the PLI

Function of the phase logic


Chapter 3

State transition logic

The state transition logic is the logic within the PLI that provides a standard interface to the project-specific phase logic. The state transition logic receives commands from the FactoryTalk Batch Server or the operator and initiates the appropriate components of the project-specific phase logic.

The state transition diagram depicts the active and quiescent states that are supported by the PLI and the legal transitions between states. The PLI and phase logic must adhere to the rules of the state transition logic. Only valid state transitions, as displayed in the following diagram, may be used. The addresses applied to the PLI will vary site-to-site, but the logical constructs should conform to the state transition logic.

State transition diagram

Chapter 3 State transition logic


Phase logic is expected to exhibit state behavior as shown in the state transition diagram below.

There are ten states recognized by the FactoryTalk Batch Server; they are categorized into active states and quiescent states.

RUNNING This is the normal active state of the phase. The phase logic is processing its normal execution path. For example, with a material charge phase, the phase logic might be sequencing valves and pumps, and monitoring flow meters or load cells.

Legal Commands HOLD Transition to HOLDING

STOP Transition to STOPPING ABORT Transition to ABORTING

Sequencing Complete Transition to COMPLETE Failure Response Transition to HOLDING

RUNNING

PAUSING

PAUSED

Semi_Auto

SEMI_AUTOIDLE

LOGIC

ProgrammedBreak

RESTART

HELDHOLDING

EXECUTING

Resume

HoldFail

Done

R

Done

STOPPING

Stop

ABORTI

STOPPED

Done

ABORTCOMPLETE

TERMINATED

REQUESTSREQUESTPENDING

ABORTPENDINGDORMANT

RESETPENDING

Request Abort

Reset

Request no

Semi_Auto

Done

Start

Phase states

Active states



HOLDING The phase logic is performing the necessary logic to transition phase devices to a safe state from which batch execution may later be resumed. The actual sequencing necessary may vary depending on the phase’s device and logic state when the transition to the HOLDING state occurred.

Legal Commands STOP Transition to STOPPING

ABORT Transition to ABORTING Sequencing Complete Transition to HELD Failure Response None

RESTARTING The phase logic is performing the necessary logic to transition from a HELD state back to the normal execution path. The actual sequencing necessary may vary depending on how far the phase logic processing has progressed prior to the transition of the phase logic to the HELD state.

Legal Commands HOLD Transition to HOLDING

STOP Transition to STOPPING ABORT Transition to ABORTING

Sequencing Complete Transition to RUNNING Failure Response Transition to HOLDING

STOPPING The phase logic is performing the necessary logic for a controlled transition from the current state to a safe state in which phase logic processing has completed. The actual sequencing necessary to execute the controlled normal transition to the STOPPED state may vary depending on the state of the phase’s devices and logic when the transition to the STOPPING state occurred.

Legal Commands ABORT Transition to ABORTING

Sequencing Complete Transition to STOPPED Failure Response None

ABORTING The phase logic is performing the necessary logic for an abnormal transition from the current state to a safe state in which phase logic processing has completed. The actual sequencing necessary for executing the controlled normal transition to the ABORTED state may vary depending on the state of the phase’s devices and logic when the transition to the ABORTING state occurred. The ABORTING logic is generally expected to perform, as rapidly as



possible, a transition to the ABORTED state, differing from the STOPPING logic, which may be expected to perform a more orderly shutdown.

Legal Commands None

Sequencing Complete Transition to ABORTED Failure Response None

IDLE The phase logic is dormant and inactive. IDLE is considered a safe state. IDLE is expected to be the default initial state of a phase.

Legal Commands START Transition to RUNNING (if no failure present)

Sequencing Complete N/A

Failure Response None

COMPLETE This is the normal terminal state of the phase. COMPLETE is considered to be a safe state. Phase logic processing has been completed and the phase is ready to be reset for its next execution.

Legal Commands RESET Transition to IDLE

Sequencing Complete N/A Failure Response None

HELD The phase logic has transitioned to a safe state in the middle of phase logic execution from which batch execution may later be resumed. Note that the definition of a safe state does not infer that nothing is happening. The definition of safe state may require that functions such as agitation, temperature control, etc., continue due to process requirements such as material in the tank, etc.

Legal Commands RESTART Transition to RESTARTING (if no failure present)

STOP Transition to STOPPING

ABORT Transition to ABORTING Sequencing Complete N/A Failure Response None

Quiescent states



STOPPED This is an abnormal terminal state of the phase. STOPPED is considered to be a safe state. Phase logic processing has been completed and the phase is ready to be reset for its next execution.



ABORTED This is an abnormal terminal state of the phase. ABORTED is considered to be a safe state. Phase logic processing has been completed and the phase is ready to be reset for its next execution.



The FactoryTalk Batch Server or external control application sends commands and parameter values to the phase logic through the PLI. The communications interface portion of the PLI interprets the commands and verifies them against the state transition logic. It then forwards the appropriate information to the phase logic. In turn, the phase logic sends requests, status information, and phase report values to the server or external control application through the PLI. The communications portion of the PLI again interprets the requests and verifies it against the state transition logic. It then forwards the information to the controlling application(s).

FactoryTalk Batch sends commands and parameter values to the phase logic through the communications protocol. In turn, the phase logic sends requests, status information, and report values to the recipe phase through the communication protocol. A simple state machine controls the flow of information.

There are three kinds of events that can cause transitions between states in the phase logic state transition diagram.

These three event types are:

Event Description

Batch Commands The first type of state transition is referred to as a commanded state transition. As shown by the state transition diagram, the phase logic is expected to respond to legal FactoryTalk Batch commands according to its current state. For example, when the phase logic is in the IDLE state, a START command should cause the phase logic to transition to the RUNNING state. If, however, the phase logic receives a STOP command while it is in the IDLE state, this is an invalid command and will be ignored. The state transition diagram clearly shows what commands are legal in each state.

Communication protocol states

State transitions



Sequencing Complete The first type of uncommanded state change is the completion of one of the ING (RUNNING, HOLDING, STOPPING, ABORTING, or RESTARTING) states. Each of these ING states is expected to transition to another state when its sequencing has completed. These end states are often referred to as the ED (STOPPED, ABORTED, HELD, COMPLETED) states, although the transition from RESTARTING to RUNNING is an exception.

Failure Response The second type of uncommanded state change is a failure response. In the RUNNING and RESTARTING states, the phase logic is commanded to behave as if a HOLD command was issued when a failure is detected.


Chapter 4

Tags and commands

The programming behind a phase is typically referred to as the phase logic. The phase logic programming is generally project-specific and typically runs in some sort of process control hardware, such as a programmable logic controller (PLC) or distributed control system (DCS), although other types of phase logic, such as Visual Basic running on a PC, are possible.

Phase tags allow for two-way communication between the FactoryTalk Batch Server and the phase. The server, or an operator through an external application, can command a phase by writing a command value to the phase tags.

When defining phases that exist in the plant using FactoryTalk Batch Equipment Editor, define the tags that are used to communicate with the phases. This set of tags is the method by which the FactoryTalk Batch Server and the phase logic communicate.

Tag Description Batch Usage Function

PHASE_OC Command Write/Subscribe Send commands to phase logic PHASE_ST State Subscribe Indicate current state of phase PHASE_RQ Request Subscribe Make request to the FactoryTalk Batch Server PHASEQ## Request Params Write/Subscribe Additional parameters for defining a request PHASE_W Owner Subscribe Permissive for FactoryTalk Batch control of phase PHASE_F Failure Subscribe Indicates failure detected by phase logic PHASE_P Pause Subscribe Indicates the phase is pausing PHASE_PD Paused Subscribe Indicates the phase is paused PHASE_SS Single Step Subscribe Indicates the phase is in Semi-Auto mode PHASE_SI Step Index Subscribe Indicates current step index of phase logic PHASE_UN Unit Write/Subscribe Indicates the unit to which the phase is associated

PHASEP## Parameter Write/Subscribe Parameter values for phase logic control PHASER## Report Subscribe Report value generated by phase logic control

The following table describes the commands that may be issued from the FactoryTalk Batch Server or from an operator to the PLI, including the corresponding values that the server writes to the phase.

Command Value Description Abort 10 Sent by the FactoryTalk Batch Server to move the phase to the ABORTING state. This

command results in an action in every phase state except IDLE, COMPLETE, STOPPED and ABORTED. If the phase is in any other state, it transitions to the ABORTING state and execute the ABORTING logic.

Phase logic API tags

FactoryTalk Batch commands

Chapter 4 Tags and commands


Command Value Description Hold 20 Sent by the FactoryTalk Batch Server to move the phase to the HOLDING state. This

command results in an action when the phase is in the RUNNING, RESTARTING, or HELD state.

Stop 30 Sent by the FactoryTalk Batch Server to move the phase to the STOPPING state. This command results in an action when the phase is in the RUNNING, HELD, HOLDING, or RESTARTING state.

Reset 40 Sent by the FactoryTalk Batch Server to move the phase to the IDLE state. This command results in an action when the phase is in the STOPPED, COMPLETE, or ABORTED state.

Pause 50 Sent by the FactoryTalk Batch Server to command the phase logic to set the PAUSE attribute (PHASE_P), which allows the phase to transition to the PAUSING and PAUSED state at the next pre-programmed breakpoint within its sequencing logic and wait for a RESUME command before proceeding. The PAUSE command results in an action when the phase logic is programmed to respond to this command.

SemiAuto 60 Sent by the FactoryTalk Batch Server to toggle the phase into and out of the Semi-Auto mode. This command causes the phase logic to set the Single Step attribute (PHASE_SS) that allows the phase to transition to the PAUSING and PAUSED state at each programmed pause transition and wait for the operator to issue a RESUME command. The SEMI_AUTO command results in an action when the phase logic is programmed to respond to this command. The SEMIAUTO command was formerly referred to as the SINGLE_STEP command. In an effort to become more consistent with the S88.01 standard, the term was changed to SEMIAUTO.

NewParameters 70 Sent by the FactoryTalk Batch Server to indicate to the phase logic that the phase has crossed a recipe transition (transfer of control). This command can trigger the phase logic to request a download of parameters. Upon execution of this command, the PLI sets a Boolean value (_DL) which the phase logic can use to initiate a download parameters request. The NEWPARAMETERS command is valid only when the phase logic is programmed to respond to this command. Other phase logic ignores the _DL without responding in any manner. Typically, this command is used for non-terminating phases that may require setpoint changes during the execution of a batch, such as temperature control, agitation, etc. The NEWPARAMETERS command was formerly referred to as the DOWNLOAD command. This term was misleading because the FactoryTalk Batch Server did not actually download the parameters; it merely informed the phase logic that it could request a download of new parameters.

Resume 80 Sent by the FactoryTalk Batch Server to the phase to resume after the phase logic has paused at a pre-programmed transition. This command orders PAUSED phase logic to resume execution. It is also used to move the phase logic to the next step during Semi-Auto processing. This command results in an action when the PAUSED attribute is active.

Restart 90 Sent by the FactoryTalk Batch Server to the phase to restart the phase logic after it has HELD. The phase transitions from the HELD state through the RESTARTING state to the RUNNING state. This command results in an action when the phase is in the HELD state.

Start 100 Sent by the FactoryTalk Batch Server to the phase to start the phase logic. This command orders the phase to transition from the IDLE state to the running state. This command results in an action when the phase is in the IDLE state.

ClearFailure 130 Sent by the FactoryTalk Batch Server to the phase to clear any outstanding phase failures.

The following commands are used as part of the request protocol:

Command Value Description

Chapter 4 Tags and commands


ReqComplete 140 Sent by the FactoryTalk Batch Server to indicate to the phase logic that the current phase request completed successfully. The PLI responds by setting the REQUEST register to 10.

ReqFailed 145 Sent by the FactoryTalk Batch Server when the processing of a phase logic request experiences an error. The PLI responds by setting the REQUEST register to 15.

ReqAbortAck 150 Sent by the FactoryTalk Batch Server to indicate to the phase logic that the previous request aborted successfully. The PLI responds by setting the REQUEST register to 20.

ReqAbortFail 160 Sent by the FactoryTalk Batch Server to indicate to the phase logic that the previous request aborted successfully. The PLI responds by setting the REQUEST register to 30.

ResetForNextRequest 170 Sent by the FactoryTalk Batch Server to indicate to the phase logic that the request is complete and can be reset to allow for a new request. The PLI responds by setting the REQUEST register to 0.


Chapter 5

PLI communications protocols

The phase logic interface (PLI) communications protocols define the behavior that must be provided by the project-specific PLI in order for the FactoryTalk Batch Server to successfully coordinate the activities of phases. It also defines the expected behavior and services provided by the FactoryTalk Batch software for use by the phase logic. Any programmer of a new PLI should begin a project by developing a solid understanding of the FactoryTalk Batch PLI protocols.

For many control systems, shell implementations of the protocols have been designed to allow FactoryTalk Batch to be used with specific brands of hardware. These implementations are typically reusable code that is expected to provide the core of the required protocol behavior for the phase logic programmer, thus freeing the programmer to concentrate on the actual control logic required for the phase.

The FactoryTalk Batch phase protocols:

• Obey the state transition diagram• Support the command handshake• Follow the phase logic request protocol • Support the pause/semi-auto functionality• Recognize the NEW_PARAMETERS command• Support the Program/External attribute• Support the failure protocol • Support the watchdog protocol

The purpose of the phase logic state transition diagram is to ensure that phase logic exhibits the required behavior characteristics to be controllable by the FactoryTalk Batch Server.

The purpose of the command handshake protocol is to guarantee that the FactoryTalk Batch Server cannot overwrite a command value in a command tag before the phase logic has a chance to see it.

Obey the state transition diagram

Support the command handshake protocol

Chapter 5 PLI communications protocols


This figure depicts the state machine used for the command handshake protocol:

State/Transition Description

State DORMANT The command handshake state machine initializes into the DORMANT state. In the DORMANT state, the FactoryTalk Batch Server can write to the phase’s command tag.

Transition COMMAND The FactoryTalk Batch Server issues a command to the phase by writing to the command tag. The command value is a 16-bit integer. The low byte of the integer contains the command value and the high byte contains a command ID. The act of writing to the command tag changes the state of the command handshake state machine from DORMANT to PENDING HANDSHAKE.

State PENDING ACK The FactoryTalk Batch Server is not permitted to write to the command tag of a phase whose command handshake state machine is in the PENDING ACK state. This is to prevent the server from overwriting a previous command value that the phase logic has not yet detected.

Transition ACK The PLI acknowledges that it has received a command by clearing the low byte of the 16-bit command tag. Acknowledgment of a command changes the state of the command handshake state machine from PENDING HANDSHAKE back to DORMANT.

Many process-connected devices work with a periodic scan. The FactoryTalk Batch Server issues commands to phase logic by writing to the phase’s command tag. Without a handshake protocol, this can lead to a problem. If the server were to attempt to issue two or more commands in rapid succession, there would be no mechanism to prevent the server from overwriting command values before the phase logic could detect them.

To guarantee that phase logic detects every command issued to the phase by the server, the FactoryTalk Batch command handshake protocol was defined. This protocol is used to guarantee that the phase logic gets the opportunity to detect each FactoryTalk Batch command as it is issued.

The phase logic command tag is treated as a 16-bit integer value. When the FactoryTalk Batch Server writes a command to a phase command tag, it stores separate values into the upper and lower bytes of the command tag. The low byte is used to hold the command value. The upper byte is used by the server to write an ID associated with the command. When the PLI detects the command, it is expected to clear the lower eight bits of the command tag to indicate to the server that the command has been received and the server can now issue queued commands.

The clearing of the low byte is simply an acknowledgment that the command has been received. It is not intended to be an acknowledgment that the command has been processed. For example, if a STOP command is issued, the handshake (clearing of the low byte) should be done immediately. Do not wait until the state has changed to STOPPING or STOPPED before completing the

COMMAND

ACK

DORMANTPENDING

HANDSHAKE

Command handshake protocol



handshake. The only purpose of the handshake is to prevent the FactoryTalk Batch Server from overwriting a command before the phase logic has received it. If this handshake were not present, it would be possible for serious problems to occur. For example, if two operators almost simultaneously issued ABORT and RESTART commands, and the RESTART command overwrote the ABORT command, the ABORT command would never be received by the phase logic.

While programmers of PLCs and similar devices may be familiar with bit level logic, programmers of DCS systems may not be as familiar with bit manipulations. The programmer of a DCS can determine the command value stored in the command tag’s low byte by using a remainder function to determine the remainder of the current command tag value’s division by 256. To clear the low byte of the command tag, the phase logic programmer can subtract the command value from the command tag.

While phase logic programmers do not need to concern themselves with the upper eight bits of the command tag, the following is a discussion of how they guarantee serialization of the FactoryTalk Batch commands to the phases.

One might ask why even have a command ID in the high byte of the command tag? Why not just have the user zero the command tag once the command has been seen? The change in value to zero could be the permissive to issue the next command.

The problem with this approach comes with the manner in which most data servers are implemented. Most data servers are written as polling applications. A data server periodically polls the process-connected device for current values and then compares the current value with the last recorded value to determine if there was a change. If the value has changed, then all subscribers are notified of the change in value.

The command tag’s high byte

Example - No command ID in high byte



The following figure depicts the execution of a simple command handshake protocol where there is no command ID stored in the high byte. The phase logic would simply zero the entire command register to acknowledge (ack) the command.

At time T1, the data server polls the process-connected device and reads a value of zero for the command tag. This may or may not be a change from the previous value, but in any event, zero is stored in the data server’s database as the latest value of the command tag.

At time T2, the FactoryTalk Batch Server writes a 100 value to the command tag for the phase, issuing a START command to the phase logic. The server will not issue any commands until it is notified that the value of the command tag is zero, indicating that the PLI has seen the command.

At time T3, the data server polls the process-connected device and reads a value of 100 for the command tag. This is a change from the previous value of zero, so the server, as a subscriber, is notified of the new value of 100 in the command tag. Since the previous command had not yet been acknowledged, the server will not issue any new commands to the phase.

At time T4, the PLI detects the presence of a command and immediately resets the command tag to zero.

At time T5, the data server polls the process-connected device and reads a value of zero for the command tag. This is a change from the last recorded value of 100, so the server, as a subscriber, is notified of the new zero value in the command tag. Since the command tag has returned to zero, the command handshake is considered complete, and the server is free to issue another command.

The simplified protocol appears to work. Consider what happens when the data server does not poll fast enough to detect the change in value of the command tag to 100.



Consider the figure below that depicts a simplified command handshake with the data server polling too slowly:


At time T2, the FactoryTalk Batch Server writes a 100 value to the command tag for the phase, issuing a START command to the phase logic. The server will not issue any commands until it is notified that the value of the command tag is zero, indicating that the PLI has seen the command.

At time T3, the PLI detects the presence of a command and immediately resets the command tag to zero.

At time T4, the data server polls the connected device and reads a value of zero for the command tag. Since this is not a change from the previous value, the subscribers are NOT notified.

The system stops responding. The server will not send another command until it is notified that the current value of the command tag is zero. The data server never sends a data update to the FactoryTalk Batch Server because it never sees a change in value of the command tag.

To prevent the kind of problem depicted in the previous example, the FactoryTalk Batch Server uses the command tag’s high byte in a manner guaranteeing that a change in the command tag’s value will occur. By forcing

CO

MM

AN

D T

AG

VA

LUE

TIME

0

100

Data serverreads value ofzero

Batchwrites 100 tocommand tag

PLIresets commandtag value to zero

Data server reazero, no changsubscribers are

T1 T2 T3 T

Example - Command ID in high byte



a change in value, the server guarantees that it will receive a value update from the data server.

The server uses the command tag’s high byte to store a serial number or command ID on each command. After each command, the command ID’s value is incremented. On startup, the server checks the high byte’s current value in the command tag to ensure that it will not use a command ID that matches the current high byte value.

This figure depicts the actual command handshake protocol:


At time T2, the FactoryTalk Batch Server writes a 356 value to the command tag for the phase, issuing a START command to the phase logic. Note that the value 356 is actually 256 + 100, where 256 is a value of one in the high byte, and 100 is the command value in the low byte. The server will not issue any further commands until it is notified that the low byte’s value of the command tag is zero, indicating that the PLI has seen the command.

At time T3, the data server polls the process-connected device and reads a value of 356 for the command tag. This is a change from the previous value of zero, so the FactoryTalk Batch Server, as a subscriber, is notified of the new value of 356 in the command tag. Since the low byte of the command word has not been zeroed, the server will not issue any new commands to the phase.

CO

MM

AN

D T

AG

VA

LUE

TIME

0

100


Batch writes356 (256 + 100) tocommand tag

Data server reads valueof 356, notifiessubscribers of change

PLI clears low byteof command tag,changing value to 256

Data server of 256, notisubscribers

T1 T2 T3 T4 T



At time T4, the PLI detects the presence of the command and immediately resets the low byte of the command tag to zero, changing the value of the command tag to 256.

At time T5, the data server polls the process-connected device and reads a value of 256 for the command tag. This is a change from the last recorded value of 356, and the FactoryTalk Batch Server, as a subscriber, is notified of the new value of 256 in the command tag. Since the low byte of the command tag has returned to zero, the command handshake is considered complete, and the server is free to issue another command.

The actual batch command handshake protocol works. Now, verify that the protocol still works, even with a data server that polls too slowly to see the value of 356 in the command tag.

Consider the following diagram that depicts an actual command handshake with the data server polling too slowly:


At time T2, the FactoryTalk Batch Server writes a 356 value to the command tag for the phase, issuing a START command to the phase logic. Note that the value 356 is actually 256 + 100, where 256 is a value of one in the high byte, and 100 is the command value in the low byte. The server will not issue any further commands until it is notified that the low byte’s value of the command tag is zero, indicating that the PLI has seen the command.

CO

MM

AN

D T

AG

VA

LUE

TIME

0

100


Batch writes356 (256 + 100) tocommand tag

PLI clears low byteof command tag,changing value to 256

Data server reof 256, notifiesubscribers of

T1 T2 T3 T4



At time T3, the PLI detects the presence of a command and immediately resets the low byte of the command tag to zero, changing the value of the command tag to 256.

At time T4, the data server polls the process-connected device and reads a value of 256 for the command tag. This is a change from the last recorded value of 0, so the FactoryTalk Batch Server, as a subscriber, is notified of the new value of 256 in the command tag. Since the low byte of the command tag has returned to zero, the command handshake is considered complete, and the server is free to issue another command.

By using the high byte of the command word to ensure that the command tag’s value changes, the FactoryTalk Batch Server is guaranteed that a polling data server, no matter how slow, will detect a change in the command tag’s value to report to the server.

The command handshake protocol prevents the FactoryTalk Batch Server from overwriting commands before the PLI has had a chance to detect the command. The responsibilities of the PLI programmer to support the command handshake can be summarized as follows:

1. Examine the low byte of the command word to detect batchcommands. In PLCs and similar devices, this can be done with masks.In DCS platforms, it may be easier to use the remainder function witha divisor of 256 to determine the command value.

2. As soon as a command is detected, clear the low byte of the commandword to signal the FactoryTalk Batch Server that it is permissible towrite another command into the command tag. In a PLC or similardevice, this can be done in a straightforward manner. In a DCS, it maybe easier to subtract the command value from the command tag. Forexample, if a START command (value 100) was received, the user wouldsimply subtract 100 from the command tag to clear the command tag’slow byte.

WARNING: Support for the command handshake protocol is critical. If the PLI does not support the command handshake protocol correctly, the FactoryTalk Batch Server may not be able to control the phase logic. This can result in command timeout failures and the inability to control the plant. FactoryTalk Batch records command protocol activity in the batch log. This can be useful for debugging problems in phase logic handling of the command handshake protocol.

PHASE_OC The FactoryTalk Batch Server supports the command handshake protocol by writing to the PHASE_OC command tag. The PLI also writes to the low byte of the PHASE_OC command tag.

Summary of the command handshake protocol

Tags used in the command handshake protocol



The purpose of the request protocol is to control the rate at which phase logic makes requests to FactoryTalk Batch in order to ensure that the FactoryTalk Batch Server detects every request.

Phase logic request protocol state machine

State/Transition Description

State DORMANT The request protocol state machine initializes into the DORMANT state. In the DORMANT state, the phase logic is free to write a request value into the request tag.

Transition REQUEST The phase logic makes a request of the FactoryTalk Batch Server by writing a request value into the request tag. The act of making a phase logic request transitions a state machine in the DORMANT state to the REQ PENDING state.

State REQ PENDING The REQ PENDING state indicates that the phase logic is waiting for the FactoryTalk Batch Server to finish processing an outstanding request. In this state, the phase logic is not permitted to write to the request register, unless it is attempting to abort the request currently being processed.

Transition COMPLETE When the FactoryTalk Batch Server has finished processing a phase logic request, it notifies the PLI of the completion of the request by sending a REQUEST COMPLETE command (140) to the phase logic. When the PLI receives this command, it is expected to write an intermediate request value of 10 into the request register. Receipt of this command by the phase logic will transition a state machine in the REQUEST PENDING state to the RESET PENDING state.

State RESET PENDING In the RESET PENDING state, the PLI is waiting for a RESET FOR NEXT REQUEST command to be issued by the FactoryTalk Batch Server. In this state, the phase logic is not permitted to write to the request register.

Transition RESET When the PLI receives a RESET FOR NEXT REQUEST command (170) from the FactoryTalk Batch Server, it is a signal that the server has seen the intermediate request value. In response to the command the PLI is expected to zero the request register. The reception of this command transitions a state machine in the RESET PENDING state to the DORMANT state.

Transition ABORT If the phase logic decides that it does not need an outstanding request to be completed, the phase logic may initiate the aborting of the request by writing a 6000 into the request register (or 16000 if using enhanced phase logic requests). The act of aborting an outstanding phase logic request will transition a state machine in the REQ PENDING state to the ABORT PENDING state.

DORMANT REQUESTABORT

PENDINGABORT

RESETPENDING

REQPENDING

RESET ABORTED/NOT

CO

MPL

ETE

Follow the phase logic request protocol



State ABORT PENDING The ABORT PENDING state indicates that the phase logic is waiting for the FactoryTalk Batch Server to finish processing the abort of an outstanding phase logic request. In this state, the phase logic is not permitted to write to the request register.

Transition ABORTED/NOT When the FactoryTalk Batch Server finishes processing a request to abort an outstanding request, it will issue one of two commands to the PLI. A REQUEST ABORTED command (150) will be issued if the command was successfully aborted. A REQUEST NOT ABORTED command (160) is issued if the FactoryTalk Batch Server was unable to abort the request. In response to a 150 command, the PLI is expected to write an intermediate request value of 20 into the request register. If the command is a 160, the PLI is expected to write an intermediate request value of 30 into the request register. The reception of either command by the PLI causes the transition of a state machine in the ABORT PENDING state to the RESET PENDING state. While the differentiation between the 150 and 160 command is defined in the communication protocol, FactoryTalk Batch does not yet fully support the differentiation between these two commands.

The phase logic request protocol is similar to the command protocol in that it was defined in order to solve problems introduced by the nature of polling data servers. Begin by describing the nature of phase logic requests.

There are numerous functions that may be performed by the FactoryTalk Batch Server at the request of the phase logic. These functions include arbitration, messaging, reporting, etc. The phase logic makes a request to the FactoryTalk Batch Server by writing a request value into the request tag. Additional parameters describing the request may also be required and are written into the request parameter tags.

This example illustrates the challenges posed by the nature of a polling data server. If the FactoryTalk Batch Server detects requests by reported changes in the value of the request tag, how do we guarantee that the server receives a data update with each request? Begin with an examination of a simple protocol that has a problem with the nature of a polling data server. Propose a protocol where, when a request is completed, the server sends a command to the phase to let it know that it is completed, and the PLI then zeros the request register.

Simplified request protocol with request tag reset to zero When this simple protocol works, a chart of the value of the request parameter might appear as follows:

Phase logic request protocol

Example - Request tag immediately reset to zero



At time T1, the data server polls the process-connected device and reads a value of zero for the request tag. This may or may not be a change from the previous value, but in any event, zero is stored in the data server’s database as the latest value of the command tag.

At time T2, the phase logic makes a download parameters request, writing the value 1000 into the request tag.

At time T3, the data server polls the process-connected device and reads a value of 1000 for the request tag. This is a change from the previous value of zero so all subscribers, including FactoryTalk Batch, are informed of the new value. The FactoryTalk Batch Server, seeing the 1000 value in the request tag, begins processing the parameter download request.

At time T4, the FactoryTalk Batch Server has completed the parameter download and sends a Request Completed command to the phase logic. In response to this command, the PLI resets the request register value to zero.

At time T5, the data server polls the process-connected device and reads a value of zero for the request tag. This is a change from the previous value of 1000 so all subscribers, including FactoryTalk Batch, are informed of the new value. The FactoryTalk Batch Server sees a value of zero as no request, and takes no action.

At time T6, the phase logic makes a second download parameters request, writing the value 1000 into the request tag again.


At time T8, the FactoryTalk Batch Server has completed the second parameter download and sends a Request Completed command to the PLI. In response to this command, the PLI resets the request register value to zero.



The problem with the above protocol occurs when the data server does not poll fast enough to detect the change in value of the request tag from 1000 to zero and then back to 1000.

Simplified request protocol with data server polling too slowly Consider the chart below:




At time T4, the FactoryTalk Batch Server has completed the parameter download and sends a Request Completed command to the PLI. In response to this command, the PLI resets the request register value to zero.


At time T6, the data server polls the process-connected device, and reads a value of 1000 for the request tag. Since this is not a change from the previously read value, no subscribers are notified. The FactoryTalk Batch Server will never process the second 1000 request because the data server will never notify the FactoryTalk Batch Server of the value since there is no change from the previously read value. The batch is now hung.

As this example illustrates, a simple protocol where the value of the request tag is simply zeroed between requests can result in the FactoryTalk Batch



Server missing a phase logic request when two identical phase logic requests are made in a row.

The actual request protocol is designed to guarantee that the FactoryTalk Batch Server detects every phase logic request, regardless of the data server’s poll rate. The FactoryTalk Batch request protocol uses a two-step acknowledge. When the FactoryTalk Batch Server completes a phase logic request, a Request Complete command is sent to the PLI. Rather than zeroing the request parameter in response to the request, however, the PLI is expected to write a value of 10 into the request register. The value of 10 is used simply because it is a value that can never be a valid request. The PLI then waits for the FactoryTalk Batch Server to see the value of 10. When the server sees the value of 10 in the request register, it then sends a Reset for Next Request command to the PLI. When the PLI receives this command, it resets the request register value to zero (0). The phase logic can now make another request.

Actual request protocol Examine this protocol in the time line below:




Example - Request tag receives intermediate value



At time T4, the FactoryTalk Batch Server has completed the parameter download and sends a Request Completed command to the PLI. In response to this command, the PLI changes the request value register to 10.

At time T5, the data server polls the process-connected device and reads a value of 10 for the request tag. This is a change from the previous value of 1000 so all subscribers, including FactoryTalk Batch, are informed of the new value.

At time T6, in response to seeing a value of 10 in the request register, the FactoryTalk Batch Server sends a Reset for Next Request command to the PLI. In response to this command, the PLI changes the request value to zero.

At time T7, the data server polls the process-connected device and reads a value of zero for the request tag. This is a change from the previous value of 10 so all subscribers, including FactoryTalk Batch, are informed of the new value. Since zero is not a valid request, the FactoryTalk Batch Server ignores the update.


At time T9, The data server polls the process-connected device and reads a value of 1000 for the request tag. This is a change from the previous value of zero so all subscribers, including FactoryTalk Batch, are informed of the new value. The FactoryTalk Batch Server, seeing the 1000 value in the request tag, begins processing the new download request.

Actual request protocol with data server polling too slowly Now, examine the effectiveness of this new protocol when the data server polls too slowly to detect the change in value from 10 to zero to 1000:






At time T4, the FactoryTalk Batch Server has completed the parameter download and sends a Request Completed command to the PLI. In response to this command, the PLI changes the request value register to 10.

At time T5, the data server polls the process-connected device and reads a value of 10 for the request tag. This is a change from the previous value of 1000 so all subscribers, including FactoryTalk Batch, are informed of the new value.

At time T6, in response to seeing a value of 10 in the request register, the FactoryTalk Batch Server sends a Reset for Next Request command to the PLI. In response to this command, the PLI changes the request value to zero.

At time T7, before the data server has had a chance to poll the process-connected device, the phase logic makes a download parameters request, writing the value 1000 into the request tag.

At time T8, the data server polls the process-connected device and reads a value of 1000 for the request tag. This is a change from the previously read value of 10 so all subscribers, including FactoryTalk Batch, are informed of the new value. The FactoryTalk Batch Server seeing the 1000 value in the request tag, begins processing the new parameter download request.

As illustrated by the analysis of this example, successive identical requests are guaranteed to be detected as unique and separate requests. The FactoryTalk Batch Server detects and processes each request, regardless of the poll rate of the data server.

There is a second aspect of the FactoryTalk Batch request protocol, which involves the aborting of phase logic requests. Phase logic may find it necessary to cancel a pending phase logic request due to a change in state. For example, a phase that has an outstanding request to download recipe parameters may want to abort the request on a state change from RUNNING to ABORTING.

An obvious approach for the aborting of phase logic requests would be for the phase logic to zero the value of the request tag. This approach, however, has the same problem shown previously, where a slow polling data server might not detect a change in value of the request register if a second request of the same value is made after the request was canceled.

In order to avoid the problems introduced by polling data servers, the FactoryTalk Batch request protocol uses a value of 6000 (or 16000 if using enhanced phase logic) in the request tag to indicate a request to abort an outstanding request. When the FactoryTalk Batch Server detects a value of

Abort phase logic requests



6000 (or 16000) in the request tag, it attempts to abort any request it may be currently processing. Once the request has been aborted, or immediately if no request was being processed, the server sends one of two commands to the PLI. These two possible commands are Request Aborted and Request Not Aborted.

The intentions of the two possible responses to the abort request are as follows: When the user asks for a request to be aborted, there are two possible scenarios. The request may have not yet been completed, and the FactoryTalk Batch Server can successfully abort the request. An example of this scenario would be a download request that caused the server to generate unacknowledged prompts to the operator. If the prompts had not been responded to and the phase logic chose to abort the download request, then the server could remove the unacknowledged prompts and the request would have been successfully aborted. In the scenario where a request is successfully aborted, the server would be expected to send the command Request Aborted when the request was successfully aborted.

The second scenario for the aborting of a phase logic request is a too late scenario. This means that the abort request came too late and the request was actually completed (and cannot be undone) before the abort request was received. An example of this would be a Send Message and Wait request. It is possible that when phase logic attempts to abort a Send Message and Wait request that the FactoryTalk Batch Server will not detect the abort request until just after the message was delivered to the partner phase. Once the message has been delivered to the phase’s message partner, there is no way to un-deliver it. In this type of scenario, the server is expected to send the Request Not Aborted command in response to the abort request.

When the PLI receives a Request Aborted or Request Not Aborted command, it is expected to respond in a similar manner to the Request Completed command. However, rather than setting the value of the request tag to 10, the request tag is set to 20 upon receipt of a Request Aborted command and to 30 upon receipt of a Request Not Aborted command. Once the FactoryTalk Batch Server detects the presence of the 20 or 30 value in the request tag, a Reset for Next Request command is issued, exactly as occurs when the request tag holds a value of 10 at the end of a successful request. In response to the Reset for Next Request command, the PLI is expected to change the request tag’s value to zero.

PHASE_RQ: The request tag is used by the phase logic to make requests of the FactoryTalk Batch Server and to store intermediate values used by the handshake protocol. This tag is used by the PLI to indicate OK to reset - 10, 15, 20, or 30, and reset complete - 0.

Tags used in the phase logic request protocol



PHASEQ##: A set of tags used to hold additional parameters for the phase logic request.

PHASE_OC: The FactoryTalk Batch Server uses commands to inform the phase logic of completed requests, the results of an abort request, and for handshakes in the request protocol. The command tag (in conjunction with the command handshake) is used by the server to issue commands to the phase logic. The relevant commands for the PLI request protocol are:

• REQUEST COMPLETED (140)• REQUEST FAILED (145)• ABORT SUCCESSFUL (150)• ABORT FAILED (160)• RESET FOR NEXT REQUEST (170)

Depending on the actual phase logic request being made, request parameter tags may be involved. For example, you need to request a specific piece of equipment (ID 125) for your phase. You will need to write 4000 (or 14000 if using enhanced phase logic) into the REQUEST tag, and the equipment ID (125) into the REQDATA_1 tag. The FactoryTalk Batch Server reads theequipment ID from the REQDATA_1 memory tag and then acquires theresource specified by the equipment ID.

IMPORTANT Phase logic programmers should store request parameter values into request parameter tags before storing the request values into the request tag. This ensures that the FactoryTalk Batch Server does not detect the request before the parameters are set.

The purpose of Semi-Auto functionality allows you to force phase logic execution to stop at programmed break points in the phase logic sequencing and wait for operator confirmation before proceeding. The SEMIAUTO command was formerly referred to as the SINGLE_STEP command. In an effort to become more consistent with the S88.01 standard, the term was changed to SEMI-AUTO.

Miscellaneous

Support for Semi-Auto functionality



The following diagram depicts the state machine defined for the Semi-Auto functionality within the phase logic:

State Description Enabled Event

FREE RUNNING The free running state is the default initial state of the phase logic’s Semi-Auto state machine. In this state, the phase logic sequencing proceeds normally. The sequencing does NOT pause at programmed breakpoints. The values of both the SingleStep, Pause, and Paused tags are all zero.

Semi-Auto – The receipt of a SEMI_AUTO command while in the FREE RUNNING state will cause the phase logic’s Semi-Auto state machine to transition to the SS PAUSING state.

SS PAUSING The SS PAUSING state indicates that the phase logic is executing its sequence logic. However, it will pause execution when it reaches the next programmed breakpoint in the sequencing logic. In this state, the SingleStep and Pause tag have a value of one, while the Paused tag has a value of zero.

BREAK – When the sequencing logic reaches a programmed breakpoint, the phase logic transitions to the SS PAUSED state. SEMI-AUTO – The receipt of a SEMI_AUTO command while in the SS PAUSING state causes a transition of the phase logic’s SEMI_AUTO state machine to the FREE RUNNING state.

SS PAUSED The SS PAUSED state indicates that the phase logic has stopped at a programmed breakpoint in the phase logic and is awaiting a resume command from the operator. In the SS PAUSED state, both the SingleStep and Paused tags have values of one, and the Pause tag has a value of zero.

RESUME – The receipt of a RESUME command while in the SS PAUSED state will cause the phase logic’s Semi-Auto state machine to transition to the SS PAUSING state. SEMI-AUTO – The receipt of a SEMI_AUTO command while in the SS PAUSED state causes a transition of the phase logic’s Semi-Auto state machine to the FREE RUNNING state.

The Semi-Auto functionality within the PLI was defined to allow users to take advantage of programmed optional breakpoints in the phase’s sequencing logic. The actual programming of breakpoints into the phase’s sequencing logic is a completely optional feature that an individual project application team may choose to implement or ignore.

Historically, Semi-Auto functionality has been useful during the startup and commissioning stage of a project. It is less common, although not unheard of,

Semi-Auto functionality



for a project to use Semi-Auto functionality as an optional part of normal batch execution.

When the SingleStep bit is on, indicating that the phase is in Semi-Auto operation, the phase logic sequencing will pause at every programmed breakpoint in the phase logic. When a sequence breakpoint is reached, the phase logic halts sequencing and sets the Paused flag to indicate that the phase logic execution has stopped. The user may then issue a RESUME command triggering the phase logic to resume execution until the next breakpoint is reached, or may issue a SEMI_AUTO command for toggling the phase logic completely out of Semi-Auto mode, so the phase can resume normal execution.

The sequence breakpoints may or may not be safe points in the phase logic. In the standard PLI implementation of the API developed by Rockwell Automation, these breakpoints are not process safe points, as the breakpoints are used for startup/commissioning checkout of the phase logic.

PHASE_OC: The command tag is (in conjunction with the command handshake) used by the FactoryTalk Batch Server for issuing commands to the phase logic. The relevant commands for the Semi-Auto functionality are:

• SEMI_AUTO (60) • PAUSE (50)• RESUME (80)

PHASE_SS: The SingleStep tag used by the phase logic indicates if the phase is in Semi-Auto operation. Semi-Auto operation means that the phase logic will pause at every programmed break point in the phase’s sequencing logic. A value of one indicates that the phase is in Semi-Auto operation. A value of zero indicates that it is not.

PHASE_PD: The Paused tag used by the phase logic indicates that the phase has paused at a programmed breakpoint and will not continue execution until commanded to resume.

Tags used with the Semi-Auto functionality



PHASE_P: The Pause tag used by the phase logic indicates that the phase will transition to the Paused state at the next pre-programmed breakpoint in the phase logic and will not continue execution until commanded to resume.

The purpose of the NEW_PARAMETERS command is to notify phase logic that a transfer of control (TOC) between two steps connected to the same phase has been completed. The NEWPARAMETERS command was formerly referred to as the DOWNLOAD command. This term was misleading because the FactoryTalk Batch Server did not actually download the parameters; it merely informed the phase logic that it could request a download of new parameters. The phase logic may choose to download new parameter values when this occurs.

When phase logic receives a NEW_PARAMETERS command, it may respond by making a 1000 series request (or 11000 if using enhanced phase logic) to request a download of the new parameters.

The NEW_PARAMETERS command is intended to support the Transfer of Control (TOC) feature within FactoryTalk Batch. Transfer of control occurs when steps representing the same phase are both above and below a transition and the transition expression does not require that the phase be in the COMPLETE state.

Tip: Transfer of Control is not supported with synchronized phases or with material-enabled phases.

The following diagram depicts an SFC of an operation in which transfer of control will occur:

Support for the NEW_PARAMETERS command

NEW_PARAMETERS command



In this operation, mixing is supposed to occur while material A is being fed. Mixing is expected to change speed from 15 to 30 rpm when the signal from the LI1000 tag on the unit exceeds a value of 50.

The MIX:1 and MIX:2 steps that bracket the "LI1000.PV > 50" transition represent a transfer of control situation. In this case, when the transition fires, it does not stop the phase and then restart it for the next step, but merely transfers control of the phase from one step to the next. When this transfer of control occurs, the FactoryTalk Batch Server sends a NEW_PARAMETERS command to the phase. This is considered a notification that there are new recipe parameters present. In this case, the setpoint for the mixer speed has changed from 15 to 30.

It is the PLI’s responsibility to respond to the NEW_PARAMETERS command by notifying the phase logic that a transfer of control has occurred. The phase logic can then choose to download new parameters, if necessary.

If a phase will NEVER be used in a transfer of control situation, it is possible that support for the NEW_PARAMETERS command could be removed from the phase logic, but remember, NEVER is a VERY LONG TIME.

PHASE_OC: The command tag (in conjunction with the command handshake) is used by the FactoryTalk Batch Server to issue the NEW_PARAMETERS command to the phase logic. The value of the NEW_PARAMETERS command is:

• NEW_PARAMETERS (70)

PHASE_RQ: The request tag used by the phase logic makes a parameter download request in response to the NEW_PARAMETERS command.

PHASEQ##: The request parameter tags may provide parameters for the download request made in response to the NEW_PARAMETERS command.

The purpose of the Program/External attribute of a phase is to act as a permissive for FactoryTalk Batch Server control of the phase.

When a phase is permitted to be controlled by the FactoryTalk Batch Server, a

Tags used with the NEW_PARAMETERS command

Support for the Program/External attribute



zero value should be stored into the owner tag. When a phase is not permitted to be controlled by the server, a non-zero value should be stored into the owner tag.

IMPORTANT A phase in EXTERNAL should never return to PROGRAM control unless it is in the IDLE state. You should expect to spend extra effort when planning how the phase logic will handle requests and synchronization if External Control is used.

The owner attribute of a phase acts as a permissive for FactoryTalk Batch Server control of the phase logic. When the phase has an owner attribute value of PROGRAM, it is indicating that the server is permitted to control the phase. When the phase has an owner attribute value of EXTERNAL, the server is not permitted to attempt to control the phase.

An owner attribute value of PROGRAM is the expected value for normal FactoryTalk Batch Server recipe execution. When all phases used by a recipe have an attribute value of PROGRAM, recipe execution can be expected to proceed normally.

If, however, one or more phases used by a recipe have an owner attribute value of EXTERNAL, recipe execution will not proceed normally. There are two scenarios in which a recipe executing in the Server may encounter a phase with an owner attribute of EXTERNAL.

The most common scenario is when the phase has an owner attribute of EXTERNAL prior to the FactoryTalk Batch Server attempting to connect to the phase. When a recipe detects that it is attempting to connect to a phase whose owner attribute is EXTERNAL, it generates a failure and holds the batch. The step that attempted to connect to the EXTERNAL phase disconnects and returns to the READY (not connected) state.

The second scenario that may occur is that a phase may transition from PROGRAM to EXTERNAL while it is being used by the FactoryTalk Batch Server. When this occurs, a failure is generated and the batch is held. The step that was connected to the phase, however, remains attached to the phase. This attachment is a view only attachment. No commands will be sent to the phase, nor will phase logic requests be processed, but the user will still be able to view the state of the phase on the SFC. Since the phase is under EXTERNAL control, however, the state of the phase is no longer included in the composite state calculations of the batch’s higher levels.

Tip: Phases put into an external state will still be viewed as binding candidates by the FactoryTalk Batch Server. In order to remove a phase from being viewed as a binding candidate, you must first take ownership of the phase.

There are several ways in which phase logic might use the EXTERNAL owner attribute. Some projects provide an alternative operator interface for control of phase logic. These alternative operator interfaces often exist for use in a failure situation, such as a failure of the FactoryTalk Batch Server node. To prevent conflict between the FactoryTalk Batch Server and the alternative operator interface, the owner attribute is used.

Program/External attribute



Some control systems use the owner attribute to indicate that the control hardware is not in the proper state for phase logic control by the FactoryTalk Batch Server.

PHASE_W: The owner tag is used by the PLI to indicate a permissive for FactoryTalk Batch Server control of the phase. The tag’s value is treated as a Boolean with zero and non-zero values defined as follows:

False 0 FactoryTalk Batch Server control of the phase is permitted. (Program Mode)

True < > 0 FactoryTalk Batch Server control of the phase is not permitted. (External Mode)

The purpose of the failure protocol is to provide a mechanism by which the phase logic can report failures to the FactoryTalk Batch Server and through which the server can respond.

Failure protocol state machine Phase logic is expected to exhibit failure behavior as depicted in the following state transition diagram:

State Description Enabled Event

NORMAL The normal state indicates that the phase logic has not detected failures. In this state, the current value of the Failure tag for the phase should be zero.

FAILURE – If a failure occurs while the phase logic is in the NORMAL state, the phase logic transitions to the FAILED state and indicates the failure by storing a value between 1 and 32767 into its Failure tag.

FAILED The failed state indicates that the phase logic has detected one or more failures. In this state, the Failure tag should have a value between 1 and 32767, indicating the most severe failure that the phase logic has detected. Higher numeric values indicate more severe failures.

CLEAR FAILURES – When a Clear Failures command is received while the phase logic is in the Failed state, the phase logic should check to see if any failure conditions still exist. If no failure conditions exist, the phase logic may transition back to the Normal state by storing a value of zero into its Failure tag.

Tip: Clear Failures clears any messages generated by the 3000 and 13000 requests.

The failure codes allow for display prioritization of multiple failures. The failure codes are prioritized by increasing value. Thus, if two or more phases represented by active steps inside of the same operation have failures, the

Tags used with the Program/External attribute

Support for the failure protocol



failure code of the operation will be the highest value of the phases’ failure codes. For example, if one phase had a failure code of 52 and a second phase had a failure code of 8899, the failure code of the operation would be 8899. Thus, if the step representing the operation were selected from the unit procedure SFC, the error message associated with the ordinal 8899 in the PHASE_FAILURES enumeration set would be displayed in the status bar of the SFC screen. This also implies that if phase logic detects more than one failure, the Failure tag of the phase should be set to the highest value failure that was detected.

Lastly, but most importantly, the storing of a non-zero value into a phase’s failure tag gives the FactoryTalk Batch Server a chance to respond to the failure. Depending upon the value that is specified in the server’s .ini file for HoldPropagate, as well as the modes of the recipe layers above the phase, some, all, or none of the batch may be held in response to the failure. The term HoldPropagate implies that the FactoryTalk Batch Server will respond to a hold command, but in fact it does not, it actually responds to a detected failure.

Once a failure has been detected, the presence of the failure is effectively latched until a Clear Failures command is issued. When the phase logic receives a Clear Failures command, it should clear the value of the failure register only if no detected failures remain.

The purpose of the watchdog protocol is to verify the presence of communication between the FactoryTalk Batch Server and the phase logic. If the communication is deemed not present, then both the server and phase logic are expected to take preventative action by transitioning any active batch elements to the HELD state.

Currently, the FactoryTalk Batch Server supports two different implementations of the watchdog protocol. These are the Standard and the Enhanced watchdog protocols.

Tip: The watchdog protocol type can be defined for a data server using the Edit Server dialog box within FactoryTalk Batch Equipment Editor. (Refer to the FactoryTalk Batch Equipment Editor User Guide for information on configuring data server definitions.)

The standard watchdog protocol is a simple set/reset protocol. The FactoryTalk Batch Server sets the watchdog register by writing a one (1) to the watchdog item. The process-connected device being accessed through the data server is expected to reset the watchdog register to zero whenever a non-zero value is detected.

The FactoryTalk Batch Server can detect the presence of a healthy process-connected device by the resetting of the watchdog register. The process-connected device can detect the presence of a healthy server by the periodic setting of the watchdog register.

Support for the watchdog protocol

Standard watchdog protocol



If the process-connected device determines that the FactoryTalk Batch Server has not written to the watchdog register for an unacceptably long period of time, then it is expected to assume that the server is no longer present and respond by holding all active phases within itself.

If the FactoryTalk Batch Server detects that the process-connected device is not resetting the watchdog bit, then it assumes communication to all tags defined in the data server is not reliable. Batches using any of these tags will be held in response to the communication problems.

The following timeline illustrates how the standard watchdog protocol operates:

At time T1, the data server reads a value of zero for the watchdog register. This is recorded as the current value of the watchdog register. Subscribers may or may not be notified, depending on whether this is a change from the previous value.

At time T2, the FactoryTalk Batch Server writes a value of one (1) to the watchdog register, fulfilling its part of the watchdog protocol.

At time T3, the data server reads a value of one for the watchdog register. Since this is a change from the previously recorded value, subscribers are notified, and one (1) is recorded as the new current value.

At time T4, the phase logic resets the watchdog register value to zero (0), fulfilling its part of the watchdog protocol.

At time T5, the data server reads a value of zero from the watchdog register. Since this is a change from the previously recorded value, subscribers are notified, and zero is recorded as the new value. When the FactoryTalk Batch Server receives the value notification, the cycle is considered to be a successful watchdog handshake.



In certain situations, the implementation of the standard watchdog protocol can fail to verify communication between the FactoryTalk Batch Server and the phase logic. Because the FactoryTalk Batch Server determines the value of the watchdog register by remaining permanently advised on it, the lack of a data update is interpreted as a successful cycle. This may result in a situation where the standard watchdog protocol is unable to detect a communication failure.

The following timeline illustrates how the standard watchdog protocol can fail to detect a communication failure:

At time T1, the data server reads a value of zero for the watchdog register. This is recorded as the current value of the watchdog register. Subscribers may or may not be notified depending on whether this is a change from the previous value.

At time T2, the FactoryTalk Batch Server writes a value of one (1) to the watchdog register, fulfilling its part of the watchdog protocol.

At time T3, before the data server has a chance to poll again, the process-connected device resets the watchdog register value to zero, fulfilling its part of the watchdog protocol.

At time T4, the data server reads a value of zero (0) for the watchdog register. Since this is not a change from the previously read value, subscribers are not notified.

As many process-connected devices have scan rates significantly faster than the poll rates of their respective data servers, this scenario in the standard watchdog protocol can occur frequently. In this scenario, the watchdog register is in the high state for such a brief time that the polling data server

WA

TCH

DO

G R

EGIS

TER

VA

LUE

TIME

0

1


Batch writes 1 tocommand tag

Process deviceresets watchdogregister value to 0

T1 T2 T3 T4

Data serverreads value of 0

Standard watchdog protocol problems



does not detect the high value. Since the FactoryTalk Batch Server is subscribed to the value of the watchdog register, no data update is ever sent. This means that the server must interpret the lack of a data update as a successful cycle.

The problem this introduces is that because the lack of a data update must be interpreted as a successful cycle, FactoryTalk Batch is not able to detect a communication problem where the data server is not sending any updates.

The enhanced watchdog protocol is more robust than the standard protocol and avoids the situation described above. The enhanced protocol treats the watchdog register as a 16-bit integer value. Under the enhanced protocol, when the FactoryTalk Batch Server writes to the watchdog register, it writes a value of "1" to the low byte, and an ID in the high byte.

The high byte ID value is treated as an 8-bit integer and incremented in every scan until it wraps. This means that initially, the high byte is set to a value of 256 and then incremented by 256 every scan until it reaches a value of 16384 where it is reset to 256 (because some systems use the highest bit of the high byte to determine positive and negative values, this bit is not used).

The process-connected device being accessed through the data server is expected to reset the value of the watchdog register’s low byte to zero whenever a non-zero value is detected.

Both the FactoryTalk Batch Server and the process-connected device can detect the presence of healthy communication by the change in value of the watchdog register.

If the process-connected device detects that the value of the watchdog register has not changed for an unacceptably long period of time, then it is expected to assume that the FactoryTalk Batch Server is no longer present and respond by holding all active phases within itself.

If the FactoryTalk Batch Server detects that the value of the watchdog register has not changed for an unacceptably long period of time, then it assumes that communication to all tags serviced by the data server are not reliable. Batches using any of these tags will be held in response to the communication problems.

The following timeline illustrates how the enhanced watchdog protocol operates:

Enhanced watchdog protocol



At time T1, the data server reads a value of zero for the watchdog register. This is recorded as the current value of the watchdog register. Subscribers may or may not be notified, depending on whether this is a change from the previous value.

At time T2, the FactoryTalk Batch Server writes a value of 257 (256 + 1) to the watchdog register, fulfilling its part of the watchdog protocol.

At time T3, before the data server has a chance to poll again, the process-connected device resets the zero bit of the watchdog register, fulfilling its part of the watchdog protocol.

At time T4, the data server reads a value of 256 for the watchdog register. This is a change from the previously recorded value so all subscribers are notified of the new value. The FactoryTalk Batch Server receives the change value notification and considers the watchdog cycle a success.

The use of the high byte to hold a different value in every cycle forces a detectable change in value of the watchdog register at the end of every cycle. This means that if the FactoryTalk Batch Server does not receive a data update, it can assume the conversation is bad.

The advantage of the enhanced protocol from the phase logic programmer’s point of view is that because the phase logic still only sets the low bit of the register, there is only minimal change from the standard protocol. To support the enhanced protocol, the watchdog register must only be capable of storing a 16-bit integer value.

The frequency at which the FactoryTalk Batch Server writes to the watchdog register is controlled by the WatchdogPeriod entry in the [XMAN] section of the batchsvr.ini file. In each period, the server begins by writing a value to the

Watchdog period



watchdog register. It then waits until the end of the period. If at the end of the period the value of the watchdog register has been modified appropriately by the process-connected device, then the period is considered to be a successful cycle. If the write fails, or the value of the watchdog register is not modified by the process-connected device at the end of the period, then the period is considered to be a failed scan.

The FactoryTalk Batch Server uses the following state machine to determine the state of every data server with which it is communicating:

State Description Enabled event

LOST This is the initial state of the FactoryTalk Batch Server’s conversation status with a data server. In the LOST state, no connection exists between the FactoryTalk Batch Server and the data server.

CONNECT – A successful connection will cause the conversation status to transition from the LOST state to the BAD state. Note that the conversation transitions to BAD instead of GOOD, because it cannot be assumed that the watchdog logic is functioning correctly just because a connection is established.

BAD In the BAD state, the FactoryTalk Batch Server is not observing successful watchdog cycles with the data server. Communication to all tags configured to be inside of this data server are considered unreliable.

DISCONNECT - A disconnect will cause a conversation in the BAD state to transition to the LOST state. GOOD CYCLE - A single successful watchdog cycle will transition a conversation in the BAD state back to the GOOD state.

GOOD In the GOOD state, the most recent watchdog cycle was completed successfully. Communication with all tags configured to be inside of the data server associated with this conversation is assumed to be reliable.

DISCONNECT - A disconnect will cause a conversation in the GOOD state to transition to the LOST state. Any batches using tag(s) associated with the conversation will hold, because communication with the tag(s) has been lost. FAILED CYCLE - A single failed watchdog cycle will transition a conversation in the GOOD state to the SUSPECT state.

BAD

NFai

ledC

ycle

s

LOST GOOD CYCLE

SUSPECT GOODFAIL CYCLE

CONNECT

DISCONNECT



SUSPECT In the SUSPECT state, one or more consecutive watchdog cycles have failed. The number of failed cycles has not yet reached the limit specified in the WatchdogCycles ini value specified in the [XMAN] section of the batchsvr.ini file. Communication with all tags configured to be inside of the data server associated with this conversation is still assumed to be reliable. The purpose of the suspect state is primarily to indicate when there may be problems with communication, due to processor loading or other problems.

DISCONNECT - A disconnect will cause a conversation in the SUSPECT status to transition to the LOST state. Any batches using tag(s) associated with the conversation will hold, because communication with the tag(s) has been lost. N FAILED CYCLES - When the number of consecutive failed watchdog cycles reaches the value defined in the WatchdogCycles ini value, a conversation in the SUSPECT state will transition to the BAD state. Any batches using tag(s) associated with the conversation will hold, because communication with the tag(s) is no longer considered reliable.

Because the FactoryTalk Batch Server and the process-connected device independently decide whether to trust the quality of the communication, it is important to see that the time limit tolerances in the FactoryTalk Batch Server and the process-connected device are appropriate in relation to each other. The server will not transition a conversation from the GOOD state to the SUSPECT state to the BAD state, until the number of consecutive failed watchdog cycles reaches the value specified in the batchsvr.ini file. So, the total length of time before the server will consider a conversation BAD is the watchdog period multiplied by the tolerance limit for the number of watchdog failures. For example, if the watchdog period is set at 10,000 milliseconds, and the WatchdogCycles ini parameter is set at 5, then the FactoryTalk Batch Server will not change the status of a GOOD conversation to bad until at least 50 seconds (5x10) has passed.

Process-connected devices typically program their watchdogs using a single timer that is reset every time a write from the FactoryTalk Batch Server is detected. If the timer times out, the communication is considered bad, and all active phases are held.

Generally, we recommend that the tolerance in the process-connected device be set a little greater than that in the FactoryTalk Batch Server. For example, if the settings in the batchsvr.ini file specified a 10-second period and five timeouts, then the server would have a tolerance of 50 seconds. In this case, the tolerance in the process-connected device should probably be set somewhere in the 70-second range.

WATCHDOG: In the area model, a watchdog item is configured for each data server. The watchdog item is a Boolean value (16-bit integer for enhanced protocol) that is set by the server and reset by the data server.

Tags used in the watchdog protocol



PHASE_ST: The PLI indicates the phase’s current state by storing an integer value into the phase’s state tag. The possible states and their values are:

• ABORTING (10) • HOLDING (20)• STOPPING (30)• RESTARTING (40) • RUNNING (50) • HELD (60)• COMPLETE (70)• STOPPED (80)• ABORTED (90)• IDLE (100)

Boolean variable processing is simpler and more efficient in some process-connected devices. In those cases, the PLI can send Boolean values to the phase logic rather than the phase logic using the Status (_ST) to determine what to do. In those cases, the following Boolean variables, one for each state, can be added.

Tip: These tags are an internal communication method between the PLI and the phase logic and are not used in any way by the FactoryTalk Batch Server.

Active State flag Active State Complete flag Final State flag: PHASE_R Running PHASE_RC Running Complete PHASE_SD Stopped PHASE_T Restarting PHASE_TC Restarting Complete PHASE_C Complete PHASE_A Aborting PHASE_AC Aborting Complete PHASE_AD Aborted PHASE_H Holding PHASE_HC Holding Complete PHASE_HD Held PHASE_S Stopping PHASE_SC Stopping Complete PHASE_I Idle

PHASE_OC: The command tag (in conjunction with the command handshake) is used by the FactoryTalk Batch Server to issue commands to the phase logic. The commands for the phase logic state transition diagram that are relevant to phase state are:

• ABORT (10)• HOLD (20) • STOP (30)• RESET (40)• RESTART (90)• START (100)

Tags used for state transitions

Optional PLI Boolean communication with the phase



PHASE_OC: The command tag (in conjunction with the command handshake) is used by the FactoryTalk Batch Server to issue the Clear Failures command to the phase logic. The value of the Clear Failures command is:

• CLEAR FAILURES (130)

PHASE_F: The Failure flag used by the phase logic provides indication to the FactoryTalk Batch Server of when the phase logic has detected a failure of some type. A value of zero is recognized as no failure, and the values 1 through 32767 are recognized as failures with larger numbers representing more severe failures.

Tags used in the Failure protocol


Chapter 6

Request data from the FactoryTalk Batch Server

The request protocol allows phase logic to communicate with the FactoryTalk Batch Server. Writing phase logic centers around defining a sequence of steps for a phase. Some steps require interaction with the FactoryTalk Batch Server.

IMPORTANT The information in this guide only applies to programming phase logic for OPC and FactoryTalk Live Data phases. For information on developing phase logic for PhaseManager phases assigned to a Logix5000 CIP data server, see the FactoryTalk Batch PhaseManager User Guide or the Logix 5000 Controllers PhaseManager User Manual.

For example, the phase logic for a charge phase may perform these steps to add material to a unit:

Step Interacts with

Download target amount FactoryTalk Batch Server Acquire pump PM102 FactoryTalk Batch Server Reset totalizer Basic control Open valve FV101 Basic control Start pump PM102 Basic control Wait for totalizer to reach target Basic control Stop pump PM102 Basic control Close valve Basic control Release pump PM102 FactoryTalk Batch Server Unload actual amount FactoryTalk Batch Server

The request protocol is the mechanism used by the phase logic to interact with the FactoryTalk Batch Server. By following the protocol, the phase logic can notify the server that the phase needs attention and service the request. The intricacies of following the request protocol are normally handled by the PLI. This leaves the phase logic programmer with a simple programming model.

The typical phase logic sequence is:

1. Prepare for request (set reports, for example) 2. Set any request parameters, if needed3. Set the request 4. Wait for the request to be reset to zero (or one if using enhanced phase

logic requests)Tip: Allowing the phase logic to transition the phase to a terminal state (STOPPED, ABORTED, COMPLETE) without first verifying that the request register has been set to 0 (zero) or 1 (one) by the FactoryTalk Batch Server can result in future executions of the phase logic receiving faulty parameter data and can also result in the phase logic failing to release needed equipment.

Use this as a reference when programming request types:

• Download parameter values1XXX (or 11XXX)• Upload report parameter values2XXX (or 12XXX)• Send messages to the operator3XXX (or 13XXX)

Chapter 6 Request data from the FactoryTalk Batch Server


• Make requests to acquire/release resources4XXX (or 14XXX)• Send messages to other phases (coordination)5XXX (or 15XXX)• Abort a request 6000 (or 16000)• Download special values7XXX (or 17XXX)

During batch execution, phase logic can send a request to the FactoryTalk Batch Server to download values associated with its recipe phase parameters. The request can specify the number of values to be downloaded, the parameter IDs of the parameter values to be downloaded, a specific subset of parameter values to be downloaded, and the destination location of the parameter values within the process controller. A phase parameter ID is a positive integer and assigned when a phase is created in FactoryTalk Batch Equipment Editor.

The parameter values may be specified when a phase is added to a recipe using FactoryTalk Batch Recipe Editor. If the phase parameter value is not specified when the recipe is built, the FactoryTalk Batch Server sends FactoryTalk Batch View a request for the value when a Download Phase Parameter Values request is received from the phase. FactoryTalk Batch View displays an Unacknowledged prompt to request the phase parameter value from the operator.

Some download requests refer to the phase parameter using a parameter ID. If, when a download request is received, a phase parameter with the requested parameter ID has not been configured, the parameter ID is incremented by one and the phase parameter configured with that ID is obtained. This process is repeated until the originally requested ID has been incremented up to 999. If the requested number of phase parameters has not been found after the parameter ID is incremented to 999, a failure is generated by the FactoryTalk Batch Server and the batch is held according to the configured Hold Propagation.

Some requests do not use parameter IDs to specify the parameter values to be downloaded. The 1000 (or 11000) request will Download All Phase Parameter Values, including phase parameter limits that exist. The other requests are 1500, 1501 and 1502, which will download a specific subset of parameters as defined in the area model. 1501 (or 11501) will request the FactoryTalk Batch Server to download all phase parameter values belonging to the Download on Start subset. The 1502 (or 11502) request will request the FactoryTalk Batch Server to download all phase parameter values belonging to the Download on TOC (transfer of control) subset. Parameters are assigned to these subsets in FactoryTalk Batch Equipment Editor.

Requests that involve parameter subsets, control strategies and upload/download parameter subsets, require a one-to-one mapping between parameters and the tags. Parameter1 in control strategies will always be the control strategy parameter and must be downloaded to Tag1.

Download parameters



When a phase is created in the process controller, the phase parameter tags defined in the area model are viewed by the FactoryTalk Batch Server as a logical array. The parameter tag built against tag class PARMTR01 is considered to be the first element in the array. The parameter built against tag class PARMTR02 is considered to be the second, and so on. Download requests that specify an index into the parameter tag array are indexing into the logical array.

When a download request is processed, the phase parameter values are written into the phase parameter array, starting at the element specified by the array index. The manner in which the array index is determined varies based on the type of request.

The request illustrated above asks for the value for three phase parameters beginning with the parameter value associated with the parameter ID of 101. The values are downloaded to the phase parameter array with the first value going to element number 2. In this example, the phase has been configured with three parameters and the phase parameter values were specified when the recipe was created.

PHASE_RQ = 1103PHASEQ01 = 101PHASEQ02 = 2

Name: Temperature ID: 101 Value: 100 EU: Degrees C

Parameter

Name: Speed ID: 107 Value: 50 EU: RPM

Parameter

Name: Duration ID: 110 Value: 4.5 EU: Minutes

Parameter

Phase Parameters

Download Phase Parameter Values RequestDownload Request

Phase Parameter ArrayPLC orProcessController

BatchServer

Element Value12345678

0100

504.5

0000

Phase parameter tags array



The process controller may specify the following types of Download Phase Parameter Value requests.

• Request all phase parameter values (most common method) • Request a range of phase parameter values• Request a single phase parameter value• Request a subset of phase parameter values

You may download values for all configured phase parameters to the phase parameter array starting at the element specified by array index 1. If control strategies are enabled, only those parameters assigned to the recipe’s control strategy will be downloaded. The control strategy parameter will always be Parameter1.

Set the phase request tag to the following value to request all phase parameter values:

Phase Tag Value/Range Descriptions

PHASE_RQ 1000 (or 11000) Request a range of phase parameter values

You may download values for a range of phase parameters. The number of values to download is specified in the two least significant digits of the request (NN). The FactoryTalk Batch Server reads the parameter ID of the first parameter to download from the PHASEQ01 phase tag, and the index of the phase parameter array element into which the first value will be stored from the phase tag PHASEQ02.

The FactoryTalk Batch Server downloads the range of parameter values, starting with the value associated with the requested parameter ID and then the values of the phase parameters with incrementally higher parameter IDs, until the number of parameters downloaded matches the number of parameters requested. The parameter IDs need not increase sequentially.

If the phase associated with the parameter has Control Strategies enabled, only those parameters belonging to the enabled Control Strategy are included in the download.

Set the phase tags to the following values to request a range of phase parameter values:

Phase Tags Value/Range Descriptions PHASE_RQ 11NN (or 111NN) Request a range of phase parameter values PHASEQ01 Parameter ID of 1st phase parameter PHASEQ02 Index into the phase parameter array

This request is functionally identical to the previously described 11NN (or 111NN) request.

Types of Download Parameter requests

All phase parameter values

Range of phase parameter values

Range of phase parameter values - Indirect



Tip: This request is necessary only when the number of parameters to download exceeds 99 (two digits).

The difference is that rather than retrieving the number of values to be moved from the last two digits of the 11NN (or 111NN) request, the number of values to be moved is stored in the third request parameter. This form of request is useful when the number of values to move exceeds two digits.

The FactoryTalk Batch Server reads the parameter ID of the first parameter to download from the phase tag PHASEQ01. The index of the phase parameter array element into which the first value will be stored is read from the phase tag PHASEQ02. It reads the number of values to download from the PHASEQ03 phase tag.

The FactoryTalk Batch Server downloads the range of parameter values starting with the value for the phase parameter associated with the requested parameter ID, and then the values of the phase parameters with incrementally higher parameter IDs until the number of parameters read matches the number of parameters requested. The parameter IDs need not increase sequentially.

Set the phase tags to the following values to request a range of phase parameter values:

Phase Tags Value/Range Descriptions PHASE_RQ 1100 (or 11100) Request a range of phase parameter values PHASEQ01 Parameter ID of 1st phase parameter PHASEQ02 Index into the phase parameter array PHASEQ03 Number of phase parameters

You can download the value for a single phase parameter. The parameter ID of the requested parameter value is specified by the two least significant digits of the request (NN).

The FactoryTalk Batch Server downloads a single value for the recipe parameter associated with the parameter ID and stores the value to the phase parameter array at the element specified by array index (NN).

Set the phase request tag to the following value to request a single phase parameter value:

Phase Tag Value/Range Descriptions PHASE_RQ 12NN (or 112NN) Request a range of phase parameter values



The difference is that rather than retrieving the number of values to be moved from the last two digits of the 12NN (or 112NN) request, the FactoryTalk Batch

Single phase parameter value

Single phase parameter value - Indirect



Server reads the parameter ID associated with the requested parameter value, from the phase tag PHASEQ01.

The FactoryTalk Batch Server downloads a single value for the recipe parameter associated with the parameter ID, and stores the value to the phase parameter array at the element specified by array index 1.

Set the phase tags to the following values to request a single phase parameter value:

Phase Tags Value/Range Description PHASE_RQ 1200 (or 11200) Request a single phase parameter value PHASEQ01 >=1 Parameter ID of phase parameter

You may download the value for a single phase parameter and specify the destination location of the value. The parameter ID of the requested parameter value is specified by the two least significant digits of the request (NN). The index of the phase parameter array element to which the first value will be stored is read from the phase tag PHASEQ01.

The FactoryTalk Batch Server downloads a single value for the phase parameter specified by the parameter ID, and stores the value to the phase parameter array at the element specified by the array index found in the phase tag PHASEQ01.

Set the phase tags to the following values to request a single phase parameter value and to specify the destination location:

Phase Tags Value/Range Description PHASE_RQ 13NN (or 113NN) Request a single phase parameter value PHASEQ01 >=1 Index into the phase parameter array



The difference is that rather than retrieving the number of values to be moved from the last two digits of the 13NN (or 113NN) request, the FactoryTalk Batch Server reads the parameter ID associated with the requested parameter, from the PHASEQ01 phase tag, and reads the index of the phase parameter array element to which the value will be stored, from the PHASEQ02 phase tag.

The FactoryTalk Batch Server downloads a single value for the phase parameter specified by the parameter ID, and stores the value to the phase parameter array at the element specified by the array index found in the phase tag PHASEQ01.

Set the phase tags to the following values to request a single phase parameter value and to specify the destination location:

Single phase parameter value - Specify location

Single phase parameter value - Indirect/specify location



Phase Tags Value/Range Description PHASE_RQ 1300 (or 11300) Request a single phase parameter value PHASEQ01 >=1 Index into the phase parameter array PHASEQ02 >=1 Parameter ID of 1st phase parameter

You can download the values for phase parameters assigned to either the Download on Start or Download on TOC parameter subsets. Each parameter value is downloaded to the tag number matching the parameter’s defined ID. If a tag with a matching ID does not exist, the download fails and an error generates that holds the batch according to the configured hold propagation setting.

If the phase associated with the parameters has control strategies enabled, only those parameters belonging to both the enabled control strategy and the specified subset is included in the download.

Set the phase tags to the following values to request a subset of parameter values:

Phase Tags Value/Range Description

PHASE_RQ 1500 (or 11500) Request a subset of parameter values. PHASEQ01 =1

or =2

Indicates the subset to be downloaded: 1 = Download on Start 2 = Download on TOC

You can download the values for phase parameters assigned to the Download on Start parameter subset. Each parameter value is downloaded to the tag number matching the parameter’s defined ID. If a tag with a matching ID does not exist, the download fails and an error generates that holds the batch according to the configured hold propagation setting.

If the phase associated with the parameters has control strategies enabled, only those parameters belonging to both the enabled control strategy and the specified subset are included in the download.

Set the phase request tag to the following value to request the Download on Start subset of parameter values:


PHASE_RQ 1501 (or 11501) Request the Download on Start subset of parameter values.

You can download the values for phase parameters assigned to the Download on TOC parameter subset. Each parameter value is downloaded to the tag number matching the parameter’s defined ID. If a tag with a matching ID

Subset of parameter values

Subset of parameter values – Download on Start

Subset of parameter values – Download on TOC



does not exist, the download fails and an error generates that holds the batch according to the configured hold propagation setting.

If the phase associated with the parameters has control strategies enabled, only those parameters belonging to both the enabled control strategy and the specified subset are included in the download.

Set the phase request tag to the following value to request the Download on TOC subset of parameter values:


PHASE_RQ 1502 (or 11502) Request the Download on TOC subset of parameter values.

During batch execution, phase logic can send a request to the FactoryTalk Batch Server to download report limits information for all reports or for a single report. This allows for the ability to take corrective action if a report value is outside the configured limits. The limit configuration consists of the report’s verification method and each configured range of limits. The verification methods are written as values to the phase’s phase tags.

The values for the verification methods are:

Verification Method Value No_Limits 0

High / Low 1 High-High / Low-Low 2 High-High-High / Low-Low-Low 3

The process controller may specify the following types of Report Limits requests:

• Request all report limits information• Request the report limit configuration for a single report

Set the phase request tag to the following value to request the download of all report limit values:

Phase Tag Value/Range Description

PHASE_RQ 1600 (or 11600) Download All Report Parameter Verification configuration.

The FactoryTalk Batch Server downloads the entire phase’s report limit configuration to the phase’s limit tags.

Download report limits

Types of download Report Limits requests

All report limits information



The FactoryTalk Batch Server supports a request to download a single report parameter limit configuration to the phase’s limit tags. The value NNN is the parameter ID number of the report parameter of interest.

This phase logic request is functionally the same as the All Report Parameter Limit request described above except only the specified report parameter limit configuration values are downloaded.

Set the phase request to the following values to request the download of a single report parameter limit value:


PHASE_RQ 1601 (or 11601) Download a Single Report Parameter Verification configuration.

PHASEQ01 NNN Parameter ID number of the report parameter of interest.

The FactoryTalk Batch Server responds to the request by writing the verification method and report limits to the limit tags.

During batch execution, phase logic can send a request to the FactoryTalk Batch Server to upload report values. The request specifies the number of values to be uploaded, the report IDs associated with the report values, and where to get the values. The report ID is assigned at the time a report is created within a phase in FactoryTalk Batch Equipment Editor. The report ID is a positive integer.

Requests to upload a report value refer to the report using a report ID. If, when an upload request is received, a report with the requested report ID has not been configured, the report ID is incremented by one and the report configured with that ID is obtained. This process is repeated until the originally requested ID has been incremented up to 999. If the requested number of reports has not been found after the report ID is incremented up to 999, a failure is generated and the batch is held according to the configured HOLD propagation.

Some requests do not use report IDs to specify the report values to be uploaded. The 2000 (and 12000) request upload all phase report values. The other requests are 2500, 2501 and 2502, upload a specific subset of parameters. 2501 (or 12501) request the FactoryTalk Batch Server to upload all report parameter values belonging to the Upload on Terminal State subset. The 2502 (or 12502) request will request the FactoryTalk Batch Server to upload all phase report values belonging to the Upload on TOC (transfer of control) subset. Reports are assigned to these subsets in FactoryTalk Batch Equipment Editor.

Requests that involve report subsets, control strategies and upload/download parameter subsets, require a one-to-one mapping between report parameters and report tags.

Download single report parameter limits configuration

Upload report values



When an equipment phase is created in the process controller, the phase report parameter tags defined in the area model are viewed by the FactoryTalk Batch Server as a logical array.

The report parameter tag built against tag class REPORT01 is considered to be the first element in the array. The report parameter built against tag class REPORT02 is considered to be the second, and so on. Upload requests that specify an index into the report parameter tag array are indexing into the logical array. When an upload request is processed, the report values are read from the report array, starting at the element specified by the array index. The manner in which the array index is determined varies based on the type of request.

The illustration below depicts an Upload Report request. The request is for three report values starting with the report ID of 321. The values are uploaded from the report array with the first value coming from element number 2. In this example the phase class has been configured with three reports.

The report values are combined with the following information, then written as entries into the electronic batch record. They are also stored in memory so they can be referenced by transition expressions.

• Batch ID • Recipe Name • Process Cell • Time/Date • Unit ID • Area • Phase Name • Engineering Units • Report Description

PHASE_RQ = 2103PHASEQ01 = 321PHASEQ02 = 2

Name: Temperature ID: 321 EU: Degrees C

Report

Name: Speed ID: 327 EU: RPM

Report

Name: Duration ID: 330 EU: Minutes

Report

Report Events

Upload Report Values RequestUpload Request

Report ArrayPLC orProcessController

BatchServer

Element Value12345678

0102

504.33

0000

Report array

Electronic batch record entries



The phase logic may specify the following types of report upload requests:

• Upload all report values (most common method)• Upload a range of report values• Upload a single report value• Upload a subset of report values

You can upload all report parameters. Upload values for all configured reports from the report array starting at the element specified by array index 1.

Set the phase request tag to the following value to send a request to upload all report parameters:


PHASE_RQ 2000 (or 12000) Upload all report parameters

If control strategies are enabled, only those reports assigned to the recipe’s control strategy are uploaded.

You can upload values for a range of reports. The number of values to upload is specified in the two least significant digits of the request (NN). The FactoryTalk Batch Server reads the report ID associated with the first requested report from the PHASEQ01 phase tag, and the index of the first report array element from the phase tag PHASEQ02.

The FactoryTalk Batch Server uploads the range of parameter values, starting with the value associated with the requested report ID and then the values of the report with incrementally higher report IDs until the number of reports for which values are uploaded matches the number of reports requested. The report IDs need not increase sequentially.

Set the phase tags to the following values to send a request to upload a range of report parameters:

Phase Tag Value/Range Description PHASE_RQ 21NN (or 121NN) Upload a range of report parameters PHASEQ01 Report ID of 1st report PHASEQ02 Index into the report array



The difference is that rather than retrieving the number of values to be moved from the last two digits of the 21NN (or 121NN) request, the FactoryTalk Batch Server reads the number of values to upload from the PHASEQ03 phase tag,

Types of upload report requests

All report values

Range of report parameter values

Range of report values - Indirect



reads the report ID of the first report value to upload from the PHASEQ01 phase tag, and reads the index of the report array element from which the first value is obtained from the phase tag PHASEQ02.

The FactoryTalk Batch Server uploads the value associated with the starting report ID and then the values of the reports with incrementally higher report IDs until the number of report values read matches the number of reports requested. The report IDs need not increase sequentially.

Set the phase tags to the following values to send a request to upload a range of report parameters:


PHASE_RQ 2100 (or 12100) Upload a range of report parameters PHASEQ01 >=1 Report ID of 1st report PHASEQ02 >=1 Index into the report array

PHASEQ03 >=1 Number of report values

You may upload a value for a single report. The report ID of the associated report value is specified by the two least significant digits of the request (NN). The FactoryTalk Batch Server uploads a single report value from the report array at the element specified by array index 1.

Set the phase request tag to the following value to send a request to upload a single report:

Phase Tag Value/Range Description PHASE_RQ 22NN (or 122NN) Upload a single report parameter

This request is functionally identical to the previously described 22NN (or122NN) request.


The difference is that rather than retrieving the number of values to be moved from the last two digits of the 22NN (or 122NN) request, the FactoryTalk Batch Server reads the report ID associated with the requested report value from the PHASEQ01 phase tag.

Upload a single report value from the report array at the element specified by array index 1.

Set the phase tags to the following values to send a request to upload a single report parameter:

Phase Tag Value/Range Description PHASE_RQ 2200 (or 12200) Upload single report parameter PHASEQ01 >=1 Report ID of report

Single report parameter value

Single report value - Indirect



You can upload a value for a single report and specify the source location of the value. The report ID for the requested report value is specified by the two least significant digits of the request (NN). The FactoryTalk Batch Server reads the index of the report array element from the PHASEQ01 phase tag. The index tells the server where in the report array to get the report value.

The FactoryTalk Batch Server uploads a single report value from the report array at the element specified by the array index.


Phase Tag Value/Range Description PHASE_RQ 23NN (or 123NN) Upload a single report parameter PHASEQ01 >=1 Index into the report array


This request is functionally identical to the previously described 23NN (or 123NN) request. The difference is that rather than retrieving the number of values to be moved from the last two digits of the 23NN (or 123NN) request, the FactoryTalk Batch Server reads the report ID for the associated report value from the PHASEQ02 phase tag, and the index of the report array element from the phase tag PHASEQ01. The index tells the server where in the report array to get the report value.

The FactoryTalk Batch Server uploads a single report value from the report array at the element specified by array index.


Phase Tag Value/Range Description PHASE_RQ 2300 (or 12300) Upload single report parameter PHASEQ01 >=1 Index into the report array PHASEQ02 NN Report ID of report

You can upload a subset of values for a group of reports. The FactoryTalk Batch Server reads the request and then refers to the appropriate subset and the reports assigned to that subset.

The FactoryTalk Batch Server uploads the subset of report values that are assigned to the request number subset. The 2501 (or 12501) request uploads the report parameters for the Upload on Terminal State subset, and the 2502 (or 12502) request uploads the report for the Upload on TOC subset. Sets are defined in the area model using FactoryTalk Batch Equipment Editor.

If the phase associated with the report parameters has control strategies enabled, only those report parameters belonging to both the enabled control strategy and the specified subset will be included in the upload.

Single report parameter value - Specify location

Single report parameter value - Indirect/specify location

Subset of report values



Set the phase tags to the following values to request an Automatic Report Upload subset of report values and to specify the destination location:

Phase Tags Value/Range Description PHASE_RQ 2500 (or 12500) Request a subset of report values. PHASEQ01 >=1 or 2 Index into the report array.

You can upload a subset of values for a group of reports. The FactoryTalk Batch Server reads the request and then refers to the appropriate subset and the reports assigned to that subset.

The FactoryTalk Batch Server uploads the subset of report values that are assigned to the request number subset. The 2501 (or 12501) request uploads the reports for the Upload on Terminal State subset.

If the phase associated with the reports has control strategies enabled, only those reports belonging to both the enabled control strategy and the Upload on Terminal State subset will be included in the upload.

Set the phase request tag to the following value to request an Automatic Report Upload subset of report values and to specify the destination location:

Phase Tags Value/Range Description PHASE_RQ 2501 (or 12501) Request the Upload on Terminal State subset of report parameter

values.

You can upload a subset of values for a group of report parameters. The FactoryTalk Batch Server reads the request and then refers to the appropriate subset and the report parameters assigned to that subset.

The FactoryTalk Batch Server uploads the subset of report parameter values that are assigned to the request number subset. The 2502 (or 12502) request uploads the report parameters for the Upload on TOC subset.

If the phase associated with the report parameters has control strategies enabled, only those report parameters belonging to both the enabled control strategy and the specified subset are included in the upload.

Set the phase request tag to the following value to request an Automatic Report Parameter Upload subset of report parameter values and to specify the destination location:

Phase Tags Value/Range Description PHASE_RQ 2502 (or 12502) Request the Upload on TOC subset of parameter values.

The set of possible messages that may be sent by the phase logic is configured when the associated phase is defined in the area model using FactoryTalk Batch Equipment Editor. Each operator message is configured with a message ID, a positive integer. Requests to send a message refer to the

Subset of report parameter values - Upload on Terminal State

Subset of report values - Upload on TOC

Send messages to the operator and clear messages



message using the message ID. During batch execution, phase logic can make a request to the FactoryTalk Batch Server to send a message to FactoryTalk Batch View and place the message into the electronic batch record.

A Send Message to Operator request displays a message to the operator. In FactoryTalk Batch View, it is displayed on the Phase Summary screen. However, this type of request does not provide a mechanism to solicit information from the operator.

The phase logic can also be configured to send a Clear Message to Operator request. This request clears the currently displayed message.

Send the message with a specified message ID to the FactoryTalk Batch client. The message ID is specified in the two least significant digits of the request (NN).

Set the phase request tag to the following value to send the operator a message:


PHASE_RQ 30NN (or 130NN) Send a message to the operator

This request is functionally identical to the previously described 30NN (or 130NN) request. This request may be used when the message ID is greater than 99. The difference is that rather than retrieving the number of values to be moved from the last two digits of the 30NN (or 130NN) request, the message ID is specified in the two least significant digits of the request (NN). The FactoryTalk Batch Server reads the message ID from the PHASEQ01 phase tag, then sends the associated message to the FactoryTalk Batch client.


Set the phase tags to the following values to send the operator a message:

Phase Tags Value/Range Description PHASE_RQ 3000 (or 13000) Send a message to the operator PHASEQ01 NN>=1 Message ID

Clear the currently displayed message.

Set the phase request tag to the following value to clear the message:


PHASE_RQ 3100 (or 13100) Clear a message

During batch execution, phase logic can issue a request to the FactoryTalk Batch Server to acquire a pre-configured resource. Each resource configured

Send message

Send a message - Indirect

Clear message

Acquire resources



with FactoryTalk Batch Equipment Editor is assigned an equipment ID, which is a positive integer. Requests to acquire a resource refer to the resource using the equipment ID.

Resources are acquired when the Acquire Resources request is issued. Acquired resources are released either by the Release Resources phase request or when the phase step is removed from the set of active steps in the recipe.

The phase logic may acquire resources using the following requests:

• Acquire a Single Resource• Acquire Multiple Resources

The types of acquire requests are explained below.

You can send a request to acquire a single resource. The equipment ID of the resource is specified by the two least significant digits of the request (NN). The FactoryTalk Batch Server acquires the resource specified by the equipment ID.

Set the phase request tag to the following value to send a request to acquire a single resource:

Phase Tag Value/Range Description PHASE_RQ 40NN (or 140NN) Send a request to acquire a single resource

This request is functionally identical to the previously described 40NN (or 140NN) request. The difference is that rather than retrieving the number of values to be moved from the last two digits of the 40NN (or 140NN) request, the FactoryTalk Batch Server reads the equipment ID from the PHASEQ01 phase tag then acquires the resource specified by the equipment ID.

Tip: This request is necessary only when the number of parameters to download exceeds 99 (two digits). Otherwise, use the 40NN (or 140NN) request.

Set the phase tags to the following values to send a request to acquire a single resource:

Phase Tag Value/Range Description PHASE_RQ 4000 (or 14000) Acquire a single resource PHASEQ01 >=1 Equipment ID

You can acquire up to 99 resources with this request.

The number of resources to acquire is specified by the two least significant digits of the request (NN). The FactoryTalk Batch Server reads the number of equipment IDs specified in the request from the phase tags. Then the server acquires the resources associated with the equipment IDs.

Types of acquire requests

Acquire a single resource

Acquire a single resource - Indirect

Acquire multiple resources



Set the phase tags to the following values to send a request to acquire multiple resources:

Phase Tag Value/Range Description PHASE_RQ 41NN (or 141NN) Acquire multiple resources PHASEQ01 >=1 Equipment ID to acquire PHASEQ02 >=1 Equipment ID to acquire PHASEQ03 >=1 Equipment ID to acquire

During batch execution, phase logic can issue a request to the FactoryTalk Batch Server to release a resource. Each resource configured with FactoryTalk Batch Equipment Editor is assigned an equipment ID, a positive integer. Requests to release a resource refer to the resource using the equipment ID. Only resources that were previously acquired with an Acquire Resources phase request can be released using the Release Resources phase request.

The process controller may release resources using the following requests:

• Release a Single Resource• Release Multiple Resources • Release All Currently Acquired Resources

The types of release requests are explained below.

You can release a single resource. The equipment ID of the resource is specified by the two least significant digits of the request (NN).

The FactoryTalk Batch Server releases the resource specified by the equipment ID if the phase had previously acquired the resource through an Acquire Resources request.

Set the phase request tag to the following value to send a request to release a single resource:

Phase Tag Value/Range Description PHASE_RQ 42NN (or 142NN) Release a single resource

This request is functionally identical to the previously described 42NN (or 142NN) request. The difference is that rather than retrieving the number of values to be moved from the last two digits of the 42NN (or 142NN) request, the FactoryTalk Batch Server reads the equipment ID from the PHASEQ01 phase tag. The server releases the resource associated with the equipment ID if the resource had been previously acquired by this phase via an Acquire Resource request.

Tip: This request is necessary only when the equipment ID exceeds 99 (two digits). Otherwise, use the 42NN (or 142NN) request.

Release resources

Types of release requests

Release a single resource

Release a single resource - Indirect



Set the phase tags to the following values to send a request to release a single resource:


PHASE_RQ 4200 (or 14200) Release a single resource PHASEQ01 >=1 Equipment ID to release

You can release up to 99 resources with this request. The number of resources to release is specified by the two least significant digits of the request (NN). The FactoryTalk Batch Server reads the number of equipment IDs specified in the request, from the phase tags. The FactoryTalk Batch Server releases the resources associated with the equipment IDs if this phase previously acquired the resources through an Acquire Resources request.

Set the phase tags to the following values to send a request to acquire multiple resources:


PHASE_RQ 43NN (or 143NN) Release multiple resources PHASEQ01 >=1 Equipment ID to release PHASEQ02 >=1 Equipment ID to release PHASEQ03 >=1 Equipment ID to release

You can release all the resources that have been acquired by a phase via an Acquire Resource request.

The FactoryTalk Batch Server releases the resources associated with the equipment IDs if the resources had been previously acquired by this phase through an Acquire Resource request.

Set the phase request tag to the following value to send a request to release all currently owned resources:


PHASE_RQ 4400 (or 14400) Release a single resource

Phases controlled by phase steps that belong to a synchronization group are able to communicate with each other. In fact, this defines the role of the synchronization group. Messages are sent between the phase steps within the synchronization group. Each message is assigned a unique message ID, a positive integer. Requests to send a message to another phase through the synchronization group refer to the message using the message ID and the number of phases that will receive the message.

Phase communication can be used for the following purposes:

• Synchronization: A synchronization function can be performed toensure that multiple phases are in agreed upon states before they

Release multiple resources

Release all currently acquired resources

Send messages to other phases



proceed. Since the phases can execute synchronization through this messaging function, no additional phase synchronization is implemented in the phase, unit or batch executives.

Tip: Synchronization cannot be used in conjunction with FactoryTalk Batch’s Transfer of Control feature.

• Permissive: A permissive function can be performed to ensure thatone phase of the synchronization group has passed a certain point inits phase logic before other phases can proceed.

• Data Transfer: A data passing function can be performed to move datafrom one phase to another.

A Send Message Wait and a Receive Message Wait request pair is complete only if the message IDs for each of the calls are identical. This prevents messages from being routed to the improper request. Additionally, the Send Message Wait call must specify the number of receives confirmed as a parameter. This number allows for synchronization groups with more than two members.

Upon receiving the Send Message call, the FactoryTalk Batch Server stores the message into the message list and actively responds to outstanding or incoming Receive Message Wait calls from other phases within the synchronization group. When a Receive Message Wait call is received from a phase of the synchronization group, the server checks the message ID and completes the message if appropriate. Upon completion of the message transfer, the server removes the message from the message list.

You can specify the following types of send message requests:

• Send a Message• Send a Message and Wait• Send a Message and Wait for One Receiver

Completion of messages

Process Send and Receive messages

Types of messages to other phases



You can send a message to another phase. The message ID of the message is specified by the two least significant digits of the request (NN). The FactoryTalk Batch Server reads the number of phases that will receive the message from the PHASEQ01 phase tag and the message values from the other phase tags.

Set the phase tags to the following values to send a message to another phase:


PHASE_RQ 50NN (or 150NN) Send a message PHASEQ01 >=1 Number of receivers PHASEQ02 Message value 1 PHASEQ03 Message value 2

You can send a message to another phase indirectly by specifying the message ID in the PHASEQ01 phase tag. The FactoryTalk Batch Server reads the message ID from the PHASEQ01 phase tag.

The FactoryTalk Batch Server reads the number of phases that will receive the message from the PHASEQ02 phase tag and the message values from the other phase tags.


PHASE_RQ 5000 (or 15000) Send a message PHASEQ01 >=1 Message ID PHASEQ02 >=1 Number of receivers PHASEQ03 Message value 1 PHASEQ04 Message value 2 PHASEQ05 Message value 3

You can send a message and wait for a response. The message ID of the message is specified by the two least significant digits of the request (NN). The FactoryTalk Batch Server reads the number of phases that will receive the message, from the PHASEQ01 phase tag and the message values from the other phase tags.

The receiving partners must issue a request before the data is sent. The sending partner may send the data at any time. The sending phase waits for confirmation of the responses from the total number of receivers before continuing. The data is cached in the FactoryTalk Batch Server until the receiving partner(s) makes a request to receive the data.

Send a message

Send a message - Indirect

Send a message and wait



Set the phase tags to the following values to send a message and wait for a response from another phase:


PHASE_RQ 51NN (or 151NN) Send a message and wait PHASEQ01 >=1 Number of receivers for which to wait PHASEQ02 Message value 1 PHASEQ03 Message value 2

You can send a message and wait for a response indirectly by specifying the message ID from the PHASEQ01 phase tag. The FactoryTalk Batch Server reads the message ID for the message from the PHASEQ01 phase tag, the number of phases that will receive the message, from the PHASEQ02 phase tag, and the message values from the remaining phase tags.

The receiving partner must issue a request before the data is sent. The sending partner may send the data at any time. The sending phase waits for confirmation of the responses from the total number of receivers before continuing. The data will be cached in the FactoryTalk Batch Server until the receiving partner makes a request to receive the data.

Set the phase tags to the following values to send a message to another phase and wait for a response:


PHASE_RQ 5100 (or 15100) Send a message and wait PHASEQ01 >=1 Message ID PHASEQ02 >=1 Number of receivers for which to wait PHASEQ03 Message value 1 PHASEQ04 Message value 2 PHASEQ05 Message value 3

You can send a message and wait for one receiver. The message ID for the associated message is specified in the two least significant digits of the request (NN). The FactoryTalk Batch Server reads the message values from the other phase tags.

The receiving partner must issue a request before the data is sent. The sending partner may send the data at any time. The sending phase logic waits for confirmation of the responses from the one receiver before continuing. The data will be cached in the FactoryTalk Batch Server until the receiving partner makes a request to receive the data.

Send a message and wait - Indirect

Send a message and wait for one receiver



Set the phase tags to the following values to send a message to another phase and wait for one receiver:


PHASE_RQ 52NN (or 152NN) Send a message and wait for one receiver

PHASEQ01 Message value 1 PHASEQ02 Message value 2

You can send a message and wait for one receiver indirectly by specifying the message ID in the PHASEQ01 phase tag. The FactoryTalk Batch Server reads the message ID for the message from the PHASEQ01 phase tag, and the message values from the other phase tags.

The receiving partner must issue a request before the data is sent. The sending partner may send the data at anytime. The sending phase logic waits for confirmation of the responses from the one receiver before continuing. The data is cached in the FactoryTalk Batch Server until the receiving partner makes a request to receive the data.

Set the phase tags to the following values to send a message to another phase and wait for one receiver:


PHASE_RQ 5200 (or 15200) Send a message and wait for one receiver PHASEQ01 >=1 Message ID PHASEQ02 Message value 1 PHASEQ03 Message value 2

The Send Message to Linked Phase call can be canceled by the phase logic that sent the message. The phase logic can remove the message by using the Cancel Message to Linked Phase request. Upon receiving the Cancel Message to Linked Phase request, the FactoryTalk Batch Server removes the message from the message queue and clears the request on the phase.

You can specify the following types of cancel message requests:

• Cancel a Single Message• Cancel All Messages

Each type of Cancel Message request is explained below.

You can cancel a message to another phase. The message number is specified in the two least significant digits of the request (NN). The FactoryTalk Batch Server cancels the message associated with the message ID. The message was previously issued using a send message request.

Send a message and wait for one receiver - Indirect

Cancel messages to other phases

Types of cancel message requests

Cancel a single message



Set the phase request tag to the following value to send a request to cancel a message to another phase:


PHASE_RQ 53NN (or 153NN) Send a request to cancel a message to another phase

You can cancel a message to another phase indirectly by specifying the message ID in the PHASEQ01 phase tag. The FactoryTalk Batch Server reads the message ID from the PHASEQ01 phase tag and cancels the message associated with the message ID, if it was previously issued using a send message request.

Set the phase tags to the following values to send a request to cancel all messages sent to another phase:


PHASE_RQ 5300 (or 15300) Cancel a message PHASEQ01 >=1 Message ID

Cancels all messages to other phases. The FactoryTalk Batch Server cancels all messages that were previously issued with a Send Message to Linked Phase request.

Set the phase request tag to the following value to send a request to cancel all messages sent to other phases:


PHASE_RQ 5400 (or 15400) Cancel all messages

The Receive Message from Linked Phase request allows phase logic to notify the FactoryTalk Batch Server that it is prepared to receive a message or a set of messages from a linked phase. The server then scans the synchronization group for pending messages with matching message IDs. The server completes the message transfer by storing the message values into PHASEQ01 through PHASEQNN, where NN is the number of Message Values received. The server then clears the request code on the phase logic.

You can send a request to wait for a message from another phase. The message ID associated with the incoming message is specified in the two least significant digits of the message (NN). The FactoryTalk Batch Server stores the message values into the phase tags.

Set the phase tags to the following values to send a request to wait for a message from another phase:

Cancel a message - Indirect

Cancel all messages

Receive message from linked phases

Receive a message from a linked phase




PHASE_RQ 55NN (or 155NN) Wait for a message from another phase PHASEQ01 Message value 1 PHASEQ02 Message value 2 PHASEQ03 Message value 3

You can send a request to wait for a message from another phase indirectly by specifying the message ID in the PHASEQ01 phase tag. The message ID associated with the incoming message is specified in the PHASEQ01 phase location. The FactoryTalk Batch Server stores the message values into the other phase tags.

Set the phase tags to the following values to send a request to wait for a message from another phase:


PHASE_RQ 5500 (or 15500) Wait for a message from another phase PHASEQ01 >=1 Message ID PHASEQ02 Message value 1 PHASEQ03 Message value 2

A request that is in process can be canceled by using the Abort Request call.

Set the phase request tag to the following value to cancel the request that is in process:


PHASE_RQ 6000 (or 16000) Cancel the request in process

While a batch is processing, batch data may be downloaded to a specific tag. The request must specify the actual tag number to which the parameter is downloaded. The exception is when the actual tag number exceeds 99. In those instances the FactoryTalk Batch parameter may be downloaded indirectly.

IMPORTANT The 7600/17600 and 7700/17700 requests are exceptions to the rest of the requests in this category in that they do NOT require you to specify the tag to which the data will be stored. Instead, the parameter Min and Max values are downloaded to the actual controller tags associated with the parameters on the phase itself. Note that the Min and Max values are downloaded for ALL the parameters on the phase without exception (including Strings and Enumerations).

The data type of the requested item must match the data type of the specified parameter.

Set the phase tags to the following values to download a FactoryTalk Batch parameter:


Receive a message from a linked phase - Indirect

Abort request

Download batch data



PHASE_RQ 71NN (or 171NN) Batch ID: Download customer’s batch ID to tag number NN Server downloads an ASCII – String value.

PHASE_RQ 72NN (or 172NN) Unique Batch ID: Download unique batch ID to tag number NN Server downloads an ASCII – Integer value.

PHASE_RQ 73NN (or 173NN) Phase ID: Download phase equipment ID to tag number NN Server downloads an ASCII - Integer value.

PHASE_RQ 74NN (or 174NN) Control: Download a value to indicate whether the phase is under recipe control or manual phase control, to tag number NN Server will download: 0 = Recipe Control 1 = Manual Phase Control

PHASE_RQ 75NN (or 175NN) Mode: Download a value to indicate the current mode of the requesting phase to tag number NN Server will download: 1 = P-Auto 2 = O-Auto

PHASE_RQ 7600 (or 17600) Parameter Min: Download all phase parameter MIN values to the controller tags associated with those parameters. The 7600/17600 and 7700/17700 requests do NOT require you to specify the tag to which the data will be stored.

PHASE_RQ 7700 (or 17700) Parameter Max: Download all phase parameter MAX values to the controller tags associated with those parameters. The 7600/17600 and 7700/17700 requests do NOT require you to specify the tag to which the data will be stored.

During batch execution, phase logic can issue a request to the FactoryTalk Batch Server to generate a signature request. Each signature template is assigned a unique ID, which is a positive integer. Requests to generate a signature specify the desired Signature Template ID. The Signature Template ID of the signature to be generated is specified by the two least significant digits of the request (NN).

Set the phase tag to the following value to send a request to generate a signature:


PHASE_RQ 79NN (or 179NN) Send a request to generate a single signature. PHASEQ01 0 or non-zero Flag indicating if signature is can be canceled.

0 = NO non-zero = YES

This request is functionally identical to the previously described 79NN request. This request is necessary when the Signature Template ID exceeds 99.

Set the phase tags to the following values to send a request to generate a Signature:


Generate an electronic signature request

General Signature request - Indirect



PHASE_RQ 7900 (or 17900) Send a request to generate a single signature. PHASEQ01 >=1 Signature Template ID. PHASEQ02 0 or non-zero Flag indicating if signature can be canceled.

0 = NO non-zero = YES

Series PHASEQ01 PHASEQ02 Description

7801 (or 17801) Attribute Id Tag # Download data about the container currently in use.

7802 (or 17802) Attribute Id Tag # Download data about the current material inside the container currently in use.

7803 (or 17803) Attribute Id Tag # Download data about the current lot inside the container currently in use.

7811 (or 17811) Attribute Id Tag # Upload data about the container currently in use. 7812 (or 17812) Attribute Id Tag # Upload data about the current material inside the container

currently in use. 7813 (or 17813) Attribute Id Tag # Upload data about the current lot inside the container currently in

use. 7821 (or 17821) Tag # >0 Download the current binding's container priority. 7822 (or 17822) Tag # >0 Upload a new container priority for the current binding. 7831 (or 17831) Tag # >0 Download data about sufficient material for step.

Series Description Functionality Supported

80NN (or 180NN) Download Material Attributes single attribute, single value downloaded

81NN (or 181NN) Download Lot Attributes single attribute, single value downloaded 83NN (or 183NN) Download Container Attributes single attribute, single value downloaded 84NN (or 184NN) Downloading Container Priority Assignments single attribute, single value downloaded 85NN (or 185NN) Uploading Material Attributes single attribute, single value uploaded 86NN (or 186NN) Uploading Lot Attributes single attribute, single value uploaded 88NN (or 188NN) Uploading Container Attributes single attribute, single value uploaded 89NN (or 189NN) Uploading Container Priority Assignments single attribute, single value uploaded

Download material-based data


Chapter 7

Request data from the Material Server

IMPORTANT The information in this guide only applies to programming phase logic for OPC and FactoryTalk Live Data phases. For information on developing phase logic for PhaseManager phases assigned a Logix5000 CIP data server, see the FactoryTalk Batch PhaseManager User Guide or the Logix 5000 Controllers PhaseManager User Manual.

Most of the fields within FactoryTalk Batch Material Manager’s material database are made available to the phase logic programmer for reading, some for writing, through the Phase PLI. Access to the data requires two things: the controller ID for the database entity and the index of the data on that entity.

There are three classifications of data in the material database; materials, lots, and containers.

There are two types of data for each of these classifications:

• Standard Attributes: Standard attributes are materials, lots andcontainers.

• Custom Attributes: Custom attributes are the properties of thematerials, containers, and lots defined in the material database.

The priority used to select containers for use can also be accessed. Container priorities are runtime data that are dependent on the area model data uploaded into the database by the FactoryTalk Batch Server. They help the server select a container to use given the material required, its feed type (addition or distribution), the unit and finally the container priority. This data is accessed with separate PCD interfaces from those used for standard attributes and custom attributes.

All of the data is accessible by an attribute ID which specifies a field.

Materials, lots, or containers are referenced directly using the 8000 (or 18000) series commands or indirectly using the 7800 (or 17800) series commands.

Standard attributes are attributes that exist by default on a data entity. The attribute ID for a standard attribute is the index.

Field Name Description Data Type Index PLI Access ID Unique Primary Key for a material Integer 1 Read

Name Material name String 2 Read Controller ID Integer ID for phase logic programmer to reference this

material Integer 3 Read

Standard attributes

Material standard attributes

Chapter 7 Request data from the Material Server


Field Name Description Data Type Index PLI Access Description Material description String 4 Read/Write EU Engineering Units for measuring the material String 5 Read Inventory Key Optionally used field for storing an identifier for this

material; used by third-party inventory control systems String 6 Read

Last Edited By The user ID (Windows logon) of the last user who changed a data field of this material

String 7 Read

Last Modification Date The time a change was made to a data field of this material

String 8 Read

Label Usage Specifies that the selection of a container holding this material may be filtered by an assigned label. Labels used are: 1 - Batch ID 2 - Product Name 3 - Custom Name

String 9 Read

Classification Designation of this material belonging to a particular class of materials. This is the ordinal of the Classification enumeration as defined by the Material Editor.

Integer 10 Read

MaterialGroupID Primary key of the Material Group assigned to the material

Integer 11 Read

DefaultLotState ID

Primary key to the Lot State assigned to the material Integer 12 Read

Field Name Description Data Type Index PLI Access

ID Unique Primary Key for a lot Integer 1 Read Name Lot name String 2 Read Controller ID Integer ID for phase logic programmer to reference this

lot Integer 3 Read

Description Lot description String 4 Read/Write EU Engineering Units for measuring the material. Note that

this data actually resides on the Material and not the Lot. The Material Server business rules are expected to return the correct value.

String 5 Read

Inventory Key Optionally used field for storing an identifier for this lot; used by third-party inventory control systems

String 6 Read

Last Edited By The user ID (Windows logon) of the last user who changed a data field of this material

String 7 Read

Creation Date Time this lot was entered into the database String 8 Read

Depletion Date The time when this lot was completely consumed String 9 Read Material Material ID value Integer 10 Read State The state of the lot 1 - Lot Available for Use Integer 11 Read/Write

Quantity Amount of material in the lot Real 12 Read

Lot standard attributes




ID Unique Primary Key for a container Integer 1 Read Name Container name String 2 Read Controller ID Integer ID for phase logic programmer to reference this

container Integer 3 Read

Description Container description String 4 Read/Write EU Engineering Units for measuring the material String 5 Read

Capacity The container’s maximum capacity Real 6 Read/Write ContainerType Container Type defines what type of container the user is

dealing with. The possible values are: 1=Composite Container 2=Plug-Flow Container 3=Pallet Container

Integer 7 Read

StateID The ID value that represents the current State of the Container. ID values correlate to the tbContainerState table.

Integer 8 Read/Write

Storage Location The ID value for the Storage Location (zero if the container is not part of a storage location).

Integer 9 Read

Heel The value (quantity) of the Container Heel (the amount of inventory that remains in a container after all of the accessible inventory has been removed).

Real 10 Read/Write

Custom attributes are user-defined properties of materials, lots or containers. Custom attributes can be accessed in addition to the standard attributes. Each property that is added in the FactoryTalk Batch Material Manager material database has a controller ID, which begins at 1000 and is incremented by 10. Several fields are made available for each attribute, which are indexes.

The attribute ID of the custom attribute is calculated from the controller ID plus the index.


Container standard attributes

Custom attributes

Material custom attribute fields




ID Unique Primary Key for a material attribute String 1 Read

Name Material property name of the String 2 Read

Controller ID The ID for this attribute Integer 3 Read Description Material attribute description String 4 Read/Write EU Engineering Units for measuring the material String 5 Read

Data Type The data type of the maximum and minimum values: • Real = 0 • Integer = 1 • String = 2

Integer 6 Read

Maximum Maximum of the range of values acceptable for this material.

Real, Integer or String

7 Read

Minimum Minimum of the range of values acceptable for this material

Real, Integer or String.

8 Read


ID Unique Primary Key for a lot attribute String 1 Read Name Lot property name String 2 Read Controller ID The ID for this attribute Integer 3 Read Description Lot attribute description String 4 Read/Write EU Engineering Units for measuring the material String 5 Read


Integer 6 Read

Maximum Maximum of the range of values acceptable for this material.

Real, Integer or String

7 Read

Minimum Minimum of the range of values acceptable for this material

Real, Integer or String.

8 Read

Value The attribute value. Real, Integer or String.

9 Read/Write


ID Unique Primary Key for a container attribute String 1 Read

Name Container property name String 2 Read

Controller ID The ID for this attribute Integer 3 Read Description Container attribute description String 4 Read/Write EU Engineering Units for measuring the contents of the

container String 5 Read


Integer 6 Read

Value The attribute value. Real, Integer or String.

7 Read/Write

Lot custom attribute fields

Container custom attribute fields



Writing phase logic for a material phase requires some additional consideration. The FactoryTalk Batch Server requires that a simple protocol be followed by the phase logic programmer to ensure that inventory levels are properly maintained within the material database and that the FactoryTalk Batch Event Journal contains entries identifying the inventory that was produced or consumed.

The protocol is:

• The phase logic must request a download of the AMOUNT parameter.• Before entering a terminal state (COMPLETE, STOPPED or

ABORTED), the phase logic must upload the ACTUAL_AMOUNT andFEED_COMPLETE report parameters. The sign of the value in theACTUAL_AMOUNT report parameter must match the configured feedtype: Additions are positive or zero; Distributions are negative or zero.Deviating from this results in an error and the batch being HELD.

• The Automatic Upload/Download functionality can be used to meetthis protocol requirement. When used, the AMOUNT parameter isdownloaded by the FactoryTalk Batch Server before the phase iscommanded to start and the ACTUAL_AMOUNT andFEED_COMPLETE report parameters is uploaded after the phase logicruns to a terminal state. This simplifies the writing of phase logic.

Tip: When the Automatic Upload function is enabled, the FactoryTalk Batch Server automatically uploads the appropriate report values when the batch transitions to a terminal state. If the server is stopped while a material-enabled phase is uploading its report parameters, these report parameters are uploaded again during a Warm or Warm All FactoryTalk Batch Server Restart. This also occurs when a material-enabled phase transitions to External while the report parameters are being uploaded. When the material-enabled phase transitions back to Program mode, the report parameters are uploaded a second time. Sometimes this generates an error that puts the batch in Hold. Issue a clear failures command to restart the batch so execution proceeds normally. To avoid this, disable the Automatic Upload function and perform report parameter uploads using phase logic requests.

Write a material phase



The following diagram is an example of a phase process:

1. The command to START the phase is issued from the FactoryTalkBatch Server. The RUNNING program eventually begins.

2. The phase logic sends a request to download the AMOUNT parameterfrom the FactoryTalk Batch Server.

3. The FactoryTalk Batch Server requests a Promise ID from the MaterialServer. This establishes an accounting data entity for tracking theinventory used.

4. The Material Server returns SUCCESS for the Promise ID to theFactoryTalk Batch Server. This is used by the FactoryTalk Batch Serverduring warm restarts to restore the state of a batch if the FactoryTalkBatch Server failed as the batch was running.

5. The FTB> Server downloads the parameters to the phase logic. ThePCD then runs its program to perform a material addition ordistribution.

6. The FEED_COMPLETE and ACTUAL_AMOUNT parameters areuploaded to the FactoryTalk Batch Server.

7. The phase logic transitions to a terminal state.8. The value returned in the FEED_COMPLETE report parameter, and

the Hold on Split Feed configuration determine what recipe executionwill do next:

Tip: Hold On Split Feed is set in the Material Policy tab in the Server Options dialog box in FactoryTalk Batch Equipment Editor.

• If FEED_COMPLETE is TRUE, the batch continues running. • If FEED_COMPLETE is FALSE, and Hold on Split Feed is YES, the

batch is held. • If FEED_COMPLETE is FALSE, and Hold on Split Feed is NO, the

batch continues running.



9. The amount of the material addition or distribution is sent to theMaterial Server. The inventory levels in the material database areupdated, and for material additions, the sublot or sublots of inventoryused are identified.

10. Material, lot, and container data are returned to the FactoryTalk BatchServer and recorded in the FactoryTalk Batch Event Journal.

FEED_COMPLETE HoldOnSplitFeed Explanation TRUE N/A The addition or distribution of the step is complete so the SFC continues

running. FALSE YES The addition or distribution is not complete. The recipe is HELD to

prevent the next step in the SFC from beginning to execute. The step must be rebound to proceed. The operator must perform an active step change away from the unfinished step, rebind the step manually, active step change back and then restart the batch.

FALSE NO The addition or distribution is not complete. In the recipe, the material phase step should have been built within a loop with the transitions testing the value of the FEED_COMPLETE report as well as the value of the step.state attribute. When FALSE, the branch looping around to rerun the phase should be taken.

Uploading data into the material database has two constraints:

• Some fields are only editable at configuration time. Only fields thatmay be changed at runtime will support uploading values.

• Security may limit the set of users allowed to modify the database. TheFactoryTalk Batch Server service must have adequate permissions tostore to the material database.

There are several requests used for downloading/uploading information to the material server through the FactoryTalk Batch Server.

The balance of this chapter should be used as a reference when programming any of the following request types:

• Downloading and uploading data during batch execution 78XX (or178XX)

• Downloading and uploading attributes 8XXX (or 188XX)

The enhanced phase logic requests (available in FactoryTalk Batch version 6.0 and higher) can be used to request alternative action when the material database is not available. The following example shows one possible method for dealing with a phase logic request failure of this type.

1. The phase logic writes a 17801 request to the PHASE_RQ tag, whichrequests a download of data from the material database and asks forthe improved phase logic request error handling.

Upload data constraints

Material server requests

Use the enhanced phase logic requests



2. The FactoryTalk Batch Server detects the 17801 request and attempts toaccess the material database to retrieve the requested data.

3. The material database access fails.4. The FactoryTalk Batch Server writes a 145 (Request Failed) command

to the PHASE_OC tag of the equipment phase. 5. The PLI responds to the 145 command by writing a value of 15 into the

PHASE_RQ tag.6. The FactoryTalk Batch Server detects the request value of 15 and

responds by writing a 170 (Reset for Next Request) command to thePHASE_OC tag of the equipment phase.

7. The PLI responds to the combination of the 170 command and currentrequest tag value of 15 by writing a 1 into the PHASE_RQ tag of theequipment phase.

8. The phase logic sees value of 1 in the PHASE_RQ tag, which indicates afailure, and decides to take the alternative action of requestingdownload of parameter to prompt the operator for equivalent data.

9. The phase logic writes an 11000 series request value into thePHASE_RQ tag requesting the download of a prompt type parameter.

Unable to Communicate with Material Server Phases can normally access the Material Server through PLI requests to upload or download data from the material database. If the access to the material database fails for any reason, including a loss of communication between the FactoryTalk Batch Server and the Material Server, the request from the PLI determines the following action.

In previous versions of FactoryTalk Batch, the standard phase logic request codes (1000-8000 series requests) used error handling logic, which reacted to a failure by holding batches according to configured Hold Propagation settings. The batch could not be restarted until communication was reestablished.

The enhanced phase logic requests are the same as the standard phase logic request codes plus 10,000 (i.e., 11000-18000). These upper range request codes use the improved error handling and must be used by the phase logic to effectively run material recipes without the Material Server.

The 78XX and 178XX requests provide access to certain types of data available or meaningful only during batch execution. These commands are intended to give the phase logic programmer access to the data of the material entities that the phase logic is interacting with.

The attribute ID for a standard attribute is the index. The attribute ID for a custom attribute is the sum of the controller ID and the index.

The following table is a summary of these recipe execution requests:

Requests for data from the recipe execution environment



Series Phase Q01 Phase Q02 Description

7801 (or 17801) Attribute ID Tag # Download data about the container currently in use.

7802 (or 17802) Attribute ID Tag # Download data about the current material inside the container currently in use.

7803 (or 17803) Attribute ID Tag # Download data about the current lot inside the container currently in use. 7811 (or 17811) Attribute ID Tag # Upload data about the container currently in use. 7812 (or 17812) Attribute ID Tag # Upload data about the current material inside the container currently in use. 7813 (or 17813) Attribute ID Tag # Upload data about the current lot inside the container currently in use.

7821 (or 17821) Tag # >0 Download the current binding's container priority. The second request must be a value greater than zero. This value is not currently used by the FactoryTalk Batch Server. It is reserved for future use.

7822 (or 17822) Tag # >0 Upload a new container priority for the current binding. The second request must be a value greater than zero. This value is not currently used by the FactoryTalk Batch Server. It is reserved for future use.

7831 (or 17831)

Tag # >0 Download data about sufficient material for step. The second request must be a value greater than zero. This value is not currently used by the FactoryTalk Batch Server. It is reserved for future use.

The 7801 and 17801 requests download material data from the container the phase is currently running against.


Phase_RQ 7801 (or 17801) Download data about the container currently in use

PhaseQ01 >0 Data field to be downloaded (attribute ID) PhaseQ02 >0 Phase parameter tag number the value is to be downloaded into

Examples: The recipe step is using the optional material-based parameters. These values are:

Parameter Name Parameter Value MATERIALS CAUSTIC AMOUNT 100 CONTAINER DRY_BIN1 LOT ABCDEFG1999 LABEL --

Container Standard Attributes (subset) Attribute Name ID Name Controller ID Description EU

Index 1 2 3 4 5 Value 53672635252 Tank101 25784 Non-Volatile Lbs.

Download data from container currently in use – 7801 request



Container Custom Attributes Property Name ID Name Controller ID Description EU Data Type Value

Index 1 2 3 4 5 6 7 Value1 38728 Number of

Feeds 1000 -- -- 1 (integer) 3

Value2 48774 Clean With 1010 -- -- 1 (integer) 4323

Example 1: Download the Name attribute for the current container into tag 22.

Phase Tags Result

Phase_RQ PhaseQ01 PhaseQ02 PhaseP22 7801 (or 17801) 2 22 Tank101

Example 2: Download the Clean With attribute for the current container value into tag 4. The Clean With attribute has the Controller ID of 1010 and the value field has the index of 7, so the attribute ID is 1017.

Phase Tags Result Phase_RQ PhaseQ01 PhaseQ02 PhaseP04 7801 (or 17801) 1017 4 4323

The 7802 and 17802 requests download material data from the current material within the container the phase is currently running against.

Phase Tags Value/Range Description Phase_RQ 7802 (or 17802) Download data about the current material inside the container currently in use

PhaseQ01 >0 Data field to be downloaded (attribute ID) PhaseQ02 >0 The phase parameter tag number the value is to be downloaded into

Examples: The recipe step is using the optional material parameters, and the current values imply the step’s binding:

Parameter Name Parameter Value

MATERIALS CAUSTIC AMOUNT 100 CONTAINER DRY_BIN1 LOT ABC-123 LABEL --

Material Standard Attributes (subset) Attribute Name ID Name Controller ID Description EU

Attr. Index 1 2 3 4 5 Value 36428736476 Caustic 2003 -- Lbs.

Download data from material in container currently in use – 7802 request



Material Custom Attributes Property Name

ID Name Controller ID

Description EU Data Type Max Min

Index 1 2 3 4 5 6 7 8 Value1 673856 pH-Factor 1000 -- pH 0 (real) 3.5 3.1

Value2 498472 Color 1010 -- -- 2 (string) -- --

Example 1: Download the current material’s Name attribute into tag 1.

Phase Tags Result Phase_RQ PhaseQ01 PhaseQ02 PhaseP01 7802 (or 17802) 2 1 Caustic

Example 2: Download the current material’s pH-Factor attribute’s maximum value into tag 1. The pH-Factor attribute has the controller ID of 1000 and the maximum field has the index of 7, so the attribute ID to access the maximum pH-Factor is 1007.

Phase Tags Result Phase_RQ PhaseQ01 PhaseQ02 PhaseP01 7802 (or 17802) 1007 1 3.5

The 7803 and 17803 requests download lot data from the current material and current lot within the container the phase is currently running against. This request does not download a field that is a list.

Identify the lot The LOT formula parameter does not need to be configured on the phase of the running phase. If the LOT formula parameter is used, it must have the lot name stored in it (either before or after binding occurred). This ensures that the correct lot is referenced. If the lot name is invalid or the material does not exist, the batch is held according to the configured hold propagation setting.

Finding the exact lot from which to get the information is simple for composite and plug-flow containers because only one sublot is accessible at a time. Pallets allow random access to sublots, so that when more than one lot of a material is stored on a pallet, the FactoryTalk Batch Server does not know which lot to retrieve data from unless there is only one lot on the pallet or the LOT formula parameter is specified.


Phase_RQ 7803 (or 17803) Download data about the current material inside the container currently in use

PhaseQ01 >0 Data field to be downloaded (attribute ID)

PhaseQ02 >0 The phase parameter tag number the value is to be downloaded into

Download data from lot in container currently in use – 7803 request



Examples: The recipe step is using the optional material-based parameters:



Lot Standard Attributes (subset) Attribute Name ID Name Controller ID Description EU

Attr. Index 1 2 3 4 5 Value 3772836327 ABC-123 6473 -- lbs.

Lot Custom Attributes Property Name


Description EU Data Type

Max Min Value

Index 1 2 3 4 5 6 7 8 9 Value1 673856 pH-Factor 1000 -- pH 0 (real) 3.5 3.1 3.35

Value2 498472 Color 1010 -- -- 2 (string) -- -- white

Example 1: Download the current binding lot’s EU attribute into tag 2.

Phase Tags Result Phase_RQ PhaseQ01 PhaseQ02 PhaseP02 7803 (or 17803) 5 2 lbs.

Example 2: Download the current binding lot’s pH-Factor attribute’s value into tag 3. The pH-Factor attribute has the attribute ID of 1000 and the value field has the index of 9, so the attribute ID to access the pH-Factor value is 1009.

Phase Tags Result

Phase_RQ PhaseQ01 PhaseQ02 PhaseP03 7803 (or 17803) 1009 3 3.35

The 7811 and 17811 requests upload container data about the container the phase is currently running against. This request fails (without notice) if the data field is read-only.


Phase_RQ 7811 (or 17811) Upload data about the container currently in use.

PhaseQ01 >0 Data field to be uploaded into (attribute ID). PhaseQ02 >0 Report tag address of the value to be stored into the material database.

Upload container data into container currently in use – 7811 request



Examples: The recipe step is using the optional material-based parameters; their values are:



Container Standard Attributes (subset) Attribute Name ID Name Controller ID Description EU

Index 1 2 3 4 5 Value 53672635252 Tank101 25784 Non-Volatile lbs.

Container Custom Attributes Property Name


Description EU Data Type Value


Feeds 1000 -- -- 1 (int) 3

Value2 48774 Clean With 1010 -- -- 1 (int) 4323

Example 1: Upload an updated value (index 4) for the Description attribute from Tag 2.

Phase Tags Data Result Phase_RQ PhaseQ01 PhaseQ02 PhaseR02 Caustic’s Description

7811 (or 17811) 4 2 Volatile Volatile

Example 2: Upload an updated value (index of 7) for the Clean With attribute from Tag 8.

Phase Tags Data Result

Phase_RQ PhaseQ01 PhaseQ02 PhaseR08 Caustic’s Clean With Value 7811 (or 17811) 1017 8 4323 4323

The 7812 and 17812 requests upload material data about the current material inside the container the phase is currently running against. This request fails (without notice) if the data field is read-only.

Phase Tags Value/Range Description Phase_RQ 7812 (or 17812) Upload data about the current material inside the container currently in use.

PhaseQ01 >0 Data field to be uploaded into

PhaseQ02 >0 Report tag address of the value to be stored into the material database

Upload material data into material in container currently in use – 7812 request



Examples: Material Classifications: 4 = Waste, 1 = Raw, 2 = Intermediate, 3 = Finished

Material Standard Attributes (subset) Attribute Name ID Name Controller ID Classification

Index 1 2 3 9 Value 36428736476 Caustic 2003 1 (Raw)


ID Name Controller ID Description EU Data Type

Max Min

Index 1 2 3 4 5 6 7 8 Value1 673856 pH-Factor 1000 -- pH 0 (real) 3.5 3.1

Value2 498472 Color 1010 -- -- 2 (string) -- --

Example 1: Upload an updated classification for the material from Tag 1.

Phase_RQ Data Result

Phase Tags PhaseQ01 PhaseQ02 PhaseR01 Caustic Classification 7812 (or 17812) 9 1 4 4(waste)

Example 2: Upload a new maximum pH-Factor attribute for this material from Tag 3. The custom pH-Factor attribute has an ID of 1000 and the maximum field has the index of 7, so the attribute ID to access the maximum pH-Factor attribute is 1008.

Phase Tags Data Result Phase_RQ PhaseQ01 PhaseQ02 PhaseR03 pH-Factor Min 7812 (or 17812) 1008 3 3.66 3.5

Although syntactically correct, this request fails because the maximum value of a custom attribute is read-only, so it may only be changed at configuration time and not at runtime.

The 7813 and 17813 requests upload lot data into the current lot of the current material inside the container the phase is currently running against. This request fails if the data field is read-only.

The LOT formula parameter does not need to be configured on the phase of the running phase. If the LOT formula parameter is used, it must have the lot name stored in it (either before or after binding occurred). This ensures that the correct lot is referenced. If the lot name is invalid or the material does not exist, the batch is held according to the configured hold propagation setting.

Upload lot data into lot in container currently in use – 7813 request

Identify the lot



Finding the exact lot from which to get the information is simple for composite and plug-flow containers because only one sublot is accessible at a time. Pallets allow random access to sublots, so that when more than one lot of a material is stored on a pallet, the FactoryTalk Batch Server does not know which lot to retrieve data from unless there is only one lot on the pallet or the LOT formula parameter is specified.


Phase_RQ 7813 (or 17813) Upload data about the current lot inside the container currently in use.

PhaseQ01 >0 Data field to be uploaded into (attribute ID). PhaseQ02 >0 Report tag address of value to be stored into the material database

Examples: Lot State Enumeration: 2 = Waiting to Test, 3 = In Test, 1 = Ready to Use

Lot Standard Attributes (subset) Attribute Name ID Name Controller ID State

Index 1 2 3 11 Value 36428736476 Caustic 2003 2 (Waiting to Test)

IMPORTANT In FactoryTalk Batch 5.0 Service Pack 1, the 7813 request, which changes the lot state, used the PKID. However, in later versions of FactoryTalk Batch (5.02 or higher), the 7813 (and 17813) requests use the Controller ID instead.



Max Min Value

Index 1 2 3 4 5 6 7 8 9 Value1 673856 pH-Factor 1000 -- pH 0 (real) 3.5 3.1 3.35 Value2 498472 Color 1010 -- -- 2 (string) -- -- white

Example 1: Upload an updated state value (index 11) for the Lot from Tag 13.

Phase Tags Data Result Phase_RQ PhaseQ01 PhaseQ02 PhaseR13 Caustic.State 7813 (or 17813) 11 13 3 3

Example 2: Upload a new value for the color for this lot from Tag 33. The color custom attribute has a controller ID of 1010 and the Value field has an index of 9; the attribute ID to access the color value is 1019.

Phase Tags Data Result Phase_RQ PhaseQ01 PhaseQ02 PhaseR33 Caustic. Color.Value 7813 (or 17813) 1019 33 Green Green



The 7821 and 17821 requests download the container selection priority for the material, container, feed type and unit currently in use by this phase.

The value is stored into a specified tag.


Phase_RQ 7821 (or 17821) Download the current binding’s container selection priority.

PhaseQ01 NN Phase parameter tag number PhaseQ02 >0 Any value greater than zero. This value is not currently used by the FactoryTalk Batch

Server. Reserved for future use. The example uses a value of 999 to indicate a request data tag that is expected by the server but not used.

Example: The container, Tank101, is currently in use and has a selection priority of 100 to be downloaded into Tag 2:

Phase Tags Result Phase_RQ PhaseQ01 PhaseQ02 PhaseP02 7821 (or 17821) 2 999 100

Download the current binding’s container selection priority – 7821 request



The 7822 and 17822 requests upload a new container selection priority for the material, container, feed type, and unit currently in use by this phase.

Phase Tags Value/Range Description Phase_RQ 7822 (or 17822) Upload a new selection priority for the container currently in use.

PhaseQ01 >0 Report tag address of priority to be assigned. PhaseQ02 >0 Any value greater than zero. This value is not currently used by the FactoryTalk Batch

Server. Reserved for future use. The example uses a value of 999 to indicate a request data tag that is expected by the server but not used.

Example: The container, Tank101, has a new selection priority of 95 in Tag 8 to be uploaded:

Phase Tags Data Result Phase_RQ PhaseQ01 PhaseQ02 PhaseR08 Selection Priority 7822 (or 17822) 8 999 95 95

The 7831and 17831 requests download information regarding the availability of sufficient material, across all the valid binding candidates, to complete the addition before starting the material addition for the step.

Phase Tags Value/Range Description Phase_RQ 7831 (or 17831) Download data about sufficient material for step:

• 0 - Insufficient material was available across the valid binding candidates at the time the binding query was performed.

• 1 - Sufficient material was available across the valid binding candidates at the time the binding query was performed.

PhaseQ01 >0 Phase parameter tag address of priority to be assigned.

PhaseQ02 >0 Any value greater than zero. This value is not currently used by the FactoryTalk Batch Server. Reserved for future use. The example uses a value of 999 to indicate a request data tag that is expected by the server but not used.

Tip: The FactoryTalk Batch Server will also, when running without the Material Server, return a ‘0’ or ‘1’ depending on when communication is lost.

Upload a container selection priority for the current binding – 7822 request

Download sufficient material data – 7831 request



Example: The step requires 500 gallons of Material B, there is 1250 available across all the valid binding candidates.

Phase Tags Result

Phase_RQ PhaseQ01 PhaseQ02 PhaseP10

7831 (or 17831) 10 999 1

The 8XXX (and 18XXX) request series provide access to the material data within the material database. These requests provide a means for accessing or storing a value to or from the material database. This provides the greatest flexibility for customization of phase logic and use of the database.

Tip: All 8XXX series requests are available with the enhanced phase logic by using the upper range request codes (18XXX).

The following is a summary of the material database requests:

Series Description Functionality Supported

80NN (or 180NN)

Download Material Attributes single attribute, single value downloaded

81NN (or 181NN)

Download Lot Attributes single attribute, single value downloaded

83NN (or 183NN)

Download Container Attributes single attribute, single value downloaded

84NN (or 184NN)

Downloading Container Priority Assignments single attribute, single value downloaded

85NN (or 185NN)

Uploading Material Attributes single attribute, single value uploaded

86NN (or 186NN)

Uploading Lot Attributes single attribute, single value uploaded

88NN (or 188NN)

Uploading Container Attributes single attribute, single value uploaded

89NN (or 189NN)

Uploading Container Priority Assignments single attribute, single value uploaded

The 80NN and 180NN commands download one attribute of a material to a specified tag. The attribute identified by the attribute ID is downloaded into the tag specified.


Phase_RQ 80NN (or 180NN) Download Material Data to phase parameter tag number NN

PhaseQ01 >0 Material Controller ID

PhaseQ02 >0 Attribute ID PhaseQ03 >0 Any value greater than zero. This value is not currently used by the FactoryTalk

Batch Server. Reserved for future use. The examples use a value of 999 to indicate a request data tag that is expected by the server but not used.

Requests for data from the material database

Download one attribute of a material - 80NN request series



Examples: The material Caustic has the following standard attributes and custom attributes:

Material Standard Attributes Attribute Name Index Value

ID 1 36428736476

Name 2 Caustic Controller ID 3 2003 Description 4 -- EU 5 lbs.



Max. Min.

Index 1 2 3 4 5 6 7 8

Value1 673856 pH-Factor 1000 -- pH 0 (real) 3.5 3.1 Value2 498472 Color 1010 -- -- 2 (string) -- --

Example 1: Download the materials Name attribute into Tag 1.

Phase Tags Result Phase_RQ PhaseQ01 PhaseQ02 PhaseQ03 PhaseP01

8001 (or 18001) 2003 2 999 Caustic

Example 2: Download the material’s pH-Factor attribute’s minimum value into Tag 1. The pH-Factor custom attribute has the controller ID of 1000 and the minimum field has the index of 8, so the attribute ID to access the minimum pH-Factor is 1008.

Phase Tags Result

Phase_RQ PhaseQ01 PhaseQ02 PhaseQ03 PhaseP01

8001 (or 18001) 2003 1008 999 3.1

The 81NN and 181NN commands download one attribute of a lot to a specified tag. The attribute identified by the attribute ID is downloaded into the tag specified. Only one value may be downloaded at a time.


Phase_RQ 81NN (or 181NN) Download Material Lot Data to phase parameter tag number NN

PhaseQ01 >0 Lot’s Controller ID

PhaseQ02 >0 Attribute ID

Download lot attributes – 81NN request series




PhaseQ03 >0 Any value greater than zero. This value is not currently used by the FactoryTalk Batch Server. Reserved for future use. The examples use a value of 999 to indicate a request data tag that is expected by the server but not used.

Examples: For the material Caustic, there exists a lot named ABC-123 that has the following standard attributes and custom attributes:

Lot Standard Attributes Attribute Name Index Value

ID 1 3772836327 Name 2 ABC-123 Controller ID 3 6473 Description 4 -- EU 5 lbs.


ID Name Controller ID Description EU Data Type Max. Min. Value

Index 1 2 3 4 5 6 7 8 9

Value1 67385 pH-Factor 1000 -- pH 0 (real) 3.5 3.1 3.35

Value2 49847 Color 1010 -- -- 2 (string) -- -- white

Example 1: Download the lot’s EU attribute into tag 2.

Phase Tags Result

Phase_RQ PhaseQ01 PhaseQ02 PhaseQ03 PhaseP02 8102 (or 18102) 6473 5 999 lbs.

Example 2: Download the lot’s pH-Factor attribute’s value into tag 3. The pH-Factor custom attribute has the property ID of 1000 and the value field has the index of 9, so the attribute ID to access the pH-Factor value is 1009.

Phase Tags Result Phase_RQ PhaseQ01 PhaseQ02 PhaseQ03 PhaseP03 8103 (or 18103) 6473 1009 999 3.35

The 83NN and 183NN commands download one attribute of a container to a specified tag. The attribute identified by the attribute ID is downloaded into the tag specified. Only one value may be downloaded at a time.


Download container attributes – 83NN request series




Phase_RQ 83NN (or 183NN) Download Container Data to phase parameter tag number NN

PhaseQ01 >0 Container’s Controller ID

PhaseQ02 >0 Attribute ID PhaseQ03 >0 Any value greater than zero. This value is not currently used by the FactoryTalk


Examples: There is a container, Tank101 that has the following standard attributes and custom attributes:

Container Standard Attributes Attribute Name Index Value

ID 1 53672635252

Name 2 Tank101 Controller ID 3 25784 Description 4 Vessel for storing non-volatile materials EU 5 lbs.


ID Name Controller ID Description EU Data Type Value


Feeds 1000 -- -- 1 (integer) 3

Value2 48774 Clean With 1010 -- -- 1 (integer) 4323

Example 1: Download the container’s Name attribute into tag 22.

Phase Tags Result Phase_RQ PhaseQ01 PhaseQ02 PhaseQ03 PhaseP22 8322 (or 18322) 25784 2 999 Tank101

Example 2: Download the value field of the container’s Clean With attribute into tag 4. The Clean With custom attribute has the controller ID of 1010 and the value field has the index of 7, so the attribute ID to access the Clean With value is 1017. This value is the Controller ID for the material to be used to clean this vessel, STANDARD DETERGENT, after the container is empty.

Phase Tags Result Phase_RQ PhaseQ01 PhaseQ02 PhaseQ03 PhaseP04 8304 (or 18304) 25784 1017 999 4323



The 84NN and 184NN commands download the selection priority of a container and load that value to a specified tag. A container's selection priority is assigned given a material, container, feed type and unit. The first three parameters are defined by values in the request registers. The unit is always restricted to the unit the phase is currently running in. Only one value may be downloaded at a time.


Phase_RQ 84NN or 184NN Download the container’s priority to phase parameter tag number NN. Tag data type = Integer

PhaseQ01 >0 Material’s controller ID PhaseQ02 >0 Container’s controller ID PhaseQ03 Positive or negative

number Feed type: • 1 = Addition. • 2 = Distribution.

Examples:

The operation recipe is running in unit MIXER_1. All 84NN (and 184NN) requests are for materials and containers within this unit.

Example 1: Download the selection priority for adding CREAM to TANK_65 into tag 2.

• Controller ID for CREAM = 10001 in PhaseQ01 • Controller ID for TANK_65 = 20065 in PhaseQ02• Feed type is an addition so 1 must be in PhaseQ03.• The selection priority for adding Cream to Tank_65 running in

MIXER_1 is 100.Phase Tags Result


8402 (or 18402) 10001 20065 1 100

Example 2: Download the selection priority for distributing SUGAR from STAGING\PALLET_122 into tag 1.

• Controller ID for SUGAR = 10110 in PhaseQ01 • Controller ID for STAGING\PALLET_122 = 20222 in PhaseQ02• Feed type is a distribution, so 2 must be in PhaseQ03.• The selection priority for distributing sugar to Staging\Pallet_122

running in MIXER_1 is 80.Phase Tags Result


8402 (or 18402) 10110 20222 2 80

The 85NN and 185NN commands upload one attribute of a material from a specified tag. The attribute identified by the attribute ID is uploaded from the specified tag into the database if security and write-protections allow. Only one value may be uploaded at a time.

Download container priority assignments – 84NN request series

Upload material attributes – 85NN request series




Phase_RQ 85NN or 185NN Upload Material Data from report parameter tag number NN

PhaseQ01 >0 Material’s Controller ID PhaseQ02 >0 Attribute ID PhaseQ03 >0 Any value greater than zero. This value is not currently used by the FactoryTalk



Material Standard Attributes Attribute Name Index Value

ID 1 36428736476 Name 2 Caustic Controller ID 3 2003 Description 4 -- EU 5 lbs. Classification 10 0 (raw)


ID Name Controller ID Description EU Data Type Max. Min.

Property Index 1 2 3 4 5 6 7 8

Value1 673856 pH-Factor 1000 -- pH 0 (real) 3.5 3.1 Value2 498472 Color 1010 -- -- 2 (string) -- --

Example 1: Upload an updated classification for the material from Tag 1.


Phase_RQ PhaseQ01 PhaseQ02 PhaseQ03 PhaseR01 Caustic Classification

8501 (or 18501) 2003 10 999 4 4 (waste)

Example 2: Upload a new maximum pH-Factor for this material from Tag 3. The pH-Factor custom attribute has a controller ID of 1000 and the maximum field has the index of 7, so the attribute ID to access the maximum pH-Factor is 1007.


Phase_RQ PhaseQ01 PhaseQ02 PhaseQ03 PhaseR03 Caustic Classification




8503 (or 18503) 2003 1007 999 3.66 3.5 Although syntactically correct, this request fails because the maximum value of a custom attribute is read-only, so it may only be changed at configuration time and not at runtime.

The 86NN and 186NN commands upload one attribute of a lot from a specified tag. The attribute identified by the attribute ID is uploaded from the specified tag into the database if security and write-protections allow. Only one value may be uploaded at a time.


Phase_RQ 86NN or 186NN Upload Lot Data from report parameter tag number NN PhaseQ01 >0 Lot’s Controller ID PhaseQ02 >0 Attribute ID PhaseQ03 >0 Any value greater than zero. This value is not currently used by the FactoryTalk



Lot Standard Attributes Attribute Name Index Value

ID 1 36428736476 Name 2 Caustic Controller ID 3 2003 Description 4 -- EU 5 lbs. State 11 0 (raw)


ID Name Controller ID Description EU Data Type Max. Min. Value

Property Index 1 2 3 4 5 6 7 8 9 Value1 673856 pH-Factor 1000 -- pH 0 (real) 3.5 3.1 3.35 Value2 498472 Color 1010 -- -- 2 (string) -- -- white

Example 1: Upload an updated state value (index 11) for the Lot from tag 13.

Upload lot attributes – 86NN request series




Phase_RQ PhaseQ01 PhaseQ02 PhaseQ03 PhaseR13 Caustic.State

8613 (or 18613) 2003 11 999 3 3

Example 2: Upload a new value for the Color for this lot from tag 33. The Color custom attribute has a controller ID of 1010 and the Value index of index of 9, so the attribute ID to access the Color value is 1019.


Phase_RQ PhaseQ01 PhaseQ02 PhaseQ03 PhaseR33 Caustic. Color.Value

8633 (or 18633) 2003 1019 999 Green Green

The 88NN and 188NN commands upload one attribute of a container from a specified tag. The attribute identified by the attribute ID is uploaded from the specified tag into the database if security and write-protections allow. Only one value may be uploaded at a time.


Phase_RQ 88NN or 188NN Upload Container Data from report parameter tag number NN

PhaseQ01 >0 Container’s Controller ID PhaseQ02 >0 Attribute ID PhaseQ03 >0 Any value greater than zero. This value is not currently used by the FactoryTalk


Examples: The container Tank101 has the following standard attributes and custom attributes:

Container Standard Attributes Attribute Name Index Value

ID 1 53672635252 Name 2 Tank101 Controller ID 3 25784 Description 4 Vessel for storing non-volatile materials EU 5 lbs.



Upload container attributes – 88NN request series



Property Name


Index 1 2 3 4 5 6 7

Value1 38728 Number of Feeds 1000 -- -- 1 (int) 3

Value2 48774 Clean With 1010 -- -- 1 (int) 4209

Example 1: Upload an updated value (index of 7) for the "Clean With" custom attribute from Tag 8.

Phase Tags Data Result Phase_RQ PhaseQ01 PhaseQ02 PhaseQ03 PhaseR08 Caustic.Clean With.

Value

8808 (or 18808) 25784 1017 999 4328 4328

The 89NN and 189NN commands upload a Selection Priority for a container from a specified tag. A container’s selection priority is assigned given a material, container, feed type and unit. The first three parameters are defined by values in the request registers. The unit is always restricted to the unit the phase is currently running in. Only one value may be uploaded at a time.


Phase_RQ 89NN or 189NN Upload the container’s priority from report parameter tag number NN. Tag data type = Integer

PhaseQ01 >0 Material’s Controller ID PhaseQ02 >0 Container’s Controller ID PhaseQ03 Positive or negative

number Feed Type: 1 = Addition 2 = Distribution

Examples: The Operation Recipe is running in unit MIXER_1. All 89NN (and 189NN) requests will be for materials and containers within this unit.

Example 1: Upload the new selection priority of 95 for adding CREAM to TANK_65 from Tag 2.

• Controller ID for CREAM = 10001 in PhaseQ01 • Controller ID for TANK_65 = 20065 in PhaseQ02• Feed Type is an Addition so 1 must be in PhaseQ03.• The Selection Priority for adding Cream to Tank_65 running in

MIXER_1 is 95.Phase Tags Data Result

Phase_RQ PhaseQ01 PhaseQ02 PhaseQ03 PhaseR02 Selection Priority

8902 (or 18902) 10001 20065 1 95 95

Upload container priority assignments – 89NN request series



Example 2: Upload the new selection priority 70 for distributing SUGAR to STAGING\PALLET_122 into tag 1

• Controller ID for SUGAR = 10110 in PhaseQ01 • Controller ID for STAGING\PALLET_122 = 20222 in PhaseQ02• Feed Type is a Distribution, so 2 must be in PhaseQ03.• The Selection Priority for distributing sugar to Staging\Pallet_122

running in MIXER_1 is 70.Phase Tags Data Result

Phase_RQ PhaseQ01 PhaseQ02 PhaseQ03 PhaseR01 Selection Priority

8901 (or 18901) 10110 20222 2 70 70


Chapter 8

Modularize the process

The most critical step of the entire automation project is the modularization of the process. According to S88.01:

"All control related sections of the standard assume that the process cell in question (both physical equipment and related control activities) has been subdivided into well-defined equipment entities such as units, phases and control modules. Effective subdivision of the process cell into well-defined equipment entities is a complex activity, highly dependent on the individual requirements of the specific environment in which the batch process exists. Inconsistent or inappropriate equipment subdivisions can compromise the effectiveness of the modular approach to recipes suggested by this standard.

Subdivision of the process cell requires a clear understanding of the purpose of the process cell’s equipment. Such understanding allows the identification of equipment entities that must work together to serve an identifiable processing purpose."

Here we discuss the physical partitioning of the process into process cell, units, phases and control modules. This partitioning should be performed in a top down manner. That is, the process should first be identified. Once its boundaries are identified, the units within the process cell are identified. Once they are identified, the phases within the units within the process cell are identified. Finally, all control modules within all other levels are identified.

Modularization Steps

About process modules

Chapter 8 Modularize the process


A unit is comprised of phases and control modules. Some of these modules are permanently engineered to be a part of the unit and some can be acquired as needed. Units should be able to operate relatively independently of each other. A unit can temporarily acquire the services of another phase or control module to carry out specific tasks. A unit typically contains or holds the batch and causes some change to occur. By definition, a unit cannot make two products (execute two batches) at the same time. A unit is capable of executing procedural control to make product.

A phase is comprised of other phases and control modules. As with a unit, a phase can acquire the services of another phase or control module temporarily to carry out specific tasks. Since a phase can be a shared resource, it can be designed to operate on more than one batch at a time (i.e. vacuum system). A phase is capable of executing procedural control (phases). The primary difference between a unit and a phase is that a phase is typically called on by a unit to perform a specific task as opposed to acting on a batch independently.

A control module (CM) is comprised of other CMs and devices. Since a CM can be a shared resource, it can be designed to operate on more than one batch at a time (i.e. header valve). A CM cannot execute procedural control, it is only called upon by procedural control to perform a specific action.

When defining units, decide on a tag naming convention. If units are grouped as a class, define a scheme that will consistently name devices. If dissimilarities between a unit and other members of its class are severe, consider moving the unit to its own class. This process will help in automatic tag generation by control systems. An example is level transmitters named by appending an "_LV" suffix to their associated unit name.

A resource is an entity (either EM or CM) that can provide services to a unit. In the previous section on process models, we described resources as either exclusive or shared resources. An example of an exclusive use resource is an analyzer. If another reactor wants to use the services of the analyzer, it must wait for the first reactor to release it.

A shared resource can provide services to several units at the same time. An example of a shared use resource is a vacuum system. However, if the capability of the shared resource is limited, then arbitration of the resource becomes critical.

Unit

Phase

Control module

Define tags

Define resources



Here are the criteria that can be used to determine the boundaries between modules:

• Purpose • Independence • Use • Expansion • Portability • Isolation • Flexibility • Physical Process Constraints

What is the intended purpose of the module? All of the elements of the module (inside the boundary) should have a similar purpose. A module should operate somewhat as a self-contained system. For example, the purpose of a vacuum system is to maintain a constant vacuum pressure on the inlet, and pull vacuum on upstream customers. The purpose of a solvent recovery system is to condense solvent from a process stream and collect the solvent. The solvent recovery system may use the vacuum system to pull the solvent from a tank, but the purpose of the vacuum system is different from the purpose of the solvent recovery system. The vacuum system may be used independently of the solvent recovery system, therefore they should be separate modules.

Use refers to how the module interacts with other modules. For example, whether the module is acquired by another module (unit or phase), operates independently, or, if acquired by another module, more than one module can acquire it at a time.

Any module that can be acquired by more than one module must be outside of the boundaries of both modules that can acquire it. For example, if a block valve control module can be acquired and used by two different reactor units, then the CM must be outside of the boundary of either unit.

Portability refers to the ability of a module to be duplicated or moved to another process or location.

If this module will be duplicated in another process cell, or be moved into another controller in the future, then the boundary of the module needs to be appropriate so that it is self-contained and can be moved.

If there is a grouping of equipment that will increase or decrease the flexibility of the process, then the modules need to be defined so as not to limit the flexibility of the overall process.

Modularization criteria

Purpose

Use

Portability

Flexibility



Independence refers to the ability of the module to operate on its own to the greatest extent possible. Sometimes that requires adding a recycle or reflux capability to the module. Independence is not always required, but it allows the process to operate much more smoothly.

Expansion refers to the ability to add capacity to the process by adding new modules. If there is a portion of the process that can or will be a bottleneck, then it is usually a good idea to draw the module boundaries so that new capacity could be added by duplicating the module.

Isolation refers to the ability to minimize the effect of process upsets by containing them within the module where the upset occurs. This goes hand in hand with independence.

A physical process constraint is any equipment limitation that may force modularization to occur in a certain manner. For example, if two tanks share a common pump, then the pump must be defined outside the boundary of either of the tank modules. The tank module then acquires the pump when it is needed.

A phase is capable of performing an independent process-oriented action called a phase. There may be one or more control steps within a phase that may be executed sequentially or concurrently. You will need to identify the phases in the process that need to be programmed to interact with FactoryTalk Batch. By looking at the Process and Instrumentation Diagram (P&ID) drawings and reviewing a copy of the plant’s process description, you should be able to identify the individual phases that exist in the process. P&ID drawings show all of the equipment and flow paths between equipment. The process description defines how the process operates.

After all phases have been identified, calculate the memory and processing requirements of the phases. The following is an example process with all phases identified within one of the units.

Independence

Expansion

Isolation

Physical process constraints

Identify the phases in the selected process



The following diagram is an example of a P&ID drawing that may be used to identify the phases that exist in the process cell:

P & ID drawing example



This figure shows the four phases associated with Unit #2.

The following describes each of these four phases:

Phase Class Phase Description

ADD Charge B Charge material B into Unit #2 ADD Charge C Charge material C into Unit #2 MIX Agitate Agitate material in Unit #2 DISCHARGE Transfer Out Transfer material out of Unit #2 into Reactor Unit #3. (The Transfer Out phase must be

coordinated with a Transfer In phase in the reactor unit.)

Unit #2 phases


Chapter 9

Program phase logic

Phase logic is programmed to enable equipment to respond to and interact with the FactoryTalk Batch automation software. This chapter describes the steps necessary to program phase logic that will interact with the FactoryTalk Batch Server. Some of the sections are purposely written in a general context since the specific phase logic programming requirements depend upon the selected plant’s process controller. For information regarding the process controller’s programming requirements, refer to the manufacturer’s supporting literature.

Any programming language may be used to program a phase for interaction with the FactoryTalk Batch Server. Generally, use the programming language that the process controller supports. However, the process controller must be able to communicate with the hardware platform on which the server is running. Once the phase logic has been programmed, configure the corresponding phases using FactoryTalk Batch Equipment Editor.

Programming phase logic is a multiple-step process. The steps necessary to program phase logic are listed below. It is recommended that these steps be performed in the following order:

1. Modularize the process.2. Identify the phases in the selected process.3. Build the phases and control modules (device drivers).4. Design the phase logic. 5. Program the phase logic. 6. Test the phase logic.

Phase memory tags store values for the 15 unique data items that the FactoryTalk Batch Server and phase use for communication purposes. Allocate phase memory tags for each phase. When allocating phase memory tags, a name and possibly a memory location must be designated for each of the following data items:

• Batch Requests • External Requests • Phase Parameter Values

• Batch Commands • External Commands • Unit • Status • Failure • Request • Request Data • Paused • Pause • Owner • Phase Report Values • Single Step

This tag is set when the SEMI_AUTO command is sent to the phase.

Allocate phase memory tags

Chapter 9 Program phase logic


• Before allocating the phase memory tags, have a good understandingof the process controller and the physical devices in the selected plant.

• Identify the phases in the process.• Calculate the memory and processing requirements for the identified

phases.• Build the phases and control modules needed for the process.• When finished, program the state transition logic.

Tip: When using control strategies in an area model, allocate one tag for each phase parameter and each phase report to be used, as well as one tag for the control strategy parameter. This is true even if each control strategy for the phase use only a portion of the total number of parameters and reports. In addition, Parameter1 and Control Strategy must always download to Tag1.

The following lists the steps necessary to allocate phase memory tags:

1. Identify the phase memory tags, including the number of arrayelements for the phase report values, phase parameter values, andrequest data values.

2. Assign the memory location and associate a symbol or a tag name toeach memory location depending on the type of process controllerbeing used.

PLC DCS Select the memory location. Assign a tag name or symbol to the phase memory tag.

Associate a tag name or symbol to the memory location.

Depending upon the DCS, you may also assign a memory location.

The following shows the 15 phase memory tags that may be allocated for each phase, and the recommended naming convention. The tags marked with Req are required by the FactoryTalk Batch Server. The phase memory tag name may begin with the phase name followed by an underscore character then a two or three character extension, as shown in the following table:

Phase Memory Tag Recommended Naming Convention Batch Command Req [PHASE NAME]_OC External Command [PHASE NAME]_EC Batch Request [PHASE NAME]_OR External Request [PHASE NAME]_ER Parameter Values [PHASE NAME]PNN,

where NN is a number. You may allocate an array or several memory tags for the phase parameter values.

Unit Req [PHASE NAME]_UN

Status Req [PHASE NAME]_ST Step Index Req [PHASE NAME]_SI Failure Req [PHASE NAME]_F Request Req [PHASE NAME]_RQ Request Data Values [PHASE NAME]QNN,

where NN is a number. You may allocate an array or several memory tags for the request data values.

Pause Req [PHASE NAME]_P

Steps to allocate phase memory tags

Phase memory tags



Phase Memory Tag Recommended Naming Convention Paused Req [PHASE NAME]_PD Owner Req [PHASE NAME]_W Report Values [PHASE NAME]RNN,

where NN is a number. You may allocate an array or several memory tags for the phase report values.

Single Step Req * [PHASE NAME]_SS

* This tag is set when the SEMI_AUTO command is sent to the phase.

Phase logic programming should be based on a clearly defined set of templates. The actual work to be performed during execution of the phase logic is then plugged into the template for each individual phase. There are three common forms of phase logic programming: SFC, Structured Text, and Ladder Logic. This document focuses on SFC and Structured Text programming (see illustration below for examples of an SFC).

State Machine Programming

When programming phase logic using SFCs, there are two common programming paradigms: Sequential and state machine. There are advantages and disadvantages of each.

Sequential phase logic programming is more intuitive and easier to troubleshoot. The SFC shows the order of step execution and most control systems will show what step is active. They are, on the other hand, more difficult to change. They also have problems with recovery from an exception. Whenever an SFC is started, it must start at the first step and progress only through connected steps and transitions. If, after an exception, you would like to restart at a step other than 1, you must create a transition from the starting point to each and every step in the SFC (see figure below). Also, in order to change the order of steps, the SFC must be redrawn.

S3

S2

S4

S1

S1 S3S2 S4

Sequential State Machine

Step=1

Step=2

Step=3

Step=4

complete

complete Step=1

Step=2

Step=3

Step=4

Step<>1

Step<>2

Step<>3

Step<>4

WHILE (not complete) DOIf Step=1 THEN

S1ELSE_IF Step=2 THEN



S4END_IF

END_WHILE

Structured Text

Parallel vs. sequential programming for phase logic



Phase Recovery

State machine-based programming can be implemented in either SFC or Structured Text. With this implementation, the phase logic can move from any step to any step, based on transitions. This allows new steps to be added and steps to be re-sequenced very easily. It also allows recovery from an exception without any changes. One drawback though, is that this form of programming is less intuitive. It does not show the sequential nature of the steps.

Semi-Auto phase processing is a powerful mechanism that can be implemented to aid in troubleshooting and commissioning. When a phase is in the Semi-Auto mode, the phase logic will halt at pre-programmed breakpoints. When a Resume command is received, the phase logic will resume processing until it reaches the next breakpoint where it will wait for another Resume command. This can allow someone to verify the control actions taken by each step within the phase logic.

Semi-Auto was formerly referred to as Single-Step. In an effort to become more consistent with the S88.01 standard, the term was changed to Semi-Auto.

IMPORTANT If a phase somehow ends up in a Semi-Auto mode during normal processing, it could cause serious problems. Care should be taken to never allow a phase to get into a Semi-Auto mode except during troubleshooting and checkouts. This can be accomplished through a security feature or by disabling the Semi-Auto functionality.

Tip: It is important to note that Semi-Auto phase logic processing works differently than Semi-Auto processing of operations, unit procedures, and procedure levels. Semi-Auto phase logic processing requires pre-programmed breakpoints in the phase logic. Semi-Auto processing of operations, unit procedures, and procedures does not require these pre-programmed breakpoints.

An example of the code that could be used to implement a breakpoint is:

S3

S2

S3

S1

Step=1

Step=3

Step=2

Step=4

Step=2

Step=3

Step=4

Complete

Semi-Auto



IF PHASE_P THEN

PHASE_PD:= TRUE;

END_IF;

The Paused flag is then used to disable the processing of the phase logic.

Pause is a mechanism that allows the operator to halt execution of phase logic at a pre-programmed breakpoint. The programmer must place the breakpoints in the code at safe points within the processing. When a phase has the Pause attribute set, the phase will pause at the next pre-programmed breakpoint. The next step is not processed until the operator issues a Resume command. Once a Resume command is received, the phase logic continues normal execution.

Tip: Pause and Semi-Auto work in a similar manner. Each will force the phase logic to pause at the next pre-programmed breakpoint until a Resume command is received. When a Resume command is received by Paused phase logic, it will continue normal execution. However, when a Resume command is received by a phase in Semi-Auto, it will continue to execute until it reaches the next pre-programmed breakpoint.

Phase logic should always treat phases and control modules as objects, but should never act directly on an output. It should send a message to a control module requesting it to take an action.

For example, when a phase wants to start a pump, it should send a start message to the pump control module (see illustration below). The pump control module would then take the appropriate actions to start the pump and verify the status of the motor. The phase logic would then verify that the pump is running by looking at the pump control module’s status attribute rather than looking directly at the pump motor status input. In this way, the control module can take all other things that affect the pump into account before setting the status.

Pause

Treat modules as objects



Phase logic to CM Communication

The project-specific phase logic contains modules of code that implement the operating sequences, plus a failure-detection module for each. The various modules are:

• RUNNING• STOPPING• ABORTING• HOLDING• RESTARTING• FAILURE-DETECTION

Tags that are set by the state transition logic in the PLI initiate these modules of code. When these modules of code terminate, they set a tag that indicates completion and which is read by the state transition logic in the PLI, allowing it to transition to the next state.

PumpDevice

PumpControl Module

Phase 1 Phase 2 Phase 3

MessageStatus Message Status Message

Status

MotorStatusStarter

Modules of code



Modules of Code in Phase Logic

The project-specific phase logic must adhere to the state transition diagram.

Tip: When designing your project-specific phase logic, you should take the following into consideration: You do need to program breakpoints within the logic if you want to take advantage of the Semi-Auto functionality. These should not be used if you need your phase logic to stop in a safe state.

The following defines the six types of project-specific phase logic, and the status value that causes the logic to execute. Boolean variable processing is simpler and more efficient in some process-connected devices. In those cases, the PLI can send Boolean values to the phase logic rather than the phase logic using the Status (_ST) tag to determine what to do. In this case, you may choose to implement the Suggested Tag Name. PHASE represents a unique character identifier for the phase. The information in this table is used in later examples.

Logic Description Batch Status Value

Suggested Tag Name

RUNNING Normal operating sequence of a phase. PHASE_ST=50 PHASE_R

Obey the state transition diagram

Project-specific phase logic



Logic Description Batch Status Value

Suggested Tag Name

HOLDING Temporarily suspends the operation of a phase. The phase logic transitions to the HELD state. For example, if a valve malfunctions, you may want to hold the operation of a phase while the valve is being repaired. After repairs are complete, issue a RESTART command to begin the RESTARTING logic and transition the phase logic to the RUNNING state.

PHASE_ST=20 PHASE_H

ABORTING Abnormal termination of the phase logic sequence of operation. The aborting logic is typically reserved for termination of the operation of phase logic when an unsafe condition develops. For example, if a pump begins pumping an ingredient onto the plant floor, issue an ABORT command to transition the phase logic through the ABORTING state to the ABORTED state and abruptly terminate the execution of the phase logic. An ABORT command does not normally interrupt to upload parameters.

PHASE_ST=10 PHASE_A

STOPPING Termination of the operation of the phase logic before normal transition to the COMPLETE state. For example, an operator may decide to transfer 150 gallons of an ingredient to a mixer, but the running recipe allows 200 gallons of an ingredient to fill a mixer. The operator may enter a STOP command to terminate the operation of the phase logic before the recipe amount of 200 gallons is transferred to the mixer.

PHASE_ST=30 PHASE_S

RESTARTING Begins the operation of the phase logic from the HELD state.

PHASE_ST=40 PHASE_T

FAILURE DETECTION

Detects abnormal events within the phase. PHASE_ST=60* PHASE_F

* If Hold Propagation is set to None, the status will remain unchanged fromprevious status.

An example phase, shown below, is used to illustrate the sequence in each phase logic module.

Phase logic modules



This section provides sequential function chart representations of the RUNNING, HOLDING, ABORTING, STOPPING and RESTARTING logic for the sample charge phase.

Running logic is the module of code that controls the phase during the RUNNING state.

The following diagram is the sequential function chart (SFC) representation of the running logic for the sample Charge phase.

Running Logic SFC Step 1 Request the parameter values; Reset the totalizer;

Transition 1 Parameter values downloaded;

Step 2 Store parameter value 1 into the totalizer setpoint; Open the valve; Transition 2 Totalizer at setpoint; Step 3 Close the valve; Transition 3 The valve is closed; Step 4 Stop the totalizer; store totalized value into the report array; request to upload report values;

Transition 4 Report values uploaded

Running logic



Each of the steps and transitions in this example SFC is discussed in greater detail in the following table.

Step 1 Step 2 The state transition logic initiates (starts) the running graph with the tag CHARGE_R. The running graph responds by executing the first step. The first step makes a Request to download the parameter values and resets the totalizer. The first transition verifies that the parameters are downloaded. When the Request tag equals zero, the download is complete.

The second step stores the parameter value into the totalizer setpoint, starts the totalizer, and opens the valve. The second transition verifies the totalized value is at the totalizer setpoint.

Step 3 Step 4 The third step closes the valve. The third transition verifies that the valve is closed.

The fourth step stops the totalizer, stores the amount totalized into the report array, and requests the FactoryTalk Batch Server to upload the report values. The fourth transition verifies that the report parameters values are uploaded by again verifying that the Request tag equals zero.

Completion



Upon termination of this graph, the running graph sets the CHARGE_RC tag. This tag indicates to the state transition logic that the RUNNING sequence has run to completion.

The figure below is the Sequential Function Chart (SFC) representation of the holding logic for the sample Charge phase.

Holding logic is the module of code that controls the phase during the HOLDING state.

Holding logic



Each of the steps and transitions in the SFC is discussed in greater detail below.

Step 1 Step 2

The state transition logic initiates (starts) the holding graph with the tag CHARGE_H. The holding graph responds by executing step one. Step one closes the fill valve. The first transition checks if the valve is closed.

The second step stops the totalizer. The second transition is always true.

Completion

Upon termination of this graph, the holding graph sets the CHARGE_HC. This tag indicates that the HOLDING sequence has run to completion.

Aborting logic is the module of code that controls the phase during the ABORTING state.

The figure below is the Sequential Function Chart (SFC) representation of the aborting logic for the sample Charge phase.

Aborting logic




Step 1 Completion

The state transition logic initiates (starts) the aborting graph with the tag CHARGE_A. The aborting graph responds by executing the first step in the graph that closes the valve and stops the totalizer. The transition checks if the valve is closed.

Upon termination of this graph, the aborting graph sets the CHARGE_AC tag. This tag indicates to the state transition logic that the ABORTING sequence has run to completion.

Stopping logic is the module of code that controls the phase during the STOPPING state.

The figure below is the Sequential Function Chart (SFC) representation of the stopping logic for the sample Charge phase.

Stopping logic




Step 1 Step 2

The state transition logic initiates (starts) the stopping graph with the tag CHARGE_S. The stopping graph responds by executing the first step in the graph that closes the valve. The first transition checks if the valve is closed.

The second step stops the totalizer, stores the amount totalized into the report array, and Requests the FactoryTalk Batch Server to upload the report values. The second transition checks if the report parameters values are uploaded by checking if the request parameter is equal to zero.

Completion Upon termination of this graph, the stopping graph sets the CHARGE_SC tag. This tag indicates to the state transition logic that the STOPPING sequence has run to completion.



Restarting logic is the module of code that controls the phase during the RESTARTING state.

The figure below is the Sequential Function Chart (SFC) representation of the restarting logic for the sample Charge phase.


Step 1 Step 2

The state transition logic initiates (starts) the restarting graph with the tag CHARGE_T. The restarting graph responds by executing Step one, which is Null (or does nothing). The first and second transitions determine which step the running graph is in and either executes Step two or Step three.

Step two responds by starting the totalizer and opening the valve. Step three is Null and does nothing. Transitions three and four are always true.

Completion

Restarting logic



Upon termination of this graph, the restarting graph sets the CHARGE_TC tag. This tag indicates to the state transition logic that the restarting sequence has run to completion.


Chapter 10

Phase Logic Interface

The FactoryTalk Batch Server communicates with the project-specific phase logic by way of the Phase Logic Interface (PLI). The PLI provides the data structure necessary for moving commands and requests between the FactoryTalk Batch Server and the phase logic. The PLI receives, interprets and translates commands from the server and forwards the appropriate information to the phase logic. In turn, the PLI also receives, interprets and translates information from the phase logic and forwards the translated information to the server.

The PLI must perform the following critical functions in order to maintain communication between the FactoryTalk Batch Server and the phase logic.

• Enforce the state transition diagram• Support the watchdog protocol• Support the request handshake protocol• Support command handshake protocol• Enable switching between external and batch control

The FactoryTalk Batch Server, or an external control application, sends commands and phase parameter values to the phase logic through the PLI. The PLI interprets the commands and verifies them against the state transition logic. It then forwards the appropriate information to the phase logic. In turn, the phase logic sends requests, status information and report values to the server, or external control application, through the PLI. The PLI again interprets the requests and verifies it against the state transition logic. It then forwards the information to the controlling application(s).

Communications interface

Chapter 10 Phase Logic Interface


Communications Interface Example

The following describes the pre-defined set of data items that allow the FactoryTalk Batch Server to communicate with the phase. These tags are created for each phase created in FactoryTalk Batch Equipment Editor.

Data Item Tag Name/Description Data Type Used By Written By Command PHASE_OC

Used to command the phase to a new state. Integer PLI FactoryTalk Batch

Server

Failure PHASE_F Indicates if the phase is experiencing a failure. 0=No Failure, 1 = Failure

Integer PLI Phase Logic

Owner PHASE_W Defines what is commanding the phase: 0 = Program (Batch), 1 = External (HMI)

Integer FactoryTalk Batch Server, HMI, or PLI

HMI

Pause PHASE_P Used to command the phase to a new state.

Integer PLI Phase Logic

Paused PHASE_PD Set when the phase logic reaches a pre-programmed break point and the single step tag (PHASE_SS) is on.

Integer Phase Logic PLI

Request PHASE_RQ This is used to request service from the FactoryTalk Batch Server.

Integer FactoryTalk Batch Server

Phase Logic

Single Step PHASE_SS Allows the phase logic to pause at each pre-programmed break point.

Integer Phase Logic PLI

Status PHASE_ST Defines the current state of the phase.


PLI

Step Index PHASE_SI Defines the step index of the phase.

Integer Phase Logic Phase Logic

Unit PHASE_UN Defines the current unit for common phases.

Integer Phase Logic FactoryTalk Batch Server

Batch Server / External

PLIPAUSE SEMI_AUTO

COMMAND STATUS EXTERNAL

Phase LogicPAUSED

REQUEST FAILURE REPORTS PARAMETERS UNITS

OWNER

STEP INDEX

Required phase tags



The following table contains a list of data items that the FactoryTalk Batch Server may send to the phase. Some of these data items are required by the server, as indicated by (Required). The remaining data items are merely recommended in the implementation of the PLI. The tag names shown here are used throughout this document.

Data Item Tag Name /Description Data Type Used By Batch Command-Batch (Required)

PHASE_OC The FactoryTalk Batch Server may command the phase to go to a particular state as defined by the state transition diagram.

Integer FactoryTalk Batch

Parameter Values

PHASEPNN where NN is the number of parameters The parameter values are stored in a virtual parameter array within the controller. The FactoryTalk Batch Server can write a single parameter value or an array of parameter values. For example, the parameter values may contain information about the amount of ingredient the phase should add, or the amount of time that the phase logic should run.

Integer, Real or String Phase Logic

External Command (optional)

PHASE_EC The operator may command the phase to go to a particular state as defined by the state transition diagram. The FactoryTalk Batch Server does not use this data item. It is provided to be used by the HMI to manually control the phase.

Integer Phase Logic

Batch RequestBatch

PHASE_RQ The FactoryTalk Batch request flag can be turned on to switch the mode from External to Batch mode. PLI changes the value of PHASE_W owner based on this request.

Boolean PLI

External Request (Optional)

PHASE_ER If the operator wishes to take control of a phase, he/she turns on the External request flag. Upon execution of the request by the PLI, the PLI would place the owner into External mode. The operator may then control the phase manually. The FactoryTalk Batch Server does not use this data item. The preferred method is to be used by the HMI to manually control the phase.

Boolean PLI

Owner (Required)

PHASE_W This tag determines whether FactoryTalk Batch or the HMI can control the phase.

Integer Batch PLI HMI

Unit (Required)

PHASE_UN The unit contains an integer that corresponds to a particular unit. This is used only when a phase is common to two or more units. For example, when a Charge phase in the PLC has the ability to charge two different units, the unit tag indicates which unit the phase should charge at the current time.

Integer Phase Logic

The following table shows the data items that the phase logic may send to the FactoryTalk Batch Server or an external interface application. The PLI must interpret and translate the data items, then forward the appropriate information. Some of these data items are required by the server, as indicated by (Required). The remaining data items are not mandatory, but are

Communication from the FactoryTalk Batch Server

Communication from the phase logic



recommended in the implementation of the PLI. The tag names shown here are used throughout this document.

Data Item Tag Name /Description Data Type Used By Status (Required)

PHASE_ST The status tag contains values that correspond to the state of the phase.

Integer State Transition Logic

Step Index (Required)

PHASE_SI The Step Index contains an integer to indicate which step the phase logic is currently executing. All of the active states (Running, Holding, Restarting, Aborting, and Stopping) use the same Step Index.


Request REQUEST The request tag initiates the request from the phase logic to the FactoryTalk Batch Server.

Integer Phase Logic and PLI

Request Data REQDATA_# where # can be from 1 to 5 The request data buffer stores values that clarify the request initiated with the REQUEST tag.

Integer Phase Logic

Failure Number (Required)

PHASE_F A failure number can be set by the phase exception (interlocking) logic. The phase programmer writes this logic. When it detects an exception condition or whenever a process condition occurs that requires a HELD state the failure integer is set to a non-zero value. An increase in the failure priority when the phase is in the RUNNING or RESTARTING state causes the phase to transition to the HOLDING logic (HELD if _RE is set). A failure number greater than zero will also inhibit the state transitions of IDLE to RUNNING and HELD to RESTARTING.

Integer Phase Logic

Pause (Required)

PHASE_P The operator can request a single pause by issuing a PAUSE command (Command 50) to the phase logic. This sets the PAUSE bit, indicating that the phase logic will pause at the next programmed transition. The PLI resets the PAUSE and PAUSED bits when the next RESUME command occurs, thus causing only a single pause to occur.

Boolean State Transition Logic, FactoryTalk Batch Server, and PLI

Paused (Required)

PHASE_PD The operator can request a single pause by issuing a PAUSE command (Command 50) to the phase. Once the phase logic has paused at the programmed pause transition, it sets the PAUSED bit, indicating that it has paused at the programmed transition. The pause bit will be reset when the next RESUME command occurs, thus causing only a single pause to occur.

Boolean Phase Logic

Owner (Required)

PHASE_W The owner of the phase logic is determined by the external interface. Two request tags are provided in the standard phase logic to toggle the mode between the FactoryTalk Batch Server and External. These request tags are Request and External Request. False= Batch True=External

Boolean State Transition Logic



Data Item Tag Name /Description Data Type Used By Report Value

PHASERNN where NN is the number of report values The report values are stored in a virtual report array within the controller in which the PLI can write a single report value or an array of report values. The FactoryTalk Batch Server can read these report values from the array.

Integer, Real or String

FactoryTalk Batch Server

Single Step (Required)

PHASE_SS The single step attribute indicates when the phase logic is in the Semi-Auto mode. Semi-Auto mode causes the phase logic to transition to the next programmed break point and wait for the operator to issue a RESUME command.

Boolean State Transition Logic

One of the requirements of the PLI is that it support the watchdog protocol. Each PCD must support watchdog logic. This logic monitors the communication with the FactoryTalk Batch Server. This can be accomplished through the watchdog protocol.

Tag Name Alternate Name Type Description

WATCHDOG WATCHDOG Boolean or Integer

The FactoryTalk Batch Server sets the Watchdog flag on a configured time interval. This flag is reset by the PLI every scan. Used for either standard or enhanced watchdog protocol. The timeout period is configurable in the Batchsvr.ini file, entered in milliseconds. The default settings are in the [XMAN] section: WatchdogPeriod=10000 and WatchdogCycles=5. The default time period for the FactoryTalk Batch Server is ten (10) seconds. The PCD timer should be set to a value slightly larger than the product of the WatchdogPeriod and the WatchdogCycles.

The following describes variables that may be used by a PLI to communicate with the FactoryTalk Batch Server or external interface. Some of these data items are required by the server, as indicated by Req. Other tags represent a recommended implementation of the PLI. The tag names shown here will be used throughout this document.

Tag Name Alternate Name Type Description PHASE_CD COMMAND Integer This is the PLI command register. Commands received from

the FactoryTalk Batch Server (PHASE_OC) or external controlling application (PHASE_EC) are copied into this register. This register is then used within the PLI to change states and properties of the phase.

PHASE_EC EXT_ COMMAND

Integer This is the PLI command register for external control. Applications such as an HMI may store to this register to control the Phase. Commands are stored into this register by the external application to change states and properties of the phase.

PHASE_OC (Required)

BS_COMMAND Integer This is the PLI command register. Commands are stored into this register by the FactoryTalk Batch Server to changes states and properties of the phase.

Watchdog communication

PLI variables



Tag Name Alternate Name Type Description PHASE_ST (Required)

STATUS Integer This is the Phase Status register. The PLI processes commands and updates the phase state in this register accordingly.

PHASE_W (Required)

OWNER Boolean This is the Owner flag. This flag is set/reset by the HMI, or force to zero (0) in the PLI.

PHASE_UN (Required)

UNIT Integer This is the Unit ID register. The Unit ID of the Operating unit is stored in this register for the phase. If a particular phase is shared between two or more units, programmed phase logic decisions can be made to change the operating characteristics of the phase logic.

PHASE_SS (Required)

SINGLE_STEP The PHASE_SS flag is set when the SEMI_AUTO command is sent to the command register.

Boolean This is the Single Step flag. the FactoryTalk Batch Server or the external source can toggle this flag by sending a SEMI_AUTO command to the command register. Whenever this flag is set, the phase pauses at every pre-programmed break point.

PHASE_P (Required)

PAUSE Boolean This is the Pause flag. This flag is set by sending a PAUSE command to the phase or if the phase is in Semi-Auto mode. Sending a RESUME command to the phase resets this flag. The user phase logic can examine this flag to pause at any transition within the phase logic. If the phase is in Semi-Auto mode, a RESUME command resets this flag for only one (1) scan.

PHASE_PD (Required)

PAUSED Boolean This is the Paused flag. This flag is set by the phase logic at a valid pause point when the Pause flag is set or by the phase logic at a valid Semi-Auto point if the phase is in SEMI_AUTO mode. Sending a RESUME command to the phase resets this flag.

PHASE_ER EXT_REQUEST Boolean This is the External Request flag. This flag is usually set externally, such as from an HMI system. When this flag is set, the PLI changes ownership of the phase to external.

PHASE_OR BS_REQUEST Boolean This is the FactoryTalk Batch Request flag. This flag is usually set externally, such as from an HMI system. When this flag is set, the PLI changes ownership of the phase to FactoryTalk Batch.

PHASE_SB STEP_BUFFER Integer This is the Phase Step Buffer register. When the PLI changes from any active state to any other active state, the value in the Step Buffer is copied into the Step Index register. When changing from the RUNNING state to the HOLDING state, the Step Index value is copied to the Step Buffer. When changing states from the RESTARTING state to the RUNNING state, the value in the Step Buffer register is copied back to the Step Index Register.



Tag Name Alternate Name Type Description PHASE_HI This is the Phase Hold Index register file. This register is user-

configurable by the STATE_STORE configuration flag. When the STATE_STORE flag is on, the Hold Index register holds the value from the last state. The user’s phase logic can make decisions in the new state based on the value in the Hold Index and the Step Buffer registers. If the STATE_STORE flag is off, the user’s phase logic controls the value in the Hold Index register. The user’s phase logic makes decisions in different states by setting and reading the Hold Index register.

PHASE_RB PHASEB01- PHASEBXn REQUEST_BUFFER

BUF_DATA01 BUF_DATA0n Integer This is the Buffered Phase Request Data Array. PHASE_DL DOWNLOAD Boolean This is the Download Request flag. The Download Request flag

is set by a NEW_PARAMETERS command (70). The NEW_PARAMETERS command is sent to the phase whenever there is "Transfer of Control" within the recipe. The phase programmer can use this flag to determine when the phase has transitioned between two (2) steps within the recipe. The programmer may choose to download new parameters when this flag is set. The phase programmer must reset this flag immediately upon making the request in order to detect another Transfer of Control.

The following describes variables that may be used by the phase logic to communicate with the FactoryTalk Batch Server or external interface by way of the PLI. Some of these data items are required by the Server, as indicated by (Required). Other tags represent a recommended implementation of the phase logic. The tag names shown here are used throughout this document.

Tag Name Alternate Name Type Description PHASE_SI (Required)

STEP_INDEX Integer This is the Phase Step Index register. When the PLI changes the state to any active state, the PLI initializes the Step Index register. The initial value is user-configurable (see _SI) and is usually set to zero (0) or one (1). The user’s phase logic can then use the Step Index Register to step through different steps or states by changing the value in the Step Index register.

PHASE_RQ (Required)

PHASEQ01-PHASEQXn

REQUEST

REQ_DATA01-REQ_DATA0n

Integer This is the virtual Request Data Array. The phase logic can make requests to the FactoryTalk Batch Server with this set of registers. When the PLI changes from any active state to any other active state, the values in the Request Data Array are cleared to zero (0).

Phase logic variables



Tag Name Alternate Name Type Description PHASE_RR RESTORE_REQUEST Boolean This is the Restore Request flag. This flag is a user-configurable

setting. When the phase transitions from RUNNING to HOLDING, then any current request is buffered. If the phase programmer wants to restore the buffered request to the Request Data Array when transitioning from RESTARTING to RUNNING, then this flag must be set.

PHASE_CR CLEAR_REQUEST Boolean This is the Clear flag. This flag is a user-configurable setting. When the phase transitions from RUNNING to HOLDING, ABORTING or STOPPING, the current request is cleared if this flag is set. If the phase programmer wants to clear the request in the Request Data Array, the phase programmer must set this flag.

PHASE_AC ABORT_COMPLETE Boolean This is the Aborting Complete flag. The user’s phase logic must set this flag to indicate to the PLI that the ABORTING logic has run to completion. The PLI monitors this flag and transitions to the ABORTED state when this flag is set.

PHASE_SC STOP_COMPLETE Boolean This is the Stopping Complete flag. The user’s phase logic must set this flag to indicate to the PLI that the STOPPING logic has run to completion. The PLI monitors this flag and transitions to the STOPPED state when this flag is set.

PHASE_HC HOLD_COMPLETE Boolean This is the Holding Complete flag. The user’s phase logic must set this flag to indicate to the PLI that the HOLDING logic has run to completion. The PLI monitors this flag and transitions to the HELD state when this flag is set.

PHASE_TC RESTART_ COMPLETE

Boolean This is the Restarting Complete flag. The user’s phase logic must set this flag to indicate to the PLI that the RESTARTING logic has run to completion. The PLI monitors this flag and transitions to the RUNNING state when this flag is set.

PHASE_RC RUN_COMPLETE Boolean This is the Running Complete flag. The user’s phase logic must set this flag to indicate to the PLI that the RUNNING logic has run to completion. The PLI monitors this flag and transitions to the COMPLETE state when this flag is set.

PHASE_F (Required)

FAILURE Integer This is the Phase Failure register. The user’s phase logic can detect abnormal conditions within the phase and store a failure code into this register. When the PLI detects a non-zero value in this register, the phase changes states from RUNNING to HOLDING

The following describes a recommended set of tags for the implementation of the PLI. These parameters are used for communication between the FactoryTalk Batch Server, or external interface, and the phase. The tag names shown here are used throughout this document.

Name Alternate Name Type Description PHASE_II IDLE_INIT Boolean This is the Idle Initialization flag. If this flag is set, the phase will

transition to the IDLE state on First Scan. The first scan bit is set when the processor mode changes from Program Mode to Run Mode or when the processor powers up in Run Mode.

PLI configuration parameters



Name Alternate Name Type Description PHASE_HA HOLD_ACTIVE Boolean This is the Set Active Phases to Hold on First Scan Configuration flag. If

this flag is set and the phase is RUNNING or RESTARTING it will transition to the HOLDING state on First Scan. The first scan bit is set when the processor mode changes from Program Mode to Run Mode or when the processor powers up in Run Mode. The PHASE_II flag will override this flag.

PHASE_RE REEXECUTE_HOLD Boolean This is the Re-execute Hold Configuration flag. This flag determines if the phase can transition from the HELD state to the HOLDING state upon an increase in Phase Failure.

PHASE_IS INITIAL_STEP Integer This register holds the initial value of the Step Index. The value in this register should be set to the desired initial Step Index value.

PHASE_WC HOLD_ON_WATCHDOG Boolean This flag tells the phase logic whether to go to hold when the PLI loses Watchdog communication with the FactoryTalk Batch Server. If this flag is set and the Watchdog time-out goes true and the phase is running or restarting, the phase will transition to holding. Recommended value = TRUE.

The following components are required to implement the state transition logic in the PLI. Each section describes a specific event, the states which are affected by the event, and the suggested code to implement the required action.

Each process-connected device (PCD) must have one instance of the watchdog logic to coordinate with the FactoryTalk Batch Server. This logic must reset the WATCHDOG flag whenever the FactoryTalk Batch Server sets it. If the WATCHDOG_TIMER times out, then the WATCHDOG_TIMEOUT flag is set. The timeout period is configurable in the Batchsvr.ini file, entered in milliseconds. The default settings are in the [XMAN] section: WatchdogPeriod=10000 and WatchdogCycles=5. The default time period for the FactoryTalk Batch Server is ten (10) seconds. The PCD timer should be set to a value slightly larger than the product of the WatchdogPeriod and the WatchdogCycles. This is used by the phase logic to toggle transitions to the HOLDING state if appropriate.

Example:

Program the PLI

PLI response to watchdog event



If the phase owner (_W) flag is set, then the FactoryTalk Batch command register value is stored into a temporary register. Only the lower byte of the FactoryTalk Batch command register is moved into the temporary command register.

The FactoryTalk Batch Server uses the lower byte of the FactoryTalk Batch command register for the phase command, and the upper byte as serial number to determine which command has been processed by the PLI.

Example: IF NOT PHASE_W AND PHASE_CD = 0 THEN PHASE_CD = PHASE_OC MOD 256; PHASE_OC = PHASE_OC – PHASE_CD;

ENDIF;

If the phase failures (_F) are latched values (are not reset automatically), then the phase failure value can be cleared through FactoryTalk Batch.

Example: IF PHASE_CD = 130 THEN PHASE_F = 0;

ENDIF;

The REQ_COMPLETE command is part of the communication handshaking that is required by FactoryTalk Batch. If the request (_RQ) has been changed to a CANCEL_REQUEST, then the REQ_COMPLETE is ignored.

Example: IF (PHASE_CD = 140) AND (PHASE_RQ <> 6000) THEN PHASE_RQ = 10;

ENDIF;

The REQ_ABORTACK command is part of the communication handshaking that is required by FactoryTalk Batch. If the request (_RQ) has been changed to a CANCEL_REQUEST, then the REQ_ABORTACK is ignored.

Example: IF (PHASE_CD = 150) AND (PHASE_RQ = 6000) THEN PHASE_RQ = 20;

ENDIF;

The REQ_ABORTFAIL command is part of the communication handshaking that is required by FactoryTalk Batch. If the request (_RQ) has been changed to a CANCEL_REQUEST, then the REQ_ABORTFAIL is ignored.

Example: IF (PHASE_CD = 160) AND (PHASE_RQ = 6000) THEN PHASE_RQ = 30;

ENDIF;

Process non-state commands and events for a phase

PLI response to a CLEAR_FAILURE command

PLI response to a REQ_COMPLETE command

PLI response to a REQ_ABORTACK command

PLI response to a REQ_ABORTFAIL command



The REQ_RESET command is part of the communication handshaking that is required by FactoryTalk Batch. This resets the request (_RQ) to 0 allowing the phase logic to issue another request.

Example: IF (PHASE_CD = 170) THEN PHASE_RQ = 0;

ENDIF;

The REQ_FAILED command is part of the communication handshaking that is required by FactoryTalk Batch. It uses the enhanced phase logic request error handling, which resets the request (_RQ) to 1, signifying a failure and allowing the phase to issue another request.

Example: IF (PHASE_CD = 145) AND (PHASE_RQ <> 6000) THEN PHASE_RQ = 15;

IF (PHASE_CD = 170) AND (PHASE_RQ = 15) THEN PHASE_RQ = 1;

ENDIF;

When the SEMI_AUTO command is received, the SingleStep flag (_SS) is toggled. When the SingleStep flag is set on, the Pause (_P) flag is also set on.

Example: IF (PHASE_CD = 60) THEN PHASE_SS = NOT (PHASE_SS); IF PHASE_SS = 0 THEN

PHASE_P = FALSE; ELSE

PHASE_P = TRUE; ENDIF;

ENDIF;

The RESUME command clears the PAUSED (_PD) flag.

Example: IF (PHASE_CD = 80) THEN PHASE_PD = FALSE;

ENDIF;

The NEW_PARAMETERS command sets the download flag (_DL). This indicates to the phase logic that there could be new parameter values to download. The phase programmer can then use this information to issue a download parameter request.

Example: IF (PHASE_CD = 70) THEN PHASE_DL = TRUE;

ENDIF;

PLI response to a REQ_RESET command

PLI response to a REQ_FAILED command

PLI response to a SEMI_AUTO command

PLI response to a RESUME command

PLI response to a NEW_PARAMETERS command



The following sections refer to the phase states that are required by FactoryTalk Batch. An example defining which events can be acted upon while in the specified state is supplied for each state. For active states, a second example is given showing the STATE COMPLETE event.

The only thing that is acted upon while a phase is in the ABORTING state is an ABORT COMPLETE (_AC) from the phase logic.

Example: CASE PHASE_ST OF 10: {ABORTING} CASE PHASE_CD OF

10: {ABORT} {COMMAND IS IGNORED} 20: {HOLD} {COMMAND IS IGNORED} 30: {STOP} {COMMAND IS IGNORED} 40: {RESET} {COMMAND IS IGNORED} 90: {RESTART} {COMMAND IS IGNORED} 100: {START} {COMMAND IS IGNORED}

END_CASE Example ABORT COMPLETE IF PHASE_AC THEN

PHASE_AC = FALSE; IF (PHASE_ST=10) THEN

PHASE_ST = 90; ENDIF;

ENDIF;

While HOLDING, an ABORT or STOP command are acted upon as is a HOLD COMPLETE (_HC) from the phase logic.

PLI phase state processing

ABORTING

HOLDING



Example: 20: {HOLDING} CASE PHASE_CD OF

10: {ABORT} PHASE_SB[PHASE_NUM] := PHASE_SI[PHASE_NUM]; PHASE_SI[PHASE_NUM] := PHASE_IS[PHASE_NUM]; PHASE_HI[PHASE_NUM] := PHASE_ST[PHASE_NUM]; PHASE_ST[PHASE_NUM] := 10; IF PHASE_CR[PHASE_NUM] AND PHASE_RQ[PHASE_NUM] > 999 THEN

PHASE_RQ[PHASE_NUM] := 6000; ENDIF; 20: {HOLD} {COMMAND IS IGNORED} 30: {STOP}

PHASE_SB[PHASE_NUM] := PHASE_SI[PHASE_NUM]; PHASE_SI[PHASE_NUM] := PHASE_IS[PHASE_NUM]; PHASE_HI[PHASE_NUM] := PHASE_ST[PHASE_NUM]; PHASE_ST[PHASE_NUM] := 30; IF PHASE_CR[PHASE_NUM] AND PHASE_RQ[PHASE_NUM] > 999 THEN

PHASE_RQ[PHASE_NUM] := 6000; ENDIF;

40: {RESET} {COMMAND IS IGNORED} 90: {RESTART} {COMMAND IS IGNORED} 100: {START} {COMMAND IS IGNORED}

END_CASE

Example HOLD COMPLETE IF PHASE_HC THEN

PHASE_HC = FALSE; IF (PHASE_ST = 20) THEN


ENDIF;



While STOPPING, an ABORT command is acted upon as is a STOP COMPLETE (_SC) from the phase logic.

Example: 30: {STOPPING} CASE PHASE_CD OF

10: {ABORT} PHASE_SB[PHASE_NUM] := PHASE_SI[PHASE_NUM]; PHASE_SI[PHASE_NUM] := PHASE_IS[PHASE_NUM]; PHASE_HI[PHASE_NUM] := PHASE_ST[PHASE_NUM]; PHASE_ST[PHASE_NUM] := 10; IF PHASE_CR[PHASE_NUM] AND PHASE_RQ[PHASE_NUM] > 999 THEN PHASE_RQ[PHASE_NUM] := 6000;

ENDIF; 20: {HOLD} {COMMAND IS IGNORED} 30: {STOP} {COMMAND IS IGNORED} 40: {RESET} {COMMAND IS IGNORED} 90: {RESTART} {COMMAND IS IGNORED} 100: {START} {COMMAND IS IGNORED} END_CASE

Example STOP COMPLETE IF PHASE_SC THEN

PHASE_SC = FALSE; IF (PHASE_ST = 30) THEN


ENDIF;

While RESTARTING, an ABORT, HOLD, or STOP command are acted upon as is a RESTART COMPLETE (_TC) from the phase logic.

STOPPING

RESTARTING


155

Example: 40: {RESTARTING} CASE PHASE_CD OF

10: {ABORT} PHASE_SB[PHASE_NUM] := PHASE_SI[PHASE_NUM]; PHASE_SI[PHASE_NUM] := PHASE_IS[PHASE_NUM];

PHASE_HI[PHASE_NUM] := PHASE_ST[PHASE_NUM]; PHASE_ST[PHASE_NUM] := 10; IF PHASE_CR[PHASE_NUM] AND PHASE_RQ[PHASE_NUM] > 999 THEN


20: {HOLD} IF ((WTCHDG_T.TOUT AND PHASE_WC[PHASE_NUM) R (PHASE_FI[PHASE_NUM])) THEN

PHASE_SI[PHASE_NUM] := PHASE_IS[PHASE_NUM]; PHASE_ST[PHASE_NUM] := 20; IF PHASE_CR[PHASE_NUM] AND PHASE_RQ[PHASE_NUM] > 999 THEN PHASE_RQ[PHASE_NUM] := 6000; ENDIF;

ENDIF; 30: {STOP}



40: {RESET} {COMMAND IS IGNORED} 90: {RESTART} {COMMAND IS IGNORED} 100: {START} {COMMAND IS IGNORED}

END_CASE IF WTCHDG_T.TOUT AND PHASE_WC[PHASE_NUM] OR

PHASE_F[PHASE_NUM] THEN PHASE_SI[PHASE_NUM] := PHASE_IS[PHASE_NUM]; PHASE_ST[PHASE_NUM] := 20; IF PHASE_CR[PHASE_NUM] AND PHASE_RQ[PHASE_NUM] > 999 THEN


ENDIF;

Example RESTART COMPLETE IF PHASE_TC THEN

PHASE_TC = FALSE; IF (PHASE_ST = 40) THEN

PHASE_ST = 50; PHASE_SI = PHASE_SB[X]; IF PHASE_RR THEN

PHASE_RQ = PHASEBRQ; PHASEQ01 = PHASEB01; PHASEQ02 = PHASEB02; PHASEQ03 = PHASEB03; PHASEQ04 = PHASEB04; PHASEQ05 = PHASEB05;

ENDIF; ENDIF;

ENDIF; Publication# BATCH-RM004B-EN-D - May 2022



While RUNNING, an ABORT, HOLD, or STOP command are acted upon as is a Running Complete (_RC) from the phase logic.

Example: 50: {RUNNING} CASE PHASE_CD OF

10: {ABORT} PHASE_SB[PHASE_NUM] := PHASE_SI[PHASE_NUM]; PHASE_SI[PHASE_NUM] := PHASE_IS[PHASE_NUM]; PHASE_HI[PHASE_NUM] := PHASE_ST[PHASE_NUM]; PHASE_ST[PHASE_NUM] := 10; IF PHASE_CR[PHASE_NUM] AND PHASE_RQ[PHASE_NUM] > 999 THEN PHASE_RQ[PHASE_NUM] := 6000; ENDIF;

20: {HOLD} PHASE_ST[PHASE_NUM] := 20; PHASE_SB[PHASE_NUM] := PHASE_SI[PHASE_NUM]; PHASE_SI[PHASE_NUM] := PHASE_IS[PHASE_NUM]; IF PHASE_RQ[PHASE_NUM] > 999 THEN IF PHASE_CR[PHASE_NUM] THEN PHASE_RQ[PHASE_NUM] := 6000; ELSE PHASEBRQ[PHASE_NUM] := PHASE_RQ[PHASE_NUM]; PHASEB01[PHASE_NUM] := PHASEQ01[PHASE_NUM]; PHASEB02[PHASE_NUM] := PHASEQ02[PHASE_NUM]; PHASEB03[PHASE_NUM] := PHASEQ03[PHASE_NUM]; PHASEB04[PHASE_NUM] := PHASEQ04[PHASE_NUM];

Example RUN COMPLETE IF PHASE_RC THEN

PHASE_RC = FALSE; IF (PHASE_ST = 50) THEN


ENDIF;

RUNNING



While HELD, an ABORT, STOP, or RESTART command is acted upon.

Example: 60: {HELD} CASE PHASE_CD OF

10: {ABORT} PHASE_SB[PHASE_NUM] := PHASE_SI[PHASE_NUM]; PHASE_SI[PHASE_NUM] := PHASE_IS[PHASE_NUM]; PHASE_HI[PHASE_NUM] := PHASE_ST[PHASE_NUM]; PHASE_ST[PHASE_NUM] := 10; IF PHASE_CR[PHASE_NUM] AND PHASE_RQ[PHASE_NUM] > 999 THEN


20: {HOLD} {COMMAND IS IGNORED} 30: {STOP}



40: {RESET} {COMMAND IS IGNORED} 90: {RESTART}

IF (PHASE_CD[PHASE_NUM]=90) THEN PHASE_SI[PHASE_NUM] := PHASE_IS[PHASE_NUM]; PHASE_ST[PHASE_NUM] := 40;

ENDIF; 100: {START} {COMMAND IS IGNORED}

END_CASE IF (PHASE_F[PHASE_NUM] AND PHASE_RE[PHASE_NUM])THEN

PHASE_SI[PHASE_NUM] := PHASE_IS[PHASE_NUM]; PHASE_ST[PHASE_NUM] := 20; IF PHASE_CR[PHASE_NUM] AND PHASE_RQ[PHASE_NUM] > 999 THEN


ENDIF;

While COMPLETE, a RESET or MANUAL command is the only thing acted upon.

HELD

COMPLETE



Example: 70: {COMPLETE} CASE PHASE_CD OF

10: {ABORT} {COMMAND IS IGNORED} 20: {HOLD} {COMMAND IS IGNORED} 30: {STOP} {COMMAND IS IGNORED} 40: {RESET}

PHASE_ST[PHASE_NUM] = 100; PHASE_F[PHASE_NUM] = 0; PHASE_SI[PHASE_NUM] = 0; PHASE_RQ[PHASE_NUM] = 0; PHASE_DL[PHASE_NUM] = 0;

90: {RESTART} {COMMAND IS IGNORED} 100: {START} {COMMAND IS IGNORED}

END_CASE

While STOPPED, a RESET or MANUAL command is the only thing acted upon.

Example: 80: {STOPPED} CASE PHASE_CD OF




END_CASE

While ABORTED, a RESET or MANUAL command is the only thing acted upon.

Example: 90: {ABORTED} CASE PHASE_CD OF




END_CASE

STOPPED

ABORTED



While IDLE, a START or MANUAL command is the only thing acted upon.

Example: 100: {IDLE} CASE PHASE_CD OF

10: {ABORT} {COMMAND IS IGNORED} 20: {HOLD} {COMMAND IS IGNORED} 30: {STOP} {COMMAND IS IGNORED} 40: {RESET} {COMMAND IS IGNORED} 90: {RESTART} {COMMAND IS IGNORED} 100: {START}

IF (PHASE_CD[PHASE_NUM]=100) THEN PHASE_SI[PHASE_NUM] = PHASE_IS[PHASE_NUM]; PHASE_ST[PHASE_NUM] = 50; ENDIF;

END_CASE

IDLE


Appendix A

Build a sequential function chart

In addition to batch terminology, FactoryTalk Batch uses a sequence technology called sequential function charts. This extremely powerful method is well worth the small investment of time required to learn it.

Sequential function charts (SFC) are composed of six graphical structures that are linked together into a chart. Each of the structures represents an element in the phase logic. The rules of execution for SFCs unambiguously describe how the phase logic executes. The following describes each of the graphical structure used in SFCs:

Element Description Graphical Structure

Initial Step The logical start of the SFC.

Step A control step of the phase. Write the control actions statements to the right of the steps.

Final Step The logical end of the SFC.

Transition Defines how control moves from step to step. Write conditional statements to the right side of the transitions.

OR Structure Represents decisions.

AND Structure Represents parallel procedures.

SFC graphical structures

Appendix A Build a sequential function chart


The following table illustrates the construction of an SFC and how an SFC executes:

Step 1 Step 2 Upon activation of this chart, the initial step is active as indicated by the color of the step).

Control is passed to Step A after Transition 1 becomes true.

Step 3 Step 4 After Transition 2 becomes true, Step 1 is inactivated and Steps B and C become active.

After Transition 3 becomes true, Step B is inactivated and Step D is activated.

Step 5 Step 6

SFC execution

Appendix A Build a sequential function chart


When Transition 4 becomes true, Steps C and D are inactivated and Step E is activated.

When Transition 5 becomes true, Step E is inactivated and the final step is activated. This indicates that the entire chart is complete.

The sequential function chart must follow a step - transition - step sequence.

The following lists the benefits of an SFC:

• Unambiguous representation of logic• Supports simple and complex logic• Supports all important logic structures: decisions, loops, parallelism• Standardized in IEC 1131-3 specification

Rules for building an SFC

Benefits of an SFC


Appendix B

Tag naming conventions

This appendix describes tag names commonly used in FactoryTalk Batch PCD interface design.

The following table lists the commonly used tag names and their associated descriptions:

Tag Description PHASE_AC Message from ABORTING logic has completed the sequence.

PHASE_CD Command. The command value to which the state transition logic responds. PHASE_CT Continue Logic Bit. PHASE_EC External Command. PHASE_ER Request for External Mode. PHASE_F Failure number. 0 = no failure. > 0 indicates a failure has occurred. Higher numbers indicate more severe

failures.

PHASE_HC Message from HOLDING logic has completed the sequence.

PHASE_HE Held. On indicates that the Holding/Held/Restarting logic is active and the running logic should not continue.

PHASE_HI Hold identification. Specifies the action to take upon a hold request or failure.

PHASE_OC FactoryTalk Batch Command. This is the command value written from FactoryTalk Batch. PHASE_OR Request for Batch Mode. PHASE_P Pause: On = pause active / off = pause inactive. PHASE_PD Paused: On = the phase logic is currently paused. PHASE_RC Message from RUNNING logic has completed the sequence. PHASE_RQ Request. This is the request value from the phase logic to FactoryTalk Batch. PHASE_SC Message from STOPPING logic has completed the sequence. PHASE_SS Single Step attribute. on = in Semi-Auto Mode. off = in Free Running Mode. PHASE_ST State or Status. (IDLE, RUNNING, Etc.) PHASE_TC Message from RESTARTING logic has completed the sequence. PHASE_UN Phase unit number. PHASE_W Owner: off = Batch mode / on = External Mode. PHASEPNN Parameter ID NN. PHASEQNN Request Parameter ID NN. PHASERNN Report Parameter ID NN. Optional Boolean Variables

PHASE_R Request to execute the RUNNING logic.

PHASE_S Request to execute the STOPPING logic. PHASE_H Request to execute the HOLDING logic. PHASE_T Request to execute the RESTARTING logic. PHASE_A Request to execute the ABORTING logic. PHASE_C Phase is in the COMPLETE state.

Commonly used tag names

Appendix B Tag naming conventions


Tag Description PHASE_SD Phase is in the STOPPED state. PHASE_HD Phase is in the HELD state. PHASE_AD Phase is in the ABORTED state. PHASE_I Phase is in the IDLE state.


Appendix C


This appendix provides a phase template for use in the Structured Text editor.

IF (PHASE_ST = 10) THEN (*TEMPLATE FOR 1 STEP ABORT*) IF (PHASE_SI= 1) THEN (*PERFORM STEP 1*) (******PUT THE WORK FOR ABORT STEP 1 HERE *)

(******PUT THE ABORT COMPLETE CRITERIA HERE *) (*IF CONDITIONX THEN*) PHASE_AC:= TRUE; (*SET THE ABORT COMPLETE FLAG*) (*ENDIF*) END_IF;

ELSIF (PHASE_ST = 30) THEN (*TEMPLATE FOR 2 STEP STOP*) IF (PHASE_SI= 1) AND (NOT PHASE_PD) THEN (*PERFORM STEP 1*) (******PUT THE WORK FOR STOP STEP 1 HERE *)

(******PUT THE TRANSITIONS OUT OF STEP 1 HERE*) (*IF CONDITIONX THEN*) PHASE_SI:= 2; (*END_IF*)

(*THIS PAUSES THE PHASE AFTER THIS STEP IF SINGLE STEP(1) IS ACTIVATED*) (***THIS CODE SHOULD BE DELETED IF SEMI-AUTO ISN’T ALLOWED AT THIS POINT*)

IF PHASE_SS THEN PHASE_PD:= TRUE; END_IF;

ELSIF (PHASE_SI= 2) AND (NOT PHASE_PD) THEN (*PERFORM STEP 2*)

(******PUT THE WORK FOR STOP STEP 2 HERE *)

(******PUT THE STOP COMPLETE CRITERIA HERE *) (*IF CONDITIONX THEN*) PHASE_SC:= TRUE; (*SET THE STOP COMPLETE FLAG*) (*END_IF*) END_IF;

ELSIF (PHASE_ST = 20) THEN (*TEMPLATE FOR 2 STEP HOLD*) IF (PHASE_SI= 1) AND (NOT PHASE_PD) THEN (*PERFORM STEP 1*)

(******PUT THE WORK FOR HOLD STEP 1 HERE *)



Appendix C Structured text phase template


(1) The Single-Step attribute is set when the SEMI_AUTO command isreceived.


(******PUT THE WORK FOR HOLD STEP 2 HERE *)

(******PUT THE HOLD COMPLETE CRITERIA HERE *) (*IF CONDITIONX THEN*) PHASE_HC:= TRUE; (*SET THE HOLD COMPLETE FLAG*) (*END_IF*) END_IF;

ELSIF (PHASE_ST = 40) THEN (*TEMPLATE FOR 2 STEP RESTART*) IF (PHASE_SI= 1) AND (NOT PHASE_PD) THEN (*PERFORM STEP 1*)

(******PUT THE WORK FOR RESTART STEP 1 HERE *)


(*THIS PAUSES THE PHASE AFTER THIS STEP IF SINGLE STEP1 IS ACTIVATED*) (******THIS CODE SHOULD BE DELETED IF SEMI-AUTO ISN’T ALLOWED AT THIS POINT*)


(******INSERT THIS CODE IF AFTER THIS STEP IS A PAUSE POINT*)

(*IF PAUSE_COMMAND THEN PHASE_PD:= TRUE; END_IF;*)


(******PUT THE WORK FOR RESTART STEP 2 HERE *) (******PUT THE RESTART COMPLETE CRITERIA HERE *) (*IF CONDITIONX THEN*) PHASE_TC:= TRUE; (*SET THE RESTART COMPLETE FLAG*) (*END_IF*) END_IF;

ELSIF (PHASE_ST = 50) THEN (*TEMPLATE FOR 5 STEP RUN*) IF (PHASE_SI= 1) AND (NOT PHASE_PD) THEN (*PERFORM STEP 1*) PHASE_RQ:= 1000; (*DOWNLOAD ALL PARAMETERS*) (******ONLY WRITE ON TIME******)


(******PUT THE WORK FOR RUN STEP 1 HERE *)

(******PUT THE TRANSITIONS OUT OF STEP 1 HERE*)



IF (PHASE_RQ=0) THEN PHASE_SI:= 2; END_IF



(****INSERT THIS CODE IF AFTER THIS STEP IS A PAUSE POINT*)

(*IF PHASE_P THEN PHASE_PD:= TRUE; END_IF;*)









(******PUT THE WORK FOR RUN STEP 3 HERE *) (******PUT THE TRANSITIONS OUT OF STEP 3 HERE*) (*IF CONDITIONX THEN*) PHASE_SI:= 4; (*END_IF*)

(*THIS PAUSES THE PHASE AFTER THIS STEP IF SINGLE STEP1 IS ACTIVATED*) (***THIS CODE SHOULD BE DELETED IF SEMI-AUTO ISN’T ALLOWED AT THIS POINT*)










(*THIS PAUSES THE PHASE AFTER THIS STEP IF SINGLE STEP22 IS ACTIVATED*) (***THIS CODE SHOULD BE DELETED IF SEMI-AUTO ISN’T ALLOWED AT THIS POINT*)


(******INSERT THIS CODE IF A PAUSE POINT IS AFTER THIS STEP *)


ELSIF (PHASE_SI= 5) AND (NOT PHASE_PD) THEN (*PERFORM STEP 5*) PHASE_RQ:= 2000; (*UPLOAD ALL REPORTS*) (****ONLY WRITE ON TIME****)


(******PUT THE RUN COMPLETE CRITERIA HERE *) IF (PHASE_RQ = 0) THEN PHASE_RC:= TRUE; (*SET THE RUN COMPLETE FLAG*) END_IF;

ELSIF (PHASE_RQ = 1) THEN PHASE_F:= 1; (*PHASE HELD*)1 END_IF; END_IF;

END_IF;

Any non-zero value causes the phase logic to fail. Failures hold batches according to configured Hold Propagation settings.


Appendix D

Structured text full PLI example

This appendix provides an example of a full Phase Logic Interface (PLI).

The following is an example of a PLI. Explanatory comments are provided in italics surrounded by curly braces {}. The comments are placed just above the section of code being described.

PHASE_NUM := 1;

WHILE (PHASE_NUM<(NUM_PHASES+1)) LOOP

{If this phase is in the IDLE state, and there are no commands in the External or the FactoryTalk Batch command registers, and there is not a request to change ownership of this phase, then the phase logic is not processed.}

If (PHASE_ST[PHASE_NUM]<>100) OR (PHASE_OC[PHASE_NUM] MOD 256 <> 0) OR (PHASE_EC[PHASE_NUM]<> 0) OR (PHASE_ER[PHASE_NUM]) OR (PHASE_OR[PHASE_NUM]) THEN

{The phase owner (_W) flag determines if FactoryTalk Batch can command the phase. If the flag is set, then FactoryTalk Batch cannot command the phase. This allows equipment and control modules to be commanded manually, without the possibility of FactoryTalk Batch interference. The phase owner flag is usually set-reset from an HMI. If the phase owner (_W) flag is set, then the FactoryTalk Batch command register value is stored into a temporary register. Only the lower byte of the FactoryTalk Batch command register is moved into the temporary command register. FactoryTalk Batch uses the lower byte of the FactoryTalk Batch command register for the phase command, and the upper byte as a serial number to determine which command has been processed by the PLI.}

{The user’s phase logic sets an ABORTING STATE COMPLETE bit to indicate to the PLI that the ABORTING logic has run to completion. This rung then changes the phase state to ABORTED. The previous state is reset and the ABORTING STATE COMPLETE bit is reset.}

IF PHASE_AC[PHASE_NUM] THEN PHASE_AC[PHASE_NUM] := FALSE; IF (PHASE_ST[PHASE_NUM]=10) THEN

PHASE_ST[PHASE_NUM] := 90; ENDIF;

ENDIF;

Full PLI example

Appendix D Structured text full PLI example


{The user’s phase logic sets a STOPPING STATE COMPLETE bit to indicate to the PLI that the STOPPING logic has run to completion. This rung then changes the phase state to STOPPED. The previous state is reset and the STOPPED STATE COMPLETE bit is reset.}

IF PHASE_SC[PHASE_NUM] THEN PHASE_SC[PHASE_NUM] := FALSE; IF (PHASE_ST[PHASE_NUM]=30) THEN


ENDIF;

{The user’s phase logic sets a HOLDING STATE COMPLETE bit to indicate to the PLI that the HOLDING logic has run to completion. This rung then changes the phase state to HELD. The previous state is reset and the HOLDING STATE COMPLETE bit is reset.}

IF PHASE_HC[PHASE_NUM] THEN PHASE_HC[PHASE_NUM] := FALSE; IF (PHASE_ST[PHASE_NUM]=20) THEN PHASE_ST[PHASE_NUM] := 60; ENDIF;

ENDIF;

{The user’s phase logic sets a RESTARTING STATE COMPLETE bit to indicate to the PLI that the RESTARTING logic has run to completion. This rung then changes the phase state back to RUNNING. If the Restore Request flag is set then the contents of the Request Buffer is stored back to Request Data Array. The Step Index is restored from the Step Buffer. The previous state is reset and the RESTARTING STATE COMPLETE bit is reset}

IF PHASE_TC[PHASE_NUM] THEN PHASE_TC[PHASE_NUM] := FALSE; IF (PHASE_ST[PHASE_NUM]=40) THEN

PHASE_ST[PHASE_NUM] := 50; PHASE_SI[PHASE_NUM] :=

PHASE_SB[PHASE_NUM]; IF PHASE_RR[PHASE_NUM] THEN

PHASE_RQ[PHASE_NUM] := PHASEBRQ[PHASE_NUM];

PHASEQ01[PHASE_NUM] := PHASEB01[PHASE_NUM];





ENDIF; ENDIF;

ENDIF;

{The user’s phase logic sets a RUNNING STATE COMPLETE bit to indicate to the PLI that the RUNNING logic has run to completion.



This rung then changes the phase state to COMPLETE. The previous state is reset and the RUNNING STATE COMPLETE bit is reset.}

IF PHASE_RC[PHASE_NUM] THEN PHASE_RC[PHASE_NUM] := FALSE; IF (PHASE_ST[PHASE_NUM]=50) THEN


ENDIF;

{If the ABORT command (10) is processed and the phase is HOLDING, STOPPING, RESTARTING, RUNNING or HELD, then the phase state is changed to ABORTING. If the Clear Request Config. flag is set, the current request is cleared. The Step Index is Stored to Step Buffer, and reinitialized. If the State Store Config. Flag is set, the previous state is stored into the Hold Index.}

IF (PHASE_CD=10) AND ((PHASE_ST[PHASE_NUM]=20) OR

(PHASE_ST[PHASE_NUM]=30) OR (PHASE_ST[PHASE_NUM]=40) OR (PHASE_ST[PHASE_NUM]=50) OR (PHASE_ST[PHASE_NUM]=60)) THEN

PHASE_SB[PHASE_NUM] := PHASE_SI[PHASE_NUM];

PHASE_SI[PHASE_NUM] := PHASE_IS[PHASE_NUM];

PHASE_HI[PHASE_NUM] := PHASE_ST[PHASE_NUM];

PHASE_ST[PHASE_NUM] := 10; IF PHASE_CR[PHASE_NUM] AND PHASE_RQ[PHASE_NUM] > 999 THEN


ENDIF;

{If the HOLD command (20) is processed or there is a phase failure and the phase is RESTARTING or RUNNING, or if _WC is set and the watchdog timer timed out, then the phase state is changed to HOLDING. Additionally, if the Re-execute Hold flag is on while in the HELD state and the phase has increase in failure, the HOLDING state is re-executed. The current request is buffered and cleared if the Clear Request flag is on. The Step Index is buffered, and reinitialized.}

IF ((PHASE_CD=20 OR PHASE_FI[PHASE_NUM] OR (WTCHDG_T.TOUT AND PHASE_WC[PHASE_NUM])) AND ((PHASE_ST[PHASE_NUM]=50) OR (PHASE_ST[PHASE_NUM]=40))) OR (PHASE_FI[PHASE_NUM] AND (PHASE_ST[PHASE_NUM]=60) AND PHASE_RE[PHASE_NUM] THEN


PHASE_ST[PHASE_NUM] := 20; IF (PHASE_ST[PHASE_NUM]=50) AND PHASE_RQ[PHASE_NUM] > 999 THEN

PHASEBRQ[PHASE_NUM] := PHASE_RQ[PHASE_NUM];



PHASEB01[PHASE_NUM] := PHASEQ01[PHASE_NUM];





ENDIF; IF PHASE_CR[PHASE_NUM] AND PHASE_RQ[PHASE_NUM] > 999 THEN

PHASE_RQ[PHASE_NUM] := 6000; ENDIF; IF (PHASE_ST[PHASE_NUM] = 50) THEN


ENDIF; ENDIF;

{If the STOP command (30) is processed and the phase is HOLDING, RESTARTING, RUNNING or HELD, then the phase state is changed to STOPPING. If the Clear Request config. flag is set, the current request is cleared. The Step Index is Stored to Step Buffer, and reinitialized. If the State Store Config. Flag is set the previous state is stored into the Hold Index.}

IF (PHASE_CD=30) AND ((PHASE_ST[PHASE_NUM]=20) OR

(PHASE_ST[PHASE_NUM]=40) OR (PHASE_ST[PHASE_NUM]=50) OR (PHASE_ST[PHASE_NUM]=60)) THEN



PHASE_HI[PHASE_NUM] := PHASE_ST[PHASE_NUM];

PHASE_ST[PHASE_NUM] := 30; IF PHASE_CR[PHASE_NUM] AND PHASE_RQ[PHASE_NUM] > 999 THEN


ENDIF;

{If the Reset command (40) is processed, and the phase is in the COMPLETE, ABORTED or STOPPED state, or the phase logic is being reinitialized, then the phase state changes to IDLE. Any failures are reset. The Step Index and the Request Data Array are reinitialized.}

IF PHASE_CD = 40 AND ((PHASE_ST[PHASE_NUM]=70) OR

(PHASE_ST[PHASE_NUM]=90) OR (PHASE_ST[PHASE_NUM]=80)) THEN

PHASE_ST[PHASE_NUM] := 100; PHASE_F[PHASE_NUM] := 0; PHASE_SI[PHASE_NUM] := 0; PHASE_RQ[PHASE_NUM] := 0;

ENDIF;



{If the RESTART command (90) is processed and the phase is HELD and the phase is not in MANUAL and there are no failures, then the phase state changes to RESTARTING. The Step Index is reinitialized.}

IF PHASE_CD = 90 AND PHASE_F[PHASE_NUM] = 0 AND

(PHASE_ST[PHASE_NUM]=60) THEN PHASE_SI[PHASE_NUM] :=

PHASE_IS[PHASE_NUM]; PHASE_ST[PHASE_NUM] := 40;

ENDIF;

{If the START command (100) is processed and the phase is IDLE and the phase is not in MANUAL and there are no failures, then the phase state changes to RUNNING. The Step Index is reinitialized.}

IF PHASE_CD = 100 AND PHASE_F[PHASE_NUM] = 0 AND

(PHASE_ST[PHASE_NUM]=100) THEN PHASE_SI[PHASE_NUM] :=

PHASE_IS[PHASE_NUM]; PHASE_ST[PHASE_NUM] := 50;

ENDIF;

{If the CLEAR FAILURE command (130) is processed then the failure register clears. The phase programmer may choose to latch in the failure register. If this is the case, a CLEAR FAILURE command must be issued from the FactoryTalk Batch Server to clear the failure register.}

IF PHASE_CD = 130 THEN PHASE_F[PHASE_NUM] := 0;

ENDIF;

{When the phase logic makes a request, the FactoryTalk Batch Server services the request and then sends a REQUEST CONFIRMED (140) command to the PLI. The PLI then stores a (10) in the request register indicating to the FactoryTalk Batch Server that it has received the confirmation. The FactoryTalk Batch Server then sends a CLEAR REQUEST (170) command to the PLI.}

IF PHASE_CD = 140 AND PHASE_RQ[PHASE_NUM] <> 6000 THEN


{When the PLI changes the state of the phase, the PLI will enter a "CANCEL PREVIOUS REQUEST" request (6000) into the request register. The FactoryTalk Batch Server will try to cancel the previous request. If the previous request was successfully canceled, the FactoryTalk Batch Server sends down a "REQUEST SUCCESSFULLY CANCELLED" command (150). The PLI will then set the request register to 20 indicating that the previous request was cancelled.}

IF PHASE_CD = 150 AND PHASE_RQ[PHASE_NUM] = 6000 THEN




{When the PLI logic changes the state of the phase, the PLI will enter a "CANCEL PREVIOUS REQUEST" request (6000) into the request register. The FactoryTalk Batch Server will try to cancel the previous request. If the previous was unsuccessfully cancelled, the FactoryTalk Batch Server sends down a "REQUEST UNSUCCESSFULLY CANCELLED" command (160). The PLI will then set the request register to 30 indicating that the previous request was not cancelled.}

IF PHASE_CD = 160 AND PHASE_RQ[PHASE_NUM] = 6000 THEN


{After a request was made, the FactoryTalk Batch Server will process the request and send a command indicating that the request was processed. The PLI will then set the Request register to a value of 10, 20, 30 depending on the type of request that was made. When the FactoryTalk Batch Server receives the acknowledgement of the command, the FactoryTalk Batch Server sends "CLEAR REQUEST REGISTER" command. The PLI then clears the request register}

IF PHASE_CD = 170 THEN PHASE_RQ[PHASE_NUM] := 0 ;

ENDIF;

{The Download Request flag is set by a NEW_PARAMETERS command (70). The NEW_PARAMETERS command is sent to the phase whenever there is "Transfer of Control" within a recipe. The programmer can use this flag to determine when the phase has transitioned between two(2) steps within the recipe. The programmer would make a new request for parameters if necessary and reset this flag.}

IF PHASE_CD = 70 THEN PHASE_DL[PHASE_NUM] := TRUE;

ENDIF;

{The Semi-Auto function is used in conjunction with the Pause function. When the SEMI_AUTO command is processed, the Single Step flag is set on unless it is already on, then it is set off. If the Single Step flag is on, the Pause flag turns on. A Resume command resets the Pause flag to off for one scan. The programmer can reference the Pause flag within the phase logic to pause at predefined transitions.}

IF PHASE_CD = 60 THEN PHASE_SS[PHASE_NUM] :=

NOT(PHASE_SS[PHASE_NUM]); ENDIF;

{The phase logic programmer can write logic at transitions within the phase logic to check the status of the PAUSE flag. If the PAUSE flag is on, then the transition to the next state should not be allowed. The PAUSE flag is set by a Pause command (50) or the phase being in Semi-



Auto mode. Only a resume command resets the PAUSE flag. If the phase is in Semi-Auto mode, the RESUME command resets the PAUSE flag until the next transition.}

IF PHASE_CD = 50 OR PHASE_SS[PHASE_NUM] THEN PHASE_P[PHASE_NUM] := TRUE;

ENDIF;

{When the Resume command (80) is processed the PAUSE flags are reset}

IF PHASE_CD = 80 THEN PHASE_P[PHASE_NUM] := FALSE; PHASE_PD[PHASE_NUM] := FALSE;

ENDIF;

ENDIF;

PHASE_NUM:= PHASE_NUM + 1; END LOOP;

Index


Index

1 1601

11601 68

A abort 27

complete 155 abort request 85 aborted 23, 161 aborting 22, 133, 155

logic 138 phase logic requests 44

acquire multiple resources 77 resources 76 single resource 76

acquire requests types 76

active states 22 all phase parameter values 64 all report parameter limits 68 all report parameters 70 allocating phase memory tags 127 AND structure 163 attribute ID 98

B basic control 17 Batch

Equipment Editor 14 Recipe Editor 14 Server 14 View 14

batch parameters download 85

boolean communication with the phase 59 boolean variables 167 BS_COMMAND 148 BS_REQUEST 148

C cancel

message indirect 84

message requests 83

message types 83 messages to other phases 83

canceling a message 83

indirect 84 all messages 84

clear message 75 CLEAR_REQUEST 149 clearfailure 27 COMMAND 148 command handshake protocol 32 communication

from the Batch Server 145 from the phase 146 interface 146 protocol states 24

communication failure with Server 97 communications interface 15, 143 complete 23, 160 completion of messages 79 container heel 91 control module 121 controller ID 89 custom attributes 89

D data transfer 79 define resources 121 define tags 121 download 148

batch parameters 85 on start 66 on TOC 66, 67 phase parameter types 63 phase parameter value requests 63

download on start 67

E electronic batch record entries 70 enhanced phase logic requests 97 enhanced watchdog protocol 55 equipment module 120 example phase

phase logic modules 134 EXT_COMMAND 148 EXT_REQUEST 148 external command tag 145 external request tag 145

F FAILURE 149 failure detection 133 failure number tag 146 failure tag 144

Index


final step 163 follow the phase logic request protocol 38 function of the phase logic 20 function of the PLI 20

G general signature request

indirect 86

H heel

container 91 held 23, 159 high byte 33 HMI 18 hold 27 hold complete 155 HOLD_ACTIVE 151 HOLD_ON_WATCHDOG 151 HOLDING 22, 133, 155 holding logic 137 Human-Machine Interface 18

I identifying the phases in the selected

process 123 idle 23, 161 IDLE_INIT 151 initial step 163 INITIAL_STEP 151 interface design 19

L logic

aborting 138

M material database 89 material database classifications 89 material phase 94

diagram 94 Material Server requests 96 message

cancel 83 indirect 84

cancel all 84 cancel to other phases 83 clear 75 send to other phase 80

indirect 81 send to other phase and wait 81

indirect 81

send to other phase and wait for one receiver 82

indirect 82 send to other phases 79 wait for message from another phase 84

indirect 85 messages

cancel 83 cancel all 84 to other phases, types 80

modularization criteria 121 modules of code in phase logic 132 multiple resources

acquiring 77

N NEW_PARAMETERS command 48 newparameters 27

O obey the state transition diagram 31 OR structure 163 OWNER 148 owner tag 144, 145, 146

P P & ID drawing 123 PAUSE 148 pause tag 144, 146 PAUSED 148 paused tag 146 permissive 79 phase API tags 27 phase communication

data transfer 79 permissive 79 synchronization 79

phase components 15 phase logic

aborting 133, 138 failure detection 133 holding 133, 137 project specific 17 purpose 20 restarting 133 restarting logic 140 running 133, 135 stopping 133, 139

phase logic interface 143 phase logic modules 134 phase logic request protocol 39 phase logic requests

aborting 44 phase logic variables 149 phase logic, programming 127

Index


phase memory tags 128 phase parameter

download parameter types 63 download value requests 63

phase parameter tags array 63 phase parameters

request/range 64 request/single 65

phase tags 27 phase tags, required 144 PHASE_AC tag 149 PHASE_CD tag 148 PHASE_CR tag 149 PHASE_DL tag 148 PHASE_EC 145 PHASE_EC tag 148 PHASE_ER 145 PHASE_ER tag 148 PHASE_F 59, 144, 146 PHASE_F tag 149 PHASE_HA 151 PHASE_HC tag 149 PHASE_HI tag 148 PHASE_II 151 PHASE_IS 151 PHASE_OC 37, 45, 48, 49, 59, 144, 145 PHASE_OC tag 148 PHASE_OR tag 148 PHASE_P 48, 144, 146 PHASE_P tag 148 PHASE_PD 48, 144, 146 PHASE_PD tag 148 PHASE_RB tag 148 PHASE_RC tag 149 PHASE_RE 151 PHASE_RQ 45, 49, 144, 145 PHASE_RQ tag 149 PHASE_RR tag 149 PHASE_SB tag 148 PHASE_SC tag 149 PHASE_SI 144, 146 PHASE_SI tag 149 PHASE_SS 48, 144, 146 PHASE_SS tag 148 PHASE_ST 58, 144, 146 PHASE_ST tag 148 PHASE_TC tag 149 PHASE_UN 144, 145 PHASE_UN tag 148 PHASE_W 51, 144, 145, 146 PHASE_W tag 148 PHASE_WC 151 PHASEBXn tag 148 PHASEPNN 145 PHASEQ## 45, 49 PHASEQXn tag 149 PHASERNN 146

PKID 105 PLI 15, 143

multiple instances 15 purpose 20 single instance 15

PLI communications protocols 31 follow the phase logic request protocol 38 obey the state transition diagram 31 support program/external attribute 50 support semi-auto functionality 46 support the command handshake protocol

31 support the failure protocol 51 support the NEW_PARAMETERS command

48 support the watchdog protocol 52

PLI phase state processing 155 PLI response

to CLEAR_FAILURE command 153 to NEW_PARAMETER command 155 to REQ_ABORTACK command 153 to REQ_ABORTFAIL command 153 to REQ_COMPLETE command 153 to REQ_FAILED command 154 to REQ_RESET command 154 to RESUME command 154 to SEMI_AUTO command 154 to watchdog event 152

PLI variables 148 priority for selecting containers 89 process modules

control module 121 equipment module 120 unit 120

processing non-state commands and events for a phase 152

processing send and receive messages 80 program/external attribute 50 programming the PLI 152 project-specific phase logic 17, 133 protocol states

communication 24

Q quiescent states 23

R range of report parameters 71 REEXECUTE_HOLD 151 release requests, types 77 release resources 77 releasing a single resource 78 releasing all acquired resources 79 releasing multiple resources 78 report parameter array 69 report parameter requests, types 70

Index

182

reqabortack 27 reqabortfail 27 reqcomplete 27 REQDATA_# 146 request 146, 149

1000 64 1100 64 11000 64 11100 64 111NN 64 11200 65 112NN 65 11300 66 113NN 66 11500 66 11501 67 11502 67 11NN 64 1200 65 12000 70 12100 71 121NN 71 12200 72 122NN 72 12300 73 123NN 72 12500 73 12501 74 12502 74 12NN 65 1300 66 13000 75 130NN 75 13100 75 13NN 66 14000 76 140NN 76 141NN 77 14200 78 142NN 78 143NN 78 14400 79 1500 66 15000 81 1501 67 1502 67 150NN 80 15100 81 151NN 81 15200 82 152NN 82 15300 84 153NN 83 15400 84 15500 85 155NN 84 16000 85 171NN 85

Publication# BATCH-RM004B-EN-D - May 2022

172NN 85 173NN 85 174NN 85 175NN 85 17600 85 17700 85 17900 86 179NN 86 2000 70 2100 71 21NN 71 2200 72 22NN 72 2300 73 23NN 72 2500 73 2501 74 2502 74 3000 75 30NN 75 3100 75 4000 76 40NN 76 41NN 77 4200 78 42NN 78 43NN 78 4400 79 5000 81 50NN 80 5100 81 51NN 81 5200 82 52NN 82 5300 84 53NN 83 5400 84 5500 85 55NN 84 6000 85 71NN 85 72NN 85 73NN 85 74NN 85 75NN 85 7600 85 7700 85 7900 86 79NN 86

request data buffer 146 request register

reset to zero 61 request tag 146 REQUEST_BUFFER 148 requesting a range of phase parameters 64 requesting a single phase parameter 65 requesting a single phase parameter value

66

Index


requesting all phase parameter values 64 requesting report parameters/all 70 requesting report parameters/range 71 requesting report parameters/single

specify location 72 requesting subset of parameter values 66

download on start 67 download on TOC 67

requesting subset of report values 73 upload on terminal state 74 upload on TOC 74

requests abort request 85 acquire resources 76 acquiring resources/multiple 77 acquiring resources/single 76 cancel messages to other phases 83 canceling a message 83

indirect 84 canceling all messages 84 clear message 75 download batch parameters 85 enhanced phase logic 97 parameter subsets 66


phase parameters/all 64 phase parameters/range 64 phase parameters/single 65 release resources 77 releasing resources/all acquired 79 releasing resources/multiple 78 releasing resources/single 78 report parameters/all 70 report parameters/range 71 report parameters/single

specify location 72 report value subsets 73

upload on terminal state 74 upload on TOC 74

send message 75 send message to other phases 79 sending a message 80

indirect 81 sending a message and wait 81

indirect 81 sending a message and wait for one

receiver 82 indirect 82

single phase parameter/specify location 66

upload report values 68 wait for message from another phase 84

indirect 85 RESET 27 resources

acquire 76 restart 27 restart complete 157 restarting 22, 133, 157 restarting logic 140 RESTORE_REQUEST 149 resume 27 rules for building an SFC 165 run complete 159 running 22, 159 running logic 135

S sample code 155 Selection Priority 112 semiauto 27 semi-auto functionality 47 send message 75 send message wait and receive message

wait request pair 79 send messages to other phases 79 sending a message 80

indirect 81 sending a message and wait 81

indirect 81 sending a message and wait for one

receiver 82 indirect 82

SFC execution 164 SFC graphical structures 163 single report parameter

specify location 72 single report parameter limits 68 single step tag 144, 146 single_step 27, 148 standard attributes 89 standard watchdog protocol 53 START 27

download on 66 state transition logic 15 state transitions 25 STATUS 148 status tag 146 step 163 step index tag 146 STEP_BUFFER 148 STEP_INDEX 149 stop 27 stop complete 156 stopped 23, 161 stopping 22, 133, 156 stopping logic 139 structured text full PLI example 173 subset of parameter values 66


Index


subset of report values 73 upload on terminal state 74 upload on TOC 74

support program/external attribute 50 support semi-auto functionality 46 support the command handshake protocol

31 support the failure protocol 51 support the NEW_PARAMETERS command

48 support the watchdog protocol 52 synchronization 79

T tag naming conventions 167 terminal state

upload on 73, 74 TOC

download on 66, 67 upload on 73, 74

transfer of control 27, 48, 68, 79, 148, 173 download on 66, 67

transition 163 transition logic 15

U unable to communicate with Material Server

97 unit 120, 148 unit tag 144, 145 upload on terminal state 73, 74 upload on TOC 73, 74 upload report values 68 using enhanced phase logic requests 97

V variables, PLI 148

W wait for a message from another phase 84

indirect 85 WATCHDOG 58 watchdog communication 147 watchdog protocol 56

enhanced 55 standard 53

WATCHDOG tag 147

Allen-Bradley, expanding human possibility, Logix, Rockwell Automation, and Rockwell Software are trademarks of Rockwell Automation, Inc.

EtherNet/IP is a trademark of ODVA, Inc.

Trademarks not belonging to Rockwell Automation are property of their respective companies.

Rockwell Otomayson Ticaret A.Ş. Kar Plaza İş Merkezi E Blok Kat:6 34752, İçerenkÖy, İstanbul, Tel: +90 (216) 5698400 EEE YÖnetmeliğine Uygundur

Publication# BATCH-RM004B-EN-D - May 2022 Supersedes Publication# BATCH-RM004A-EN-D - October 2020 Copyright © 2022 Rockwell Automation Technologies, Inc. All Rights Reserved. Printed in the U.S.A.

Rockwell Automation support Use these resources to access support information.

Technical Support Center Find help with how-to videos, FAQs, chat, user forums, and product notification updates. rok.auto/support

Knowledgebase Access Knowledgebase articles. rok.auto/knowledgebase Local Technical Support Phone Numbers Locate the telephone number for your country. rok.auto/phonesupport

Literature Library Find installation instructions, manuals, brochures, and technical data publications. rok.auto/literature Product Compatibility and Download Center (PCDC)

Get help determining how products interact, check features and capabilities, and find associated firmware.

rok.auto/pcdc

Documentation feedback Your comments help us serve your documentation needs better. If you have any suggestions on how to improve our content, complete the form at rok.auto/docfeedback.

Waste Electrical and Electronic Equipment (WEEE)

At the end of life, this equipment should be collected separately from any unsorted municipal waste.

Rockwell Automation maintains current product environmental information on its website at rok.auto/pec.

http://rok.auto/support

http://rok.auto/knowledgebase

http://rok.auto/phonesupport

http://rok.auto/literature

http://rok.auto/pcdc

http://rok.auto/docfeedback

http://rok.auto/pec

Documents

FactoryTalk Batch PCD Programming (Publication# BATCH