FactoryTalk Batch Technical Reference Guide Volume 1literature.rockwellautomation.com/idc/groups/literature/documents/... · FactoryTalk Batch PCD Programmer Technical Reference Guide

Technical Reference GuideVolume 1

FactoryTalk® Batch

Reference Guide

FactoryTalk® Batch Server API Communication Language

Important User Information

Solid-state equipment has operational characteristics differing from those of electromechanical equipment. Safety Guidelines for the Application, Installation, and Maintenance of Solid State Controls (publication SGI-1.1 available from your local Rockwell Automation sales office or online at http://www.rockwellautomation.com/literature/) describes some important differences between solid-state equipment and hard-wired electromechanical devices. Because of this difference, and also because of the wide variety of uses for solid-state equipment, all persons responsible for applying this equipment must satisfy themselves that each intended application of this equipment is acceptable.

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

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.

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

Allen-Bradley, Rockwell Software, and Rockwell Automation ControlLogix, eProcedure, FactoryTalk, RSBizWare, RSBizWare BatchHistorian, RSBizWare Historian, RSBizWare MaterialTrack, and RSLinx are trademarks of Rockwell Automation, Inc.

Trademarks not belonging to Rockwell Automation are property of their respective companies.

http://www.rockwellautomation.com/literature

Rockwell Automation Publication FactoryTalk Batch Server API Communication Language Reference Guide - February 2017 3

Table of contents

Chapter 1

Move from DDE to COM ............................................................................................... 11 COM protocol .................................................................................................................... 12

Properties, methods, and events .............................................................................. 12 BatchServer object ...................................................................................................... 13 BatchRemote object ................................................................................................... 14

Available items .................................................................................................................... 15 Available executes ............................................................................................................... 19 Additional resources .......................................................................................................... 21

Chapter 2

BadTagCount ..................................................................................................................... 24 BatchList .............................................................................................................................. 24 BatchListCt ......................................................................................................................... 26 BatchOverrides ................................................................................................................... 27 BLBatchID_x ...................................................................................................................... 27 BLCMDMask_x ................................................................................................................ 28 BLDesc_x ............................................................................................................................. 29 BLFailure_x ......................................................................................................................... 31 BLMode_x ........................................................................................................................... 32 BLRecipe_x ......................................................................................................................... 33 BLStartTime_x ................................................................................................................... 34 BLState_x ............................................................................................................................. 35 BLType_x ............................................................................................................................ 36 COMClientCount ............................................................................................................ 37 CPRVersion ........................................................................................................................ 37 CreateIDBatchStepDataList ........................................................................................... 38 CreateIDBatchStepDataList2 ......................................................................................... 42 CreateIDEventData .......................................................................................................... 46 CreateIDEventDataFile .................................................................................................... 47 CreateIDScale ..................................................................................................................... 48 DataServersList ................................................................................................................... 48 DataServerStatistics ........................................................................................................... 51 DDEClientCount .............................................................................................................. 52 DecimalSeparator ............................................................................................................... 53 Domains ............................................................................................................................... 53 EnumSetEnumSet .............................................................................................................. 54 EquipmentModel ............................................................................................................... 55 EquipmentModelDate ...................................................................................................... 55 ErrorMessage ....................................................................................................................... 56 EventDataFiles .................................................................................................................... 56

FactoryTalk Batch Server API introduction

Item reference

Table of contents

4 Rockwell Automation Publication FactoryTalk Batch Server API Communication Language Reference Guide - February 2017

ExpressionID_UnitID_Values ........................................................................................ 58 ExpressionIDParamExprValues ...................................................................................... 59 ExpressionIDReportExprValues ..................................................................................... 61 HyperlinkLabels ................................................................................................................. 62 IncompleteSignaturesCt ................................................................................................... 63 InfoMessage ......................................................................................................................... 64 ItemCount ........................................................................................................................... 64 JournalDir ............................................................................................................................ 65 ListSeparator ....................................................................................................................... 65 Locale .................................................................................................................................... 66 MatSvrStatus ....................................................................................................................... 67 OPCClientCount .............................................................................................................. 67 OperationDataList............................................................................................................. 68 OperationErrs ..................................................................................................................... 71 OperationErrsCt ................................................................................................................ 72 PhaseDataList ..................................................................................................................... 73 PhaseErrs .............................................................................................................................. 76 PhaseErrsCt ......................................................................................................................... 77 PhaseIDBatchID ................................................................................................................ 78 PhaseIDFailure ................................................................................................................... 78 PhaseIDInfo ........................................................................................................................ 79 PhaseIDMessage ................................................................................................................. 79 PhaseIDOwnerFlag ........................................................................................................... 80 PhaseIDParms ..................................................................................................................... 81 PhaseIDParms2 .................................................................................................................. 82 PhaseIDPause ...................................................................................................................... 83 PhaseIDPausing .................................................................................................................. 84 PhaseIDPhaseData ............................................................................................................. 85 PhaseIDPhaseData2 .......................................................................................................... 87 PhaseIDRequests ................................................................................................................ 89 PhaseIDSS ........................................................................................................................... 89 PhaseIDState ....................................................................................................................... 90 PhaseIDStepIndex ............................................................................................................. 90 PhaseIDUnit ....................................................................................................................... 91 PhasesList ............................................................................................................................. 92 PhasesList2 .......................................................................................................................... 93 PhasesList3 .......................................................................................................................... 94 ProcedureIDData ............................................................................................................... 96 ProcedureIDData2 .......................................................................................................... 102 ProcedureIDData3 .......................................................................................................... 109 ProcedureIDDevLimits .................................................................................................. 116 ProcedureIDStatus........................................................................................................... 118 ProcedureIDStatus2 ........................................................................................................ 123 ProcedureIDUnitRequirements ................................................................................... 129 ProcessCellBitMaps ......................................................................................................... 130 ProcessCellIDUnits ......................................................................................................... 131 ProcessCellsList ................................................................................................................ 133

Table of contents


ProcessCellsList2 .............................................................................................................. 134 RecipeDir ........................................................................................................................... 135 RecipeList .......................................................................................................................... 135 ResourceIDEqData .......................................................................................................... 138 ResourceIDHyperlinks ................................................................................................... 149 ResourceIDInfo ................................................................................................................ 150 ResourceIDOwned .......................................................................................................... 151 ResourceIDOwners ......................................................................................................... 152 ResourceIDRequested ..................................................................................................... 153 ResourceIDRequesters .................................................................................................... 154 ResourceIDStrings ........................................................................................................... 155 ResourcesList ..................................................................................................................... 156 RunMode ........................................................................................................................... 157 RunWithoutMatSvr ........................................................................................................ 157 SignatureIDSig .................................................................................................................. 158 Signatures ........................................................................................................................... 163 StartTime ........................................................................................................................... 164 StepsList ............................................................................................................................. 165 StringLabels ....................................................................................................................... 166 TagVerStatus ..................................................................................................................... 168 TagVerStatusOrd ............................................................................................................. 169 ThousandsSeparator ........................................................................................................ 169 Time .................................................................................................................................... 170 Time2 ................................................................................................................................. 171 TimerIDTimerData ........................................................................................................ 172 TimerIDTimerStatus ...................................................................................................... 175 TimerSteps ........................................................................................................................ 177 TotalTagCount ................................................................................................................ 178 UEArea_x .......................................................................................................................... 179 UEBatchID_x ................................................................................................................... 180 UEDefault_x ..................................................................................................................... 181 UEDesc_x .......................................................................................................................... 182 UEEU_x ............................................................................................................................. 183 UEEvent_x ........................................................................................................................ 184 UEEventID_x ................................................................................................................... 185 UEHigh_x ......................................................................................................................... 186 UELow_x ........................................................................................................................... 187 UEPhase_x ........................................................................................................................ 188 UEProcCell_x ................................................................................................................... 189 UERecipe_x ....................................................................................................................... 190 UERespType_x ................................................................................................................. 191 UETime_x ......................................................................................................................... 193 UEUnit_x .......................................................................................................................... 194 UEValue_x ........................................................................................................................ 195 UnAcknowledgedEvents ................................................................................................ 196 UnacknowledgedEventsCt ............................................................................................ 198 UnitBitMaps ..................................................................................................................... 199

Table of contents


UnitIDBatchID ................................................................................................................ 200 UnitIDOperations ........................................................................................................... 201 UnitIDPhaseBitmaps ...................................................................................................... 202 UnitIDPhases.................................................................................................................... 203 UnitIDPhases2 ................................................................................................................. 204 UnitIDUnitTagData ...................................................................................................... 205 UnitReqIDBindingPreferences ..................................................................................... 209 UnitReqIDBindingRequirements ................................................................................ 211 UnitsList ............................................................................................................................ 212 VerifiedTagCount............................................................................................................ 213 Version ............................................................................................................................... 214 WarningMessage .............................................................................................................. 215

Chapter 3

Ack ...................................................................................................................................... 219 Acquire ............................................................................................................................... 220 AddEvent ........................................................................................................................... 221 AddEvent_CI.................................................................................................................... 223 AddEvent_Instruction .................................................................................................... 224 AddEvent_Phase .............................................................................................................. 225 Archiver .............................................................................................................................. 226 AutoBatchID_Info .......................................................................................................... 227 AutoRemove ..................................................................................................................... 229 Batch ................................................................................................................................... 230 Bind ..................................................................................................................................... 233 BindPhase .......................................................................................................................... 234 CancelSignature................................................................................................................ 236 Command .......................................................................................................................... 237 ControlStrategy ................................................................................................................ 239 Enum .................................................................................................................................. 240 Expression .......................................................................................................................... 241 ForceTransistion .............................................................................................................. 243 GetContainerData ........................................................................................................... 244 GetFeedTypeAndMaterials ........................................................................................... 246 GetLegalEqModules ........................................................................................................ 248 GetLegalUnits ................................................................................................................... 250 GetPossibleLegalUnits .................................................................................................... 251 Info ...................................................................................................................................... 253 Info2.................................................................................................................................... 257 InfoTrimmed .................................................................................................................... 259 MatSvrControl ................................................................................................................. 264 Messages ............................................................................................................................. 265 Mtrl_Info ........................................................................................................................... 266 Order .................................................................................................................................. 268 ParamExpClear ................................................................................................................. 269

Execute reference

Table of contents


ParamExpOverride .......................................................................................................... 270 Parms .................................................................................................................................. 271 Parms2 ................................................................................................................................ 272 Phase ................................................................................................................................... 273 Phase2 ................................................................................................................................. 275 Phase3 ................................................................................................................................. 276 ReactivateStep ................................................................................................................... 279 RecipeList .......................................................................................................................... 280 Release ................................................................................................................................ 282 Remove ............................................................................................................................... 283 SetAllLabel ........................................................................................................................ 284 SetAllLot ............................................................................................................................ 285 SetParm .............................................................................................................................. 287 SignoffSignature ............................................................................................................... 288 Step ...................................................................................................................................... 289 Tag_Verify ......................................................................................................................... 291 User_Verify ....................................................................................................................... 292 VerificationInfo ................................................................................................................ 292

Chapter 4

ResourcesListX ................................................................................................................. 294 ResourcesListX example ......................................................................................... 295

[ResourceID] ResourceDataX ....................................................................................... 296 [ResourceID]ResourceDataX example ................................................................ 297

Appendix A

GetItem method ............................................................................................................... 300 Execute method ................................................................................................................ 301 CallTimeout property ..................................................................................................... 302 ConnectTimeout property ............................................................................................. 303 Node property ................................................................................................................... 304 TimeoutPeriod property ................................................................................................. 305 Command prompt ........................................................................................................... 306

Appendix B

Command masks .............................................................................................................. 309 Command values ...................................................................................................... 310

Arbitration masks ............................................................................................................. 316

XML-based item references

Object reference

Command and arbitration masks

Table of contents


Appendix C

Appendix D

Legal Notices ..................................................................................................................... 321

Valid states and modes

FactoryTalk Batch Server API glossary

Legal Notices Index


Chapter 1

FactoryTalk Batch Server API introduction

This information was developed to provide quick and easy access to information regarding the interface between the FactoryTalk Batch Server and FactoryTalk Batch View — the Application Programming Interface (API). It is a reference for those who want to develop custom interfaces.

The API is the interface between the FactoryTalk Batch Server and FactoryTalk Batch View or a custom user interface application. The server API allows collection of batch control system information and commands the server to take some action.

Tip: The interface between the FactoryTalk Batch Server and Phase is documented in the FactoryTalk Batch PCD Programmer Technical Reference Guide.

The two basic components of the server API are:

• Items - An item is a named data structure accessed using the GetItem method.

• Executes - An execute is a command to the FactoryTalk Batch Server to perform some action.

Chapter 1 FactoryTalk Batch Server API introduction


This diagram depicts the relationships between the various components of a FactoryTalk Batch system. The Component Object Model (COM) or Distributed Component Object Model (DCOM) protocol is used between FactoryTalk Batch View and the server. Use the COM or DCOM protocol between the FactoryTalk Batch Server and a custom user interface.

See also

Move from DDE to COM on page 11

COM protocol on page 12

FactoryTalk Batch Server API introduction Chapter 1


Applications that use Dynamic Data Exchange (DDE) to interact with the FactoryTalk Batch Server upgraded to work with FactoryTalk Batch 10.xx or higher must modify the parsing program. Data returned from the server through the Component Object Model (COM) interface parses differently than the data returned through the DDE interface. When using the DDE interface, the server places a space between delimiters. When using the COM interface, the server does not put a space between two consecutive delimiters.

For example, issuing a request for the DataServersList item could return:

• DDE Interface OPC_SIM \t STANDARD \t LOCAL \t <sp> \t OPC \t {3203642A-F66D-11d1-AD6C-00A024386728} \t PHASES \t WATCHDOG \t <sp> \t <sp> \t <sp> \t <sp> \crlf

• COM Interface OPC_SIM \t STANDARD \t LOCAL \t \t OPC \t {3203642A-F66D-11d1-AD6C-00A024386728} \t PHASES \t WATCHDOG \ t \t \t \t \crlf

Address the new way in which the data returns from the server within the parsing logic. If the application was written in Visual Basic, address the new parsing requirement by using the Split method. Pass the return string to the Split method creating an array with the number of elements equaling the number of fields in the string.

See also

FactoryTalk Batch Server API introduction on page 9

Move from DDE to COM



The Component Object Model (COM) interface allows programmers and system integrators to build applications to command the FactoryTalk Batch Server and read information from the server. The COM interface builds on the set of data items and execute commands in the server API. The COM interface allows Visual Basic and C/C++ programmers to use COM or Distributed Component Object Model (DCOM) as the inter-process communications protocol. Additionally, this interface allows a synchronous programming model.

The typical FactoryTalk Batch Server and BatchRemote objects user is a Visual Basic programmer either writing a custom Visual Basic program or using a scripting language embedded within a third-party application.

See also

Properties, methods, and events on page 12

BatchServer object on page 13

BatchRemote object on page 14

An object is a combination of code treated as a unit, such as a control, form, or application. Each object is defined by a class, and the FactoryTalk Batch library provides two object classes, BatchControl.BatchServer and BatchRemote.RemoteSupport.

• A property is a named attribute of an object. Properties define object characteristics such as size, color, and screen location, or they can define the state of an object, such as enabled or disabled.

• A method is a procedure that acts upon an object.

• An event is an action recognized by an object, such as clicking the mouse or pressing a key, for which written code responds. Events can occur as the result of a user action or program code, or can be triggered by the control. There are no events in this particular interface.

See also


COM protocol

Properties, methods, and events



The BatchServer object provides the mechanism used to interact with the FactoryTalk Batch Server by sending execute commands and retrieving data items. The BatchServer object represents the same interface the Batch ActiveX Controls Library uses for interacting with the FactoryTalk Batch Server. Thus, all information exposed from the server application is exposed through this interface.

Within a Visual Basic script, a user must dimension a BatchServer object in order to use the object’s methods and property. This does not start a new instance of the server, but instead represents a new connection to an existing server. Therefore, the server must be running before the user can dimension a new BatchServer object.

The BatchServer object is a simple object in that it exposes only two methods and a single property. These methods are GetItem and Execute. These map directly to the items and executes documented within this manual. Retrieve any item referenced in this manual through the GetItem method on the BatchServer object. Also, send any execute referenced in this manual with the Execute method on the BatchServer object.

See also

Object reference on page 299

BatchServer object



The BatchRemote object and the BatchServer object both provide a mechanism used to interact with the FactoryTalk Batch Server. However, the BatchRemote object provides additional features, allowing easier access to the server from a remote computer. These additional features include the ability to automatically locate the server computer and time out a connection.

Automatically locating a server from a remote client means it is not necessary to specify the server’s computer name. This is especially useful as it allows client applications to be developed in a more generic manner. The server name is written to the Windows registry during a client installation and accessed by the BatchRemote object.

The timing out of a connection allows client applications to specify timeout periods for a call (GetItem or Execute) or for a connection. Distributed Component Object Model (DCOM) may take a significant amount of time to return an error code on a failed network. The BatchRemote object can minimize the time and effort required to implement error handling within the client. The timing out of a connection also provides a means to keep a client from hanging while in a connect or call for an extended period.

Within a Visual Basic script, dimension a BatchRemote object in order to use the object’s methods and properties. Like the BatchServer object, the BatchRemote object exposes only two methods: GetItem and Execute. These map directly to the items and executes that are documented within this manual. Any item referenced in this manual can be retrieved through the GetItem method on the BatchRemote object. Any execute referenced in this manual can be sent through the Execute method on the BatchRemote object.

In order to use the BatchRemote object, add the Batch Server Remote 1.0 Type Library to the Visual Basic project.

Tip: The FactoryTalk Batch Server application includes the BatchServer object, the Batchsvr.exe file. The BatchRemote object is in the Batchrem.dll file. Both files are located in the \Bin subdirectory where FactoryTalk Batch installs. A type library, Batchsvr.tlb, installs with the server and can be loaded as a reference in Visual Basic. For more information on how to reference an ActiveX object in a Visual Basic project, see the Microsoft Visual Basic Programmer's Guide. Additionally, a header file, Batchsvr.h, used for C or C++ programming installs with the server.

See also


BatchRemote object



List of all supported items in the FactoryTalk Batch Server API:

Item Description

BadTagCount Number of tags, phases, and equipment operation sequences on which verification failed.

BatchList Listing of all created batches.

BatchListCt Batch list count.

BatchOverrides Returns the number of Parameter Expression Overrides currently in effect for each batch on the batch list.

BLBatchID_x Identifier for a batch.

BLCMDMask_x Command mask for a batch.

BLCreateID_x Create identifier for a batch.

BLDesc_x Description for a batch.

BLFailure_x Highest priority failure message for a batch.

BLMode_x Mode for a batch.

BLRecipe_x Recipe for a batch.

BLStartTime_x Start time for a batch.

BLState_x State for a batch.

BLType_x Type for a batch.

COMClientCount Number of COM clients connected to the FactoryTalk Batch Server.

CPRVersion CPR version of the FactoryTalk Batch Server.

CreateIDBatchStepDataList List of all steps in a recipe.

CreateIDBatchStepDataList2 List of all steps in a recipe (allows displaying of override status of a parameter).

CreateIDEventData Most recent data for a batch.

CreateIDEventDataFile Name of a batch data file.

CreateIDScale Scale factor for a batch.

DataServersList Information about all of the data servers defined for the equipment database.

DataServerStatistics Detailed description of each configured data server conversation and the status of each conversation.

DDEClientCount Number of DDE clients connected to the FactoryTalk Batch Server.

DecimalSeparator Decimal symbol used by the FactoryTalk Batch Server.

Domains List of the domain names available for authenticating users attempting signoffs on signature requests.

EnumSetEnumSet List of enumerations within a specified enumeration set.

EquipmentModel Path and file name of the equipment model in use.

EquipmentModelDate Date of the equipment model in use.

ErrorMessage Most recent severe message in the server’s log file.

EventDataFiles List of event data fields in the system.

ExpressionIDParamExprValues Current expression values for each term in the expression.

ExpressionIDReportExprValues Current expression values for each term in a report expression.

ExpressionID_UnitID_Values Current expression value and all of its leaf node values for a given expression or unit association.

Available items



Item Description

HyperlinkLabels Tab-delimited list of hyperlink labels for each equipment type.

IncompleteSignaturesCt Count of all incomplete signature requests, excluding those generated by private interfaces.

InfoMessage Most recent information message in the server’s log file.

ItemCount Number of items created by the FactoryTalk Batch Server that are exposed through DDE and COM.

JournalDir Path to the journals directory.

ListSeparator List separator used by the FactoryTalk Batch Server, as read from Control Panel > Regional Options.

Locale Locale identifier (language ID and code page) used by the FactoryTalk Batch Server, as read from the Control Panel.

MatSvrStatus List of all phases in the system.

OPCClientCount Number of OPC clients connected to the FactoryTalk Batch Server.

OperationDataList Information about all of the equipment operation sequences in the system.

OperationErrs List of all the equipment operation sequences that are currently in failure or have an error.

OperationErrsCt Count of the equipment operation sequences errors or failures.

PhaseDataList Information about all of the phases in the system.

PhaseErrs List of all phases currently in failure or have an error.

PhaseErrsCt Count of the phase errors or failures.

PhaseIDBatchID Information where a batch phase belongs.

PhaseIDFailure Phase failure for the specified phase.

PhaseIDInfo Name of the specified phase.

PhaseIDMessage Last phase message logged into the event journal for the specified phase.

PhaseIDOwnerFlag Current owner of the specified phase.

PhaseIDParms All parameters for the specified phase.

PhaseIDParms2 All parameters for the specified phase including parameter limits and report limits.

PhaseIDPause Pause attribute for the specified phase or equipment operation sequence.

PhaseIDPausing Pausing attribute for the specified phase or equipment operation sequence.

PhaseIDPhaseData Status information for the specified phase or equipment operation sequence.

PhaseIDPhaseData2 Status information for the specified phase or equipment operation sequence including a field for storing automatic pauses at each sequence transition (sequence program) or breakpoint (the PPD Instruction in a phase program).

PhaseIDRequests Request value for the specified phase.

PhaseIDSS Single-step flag for the specified phase or equipment operation sequence.

PhaseIDState State of the specified phase or equipment operation sequence.

PhaseIDStepIndex Returns the current step index for the specified phase.

PhaseIDUnit Current unit for the specified phase or equipment operation sequence.

PhasesList List of all phases, corresponding equipment IDs, and valid units.

PhasesList2 List of all equipment phases, corresponding equipment IDs, recipe phases, the phase type and valid units.



Item Description

PhasesList3 List of all equipment phases, corresponding equipment IDs, recipe phases, phase types, bitmap files, and valid units.

ProcedureIDData Graphical data for an SFC.

ProcedureIDData2 Graphical data for an SFC, including transition names and comment information.

ProcedureIDData3 Graphical data for an SFC, including transition names and comment information. This item supports parameter and report expressions.

ProcedureIDDevLimits Recipe report parameters for a procedure.

ProcedureIDStatus Status data for an SFC.

ProcedureIDStatus2 Status data for an SFC to support showing the status of report and parameter expressions.

ProcedureIDUnitRequirements Set of unit requirements configured within the specified recipe structure.

ProcessCellBitMaps Bitmap index for all process cells within the system.

ProcessCellIDUnits Information about all units in a process cell.

ProcessCellsList List of process cells in the current area.

ProcessCellsList2 List of process cells in the current area, including the process cell class name.

RecipeDir Path to the recipe directory.

RecipeList Recipe information for all recipes released to production.

ResourceIDEqData Tag status information for all tags associated with the phase and state machine information to indicate the current status of the phase.

ResourceIDHyperlinks Tab-delimited list of hyperlinks configured in the area model for the equipment element identified by the resource ID.

ResourceIDInfo Resource name denoted by the resource ID.

ResourceIDOwned List of all resources and corresponding IDs currently owned by the operator.

ResourceIDOwners List of all resource owners and the corresponding owner IDs.

ResourceIDRequested List of all resources requested by the operator.

ResourceIDRequesters List of all resource requesters and the corresponding owner IDs.

ResourceIDStrings List of the cross invocation strings associated with the resource specified by the resource ID.

ResourcesList List of all resources and corresponding equipment IDs.

ResourcesListX List of all resources and corresponding equipment IDs.

RunMode Indicator of whether the server is running in demo or production mode.

RunWithoutMatSvr Time stamp when the Material Server started.

SignatureIDSig Information for individual signature requests, excluding those generated by private interfaces.

Signatures List of all outstanding signature requests, excluding those generated by private interfaces.

StartTime Time stamp of when the FactoryTalk Batch Server started.

StepsList List of all dynamic owners (control recipes) and owner IDs.

StringLabels Labels used for the generic strings.

TagVerStatus Internationalized string indicating the current state of the tag verification process.

TagVerStatusOrd Current state of the tag verification process.

ThousandsSeparator Thousands separator used by the FactoryTalk Batch Server as read from the Control Panel.



Item Description

Time Current time from the FactoryTalk Batch Server and the conversation status of the data servers.

Time2 Current time from the FactoryTalk Batch Server and the most severe conversation status of all defined data servers.

TimerSteps Retrieves retrieves selected information about all of the timer steps currently on the batch list.

TimerIDTimerData Retrieves information about the selected static information for a timer step on the batch list.

TimerIDTimerStatus Retrieves dynamic information about a specific timer step.

TotalTagCount Total number of tags, phases, and equipment operation sequences configured in the equipment database.

UEArea_x Unacknowledged prompt area.

UEBatchID_x Unacknowledged prompt batch ID.

UEDefault_x Default value for the xth unacknowledged event in the unacknowledged event list.

UEDesc_x Unacknowledged prompt description.

UEEU_x Unacknowledged prompt engineering units.

UEEvent_x Unacknowledged prompt event type.

UEEventID_x Unacknowledged prompt event ID.

UEHigh_x Unacknowledged prompt high.

UELow_x Unacknowledged prompt low.

UEPhase_x Unacknowledged prompt phase.

UEProcCell_x Unacknowledged prompt process cell.

UERecipe_x Unacknowledged prompt recipe.

UERespType_x Unacknowledged prompt response type.

UETime_x Unacknowledged prompt time.

UEUnit_x Unacknowledged prompt unit.

UEValue_x Unacknowledged prompt value.

UnAcknowledgedEvents List of unacknowledged prompts.

UnacknowledgedEventsCt Unacknowledged prompt count.

UnitBitMaps Bitmap index for all units.

UnitIDBatchID Operator entered batch ID for a batch running in the specified unit.

UnitIDOperations List of all the equipment operation sequences within the specified unit.

UnitIDPhaseBitmaps List of filenames for the bitmaps within the unit.

UnitIDPhases List of all the phases within the specified unit.

UnitIDPhases2 List of all the phases within the specified unit, including whether or not there is an associated control strategy.

UnitIDUnitTagData Unit name, unit class, and tag status information for the specified unit.

UnitReqIDBindingPreferences Set of binding preferences configured on the specified unit requirement.

UnitReqIDBindingRequirements Set of binding requirements configured on the specified unit requirement.

UnitsList List of all units, corresponding equipment IDs, and unit classes.

VerifiedTagCount Total number of verified tags, phases, and equipment operation sequences. This total includes tags, phases, and equipment operation sequences that were successfully verified and those that failed verification.



Item Description

Version Server software version.

WarningMessage Most recent warning message in the FactoryTalk Batch Server log file.

See also


Item reference on page 23

List of all supported executes in the FactoryTalk Batch Server API:

EXECUTE DESCRIPTION

Ack Acknowledges a prompt.

Acquire Acquires a resource for the operator.

AddEvent Adds an event to all active event journals based on the BatchID.

AddEvent_CI Adds a single event to the event journal based on the CreateID.

AddEvent_Instruction Appends an event associated with an eProcedure control step in an electronic batch record from an external application.

AddEvent_Phase Appends an event in FactoryTalk Batch to an external application.

Archiver Starts the Archiver application.

AutoBatchID_Info Returns the BatchID from a call to BatchIDCreation.

AutoRemove Tells the server to automatically remove a batch.

Batch Creates a new batch (control recipe).

Bind Binds a unit to a step within a control recipe.

BindPhase Rebinds a step from its current phase to a new phase and optionally a new container.

CancelSignature Cancels a signature request on an incomplete signature (except for those generated by private interfaces).

Command Sends a command to a batch or procedure.

ControlStrategy Returns a list of control strategies configured for the specified phase.

Enum Obtains the enumeration sets defined in FactoryTalk Batch Equipment Editor.

Expression Obtains the transition data from the server.

ForceTransition Forces a transition to fire when the only thing preventing it from firing is a TRUE evaluation of its transition expression.

GetContainerData Obtains a list of container and lot data specifying what phase may be bound to for manually binding a material-enabled phase step.

GetFeedTypeAndMaterials Obtains a list of feed types and materials supported by the phase.

GetLegalEqModules Obtains a list of phase - container - lot entries to be considered for manually binding or rebinding a phase step.

GetLegalUnits Obtains a list of units to which the step may be bound.

GetPossibleLegalUnits Retrieves the possible binding options for a non-statically bound unit procedure or operation.

Info Obtains information about a recipe.

Info2 Obtains information about a recipe.

Available executes



EXECUTE DESCRIPTION

InfoTrimmed Retrieves the information necessary for the formatting of a Batch execute that would be used to instantiate a batch.

MatSvrControl Reestablishes communication with the Material Server.

Messages Obtains a list of the messages associated with a particular phase.

Mtrl_Info Returns the information necessary to allow a selection of material for a Material Server phase written as material class-based.

Order Reorders the requesters list for a resource.

ParamExpClear Allows removal of an override of a specified expression that was created by a prior ParamExpOverride execute.

ParamExpOverride Overrides the result of a parameter expression evaluation with a specified value.

Parms Obtains the parameters for a procedure.

Parms2 Obtains the parameters for a procedure with the addition of the parameter limits.

Phase Commands a phase or equipment operation sequence to a desired state.

Phase2 Commands a phase associated with a control strategy to a desired state. This execute cannot be used with an equipment operation sequence.

Phase3 Commands a phase or equipment operation sequence to a desired state including phases that may be material-enabled or control strategy and material-enabled.

ReactivateStep Commands the FactoryTalk Batch Server to journal a Step_Reactivation Request event.

RecipeList Obtains information about the recipes from FactoryTalk Batch Recipe Editor.

Release Releases the resource from the operator.

Remove Removes a batch from the batch list.

SetAllLabel Sets the same label on all material phase steps within a recipe.

SetAllLot Sets the lot controller ID on a material phase step.

SetParm Sets the parameter values in a control recipe.

SignoffSignature Signs a signature request on an incomplete signature, excludes those generated by private interfaces.

Step Changes the active step in a procedure.

Tag_Verify Initiates or aborts the tag verification process. Tags include phase tags (OPC tags), unit attribute tags, and backing tags for each phase and equipment operation sequence.

User_Verify Determines if the password provided for a user is correct.

See also


Execute reference on page 217



These documents contain additional information concerning related Rockwell Automation products.

Resource Description

FactoryTalk Batch Administrator Guide Instructions for configuring security and services, and implementation and use of components not normally accessed or used by batch operators, such as the FactoryTalk Batch Server, Simulator, and performance chart.

FactoryTalk Batch PCD Programmer Technical Reference Guide

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

View or download publications at http://www.rockwellautomation.com/literature. To order paper copies of technical documentation, contact the local Rockwell Automation distributor or sales representative.

Additional resources



Chapter 2

Item reference

An item is a named data structure accessed using any data access technology supported by the FactoryTalk Batch Server like the custom COM interface GetItem method or through OPC.

Tip: Some data returned with a request are localized. States and modes, as well as most information in the event journal are localized, based upon the language selected in the Control Panel. Time and date formats are based upon the system’s International settings.

The formatting methods used for each of the items:

Item Description

Input Format Describes the COM/DCOM method used to obtain this item (REQUEST). Use this format: object.GetItem ItemName. For example: object.GetItem(BatchList).

Output Format

Describes the data returned and the format displayed. All data returns in CFTEXT format, representing either strings or integers. A list of the key characters and what they symbolize follows:

<TEXT> is Denotes a variable to define.

TEXT is Any text that is not enclosed in the < > characters is a keyword and appears as the literal string.

<NullString> is Denotes an empty string, Cstring.Empty ( ), unless otherwise specified.

\t is Denotes a Tab character (ASCII - 9) used as a field delimiter. A space before and after the \t is included for readability, do not include the spaces when formatting the command line.

| is Used to denote an OR situation. Only one segment of the statement is used. For example, A | B | C \t D \crlf would indicate: A or B or C \t D \crlf.

\crlf is Denotes a carriage return (ASCII - 13) and a line feed (ASCII - 10) character used as a record delimiter.

<sp> blank is Denotes a space character (ASCII – 32).

<CmdMask> is Command masks

<ArbMask> is Arbitration masks

Example: Defines an example for the REQUEST statement: Input statement Output statement

See also

Command masks on page 309

Arbitration masks on page 316

Chapter 2 Item reference


The BadTagCount item returns an integer indicating the number of tags, phases, and equipment operation sequences on which verification failed.

The following table shows the input and output formats for this item.

Input Format Request: BadTagCount

Output Format The BadTagCount item returns in this format: <Count>

Field Name Format Description

<Count> ASCII - Integer Total number of tags, phases, and equipment operation sequences that failed verification.

The following table shows an example of the return on this request.

Example: A request on object.GetItem(BadTagCount) could return: 2

See also


The BatchList item returns a list of all batches in the system.


Input Format Request: BatchList

Output Format The BatchList item returns in this format:

<BatchList> is <NullList> | <BList>

<BList> is <Batch> \crlf | <Batch> \crlf <BList>

<Batch> is <BatchID> \t <RecipeName> \t <BatchDesc> \t <StartTime> \t <ElapsedTime> \t <State> \t <Mode> \t <Failures> \t <CreateID> \t <CmdMask> \t <BatchType> \t <ProcCellList> \t <UnitList> \t <PhaseList>

where <Batch> is:


<BatchID> ASCII - String Operator-entered batch identification number.

<RecipeName> ASCII - String Procedure identifier from FactoryTalk Batch Recipe Editor.

<BatchDesc> ASCII - String Procedure description from FactoryTalk Batch Recipe Editor.

<StartTime> ASCII - String Starting time for the batch, formatted according to Control Panel. May be a single space character.

<ElapsedTime> ASCII - String Time elapsed since batch started. If batch has not yet, started zero length string returns: 0:00:00.

<State> ASCII - String Current state of the batch. (Localized)

<Mode> ASCII - String Current mode of the recipe. (Localized)

<Failures> ASCII - String Describes failure message.

<CreateID> ASCII - Integer Unique batch ID assigned by the FactoryTalk Batch Server.

BadTagCount

BatchList

Item reference Chapter 2


<CmdMask> ASCII - Integer Command masks

<BatchType> ASCII - Integer Type of control: 1 = Recipe 2 = Manual Phase control

<ProcCellList> Variable Process Cell(s) in which batch is running.

<UnitList> Variable Unit(s) in which batch is running.

<PhaseList> Variable List of active phases in the recipe at this time.

where <ProcCellList> is:

<ProcCellList> is <NullList> | <PCList>

<NullList> is $PRCL \t <sp> $END

<PCList> is $PRCL \t <ProcessCells>\t $END

<ProcessCells> is <PCellName> | <PCellName> \t <ProcessCells>

where:


<PCellName> ASCII - String Procedure cell’s name

where <UnitList> is:

<UnitList> is <NullList> | <UList>

<NullList> is $UNIT \t <sp>$END

<UList> is $UNIT \t <Units>\t $END

<Units> is <UnitName> | <UnitName> \t <Units>

where:


<UnitName> ASCII - String Unit’s Name

where <PhaseList> is:

<PhaseList> is <NullList> | <PHList>

<NullList> is $PHASE \t <sp> $END

<PHList> is $PHASE \t <Phases> \t $END

<Phases> is <PhaseName> | <Phasename> \t <Phases>

where:


<PhaseName> ASCII - String Phase’s Name




Example: A request on the object.GetItem(Batchlist) could return: BATCH_98 \t CLS_FRENCHVANILLA \t FRENCH VANILLA PREMIUM - CLASS BASED \t \t 0:00:00 \t READY \t O_AUTO \t \t 15 \t 18976 \t 1 \t $PRCL \t SOUTH_PARLOR \t $END \t $UNIT \t SP_MIXER1 \t SP_FREEZER1 \t $END \t $PHASE \t $END \crlf BATCH_99 \t CLS_FRENCHVANILLA \t FRENCH VANILLA PREMIUM - CLASS BASED \t \t 0:00:00 \t READY \t O_AUTO \t \t 16 \t 18976 \t 1 \t $PRCL \t SOUTH_PARLOR \t $END \t $UNIT \t SP_MIXER1 \t SP_FREEZER1 \t $END \t $PHASE \t $END \crlf BATCH_100 \t MCLS_FRENCHVANILLA \t FRENCH VANILLA PREMIUM - CLASS BASED/MATERIAL BASED \t \t 0:00:00 \t READY \t O_AUTO \t \t 17 \t 18976 \t 1 \t $PRCL \t NORTH_PARLOR \t $END \t $UNIT \t NP_MIXER2 \t NP_FREEZER2 \t $END \t $PHASE \t $END \crlf

See also



The BatchListCt item returns the number of batches in the batch list.


Input Format Request: BatchListCt

Output Format The BatchListCt item returns in this format: <NumberBatches>


<NumberBatches> ASCII – Integer Number of batches currently in the batch list.


Example: A request on object.GetItem(BatchListCt), assuming there are three batches on the batch list, could return:

3

See also


BatchListCt



The BatchOverrides item returns the number of parameter expression overrides currently in effect for each batch on the batch list.


Input Format Request: BatchOverrides

Output Format The BatchOverrides item returns in this format:

<Statistics > is <NullList> | <OverridesList>

<OverridesList> is <OverrideRecord> | <OverrideRecord> <OverridesList>

<OverrideRecord> is <CreateID> \t <NumOverrides>\crlf


<CreateID> ASCII – String Integer, INTERNAL identifier assigned by the FactoryTalk Batch Server to a batch when created. Obtained from the BatchList item.

<NumOverrides> ASCII - String Number of overrides in effect for the batch with this CreateID


Example: A request on object.GetItem(BatchOverrides) could return: 14 \t 3 \crlf 15 \t 0 \crlf 16 \t 5 \crlf

See also


The BLBatchID_x item returns the batch ID for the xth batch in the batch list.


Input Format Request: BLBatchID_<RowNumber>

<RowNumber> is ASCII - Integer An array index. When an unacknowledged prompt generates, it adds to an array. If the unacknowledged prompts list is not sorted, then x is the row number of the unacknowledged prompt appearing in the unacknowledged prompts list.

The BLBatchID_x item requires the batchsvr.ini file to contain this setting in the [CLIENT MGR DDE] section: MaxBatchTableLength = n where n is the maximum number of batches accessible to this Item (the maximum number of entries in the array). If the number of batches in the batch list is larger than n, then this item will only access the first n batches in a non-sorted batch list. When a batch with an index of less than n is removed from the batch list, all subsequent batches will have their index decreased by one. The default value of MaxBatchTableLength is 0 (zero).

BatchOverrides

BLBatchID_x



Output Format The BLBatchID_x item returns in this format: <BatchID>


<BatchID> ASCII – String Identifier for the batch assigned by the operator during batch creation to the batch appearing on the xth row of the batch list.

This table is a typical batch list containing three batches with batch IDs BATCH_98, BATCH_99, and BATCH_100:

Batch ID Recipe Desc Start Time State Mode

BATCH_98 Vanilla Ice Cream 1 2/24/2017 1:22:02 pm RUNNING O_Auto

BATCH_99 Chocolate Ice Cream 2 2/24/2017 1:24:12 pm RUNNING S_Auto

BATCH_100 Premium French Vanilla

Ice Cream 3 2/24/2017 1:32:30 pm RUNNING O_Auto


Example: A request on object.GetItem(BLBatchID_3) returns the batch ID of the batch in the batch list’s third row: BATCH_100

See also


The BLCMDMask_x item returns the command mask for the xth batch in the batch list. The command mask is a binary value (passed as an integer) whose bits represent the current set of valid commands this batch can receive.


Input Format Request: BLCMDMask_<RowNumber>


The BLCMDMask_x item requires the batchsvr.ini file to contain this setting in the [CLIENT MGR DDE] section: MaxBatchTableLength = n where n is the maximum number of batches accessible to this Item (the maximum number of entries in the array). If the number of batches in the batch list is larger than n, then this item will only access the first n batches in a non-sorted batch list. When a batch with an index of less than n is removed from the batch list, all subsequent batches will have their index decreased by one. The default value of MaxBatchTableLength is 0 (zero).

Output Format The BLCMDMask_x item returns in this format: <CMDMask>


<CmdMask> ASCII – Integer Current set of valid commands that may be sent to the batch appearing on xth row of the batch list.

BLCMDMask_x



This table is an example of a typical batch list containing three batches with batch IDs BATCH_98, BATCH_99, and BATCH_100:







Example: A request on object.GetItem(BLCMDMask_3) would return the command mask of the batch in the batch list’s third row:

2087

See also


The BLDesc_x item returns the description for the xth batch in the batch list.


Input Format Request: BLDesc_<RowNumber>


The BLDesc_x item requires the batchsvr.ini file to contain this setting in the [CLIENT MGR DDE] section: MaxBatchTableLength = n where n is the maximum number of batches accessible to this Item (the maximum number of entries in the array). If the number of batches in the batch list is larger than n, then this item will only access the first n batches in a non-sorted batch list. When a batch with an index of less than n is removed from the batch list, all subsequent batches will have their index decreased by one. The default value of MaxBatchTableLength is 0 (zero).

Output Format The BLDesc_x item returns in this format: <Description>


<Description> ASCII – String Description of the batch appearing on xth row of the batch list. The description is taken from the recipe’s header data.

BLDesc_x










Example: A request on object.GetItem(BLDESC_3) would return the description of the batch in the batch list’s third row:

Ice Cream 3

See also




The BLFailure_x item returns the failure message for the xth batch in the batch list. This is the highest priority failure message for the steps running within the recipe.


Input Format Request: BLFailure_<RowNumber>


Output Format The BLFailure_x item returns in this format:<Failure>


<Failure> ASCII – String Failure message for the batch appearing on xth row of the batch list.


Batch ID Recipe Desc Start Time State Failure

BATCH_98 Vanilla Ice Cream 1 2/24/2017 1:22:02 pm RUNNING

BATCH_99 Chocolate Ice Cream 2 2/24/2017 1:24:12 pm RUNNING


Ice Cream 3 2/24/2017 1:32:30 pm RUNNING PHASE UNDER EXTERNAL CONTROL DETECTED


Example: A request on object.GetItem(BLFailure_3) would return the failure field of the batch in the batch list’s third row: PHASE UNDER EXTERNAL CONTROL DETECTED

See also


BLFailure_x



The BLMode_x item returns the mode for the xth batch in the batch list.


Input Format Request: BLMode_<RowNumber>


The BLMode_x item requires the batchsvr.ini file to contain this setting in the [CLIENT MGR DDE] section: MaxBatchTableLength = n where n is the maximum number of batches accessible to this Item (the maximum number of entries in the array). If the number of batches in the batch list is larger than n, then this item will only access the first n batches in a non-sorted batch list. When a batch with an index of less than n is removed from the batch list, all subsequent batches will have their index decreased by one. The default value of MaxBatchTableLength is 0 (zero).

Output Format The BLMode_x item returns in this format: <Mode>


<Mode> ASCII – String Current mode of the batch appearing on xth row of the batch list.








Example: A request on object.GetItem(BLMode_3) would return the mode of the batch in the batch list’s third row:

O_AUTO

See also

Valid states and modes on page 317

BLMode_x



The BLRecipe_x item returns the recipe for the xth batch in the batch list.


Input Format Request: BLRecipe_<RowNumber>


The BLRecipe_x item requires the batchsvr.ini file to contain this setting in the [CLIENT MGR DDE] section: MaxBatchTableLength = n where n is the maximum number of batches accessible to this Item (the maximum number of entries in the array). If the number of batches in the batch list is larger than n, then this item will only access the first n batches in a non-sorted batch list. When a batch with an index of less than n is removed from the batch list, all subsequent batches will have their index decreased by one. The default value of MaxBatchTableLength is 0 (zero).

Output Format The BLRecipe_x item returns in this format: <RecipeName>


<RecipeName> ASCII – String Name of the batch appearing on xth row of the batch list.








Example: A request on object.GetItem(BLRecipe_3) would return the recipe name of the batch in the batch list’s third row:

Premium French Vanilla

See also


BLRecipe_x



The BLStartTime_x item returns the start time for the xth batch in the batch list.


Input Format Request: BLStartTime_<RowNumber>


The BLStartTime_x item requires the batchsvr.ini file to contain this setting in the [CLIENT MGR DDE] section: MaxBatchTableLength = n where n is the maximum number of batches accessible to this Item (the maximum number of entries in the array). If the number of batches in the batch list is larger than n, then this item will only access the first n batches in a non-sorted batch list. When a batch with an index of less than n is removed from the batch list, all subsequent batches will have their index decreased by one. The default value of MaxBatchTableLength is 0 (zero).

Output Format The BLStartTime_x item returns in this format: <Time>


<Time> ASCII – String Start time, formatted according to Windows internationalization and locality settings, of the batch appearing on xth row of the batch list.

This table is an example of a typical Batch List containing three batches with batch IDs BATCH_98, BATCH_99, and BATCH_100:







Example: A request on object.GetItem(BLStartTime_3) would return the start time of the batch in the batch list’s third row:

2/24/2017 1:32:30 pm

See also


BLStartTime_x



The BLState_x item returns the State field for the xth batch in the batch list.


Input Format Request: BLState_<RowNumber>


The BLState_x item requires the batchsvr.ini file to contain this setting in the [CLIENT MGR DDE] section: MaxBatchTableLength = n where n is the maximum number of batches accessible to this Item (the maximum number of entries in the array). If the number of batches in the batch list is larger than n, then this item will only access the first n batches in a non-sorted batch list. When a batch with an index of less than n is removed from the batch list, all subsequent batches will have their index decreased by one. The default value of MaxBatchTableLength is 0 (zero).

Output Format The BLState_x item returns in this format: <State>


<State> ASCII – String Current state of the batch appearing on xth row of the batch list.








Example: A request on object.GetItem(BLState_3) would return the state field of the batch in the batch list’s third row:

RUNNING

See also


BLState_x



The BLType_x item returns the type for the xth batch in the batch list, recipe, or manual phase control.


Input Format Request: BLType_<RowNumber>


The BLType_x item requires the batchsvr.ini file to contain this setting in the [CLIENT MGR DDE] section: MaxBatchTableLength = n where n is the maximum number of batches accessible to this Item (the maximum number of entries in the array). If the number of batches in the batch list is larger than n, then this item will only access the first n batches in a non-sorted batch list. When a batch with an index of less than n is removed from the batch list, all subsequent batches will have their index decreased by one. The default value of MaxBatchTableLength is 0 (zero).

Output Format The BLType_x item returns in this format: <Type>


<Type> ASCII – String Type of the batch appearing on xth row of the batch list. • 1 = Recipe

• 2 = Manual Phase Control


Batch ID Recipe Desc State Mode Type (not displayed in the Batch List view)

BATCH_98 Vanilla Ice Cream 1 RUNNING O_Auto Recipe

BATCH_99 Chocolate Ice Cream 2 RUNNING S_Auto Manual Phase Control

BATCH_100 Premium French Vanilla Ice Cream 3 RUNNING O_Auto Recipe


Example: A request on object.GetItem(BLType_3) would return the batch type in the third row of the batch list:

1 A request on object.GetItem(BLType_2) would return the batch type in the second row of the batch list:

2

See also


BLType_x



The COMClientCount item returns the number of COM clients connected to the FactoryTalk Batch Server.


Input Format Request: COMClientCount

Output Format The COMClientCount item returns in this format: <COMCount>


<COMCount> ASCII – String Number of COM clients connected to the FactoryTalk Batch Server.


Example: A request on object.GetItem(COMClientCount) could return: 3

See also


The CPRVersion item returns data describing the CPR version of the FactoryTalk Batch Server.


Input Format Request: CPRVersion

Output Format The CPRVersion item returns in this format: <CPR Number>

where:


<CPR Number> ASCII -Integer CPR number for the release containing this FactoryTalk Batch Server version.


Example: A request on object.GetItem(CPRVersion) could return: 9

See also


COMClientCount

CPRVersion



The CreateIDBatchStepDataList item returns a list of all the steps in a recipe batch, and each step’s status.


Input Format Request: CreateIDBatchStepDataList

CreateID is ASCII – Integer, INTERNAL identifier assigned by the FactoryTalk Batch Server to a batch when it is created. Obtained from the BatchList item.

Output Format The CreateIDBatchStepDataList item returns in this format:

<BSList> is <NullList> | <StepList>

<StepList> is <Step> \crlf | <Step> \crlf <StepList>

<Step> is <ID> \t <Name> \t <SP88Type> \t <KeyPName> \t <KeyValue> \t <State> \t <Mode> \t <UnitName> \t <Control> \t <Index> \t <Paused> \t <Msg> \t <Rqst> \t <Fail> \t <ParmList> \t <RepParmList> \t <OwnerID> \t <OwnerName> \t <CmdMask>

where:


<ID> ASCII - Integer Element ID (defined by ProcedureIDData item)

<Name> ASCII - String Element Name

<SP88Type> ASCII - Integer Step type: • 0 = Null

• 1 = Procedure

• 2 = Unit Procedure

• 3 = Operation

• 4 = Phase

<KeyPName> ASCII - String Key Parameter Name: may contain a single space if the step does not have a key parameter value.

<KeyValue> ASCII - String Step’s Key Value: may contain a single space if the step does not have a key parameter value.

<State> ASCII - String Element State

<Mode> ASCII - String Step’s Mode: • O-AUTO

• P-AUTO

• S-AUTO

• MANUAL

• UNKNOWN

<UnitName> ASCII - String Unit under which the Step runs.

CreateIDBatchStepDataList



<Control> ASCII - String Who controls the Step: • NONE

• PROGRAM

• EXTERNAL

This field may contain a single space character if the step is not an active recipe element.

<Index> ASCII - Integer Step Index: the value may be a single-space character if the step is not an active recipe element.

<Paused> ASCII - Integer Indicates if the step is Paused.

• 0 = False

• 1 = True

Only a Phase can have Paused = True. All others are False.

<Msg> ASCII - String Step Message

<Rqst> ASCII - Integer Step Request, contents of request register

<Fail> ASCII- String Fail Message, single space if not active or no failures

<ParmList> Variable list List of recipe parameters

<RepParmList> Variable list List of report parameters

<OwnerID> ASCII - Integer Element Owner ID, single space if step not of phase

<OwnerName> ASCII - String Owner Name, single space if step not of phase


where <KeyValue> is:

<KeyValue> is <ValueAndEU> | <EquipmentID>

<ValueAndEU> is <DefaultValue> <sp> <EngUnits>

where <ValueAndEU> is:


<EquipmentID> ASCII – String Unique ID corresponding to the step.

<DefaultValue> ASCII – String Default value of display parameter

<EngUnits> ASCII – String Engineering units associated with default value

where <ParmList> is:

<ParmList> is $PARM \t <Parameters> \t $END

<Parameters> is <NullList> | <PList>

<PList> is <Parameter> | <Parameter> \t <PList>

<Parameter> is <ParmName> \t <Value>


<ParmName> ASCII – String Parameter Name

<Value> ASCII – String Current batch value. ??? indicates that there is no value assigned.

where <RepParmList> is:

<RepParmList> is $REPORT \t <Parameters> \t $END



<Parameters> is <NullList> | <RList>

<RList> is <Parameter> | <Parameter> \t <RList>



<ParmName> ASCII – String Report Parameter Name

<Value> ASCII – String Current batch value




Example: The BatchList contains a batch with the CreateID of 21. Use this Request to see a list of steps for this batch: object.GetItem(21BatchStepDataList), which could return:

627 \t BATCH_ID \t 3 \t \t MP_MIXERFREEZER2 \t RUNNING \t O_AUTO \t MP_MIXERFREEZER2 \t PROGRAM \t \t 0 \t \t \t \t $PARM \t \t $END \t $REPORT \t \t $END \t \t \t 2087 \crlf 661 \t MBR_ADD:1 \t 4 \t \t \t \t \t MP_MIXERFREEZER2 \t \t 0 \t \t \t \t \t $PARM \t MATERIAL \t SUGAR_GRANULATED \t AMOUNT \t 800 \t $BINDCONTAINER \t NULL_CONTAINER \t $BINDEQMODULE \t \t $END \t $REPORT \t ACTUAL_AMOUNT \t 700 \t FEED_COMPLETE \t YES \t $END \t \t \t 262144\n662 \t AGITATE:1 \t 4 \t \t \t \t \t MP_MIXERFREEZER2 \t \t 0 \t \t \t \t \t $PARM \t SPEED_RATE \t 5 \t $END \t $REPORT \t MIX_SPEED \t 30 \t $END \t \t \t 0 \crlf 632 \t MBR_ADD:2 \t 4 \t \t \t \t \t MP_MIXERFREEZER2 \t \t 0 \t \t \t \t \t $PARM \t MATERIAL \t EGG_YOLK \t AMOUNT \t 180 \t $BINDCONTAINER \t NULL_CONTAINER \t $BINDEQMODULE \t \t $END \t $REPORT \t ACTUAL_AMOUNT \t 150 \t FEED_COMPLETE \t YES \t $END \t \t \t 262144\n636 \t MBR_ADD:3 \t 4 \t \t \t \t \t MP_MIXERFREEZER2 \t \t 0 \t \t \t \t \t $PARM \t MATERIAL \t CREAM \t AMOUNT \t 2000 \t $BINDCONTAINER \t NULL_CONTAINER \t $BINDEQMODULE \t \t $END \t $REPORT \t ACTUAL_AMOUNT \t 2000 \t FEED_COMPLETE \t YES \t $END \t \t \t 262144 \crlf 660 \t TEMP_CTL:1 \t 4 \t \t \t \t \t MP_MIXERFREEZER2 \t \t 0 \t \t \t \t \t $PARM \t HOLD_TIME \t 5 \t TEMP_SP \t 71.1 \t $END \t $REPORT \t TEMPERATURE \t 0 \t TIME_HELD \t 0 \t $END \t \t \t 0 \crlf 659 \t AGITATE:2 \t 4 \t \t \t \t \t MP_MIXERFREEZER2 \t \t 0 \t \t \t \t \t $PARM \t SPEED_RATE \t 5 \t $END \t $REPORT \t MIX_SPEED \t 30 \t $END \t \t \t 0 \crlf 658 \t MBR_ADD:4 \t 4 \t \t \t \t \t MP_MIXERFREEZER2 \t \t 0 \t \t \t \t \t $PARM \t MATERIAL \t MILK \t AMOUNT \t 2000 \t $BINDCONTAINER \t NULL_CONTAINER \t $BINDEQMODULE \t \t $END \t $REPORT \t ACTUAL_AMOUNT \t 2000 \t FEED_COMPLETE \t YES \t $END \t \t \t 262144\n640 \t AGITATE:3 \t 4 \t \t \t \t \t MP_MIXERFREEZER2 \t \t 0 \t \t \t \t \t $PARM \t SPEED_RATE \t 5 \t $END \t $REPORT \t MIX_SPEED \t 30 \t $END \t \t \t 0 \crlf 644 \t MBR_ADD:5 \t 4 \t \t \t RUNNING \t P_AUTO \t MP_MIXERFREEZER2 \t PROGRAM \t 10 \t 0 \t \t 0 \t \t $PARM \t MATERIAL \t VANILLA \t AMOUNT \t 20 \t $BINDCONTAINER \t TEMPFLAVOR_VANILLA \t $BINDEQMODULE \t MP_ADDFLAVOR_MF2 \t $END \t $REPORT \t ACTUAL_AMOUNT \t \t FEED_COMPLETE \t \t $END \t -1142 \t 21:FRENCH_VANILLAPREMIUM1_MEGA_PARLOR_OPT_1_O1 \t 32 \crlf 657 \t TEMP_CTL:2 \t 4 \t \t \t \t \t MP_MIXERFREEZER2 \t \t 0 \t \t \t \t \t $PARM \t HOLD_TIME \t 5 \t TEMP_SP \t 71.1 \t $END \t $REPORT \t TEMPERATURE \t \t TIME_HELD \t \t $END \t \t \t 0\n648 \t RECIRC:1 \t 4 \t \t \t \t \t MP_MIXERFREEZER2 \t \t 0 \t \t \t \t \t $PARM \t RECIRC_RATE \t 50 \t $END \t $REPORT \t FINAL_RECIRC_RATE \t \t $END \t \t \t 0\n652 \t MBR_DUMP:1 \t 4 \t \t \t \t \t MP_MIXERFREEZER2 \t \t 0 \t \t \t \t \t $PARM \t MATERIAL \t IC_FRENCH_VANILLA \t AMOUNT \t -5000 \t $BINDCONTAINER \t \t $BINDEQMODULE \t \t $END \t $REPORT \t ACTUAL_AMOUNT \t \t FEED_COMPLETE \t \t $END \t \t \t 262144 \crlf

See also





The CreateIDBatchStepDataList2 item returns a list of all the steps in a recipe batch and the step status.


Input Format Request: CreateIDBatchStepDataList2

CreateID is ASCII – Integer, INTERNAL identifier assigned during batch creation. Obtained from the BatchList item.

Output Format The CreateIDBatchStepDataList2 item returns in this format:

<BSList> is <NullList> | <StepList>


<Step> is <ID> \t <Name> \t <SP88Type> \t <KeyPName> \t <KeyValue> \t <State> \t <KeyValueStatus> t\ <Mode> \t <UnitName> \t <Control> \t <Index> \t <Paused> \t <Msg> \t <Rqst> \t <Fail> \t <ParmList> \t <RepParmList> \t <OwnerID> \t <OwnerName> \t <CmdMask>

where:


<ID> ASCII - Integer Element ID (defined by ProcedureIDData item)

<Name> ASCII - String Element Name


• 1 = Procedure

• 2 = Unit Procedure

• 3 = Operation

• 4 = Phase

<KeyPName> ASCII - String Key Parameter Name: may contain a single space if the step does not have a key parameter value.

<KeyValue> ASCII - String Step’s Key Value; may contain a single space if the step does not have a key parameter value.

<KeyValueStatus> ASCII - Integer Step's Key Value Status of an expression: • 0 or blank = OK or not an expression

• 1 = Override

• 2 = Exception

• 3 = Override, Exception

• 4 = Out of Range

• 5 = Override, Out of Range

• 6 = Exception,Out of Range

• 7 = Override, Exception, Out of Range

<State> ASCII - String Element State

CreateIDBatchStep DataList2



<Mode> ASCII - String Step’s Mode: • O-AUTO

• P-AUTO

• S-AUTO

• MANUAL

• UNKNOWN

<UnitName> ASCII - String Unit under which the Step runs.

<Control> ASCII - String Who controls the Step: • NONE

• PROGRAM

• EXTERNAL


<Index> ASCII - Integer Step Index: the value may be a single space character if the step is not an active recipe element.

<Paused> ASCII - Integer Indicates if the step is Paused. • 0 = False

• 1 = True

Only a Phase can have Paused = True. All others are False.


<Rqst> ASCII - Integer Step Request, contents of request register

<Fail> ASCII- String Fail Message, single space if not active or no failures

<ParmList> Variable list List of recipe parameters

<RepParmList> Variable list List of report parameters

<OwnerID> ASCII - Integer Element Owner ID, single space if step not of phase

<OwnerName> ASCII - String Owner Name, single space if step not of phase

<CmdMask> ASCII - Integer Command Masks

where <KeyValue> is:

<KeyValue> is <ValueAndEU> | <EquipmentID>

<ValueAndEU> is <DefaultValue> <sp> <EngUnits>

where <ValueAndEU> is:


<EquipmentID> ASCII – String Unique ID corresponding to the step

<DefaultValue> ASCII – String Default value of display parameter

<EngUnits> ASCII – String Engineering units associated with default value



<Parameters> is <NullList> | <PList>




<Parameter> is <ParmName> \t <Value> \t <Status>


<ParmName> ASCII – String Parameter Name

<Value> ASCII – String Current batch value ??? indicates that there is no value assigned.

<Status> ASCII – String Parameter Status

where <RepParmList> is:

<RepParmList> is $REPORT \t <Parameters> \t $END

<Parameters> is <NullList> | <RList>

<RList> is <Parameter> | <Parameter> \t <RList>



<ParmName> ASCII – String Report Parameter Name

<Value> ASCII – String Current batch value




Example: The BatchList contains a batch with the CreateID of 21. Use this Request to see a list of steps for this batch: object.GetItem(21BatchStepDataList), which could return:

627 \t BATCH_ID \t 3 \t \t MP_MIXERFREEZER2 \t RUNNING \t O_AUTO \t MP_MIXERFREEZER2 \t PROGRAM \t \t 0 \t \t \t \t $PARM \t \t $END \t $REPORT \t \t $END \t \t \t 2087 \crlf 661 \t MBR_ADD:1 \t 4 \t \t \t \t \t MP_MIXERFREEZER2 \t \t 0 \t \t \t \t \t $PARM \t MATERIAL \t SUGAR_GRANULATED \t AMOUNT \t 800 \t $BINDCONTAINER \t NULL_CONTAINER \t $BINDEQMODULE \t \t $END \t $REPORT \t ACTUAL_AMOUNT \t 700 \t FEED_COMPLETE \t YES \t $END \t \t \t 262144\n662 \t AGITATE:1 \t 4 \t \t \t \t \t MP_MIXERFREEZER2 \t \t 0 \t \t \t \t \t $PARM \t SPEED_RATE \t 5 \t $END \t $REPORT \t MIX_SPEED \t 30 \t $END \t \t \t 0 \crlf 632 \t MBR_ADD:2 \t 4 \t \t \t \t \t MP_MIXERFREEZER2 \t \t 0 \t \t \t \t \t $PARM \t MATERIAL \t EGG_YOLK \t AMOUNT \t 180 \t $BINDCONTAINER \t NULL_CONTAINER \t $BINDEQMODULE \t \t $END \t $REPORT \t ACTUAL_AMOUNT \t 150 \t FEED_COMPLETE \t YES \t $END \t \t \t 262144\n636 \t MBR_ADD:3 \t 4 \t \t \t \t \t MP_MIXERFREEZER2 \t \t 0 \t \t \t \t \t $PARM \t MATERIAL \t CREAM \t AMOUNT \t 2000 \t $BINDCONTAINER \t NULL_CONTAINER \t $BINDEQMODULE \t \t $END \t $REPORT \t ACTUAL_AMOUNT \t 2000 \t FEED_COMPLETE \t YES \t $END \t \t \t 262144 \crlf 660 \t TEMP_CTL:1 \t 4 \t \t \t \t \t MP_MIXERFREEZER2 \t \t 0 \t \t \t \t \t $PARM \t HOLD_TIME \t 5 \t TEMP_SP \t 71.1 \t $END \t $REPORT \t TEMPERATURE \t 0 \t TIME_HELD \t 0 \t $END \t \t \t 0 \crlf 659 \t AGITATE:2 \t 4 \t \t \t \t \t MP_MIXERFREEZER2 \t \t 0 \t \t \t \t \t $PARM \t SPEED_RATE \t 5 \t $END \t $REPORT \t MIX_SPEED \t 30 \t $END \t \t \t 0 \crlf 658 \t MBR_ADD:4 \t 4 \t \t \t \t \t MP_MIXERFREEZER2 \t \t 0 \t \t \t \t \t $PARM \t MATERIAL \t MILK \t AMOUNT \t 2000 \t $BINDCONTAINER \t NULL_CONTAINER \t $BINDEQMODULE \t \t $END \t $REPORT \t ACTUAL_AMOUNT \t 2000 \t FEED_COMPLETE \t YES \t $END \t \t \t 262144\n640 \t AGITATE:3 \t 4 \t \t \t \t \t MP_MIXERFREEZER2 \t \t 0 \t \t \t \t \t $PARM \t SPEED_RATE \t 5 \t $END \t $REPORT \t MIX_SPEED \t 30 \t $END \t \t \t 0 \crlf 644 \t MBR_ADD:5 \t 4 \t \t \t RUNNING \t P_AUTO \t MP_MIXERFREEZER2 \t PROGRAM \t 10 \t 0 \t \t 0 \t \t $PARM \t MATERIAL \t VANILLA \t AMOUNT \t 20 \t $BINDCONTAINER \t TEMPFLAVOR_VANILLA \t $BINDEQMODULE \t MP_ADDFLAVOR_MF2 \t $END \t $REPORT \t ACTUAL_AMOUNT \t \t FEED_COMPLETE \t \t $END \t -1142 \t 21:FRENCH_VANILLAPREMIUM1_MEGA_PARLOR_OPT_1_O1 \t 32 \crlf 657 \t TEMP_CTL:2 \t 4 \t \t \t \t \t MP_MIXERFREEZER2 \t \t 0 \t \t \t \t \t $PARM \t HOLD_TIME \t 5 \t TEMP_SP \t 71.1 \t $END \t $REPORT \t TEMPERATURE \t \t TIME_HELD \t \t $END \t \t \t 0\n648 \t RECIRC:1 \t 4 \t \t \t \t \t MP_MIXERFREEZER2 \t \t 0 \t \t \t \t \t $PARM \t RECIRC_RATE \t 50 \t $END \t $REPORT \t FINAL_RECIRC_RATE \t \t $END \t \t \t 0\n652 \t MBR_DUMP:1 \t 4 \t \t \t \t \t MP_MIXERFREEZER2 \t \t 0 \t \t \t \t \t $PARM \t MATERIAL \t IC_FRENCH_VANILLA \t AMOUNT \t -5000 \t $BINDCONTAINER \t \t $BINDEQMODULE \t \t $END \t $REPORT \t ACTUAL_AMOUNT \t \t FEED_COMPLETE \t \t $END \t \t \t 262144 \crlf

See also





The CreateIDEventData item returns the data regarding the most recently generated event for the specified batch.


Input Format Request: CreateIDEventData


Output Format The CreateIDEventData item returns in this format:

<EvtData> is <SVRSignal> \crlf <EList>

where:

<SVRSignal> ASCII – Integer 0 = continue update of data for this advise 1 = discontinue update of data for this advise

where <EList> is:

<Event> is <Event> | <Event> <EList>

<EList> is <Time> \t <BatchID> \t <RecipePath> \t <Description> \t <EventType> \t <Value> \t <EngUnits> \t <Area> \t <PCell> \t <Unit> \t <EQMName> \t <PhaseType> \t <UserID> \t <CreateID> \crlf


<Time> ASCII – String Time at which the event occurred.

<BatchID> ASCII – String Operator entered batch identification number.

<RecipePath> ASCII – String Procedure identifier from FactoryTalk Batch Recipe Editor.

<Description> ASCII – String Description of the event.

<EventType> ASCII – String Type of event.

<Value> ASCII – String Value associated with the event.

<EngUnits> ASCII – String Engineering units associated with the event, if any.

<Area> ASCII – String Area from the Equipment database.

<PCell> ASCII – String Process cell in which the event occurred.

<Unit> ASCII – String Unit in which the event occurred.

<EQMName> ASCII – String Phase in which the event occurred.

<PhaseType> ASCII – String Phase Class Category.

<User> ASCII – String Machine Name/User Name of person who issued this event to the FactoryTalk Batch Server. This may not be displayed if the event was not generated by the operator.

<CreateID> ASCII – Integer Unique batch ID assigned by the FactoryTalk Batch Server.

CreateIDEventData




Example: A request on object.GetItem(17EventData) could return: 2017.02.24 16:20:54 \t BATCH_100 \t 17:MCLS_FRENCHVANILLA\MCLS_SWEETCREAM_UP:1\MCLS_SWEETCREAM_OP:1-1 \t State Changed: \t State Change \t RUNNING \t \t AREA1 \t NORTH_PARLOR \t NP_MIXER2 \t \t \t \t 17 \t \t \t \t \t \t \t \r\n

See also


The CreateIDEventDataFile item returns the path to the electronic batch record file as long as it has not been removed from the batch list.


Input Format Request: CreateIDEventDataFile

CreateID is ASCII – Integer, INTERNAL identifier assigned by the FactoryTalk Batch Server to a batch when it is created. Obtained from the BatchList item.

Output Format The CreateIDEventDataFile item returns in this format:

<PathToEventDataFile> is <PathToJournalDirectory><EventFile>

<PathToJournalDirectory> is <DriveLetter>:<PathToDirectory>\ as defined in the batchsvr.ini file under [EventManager] section, EventDirectoryPath item.

<EventFile> is <CreateID>.EVT


<CreateID> ASCII – Integer CreateID described in the Input Format, above.


Example: A request on the object.GetItem(17EventDataFile) could return: \\STATION5\PROGRAM FILES\ROCKWELL SOFTWARE\BATCH\SAMPLEAPP\JOURNALS\17.evt

See also


CreateIDEventDataFile



The CreateIDScale item returns the scale factor defined during batch creation.


Input Format Request: CreateIDScale


Output Format The CreateIDScale item returns in this format: <ScaleText>

where:


<ScaleText> ASCII – Integer String representation of batch scale where 1 represents 100% and 0.5 would be 50%.


Example: A request on the object.GetItem(3scale) could return: 0.75.

See also


The DataServersList item returns information about all of the data servers defined for the equipment database.


Input Format Request: DataServersList

Output Format The DataServersList item returns in this format:

<DataServersList> is <ServerList>

<ServerList> is <NullList> | <DataServersList>

<DataServersList> is <Server> | <Server> \t <DataServersList>

where:

<Server> is <DataServerName> \t <WatchdogProtocol> \t <Location> \t <RemoteNodeName> \t <Protocol> \t <ServerIdentifier> \t <ConfigString1> \t <ConfigString2> \t <ConfigString3> \t <ConfigString4> \t <LocaleID> \t <BadValueString> \crlf

where:


<DataServerName> ASCII - String Configured name of the data server.

CreateIDScale

DataServersList



<WatchdogProtocol> ASCII - String Indicates configuration option in the equipment database: OPC: Either ENHANCED or STANDARD, indicating configured behavior in area model. DDE: Either ENHANCED or STANDARD, indicating configured behavior in area model. CIP: Unused (<sp>) FTD:Either ENHANCED or STANDARD, indicating configured behavior in area model.

<Location> ASCII - String Indicates configuration option in the equipment database: OPC: Either LOCAL or REMOTE, indicating configuration of data server in area model. DDE: Either LOCAL or REMOTE, indicating configuration of data server in area model. CIP: LOCAL (only possible selection for CIP server) FTD: LOCAL (only possible selection for FTD server)

<RemoteNodeName> ASCII – String Configured name of the remote node: OPC: If <Location> is REMOTE, this is the remote node’s configured name where the OPC data server is located. If <Location> is LOCAL, this field is unused (<sp>). DDE: If <Location> is REMOTE, this is the remote node’s configured name where the DDE data server is located. If <Location> is LOCAL, this field is unused (<sp>). CIP: Unused (<sp>) FTD: Unused (<sp>)

<Protocol> ASCII – String Data server type selected in the equipment database. Legal values are OPC, DDE, CIP, and FTD.

<ServerIdentifier> ASCII – String Protocol specific configuration string exposed as follows: OPC: An 128-bit GUID indicating the ClassID of the OPC server. DDE: The Application name used in establishing a connection to the DDE server. CIP: The string constant "RSLinx". FTD: The Area Path used in establishing a connection to the FTD server.

<ConfigString1> ASCII – String Protocol specific configuration string exposed as follows: OPC: The data server’s configured watchdog read item access path. DDE: The data server’s configured watchdog read item topic. CIP: Controller Path FTD: The data server’s configured watchdog read item access path.

<ConfigString2> ASCII – String Protocol specific configuration string exposed as follows: OPC: The data server’s configured watchdog read item name. DDE: The data server’s configured watchdog read item name. CIP: Controller Type FTD: The data server’s configured watchdog read item name.



<ConfigString3> ASCII – String Protocol specific configuration string exposed as follows: OPC: The data server’s configured watchdog write item name. DDE: The data server’s configured watchdog write item topic. CIP: Unused (<sp>). FTD: The data server’s configured watchdog write item access path.

<ConfigString4> ASCII – String Protocol specific configuration string exposed as follows: OPC: The data server’s configured watchdog write item name. DDE: The data server’s configured watchdog write item name. CIP: Unused (<sp>). FTD: The data server’s configured watchdog write item name.

<LocaleID> ASCII – Integer Protocol specific configuration string exposed as follows: OPC: Unused (<sp>) DDE: The configured LocaleID of the data server. CIP: Unused (<sp>) FTD: Unused (<sp>)

<BadValueString> ASCII – String Protocol specific configuration string exposed as follows: OPC: Unused (<sp>) DDE: The data server’s configured Bad Value string. CIP: Unused (<sp>) FTD: Unused (<sp>)


Example: A request on object.GetItem(DataServersList) could return: INSTRUCTIONBASEDSERVER \t STANDARD \t LOCAL \t \t OPC \t {473B5480-888D-11d2-811B-0800363B4A03} \t INSTRUCTIONS \t WATCHDOG \t \t \t \t \crlf OPC_SIM \t STANDARD \t LOCAL \t \t OPC \t {3203642A-F66D-11d1-AD6C-00A024386728} \t PHASES \t WATCHDOG \t \t \t \t \crlf

See also




The DataServerStatistics item returns a detailed description of each configured data server conversation and each conversation’s status.


Input Format Request: DataServerStatistics

Output Format The DataServerStatistics item returns in this format:

<Statistics > is <NullList> | <ServerList>

<ServerList> is <ServerRecord> | <ServerRecord> <ServerList>

<ServerRecord> is <ServerName> \t <ConfigString1> \t <ConfigString2> \t <ConversationStatus> \t <WatchDog> \crlf

where <ServerRecord> is:


<ServerName> ASCII - String Name of the data server.

<ConfigString1> ASCII - String Protocol-specific configuration string exposed as follows: OPC: Data Server brand name from DSDF file. DDE: Application Name used to connect to data server. CIP: The string constant "RSLinx". FTD:The Area Path used in establishing a connection to the FactoryTalk Live Data server.

<ConfigString2> ASCII - String Protocol-specific configuration string exposed as follows: OPC: Data server’s configured watchdog read item access path. DDE: Topic name used to connect with data server. CIP: Controller path FTD: Data server’s configured watchdog read item access path.

<Conversation Status> ASCII – String Language-specific word for the current conversation status between the FactoryTalk Batch Server and the data server: Good, Bad, Suspect, or Lost

<WatchDog> ASCII – String Protocol-specific configuration string exposed as follows: OPC: Data server’s configured watchdog read item name. DDE: Data server’s watchdog item name. CIP: Unused (<sp>) FTD: Data server’s configured watchdog read item name.

DataServerStatistics




Example: A request on the object.GetItem(DataServerStatistics) could return this for two servers:

OPC_SIM \t \t PHASES \t GOOD \t WATCHDOG \crlf INSTRUCTIONBASEDSERVER \t \t INSTRUCTIONS \t GOOD \t WATCHDOG \crlf

See also


The DDEClientCount item returns the number of DDE clients connected to the FactoryTalk Batch Server.


Input Format Request: DDEClientCount

Output Format The DDEClientCount item returns in this format: <DDECount>


<DDECount> ASCII - String Number of DDE clients connected to the FactoryTalk Batch Server.


Example: A request on the object.GetItem(DDEClientCount) could return: 1.

See also


DDEClientCount



The DecimalSeparator item returns the decimal symbol used by the FactoryTalk Batch Server.


Input Format Request: DecimalSeparator

Output Format The DecimalSeparator item returns in this format: <Character>


<Character> ASCII – String Decimal character for the language specific operating system.


Example: A request on object.GetItem(DecimalSeparator) could return: .

See also


The Domains item returns an empty list.


Input Format Request: Domains

Output Format The Domains item returns in this format:

<Domains> is <Domain> | <DomainList>

<DomainList> is <Domain> | <Domain> \t <DomainList>


<Domain> ASCII - String Name of a supported domain for user ID authentication passed in signoff.


Example: A request on object.GetItem(Domains) returns: [ ]

See also


DecimalSeparator

Domains



The EnumSetEnumSet item returns the names and ordinal values for each enumeration within the specified enumeration set as defined in the current area model.


Input Format Request only: EnumSetEnumSet

EnumSet is ASCII – text, any enumeration set name as defined in the equipment database.

Output Format The EnumSetEnumSet item returns in this format:

<EnumList> is <EList> | <EList> <EnumList>

<EList> is <EnumName> \t <OrdValue> \crlf


<EnumName> ASCII – String Enumeration name.

<OrdValue> ASCII – String Ordinal value associated with the enumeration.


Example: A request on object.GetItem(YES_NOEnumSet) could return: NO \t 0 \crlf YES \t 1 \crlf

See also


EnumSetEnumSet



The EquipmentModel item returns the path and file name of the equipment model in use.


Input Format Request: EquipmentModel

Output Format The EquipmentModel item returns in this format: <PathName>


<PathName> ASCII – String Path and file name of equipment model in use.


Example: A request on object.GetItem(EquipmentModel) could return: \\STATION5\PROGRAM FILES\ROCKWELL SOFTWARE\BATCH\SAMPLEAPP\RECIPES\ICE_CREAM.CFG

See also


The EquipmentModelDate item the timestamp on the equipment model loaded by the FactoryTalk Batch Server upon startup.


Input Format Request: EquipmentModelDate

Output Format The EquipmentModelDate item returns in this format: <Date>


<Date> ASCII - String Time stamp of equipment model.


Example: A request on object.GetItem(EquipmentModelDate) could return: 2017.02.24 10:05:16

See also


EquipmentModel

EquipmentModelDate



The ErrorMessage item returns the most recent severe message in the FactoryTalk Batch Server’s log file.


Input Format Request: ErrorMessage

Output Format The ErrorMessage item returns in this format: <Time> \t <Description> \t <Additional Data>\crlf


<Time> ASCII – String Time when the message generated.

<Description> ASCII – String General message description.

<Additional Data> ASCII – String More specific message information. May be <NullString> or a blank space character <sp>.


Example: A request on object.GetItem(ErrorMessage) could return: 2017.02.24 16:14:49:220 \t SETTING CONVERSATION STATUS BAD \t SERVER:OPC_SIM \crlf

See also


The EventDataFiles item returns the list of event data files in the system.


Input Format Request: EventDataFiles

Output Format The EventDataFiles item returns in this format:

<EvtDataFiles> is <NullList> | <EvtFileList>

<EvtFileList> is <EventFile> | <EventFile> <EvtFileList>

<EventFile> is <BatchID> \t <CreateID> \t <Description> \t <FilePath> \t <StartTime> \t <RecipeName> \crlf

where <EventFile> is:


<BatchID> ASCII - String Operator-entered batch ID number.


<Description> ASCII - String Procedure description from FactoryTalk Batch Recipe Editor.

<FilePath> ASCII - String Complete file name and event file path as defined in the batchsvr.ini file under [EventManager] section, EventDirectoryPath item.

ErrorMessage

EventDataFiles



<StartTime> ASCII - String Time at which the batch started. May be a blank space character if the batch has not yet started.

<RecipeName> ASCII - String Recipe file name.


Example: A request on object.GetItem(EventDataFiles) could return: BATCH_98 \t 15 \t French Vanilla Premium - class based \t \\STATION5\PROGRAM FILES\ROCKWELL SOFTWARE\BATCH \SAMPLEAPP\JOURNALS\15.evt \t \t CLS_FRENCHVANILLA \crlf BATCH_99 \t 16 \t French Vanilla Premium - class based \t \\STATION5\PROGRAM FILES\ROCKWELL SOFTWARE\BATCH \SAMPLEAPP\JOURNALS\16.evt \t \t CLS_FRENCHVANILLA \crlf BATCH_100 \t 17 \t French Vanilla Premium - class based/material based \t \\STATION5\PROGRAM FILES\ROCKWELL SOFTWARE\BATCH\SAMPLEAPP\JOURNALS\17.evt \t 2017.02.24 16:20:54 \t MCLS_FRENCHVANILLA \crlf

See also




The ExpressionID_UnitID_Values item returns the current expression value and all of its leaf node values for a given expression and unit association.


Input Format Request: ExpressionID_UnitID_Values

ExpressionID is ASCII - Integer, the unique ID of an Expression. Use UnitReqIDBindingRequirements data item or UnitReqIDBindingPreferences data item to retrieve this value.

UnitID is ASCII - Integer, the unique ID of a unit instance. Use UnitsList data item to retrieve this value.

Output Format The ExpressionID_UnitID_Values item returns in this format:

where:

<ExpressionValues> is <ExpressionValue> <ExpressionData>

<ExpressionData> is <ErrorData> | <LeafValuePairs>

<LeafValuePairs> is <NullList> | /t <LeafValueList>

<LeafValueList> is <LeafPair> | <LeafPair> /t <LeafValueList>

<LeafPair> is <LeafName> /t <LeafValue>

where:


<ErrorData> ASCII - String String describing an error that prevents proper evaluation of a Binding Expression. This is typically either a parsing error or a mathematical exception.

<ExpressionValue> ASCII - Variable Evaluated value of the expression.

<LeafName> ASCII - String Name of the leaf from the expression.

<LeafValue> ASCII - Variable Value of the leaf from the expression.

<NullList> ASCII - String Empty string


Example: A request on object.GetItem(15_4_Values), ) which is associated with the expression "(25 <= ON_SCAN_READY) AND ( ON_SCAN_READY <= 75) OR ON_SCAN_READY >= 0"could return: TRUE/tON_SCAN_READY/t0/t0/t0/ON_SCAN_READY/t/t0/t75/t75/t25/t25/ON_SCAN_READY/t0

See also


ExpressionID_UnitID _Values



The ExpressionIDParamExprValues item returns the current expression value and all of its leaf node values for a given parameter expression.


Input Format Request: ExpressionIDParamExprValues

ExpressionID is ASCII - Integer, the unique ID of a parameter expression. Use the ProcedureIDData3 data item to retrieve this item.

Output Format The ExpressionIDParamExprValues item returns in this format:

where:

<ExpressionValues> is <ExpressionText> /t <CurrentValue> /t <ExpressionStatus> /t <ExpressionValue> /t <LeafValuePairs>




where:


<ExpressionText> ASCII - String Configured expression text.

<CurrentValue> ASCII - Variable Expression’s current value. Note this may be changed by Parameter expression overrides or forced to Bad Value (???) by range limit checks.

<ExpressionStatus> ASCII - Integer Integer value of Parameter Expression Status Mask if parameter is a parameter expression, else a single space character. Parameter Expression Status Mask bits are defined as:

• Bit 0 - Expression Forced

• Bit 1 - Expression Evaluation Exception

• Bit 2 - Expression Evaluating Out of Range

<ExpressionValue> ASCII - Variable Value to which the expression would currently evaluate ignoring expression overrides and range limit checks.




ExpressionIDParam ExprValues




Example: A request on object.GetItem(9ParamExprValues) could return: CLS_FRENCHVANILLA_OP.FLAVOR_AMOUNT + ADD_FLAVOR:1.AMOUNT_ADDED ) / RECIRC:1.RECIRC_RATE<t> 2<t> 0<t> 2<t> CLS_FRENCHVANILLA_OP.FLAVOR_AMOUNT<t> 50<t> ADD_FLAVOR:1.AMOUNT_ADDED<t> 50<t> RECIRC:1.RECIRC_RATE<t> 50

See also




The ExpressionIDReportExprValues item returns the current expression value and all of its leaf node values for a given report expression.


Input Format Request: ExpressionIDReportExprValues

ExpressionID is ASCII - Integer, the unique ID of a report expression. Use ProcedureIDData3 data item to retrieve this value.

Output Format The ExpressionIDReportExprValues item returns in this format:

where:

<ExpressionValues> is <ExpressionText> /t <ExpressionValue> <LeafValuePairs>




where:


<ExpressionText> ASCII - String Configured expression text.

<ExpressionValue> ASCII - Variable Current value of the report expression. Note this may be Bad Value (???) if the report expression calculation condition has not been reached. If the report expression has not yet been evaluated, there will be no <LeafValuePairs>





Example: A request on object.GetItem(15ReportExprValues) could return: ADD_CREAM:1.AMOUNT_ADDED+ADD_MILK:1.AMOUNT_ADDED+ADD_SUGAR:1.AMOUNT_ADDED<t>35.98<t>ADD_CREAM:1.AMOUNT_ADDED<t>15.7<t>ADD_MILK:1.AMOUNT_ADDED<t>14.69<t>ADD_SUGAR:1.AMOUNT_ADDED<t>5.59

See also


ExpressionIDReport ExprValues



The HyperlinkLabels item returns a tab-delimited list of hyperlink labels for each equipment type: process cells, units, equipment phases, and shared resources. Each equipment type can contain up to five hyperlink labels.


Input Format Request: HyperlinkLabels

Output Format The HyperlinkLabels item returns in this format: <PCellLabels> \crlf <UnitLabels> \crlf <PhaseLabels> \crlf <ShResrcLabels>

where:

<PCellLabels> is <PCL1> \t <PCL2> \t <PCL3> \t <PCL4> \t <PCL5>

<UnitLabels> is <UL1> \t <UL2> \t <UL3> \t <UL4> \t <UL5>

<PhaseLabels> is <PL1> \t <PL2> \t <PL3> \t <PL4> \t <PL5>

<ShResrcLabels> is <SRL1> \t <SRL2> \t <SRL3> \t <SRL4> \t <SRL5>

where:


<PCL#> ASCII – String Where # is an integer from 1 through 5. Hyperlink label for a process cell.

<UL#> ASCII – String Where # is an integer from 1 through 5. Hyperlink label for a unit.

<PL#> ASCII – String Where # is an integer from 1 through 5. Hyperlink label for a phase.

<SRL#> ASCII – String Where # is an integer from 1 through 5. Hyperlink label for a shared resource.

HyperlinkLabels




Example: A request on object.GetItem(HyperlinkLabels) could return: Hyperlink Label 1 English Process Cell \t Hyperlink Label 2 English Process Cell \t Hyperlink Label 3 English Process Cell \t Hyperlink Label 4 English Process Cell \t Hyperlink Label 5 English Process Cell \crlf Hyperlink Label 1 English Unit \t Hyperlink Label 2 English Unit \t Hyperlink Label 3 English Unit \t Hyperlink Label 4 English Unit \t Hyperlink Label 5 English Unit \crlf Hyperlink Label 1 English Phase \t Hyperlink Label 2 English Phase \t Hyperlink Label 3 English Phase \t Hyperlink Label 4 English Phase \t Hyperlink Label 5 English Phase \crlf Hyperlink Label 1 English Resource String \t Hyperlink Label 2 English Resource String \t Hyperlink Label 3 English Resource String \t Hyperlink Label 4 English Resource String \t Hyperlink Label 5 English Resource String \crlf

See also


The IncompleteSignaturesCt item returns a count of all incomplete signature requests (excluding those generated by private interfaces).


Input Format Request: IncompleteSignaturesCt

Output Format The IncompleteSignaturesCt item returns in this format: <NumSignatures>

where:


<NumSignatures> ASCII - Integer Number of incomplete signatures in the batch system (excluding those generated by private interfaces).

See also


IncompleteSignaturesCt



The InfoMessage item returns the most recent information message in the FactoryTalk Batch Server’s log file.


Input Format Request: InfoMessage

Output Format The InfoMessage returns in the format: <Time> \t <Description> \t <Additional Data>

where:


<Time> ASCII – String Time when the message generated.

<Description> ASCII – String General description of the message.

<Additional Data> ASCII – String More specific message information. May be <NullString> or a blank space character <sp>.


Example: A request on object.GetItem(InfoMessage) could return: 2017.02.24 16:20:56:488 \t COMMAND VALUE UPDATE RECEIVED - COMMAND NOT YET PROCESSED BY PHASE \t CMDID =1 LOW BYTE =100 \crlf

See also


The ItemCount item returns the number of items created by the FactoryTalk Batch Server exposed through DDE and COM.


Input Format Request: ItemCount

Output Format The ItemCount item returns in this format: <Count>


<Count> ASCII – String Number of DDE and COM items created by the FactoryTalk Batch Server.


Example: A request on object.GetItem(ItemCount) could return: 3588

See also


InfoMessage

ItemCount



The JournalDir item returns the path to the journal directory specified in the batchsvr.ini file.


Input Format Request: JournalDir

Output Format The JournalDir item returns in this format: <Path> \crlf

where:


<Path> ASCII – String Journal directory path specified in the batchsvr.ini file.


Example: A request on object.GetItem(JournalDir) could return: \\STATION5\PROGRAM FILES\ROCKWELL SOFTWARE\BATCH\ SAMPLEAPP\JOURNALS\ \crlf

See also


The ListSeparator item returns the list separator used by the FactoryTalk Batch Server.


Input Format Request: ListSeparator

Output Format The ListSeparator item returns in this format: <Separator>


<Separator> ASCII – String Default list separator for the language specific operating system.


Example: A request on object.GetItem(ListSeparator) could return: ,

See also


JournalDir

ListSeparator



The Locale item returns the locale information used by the FactoryTalk Batch Server. This includes the language ID and code page.


Input Format Request: Locale

Output Format The Locale item returns in this format: <LanguageID> \t <CodePage>


<LanguageID> ASCII – String ID that identifies the language: 1031 – German (Standard) 1033 – English (United States) 1036 – French (Standard) 1040 – Italian (Standard) 3082 – Spanish (Modern Sort)

<CodePage> ASCII – String Code page used by server, decimal number


Example: A request on object.GetItem(Locale) could return: 1033 \t 1252

See also


Locale



The MatSvrStatus item returns the status of the Material Server as an ordinal data item.


Input Format Request: MatSvrStatus

Output Format The MatSvrStatus item returns in this format: <Status>

where:


<Status> ASCII – Integer 3 = Material Manager not installed. 2 = Material Server communication in use. 1 = Material Server communication available but not restored. 0 = Material Server communication not available.


Example: A request on object.GetItem(MatSvrStatus) could return: 3

See also


The OPCClientCount item returns the number of OPC clients connected to the FactoryTalk Batch Server.


Input Format Request: OPCClientCount

Output Format The OPCClientCount item returns in this format: <OPCCount>

where:


<OPCCount> ASCII – String Number of OPC clients connected to the FactoryTalk Batch Server.


Example: A request on object.GetItem(OPCClientCount) could return: 2

See also


MatSvrStatus

OPCClientCount



The OperationDataList item lists information about all of the equipment operation sequences in the system. The OperationDataList item exposes a large amount of data for each equipment operation sequence. This can cause a significant processing load on the data server, FactoryTalk Batch Server, and client.

Disable the OperationDataList item and the OperationErrs item by adding this entry in the [CLIENT MGR DDE] section of the batchsvr.ini file.

[CLIENT MGR DDE] DisableOperationDataList=YES

If the items are disabled, the FactoryTalk Batch Server does not return any data if issued a request for either of these items. If the DisableOperationDataList item is set to YES, the Alarm Summary and Phase/Operation Summary windows in FactoryTalk Batch View will not be able to display equipment operation sequence data. When using FactoryTalk Batch View as the HMI, disabling this item is not recommended.


Input Format Request: OperationDataList

Output Format The OperationDataList item returns in this format:

<OperationList> is <OperationData> \crlf | <OperationData> \crlf <OperationList>

<OperationData> is <OpSeqID> \t <OpSeqName> \t <OpSeqState> \t <Pausing> \t <Mode> \t <ArbMask> \t <CmdMask> \t <UnitID> \t <UnitName> \t <Owner> \t <BatchID> \t <FailMsg> \t <OperationMsg> \t <StepIndex> \t <ValidUList>\crlf

where <OperationData> is:


<OpSeqID> ASCII – String Equipment ID of the equipment operation sequence.

<OpSeqName> ASCII – String Name of the equipment operation sequence configured in FactoryTalk Batch Equipment Editor.

<OpSeqState> ASCII – String Current state of the equipment operation sequence.

<Pausing> ASCII – Integer Pause and Paused attributes with the following valid values: • 0 = Not significant

• 1 = Pausing – Pause && !Paused

• 2 = Paused – Paused

OperationDataList



<Mode> ASCII - String Mode of the equipment operation sequence. When recipe control is used, these are the valid values:

• O-AUTO

• P-AUTO

• S-AUTO

• MANUAL

When manual control is used, these are the valid values:

• PS-AUTO

• PS-SEMI

If the equipment operation sequence is not part of a running recipe or owned by the operator, a blank character is returned.

<ArbMask> ASCII - String Arbitration mask.

<CmdMask> ASCII - String Command mask.

<UnitID> ASCII - Integer Identifier for the unit.

<UnitName> ASCII - String Name of the unit.

<Owner> ASCII - String Current owner: • NONE

• PROGRAM

• OPERATOR

• EXTERNAL

<BatchID> ASCII - String User-entered identifier for the batch.

<FailMsg> ASCII - String Failure message.

<OperationMsg> ASCII - String Equipment operation sequence message.

<StepIndex> ASCII - Integer Value of the Step Index tag in the process-connected device. This field is not used and always returns a zero (0).

<ValidUList> Variable list List of the valid units.

where:

<ValidUList> is <UnitName> | <UnitName> \t <ValidUList>


<UnitName> ASCII - String Name of the valid unit.




Example: A request on object.GetItem(OperationDataList) could return: 5 \t MAKE_CAJUN_BROTH_M1 \t IDLE \t 0 \t \t 1 \t 0 \t 0 \t \t UNKNOWN \t \t \t \t 0 \t WP_MIXER1\crlf 6 \t MAKE_CAJUN_BROTH_M2 \t IDLE \t 0 \t \t 1 \t 0 \t 0 \t \t UNKNOWN \t \t \t \t 0 \t WP_MIXER2\crlf

See also


OperationErrs on page 71





The OperationErrs item lists all the equipment operation sequences that are currently in failure or have an error. If the FactoryTalk Batch Server does not return any data when a request is issued against this item, the item may be disabled in the batchsvr.ini file.

Use the OperationDataList item to disable this item.


Input Format Request: OperationErrs

Output Format The OperationErrs item returns in this format:

<OperationErrors> is <NullList> | <OpSeqErrList> \crlf

<OpSeqErrList> is <OpSeqErrDesc> \crlf | <OpSeqErrDesc> \crlf <OpSeqErrList>

<OpSeqErrDesc> is <OpSeqID> \t <OpSeqName> \t <UnitID> \t <UnitName> \t <PCellName> \t <AreaName> \t <Owner> \t <BatchID> \t <OpSeqErrMsg> \t <State>

<OpSeqErrMsg> is <FailMsg> | <ErrMsg>

where <OpSeqErrDesc> is:


<OpSeqID> ASCII - Integer Equipment ID of the equipment operation sequence.

<OpSeqName> ASCII - String Name of the equipment operation sequence configured in FactoryTalk Batch Equipment Editor.

<UnitID> ASCII - Integer Current unit ID.


<PCellName> ASCII - String Process cell name.

<AreaName> ASCII - String Area name.

<Owner> ASCII - String Owner name.


<OpSeqErrMsg> ASCII - String Message generated by the FactoryTalk Batch Server.

<State> ASCII - String Current state of the equipment operation sequence.

where <OpSeqErrMsg> is:

<FailMsg> ASCII - String Failure message generated by the logic running in the PLC. This message is configured in the Phase_Failures enumeration of the Equipment Database.

<ErrMsg> ASCII - String Error message generated by the FactoryTalk Batch Server. This message is internal to FactoryTalk Batch.

OperationErrs




Example: A request on object.GetItem(OperationErrs) could return: 68 \t MAKE_ICE_CREAM \t 0 \t \t West_Parlor \t AREA1 \t \t \t FV101_FAILED_TO_CLOSE \t IDLE \crlf

See also

OperationDataList on page 68


The OperationErrsCt item returns the number of equipment operation sequence errors currently detected by the FactoryTalk Batch Server.


Input Format Request: OperationErrsCt

Output Format The OperationErrsCt item returns in this format: <NumberOfErrors>


<NumberOf Errors>

ASCII - Integer Number of equipment operation sequence errors currently detected by the FactoryTalk Batch Server.


Example: A request on object.GetItem(OperationErrsCt) could return: 3

See also


OperationErrsCt



The PhaseDataList item lists information about all of the phases in the system. The PhaseDataList item exposes a large amount of data for each phase. This can cause a significant processing load on the data server, FactoryTalk Batch Server, and client. The PhaseIDPhaseData item can be used in place of the PhaseDataList item, only returning data for a specific phase.

Disable the PhaseDataList item and the PhaseErrs item by adding this entry in the [CLIENT MGR DDE] section of the batchsvr.ini file.

[CLIENT MGR DDE] DisablePhaseDataList=YES

If the items are disabled, the FactoryTalk Batch Server does not return any data if issued a request for either of these items. If the DisablePhaseDataList item is set to YES, the Alarm Summary and Phase/Operation Summary windows in FactoryTalk Batch View will not display any data.


Input Format Request: PhaseDataList

Output Format The PhaseDataList returns in this format:

<PhaseDataList> is <Phase> \crlf | <Phase> \crlf <PhaseDataList>

<Phase> is <PhaseID> \t <PhaseName> \t <PhaseState> \t <Pausing> \t <Mode> \t <ArbMask> \t <CmdMask> \t <UnitID> \t <UnitName> \t <Owner> \t <BatchID> \t <FailMsg> \t <PhaseMsg> \t <StepIndex> \t <ValidUList>\crlf

where <Phase> is:


<PhaseID> ASCII – String Equipment ID of phase.

<PhaseName> ASCII – String Name of phase configured in FactoryTalk Batch Equipment Editor.

<PhaseState> ASCII – String Current state of the phase.

<Pausing> ASCII – Integer Pause and Paused attributes: • 0 = not significant



PhaseDataList



<Mode> ASCII - String Mode of the phase. When recipe control is used, these are the valid values:

• O-AUTO

• P-AUTO

• S-AUTO

• MANUAL


• PH-AUTO

• PH-SEMI

If the phase is not part of a running recipe or owned by the operator, a blank character is returned.






• PROGRAM

• OPERATOR

• EXTERNAL



<PhaseMsg> ASCII - String Phase message.

<StepIndex> ASCII - Integer Value of the Step Index tag in the process-connected device.


where:



<UnitName> ASCII - String Name of the valid unit.




Example: A request on object.GetItem(PhaseDataList) could return: 5 \t WP_ADD_CREAM_M1 \t IDLE \t 0 \t \t 1 \t 0 \t 0 \t \t UNKNOWN \t \t \t \t 0 \t WP_MIXER1 \crlf 6 \t WP_ADD_CREAM_M2 \t IDLE \t 0 \t \t 1 \t 0 \t 0 \t \t UNKNOWN \t \t \t \t 0 \t WP_MIXER2 \crlf ... 104 \t MP_DUMP_MF2 \t IDLE \t 0 \t \t 1 \t 0 \t 0 \t \t UNKNOWN \t \t \t \t 0 \t MP_MIXERFREEZER2 \crlf

See also


PhaseIDPhaseData on page 85





The PhaseErrs item lists all the phases that are currently in failure or have an error. If the FactoryTalk Batch Server does not return any data when issued a request against this item, it is possible that the item is disabled in the batchsvr.ini file.

Use the PhaseDataList item to disable this item.


Input Format Request: PhaseErrs

Output Format The PhaseErrs item returns in this format:

<PhaseErrors> is <NullList> | <PhErrList> \crlf

<PhErrList> is <PhErrDesc> \crlf | <PhErrDesc> \crlf <PhErrList>

<PhErrDesc> is <PhaseID> \t <PhaseName> \t <UnitID> \t <UnitName> \t <PCellName> \t <AreaName> \t <Owner> \t <BatchID> \t <PhErrMsg> \t <State>

<PhErrMsg> is <FailMsg> | <ErrMsg>

where <PhErrDesc> is:


<PhaseID> ASCII - Integer Equipment ID of the phase.

<PhaseName> ASCII - String Name of phase configured in FactoryTalk Batch Equipment Editor.

<UnitID> ASCII - Integer Current unit ID.

<UnitName> ASCII - String Current unit name.

<PCellName> ASCII - String Process cell name.

<AreaName> ASCII - String Area name.

<Owner> ASCII - String Owner name.


<PhErrMsg> ASCII - String Message generated by the FactoryTalk Batch Server.

<State> ASCII - String Current state of the phase.

where <PhErrMsg> is:

<FailMsg> ASCII - String Failure message generated by the logic running in the PLC. It is configured in the Phase_Failures enumeration of the Equipment Database.

<ErrMsg> ASCII - String Error message generated by the FactoryTalk Batch Server. This message is internal to FactoryTalk Batch.

PhaseErrs




Example: A request on object.GetItem(PhaseErrs) could return: 68 \t NP_ADDDAIRY_M1 \t 0 \t \t West_Parlor \t AREA1 \t \t \t FV101_FAILED_TO_CLOSE \t IDLE \crlf

See also


PhaseDataList on page 73

The PhaseErrsCt item returns the number of phase errors currently detected by the FactoryTalk Batch Server.


Input Format Request: PhaseErrsCt

Output Format The PhaseErrsCt item returns in this format: <NumberOfErrors>


<NumberOf Errors>

ASCII - Integer Number of phase errors currently detected by the FactoryTalk Batch Server.


Example: A request on object.GetItem(PhaseErrsCt) could return: 3

See also


PhaseErrsCt



The PhaseIDBatchID item lists the operator-entered batch ID for the batch to which the phase belongs.


Input Format Request: PhaseIDBatchID

PhaseID is ASCII - Integer, the unique Equipment ID corresponding to the phase.

Output Format The PhaseIDBatchID item returns in this format:

<BatchID> is ASCII - String (user defined)


Example: A request on object.GetItem(68BatchID) could return: Batch_100

See also


The PhaseIDFailure item lists the phase failure message for the phase denoted by the phase ID.


Input Format Request: PhaseIDFailure

PhaseID is ASCII - Integer, the unique equipment ID corresponding to the phase.

Output Format The PhaseIDFailure item returns in this format: <FailureMessage>


<FailureMessage> ASCII - String Text of the error generated in the Phase Failures enumeration. If an error message has not been defined for the failure number, a Config Error message displays. If the phase is not active, OFF displays.


Example: A request on object.GetItem(68Failure) could return: FV101_FAILED_TO_CLOSE

See also


PhaseIDBatchID

PhaseIDFailure



The PhaseIDInfo item returns the name of the phase which is denoted by the phase ID.


Input Format Request: PhaseIDInfo


Output Format The PhaseIDInfo item returns in this format: Phase <PhaseInfo>


<PhaseInfo> ASCII - String Name of the phase prefaced with the text Phase.


Example: A request on object.GetItem(68Info) could return: Phase NP_ADDDAIRY_M1

See also


The PhaseIDMessage item returns the last message sent to the FactoryTalk Batch Server by the phase, which is denoted by the phase ID.


Input Format Request: PhaseIDMessage


Output Format The PhaseIDMessage item returns in this format: <PhaseMessage>


<PhaseMessage> ASCII - String Text of the last message sent to the FactoryTalk Batch Server by the phase.


Example: A request on object.GetItem(68Message) could return: CHARGE_MESSAGE

See also


PhaseIDInfo

PhaseIDMessage



The PhaseIDOwnerFlag item returns the phase’s current owner as denoted by the phase ID.


Input Format Request: PhaseIDOwnerFlag


Output Format The PhaseIDOwnerFlag item returns in this format: <PhaseOwner>


<PhaseOwner> ASCII – String Phase owner: Response No owner: S_AUTO Procedure Control: P_AUTO Operator Control: MANUAL External Control: O_AUTO


Example: A request on object.GetItem(68OwnerFlag) could return: P_AUTO

See also


PhaseIDOwnerFlag



The PhaseIDParms item returns all parameters for the phase. If the phase is inactive there is no data returned.


Input Format Request: PhaseIDParms


Output Format The PhaseIDParms item returns in this format:

<PhaseIDParms> is <NullList> | <PhaseParmList>

<PhaseParmList> is <ParmEntry> | <ParmEntry> <PhaseParmList>

<ParmEntry> is <ParmName> \t <ParmType> \t <ParmScope> \t <Eus> \t <MaxValue> \t <MinValue> \t <Value> \t

where <ParmEntry> is:


<ParmName> ASCII - String Name of parameter.

<ParmType> ASCII - Integer 1: Real 2: Long Integer 3: String 5: Enumeration

<ParmScope> ASCII - Integer 1: Value 2: UnAcked Prompt 3: Deferred Parameter

<EUs> ASCII - String Engineering units.

<MaxValue> ASCII - String Maximum value.

<MinValue> ASCII - String Minimum value.

<Value> ASCII - String Current value. ??? represents an Unacknowledged Prompt


Example: A request on object.GetItem(68Parms) could return: MATERIAL \t 5 \t 1 \t MATERIALS \t \t \t CREAM

See also


PhaseIDParms



The PhaseIDParms2 item returns all parameters for the phase including the parameter limits high/low, high-high/low-low and high-high-high/low-low-low. If the phase is inactive there is no data returned.


Input Format Request: PhaseIDParms2


Output Format The PhaseIDParms2 item returns in this format:

<PhaseIDParms> is <NullList> | <PhaseParmList>

<PhaseParmList> is <ParmEntry> | <ParmEntry> <PhaseParmList>

<ParmEntry> is <ParmName> \t <ParmType> \t <ParmScope> \t <Eus> \t <MaxValue> \t <MinValue> \t <Value> \t <HighHighHighLimit> \t <HighHighLimit> \t <HighLimit> \t <LowLimit> \t <LowLowLimit> \t <LowLowLowLimit>

where <ParmEntry> is:


<ParmName> ASCII - String Name of parameter:

• $BINDCONTAINER - for container only.

• $BINDEQMODULE - for phase only.

<ParmType> ASCII - Integer Data type: • 1: Real

• 2: Long integer

• 3: String

• 5: Enumeration

<ParmScope> ASCII - Integer Kind of parameter: • 1: Value

• 2: UnAcked Prompt

• 3: Deferred

• 4: Static

• 5: Material Data

<EUs> ASCII - String Engineering Units IF <ParmType> = 5, then this is the enumeration set IF <ParmType> = 3, then a space

<MaxValue> ASCII - Integer Maximum Value Single space for strings and enumerations

<MinValue> ASCII - String Minimum Value Single space for strings and enumerations

<Value> ASCII - String Current Value ??? represents an Unacknowledged Prompt

PhaseIDParms2



<HighHighHigh Limit>

ASCII - Integer High-High-High Limit

<HighHighLimit> ASCII - Integer High-High Limit

<HighLimit> ASCII - Integer High Limit

<LowLimit> ASCII - Integer Low Limit

<LowLowLimit> ASCII - Integer Low-Low Limit

<LowLowLow Limit>

ASCII - Integer Low-Low-Low Limit


Example: A request on object.GetItem(68Parms) could return: MATERIAL \t 5 \t 1 \t MATERIALS \t \t \t CREAM \t \t \t \t \t \t

See also


The PhaseIDPause item returns the PAUSE attribute for a phase or an equipment operation sequence.


Input Format Request: PhaseIDPause

PhaseID is Unique equipment ID corresponding to the phase or equipment operation sequence.

Output Format The PhaseIDPause item returns in this format: <PauseText>


<PauseText> ASCII - String Value in the Pause tag in the process-connected device (PCD).

• Off when the value is zero.

• On when the value is non-zero.


Example: A request on object.GetItem(68Pause) could return: Off

See also


PhaseIDPause



The PhaseIDPausing item returns the PAUSING attribute for a phase or an equipment operation sequence.


Input Format Request: PhaseIDPausing


Output Format The PhaseIDPausing item returns in this format: <PausingText>


<PausingText> ASCII - String Value in the Pausing tag in the process-connected device (PCD).

• Off when the value is zero.

• On when the value is non-zero.


Example: A request on object.GetItem(68Pausing) could return: Off

See also


PhaseIDPausing



The PhaseIDPhaseData item returns current status information for a phase or equipment operation sequence denoted by the PhaseID.

The PhaseIDPhaseData item was created to be used in place of the PhaseDataList item. The PhaseDataList item returns data on all phases or equipment operation sequences within an equipment database, where the PhaseIDPhaseData item returns data only for the specified phase or equipment operation sequence.


Input Format Advise: PhaseIDPhaseData


Output Format The PhaseIDPhaseData item returns in this format:

<PhaseIDPhaseData> is <PhaseID> \t <PhaseName> \t <PhaseState> \t <Pausing> \t <Mode> \t <ArbMask> \t <CmdMask> \t <UnitID> \t <UnitName> \t <Owner> \t <BatchID> \t <FailMsg> \t <PhaseMsg> \t <StepIndex> \t <ValidUList>

where <Phase> is:


<PhaseID> ASCII - Integer Unique equipment ID corresponding to the phase or equipment operation sequence.

<PhaseName> ASCII - String Name of the phase or equipment operation sequence configured in FactoryTalk Batch Equipment Editor.

<PhaseState> ASCII - String Current state of the phase or equipment operation sequence.

<Pausing> ASCII - Integer Pause and Paused attributes with the following valid values: • 0 = Not significant



<Mode> ASCII - String Mode of the phase or equipment operation sequence. When recipe control is used, these are the valid values:

• O_AUTO

• P_AUTO

• S_AUTO

• MANUAL


• PS-AUTO

• PS-SEMI

If the phase or equipment operation sequence is not part of a running recipe or owned by the operator, a blank character is returned.




PhaseIDPhaseData





• PROGRAM

• OPERATOR

• EXTERNAL





<ValidUList> Variable list List of valid units.

where:





Example: A request on object.GetItem(68PhaseData) could return: 68 \ t NP_ADDDAIRY_M1 \t COMPLETE \t 0 \t P_AUTO \t 1 \t 32 \t 55 \t NP_MIXER1 \t PROGRAM \t BATCH_ID \t \t FEED_COMPLETE NOT COMPLETE. \t 10 \t NP_MIXER1\crlf

See also






The PhaseIDPhaseData2 item returns current status information for a phase or equipment operation sequence denoted by the PhaseID including the status of enabling or disabling pausing execution of the referenced phase or equipment operation sequence.


Input Format Advise: PhaseIDPhaseData2


Output Format The PhaseIDPhaseData2 item returns in this format:

<PhaseIDPhaseData2> is <PhaseID> \t <PhaseName> \t <PhaseState> \t <SingleStep> \t <Pausing> \t <Mode> \t <ArbMask> \t <CmdMask> \t <UnitID> \t <UnitName> \t <Owner> \t <BatchID> \t <FailMsg> \t <PhaseMsg> \t <StepIndex> \t <ValidUList>

where <Phase> is:


<PhaseID> ASCII - Integer Unique equipment ID corresponding to the phase or equipment operation sequence.

<PhaseName> ASCII - String Name of the phase or equipment operation sequence configured in FactoryTalk Batch Equipment Editor.

<PhaseState> ASCII - String Current state of the phase or equipment operation sequence.

<SingleStep> ASCII - String Whether pausing is enabled or disabled for the execution of the following: • Equipment sequence programs at each transition

• Phase programs at each PPD instruction executed by the controller

These are the valid values: • 1 = True

• 0 = False

<Pausing> ASCII - Integer Pause and Paused attributes with the following valid values: • 0 = Not significant



<Mode> ASCII - String Mode of the phase or equipment operation sequence. When recipe control is used, these are the valid values:

• O_AUTO

• P_AUTO

• S_AUTO

• MANUAL


• PS-AUTO

• PS-SEMI

If the phase or equipment operation sequence is not part of a running recipe or owned by the operator, a blank character is returned.

PhaseIDPhaseData2







<Owner> ASCII - String Current owner:

• NONE

• PROGRAM

• OPERATOR

• EXTERNAL






where:





Example: A request on object.GetItem(68PhaseData) could return: 68 \ t NP_ADDDAIRY_M1 \t COMPLETE\t 0 \t P_AUTO \t 1 \t 32 \t 55 \t NP_MIXER1 \t PROGRAM \t BATCH_ID \t \t FEED_COMPLETE NOT COMPLETE. \t 10 \t NP_MIXER1\crlf

See also






The PhaseIDRequests item returns the phase request value.


Input Format Request: PhaseIDRequests

PhaseID is ASCII - Integer, the unique equipment ID corresponding to the phase.

Output Format The PhaseIDRequests item returns in this format: <RequestsText>


<RequestsText> ASCII - String Text representation of the value of the request register in the process-connected device for the specified phase.


Example: A request on object.GetItem(68Requests) could return: 1000

See also


The PhaseIDSS item returns the single step index attribute for a phase or an equipment operation sequence.


Input Format Request: PhaseIDSS


Output Format The PhaseIDSS item returns in this format: <SingleStepText>


<SingleStepText> ASCII - String Value in the Single Step tag in the process-connected device. These are the valid values: • Off = The value is zero.

• On = The value is non-zero.

• ??? = The phase is inactive.


Example: A request on object.GetItem(68SS) could return: Off

See also


PhaseIDRequests

PhaseIDSS



The PhaseIDState item returns the current state for a phase or an equipment operation sequence.


Input Format Request: PhaseIDState


Output Format The PhaseIDState item returns in this format: <StateText>


<StateText> ASCII - String Value corresponding to the state register’s value in the process-connected device. If this value does not correspond to any defined batch state, displays ???.


Example: A request on object.GetItem(68State) could return: IDLE

See also



The PhaseIDStepIndex item returns the current step attribute of the phase specified by the phase ID.


Input Format Request: PhaseIDStepIndex

Output Format The PhaseIDStepIndex item returns in this format: <StepIndex>




Example: A request on the object.GetItem(12stepindex) could return: 4

See also


PhaseIDState

PhaseIDStepIndex



The PhaseIDUnit item returns the current unit for a phase or an equipment operation sequence.


Input Format Request: PhaseIDUnit


Output Format The PhaseIDUnit item returns in this format: <UnitID>


<UnitID> ASCII - Integer Returns the text representation of the equipment ID of the unit to which this phase or equipment operation sequence belongs.


Example: A request on object.GetItem(68Unit) could return: 55

See also


PhaseIDUnit



The PhasesList item returns a list of all phases, corresponding equipment IDs, and valid units.


Input Format Request: PhasesList

Output Format The PhasesList item returns in this format:

<PhasesList> is <PhaseData> \crlf | <PhaseData> \crlf <PhasesList>

<PhaseData> is <PhaseDesc> \t <UnitList>

<PhaseDesc> is <PhaseID> \t <PhaseName>

<UnitList> is <UnitName> | <UnitName> \t <UnitList>

where <PhaseDesc> is:


<PhaseID> ASCII - Integer Unique equipment ID for a phase.

<PhaseName> ASCII - String Name of a phase.





Example: A request on object.GetItem(PhasesList) could return: 5 \t WP_ADD_CREAM_M1 \t WP_MIXER1 \crlf 6 \t WP_ADD_CREAM_M2 \t WP_MIXER2 \crlf 39 \t SP_ADD_CREAM_M1 \t SP_MIXER1 \crlf

... 04 \t MP_DUMP_MF2 \t MP_MIXERFREEZER2 \crlf

See also


PhasesList



The PhasesList2 item returns a list of all equipment phases, corresponding equipment IDs, recipe phases, the phase type, and valid units.


Input Format Request: PhasesList2

Output Format The PhasesList2 item returns in this format:



<PhaseDesc> is <PhaseID> \t <Equipment PhaseName> \t <Recipe PhaseName> \t <PhaseType>





<Equipment PhaseName> ASCII - String Name of an equipment phase. (Marked as the phase in FactoryTalk Batch Equipment Editor.)

<Recipe PhaseName> ASCII - String Name of a recipe phase. (Marked as the phase in FactoryTalk Batch Equipment Editor.)

<PhaseType> ASCII - Integer 0 = Reserved for future use.





Example: A request on object.GetItem(PhasesList2) could return: 5 \t WP_ADD_CREAM_M1 \t ADD_CREAM \t 0 \t WP_MIXER1 \crlf 6 \t WP_ADD_CREAM_M2 \t ADD_CREAM \t 0 \t WP_MIXER2 \crlf 39 \t SP_ADD_CREAM_M1 \t ADD_CREAM \t 0 \t SP_MIXER1 \crlf ... 104 \t MP_DUMP_MF2 \t MBR_DUMP \t 0 \t MP_MIXERFREEZER2 \crlf

See also


PhasesList2



The PhasesList3 item returns a list of all equipment phases, corresponding equipment IDs, recipe phases, phase types, bitmap filenames, and valid units.


Input Format Request: PhasesList3

Output Format The PhasesList3 item returns in this format:



<PhaseDesc> is <PhaseID> \t <Equipment PhaseName> \t <Recipe PhaseName> \t <PhaseType> \t <PhaseBitmapName>





<Equipment PhaseName> ASCII - String Name of an equipment phase. (Marked as the phase in FactoryTalk Batch Equipment Editor.)

<Recipe PhaseName> ASCII - String Name of a recipe phase. (Marked as the phase in FactoryTalk Batch Equipment Editor.)

<PhaseType> ASCII - Integer 0 = Reserved for future use.

<PhaseBitmap Name>

ASCII - String Name of the phase bitmap file.




PhasesList3




Example: A request on object.GetItem(PhasesList3) could return: 5 \t WP_ADD_CREAM_M1 \t ADD_CREAM \t 0 \t DUMP2&.BMP \t WP_MIXER1 \crlf 6 \t WP_ADD_CREAM_M2 \t ADD_CREAM \t 0 \t DUMP2&.BMP \t WP_MIXER2 \crlf 39 \t SP_ADD_CREAM_M1 \t ADD_CREAM \t 0 \t DUMP2&.BMP \t SP_MIXER1 \crlf ... 104 \t MP_DUMP_MF2 \t MBR_DUMP \t 0 \t dump1&.bmp \t MP_MIXERFREEZER2 \crlf

See also




The ProcedureIDData item returns detailed data regarding the specified level of a procedure. Query each recipe level to get complete recipe details. The data returned by this item is static. Obtain this item again to reflect any updates.


Input Format Request: ProcedureIDData

ProcedureID is ASCII - String, the unique path to the recipe step. This path begins with the CreateID. Use BLCreateID_x item to retrieve the CreateID.

Procedure Level is CreateID

Unit Procedure Level is CreateID \t UnitProcedureName

Operation Level is CreateID \t UnitProcedureName \t OperationName

Output Format The ProcedureIDData item returns in this format:

<ProcData> is <SVRSignal> \crlf <DataList>

where:


<SVRSignal> ASCII - Integer 0 = continue update of data for this advise 1 = discontinue update of data for this advise

where <DataList> is:

<DataList> is <RecipeDat> \crlf <RecipeElemList> <RecipeElemList> expanded after <RecipeDat>

<RecipeDat> is <RecpAbstr> \crlf <RecpDesc> \crlf <RecpID> \crlf <RecpCode> \crlf <RecpVersion> \crlf <RecpAuthor> \crlf <RecpDate> \crlf <DocDim> \crlf <AreaName> \crlf <ProcCellList> \crlf <BoundUnit>

where <RecipeDat> is:


<RecpAbstr> ASCII - String Recipe abstract.

<RecpDesc> ASCII - String Recipe description.

<RecpID> ASCII - String Recipe identifier.

<RecpCode> ASCII - String Recipe product code.

<RecpVersion> ASCII - String Recipe version.

<RecpAuthor> ASCII - String Recipe author.

<RecpDate> ASCII - String Date recipe was last saved with the format in accordance with the date and time as set in Control Panel.

<DocDim> Variable List Recipe drawing dimensions.

<AreaName> ASCII - String Equipment database name.

<ProcCellList> ASCII - String Currently always a blank space character.

<BoundUnit> ASCII - String Unit name to which the step is bound.

ProcedureIDData



where <DocDim> is:

<DocDim> is <Xdim> \t <Ydim>


<Xdim> ASCII - Integer Always returns zero. Reserved for future use.

<Ydim> ASCII - Integer Always returns zero. Reserved for future use.

where <RecipeElemList> is: <ParentStep> is always the first element in a <RecipeElemList> and only appears once in that list.

<RecipeElemList> is <RecipeElem> | <RecipeElem> \crlf <RecipeElemList>

<RecipeElem> is <ParentStep> | <InitialStep> | <TerminalStep> | <RegularStep> | <Transition> | <EqModLink> | <OrDiverg> | <OrConverg> | <AndDiverg> | <AndConverg>

<ParentStep> is <ElemType> \t <ElemID> \t <RecipeLink> \t <ParmList>

<InitialStep> is <ElemType> \t <ElemID> \t <DrawXCord> \t <DrawYCord>

<TerminalStep> is <ElemType> \t <ElemID> \t <DrawXCord> \t <DrawYCord>

<RegularStep> is <ElemType> \t <ElemID> \t <DrawXCord> \t <DrawYCord> \t <StepName> \t <ControllingProc> \t <ParmList> \t <RptParmList>

<Transition> is <ElemType> \t <ElemID> \t <DrawXCord> \t <DrawYCord> \t <ConditionExpression>

<EqModLink> is <ElemType> \t <ElemID> \t <PrevElemID> \t <NextElemID>

<OrDiverg> is <ElemType> \t <ElemID> \t <PrevElemIDList> \t <NextElemIDList>

<OrConverg> is <ElemType> \t <ElemID> \t <NextElemIDList> \t <PrevElemIDList>

<AndDiverg> is <ElemType> \t <ElemID> \t <PrevElemIDList> \t <NextElemIDList>

<AndConverg> is <ElemType> \t <ElemID> \t <NextElemIDList> \t <PrevElemIDList>

where <RecipeElemList> is:


<ElemType> ASCII - Integer Recipe Element Type 0 = Parent Step 1 = Initial Step 2 = Terminal Step 3 = Regular Step 4 = Transition 5 = Link 6 = OR Divergence 7 = OR Convergence 8 = AND Divergence 9 = AND Convergence

<ElemID> ASCII - Integer Element identifier.



<RecipeLink> ASCII - Integer Path to the recipe file and recipe.

<DrawXCoord> ASCII - Integer X coordinate for drawing the element.

<DrawYCoord ASCII - Integer Y coordinate for drawing the element.

<ParmList> Variable List Parameters associated with the procedure.

<StepName> ASCII - String Name of a step element.

<ControllingProc> ASCII - String Name of the procedure a step element controls.

<RptParmList> Variable List Report parameters associated with the procedure.

<ConditionExpression> ASCII - String Condition expression’s text of a transition element.

<PrevElemID> ASCII - Integer Element identifier appearing IN FRONT of a phase link.

<NextElemID> ASCII - Integer Element identifier appearing BEHIND a phase link.

<PrevElemIDList> Variable List List of elements appearing ABOVE a divergence or convergence.

<NextElemIDList> Variable List List of elements appearing BELOW a divergence or convergence.



<Parameters> is <NullParmList> | <PList>

<NullParmList> is <sp>


<Parameter> is <ParmName> \t <ParmType> \t <ParmKind> \t <EUs> \t <MaxValue> \t <MinValue> \t <DefaultValue>

where <Parameter> is:

Field Name Format Field Name

<ParmName> ASCII - String Parameter name $BINDCONTAINER - for container only. $BINDEQMODULE - for phase only

<ParmType> ASCII - Integer Data type • 1: Rea

• 2: Long

• 3: String

• 5: Enumeration

<ParmKind> ASCII - Integer Kind of parameter. 1: Value 2: UnAcked Prompt 3: Deferred 4: Static 5: Material Data

<EUs> ASCII - String Eng Unit If <ParmType> = 5, then this is the enumeration set If <ParmType>=3, then a space

<MaxValue> ASCII - String Maximum value Single space for strings and enumerations



<MinValue> ASCII - String Minimum value Single space for strings and enumerations

<DefaultValue> <ParmType> Default value assigned to parameter

where <RptParmList> is:

<RptParmList> is <NullRPList> | <RPList>

<NullRPList> is $REPORT \t $END

<RPList> is $REPORT \t <RList> \t $END

<RList> is <ReportParm> | <ReportParm> \t <RList>

<ReportParm> is <RptName> \t <EUs>

where <ReportParm> is:


<RptName> ASCII - String Report parameter name

<EUs> ASCII - String Engineering units for report parameter

where <PrevElemIDList> is:

<PrevElemIDList> is <ElemIDList>

where <NextElemIDList> is:

<NextElemIDList> is <ElemIDList>

where <ElemIDList> is:

<ElemIDList> is <ElemID> | <ElemID> \t <ElemIDList>


<ElemID> ASCII - Integer Element identifier




Example: A request on object.GetItem(17Data) (Procedure Level of MCLS_FRENCHVANILLA) could return: 0 \crlf \crlf French Vanilla Premium - class based/material based \crlf MCLS_FRENCHVANILLA \crlf FV-101 \crlf 1.0 \crlf Mark Shepard \crlf 2/24/2017 10:11:30 AM \crlf 30000 \t 30000 \crlf AREA1 \crlf \crlf \crlf 0 \t 572 \t MCLS_FRENCHVANILLA.BPC \t $PARM \t MILK_AMOUNT \t 1 \t 1 \t KG \t 5000 \t 0 \t 1999 \t SUGAR_AMOUNT \t 1 \t 1 \t KG \t 1500 \t 0 \t 750 \t CREAM_AMOUNT \t 1 \t 1 \t KG \t 5000 \t 0 \t 2001 \t EGG_AMOUNT \t 1 \t 1 \t KG \t 500 \t 0 \t 230 \t FLAVOR_AMOUNT \t 1 \t 1 \t KG \t 100 \t 0 \t 20 \t $END \crlf 1 \t 573 \t 700 \t 100 \crlf 5 \t 574 \t 573 \t 575 \crlf 4 \t 575 \t 800 \t 398 \t TRUE \crlf 5 \t 576 \t 575 \t 577 \crlf 3 \t 577 \t 600 \t 598 \t MCLS_SWEETCREAM_UP:1 \t MCLS_SWEETCREAM_UP.UPC \t $PARM \t MILK_AMOUNT \t 1 \t 3 \t KG \t 5000 \t 0 \t 0 \t SUGAR_AMOUNT \t 1 \t 3 \t KG \t 1500 \t 0 \t 0 \t CREAM_AMOUNT \t 1 \t 3 \t KG \t 5000 \t 0 \t 0 \t EGG_AMOUNT \t 1 \t 3 \t KG \t 500 \t 0 \t 0 \t $END \t $REPORT \t $END \crlf 5 \t 578 \t 577 \t 579 \crlf 4 \t 579 \t 800 \t 898 \t MCLS_SWEETCREAM_UP:1.STATE = COMPLETE \crlf 8 \t 580 \t 579 \t 590 \t 581 \crlf 3 \t 590 \t 200 \t 1300 \t MCLS_TRANSFER_OUT_UP:1 \t MCLS_TRANSFER_OUT_UP.UPC \t $PARM \t \t $END \t $REPORT \t $END \crlf 3 \t 581 \t 900 \t 1300 \t MCLS_TRANSFER_IN_UP:1 \t MCLS_TRANSFER_IN_UP.UPC \t $PARM \t \t $END \t $REPORT \t $END \crlf 4 \t 583 \t 800 \t 1800 \t MCLS_TRANSFER_IN_UP:1.STATE = COMPLETE AND MCLS_TRANSFER_OUT_UP:1.STATE = COMPLETE \crlf 9 \t 582 \t 583 \t 590 \t 581 \crlf 5 \t 584 \t 583 \t 585 \crlf 3 \t 585 \t 600 \t 2000 \t MCLS_FRENCHVANILLA_UP:1 \t MCLS_FRENCHVANILLA_UP.UPC \t $PARM \t FLAVOR_AMOUNT \t 1 \t 3 \t KG \t 100 \t 0 \t 0 \t $END \t $REPORT \t $END \crlf 5 \t 586 \t 585 \t 587 \crlf 4 \t 587 \t 800 \t 2400 \t MCLS_FRENCHVANILLA_UP:1.STATE = COMPLETE \crlf 5 \t 588 \t 587 \t 589 \crlf 2 \t 589 \t 800 \t 2700 \crlf



Example: A request on object.GetItem(17 \t MCLS_SWEETCREAM_UP:1 \t MCLS_SWEETCREAM_OP:1DATA) (Operation Level of MCLS_FRENCHVANILLA) could return: 0 \crlf \crlf Sweetcream operation - class based/material based \crlf MCLS_SWEETCREAM_OP \crlf SWC-101 \crlf 1.0 \crlf Mark S. Shepard \crlf 2/28/2017 7:14:07 AM \crlf 30000 \t 30000 \crlf AREA1 \crlf \crlf NP_MIXER1 \crlf 0 \t 162 \t MCLS_SWEETCREAM_OP.UOP \t $PARM \t MILK_AMOUNT \t 1 \t 3 \t KG \t 5000 \t 0 \t 0 \t SUGAR_AMOUNT \t 1 \t 3 \t KG \t 1500 \t 0 \t 0 \t CREAM_AMOUNT \t 1 \t 3 \t KG \t 5000 \t 0 \t 0 \t EGG_AMOUNT \t 1 \t 3 \t KG \t 500 \t 0 \t 0 \t $END \crlf 1 \t 167 \t 700 \t 100 \crlf 5 \t 168 \t 167 \t 169 \crlf 4 \t 169 \t 800 \t 398 \t TRUE \crlf 8 \t 170 \t 169 \t 184 \t 185 \t 171 \crlf 3 \t 184 \t 600 \t 698 \t MBR_ADD:1 \t \t $PARM \t MATERIAL \t 5 \t 4 \t MATERIALS \t \t \t NULL_MATERIAL \t AMOUNT \t 1 \t 3 \t \t 5000 \t 0 \t 0 \t $BINDCONTAINER \t 3 \t 5 \t \t \t \t \t $BINDEQMODULE \t 3 \t 5 \t \t \t \t \t $END \t $REPORT \t ACTUAL_AMOUNT \t ENG. UNITS \t FEED_COMPLETE \t YES_NO \t $END \crlf 3 \t 185 \t 1400 \t 698 \t MBR_ADD:2 \t \t $PARM \t MATERIAL \t 5 \t 4 \t MATERIALS \t \t \t NULL_MATERIAL \t AMOUNT \t 1 \t 3 \t \t 5000 \t 0 \t 0 \t $BINDCONTAINER \t 3 \t 5 \t \t \t \t \t $BINDEQMODULE \t 3 \t 5 \t \t \t \t \t $END \t $REPORT \t ACTUAL_AMOUNT \t ENG. UNITS \t FEED_COMPLETE \t YES_NO \t $END \crlf 3 \t 171 \t 2500 \t 700 \t AGITATE:1 \t \t $PARM \t SPEED_RATE \t 1 \t 1 \t RPM \t 50 \t 0 \t 5 \t $END \t $REPORT \t MIX_SPEED \t RPM \t $END \crlf 4 \t 182 \t 800 \t 1096 \t MBR_ADD:2.STATE = COMPLETE AND MBR_ADD:1.STATE = COMPLETE \crlf 9 \t 183 \t 182 \t 184 \t 185 \crlf 8 \t 181 \t 182 \t 180 \t 186 \crlf 3 \t 180 \t 600 \t 1396 \t MBR_ADD:3 \t \t $PARM \t MATERIAL \t 5 \t 4 \t MATERIALS \t \t \t NULL_MATERIAL \t AMOUNT \t 1 \t 3 \t \t 5000 \t 0 \t 0 \t $BINDCONTAINER \t 3 \t 5 \t \t \t \t \t $BINDEQMODULE \t 3 \t 5 \t \t \t \t \t $END \t $REPORT \t ACTUAL_AMOUNT \t ENG. UNITS \t FEED_COMPLETE \t YES_NO \t $END \crlf 3 \t 186 \t 1400 \t 1400 \t TEMP_CTL:1 \t \t $PARM \t TEMP_SP \t 1 \t 1 \t DEG C \t 100 \t 0 \t 71.1 \t HOLD_TIME \t 1 \t 2 \t MINUTES \t 60 \t 0 \t 5 \t $END \t $REPORT \t TEMPERATURE \t DEG F \t TIME_HELD \t MIN \t $END \crlf 4 \t 178 \t 800 \t 1794 \t TEMP_CTL:1.STATE = COMPLETE AND MBR_ADD:3.STATE = COMPLETE \crlf 9 \t 179 \t 178 \t 180 \t 186 \crlf 5 \t 177 \t 178 \t 176 \crlf 3 \t 176 \t 600 \t 1994 \t MBR_ADD:4 \t \t $PARM \t MATERIAL \t 5 \t 4 \t MATERIALS \t \t \t NULL_MATERIAL \t AMOUNT \t 1 \t 3 \t \t 5000 \t 0 \t 0 \t $BINDCONTAINER \t 3 \t 5 \t \t \t \t \t $BINDEQMODULE \t 3 \t 5 \t \t \t \t \t $END \t $REPORT \t ACTUAL_AMOUNT \t ENG. UNITS \t FEED_COMPLETE \t YES_NO \t $END \crlf 4 \t 173 \t 800 \t 2500 \t MBR_ADD:4.STATE = COMPLETE \crlf 9 \t 172 \t 173 \t 176 \t 171 \crlf 5 \t 174 \t 173 \t 175 \crlf 2 \t 175 \t 800 \t 2700 \crlf

See also




The ProcedureIDData2 item returns detailed data regarding the specified level of a procedure. Query each recipe level to get complete recipe details. The data returned by this item is static; obtain this item again to reflect any updates.


Input Format Request: ProcedureIDData2




OperationLevel is CreateID \t UnitProcedureName \t OperationName

Output Format The ProcedureIDData2 item returns in this format:


where:



















where <DocDim> is:

ProcedureIDData2









<RecipeElem> is <ParentStep> | <InitialStep> | <TerminalStep> | <RegularStep> | <Transition> | <EqModLink> | <OrDiverg> | <OrConverg> | <AndDiverg> | <AndConverg> | <TextBox>

<ParentStep> is <ElemType> \t <ElemID> \t <RecipeLink> \t <ParmList> \t <RptParmList>




<Transition> is <ElemType> \t <ElemID> \t <DrawXCord> \t <DrawYCord> \t <TransitionName> \t <ConditionExpression>






<TextBox> is <ElemType> \t <Size> \t <Comment> \t <Associated Element> \t <TextBoxID>





<ElemType> ASCII - Integer Recipe Element Type 0 = Parent Step 1 = Initial Step 2 = Terminal Step 3 = Regular Step 4 = Transition 5 = Link 6 = OR Divergence 7 = OR Convergence 8 = AND Divergence 9 = AND Convergence 10 = Text box


<RecipeLink> ASCII-Integer Path to the recipe file and recipe.


<DrawYCoord> ASCII-Integer Y coordinate for drawing the element.





<Condition Expression> ASCII - String Condition expression text of a transition element.





<TransitionName> ASCII - String Name of a transition: T followed by a unique number. For example, T55.

<Size> Fixed List Coordinates of the text box (upper left-hand corner and lower right-hand corner).

<Comment> ASCII - String The FactoryTalk Batch Server encodes these characters found in any text box comments: CharacterReplacement Sequence / /FS List Separator /LS ( /OP ) /CP \t /TAB crlf /CRLF

<Associated Element> ASCII - String Name of step or transition that text box is associated with. If the text box is NOT associated with a step or transition, this field is empty.

<TextBoxID> ASCII - String Name of text box: C followed by a unique number. For example, C53.

where <Size> is:

<Size> is <Left> \t <Top> \t <Right> \t <Bottom>

where:

<Left> ASCII - Number X coordinate for upper left hand corner.

<Top> ASCII - Number Y coordinate for upper left hand corner.



<Right> ASCII - Number X coordinate for lower right hand corner.

<Bottom> ASCII - Number Y coordinate for lower right hand corner.






<Parameter> is <ParmName> \t <ParmType> \t <ParmKind> \t <EUs> \t <MaxValue> \t <MinValue> \t <DefaultValue> \t <ParamExpressionID>



<ParmName> ASCII - String Parameter name $BINDCONTAINER - for container only $BINDEQMODULE - for phase only

<ParmType> ASCII - Integer Data type 1: Real 3: String 2: Long 5: Enumeration

<ParmKind> ASCII - Integer Kind of parameter 1: Value 4: Static 2: UnAcked Prompt 5: Material Data 3: Deferred 6: Expression

<EUs> ASCII - String Engineering unit If <ParmType> = 5, then this is the enumeration set If <ParmType> = 3, then a space




<ParamExpressionID> ASCII - Variable If 0, parameter is not an expression If a unique positive integer, parameter is an expression






<ReportParm> is <RptName> \t <EUs> \t <ReportExpressionID>







<ReportExpressionID> ASCII - Variable If 0, report is not an expression If a unique positive integer, report is an expression












Example: A request on object.GetItem(17Data) (Procedure Level of MCLS_FRENCHVANILLA) could return: 0 \crlf \crlf French Vanilla Premium - class based/material based \crlf MCLS_FRENCHVANILLA \crlf FV-101 \crlf 1.0 \crlf Mark Shepard \crlf 2/24/2017 10:11:30 AM \crlf 30000 \t 30000 \crlf AREA1 \crlf \crlf \crlf 0 \t 572 \t MCLS_FRENCHVANILLA.BPC \t $PARM \t MILK_AMOUNT \t 1 \t 1 \t KG \t 5000 \t 0 \t 1999 \t SUGAR_AMOUNT \t 1 \t 1 \t KG \t 1500 \t 0 \t 750 \t CREAM_AMOUNT \t 1 \t 1 \t KG \t 5000 \t 0 \t 2001 \t EGG_AMOUNT \t 1 \t 1 \t KG \t 500 \t 0 \t 230 \t FLAVOR_AMOUNT \t 1 \t 1 \t KG \t 100 \t 0 \t 20 \t $END \crlf 1 \t 573 \t 700 \t 100 \crlf 5 \t 574 \t 573 \t 575 \crlf 4 \t 575 \t 800 \t 398 \t T51 \t TRUE \crlf 5 \t 576 \t 575 \t 577 \crlf 3 \t 577 \t 600 \t 598 \t MCLS_SWEETCREAM_UP:1 \t MCLS_SWEETCREAM_UP.UPC \t $PARM \t MILK_AMOUNT \t 1 \t 3 \t KG \t 5000 \t 0 \t 0 \t SUGAR_AMOUNT \t 1 \t 3 \t KG \t 1500 \t 0 \t 0 \t CREAM_AMOUNT \t 1 \t 3 \t KG \t 5000 \t 0 \t 0 \t EGG_AMOUNT \t 1 \t 3 \t KG \t 500 \t 0 \t 0 \t $END \t $REPORT \t $END \crlf 5 \t 578 \t 577 \t 579 \crlf 4 \t 579 \t 800 \t 898 \t T55 \t MCLS_SWEETCREAM_UP:1.STATE = COMPLETE \crlf 8 \t 580 \t 579 \t 590 \t 581 \crlf 3 \t 590 \t 200 \t 1300 \t MCLS_TRANSFER_OUT_UP:1 \t MCLS_TRANSFER_OUT_UP.UPC \t $PARM \t \t $END \t $REPORT \t $END \crlf 3 \t 581 \t 900 \t 1300 \t MCLS_TRANSFER_IN_UP:1 \t MCLS_TRANSFER_IN_UP.UPC \t $PARM \t \t $END \t $REPORT \t $END \crlf 4 \t 583 \t 800 \t 1800 \t T56 \t MCLS_TRANSFER_IN_UP:1.STATE = COMPLETE AND MCLS_TRANSFER_OUT_UP:1.STATE = COMPLETE \crlf 9 \t 582 \t 583 \t 590 \t 581 \crlf 5 \t 584 \t 583 \t 585 \crlf 3 \t 585 \t 600 \t 2000 \t MCLS_FRENCHVANILLA_UP:1 \t MCLS_FRENCHVANILLA_UP.UPC \t $PARM \t FLAVOR_AMOUNT \t 1 \t 3 \t KG \t 100 \t 0 \t 0 \t $END \t $REPORT \t $END \crlf 5 \t 586 \t 585 \t 587 \crlf 4 \t 587 \t 800 \t 2400 \t T60 \t MCLS_FRENCHVANILLA_UP:1.STATE = COMPLETE \crlf 5 \t 588 \t 587 \t 589 \crlf 2 \t 589 \t 800 \t 2700 \crlf



Example: A request on object.GetItem(17 \t MCLS_SWEETCREAM_UP:1 \t MCLS_SWEETCREAM_OP:1DATA) (Operation Level of MCLS_FRENCHVANILLA) could return: 0 \crlf \crlf Sweetcream operation - class based/material based \crlf MCLS_SWEETCREAM_OP \crlf SWC-101 \crlf 1.0 \crlf Mark S. Shepard \crlf 2/28/2017 7:14:07 AM \crlf 30000 \t 30000 \crlf AREA1 \crlf \crlf NP_MIXER1 \crlf 0 \t 162 \t MCLS_SWEETCREAM_OP.UOP \t $PARM \t MILK_AMOUNT \t 1 \t 3 \t KG \t 5000 \t 0 \t 0 \t SUGAR_AMOUNT \t 1 \t 3 \t KG \t 1500 \t 0 \t 0 \t CREAM_AMOUNT \t 1 \t 3 \t KG \t 5000 \t 0 \t 0 \t EGG_AMOUNT \t 1 \t 3 \t KG \t 500 \t 0 \t 0 \t $END \crlf 1 \t 167 \t 700 \t 100 \crlf 5 \t 168 \t 167 \t 169 \crlf 4 \t 169 \t 800 \t 398 \t T12 \t TRUE \crlf 8 \t 170 \t 169 \t 184 \t 185 \t 171 \crlf 3 \t 184 \t 600 \t 698 \t MBR_ADD:1 \t \t $PARM \t MATERIAL \t 5 \t 4 \t MATERIALS \t \t \t NULL_MATERIAL \t AMOUNT \t 1 \t 3 \t \t 5000 \t 0 \t 0 \t $BINDCONTAINER \t 3 \t 5 \t \t \t \t \t $BINDEQMODULE \t 3 \t 5 \t \t \t \t \t $END \t $REPORT \t ACTUAL_AMOUNT \t ENG. UNITS \t FEED_COMPLETE \t YES_NO \t $END \crlf 3 \t 185 \t 1400 \t 698 \t MBR_ADD:2 \t \t $PARM \t MATERIAL \t 5 \t 4 \t MATERIALS \t \t \t NULL_MATERIAL \t AMOUNT \t 1 \t 3 \t \t 5000 \t 0 \t 0 \t $BINDCONTAINER \t 3 \t 5 \t \t \t \t \t $BINDEQMODULE \t 3 \t 5 \t \t \t \t \t $END \t $REPORT \t ACTUAL_AMOUNT \t ENG. UNITS \t FEED_COMPLETE \t YES_NO \t $END \crlf 3 \t 171 \t 2500 \t 700 \t AGITATE:1 \t \t $PARM \t SPEED_RATE \t 1 \t 1 \t RPM \t 50 \t 0 \t 5 \t $END \t $REPORT \t MIX_SPEED \t RPM \t $END \crlf 4 \t 182 \t 800 \t 1096 \t T13 \t MBR_ADD:2.STATE = COMPLETE AND MBR_ADD:1.STATE = COMPLETE \crlf 9 \t 183 \t 182 \t 184 \t 185 \crlf 8 \t 181 \t 182 \t 180 \t 186 \crlf 3 \t 180 \t 600 \t 1396 \t MBR_ADD:3 \t \t $PARM \t MATERIAL \t 5 \t 4 \t MATERIALS \t \t \t NULL_MATERIAL \t AMOUNT \t 1 \t 3 \t \t 5000 \t 0 \t 0 \t $BINDCONTAINER \t 3 \t 5 \t \t \t \t \t $BINDEQMODULE \t 3 \t 5 \t \t \t \t \t $END \t $REPORT \t ACTUAL_AMOUNT \t ENG. UNITS \t FEED_COMPLETE \t YES_NO \t $END \crlf 3 \t 186 \t 1400 \t 1400 \t TEMP_CTL:1 \t \t $PARM \t TEMP_SP \t 1 \t 1 \t DEG C \t 100 \t 0 \t 71.1 \t HOLD_TIME \t 1 \t 2 \t MINUTES \t 60 \t 0 \t 5 \t $END \t $REPORT \t TEMPERATURE \t DEG F \t TIME_HELD \t MIN \t $END \crlf 4 \t 178 \t 800 \t 1794 \t T14 \t TEMP_CTL:1.STATE = COMPLETE AND MBR_ADD:3.STATE = COMPLETE \crlf 9 \t 179 \t 178 \t 180 \t 186 \crlf 5 \t 177 \t 178 \t 176 \crlf 3 \t 176 \t 600 \t 1994 \t MBR_ADD:4 \t \t $PARM \t MATERIAL \t 5 \t 4 \t MATERIALS \t \t \t NULL_MATERIAL \t AMOUNT \t 1 \t 3 \t \t 5000 \t 0 \t 0 \t $BINDCONTAINER \t 3 \t 5 \t \t \t \t \t $BINDEQMODULE \t 3 \t 5 \t \t \t \t \t $END \t $REPORT \t ACTUAL_AMOUNT \t ENG. UNITS \t FEED_COMPLETE \t YES_NO \t $END \crlf 4 \t 173 \t 800 \t 2500 \t T15 \t MBR_ADD:4.STATE = COMPLETE \crlf 9 \t 172 \t 173 \t 176 \t 171 \crlf 5 \t 174 \t 173 \t 175 \crlf 2 \t 175 \t 800 \t 2700 \crlf 10 \t 820 \t 1096 \t 880 \t 1140 \t This is comment \t MBR_ADD:1 \t C10 \crlf

See also




The ProcedureIDData3 item returns detailed data regarding the specified level of a procedure. Query each recipe level to get complete recipe details. The data returned by this item is static; obtain this item again to reflect any updates.


Input Format Request: ProcedureIDData3




OperationLevel is CreateID \t UnitProcedureName \t OperationName

Output Format The ProcedureIDData3 item returns in this format:


where:



















where <DocDim> is:

ProcedureIDData3









<RecipeElem> is <ParentStep> | <InitialStep> | <TerminalStep> | <RegularStep> | <Transition> | <EqModLink> | <OrDiverg> | <OrConverg> | <AndDiverg> | <AndConverg> | <TextBox>

<ParentStep> is <ElemType> \t <ElemID> \t <RecipeLink> \t <ParmList> \t <RptParmList>




<Transition> is <ElemType> \t <ElemID> \t <DrawXCord> \t <DrawYCord> \t <TransitionName> \t <ConditionExpression>






<TextBox> is <ElemType> \t <Size> \t <Comment> \t <Associated Element> \t <TextBoxID>





<ElemType> ASCII - Integer Recipe Element Type 0 = Parent Step 1 = Initial Step 2 = Terminal Step 3 = Regular Step 4 = Transition 5 = Link 6 = OR Divergence 7 = OR Convergence 8 = AND Divergence 9 = AND Convergence 10 = Text box


<RecipeLink> ASCII-Integer Path to the recipe file and recipe.


<DrawYCoord> ASCII-Integer Y coordinate for drawing the element.





<Condition Expression> ASCII - String Condition expression text of a transition element.





<TransitionName> ASCII - String Name of a transition: T followed by a unique number. For example, T55.

<Size> Fixed List Coordinates of text box (upper left-hand corner and lower right-hand corner).

<Comment> ASCII - String The FactoryTalk Batch Server encodes these characters found in any text box comments: CharacterReplacement Sequence / /FS List Separator /LS ( /OP ) /CP \t /TAB crlf /CRLF

<Associated Element> ASCII - String Name of step or transition that text box is associated with. If the text box is NOT associated with a step or transition, this field is empty.

<TextBoxID> ASCII - String Name of text box: C followed by a unique number. For example, C53.

where <Size> is:

<Size> is <Left> \t <Top> \t <Right> \t <Bottom>

where:

<Left> ASCII - Number X coordinate for upper left hand corner.



<Top> ASCII - Number Y coordinate for upper left hand corner.

<Right> ASCII - Number X coordinate for lower right hand corner.

<Bottom> ASCII - Number Y coordinate for lower right hand corner.






<Parameter> is <ParmName> \t <ParmType> \t <ParmKind> \t <EUs> \t <MaxValue> \t <MinValue> \t <DefaultValue> \t <ParamExpressionID>



<ParmName> ASCII - String Parameter name $BINDCONTAINER - for container only $BINDEQMODULE - for phase only

<ParmType> ASCII - Integer Data type 1: Real 3: String 2: Long 5: Enumeration

<ParmKind> ASCII - Integer Kind of parameter 1: Value 4: Static 2: UnAcked Prompt 5: Material Data 3: Deferred 6: Expression

<EUs> ASCII - String Engineering unit If <ParmType> = 5, then this is the enumeration set If <ParmType> = 3, then a space




<ParamExpressionID> ASCII - Variable If 0, parameter is not an expression If a unique positive integer, parameter is an expression






<ReportParm> is <RptName> \t <EUs> \t <ReportExpressionID>







<ReportExpressionID> ASCII - Variable If 0, report is not an expression If a unique positive integer, report is an expression












Example: A request on object.GetItem(17Data) (Procedure Level of MCLS_FRENCHVANILLA) could return: 0 \crlf \crlf French Vanilla Premium - class based/material based \crlf MCLS_FRENCHVANILLA \crlf FV-101 \crlf 1.0 \crlf Mark Shepard \crlf 2/24/2017 10:11:30 AM \crlf 30000 \t 30000 \crlf AREA1 \crlf \crlf \crlf 0 \t 572 \t MCLS_FRENCHVANILLA.BPC \t $PARM \t MILK_AMOUNT \t 1 \t 1 \t KG \t 5000 \t 0 \t 1999 \t SUGAR_AMOUNT \t 1 \t 1 \t KG \t 1500 \t 0 \t 750 \t CREAM_AMOUNT \t 1 \t 1 \t KG \t 5000 \t 0 \t 2001 \t EGG_AMOUNT \t 1 \t 1 \t KG \t 500 \t 0 \t 230 \t FLAVOR_AMOUNT \t 1 \t 1 \t KG \t 100 \t 0 \t 20 \t $END \crlf 1 \t 573 \t 700 \t 100 \crlf 5 \t 574 \t 573 \t 575 \crlf 4 \t 575 \t 800 \t 398 \t T51 \t TRUE \crlf 5 \t 576 \t 575 \t 577 \crlf 3 \t 577 \t 600 \t 598 \t MCLS_SWEETCREAM_UP:1 \t MCLS_SWEETCREAM_UP.UPC \t $PARM \t MILK_AMOUNT \t 1 \t 3 \t KG \t 5000 \t 0 \t 0 \t SUGAR_AMOUNT \t 1 \t 3 \t KG \t 1500 \t 0 \t 0 \t CREAM_AMOUNT \t 1 \t 3 \t KG \t 5000 \t 0 \t 0 \t EGG_AMOUNT \t 1 \t 3 \t KG \t 500 \t 0 \t 0 \t $END \t $REPORT \t $END \crlf 5 \t 578 \t 577 \t 579 \crlf 4 \t 579 \t 800 \t 898 \t T55 \t MCLS_SWEETCREAM_UP:1.STATE = COMPLETE \crlf 8 \t 580 \t 579 \t 590 \t 581 \crlf 3 \t 590 \t 200 \t 1300 \t MCLS_TRANSFER_OUT_UP:1 \t MCLS_TRANSFER_OUT_UP.UPC \t $PARM \t \t $END \t $REPORT \t $END \crlf 3 \t 581 \t 900 \t 1300 \t MCLS_TRANSFER_IN_UP:1 \t MCLS_TRANSFER_IN_UP.UPC \t $PARM \t \t $END \t $REPORT \t $END \crlf 4 \t 583 \t 800 \t 1800 \t T56 \t MCLS_TRANSFER_IN_UP:1.STATE = COMPLETE AND MCLS_TRANSFER_OUT_UP:1.STATE = COMPLETE \crlf 9 \t 582 \t 583 \t 590 \t 581 \crlf 5 \t 584 \t 583 \t 585 \crlf 3 \t 585 \t 600 \t 2000 \t MCLS_FRENCHVANILLA_UP:1 \t MCLS_FRENCHVANILLA_UP.UPC \t $PARM \t FLAVOR_AMOUNT \t 1 \t 3 \t KG \t 100 \t 0 \t 0 \t $END \t $REPORT \t $END \crlf 5 \t 586 \t 585 \t 587 \crlf 4 \t 587 \t 800 \t 2400 \t T60 \t MCLS_FRENCHVANILLA_UP:1.STATE = COMPLETE \crlf 5 \t 588 \t 587 \t 589 \crlf 2 \t 589 \t 800 \t 2700 \crlf



Example: A request on object.GetItem(17 \t MCLS_SWEETCREAM_UP:1 \t MCLS_SWEETCREAM_OP:1DATA) (Operation Level of MCLS_FRENCHVANILLA) could return: 0 \crlf \crlf Sweetcream operation - class based/material based \crlf MCLS_SWEETCREAM_OP \crlf SWC-101 \crlf 1.0 \crlf Mark S. Shepard \crlf 2/28/2017 7:14:07 AM \crlf 30000 \t 30000 \crlf AREA1 \crlf \crlf NP_MIXER1 \crlf 0 \t 162 \t MCLS_SWEETCREAM_OP.UOP \t $PARM \t MILK_AMOUNT \t 1 \t 3 \t KG \t 5000 \t 0 \t 0 \t SUGAR_AMOUNT \t 1 \t 3 \t KG \t 1500 \t 0 \t 0 \t CREAM_AMOUNT \t 1 \t 3 \t KG \t 5000 \t 0 \t 0 \t EGG_AMOUNT \t 1 \t 3 \t KG \t 500 \t 0 \t 0 \t $END \crlf 1 \t 167 \t 700 \t 100 \crlf 5 \t 168 \t 167 \t 169 \crlf 4 \t 169 \t 800 \t 398 \t T12 \t TRUE \crlf 8 \t 170 \t 169 \t 184 \t 185 \t 171 \crlf 3 \t 184 \t 600 \t 698 \t MBR_ADD:1 \t \t $PARM \t MATERIAL \t 5 \t 4 \t MATERIALS \t \t \t NULL_MATERIAL \t AMOUNT \t 1 \t 3 \t \t 5000 \t 0 \t 0 \t $BINDCONTAINER \t 3 \t 5 \t \t \t \t \t $BINDEQMODULE \t 3 \t 5 \t \t \t \t \t $END \t $REPORT \t ACTUAL_AMOUNT \t ENG. UNITS \t FEED_COMPLETE \t YES_NO \t $END \crlf 3 \t 185 \t 1400 \t 698 \t MBR_ADD:2 \t \t $PARM \t MATERIAL \t 5 \t 4 \t MATERIALS \t \t \t NULL_MATERIAL \t AMOUNT \t 1 \t 3 \t \t 5000 \t 0 \t 0 \t $BINDCONTAINER \t 3 \t 5 \t \t \t \t \t $BINDEQMODULE \t 3 \t 5 \t \t \t \t \t $END \t $REPORT \t ACTUAL_AMOUNT \t ENG. UNITS \t FEED_COMPLETE \t YES_NO \t $END \crlf 3 \t 171 \t 2500 \t 700 \t AGITATE:1 \t \t $PARM \t SPEED_RATE \t 1 \t 1 \t RPM \t 50 \t 0 \t 5 \t $END \t $REPORT \t MIX_SPEED \t RPM \t $END \crlf 4 \t 182 \t 800 \t 1096 \t T13 \t MBR_ADD:2.STATE = COMPLETE AND MBR_ADD:1.STATE = COMPLETE \crlf 9 \t 183 \t 182 \t 184 \t 185 \crlf 8 \t 181 \t 182 \t 180 \t 186 \crlf 3 \t 180 \t 600 \t 1396 \t MBR_ADD:3 \t \t $PARM \t MATERIAL \t 5 \t 4 \t MATERIALS \t \t \t NULL_MATERIAL \t AMOUNT \t 1 \t 3 \t \t 5000 \t 0 \t 0 \t $BINDCONTAINER \t 3 \t 5 \t \t \t \t \t $BINDEQMODULE \t 3 \t 5 \t \t \t \t \t $END \t $REPORT \t ACTUAL_AMOUNT \t ENG. UNITS \t FEED_COMPLETE \t YES_NO \t $END \crlf 3 \t 186 \t 1400 \t 1400 \t TEMP_CTL:1 \t \t $PARM \t TEMP_SP \t 1 \t 1 \t DEG C \t 100 \t 0 \t 71.1 \t HOLD_TIME \t 1 \t 2 \t MINUTES \t 60 \t 0 \t 5 \t $END \t $REPORT \t TEMPERATURE \t DEG F \t TIME_HELD \t MIN \t $END \crlf 4 \t 178 \t 800 \t 1794 \t T14 \t TEMP_CTL:1.STATE = COMPLETE AND MBR_ADD:3.STATE = COMPLETE \crlf 9 \t 179 \t 178 \t 180 \t 186 \crlf 5 \t 177 \t 178 \t 176 \crlf 3 \t 176 \t 600 \t 1994 \t MBR_ADD:4 \t \t $PARM \t MATERIAL \t 5 \t 4 \t MATERIALS \t \t \t NULL_MATERIAL \t AMOUNT \t 1 \t 3 \t \t 5000 \t 0 \t 0 \t $BINDCONTAINER \t 3 \t 5 \t \t \t \t \t $BINDEQMODULE \t 3 \t 5 \t \t \t \t \t $END \t $REPORT \t ACTUAL_AMOUNT \t ENG. UNITS \t FEED_COMPLETE \t YES_NO \t $END \crlf 4 \t 173 \t 800 \t 2500 \t T15 \t MBR_ADD:4.STATE = COMPLETE \crlf 9 \t 172 \t 173 \t 176 \t 171 \crlf 5 \t 174 \t 173 \t 175 \crlf 2 \t 175 \t 800 \t 2700 \crlf 10 \t 820 \t 1096 \t 880 \t 1140 \t This is comment \t MBR_ADD:1 \t C10 \crlf

See also




The ProcedureIDDevLimits item returns recipe and report parameter limits for a procedure.


Input Format Request: ProcedureIDDevLimits





Output Format <ProcIDDev Limits>

is <ElemList>

where <ElemList> is:

<ElemList> is <RegularStep> \crlf <RegularStep>

<RegularStep> is <Name> \t <ParmLimitList> \t <RptLimitList>


<Name> ASCII - Integer Step name For example: PHASE1:1

where <ParamLimitList> is:

<ParamLimitList> is $PARM \t <ParameterLimits> \t $END

<ParameterLimits> is <NullParmList> | <PList>


<PList> is <ParameterLimit> | <ParameterLimits> \t <PList>

<ParameterLimit> is <ParamName> \t <VerificationMethod> \t <HighHighHighLimit> \t <HighHighLimit> \t <HighLimit> \t <LowLimit> \t <LowLowLimit> \t <LowLowLowLimit>

where <ParameterLimit> is:


<ParmName> ASCII - String Parameter name.

<Verification Method>

ASCII - Integer Parameter verification method:

• 0 = No Limits

• 1 = High/Low

• 2 = High-High/Low-Low

• 3 = High-High-High/Low-Low-Low

<HighHighHighLimit> ASCII - Integer High-High-High Limit

ProcedureIDDevLimits







<LowLowLowLimit> ASCII - Integer Low-Low-Low Limit

where <RptLimitList> is:

<RptLimitList> is $REPORT \t <ReportLimits> \t$END

<ReportLimits> is <NullRptList> | <RPList>

<NullRptList> is <sp>

<RPList> is <ReportLimit> | <ReportLimit> \t <RPList>

<ReportLimit> is <ReportName> \t <VerificationMethod> \t <HighHighHighLimit> \t <HighHighLimit> \t <HighLimit> \t <LowLimit> \t <LowLowLimit> \t <LowLowLowLimit>

where <ReportLimit> is:


<ReportName> ASCII - String Report name.

<Verification Method>

ASCII - Integer Parameter verification method: • 0 = No Limits

• 1 = High/Low

• 2 = High-High/Low-Low

• 3 = High-High-High/Low-Low-Low

<HighHighHighLimit> ASCII - Integer High-High-High Limit





<LowLowLowLimit> ASCII - Integer Low-Low-Low Limit

See also




The ProcedureIDStatus item returns data regarding the status of a specified procedure level. Query each recipe level to get complete recipe details.


Input Format Request: ProcedureIDStatus





Output Format <ProcIDStatus> is <SVRSignal> \crlf <ElemList>

where:


<SVRSignal> ASCII - Integer 0=Continue update of data for this advise 1=Discontinue update of data for this advise


<ElemList> is <ParentStep> \crlf <ChildElemList>

<ParentStep> is <RegularStep>

<RegularStep> is <ID> \t <Name> \t <SP88Type> \t <KeyPName> \t <KeyValue> \t <State> \t <Mode> \t <UnitName> \t <Control> \t <Index> \t <Paused> \t <Msg> \t <Rqst> \t <Fail> \t <ParmList> \t <RptParmList> \t <OwnerID> \t <OwnerName> \t <CmdMask>

<ChildElemList> is <RecipeElement> \crlf | <RecipeElement> \crlf <ChildElemList>

<RecipeElement> is <InitialStep> | <TerminalStep> | <Transition> | <RegularStep>

<InitialStep> is <ElemID> \t <ElemState> \t <FailureMsg>

<TerminalStep> is <ElemID> \t <ElemState> \t <FailureMsg>

<Transition> is <ElemID> \t <ElemState> \t <FailureMsg> \t <RqstAcquire> \t <Paused>

where <InitialStep> is:


<ElemID> ASCII - Integer Element ID (defined by ProcedureIDData data item).

<ElemState> ASCII - String Element state

ProcedureIDStatus



<FailureMsg> ASCII - String Failure message, single space if not active or if there are no failures.

where <TerminalStep> is:





where <Transition> is:





<RqstAcquire> ASCII - Integer Displays a string that equates to the value of the transition’s Firing Attribute: 0 = " " 4 = "Stopping" 1 = "Acquiring" 5 = "Resetting" 2 = "Binding" 6 = "Pending" 3 = "Committed" 7 = "Paused"

<Paused> ASCII - Integer Not used, replaced with the firing attribute and only supported for legacy systems.

where <RegularStep> is:


<ID> ASCII - Integer Element ID (defined by ProcedureIDData data item).

<Name> ASCII - String Element name.


• 1 = Procedure

• 2 = Unit procedure

• 3 = Operation

• 4 = Phase

<KeyPName> ASCII - String Key parameter name; may contain a single space if the step does not have a key parameter value.

<KeyValue> ASCII - String Step key value; may contain a single space if the step does not have a key parameter value

<State> ASCII - String Element state; the value can be a single space character if the step is not an active element.

<Mode> ASCII - String Returns the step mode when the step is active or inactive.

<UnitName> ASCII - String Unit step runs under; the value can be a single space character if the step is not associated with a single unit. For example, BPC batch step.



<Control> ASCII - String Who controls the Step • NONE

• PROGRAM

• EXTERNAL


<Index> ASCII - Integer Step Index; the value may be a single space character if the step is not an active recipe element.

<Paused> ASCII - Integer 0 = not paused, 1 = paused


<Rqst> ASCII- integer Step Request, contents of request register; the value may be a single space character if the step is not an active recipe element or is not a phase level step.

<Fail> ASCII - String Fail Message; the value may contain a single space character if there is no failure associated with the step.

<ParmList> Variable List of recipe parameters

<RptParmList> Variable List of report parameters

<OwnerID> ASCII - Integer ElemOwner ID only for phase steps, otherwise blank space character.

<OwnerName> ASCII - String Owner Name only for phase steps, otherwise blank space character.







<Parameter> is <ParmName> \t <CurrentValue>




<CurrentValue> ASCII - Integer Current value of parameter in recipe. Could also be the name of the container or the phase.



<NullRPList> is $REPORT \t <sp> \t $END





<ReportParm> is <ParmName> \t <ParmValue>



<ParmName> ASCII - String Report parameter name

<ParmValue> ASCII - Integer The value of the report parameter. This value displays ??? if the value is not yet assigned.


Example: A request on object.GetItem(17Status) could return: 0\crlf124\tBATCH_ID\t1\t\t \tHELD\tO_AUTO\t \tPROGRAM\t \t0\t \t \t \t$PARM\tMILK_AMOUNT\t1999\tSUGAR_AMOUNT\t750 \tCREAM_AMOUNT\t2001\tEGG_AMOUNT\t200 \tFLAVOR_AMOUNT\t50\t$END\t$REPORT\t \t$END\t \t \t2341\crlf129\t \t \crlf125\tCLS_FRENCHVANILLA_UP:1\t2 \tFLAVOR_AMOUNT\tWP_FREEZER1\t \tP_AUTO\tWP_FREEZER1\t \t \t0\t \t \t \t$PARM\tFLAVOR_AMOUNT\t50\t \t$END\t$REPORT\t \t$END\t \t \t32768\crlf126\tCLS_SWEETCREAM_UP:1\t2\t\tWP_MIXER1 \tHELD\tP_AUTO\tWP_MIXER1\tPROGRAM\t \t0\t \t \t \t$PARM\tMILK_AMOUNT\t1999\t \tSUGAR_AMOUNT\t750\t \tCREAM_AMOUNT\t2001\t \tEGG_AMOUNT\t200\t \t$END\t$REPORT\t \t$END\t \t \t2080\crlf127\tCLS_TRANSFER_IN_UP:1\t2\t\tWP_FREEZER1 \t \tP_AUTO\tWP_FREEZER1\t \t \t0\t \t \t \t$PARM\t \t$END\t$REPORT\t \t$END\t \t \t32768\crlf128\tCLS_TRANSFER_OUT_UP:1\t2 \t\tWP_MIXER1\t \tP_AUTO\tWP_MIXER1\t \t \t0\t \t \t \t$PARM\t \t$END\t$REPORT\t \t$END\t \t \t0\crlf130\t \t \crlf131\tIDLE\t \t0\t0\crlf132 \tHELD\t \t0\t0\crlf133\tIDLE\t \t0\t0\crlf134\tIDLE\t \t0\t0\crlf



Example: A request on object.GetItem(17 \t MCLS_SWEETCREAM_UP:1 \t MCLS_SWEETCREAM_OP:1Status) could return: 0 \crlf 162 \t MCLS_SWEETCREAM_OP:1 \t 3 \t \t \t HELD \t P_AUTO \t NP_MIXER1 \t PROGRAM \t \t 0 \t \t \t FEED_COMPLETE NOT COMPLETE. \t $PARM \t MILK_AMOUNT \t 1999 \t SUGAR_AMOUNT \t 750 \t CREAM_AMOUNT \t 2001 \t EGG_AMOUNT \t 230 \t $END \t $REPORT \t \t $END \t \t \t 2080 \crlf 167 \t \t \crlf 171 \t AGITATE:1 \t 4 \t SPEED_RATE \t 25 \t COMPLETE \t P_AUTO \t NP_MIXER1 \t PROGRAM \t 10 \t 0 \t \t 0 \t \t $PARM \t SPEED_RATE \t 25 \t $END \t $REPORT \t MIX_SPEED \t 0 \t $END \t -1112 \t 28:MCLS_FRENCHVANILLA\MCLS_SWEETCREAM_UP:1\MCLS_SWEETCREAM_OP:1 \t 32 \crlf 184 \t MBR_ADD:1 \t 4 \t \t \t \t \t NP_MIXER1 \t \t 0 \t \t \t \t \t $PARM \t MATERIAL \t EGG_YOLK \t AMOUNT \t 230 \t $BINDCONTAINER \t NULL_CONTAINER \t $BINDEQMODULE \t \t $END \t $REPORT \t ACTUAL_AMOUNT \t 0 \t FEED_COMPLETE \t NO \t $END \t \t \t 262144 \crlf 185 \t MBR_ADD:2 \t 4 \t \t \t \t \t NP_MIXER1 \t \t 0 \t \t \t \t \t $PARM \t MATERIAL \t SUGAR_GRANULATED \t AMOUNT \t 750 \t $BINDCONTAINER \t NULL_CONTAINER \t $BINDEQMODULE \t \t $END \t $REPORT \t ACTUAL_AMOUNT \t 0 \t FEED_COMPLETE \t NO \t $END \t \t \t 262144 \crlf 180 \t MBR_ADD:3 \t 4 \t \t \t \t \t NP_MIXER1 \t \t 0 \t \t \t \t \t $PARM \t MATERIAL \t CREAM \t AMOUNT \t 2001 \t $BINDCONTAINER \t NULL_CONTAINER \t $BINDEQMODULE \t \t $END \t $REPORT \t ACTUAL_AMOUNT \t 0 \t FEED_COMPLETE \t NO \t $END \t \t \t 262144 \crlf 176 \t MBR_ADD:4 \t 4 \t \t \t COMPLETE \t P_AUTO \t NP_MIXER1 \t PROGRAM \t 10 \t 0 \t FEED_COMPLETE NOT COMPLETE. \t 0 \t FEED_COMPLETE NOT COMPLETE. \t $PARM \t MATERIAL \t MILK \t AMOUNT \t 1999 \t $BINDCONTAINER \t DAIRY_WEST1 \t $BINDEQMODULE \t NP_ADDDAIRY_M1 \t $END \t $REPORT \t ACTUAL_AMOUNT \t 0 \t FEED_COMPLETE \t NO \t $END \t -1112 \t28:MCLS_FRENCHVANILLA\MCLS_SWEETCREAM_UP:1\MCLS_SWEETCREAM_OP:1 \t 32 \crlf 186 \t TEMP_CTL:1 \t 4 \t TEMP_SP \t 71.1 \t \t \t NP_MIXER1 \t \t 0 \t \t \t \t \t $PARM \t HOLD_TIME \t 5 \t TEMP_SP \t 71.1 \t $END \t $REPORT \t TEMPERATURE \t 0 \t TIME_HELD \t 0 \t $END \t \t \t 0 \crlf 175 \t \t \crlf 169 \t IDLE \t \t 0 \t 0 \crlf 182 \t IDLE \t \t 0 \t 0 \crlf 178 \t IDLE \t \t 0 \t 0 \crlf 173 \t HELD \t \t 0 \t 0 \crlf

See also






The ProcedureIDStatus2 item returns data regarding the status of a specified procedure level. Each recipe level must be queried to get the complete picture of the recipe.


Input Format Request: ProcedureIDStatus2





Output Format <ProcIDStatus2> is <SVRSignal> \crlf <ElemList>

where:


<SVRSignal> ASCII - Integer 0=continue update of data for this advise 1=discontinue update of data for this advise


<ElemList> is <ParentStep> \crlf <ChildElemList>

<ParentStep> is <RegularStep>

<RegularStep> is <ID> \t <Name> \t <SP88Type> \t <KeyPName> \t <KeyValue> \t <KeyValueStatus> \t <State> \t <Mode> \t <UnitName> \t <Control> \t <Index> \t <Paused> \t <Msg> \t <Rqst> \t <Fail> \t <ParmList> \t <RptParmList> \t <OwnerID> \t <OwnerName> \t <CmdMask>

<ChildElemList> is <RecipeElement> \crlf | <RecipeElement> \crlf <ChildElemList>

<RecipeElement> is <InitialStep> | <TerminalStep> | <Transition> | <RegularStep>

<InitialStep> is <ElemID> \t <ElemState> \t <FailureMsg>

<TerminalStep> is <ElemID> \t <ElemState> \t <FailureMsg>

<Transition> is <ElemID> \t <ElemState> \t <FailureMsg> \t <RqstAcquire> \t <Paused>

where <InitialStep> is:

ProcedureIDStatus2







where <TerminalStep> is:





where <Transition> is:





<RqstAcquire> ASCII - Integer Displays a string that equates to the value of the transition’s Firing Attribute: 0 = " " 4 = "Stopping" 1 = "Acquiring" 5 = "Resetting" 2 = "Binding" 6 = "Pending" 3 = "Committed" 7 = "Paused"

<Paused> ASCII - Integer Not used, replaced with Firing Attribute. Supported for legacy systems only.

where <RegularStep> is:


<ID> ASCII - Integer Element ID (defined by ProcedureIDData data item).

<Name> ASCII - String Element Name.

<SP88Type> ASCII - Integer Step Type: 0 = Null 3 = Operation 1 = Procedure 4 = Phase 2 = Unit Procedure

<KeyPName> ASCII - String Key Parameter Name; may contain a single space if the step does not have a key parameter value.

<KeyValue> ASCII - String Step’s Key Value;may contain a single space if the step does not have a key parameter value



<KeyValueStatus> ASCII - Integer Step’s Key Value Status of an expression: 0 or blank = "OK or not an expression" 1= "Override" 2="Exception" 3="Override", "Exception" 4="Out of Range" 5="Override", "Out of Range" 6="Exception","Out of Range" 7="Override", "Exception", "Out of Range" The field may contain a single space character if the step does not have a key parameter value or if the key parameter is not a parameter expression.

<State> ASCII - String Element State; the value can be a single space character if the step is not an active element.

<Mode> ASCII - String Returns the Step’s Mode when the step is active or inactive.

<UnitName> ASCII - String Unit Step runs under; the value can be a single space character if the step is not associated with a single Unit (for example, BPC batch step).

<Control> ASCII - String Who controls the Step NONE PROGRAM EXTERNAL This field may contain a single space character if the step is not an active recipe element.

<Index> ASCII - Integer Step Index; the value may be a single space character if the step is not an active recipe element.

<Paused> ASCII - Integer 0 = not paused, 1 = paused


<Rqst> ASCII- integer Step Request, contents of request register; the value may be a single space character if the step is not an active recipe element or is not a phase level step.

<Fail> ASCII - String Fail Message; the value may contain a single space character if there is no failure associated with the step.

<ParmList> Variable List of recipe parameters

<RptParmList> Variable List of report parameters

<OwnerID> ASCII - Integer ElemOwner ID only for phase steps, otherwise blank space character.

<OwnerName> ASCII - String Owner Name only for phase steps, otherwise blank space character.







<Parameter> is <ParmName> \t <CurrentValue> \t <CurrentStatus>






<CurrentValue> ASCII - Integer Current value of parameter in recipe. Could also be the name of the container or the phase.

<CurrentStatus> ASCII - Integer Current status of value if parameter is an expression: 0 or blank = "OK or not an expression" 1= "Override" 2="Exception" 3="Override", "Exception" 4="Out of Range" 5="Override", "Out of Range" 6="Exception","Out of Range" 7="Override", "Exception", "Out of Range" The field may contain a single space character if the parameter is not a parameter expression.



<NullRPList> is $REPORT \t <sp> \t $END



<ReportParm> is <ParmName> \t <ParmValue>



<ParmName> ASCII - String Report parameter name

<ParmValue> ASCII - Integer The value of the report parameter. This value displays ??? if the value is not yet assigned.




Example: A request on object.GetItem(17Status) could return: 0\crlf124\tBATCH_ID\t1\t\t \t \tHELD\tO_AUTO\t \tPROGRAM\t \t0\t \t \t \t$PARM\tMILK_AMOUNT\t1999\t \tSUGAR_AMOUNT\t750\t

\tCREAM_AMOUNT\t2001\t \tEGG_AMOUNT\t200\t \tFLAVOR_AMOUNT\t50\t \t$END\t$REPORT\t \t$END\t \t \t2341\crlf129 \t \t \crlf125\tCLS_FRENCHVANILLA_UP:1\t2 \tFLAVOR_AMOUNT\tWP_FREEZER1\t \t \tP_AUTO\tWP_FREEZER1\t \t \t0\t \t \t \t$PARM\tFLAVOR_AMOUNT\t50\t \t$END\t$REPORT\t \t$END\t \t \t32768\crlf126\tCLS_SWEETCREAM_UP:1\t2\t\tWP_MIXER1 \t \tHELD\tP_AUTO\tWP_MIXER1\tPROGRAM\t \t0\t \t \t \t$PARM\tMILK_AMOUNT\t1999\t \tSUGAR_AMOUNT\t750\t \tCREAM_AMOUNT\t2001\t \tEGG_AMOUNT\t200\t \t$END\t$REPORT\t \t$END\t \t \t2080\crlf127\tCLS_TRANSFER_IN_UP:1\t2\t\tWP_FREEZER1 \t \t \tP_AUTO\tWP_FREEZER1\t \t \t0\t \t \t \t$PARM\t \t$END\t$REPORT\t \t$END\t \t \t32768\crlf128 \tCLS_TRANSFER_OUT_UP:1\t2\t\tWP_MIXER1\t \t \tP_AUTO\tWP_MIXER1\t \t \t0\t \t \t \t$PARM\t \t$END\t$REPORT\t \t$END\t \t \t0\crlf130\t \t \crlf131\tIDLE\t \t0\t0\crlf132\tHELD\t \t0\t0 \crlf133\tIDLE\t \t0\t0\crlf134\tIDLE\t \t0\t0\crlf



Example: A request on object.GetItem(17 \t MCLS_SWEETCREAM_UP:1 \t MCLS_SWEETCREAM_OP:1Status) could return: 0/crlf422/tCLS_SWEETCREAM_OP:1/t3/t/t /t /tHELD/tP_AUTO/tWP_MIXER1/tPROGRAM/t /t0/t /t /t /t$PARM/tMILK_AMOUNT/t1999/t /tSUGAR_AMOUNT/t750/t /tCREAM_AMOUNT/t2001/t /tEGG_AMOUNT/t200/t /t$END/t$REPORT/t /t$END/t /t /t2080/crlf436/t /t /crlf431/tADD_CREAM:1/t4/tADD_AMOUNT/t2001/tKG/t /t /tP_AUTO/tWP_MIXER1/t /t /t0/t /t /t /t$PARM/tADD_AMOUNT/t2001/t /t$END/t$REPORT/tAMOUNT_ADDED/t???/t$END/t /t /t0/crlf432/tADD_EGG:1/t4/tADD_AMOUNT/t200/tKG/t /tHELD/tP_AUTO/tWP_MIXER1/tPROGRAM/t10/t0/t/t0/t /t$PARM/tADD_AMOUNT/t200/t /t$END/t$REPORT/tAMOUNT_ADDED/t???/t$END/t-1042/t36:CLS_FRENCHVANILLA\CLS_SWEETCREAM_UP:1\CLS_SWEETCREAM_OP:1/t32/crlf433/tADD_MILK:1/t4/tADD_AMOUNT/t1999/tKG/t /t /tP_AUTO/tWP_MIXER1/t /t /t0/t /t /t /t$PARM/tADD_AMOUNT/t1999/t /t$END/t$REPORT/tAMOUNT_ADDED/t???/t$END/t /t /t0/crlf434/tADD_SUGAR:1/t4/tADD_AMOUNT/t750/tKG/t /tHELD/tP_AUTO/tWP_MIXER1/tPROGRAM/t10/t0/t/t0/t /t$PARM/tADD_AMOUNT/t750/t /t$END/t$REPORT/tAMOUNT_ADDED/t???/t$END/t-1042/t36:CLS_FRENCHVANILLA\CLS_SWEETCREAM_UP:1\CLS_SWEETCREAM_OP:1/t32/crlf435/tAGITATE:1/t4/tSPEED_RATE/t25 RPM/t /tHELD/tP_AUTO/tWP_MIXER1/tPROGRAM/t10/t0/t/t0/t /t$PARM/tSPEED_RATE/t25/t /t$END/t$REPORT/tMIX_SPEED/t???/t$END/t-1042/t36:CLS_FRENCHVANILLA\CLS_SWEETCREAM_UP:1\CLS_SWEETCREAM_OP:1/t32/crlf437/tTEMP_CTL:1/t4/tTEMP_SP/t71.1/tDEG C/t /t /tP_AUTO/tWP_MIXER1/t /t /t0/t /t /t /t$PARM/tHOLD_TIME/t5/t /tTEMP_SP/t71.1/t /t$END/t$REPORT/tTEMPERATURE/t???/tTIME_HELD/t???/t$END/t /t /t0/crlf438/t /t /crlf439/tIDLE/t /t0/t0/crlf440/tHELD/t /t0/t0/crlf441/tIDLE/t /t0/t0/crlf442/tHELD/t /t0/t0/crlf

See also






The ProcedureIDUnitRequirements item returns the set of unit requirements configured within the specified recipe structure.


Input Format Request: ProcedureIDUnitRequirements

<ProcedureID> is ASCII - String, the unique path to the recipe step. This path begins with the CreateID. Use BLCreateID_x item to retrieve the CreateID.

for an Operation Recipe:

<Operation Level> is <CreateID>

for a Unit Procedure Recipe:

<Unit Procedure Level> is <CreateID>

<Operation Level> is <CreateID> \t Operation Name

for a Procedure Recipe:

<Procedure Level> is <CreateID>

<Unit Procedure Level> is <CreateID> \t UnitProcedure Name

<Operation Level> is <CreateID> \t UnitProcedure Name \t Operation Name

Output Format The ProcedureIDUnitRequirements item returns in this format:

<UnitRequirements> is <NullList> | <UnitReqList>

<UnitReqList> is <UnitRequirement> | <UnitRequirement> \crlf <UnitReqList>

<UnitRequirement> is <UnitReqName> /t <UnitReqID> /t <UnitReqType> /t <UnitReqClassOrInstanceName> <AssocStepList> /t $END <DownstreamUnitReqList>

<AssocStepList> is <NullList> | /t <AssocSteps>

<AssocSteps> is <ElemID> | <ElemID> /t <AssocSteps>

<DownstreamUnitReqList> is <NullList> | /t <DownstreamUnitReqs>

<DownstreamUnitReqs> is <DownstreamUnitReqID> | <DownstreamUnitReqID> /t <DownstreamUnitReqs>



<UnitReqName> ASCII - String Unit Requirement Name

<UnitReqID> ASCII - Integer Unique ID assigned to Unit Requirement

<UnitReqType> ASCII - Integer Unit Requirement Type Code: 1 = Unit Class 2 = Unit Instance

<UnitReqClassOr InstanceName>

ASCII - String Name of Unit Class or Unit Instance associated with Unit Requirement

ProcedureIDUnit Requirements



<ElemID> ASCII - Integer Unique ID of step associated with this Unit Requirement

<DownstreamUnitReqID> ASCII - Integer Unique ID of configure downstream Unit Requirement


Example: A request on object.GetItem(17UnitRequirements) could return: MAX_SPEED \t 13 \t 1 \t MIXER \t 127 \t $END \t 14 \crlf TEMP \t 14 \t 1 \t FREEZER \t 128 \t $END

See also


The ProcessCellBitMaps item returns the bitmap index for all the process cells within the equipment database loaded by the server.


Input Format Request: ProcessCellBitMaps

Output Format The ProcessCellBitMaps item returns in this format:

<ProcessCellBitMaps> is <NullList> | <BitMapList>

<BitMapList> is <BitMap> | <BitMap> \crlf <BitMapList>

<BitMap> is <BitMapIndex> \t <ProcessCellName>

<ProcessCellBitMaps> is <NullList> | <BitMapList>

where <BitMapList> is:


<BitMapIndex> ASCII - Integer Location of the bit map in the process cell items.

<ProcessCellName> ASCII - String The name of the process cell bitmap file.


Example: A request on object.GetItem(ProcessCellBitMaps) could return: 0 \t REFINERY.BMP \crlf 1 \t REFINERY.BMP \crlf

2 \t REFINERY.BMP \crlf 3 \t REFINERY.BMP \crlf

See also


ProcessCellBitMaps



The ProcessCellIDUnits item returns information about all units in a process cell, including how they are linked.


Input Format

Request only: ProcessCellIDUnits While Advise will return information, it would not normally be used as the data does not change during processing.

ProcessCellID is ASCII – Integer, the unique Equipment ID corresponding to the process cell

Output Format The ProcessCellIDUnits item returns in this format:

<PCellIDUnits> is <NullList> | <UnitList>

<NullList> is CString.Empty() \crlf

<UnitList> is <UnitData> \crlf | <UnitData> \crlf <UnitList>

<UnitData> is <UnitID> \t <UnitName> \t <UnitClass> \t <MaxOwners> \t <XCord> \t <YCord> \t <BitMapIndex> \t <Connections>

where <UnitData> is:


<UnitID> ASCII - Integer Resource ID configured in FactoryTalk Batch Equipment Editor.

<UnitName> ASCII - String Unit Name.

<UnitClass> ASCII - String Unit Class Name.

<MaxOwners> ASCII - Integer Max # of Owners as configured in FactoryTalk Batch Equipment Editor.

<XCord> ASCII - Integer X Coordinate for Equipment View.

<YCord> ASCII - Integer Y Coordinate for Equipment View.

<BitMapIndex> ASCII - Integer Location of bitmap in the list of Unit Bitmaps item.

<Connections> Variable Information about the units to which this unit is connected.

where <Connections> is:

<Connections> is $CONN \t <ConnData> \t $END

<ConnData> is <NullConnList> | <ConnList>

<NullConnList> is \t \t

<ConnList> is <UnitName> \t <UnitID>

where <ConnList> is:


<UnitName> ASCII - String Unit Name.

<UnitID> ASCII - Integer Resource ID configured in FactoryTalk Batch Equipment Editor.

ProcessCellIDUnits




Example: A request on object.GetItem(54Units) could return: 55 \t NP_MIXER1 \t MBR_MIXER_CLS \t 1 \t 194 \t 54 \t 8 \t $CONN \t NP_FREEZER1 \t 67 \t $END \crlf 84 \t NP_MIXER2 \t MBR_MIXER_CLS \t 1 \t 392 \t 54 \t 9 \t $CONN \t NP_FREEZER2 \t 85 \t $END \crlf 85 \t NP_FREEZER2 \t MBR_FREEZER_CLS \t 1 \t 392 \t 242 \t 11 \t $CONN \t \t $END \crlf 67 \t NP_FREEZER1 \t MBR_FREEZER_CLS \t 1 \t 194 \t 246 \t 10 \t $CONN \t \t $END \crlf

See also




The ProcessCellsList item returns a list of process cells in the current area.


Input Format Request: ProcessCellsList

Output Format The ProcessCellsList item is returned in this format:

<ProcessCellList> is <NullList> | <PCList>

<PCList> is <ProcessCell> | <ProcessCell> <PCList>

<ProcessCell> is <PCellID> \t <PCellName> \t <MaxOwners> \t <XCoord> \t <YCoord> \t <Area> \t <BitMapIndex> \crlf

where <ProcessCell> is:


<PCellID> ASCII - Integer Resource ID for process cell.

<PCellName> ASCII - String Name of process cell.

<MaxOwners> ASCII - Integer Maximum number of owners.

<XCoord> ASCII - Integer X Coordinate for Equipment View.

<YCoord> ASCII integer Y Coordinate for Equipment View.

<Area> ASCII - String Area name.

<BitMapIndex> ASCII integer Location of bitmap in the list of process cell bitmaps item.


Example: A request on object.GetItem(ProcessCellsList) could return: 1 \t WEST_PARLOR \t 1 \t 120 \t 48 \t AREA1 \t 0 \crlf 24 \t SOUTH_PARLOR \t 1 \t 271 \t 48 \t AREA1 \t 1 \crlf 54 \t NORTH_PARLOR \t 1 \t 423 \t 47 \t AREA1 \t 2 \crlf 36 \t MEGA_PARLOR \t 1 \t 280 \t 195 \t AREA1 \t 3 \crlf

See also


ProcessCellsList



The ProcessCellsList2 item returns a list of process cells in the current area. This item is different from the ProcessCellsList item in that it provides the name of a class on which a process cell is based.


Input Format Request: ProcessCellsList2

Output Format The ProcessCellsList2 item is returned in this format:

<ProcessCellList> is <NullList> | <PCList>

<PCList> is <ProcessCell> | <ProcessCell> <PCList>

<ProcessCell> is <PCellID> \t <PCellName> \t <MaxOwners> \t <XCoord> \t <YCoord> \t <Area> \t <BitMapIndex> \t <PCellClass> \crlf

where <ProcessCell> is:


<PCellID> ASCII - Integer Resource ID for process cell.

<PCellName> ASCII - String Name of process cell.

<MaxOwners> ASCII - Integer Max # of Owners.

<XCoord> ASCII - Integer X Coordinate for Equipment View.

<YCoord> ASCII - Integer Y Coordinate for Equipment View.

<Area> ASCII - String Area name.

<BitMapIndex> ASCII - Integer Location of bitmap in the list of process cell bitmaps item.

<PCellClass> ASCII - String Name of the process cell class.


Example: A request on object.GetItem(ProcessCellsList2) could return: 1 \t WEST_PARLOR \t 1 \t 120 \t 48 \t AREA1 \t 0 \t TOM_AND_JERRY \crlf 24 \t SOUTH_PARLOR \t 1 \t 271 \t 48 \t AREA1 \t 1 \t TOM_AND_JERRY \crlf 54 \t NORTH_PARLOR \t 1 \t 423 \t 47 \t AREA1 \t 2 \t TOM_AND_JERRY \crlf 36 \t MEGA_PARLOR \t 1 \t 280 \t 195 \t AREA1 \t 3 \t TOM_AND_JERRY \crlf

See also


ProcessCellsList2



The RecipeDir item returns the path to the recipe directory specified in the batchsvr.ini file.


Input Format Request: RecipeDir

Output Format The RecipeDir item returns in this format: <Path>


<Path> ASCII - String Recipe directory path specified in the batchsvr.ini file.


Example: A request on object.GetItem(RecipeDir) could return: \\STATION5\PROGRAM FILES\ROCKWELL SOFTWARE\BATCH \SAMPLEAPP\RECIPES\

See also


The RecipeList item returns information about the recipes available within FactoryTalk Batch View. The RecipeList execute must be run once prior to advising or requesting on this item.


Input Format Request: RecipeList

Output Format The RecipeList item returns in this format:

<RecipeList> is <RecipeInfo> | <RecipeInfo> <RecipeList>

<RecipeInfo> is <ProductVersion> \t <FileName> \t <RecipeID> \t <RecipeDesc> \t <ProductName> \t <ProductCode> \t <RecipeVersion> \t <RecipeVersTime> \t <Author> \t <ApprovedBy> \t <RecipeLevel> \t <RecipeType> \t <Abstract> \t <MinBatchSize> \t <DefBatchSize> \t <MaxBatchSize> \t <UOM> \t <EstDuration> \t <Released> \t <AreaModel> \t <AreaModelTime> \t <Unit> \t <VerifyDate> \crlf

<RecipeList> is <RecipeInfo> | <RecipeInfo> <RecipeList>

where <RecipeInfo> is:


<ProductVersion> ASCII - String The version of the product as defined in the recipe header.

<FileName> ASCII - String The filename of the recipe.

<RecipeID> ASCII - String The recipe identifier as defined in the recipe header.

RecipeDir

RecipeList



<RecipeDesc> ASCII - String A recipe description as defined in the recipe header.

<ProductName> ASCII - String The product name as defined in the recipe header.

<ProductCode> ASCII - String The product code as defined in the recipe header.

<RecipeVersion> ASCII - String The recipe version as defined in the recipe header.

<RecipeVersTime> ASCII - String dd/mm/yy hh:mm

The date/time that the recipe was saved. The format is in accordance with the date/time as set in the Control Panel.

<Author> ASCII - String The recipe author as defined in the recipe header.

<ApprovedBy> ASCII - String The approved by name as defined in the recipe header.

<RecipeLevel> ASCII - String The level of the recipe: PROCEDURE, UNIT PROCEDURE, or OPERATION.

<RecipeType> ASCII - String The type of equipment requirements for the recipe: CLASS or INSTANCE.

<Abstract> ASCII - String The recipe abstract as defined in the recipe header.

<MinBatchSize> ASCII - String The minimum batch size, as defined in the recipe header.

<DefBatchSize> ASCII - String The default batch size, as defined in the recipe header.

<MaxBatchSize> ASCII - String The maximum batch size, as defined in the recipe header.

<UOM> ASCII - String The unit of measure, as defined in the recipe header.

<EstDuration> ASCII - String The estimated duration of the batch, as defined in the recipe header.

<Released> ASCII - String Indicates if the recipe has been released to production. Always TRUE. (Only recipes which have been released to production are included in the RecipeList item.)

<AreaModel> ASCII - String The area model file and path name against which the recipe was verified.

<AreaModelTime> dd/mm/yy hh:mm The date/time of area model file against which the recipe was verified. The format will be in accordance with the date/time as set in the Control Panel.

<Unit> ASCII - String The name of the unit or alias to which the recipe is bound. Will return an empty string for PROCEDURE level recipes.

<VerifyDate> ASCII - String dd/mm/yy hh:mm

The latest modification date/time for the recipe. The format will be in accordance with the date/time as set in the Control Panel.




Example: A request on object.GetItem(RecipeList) could return: 3.0 \t FRENCH_VANILLAPREMIUM1_MEGA_PARLOR_OPT_2_U1.UPC \t FRENCH_VANILLAPREMIUM1_MEGA_PARLOR_OPT_2_U1 \t French Vanilla IceCream \t French Vanilla \t FVP-101 \t Premium 1 \t 2/24/2017 10:11:33 AM \t Administrator \t rpmServer (STAGE1\rpmServer) on computer STAGE1 \t UNIT PROCEDURE \t Instance \t The general recipe French_Vanilla, Variant= Premium, Version= 1 is successfully converted to master recipe FRENCH_VANILLAPREMIUM1_MEGA_PARLOR \t 25 \t 50 \t 100 \t KG \t \t TRUE \t \\STATION5\PROGRAM FILES\ROCKWELL SOFTWARE\BATCH\SAMPLEAPP\RECIPES\ICE_CREAM.CFG \t 2/24/2017 10:05:16 AM \t MP_MIXERFREEZER1 \t 2/24/2017 10:11:27 AM \crlf ... 3.0 \t CLS_STRAWBERRY_ICEMILK.BPC \t CLS_STRAWBERRY_ICEMILK \t Strawberry Ice Milk - Reduced Fat Ice Cream - class based \t Strawberry Ice Milk \t SIM-101 \t 1.0 \t 2/24/2017 10:11:34 AM \t Mark Shepard \t MSS \t PROCEDURE \t Class \t \t 3000 \t 5000 \t 7000 \t KG \t 45 \t TRUE \t \\STATION5\PROGRAM FILES\ROCKWELL SOFTWARE\BATCH\SAMPLEAPP\RECIPES\ICE_CREAM.CFG \t 2/24/2017 10:05:16 AM \t \t 2/24/2017 10:11:27 AM \crlf

See also




The ResourceIDEqData item returns the tag status information for tags associated with the equipment phase, and state machine information to indicate the current status of the equipment phase. A setting in the batchsvr.ini file controls whether data collection disables, enables without deviation limits, or enables with deviation limits supported in the format of the returned ResourceIDEqData. The setting EqDataItemFormat is found in the CLIENT_MGR_DDE section of the batchsvr.ini file.


batchsvr.ini Section: CLIENT_MGR_DDE

where:

Setting Name Value Meaning

EqDataItemFormat 0 (zero) Data collection for ResourceIDEqData is disabled. The item is not supported.

EqDataItemFormat 1 Data collection for ResourceIDEqData is enabled. Deviation Limits are not supported. (Default: EqDataItemFormat=1)

EqDataItemFormat 2 Data collection for ResourceIDEqData is enabled. Deviation Limits are supported.

EqDataItemFormat Setting does not exist in the ini

Data collection for ResourceIDEqData is disabled. The item is not supported.

EqDataItemFormat Any other value

Data collection for ResourceIDEqData is disabled. The item is not supported.

Input Format Request: ResourceIDEqData

ResourceID is ASCII - String, the unique ID corresponding to a specific equipment phase.

Output Format The ResourceIDEqData item returns in this format:

<EqData> is <EqModName> \crlf <PhaseName> \crlf <StateTag> \crlf <CmdTag> \crlf <FailTag> \crlf <OwnTag> \crlf <ReqTag> \crlf <PauseTag> \crlf <PausedTag> \crlf <SnglStepTag> \crlf <StepIdxTag> \crlf <UnitTag> \crlf <ParmList> \crlf <ParmLimitList> \crlf <RptList> \crlf <RptLimitList> \crlf <ReqList> \crlf <ConnFsm> \crlf <CmdFsm> \crlf <ReqFsm> \crlf

where:


<EqModName> ASCII - String The name of the equipment phase.

<PhaseName> ASCII - String The name of the recipe phase the equipment phase can execute.

where:

<StateTag> is <TagInfo>

ResourceIDEqData



<CmdTag> is <TagInfo>

<FailTag> is <TagInfo>

<OwnTag> is <TagInfo>

<ReqTag> is <TagInfo>

<PauseTag> is <TagInfo>

<PausedTag> is <TagInfo>

<SnglStepTag> is <TagInfo>

<StepIdxTag> is <TagInfo>

<UnitTag> is <TagInfo>

<ParmList> is <NullList> | <PTagList>

<PTagList> is <TagInfo> | <TagInfo> \t <PTagList>

<ParmLimitList> is <NullList> | <LimitTagList>

<LimitTagList> is <MethodTag> \t<NormPolTag><MethodTag> \t <NormPolTag> \t <LoLtTag> \t <HiLtTag> \t <HLPolTag> \t <LoLoLtTag> \t <HiHiLtTag> \t <HHLLPolTag> \t <LoLoLoLtTag> \t <HiHiHiLtTag> \t <HHHLLLPolTag>\

<RptList> is <NullList> | <RptTagList>

<RptTagList> is <TagInfo> | <TagInfo> \t <RptTagList>

RptLimitList> is <NullList> | <LimitTagList>

<LimitTagList> is <MethodTag> \t<NormPolTag> \t<LoLtTag> \t <HiLtTag> \t <HLPolTag> \t <LoLoLtTag> \t <HiHiLtTag> \t <HHLLPolTag> \t <LoLoLoLtTag> \t <HiHiHiLtTag> \t <HHHLLLPolTag> \t

<ReqList> is <NullList> | <ReqTagList>

<ReqTagList> is <TagInfo> | <TagInfo> \t <ReqTagList>

where:

<MethodTag> is <TagInfo>

<NormPolTag is <TagInfo>

<LoLtTag> is <TagInfo>



<HiLtTag> is <TagInfo>

<HLPolTag> is <TagInfo>

<LoLoLtTag> is <TagInfo>

<HiHiLtTag> is <TagInfo>

<HHLLPolTag> is <TagInfo>

<LoLoLoLtTag> is <TagInfo>

<HiHiHiLtTag> is <TagInfo>

<HHHLLLPolTag> is <TagInfo>

where:

<TagInfo> is <TagName> \t <DataServerName> \t <ConfigString1> \t ConfigString2> \t <ConfigString3> \t <ConfigString4> \t <Protocol> \t <ConfiguredDataType> \t <OPCAdviseItemDataType> \t <OPCReadItemDataType> \t <OPCWriteItemDataType> \t <AdviseStatus> \t <LatestAdviseValue> \t <LatestAdviseValueQuality> \t <LatestAdviseValueTimestamp> \t <ReadStatus> \t <LatestReadValue> \t <LatestReadValueQuality> \t <LatestReadValueTimestamp> \t <WriteStatus> \t <LastValueWritten> \t <LastWriteResult> \t <LastWriteTimestamp>

where:


<TagName> ASCII - String Protocol-specific configuration string: OPC - Name of the tag. DDE - Name of the tag. CIP - An English string indicating the equipment phase attribute exposed in this <TagInfo> structure. FTD - Name of the tag.

<DataServerName> ASCII - String Protocol-specific configuration string: OPC - Data server name the tag uses. DDE - Data server name the tag uses. CIP - Name of data server associated with equipment phase. FTD - Data server name the tag uses.

<ConfigString1> ASCII - String Protocol-specific configuration string: OPC - Read Item Access Path DDE - Read Item Topic Name CIP - Unused (<sp>) FTD - Read Item Access Path



<ConfigString2> ASCII - String Protocol-specific configuration string: OPC - Read Item Name DDE - Read Item Name CIP - Unused (<sp>) FTD - Read Item Name

<ConfigString3> ASCII - String Protocol-specific configuration string: OPC - Write Item Access Path DDE - Write Item Topic Name CIP - Unused (<sp>) FTD - Write Item Access Path

<ConfigString4> ASCII - String Protocol-specific configuration string: OPC - Write Item Name DDE - Write Item Name CIP - Unused (<sp>) FTD - Write Item Name

<Protocol> ASCII - String String indicating communication protocol used for the tag or equipment phase attribute. Possible legal values are: DDE, OPC, CIP or FTD.

<ConfiguredData Type>

ASCII - Integer Protocol-specific data type configured for tag in equipment database. OPC – Ordinal indicating data type configured for tag in area model. 1 = FLOAT 2 = INTEGER 3 = STRING 4 = ENUMERATION DDE – Same as OPC CIP – Same as OPC FTD – Same as OPC

<OPCAdviseItem DataType>

ASCII - Integer Protocol-specific string. OPC – Ordinal indicating OLE variant type returned by the data server for advises. These ordinals are defined by Windows. Some common values are: 2 = Two byte integer 3 = Four byte integer 4 = Four byte real 5 = Eight byte real 8 = String 11 = Boolean 17 = Unsigned char (1 byte unsigned integer) DDE – Unused (<sp>) CIP – Unused (<sp>) FTD – Same as OPC



<OPCReadItem DataType>

ASCII - Integer Protocol-specific string. OPC – Ordinal indicating OLE variant type returned by the data server for reads. These ordinals are defined by Windows. Some common values are: 2 = Two byte integer 3 = Four byte integer 4 = Four byte real 5 = Eight byte real 8 = String 11 = Boolean 17 = Unsigned char (1 byte unsigned integer) DDE – Unused (<sp>) CIP – Unused (<sp>) FTD – Same as OPC

<OPCWriteItem DataType>

ASCII - Integer Protocol-specific string. OPC – Ordinal indicating OLE variant type returned by the data server for writes. These ordinals are defined by Windows. Some common values are: 2 = Two byte integer 3 = Four byte integer 4 = Four byte real 5 = Eight byte real 8 = String 11 = Boolean 17 = Unsigned char (1 byte unsigned integer) DDE – Unused (<sp>) CIP – Unused (<sp>) FTD – Same as OPC

<AdviseStatus> ASCII - Integer Ordinal indicating current status of any advise operation associated with the tag. 0 = NOT ADVISED 1 = ADVISED – Advise established and initial value received 2 = PENDING – Pending asynchronous establishment 3 = ENDING – Asynchronously ending advise 4 = FAILED 5 = ESTABLISHED – Advised, but no initial value received 9 = UNDEFINED/ERROR

<LatestAdvise Value>

ASCII - String The latest data value received by the tag as the result of an update from an advise or active item. The value of the tag is converted to a string representation. If a data update is not received via an advise mechanism, then this field is empty.

<LatestAdviseValue Quality>

ASCII - Integer The quality of the latest advise value update. Protocol-specific value: OPC: Quality value per OPC specification DDE: 192 = GOOD 0 = BAD CIP: 0 = GOOD Non-Zero = BAD FTD: Same as OPC If an advise data update is never received, then this field is empty.



<LatestAdviseValueTimestamp>

ASCII - String The timestamp associated with the most recent advise value. This is not an OPC timestamp. This timestamp is recorded by the FactoryTalk Batch Server at the time it received the data update. The time is represented by a string in the format: "%m/%d/%Y %H:%M:%S" If a data update is never received, then this field is empty.

<ReadStatus> ASCII - Integer Ordinal indicating current status of any read operation associated with the tag. 0 = NOT PENDING 1 = FAILED 2 = PENDING 9 = UNDEFINED/ERROR

<LatestReadValue> ASCII - String The latest data value received by the tag as the result of a completed read operation. The value of the tag is converted to a string representation. If a read operation is never successfully completed, then this field is empty.

<LatestReadValue Quality>

ASCII - Integer Protocol-specific value. The quality of the latest read value update: OPC: Quality value per OPC specification DDE: 192 = GOOD 0 = BAD CIP: 0 = GOOD Non-Zero = BAD FTD: Same as OPC If an advise data update is not received, then this field is empty.

<LatestReadValue TimeStamp>

ASCII - String The timestamp associated with the most recently read value. This is not an OPC timestamp. This timestamp is recorded by the FactoryTalk Batch Server at the time it receives the read data. The time is represented by a string in the format: "%m/%d/%Y %H:%M:%S" If data is not successfully read, then this field is empty.

<WriteStatus> ASCII - Integer Ordinal indicating current status of any write operation associated with the tag. 0 = NOT PENDING 1 = FAILED 2 = PENDING 9 = UNDEFINED/ERROR

<LastValueWritten> ASCII - String The last value that the FactoryTalk Batch Server wrote to the equipment phase attribute. The value is depicted as a string. If the equipment phase attribute is never written to, then this field is empty.

<LastWriteResult> ASCII - Integer An ordinal that indicates the success or failure of the last attempted write. If the tag is associated with an OPC or FTD data server, then the complete set of OPC errors may be received; refer to the OPC standard for a list of the possible return values. If the tag is associated with a DDE server, then the result is constrained to either an S_OK or E_FAIL status. S_OK- Successful E_FAIL - Failed Additional vendor-specific error codes may be returned. It is not possible to know the values of these ordinals in advance. If the tag is never written to, this field is empty.



<LastWriteTime stamp>

ASCII - Integer The time at which the FactoryTalk Batch Server last received the results of a write attempt from the data server. The time is represented by a string in the format: "%m/%d/%Y %H:%M:%S". If data is never successfully read, then this field is empty.

where:

<ConnFsm> is <ConnMachState> \t <ParentStepName> \t <PendAdvs>

<PendAdvs> is <NullList> | <PendList>

<PendList> is <PendTagName> | <PendTagName> \t <PendList>

where:


<ConnMachState> ASCII - Integer The current state of the connection state machine associated with the equipment phase. The possible states are: 0 = DORMANT 1 = PEND_SUBSCRIBE 2 = PEND_UNIT_ID 3 = CONNECTED 4 = RECONNECTING 5 = EXTERNAL_CONTROL

<ParentStepName> ASCII - String The batch step name connected to the equipment phase. If a batch step is not currently connected, then this field is empty.

<PendTagName> ASCII - String The tag name on which the connection state machine awaits an initial value before advancement to the next state is allowed.

where:

<CmdFsm> is <CmdMachState> \t <CurrCmd> \t <CurrCmdID> \t <CmdQ> $END \t <CmdEvents>

<CmdQ> is <NullList> | <CmdList>

<CmdList> is <QueuedCmd> | <QueuedCmd> \t <CmdList>


<CmdMachState> ASCII - Integer The current state of the Command state machine associated with the equipment phase. The possible states are: 0 = DORMANT 1 = INITIALIZING 3 = PEND_COMMAND_ACK 4 = PEND_WRITE_COMPLETE

<CurrCmd> ASCII - Integer If a Command is being processed, this field contains the current Command. Otherwise, this field is empty.

<CurrCmdID> ASCII - Integer If a Command is being processed, this field contains the ID of the current Command. Otherwise, this field is empty.

<QueuedCmd> ASCII - Integer A Command value in the Command queue waiting to be processed when the current Command completes.

where:



<CmdEvts> is <NullList> | <CmdEvtList>

<CmdEvtList> is <CmdEvent> | <CmdEvent> \t <CmdEvtList>

<CmdEvent> is <CmdInit> | <CmdSent> | <CmdAck> | <CmdNAck> | <CmdTime> | CmdQued> | <CmdCommErr> | <CmdNotYetProcessed> | <CmdProtocolViolate> | <CmdExternal> | <CmdQueueFlushed> | <CmdWriteFailed> | <CmdWriteSucceeded>

<CmdInit> is 101 \t <EvtTstmp> \t <SpareParm> \t <InitialCmdID>

<CmdSent> is 102 \t <EvtTstmp> \t <Cmd> \t <CmdID>

<CmdAck> is 103 \t <EvtTstmp> \t <Cmd> \t <CmdID>

<CmdNAck> is 104 \t <EvtTstmp> \t <Cmd> \t <CmdID>

<CmdTime> is 105 \t <EvtTstmp> \t <Cmd> \t <CmdID>

<CmdQued> is 106 \t <EvtTstmp> \t <Cmd> \t <SpareParm>

<CmdNotYetProcessed> is 108 \t <EvtTstmp> \t <Cmd> \t <CmdID>

<CmdProtocolViolate> is 109 \t <EvtTstmp> \t <Cmd> \t <CmdID>

<CmdExternal> is 110 \t <EvtTstmp> \t <SpareParm> \t <SpareParm>

<CmdQueueFlushed> is 111 \t <EvtTstmp> \t <SpareParm> \t <SpareParm>

<CmdWriteFailed> is 112 \t <EvtTstmp> \t <SpareParm> \t <SpareParm>

<CmdWriteSucceeded> is 113 \t <EvtTstmp> \t <SpareParm> \t <SpareParm>


<EvtTstmp> ASCII - String The time at which the FactoryTalk Batch Server recorded the event. The time is represented as an eight byte float value. This is the "DATE" time as defined by OLE and encapsulated by the COleDateTime class.

<SpareParm> ASCII - String An unused event parameter field. It populates with the value zero (0) by default.

<InitialCmdID> ASCII - Integer The Command ID used for the first Command issued after the Command state machine is initialized by reading the Command tag’s current value. Normally, a value of 1 is used, unless the current value of the tag’s high byte is 1, in which case Commands are started with an ID of 2.

<Cmd> ASCII - Integer The Command value associated with the recorded event.

<CmdID> ASCII - Integer The Command ID value associated with the recorded event.

where:



<ReqFSM> is <RqstMachState> \t <CurrRqst> \t <CurrRqstParm1> \t <CurrRqstParm2> \t <CurrRqstParm3> \t <ReqEvents>

where:


<RqstMachState> ASCII - Integer The current state of the request state machine associated with the equipment phase. The possible states are: 0 = DORMANT 1 = PEND_GET_DATA 2 = PERFORMING_REQ 3 = PEND_PUT_DATA 4 = PEND_VERIFY_DATA 5 = PEND_COMPLETE

<CurrRqst> ASCII - Integer If a request is being processed, this is the value of the current request, otherwise this field is blank.

<CurrRqstParm1> ASCII - Integer If a request is being processed that requires request parameters, then this is the value of the first request parameter. Otherwise, this field is blank.

<CurrRqstParm2> ASCII - Integer If a request is being processed that requires two or more request parameters, then this is the value of the second request parameter. Otherwise, this field is blank.

<CurrRqstParm3> ASCII - Integer If a request is processed that requires three or more request parameters, then this is the value of the third request parameter. Otherwise, this field is blank.

where <ReqEvents> is:

<ReqEvents> is <NullList> | <ReqEvtList>

<ReqEvtList> is <ReqEvent> | <ReqEvent> \t <ReqEvtList>

<ReqEvent> is <ReqReq> | <ReqRSet> | <ReqAbrtAck> | <ReqAbrtFail> | <ReqGetParm> | <ReqProcsng> | <ReqCmpltd> | <ReqPutData> | <ReqVerData>

<ReqReq> is 203 \t <EvtTstmp> \t <RqstValue> \t <SpareParm>

<ReqRSet> is 204 \t <EvtTstmp> \t <SpareParm> \t <SpareParm>

<ReqAbrtAck> is 205 \t <EvtTstmp> \t <SpareParm> \t <SpareParm>

<ReqAbrtFail> is 206 \t <EvtTstmp> \t <SpareParm> \t <SpareParm>

<ReqGetParm> is 207 \t <EvtTstmp> \t <RqstValue> \t <SpareParm>

<ReqProcsng> is 208 \t <EvtTstmp> \t <RqstValue> \t <SpareParm>

<ReqCmpltd> is 209 \t <EvtTstmp> \t <RqstValue> \t <SpareParm>

<ReqPutData> is 210 \t <EvtTstmp> \t <RqstValue> \t <SpareParm>



<ReqVerData> is 211 \t <EvtTstmp> \t <RqstValue> \t <SpareParm>

Items 212 through 315 are proprietary.

where:


<EvtTstmp> ASCII - String The time at which the FactoryTalk Batch Server recorded the event. The time is represented as an eight-byte float value. This is the "DATE" time as defined by OLE and encapsulated by the COleDateTime class.

<SpareParm> ASCII - String An unused event parameter field. It is by default populated with the value zero.

<RqstValue> ASCII - Integer The value of the equipment phase request associated with the recorded event.




Example: A request on object.GetItem(68EqData) could return: NP_ADDDAIRY_M1 \crlf MBR_ADD \crlf NP_ADDDAIRY_M1_ST \t OPC_SIM \t PHASES \t NP_ADDDAIRY_M1_ST \t \t \t OPC \t 2 \t 3 \t \t 3 \t 1 \t 100 \t 192 \t 02/24/2017 16:20:57 \t 0 \t \t 0 \t \t 0 \t \t 0 \t \crlf NP_ADDDAIRY_M1_OC \t OPC_SIM \t PHASES \t NP_ADDDAIRY_M1_OC \t PHASES \t NP_ADDDAIRY_M1_OC \t OPC \t 2 \t 3 \t \t 3 \t 1 \t 2816 \t 192 \t 02/24/2017 16:14:48 \t 0 \t \t 0 \t \t 0 \t \t 0 \t \crlf NP_ADDDAIRY_M1_F \t OPC_SIM \t PHASES \t NP_ADDDAIRY_M1_F \t \t \t OPC \t 2 \t 3 \t \t 3 \t 1 \t 0 \t 192 \t 02/24/2017 16:14:49 \t 0 \t \t 0 \t \t 0 \t \t 0 \t \crlf NP_ADDDAIRY_M1_W \t OPC_SIM \t PHASES \t NP_ADDDAIRY_M1_W \t \t \t OPC \t 2 \t 3 \t \t 3 \t 1 \t 0 \t 192 \t 02/24/2017 16:20:57 \t 0 \t \t 0 \t \t 0 \t \t 0 \t \crlf NP_ADDDAIRY_M1_RQ \t OPC_SIM \t PHASES \t NP_ADDDAIRY_M1_RQ \t \t \t OPC \t 2 \t 3 \t \t 3 \t 1 \t 0 \t 192 \t 02/24/2017 16:21:18 \t 0 \t \t 0 \t \t 0 \t \t 0 \t \crlf NP_ADDDAIRY_M1_P \t OPC_SIM \t PHASES \t NP_ADDDAIRY_M1_P \t \t \t OPC \t 2 \t 3 \t \t 3 \t 1 \t 0 \t 192 \t 02/24/2017 16:20:57 \t 0 \t \t 0 \t \t 0 \t \t 0 \t \crlf NP_ADDDAIRY_M1_PD \t OPC_SIM \t PHASES \t NP_ADDDAIRY_M1_PD \t \t \t OPC \t 2 \t 3 \t \t 3 \t 1 \t 0 \t 192 \t 02/24/2017 16:20:57 \t 0 \t \t 0 \t \t 0 \t \t 0 \t \crlf NP_ADDDAIRY_M1_SS \t OPC_SIM \t PHASES \t NP_ADDDAIRY_M1_SS \t \t \t OPC \t 2 \t 3 \t \t 3 \t 0 \t \t 0 \t \t 0 \t \t 0 \t \t 0 \t \t 0 \t \crlf NP_ADDDAIRY_M1_SI \t OPC_SIM \t PHASES \t NP_ADDDAIRY_M1_SI \t \t \t OPC \t 2 \t 3 \t \t 3 \t 1 \t 0 \t 192 \t 02/24/2017 16:20:57 \t 0 \t \t 0 \t \t 0 \t \t 0 \t \crlf \t NP_ADDDAIRY_M1P02 \t PHASES \t NP_ADDDAIRY_M1P02 \t OPC \t 1 \t 5 \t \t 5 \t 0 \t \t 0 \t \t 0 \t \t 0 \t \t 0 \t \t 0 \t \crlf ... \crlf 0 \t \t \crlf 1 \t 0 \t 0 \t $END \t 101 \t 02/24/2017 16:14:56 \t 0 \t 1 \crlf 0 \t 0 \t 0 \t 0 \t 0 \t

See also




The ResourceIDHyperlinks item returns a tab-delimited list of hyperlinks that were configured in the area model for the equipment element identified by the resource ID.


Input Format The FactoryTalk Batch Server supports an item named ResourceIDHyperlinks. The format of the data returned by this item is: <ResourceName> \t <Hyperlink1> \t <Hyperlink2> \t <Hyperlink3> \t <Hyperlink4> \t <Hyperlink5>

Output Format The ResourceIDHyperlinks item returns in this format:

where:


ResourceName ASCII - String Resource name identified by the ResourceID included in the item. Can represent a process cell, unit, equipment phase or shared resource.

Hyperlink# ASCII - String Hyperlinks defined for the identified resource, where # is a number from 1 through 5. An empty string returns for any hyperlink without an assigned a value in the area model.


Example: A request on object.GetItem(68Hyperlinks) could return: NP_ADDDAIRY_M1 \t HYPERLINK1 \t HYPERLINK2 \t HYPERLINK3 \t HYPERLINK4 \t HYPERLINK5

See also


ResourceIDHyperlinks



The ResourceIDInfo item returns the resource name denoted by the resource ID.


Input Format Request: ResourceIDInfo

ResourceID is ASCII - String, the unique equipment ID corresponding to a specific resource. A resource is an equipment entity (Process Cell, Unit, Phase or Shared Resource).

Output Format The ResourceIDInfo item returns in this format:

<ResourceInfo> is <ResourceInfo>

where:


<ResourceInfo> ASCII - String The name of the resource prefaced with the type of resource: Procedure (for Operator) Process Cell Unit Phase Resource


Example: A request on object.GetItem(68Info) could return: Phase NP_ADDDAIRY_M1

See also


ResourceIDInfo



The ResourceIDOwned item returns a resource list and their associated equipment IDs, which are currently owned by the resource denoted as ResourceID. A resource must be configured as a needed equipment item in FactoryTalk Batch Equipment Editor or must be specifically requested by the phase logic in order to be considered owned. The resource ID for the operator is 0.


Input Format Request: ResourceIDOwned


Output Format The ResourceIDOwned item returns in this format:

<ResourceIDOwned> is <NullList> \crlf | <OwnedList> \crlf

<OwnedList> is <Resource> | <Resource> <OwnedList>

Resource> is <ResourceID> \t <ResourceName> \crlf

where:


<ResourceID> ASCII - Integer Unique equipment ID configured in FactoryTalk Batch Equipment Editor.

<ResourceName> ASCII - String Name of the Procedure, Process Cell, Unit, Phase or Resource.


Example: A request on object.GetItem(68Owned) could return: 125 \t P101 \crlf

See also


ResourceIDOwned



The ResourceIDOwners item returns a list of all resource owners and the corresponding owner IDs.


Input Format Request: ResourceIDOwners

ResourceID is ASCII - String, the unique Equipment ID corresponding to a specific resource. A Resource is an equipment entity (Process Cell, Unit, Phase or Shared Resource).

Output Format The ResourceIDOwners item returns in this format:

<ResourceIDOwners> is <NullList> \crlf | <OwnsList> \crlf

<OwnsList> is <Resource> | <Resource> <OwnsList>

<Resource> is <ResourceID> \t <ResourceName> \crlf

where:


<ResourceID> ASCII - Integer The unique equipment ID configured in FactoryTalk Batch Equipment Editor. If the owner is the batch operator, the ID is 0 (zero).

<ResourceName> ASCII - String The name of the Process Cell, Unit, Phase or Resource.


Example: A request on object.GetItem(119Owners) could return: 0 \t OPERATOR \crlf

See also


ResourceIDOwners



The ResourceIDRequested item returns a list of all resources and the corresponding equipment IDs, requested by the resource owner indicated as ResourceID. The resource ID for the operator is 0.


Input Format Request: ResourceIDRequested

ResourceID is ASCII - String, the unique Equipment ID corresponding to a specific resource. A Resource is an equipment entity (Process Cell, Unit, Phase or Shared Resource).

Output Format The ResourceIDRequested item returns in this format:

<ResourceID Requested> is <NullList> \crlf | <RequestedList>

<RequestedList> is <Resource> | <Resource> <RequestedList>


where:


<ResourceID> ASCII - Integer The unique equipment ID configured in FactoryTalk Batch Equipment Editor.

<ResourceName> ASCII - String The name of the Process Cell, Unit, Phase, or Resource.


Example: A request on object.GetItem(68Requested) could return: 119 \t FV101 \crlf

See also


ResourceIDRequested



The ResourceIDRequesters item returns a list of all resource requesters and their corresponding owner IDs.


Input Format Request: ResourceIDRequesters


Output Format The ResourceIDRequesters item returns in this format:

<ResourceIDRequesters> is <NullList> \crlf | <RequestingList>

<RequestingList> is <Resource> | <Resource> <RequestingList>


where:


<ResourceID> ASCII - Integer Unique equipment ID configured in FactoryTalk Batch Equipment Editor. If the owner is the batch operator, the ID is 0 (zero).

<ResourceName> ASCII - String Name of the Process Cell, Unit, Phase or Resource.


Example: A request on object.GetItem(119Requesters) could return: 0 \t OPERATOR \crlf

See also


ResourceIDRequesters



The ResourceIDStrings item returns the list of five generic strings associated with the identified resource.


Input Format Request: ResourceIDStrings


Output Format The ResourceIDStrings item returns in this format: <ResourceName> \t <GenericString1> \t <GenericString2> \t <GenericString3> \t <enericString4> \t <GenericString5>

where:


<ResourceName> ASCII - String Name of the resource.


Example: A request on object.GetItem(68Strings) could return: NP_ADDDAIRY_M1 \t CROSS INVOCATION LABEL 1 \t CROSS INVOCATION LABEL 2 \t CROSS INVOCATION LABEL 3 \t CROSS INVOCATION LABEL 4 \t CROSS INVOCATION LABEL 5

See also


ResourceIDStrings



The ResourcesList item returns a list of all resources and their corresponding equipment IDs.


Input Format Request: ResourcesList

Output Format The ResourcesList item returns in this format:

<ResourcesList> is <Resource> | <Resource> <ResourcesList>

<Resource> is <ResourceID> \t <ResourceName> \t <ResourceType> \t <ArbMask> \crlf

where <Resource> is:


<ResourceID> ASCII - Integer Unique equipment ID for a resource.

<ResourceName> ASCII - String Name of the resource. (Process Cells, Units and Shared Resources are included in this list.)

<ResourceType> ASCII - Integer Type of the resource: • 1: Process Cell

• 2: Unit

• 3: Phase

• 4: Resource

• 5: Procedure

<ArbMask> Encoded String Arbitration masks


Example: A request on object.GetItem(ResourcesList) could return: -1138 \t 17:MCLS_FRENCHVANILLA\MCLS_TRANSFER_OUT_UP:1\MCLS_TRANSFER_OUT_OP:1 \t 5 \t 0 \crlf -1137 \t 17:MCLS_FRENCHVANILLA\MCLS_TRANSFER_OUT_UP:1 \t 5 \t 0 \crlf -1136 \t 17:MCLS_FRENCHVANILLA\MCLS_TRANSFER_IN_UP:1\MCLS_TRANSFER_IN_OP:1 \t 5 \t 0 \crlf ... 119 \t FV101 \t 4 \t 1 \crlf

See also



ResourcesList



The RunMode item returns a string which indicates whether the FactoryTalk Batch Server is running in demo or production mode.


Input Format Request: RunMode

Output Format The RunMode item returns in this format: <Mode>

where:


<Mode> ASCII - String The mode in which the FactoryTalk Batch Server is running: Demo or Production


Example: A request on object.GetItem(RunMode) could return: Production

See also


The RunWithoutMatSvr item returns the configured option of running when Material Server communication is lost as an ordinal data item.


Input Format Request: RunWithoutMatSvr

Output Format The RunWithoutMatSvr item returns in this format: <Option>

where:


<Option> ASCII - Integer 0 = FailureAndHold 1 = SwitchToManual


Example: A request on object.GetItem(RunWithoutMatSvr) could return: 1

See also


RunMode

RunWithoutMatSvr



The SignatureIDSig item returns the signature information for a single signature (excluding those generated by private interfaces).


Input Format Request: SignatureIDSig

SignatureID is ASCII – String, the unique Signature ID corresponding to a specific signature.

Output Format The SignatureIDSig item returns in this format:

<SigData> is <ActionID> /t <CreateID> /t <SigState> /t <SigCreateTime> /t <SigEndTime> /t <SigCancelable> /t <ReqSignOffs> /t <SigType> /t <reserved1> /t <reserved2> /t <SigContext> /crlf <LastSignOff> /t <SignOffList>

<SignOffList> is <SignOff> | <SignOff> /crlf <SignOffList>

<SignOff> is <SignoffState> /t <CommentControl> /t <Meaning> /t <CompletionTime> /t <SignerName> /t <SignerID> /t <SignerComment> /t <PermissionList>

<PermissionList> is <Permission> | <Permission> /t <PermissionList>

<SigContext> is <CommandContext > | <GeneralUsageContext> | <ParamDeviationContext> | <ParamValueAckContext> | <ReportDeviationContext> | <UnitBindContext> | <UnitBindAckContext> | <PhaseBindContext> | <PhaseBindAckContext> | <RemoveContext> | <ASCContext> | <AddEventContext> | <SetParmContext> | <SetAllLabelContext> | <SetAllLotContext> | <ForceTransitionContext> | <OverrideContext> | <OverrideClearContext>

<CommandContext> is <ProcedureID> /t <Command>

<GeneralUsageContext> is <ProcedureID> /t <StepIndex>

<ParamDeviationContext> is <ProcedureID> /t <ParameterName> /t <NewValue> /t <CurrentValue> /t <DeviationType> /t <ParamLimits>

<ParamValueAckContext> is <ProcedureID> /t <ParameterName> /t <NewValue> /t <DefaultValue>

<ReportDeviationContext> is <ProcedureID> /t <ReportName> /t <UploadedValue> /t <TargetParamName> /t <TargetParamValue> /t <DeviationType> /t <ReportLimits>

<UnitBindContext> is <UnitID> /t <ProcedureList>

<UnitBindAckContext> is <UnitID> /t <ProcedureList>

SignatureIDSig



<PhaseBindContext> is <ProcedureID> /t <EquipmentPhaseID> /t <ContainerName> /t <MaterialName> /t <Lot> /t <Label>

<PhaseBindAckContext> is <ProcedureID> /t <EquipmentPhaseID> /t <ContainerName> /t <MaterialName> /t <MaterialName> /t <Lot> /t <Label>

<RemoveContext> is <ProcedureID>

<ASCContext> is <ProcedureID> /crlf <ActivateStepList> /crlf <DeactivateStepList>

<AddEventContext> is <ProcedureID> /crlf <Type> /crlf <Description> /crlf <Value>

<SetParmContext> is <ProcedureID> /t <ParameterName> /t <NewValue> /t <CurrentValue>

<SetAllLabelContext> is <ProcedureID> /t <NewValue>

<SetAllLotContext> is <ProcedureID> /t <NewValue>

<OverrideContext> is <ProcedureID> /t <Parameter Name> /t <New Value> /t <Current Value>

<OverrideClearContext> is <ProcedureID> /t <Parameter Name> /t <New Value> /t <Current Value>

<ForceTransitionContext> is <TransitionID> /t <Transition Condition Expression>

<ParamLimits> is <LLimit> /t <HLimit> /t <LLLimit> /t <HHLimit> /t <LLLLimit> /t <HHHLimit>

<ReportLimits> is <LLimit> /t <HLimit> /t <LLLimit> /t <HHLimit> /t <LLLLimit> /t <HHHLimit>

<ProcedureList> is <ProcedureID> | <ProcedureID> /t <ProcedureList>

<ActivateStepList> is <NullList> | <StepList>

<DeactivateStepList> is <NullList> | <StepList>

<StepList> is <StepName> | <StepName> /t <StepList>

where:


<ActionID> ASCII - Integer Action ID as a 32-bit unsigned integer. Action ID is used to associate multiple signatures that were generated from an action (for example, SetParm).

<CreateID> ASCII – Integer Unique CreateID of batch with which signature is associated.

<SigState> ASCII – Integer The signature state: 1 = Incomplete 2 = Complete 3 = Cancelled 4 = System Cancelled

<SigCreateTime> ASCII – String The time when the signature request was created, formatted as specified within the Control Panel.



<SigType> ASCII – Integer The signature type: 1 = Command 2 = General Usage 3 = Recipe Parameter Deviation 4 = Parameter Value Ack 5 = Report Parameter Deviation 6 = Unit Bind 7 = Unit Bind Ack 8 = Phase Bind 9 = Phase Bind Ack 10 = Batch Removal 11 = Active Step Change 12 = Add Event Context 13 = Set Parameter Context 14 = SetAllLabel Context 15 = SetAllLot Context 16 = PhaseDisconnectContext 17 = PhaseResetContext 18 = ForceTransitionContext 19 = OverrideContext 20 = OverrideClearContext This field controls the type of the <SigContext> field as follows: 1 = <CommandContext> 2 = <GeneralUsageContext> 3 = <ParamDeviationContext> 4 = <ParamValueAckContext> 5 = <ReportDeviationContext> 6 = <UnitBindContext> 7 = <UnitBindAckContext> 8 = <PhaseBindContext> 9 = <PhaseBindAckContext> 10 = <RemoveContext> 11 = <ASCContext> 12 = <AddEventContext> 13 = <SetParmContext> 14 = <SetAllLabelContext> 15 = <SetAllLotContext> 16 = <PhaseDisconnectContext> 17 = <PhaseResetContext> 18 = <ForceTransitionContext> 19 = <OverrideContext> 20 = <OverrideClearContext>

<Reserved1> ASCII – String Reserved for future use.

<Reserved2> ASCII – String Reserved for future use.

<SigEndTime> ASCII – String The time when the signature was completed or cancelled, formatted as specified within the control panel. If the signature state is "Incomplete", then this field is empty.

<SigCancelable> ASCII – Integer Cancelable property of Signature: 0 = Not Cancelable 1 = Cancelable

<ReqSignOffs> ASCII – Integer Number of required signoffs. This field specifies the number of <SignOff> structures found in the <SignoffList>.



<SignoffState> ASCII – Integer The signoff state: 1 = Incomplete 2 = Complete 3 = Cancelled 4 = System Cancelled

<CommentControl> ASCII – Integer The configured comment control value: 0 = Optional 1 = Required 2 = Not Allowed

<Permission> ASCII - String Windows User or Group Identifiers permitted to perform the signoff. The identifier is always prepended with either a capitol "G" or "U". A "G" indicates that the string describes the name of a group, while a "U" indicates that the string describes the name of a user.

<Meaning> ASCII – String A description of the signature’s meaning.

<CompletionTime> ASCII – String The time when the signoff was completed or cancelled, formatted as specified within the control panel. If the signoff state is "Incomplete", then this field is blank.

<SignerName> ASCII – String The signer’s full name. This field is blank if the state of the signoff is "Incomplete" or "Cancelled".

<SignerID> ASCII – String The signer’s user ID. This field is blank if the state of the signoff is "Incomplete" or "Cancelled".

<SignerComment> ASCII - String If entered, the signer’s comment. This field is blank if the state of the signoff is "Incomplete" or "Cancelled".

<ProcedureID> ASCII – String Hierarchical path name to the procedure, unit procedure, operation, or phase associated with the signature.

<UnitID> ASCII – Integer The resource ID of the Unit specified by a Bind Unit execute.

<EquipmentPhaseID> ASCII – Integer The resource ID of the equipment phase specified by a Bind Recipe Phase execute.

<ContainerName> ASCII – String The container specified by a Bind Phase Recipe execute.

<MaterialName> ASCII – String The material specified by a Bind Phase or Bind Phase Ack execute.

<Lot> ASCII – String The lot specified by a Bind Phase Recipe execute.

<Label> ASCII – String The label specified by a Bind Phase Recipe execute.

<StepName> ASCII – String The step name inside a recipe.

<Command> ASCII – Integer The command value queued pending signature collection.

<StepIndex> ASCII – Integer The Step Index of the equipment phase for which the signature was generated.

<ParameterName> ASCII – String The recipe phase parameter’s name for which a parameter deviation generated a signature request. If this is the "actual amount" report in a material-based recipe step, then the type of material is appended to the "actual amount" report name.

<NewValue> ASCII – String The new value stored to a parameter when a signature is generated in response to a parameter deviation.

<CurrentValue> ASCII – String The current value of a parameter for which a signature has been generated in response to a parameter deviation.

<Default Value> ASCII – String The parameter’s default value.

<ReportName> ASCII – String The recipe phase report’s name for which the signature was generated. If this is the "amount" parameter in a material-based recipe step, then the material type is appended to the "amount" parameter name.



<UploadedValue> ASCII – String The uploaded report value for which a signature was generated.

<Type> ASCII – String The Type field passed in the AddEvent, AddEvent_CI, or AddEvent_Phase execute.

<Description> ASCII – String The Description field passed in the AddEvent, AddEvent_CI, or AddEvent_Phase execute.

<Value> ASCII - String The Value field passed in the AddEvent, AddEvent_CI, or AddEvent_Phase execute.

<TargetParamName> ASCII – String The parameter’s name from which the report parameter deviation limits calculate.

<TargetParam Value>

ASCII – String The parameter’s value from which the report parameter deviation limits calculate (at the time the deviation was detected).

<DeviationType> ASCII – Integer The type of deviation being recorded: 0 = Normal 11 = Low 12 = Low Low 13 = Low Low Low 21 = High 22 = High High 23 = High High High

<LastSignOff> ASCII – Integer The 1-based ordinal of the Signoff in the SignoffList that must be the "last" completed. If none is configured as being required to be "last", then the value is zero.

<TransitionID> ASCII – String The unique ID of the transition, as assigned by the system.

<TransitionCondition Expression>

ASCII – String The condition expression text of a transition element.

<LLimit> ASCII – String The report’s Low Limit or parameter for which a deviation signature has been generated. This field may be empty if the limit is not defined.

<HLimit> ASCII – String The report’s High Limit or parameter for which a deviation signature has been generated. This field may be empty if the limit is not defined.

<LLLimit> ASCII – String The report’s Low-Low Limit or parameter for which a deviation signature has been generated. This field may be empty if the limit is not defined.

<HHLimit> ASCII – String The report’s High-High Limit or parameter for which a deviation signature has been generated. This field may be empty if the limit is not defined.

<LLLLimit> ASCII – String The report’s Low-Low-Low limit or parameter for which a deviation signature has been generated. This field may be empty if the limit is not defined.

<HHHLimit> ASCII – String The report’s High-High-High limit or parameter for which a deviation signature has been generated. This field may be empty if the limit is not defined.

See also




The Signatures item returns a list of all outstanding signature requests (excluding those generated by private interfaces).


Input Format Request: Signatures

Output Format The Signatures item returns in this format:

<Signatures> is <NullList> | <SList>

<SList> is <Signature> | <Signature> \crlf<SList>

<Signature> is <SignatureID> \t <CreateID> \t <ActionID> /t <SigState>

where:


<SignatureID> ASCII - Integer Unique ID as a 32-bit unsigned integer.

<CreateID> ASCII – Integer Unique CreateID of batch with which signature associates.

<ActionID> ASCII – Integer Action ID as a 32-bit unsigned integer (an action may generate multiple signatures. For example, SetParm).

<SigState> ASCII – Integer Signature state:

• 1 = Incomplete

• 2 = Complete

• 3 = Cancelled

• 4 = System Cancelled

See also


Signatures



The StartTime item returns the time stamp of the FactoryTalk Batch Server.


Input Format Request: StartTime

Output Format The StartTime item returns in this format: <Time>

where:


<Time> ASCII - String The time FactoryTalk Batch Server started, formatted according to Windows internationalization and locality settings.


Example: A request on object.GetItem(StartTime) could return: 2017.02.24 16:14:35

See also


StartTime



The StepsList item returns a list of all dynamic owners (control recipes) and owner IDs.


Input Format Request: StepsList

Output Format The StepsList item returns in this format:

<StepsList> is <NullList> | <StepList>


<Step> is <ResourceID> \t <ResourceName> \t <ResourceType> \t <ArbMask>

where <Step> is:


<ResourceID> ASCII - Integer The unique ID for each step.

<ResourceName> ASCII - String The hierarchical path name to the procedure.

<ResourceType> ASCII - String Owner Resource Type: 1. Process Cell

2. Unit

3. Phase

4. Resource

5. Procedure

<ArbMask> Encoded String Arbitration masks


Example: A request on object.GetItem(StepsList) could return: -1128 \t 16:CLS_FRENCHVANILLA\CLS_TRANSFER_OUT_UP:1\CLS_TRANSFER_OUT_OP:1 \t 5 \t 0 \crlf -1136 \t 17:MCLS_FRENCHVANILLA\MCLS_TRANSFER_IN_UP:1\MCLS_TRANSFER_IN_OP:1 \t 5 \t 0 \crlf ... -1114 \t 15:CLS_FRENCHVANILLA\CLS_SWEETCREAM_UP:1\CLS_SWEETCREAM_OP:1 \t 5 \t 0 \crlf

See also



StepsList



The StringLabels item returns the labels used for generic strings. There are four groups of five strings. The groups are ordered as follows: Process Cell labels, Unit labels, Phase labels, and Shared Resource labels.


Input Format Request: StringLabels

Output Format The StringLabels item returns in this format: <StringLabels>

<StringLabels> is <ProcessCellLabels> \crlf <UnitLabels> \crlf <PhaseLabels> \crlf <SharedResourceLabels> \crlf

<ProcessCellLabels> is <s1> \t <s2> \t <s3> \t <s4> \t <s5>

<UnitLabels> is <s1> \t <s2> \t <s3> \t <s4> \t <s5>

<PhaseLabels> is <s1> \t <s2> \t <s3> \t <s4> \t <s5>

<SharedResourceLabels> is <s1> \t <s2> \t <s3> \t <s4> \t <s5>

where:


<s1> ASCII - String Label for first generic string.

<s2> ASCII - String Label for second generic string.

<s3> ASCII - String Label for third generic string.

<s4> ASCII - String Label for fourth generic string.

<s5> ASCII - String Label for fifth generic string.

StringLabels




Example: A request on object.GetItem(StringLabels) could return: Cross Invocation Label 1 English Process Cell \t Cross Invocation Label 2 English Process Cell \t Cross Invocation Label 3 English Process Cell \t Cross Invocation Label 4 English Process Cell \t Cross Invocation Label 5 English Process Cell \crlf Cross Invocation Label 1 English Unit \t Cross Invocation Label 2 English Unit \t Cross Invocation Label 3 English Unit \t Cross Invocation Label 4 English Unit \t Cross Invocation Label 5 English Unit \crlf Cross Invocation Label 1 English Phase \t Cross Invocation Label 2 English Phase \t Cross Invocation Label 3 English Phase \t Cross Invocation Label 4 English Phase \t Cross Invocation Label 5 English Phase \crlf Cross Invocation Label 1 English Resource String \t Cross Invocation Label 2 English Resource String \t Cross Invocation Label 3 English Resource String \t Cross Invocation Label 4 English Resource String \t Cross Invocation Label 5 English Resource String \crlf

See also




The TagVerStatus item returns an internationalized string, indicating the current state of the tag verification process.


Input Format Request: TagVerStatus

Output Format The TagVerStatus item returns in this format: <State>

where:


<State> ASCII - String The state of the current tag verification process. Valid states are: • READY

• RUNNING

• ABORTED

• COMPLETE


Example: A request on object.GetItem(TagVerStatus) could return: RUNNING

See also


TagVerStatus



The TagVerStatusOrd item returns an integer indicating the current state of the tag verification process.


Input Format Request: TagVerStatusOrd

Output Format The TagVerStatusOrd item returns in this format: <State>

where:


<State> ASCII - Integer The state of the current tag verification process. Valid states are:

• 0 = READY

• 1 = RUNNING

• 2 = ABORTED

• 3 = COMPLETE


Example: A request on object.GetItem(TagVerStatusOrd) could return: 1

See also


The ThousandsSeparator item returns the thousands separator used by the FactoryTalk Batch Server.


Input Format Request: ThousandsSeparator

Output Format The ThousandsSeparator item returns in this format: <Separator>

where:


<Separator> ASCII - String The thousands separator for the language specific operating system.


Example: A request on object.GetItem(ThousandsSeparator) could return: ,

See also


TagVerStatusOrd

ThousandsSeparator



The Time item returns the FactoryTalk Batch Server’s current time and the data servers' conversation.


Input Format Request: Time.

Output Format The Time item returns in this format:

<TimeData> is <Time> <sp> <DDESvrStatList>

<DDESvrStatList> is <DDESvrStatus> | <DDESvrStatus> <DDESvrStatList>

where:


<Time> ASCII - String If the server finishes initializing, this is the current time, expressed using Windows internationalization and locality settings. If the server does not finish initializing, BOOTING displays.

<DDESvrStatus> ASCII - String The conversation status of the FactoryTalk Batch Server to the configured DDE server(s) Good / Bad / Suspect / Lost English: G / B / S / L French: B / E / S / P German: S / I / F / U Italian: B / C / S / P Spanish: B / E / D / P


Example: A request on object.GetItem(Time) could return: 16:21:21 GG \crlf

See also


Time



The Time2 item returns the FactoryTalk Batch Server’s time stamp and the most severe conversation status of all the data servers.

The severity status from highest to lowest severity is: Lost, Bad, Suspect and Good.


Input Format Request: Time2

Output Format The Time2 item returns in this format:

<TimeData> is <Time> <MostSevereStatus> \crlf

where:


<Time> ASCII - String If the server finishes initializing, this is the current time, expressed using Windows internationalization and locality settings. If the server does not finish initializing, BOOTING displays.

<MostSevere Status>

ASCII character The FactoryTalk Batch Server’s conversation status to the configured DDE server(s) Good / Bad / Suspect / Lost English: G / B / S / L French: B / E / S / P German: S / I / F / U Italian: B / C / S / P Spanish: B / E / D / P


Example: A request on object.GetItem(Time2) could return: 16:21:21 G \crlf

See also


Time2



The TimerIDTimerData item retrieves information about the selected static timer step on the batch list.


Input Format Request: TimerIDTimerData

Output Format The TimerIDTimerData item returns in this format:

<StaticTimerData> is <CreateID> \t <Step Name> \t <State> \t <Mode> \t <CmdMask> \t <FailMsg> \t <UnitID> \t <Unit Name> \t <Recipe Path> \t <ParamList> \t <ParamList> \t <ParamLimitList> \t <RptList> \t <RptLimitList>

where <StaticTimerData> is:


<CreateID> ASCII - String CreateID of associated recipe timer step.

<Step Name> ASCII - String Name of the Timer Step (includes CreateID and path in recipe.

<Recipe Path> ASCII - String For timer steps this field holds the phase class name from the area model.

<ParamList> Variable List Parameters associated with the phase

<ParamLimitList> Variable List Parameter deviation limits associated with the phase

<RptList> Variable List Report parameters associated with the Phase

<RptLimitList> Variable List Report parameter deviation limits associated with the phase.

where <ParamList> is:

<ParamList> is $PARM \t <Parameters> \t $END

<Parameters> is <NullParamList> | <PList>

<NullParamList> is <sp>


<Parameter> is <ParmName> \t <ParmType> \t <ParmKind> \t <EUs> \t <MaxValue> \t <MinValue> \t <Value>



<ParmName> ASCII - String Parameter Name

<ParmType> ASCII - Integer Data Type 1: Real 3: String 2: Long 5: Enumeration

<ParmKind> ASCII - Integer Type of parameter 1: Value 4: Static 2: UnAcked Prompt 5: Material Data 3: Deferred 6: Expression

TimerIDTimerData



<EUs> ASCII - String Eng Unit If <ParmType> =5, then this is the enumeration set If <ParmType> =3, then it is a single space

<MaxValue> ASCII - String Maximum value (Use a single space for strings and enumerations)

<MinValue> ASCII - String Minimum value (Use a single space for strings and enumerations)

<Value> <ParmType> Value assigned to parameter.

where <ParamLimitList> is:

<ParamLimitList> is $PARAMLIMITS \t <ParamLimits> \t $END

<ParamLimits> is <NullParamLimitList> | <PLList>

<NullParamLimitList> is <sp>

<PLList> is <ParameterLimit> | <ParameterLimit> \t <PList>

<ParameterLimit> is <ParmName> \t <Verification Method> \t <HighHighHigh Limit> \t <HighHigh Limit> \t <High Limit> \t <Low Limit> \t <LowLow Limit> \t <LowLowLow Limit>

where <ParameterLimit> is:


<ParmName> ASCII - String Parameter Name

<Verification Method> ASCII - Integer Parameter Verification Method: 0 = No Limits 1 = High/Low 2 = High-High/Low-Low 3 = High-High-High/Low-Low-Low

<HighHighHigh Limit> ASCII - Integer High-High-High Limit

<HighHigh Limit> ASCII - Integer High-High Limit

<High Limit> ASCII - Integer High Limit

<Low Limit> ASCII - Integer Low Limit

<LowLow Limit> ASCII - Integer Low-Low Limit

<LowLowLow Limit> ASCII - Integer Low-Low-Low Limit

where <RptList> is:

<RptList> is $REPORT \t <RptParameters> \t $END

<RptParameters> is <NullRptList> | <RPList>

<RPList> is <ReportParam> | <ReportParam> \t <RPList>

<ReportParam> is <RptName> \t <RptType> \t <EUs> \t <Value>

where <ReportParam> is:


<RptName> ASCII - String Report parameter Name



<RptType> ASCII - Integer Data Type 1: Real 3: String 2: Long 5: Enumeration

<EUs> ASCII - String Eng Unit If <RptType> =5, then this is the enumeration set If <RptType> =3, then it is a single space

where <RptLimitList> is:

<RptLimitsList> is $REPORTLIMITS \t <RptLimits> \t $END

<RptLimits> is <NullRptLimitList> | <RLList>

<NullRptLimitList> is <sp>

<RLList> is <ReportParmLimit> | <ReportParmLimit> \t <RList>

<ReportParmLimit> is <ReportParmName> \t <Verification Method> \t <HighHighHigh Limit> \t <HighHigh Limit> \t <High Limit> \t <Low Limit> \t <LowLow Limit> \t <LowLowLow Limit>

where <ReportParmLimit> is:


<ReportParm Name> ASCII - String Parameter Name

<Verification Method> ASCII - Integer Parameter Verification Method: 0 = No Limits 1 = High/Low 2 = High-High/Low-Low 3 = High-High-High/Low-Low-Low

<HighHighHigh Limit> ASCII - Integer High-High-High Limit

<HighHigh Limit> ASCII - Integer High-High Limit

<High Limit> ASCII - Integer High Limit

<Low Limit> ASCII - Integer Low Limit

<LowLow Limit> ASCII - Integer Low-Low Limit

<LowLowLow Limit> ASCII - Integer Low-Low-Low Limit




Example: A request on object.GetItem(4TimerData) could return: 9\t9:CLS_FRENCHVANILLA\CLS_FRENCHVANILLA_UP:1\TIMER_DN:1\t$TIMER_DN_SECOND\r\n $PARM\tTIMER_TYPE\t5\t1\t$TIMER_TYPE\t \t \tCOUNT_DOWN\tHOLD_BEHAVIOR\t5\t1\t$HOLD_BEHAVIOR\t \t \tCONTINUE\tSETPOINT\t1\t1\tSECONDS\t4147200\t10\t300\t$END\r\n $PARMLIMITS\tTIMER_TYPE\t0\t \t \t \t \t \t \tHOLD_BEHAVIOR\t0\t \t \t \t \t \t \tSETPOINT\t0\t \t \t \t \t \t \t$END\r\n $REPORT\tELAPSED_TIME\t1\tSECONDS\tREMAINING_TIME\t1\tSECONDS\t$END\r\n $REPORTLIMITS\tELAPSED_TIME\t0\t \t \t \t \t \t \tREMAINING_TIME\t0\t \t \t \t \t \t \t$END\r\n

See also


The TimerIDStatus item retrieves dynamic information about a specific Timer step. The TimerID is the internal reference number to a specific Timer on the batch list. This number is unique for all timers on the batch list. (The TimerSteps item can be used to get a list of all the TimerIDs currently on the batch list.)


Input Format Request: TimerIDStatus

Output Format The TimerIDStatus item returns in these formats:

For timers of Type Count_Down:

<DynamicTimerData> is <Elapsed_Time> \t <Remaining_Time> \t <State>

where <DynamicTimerData>:


<State> ASCII - Integer Current state of the Timer step.

<Mode> ASCII - String Mode of the Phase under Recipe Control: O_AUTO P_AUTO

<CmdMask> ASCII - String Command masks

<Unit Name> ASCII - String Current Unit Name

<UnitID> ASCII - Integer Current Unit ID.

<FailMsg> ASCII - Integer Failure Message

<Elapsed_Time> ASCII - Integer Amount of time timer has been in the running state

<Remaining_Time> ASCII - Integer Amount of time remaining (Setpoint - Elapsed_Time)

<Hold Behavior> ASCII - Integer Current Value of the Hold_Behavior Parameter

<Setpoint> ASCII - Integer Current Value of the Setpoint Parameter

For timers of Type Count_Up:

TimerIDTimerStatus



where <DynamicTimerData>:


<State> ASCII - Integer Current state of the Timer step.

<Mode> ASCII - String Mode of the Phase under Recipe Control: O_AUTO P_AUTO

<CmdMask> ASCII - String Command masks

<Unit Name> ASCII - String Current Unit Name

<UnitID> ASCII - Integer Current Unit ID.

<FailMsg> ASCII - Integer Failure Message

<Elapsed_Time> ASCII - Integer Amount of time timer has been in the running state

<Hold Behavior> ASCII - Integer Current Value of the Hold_Behavior Parameter


Example: A request on object.GetItem(4Status) for a COUNT_DOWN timer could return: READY\tP_AUTO\t0\tWP_FREEZER1\t4\t \t250\t50\tCONTINUE\t300\r\n

A request on object.GetItem(4Status) could return this for a COUNT_UP timer: RUNNING\tP_AUTO\t0\t \t\t \t40\tCONTINUE\r\n

See also





The TimerSteps item retrieves selected information about all of the Timer steps currently on the batch list.


Input Format Request: TimerSteps

Output Format The TimerSteps item returns in this format:

<TimerList> is <NullTimerList> | <TLList>

<TLList> is <TimerStep> | <TimerStep> \t <TLList>

where <TimerStep> is:


<TimerID> ASCII - String Internal Timer step ID used to specify a Timer on the Batch List.

<BatchID> ASCII - String User Entered Recipe Batch ID.

<Recipe Path> ASCII - String Path to the Timer Step in the Recipe (Includes Timer step name.

<Unit> ASCII - String Unit the Timer step is bound to. (Procedure Level: Blank Value Unit Procedure and Operation Level: shows Bound unit or Legal Binding option of Prompt or First Available)


Example: A request on object.GetItem(TimerSteps) could return: 2\tBATCH_432\t9:CLS_FRENCHVANILLA\CLS_FRENCHVANILLA_UP:1\CLS_FRENCHVANILLA_OP:1\TIMER_DN:1\tWP_FREEZER1\r\n 3\tBATCH_432\t9:CLS_FRENCHVANILLA\CLS_FRENCHVANILLA_UP:1\CLS_FRENCHVANILLA_OP:1\TIMER_UP:1\tWP_FREEZER1\r\n 4\tBATCH_432\t9:CLS_FRENCHVANILLA\CLS_FRENCHVANILLA_UP:1\TIMER_DN:1\tWP_FREEZER1\r\n 5\tBATCH_432\t9:CLS_FRENCHVANILLA\TIMER_COUNTUP:1\t \r\n 6\tBATCH_432\t9:CLS_FRENCHVANILLA\TIMER_DN:1\t \r\n

See also


TimerSteps



The TotalTagCount item returns an integer indicating the total number of tags, phases, and equipment operation sequences configured in the equipment database.


Input Format Request: TotalTagCount

Output Format The TotalTagCount item returns in this format: <Count>

where:


<Count> ASCII - Integer Total number of tags, phases, and equipment operation sequences configured in the equipment database.


Example: A request on object.GetItem(TotalTagCount) could return: 1053

See also


TotalTagCount



The UEArea_x item returns the area model of the xth unacknowledged prompt in the unacknowledged prompts list.


Input Format Request: UEArea_<RowNumber>


The UEArea_x item requires the batchsvr.ini file to contain this setting in the [CLIENT MGR DDE] section: MaxPromptTableLength = n where n is the maximum number of unacknowledged prompts accessible to this item (the maximum number of entries in the array). And, where 0 ≤ x ≤ MaxPromptTableLength. If the number of unacknowledged prompts in the unacknowledged prompts list is larger than n, then this item will only access the first n unacknowledged prompts in a non-sorted unacknowledged prompts list. When an unacknowledged prompt with an index of less than n is removed from the unacknowledged prompts list, all subsequent unacknowledged prompts will have their index decreased by one. The default value of MaxPromptTableLength is 0 (zero).

Output Format The UEArea_x item returns in this format: <AreaName>

where:


<AreaName> ASCII - String The batch’s area model name issuing the unacknowledged prompt.

This table is an example of an unacknowledged prompts list containing two unacknowledged prompts:

Time Batch ID Desc Value Area Unit Phase

2/24/2017 2:33:45 PM BATCH_99 Charge_ Amount 35 AREA1 UA_1 P1

2/24/2017 2:34:06 PM BATCH_100 Hold_Time 5 AREA1 UA_2 P44


Example: For the area associated with the prompt in the second row of the unacknowledged prompts list, request on object.GetItem(UEArea_2) returns:

AREA1

See also


UEArea_x



The UEBatchID_x item returns the batch identifier of the xth unacknowledged prompt in the unacknowledged prompts list.


Input Format Request: UEBatchID_<RowNumber>


The UEBatchID_x item requires the batchsvr.ini file to contain this setting in the [CLIENT MGR DDE] section: MaxPromptTableLength = n where n is the maximum number of unacknowledged prompts accessible to this item (the maximum number of entries in the array). And, where 0 ≤ x ≤ MaxPromptTableLength. If the number of unacknowledged prompts in the unacknowledged prompts list is larger than n, then this item will only access the first n unacknowledged prompts in a non-sorted unacknowledged prompts list. When an unacknowledged prompt with an index of less than n is removed from the unacknowledged prompts list, all subsequent unacknowledged prompts will have their index decreased by one. The default value of MaxPromptTableLength is 0 (zero).

Output Format The UEBatchID_x item returns in this format: <Batch ID>

where:


<Batch ID> ASCII - String Operator entered batch identification value.



2/24/2017 2:33:45 PM BATCH_99 Charge_Amount 35 AREA1 UA_1 P1



Example: For the batch ID of the prompt in the first row of the unacknowledged prompts list, advise on object.GetItem(UEBatchID_1) would return:

BATCH_99

See also


UEBatchID_x



The UEDefault_x item returns the default value for the xth unacknowledged prompt in the unacknowledged prompts list.


Input Format Request: UEDefault_<RowNumber>


The UEDefault_x item requires the batchsvr.ini file to contains this setting in the [CLIENT MGR DDE] section: MaxPromptTableLength = n where n is the maximum number of unacknowledged prompts accessible to this item (the maximum number of entries in the array). And, where 0 ≤ x ≤ MaxPromptTableLength. If the number of unacknowledged prompts in the unacknowledged prompts list is larger than n, then this item will only access the first n unacknowledged prompts in a non-sorted unacknowledged prompts list. When an unacknowledged prompt with an index of less than n is removed from the unacknowledged prompts list, all subsequent unacknowledged prompts will have their index decreased by one. The default value of MaxPromptTableLength is 0 (zero).

Output Format The UEDefault_x item returns in this format: <DefaultValue>

where:


<DefaultValue> ASCII - String The default value assigned to the parameter which issued the unacknowledged prompt.



2/24/2017 2:33:45 PM BATCH_99 Charge_Amount 35 AREA1 UA_1 P1



Example: For the default value of the prompt in the first row of the unacknowledged prompts list, advise on object.GetItem(UEDefault_1) would return:

35

See also


UEDefault_x



The UEDesc_x item returns the description of the xth unacknowledged prompt in the unacknowledged prompts list.


Input Format Request: UEDesc_<RowNumber>


The UEDesc_x item requires the batchsvr.ini file to contain this setting in the [CLIENT MGR DDE] section: MaxPromptTableLength = n where n is the maximum number of unacknowledged prompts accessible to this item (the maximum number of entries in the array). And, where 0 ≤ x ≤ MaxPromptTableLength. If the number of unacknowledged prompts in the unacknowledged prompts list is larger than n, then this item will only access the first n unacknowledged prompts in a non-sorted unacknowledged prompts list. When an unacknowledged prompt with an index of less than n is removed from the unacknowledged prompts list, all subsequent unacknowledged prompts will have their index decreased by one. The default value of MaxPromptTableLength is 0 (zero).

Output Format The UEDesc_x item returns in this format: <Description>

where:


<Description> ASCII - String Name of the parameter into which the prompt is stored.






Example: For the description of the prompt in the first row of the unacknowledged prompts list, advise on object.GetItem(UEDesc_1) would return:

Charge_Amount

See also


UEDesc_x



The UEEU_x item returns the engineering units for the xth unacknowledged prompt in the unacknowledged prompts list.


Input Format Request: UEEU_<RowNumber>


The UEEU_x item requires the batchsvr.ini file to contain this setting in the [CLIENT MGR DDE] section: MaxPromptTableLength = n where n is the maximum number of unacknowledged prompts accessible to this item (the maximum number of entries in the array). And, where 0 ≤ x ≤ MaxPromptTableLength. If the number of unacknowledged prompts in the unacknowledged prompts list is larger than n, then this item will only access the first n unacknowledged prompts in a non-sorted unacknowledged prompts list. When an unacknowledged prompt with an index of less than n is removed from the unacknowledged prompts list, all subsequent unacknowledged prompts will have their index decreased by one. The default value of MaxPromptTableLength is 0 (zero).

Output Format The UEEU_x item returns in this format: <EUs>

where:


<EUs> ASCII - String Engineering units associated with the parameter.


Time Batch ID Desc Value Area Unit EU

2/24/2017 2:33:45 PM BATCH_99 Charge_ Amount 35 AREA1 UA_1 lbs

2/24/2017 2:34:06 PM BATCH_100 Hold_Time 5 AREA1 UA_2 minutes


Example: For the engineering units of the prompt in the second row of the unacknowledged prompts list, a request on object.GetItem(UEEU_2) would return:

minutes

See also


UEEU_x



The UEEvent_x item returns the event type for the xth unacknowledged prompt in the unacknowledged prompts list.


Input Format Request: UEEvent_<RowNumber>


The UEEvent_x item requires the batchsvr.ini file to contain this setting in the [CLIENT MGR DDE] section: MaxPromptTableLength = n where n is the maximum number of unacknowledged prompts accessible to this item (the maximum number of entries in the array). And, where 0 ≤ x ≤ MaxPromptTableLength. If the number of unacknowledged prompts in the unacknowledged prompts list is larger than n, then this item will only access the first n unacknowledged prompts in a non-sorted unacknowledged prompts list. When an unacknowledged prompt with an index of less than n is removed from the unacknowledged prompts list, all subsequent unacknowledged prompts will have their index decreased by one. The default value of MaxPromptTableLength is 0 (zero).

Output Format The UEEvent_x item returns in this format: <EventType>

where:


<EventType> ASCII - String The event type is assigned by the FactoryTalk Batch Server and used to sort events in the event journals. For unacknowledged prompts, the type will always be Prompt.






Example: For the event type of the prompt in the second row of the unacknowledged prompts list, a request on object.GetItem(UEEvent_2) would return:

Prompt

See also


UEEvent_x



The UEEventID_x item returns the unique identifier assigned by the FactoryTalk Batch Server to the xth unacknowledged prompt in the unacknowledged prompts list.


Input Format Request: UEEventID_<RowNumber>


The UEEventID_x item requires the batchsvr.ini file to contain this setting in the [CLIENT MGR DDE] section: MaxPromptTableLength = n where n is the maximum number of unacknowledged prompts accessible to this item (the maximum number of entries in the array). And, where 0 ≤ x ≤ MaxPromptTableLength. If the number of unacknowledged prompts in the unacknowledged prompts list is larger than n, then this item will only access the first n unacknowledged prompts in a non-sorted unacknowledged prompts list. When an unacknowledged prompt with an index of less than n is removed from the unacknowledged prompts list, all subsequent unacknowledged prompts will have their index decreased by one. The default value of MaxPromptTableLength is 0 (zero).

Output Format The UEEventID_x item returns in this format: <EventID>

where:


<EventID> ASCII - Integer The unique event identifier assigned by the FactoryTalk Batch Server to keep track of issued prompts.

This table is an example of an unacknowledged prompts list containing two unacknowledged prompts. The Event ID is batch data that is not displayed in the Batch List window.

Time Batch ID Desc Value Unit Phase Event ID

2/24/2017 2:33:45 PM BATCH_99 Charge_ Amount 35 UA_1 P1 20

2/24/2017 2:34:06 PM BATCH_100 Hold_Time 5 UA_2 P44 21


Example: For the prompt’s event ID in the second row of the unacknowledged prompts list, advise on object.GetItem(UEEventID_2) could return:

21

See also


UEEventID_x



The UEHigh_x item returns the high limit for the prompted parameter for the xth unacknowledged prompt in the unacknowledged prompts list.


Input Format Request: UEHigh_<RowNumber>


The UEHigh_x item requires the batchsvr.ini file to contain this setting in the [CLIENT MGR DDE] section: MaxPromptTableLength = n where n is the maximum number of unacknowledged prompts accessible to this item (the maximum number of entries in the array). And, where 0 ≤ x ≤ MaxPromptTableLength. If the number of unacknowledged prompts in the unacknowledged prompts list is larger than n, then this item will only access the first n unacknowledged prompts in a non-sorted unacknowledged prompts list. When an unacknowledged prompt with an index of less than n is removed from the unacknowledged prompts list, all subsequent unacknowledged prompts will have their index decreased by one. The default value of MaxPromptTableLength is 0 (zero).

Output Format The UEHigh_x item returns in this format: <HighLimit>

where:


<HighLimit> ASCII - Integer Maximum allowed value.

This table is an example of an unacknowledged prompts list containing two unacknowledged prompts. Shaded columns represent batch data that is not displayed in the Batch List window.

Time Batch ID Desc Value Unit Phase High


2/24/2017 2:34:06 PM BATCH_100 Bake_ Time 5 UA_2 P44 50


Example: For the prompt’s high limit in the first row of the unacknowledged prompts list, advise on object.GetItem(UEHigh_1) would return:

100

See also


UEHigh_x



The UELow_x item returns the low limit for the prompted parameter for the xth unacknowledged prompt in the unacknowledged prompts list.


Input Format Request: UELow_<RowNumber>


The UELow_x item requires the batchsvr.ini file to contain this setting in the [CLIENT MGR DDE] section: MaxPromptTableLength = n where n is the maximum number of unacknowledged prompts accessible to this item (the maximum number of entries in the array). And, where 0 ≤ x ≤ MaxPromptTableLength. If the number of unacknowledged prompts in the unacknowledged prompts list is larger than n, then this item will only access the first n unacknowledged prompts in a non-sorted unacknowledged prompts list. When an unacknowledged prompt with an index of less than n is removed from the unacknowledged prompts list, all subsequent unacknowledged prompts will have their index decreased by one. The default value of MaxPromptTableLength is 0 (zero).

Output Format The UELow_x item returns in this format: <LowLimit>

where:


<LowLimit> ASCII - String Minimum allowed value.

This table is an example of an unacknowledged prompts list containing two unacknowledged prompts. Shaded columns represent batch data that is not displayed in the Batch List window.

Time Batch ID Desc Value Unit Phase Low


2/24/2017 2:34:06 PM BATCH_100 Hold_Time 5 UA_2 P44 0


Example: For the prompt’s low limit in the second row of the unacknowledged events list, a request on object.GetItem(UELow_2) would return:

0

See also


UELow_x



The UEPhase_x item returns the phase value for the prompted parameter for the xth unacknowledged prompt in the unacknowledged prompts list.


Input Format Request: UEPhase_<RowNumber>


The UEPhase_x item requires the batchsvr.ini file to contain this setting in the [CLIENT MGR DDE] section: MaxPromptTableLength = n where n is the maximum number of unacknowledged prompts accessible to this item (the maximum number of entries in the array). And, where 0 ≤ x ≤ MaxPromptTableLength. If the number of unacknowledged prompts in the unacknowledged prompts list is larger than n, then this item will only access the first n unacknowledged prompts in a non-sorted unacknowledged prompts list. When an unacknowledged prompt with an index of less than n is removed from the unacknowledged prompts list, all subsequent unacknowledged prompts will have their index decreased by one. The default value of MaxPromptTableLength is 0 (zero).

Output Format The UEPhase_x item returns in this format: <PhaseName>

where:


<PhaseName> ASCII - String Phase which originated the prompt.






Example: For the phase associated with the prompt in the second row of the unacknowledged events list, a request on object.GetItem(UEPhase_2) would return:

P44

See also


UEPhase_x



The UEProcCell_x item returns the process cell value for the prompted parameter for the xth unacknowledged prompt in the unacknowledged prompts list.


Input Format Request: UEProcCell_<RowNumber>


The UEProcCell_x item requires the batchsvr.ini file to contain this setting in the [CLIENT MGR DDE] section: MaxPromptTableLength = n where n is the maximum number of unacknowledged prompts accessible to this item (the maximum number of entries in the array). And, where 0 ≤ x ≤ MaxPromptTableLength. If the number of unacknowledged prompts in the unacknowledged prompts list is larger than n, then this item will only access the first n unacknowledged prompts in a non-sorted unacknowledged prompts list. When an unacknowledged prompt with an index of less than n is removed from the unacknowledged prompts list, all subsequent unacknowledged prompts will have their index decreased by one. The default value of MaxPromptTableLength is 0 (zero).

Output Format The UEProcCell_x item returns in this format: <ProcCellName>

where:


<ProcCellName> ASCII - String Process cell in which the phase originating the prompt is running.


Time Batch ID Desc Value Process Cell Unit Phase

2/24/2017 2:33:45 PM BATCH_99 Charge_ Amount 35 PC_A UA_1 P1

2/24/2017 2:34:06 PM BATCH_100 Hold_Time 5 PC_A UA_2 P44


Example: For the process cell with which the prompt in the second row of the unacknowledged prompts list is associated, a request on object.GetItem(UEProcCell_2) would return:

PC_A

See also


UEProcCell_x



The UERecipe_x item returns the recipe value for the prompted parameter the xth unacknowledged prompt in the unacknowledged prompts list.


Input Format Request: UERecipe_<RowNumber>


The UERecipe_x item requires the batchsvr.ini file to contain this setting in the [CLIENT MGR DDE] section: MaxPromptTableLength = n where n is the maximum number of unacknowledged prompts accessible to this item (the maximum number of entries in the array). And, where 0 ≤ x ≤ MaxPromptTableLength. If the number of unacknowledged prompts in the unacknowledged prompts list is larger than n, then this item will only access the first n unacknowledged prompts in a non-sorted unacknowledged prompts list. When an unacknowledged prompt with an index of less than n is removed from the unacknowledged prompts list, all subsequent unacknowledged prompts will have their index decreased by one. The default value of MaxPromptTableLength is 0 (zero).

Output Format The UERecipe_x item returns in this format:

<UERecipe_x> is <Recipe>

<Recipe> is <CreateID>:<PathToPhase>-<ConnectNum>

where:


<CreateID> ASCII - Integer Unique identifier assigned by the FactoryTalk Batch Server to the batch where this prompt originated.

<PathToPhase> ASCII - String Path through the levels of the batch’s recipe to the phase which made the download request then became this prompt.

<ConnectNum> ASCII - Integer Number of times this phase has been connected to through DDE while the recipe or subrecipe has been running (this is roughly but not always equal to the number of times the phase ran).

UERecipe_x




Time Batch ID Recipe Desc Unit Phase

2/24/2017 2:33:45 PM BATCH_99 12: French_Vanilla Charge_ Amount UA_1 P1

2/24/2017 2:34:06 PM BATCH_100 17:MCLS_FRENCHVANILLA\ P44:1-1

Hold_Time UA_2 P44


Example: For the recipe associated with the prompt in the first row of the unacknowledged prompts list, a request on object.GetItem(UERecipe_1) would return:

12:French_Vanilla:1-1

See also


The UERespType_x item returns the expected response’s data type for the prompted parameter in the xth unacknowledged prompt in the unacknowledged prompts list.


Input Format Request: UERespType_<RowNumber>


The UERespType_x item requires the batchsvr.ini file to contain this setting in the [CLIENT MGR DDE] section: MaxPromptTableLength = n where n is the maximum number of unacknowledged prompts accessible to this item (the maximum number of entries in the array). And, where 0 ≤ x ≤ MaxPromptTableLength. If the number of unacknowledged prompts in the unacknowledged prompts list is larger than n, then this item will only access the first n unacknowledged prompts in a non-sorted unacknowledged prompts list. When an unacknowledged prompt with an index of less than n is removed from the unacknowledged prompts list, all subsequent unacknowledged prompts will have their index decreased by one. The default value of MaxPromptTableLength is 0 (zero).

Output Format The UERespType_x item returns in this format: <DataType>

where:

UERespType_x




<DataType> ASCII - Integer Data type for the response: • 1: Real

• 2: Long Integer

• 3: String

• 5: Enumeration

This example is an unacknowledged prompts list containing two unacknowledged prompts. Data Type does not display in the Batch List window.

Time Batch ID Desc Value Area Unit Data Type

2/24/2017 2:33:45 PM BATCH_99 Charge_ Amount 35 AREA1 UA_1 2

2/24/2017 2:34:06 PM BATCH_100 Hold_Time 5 AREA1 UA_2 2


Example: For the data type associated with the prompt in the first row of the unacknowledged prompts list, a request on object.GetItem(UERespType_1) would return:

2

See also




The UETime_x item returns the time for the xth unacknowledged prompt in the unacknowledged prompts list.


Input Format Request: UETime_<RowNumber>


The UETime_x item requires the batchsvr.ini file to contain this setting in the [CLIENT MGR DDE] section: MaxPromptTableLength = n where n is the maximum number of unacknowledged prompts accessible to this item (the maximum number of entries in the array). And, where 0 ≤ x ≤ MaxPromptTableLength. If the number of unacknowledged prompts in the unacknowledged prompts list is larger than n, then this item will only access the first n unacknowledged prompts in a non-sorted unacknowledged prompts list. When an unacknowledged prompt with an index of less than n is removed from the unacknowledged prompts list, all subsequent unacknowledged prompts will have their index decreased by one. The default value of MaxPromptTableLength is 0 (zero).

Output Format The UETime_x item returns in this format: <Time>

where:


<Time> ASCII - String Time the prompt was issued and formatted according to Windows internationalization and locality settings.



2/24/2017 2:33:45 PM LotABC Manual_ Charge_ Amount 100 PC_A UA_1 P1

2/24/2017 2:34:06 PM LotGHI Bake_ Time 35 PC_A UA_2 P44


Example: For the time associated with the prompt in the first row of the unacknowledged prompts list, a request on object.GetItem(UETime_1) would return:

2/24/2017 2:33:45 PM

See also


UETime_x



The UEUnit_x item returns the unit for the xth unacknowledged prompt in the unacknowledged prompts list.


Input Format Request: UEUnit_<RowNumber>


The UEUnit_x item requires the batchsvr.ini file to contain this setting in the [CLIENT MGR DDE] section: MaxPromptTableLength = n where n is the maximum number of unacknowledged prompts accessible to this item (the maximum number of entries in the array). And, where 0 ≤ x ≤ MaxPromptTableLength. If the number of unacknowledged prompts in the unacknowledged prompts list is larger than n, then this item will only access the first n unacknowledged prompts in a non-sorted unacknowledged prompts list. When an unacknowledged prompt with an index of less than n is removed from the unacknowledged prompts list, all subsequent unacknowledged prompts will have their index decreased by one. The default value of MaxPromptTableLength is 0 (zero).

Output Format The UEUnit_x item returns in this format: <UnitName>

where:


<UnitName> ASCII - String Name of the unit the phase originating the prompt is bound to.






Example: For the unit associated with the prompt in the first row of the unacknowledged prompts list, a request on object.GetItem(UEUnit_1) would return:

UA_1

See also


UEUnit_x



The UEValue_x item returns the value for the xth unacknowledged prompt in the unacknowledged prompts list.


Input Format Request: UEValue_<RowNumber>


The UEValue_x item requires the batchsvr.ini file to contain this setting in the [CLIENT MGR DDE] section: MaxPromptTableLength = n where n is the maximum number of unacknowledged prompts accessible to this item (the maximum number of entries in the array). And, where 0 ≤ x ≤ MaxPromptTableLength. If the number of unacknowledged prompts in the unacknowledged prompts list is larger than n, then this item will only access the first n unacknowledged prompts in a non-sorted unacknowledged prompts list. When an unacknowledged prompt with an index of less than n is removed from the unacknowledged prompts list, all subsequent unacknowledged prompts will have their index decreased by one. The default value of MaxPromptTableLength is 0 (zero).

Output Format The UEValue_x item returns in this format: <Value>

where:


<Value> ASCII - String Value of the unacknowledged prompt prior to being answered by the operator is the configured default value of the parameter.






Example: For the value associated with the prompt in the first row of the unacknowledged prompts list, a request on object.GetItem(UEValue_1) would return:

35

See also


UEValue_x



The UnAcknowledgedEvents item returns a list of all outstanding operator prompts.


Input Format Request: UnAcknowledgedEvents

Output Format The UnAcknowledgedEvents item returns in this format:

<UnAckEvents> is <NullList> | <PromptsList>

<PromptsList> is <Prompt> | <Prompt> /crlf <PromptsList>

<Prompt> is <OldPrompt> | <OldPrompt> /t <ActionID> /t <HighLimit> /t <HighHighLimit> /t <HighHighHighLimit> /t <LowLimit> /t <LowLowLimit> /t <LowLowLowLimit>

<OldPrompt> is <Time> /t <BatchID> /t <RecipePath> /t <Description> /t <Event> /t <Value> /t <EngUnits> /t <Area> /t <PCell> /t <Unit> /t <Phase> /t <UnAckedPromptID> /t <ParamDataType> /t <High> /t <Low> /t <Default>

where:


<ActionID> ASCII - Integer Action ID as a 32-bit unsigned integer. If non-zero, it is the ActionID of an Ack that is pending for the UnacknowledgedEvent. If zero, then there is no Ack pending.

<HighLimit> ASCII – Value High deviation limit for prompts with a <ParamDataType> value of 1 or 2. A value returns when the limit value is defined and a Signature Template is defined, otherwise this field is empty.

<HighHighLimit> ASCII – Value High high deviation limit for prompts with a <ParamDataType> value of 1 or 2. A value returns when the limit value is defined and a Signature Template is defined, otherwise this field is empty.

<HighHighHighLimit> ASCII – Value High high high deviation limit for prompts with a <ParamDataType> value of 1 or 2. A value returns when the limit value is defined and a Signature Template is defined, otherwise this field is empty.

<LowLimit> ASCII – Value Low deviation limit for prompts with a <ParamDataType> value of 1 or 2. A value returns when the limit value is defined and a Signature Template is defined, otherwise this field is empty.

<LowLowLimit> ASCII – Value Low low deviation limit for prompts with a <ParamDataType> value of 1 or 2. A value returns when the limit value is defined and a Signature Template is defined, otherwise this field is empty.

<LowLowLowLimit> ASCII – Value Low low low deviation limit for prompts with a <ParamDataType> value of 1 or 2. A value returns when the limit value is defined and a Signature Template is defined, otherwise this field is empty.

<Time> ASCII - String hh:mm

The time at which the event was generated, as formatted within the Control Panel.

<BatchID> ASCII - String Operator-entered batch identification number.

<RecipePath> ASCII - String The path within the recipe to the phase where the unacknowledged prompt originated.

UnAcknowledgedEvents



<Description> ASCII - String A description of the event.

<Event> ASCII - String The type of event. Contains the string Prompt.

<Value> ASCII - String The current value associated with the event. The value will be set to the parameter’s default value until the prompt is acknowledged. For binding prompts, the value will be unit, unitid, unit, unitid.

<EngUnits> ASCII - String Engineering units associated with the event, if any. MATERIALS returns for material phase binding.

<Area> ASCII - String Area from the equipment database.

<PCell> ASCII - String Process cell in which the event occurred.

<Unit> ASCII - String Unit in which the event occurred. For binding prompts the unit will contain the alias name.

<Phase> ASCII - String Phase in which the event occurred.

<UnAckedPromptID> ASCII - String Unique FactoryTalk Batch Server assigned identification number.

<ParamData Type>

ASCII - String Data type for the response 1=real, 2=long, 3=string, 5=enumeration, 10=binding, 20=phase binding.

<MaxValue> ASCII - String Maximum allowed value. Not used for binding prompts.

<MinValue> ASCII - String Minimum allowed value. Not used for binding prompts.

<Default> ASCII - String Default value.


Example: A request on object.GetItem(UnAcknowledgedEvents) could return: 2/24/2017 4:21:14 PM /t BATCH100 /t 17:FRENCHVANILLA\SWEETCREAMUP:1\SWEETCREAMOP:1 \t EMPCTL:1-1 \t HOLDTIME \t Prompt \t MINUTES \t AREA1 \t NORTHPARLOR \t NPMIXER2 \t NPHEATM2 \t 1 \t 60 \t 5 \t 64 \t 10 \t 20 \t 40 \t 3 \t 2 \t 1

See also




The UnacknowledgedEventsCt item returns the number of unacknowledged prompts in the unacknowledged prompts list.


Input Format Request: UnacknowledgedEventsCt

Output Format The UnacknowledgedEventsCt item returns in this format: <NumberOfPrompts>

where:


<NumberOfPrompts> ASCII - Integer Number of prompts currently in the unacknowledged prompts list.


Example: A request on object.GetItem(UnacknowledgedEventsCt) could return: 1

See also


UnacknowledgedEventsCt



The UnitBitMaps item returns the unit IDs and bitmap files for all the units in the system.


Input Format Request: UnitBitMaps

Output Format The UnitBitMaps item returns in this format:

<UnitBitMaps> is <NullList> | <BitMapList>

<BitMapList> is <BitMap> | <BitMap> \crlf <BitMapList>

<BitMap> is <BitMapIndex> \t <UnitName>

where <BitMap> is:


<BitMapIndex> ASCII - Integer Location of the bit map in the unit items.



Example: A request on object.GetItem(UnitBitMaps) returns: 0 \t MIX-1.BMP \crlf 1 \t MIX-1.BMP \crlf ... 13 \t CompactSpray.BMP \crlf

See also


UnitBitMaps



The UnitIDBatchID item lists the operator-entered batch ID for the batch to which the unit belongs.


Input Format Request: UnitIDBatchID

UnitID is ASCII - Integer, the unique Equipment ID corresponding to the unit.

Output Format The UnitIDBatchID item returns in this format:

<BatchID> is ASCII - String (user defined)


Example: A request on object.GetItem(55BatchID) returns: Batch_100

See also


UnitIDBatchID



The UnitIDOperations item returns a list of the equipment operation sequences within the unit specified by the unit ID.


Input Format Request: UnitIDOperations

UnitID is An ASCII - integer representing the unique equipment ID corresponding to the unit.

Output Format The UnitIDOperations item returns in this format:

<OperationsList> is <Operation> \crlf | <Operation> \crlf <OperationList>

<Operation> is <OpSeqID> \t <OpSeqName> \t <MaxOwners> \t <OperationType> \t <XCord> \t <YCord> \t <BitMapIndex>

where <Operation> is:


<OpSeqID> ASCII - Integer Equipment ID of the equipment operation sequence.

<OpSeqName> ASCII - String Name of the equipment operation sequence configured in FactoryTalk Batch Equipment Editor.


<OperationType> ASCII - Integer This is an equipment operation sequence, so this field is not used.

<XCord> ASCII - Integer X coordinate for the bitmap in the Equipment View.

<YCord> ASCII - Integer Y coordinate for the bitmap in the Equipment View.

<BitMapIndex> ASCII - Integer Location of bitmap in the List of Phase Bitmap items. This field is not used.


Example: A request on object.GetItem(55Operations) could return: 68 \t MAKE_CHOCOLATE_CUSTARD \t 1 \t 0 \t 95 \t 88 \t 0 \crlf 70 \t MAKE_VANILLA_CUSTARD \t 2 \t 0 \t 362 \t 89 \t 0 \crlf

See also


UnitIDOperations



The UnitIDPhaseBitmaps item returns a filename list for the phase bitmaps within the unit specified by the unit ID. This is a companion item to the UnitIDPhases item. The files are returned in the same order as <BitMapIndex> in UnitIDPhases.


Input Format Request: UnitIDPhaseBitmaps

<UnitID > is ASCII – String, the unique equipment ID corresponding to the unit.

Output Format The UnitIDPhaseBitmaps item returns in this format: <List>

<List> is <BitMap> \crlf <List>

<BitMap> is <BitMapIndex>\t<FileName>

where:


<BitMapIndex> ASCII - Integer Location of bit map in the List of Phase Bitmap items – same offset as returned in UnitIDPhases.

<FileName> ASCII - String Filename of the bitmap.


Example: A request on object.GetItem(55PhaseBitmaps) could return: 0 \t dump2&.bmp \crlf 1 \t dump2&.bmp \crlf ... 5 \t t-in.bmp \crlf

See also


UnitIDPhaseBitmaps



The UnitIDPhases item returns a list of all the phases within the unit specified by the unit ID.


Input Format Request: UnitIDPhases

UnitID is An ASCII - Integer representing the unique equipment ID corresponding to the unit.

Output Format The UnitIDPhases item returns in this format:

<PhaseList> is <Phase> \crlf <Phase> \crlf <PhaseList>

<Phase> is <PhaseID> \t <PhaseName> \t <MaxOwners> \t <XCord> \t <Ycord> \t <BitMapIndex>

where <Phase> is:


<PhaseID> ASCII - Integer Phase’s resource ID.

<PhaseName> ASCII - String Phase name.


<XCord> ASCII - Integer X coordinate for the bitmap in the Equipment View


<BitMapIndex> ASCII - Integer Location of bitmap in the List of Phase Bitmap items.


Example: A request on object.GetItem(55Phases) returns: 68 \t NP_ADDDAIRY_M1 \t 1 \t 95 \t 88 \t 1 \crlf 70 \t NP_ADDEGG_M1 \t 1 \t 362 \t 89 \t 2 \crlf 72 \t NP_HEAT_M1 \t 1 \t 343 \t 182 \t 3 \crlf 71 \t NP_AGITATE_M1 \t 1 \t 235 \t 183 \t 4 \crlf 73 \t NP_XFR_OUT_M1 \t 1 \t 233 \t 362 \t 5 \crlf

See also


UnitIDPhases



The UnitIDPhases2 item returns a list of all the phases within the unit specified by the Unit ID, including whether or not there is an associated control strategy.


Input Format Request: UnitIDPhases2

UnitID is ASCII - Integer, the unique Equipment ID corresponding to the unit.

Output Format The UnitIDPhases2 item returns in this format:

<PhaseList2> is <Phase2> \crlf | <Phase2> \crlf <PhaseList2>

<Phase2> is <PhaseID> \t <PhaseName> \t <MaxOwners> \t <PhaseType> \t<XCord> \t <YCord> \t <BitMapIndex>

where <Phase2> is:


<PhaseID> ASCII - Integer Phase’s resource ID.

<PhaseName> ASCII - String Phase name.

<MaxOwners> ASCII - Integer Max number of owners.

<PhaseType> ASCII – Integer Type of phase:

• 0 = No Control Strategy

• 1 = Control Strategy

<XCord> ASCII - Integer X coordinate for the bitmap in the Equipment View.


<BitMapIndex> ASCII - Integer Location of the bitmap in the List of Phase Bitmap items.


Example: A request on object.GetItem(55Phases2) could return: 68 \t NP_ADDDAIRY_M1 \t 1 \t 2 \t 95 \t 88 \t 1 \crlf 70 \t NP_ADDEGG_M1 \t 1 \t 2 \t 362 \t 89 \t 2 \crlf 72 \t NP_HEAT_M1 \t 1 \t 0 \t 343 \t 182 \t 3 \crlf 71 \t NP_AGITATE_M1 \t 1 \t 0 \t 235 \t 183 \t 4 \crlf 73 \t NP_XFR_OUT_M1 \t 1 \t 0 \t 233 \t 362 \t 5 \crlf

See also


UnitIDPhases2



The UnitIDUnitTagData item returns the unit name, unit class, and tag status information for the specified unit.


Input Format Request: UnitIDUnitTagData

UnitID is ASCII - String, the unique ID corresponding to the unit.

Output Format The UnitIDUnitTagData item is returned in this format:

<UnitTagData> is <UnitName> \crlf <UnitClassName> \crlf <Tags>

<Tags> is <NullList> | <TagList>

<TagList> is <TagInfo> | <TagInfo> \t <TagList>

<TagInfo> is <TagName> \t <DataServerName> \t <ConfigString1> \t ConfigString2> \t <ConfigString3> \t <ConfigString4> \t <Protocol> \t <ConfiguredDataType> \t <OPCAdviseItemDataType> \t <OPCReadItemDataType> \t <OPCWriteItemDataType> \t <AdviseStatus> \t <LatestAdviseValue> \t <LatestAdviseValueQuality> \t <LatestAdviseValueTimestamp> \t <ReadStatus> \t <LatestReadValue> \t <LatestReadValueQuality> \t <LatestReadValueTimestamp> \t <WriteStatus> \t <LastValueWritten> \t <LastWriteResult> \t <LastWriteTimestamp>

where:


<UnitName> ASCII - String Unit name.

<UnitClassName> ASCII - String Unit class name to which the unit belongs.

<TagName> ASCII - String Protocol-specific configuration string: OPC - Tag name DDE - Tag name CIP - Unused (<sp>) FTD - Tag name

<DataServerName> ASCII - String Protocol-specific configuration string: OPC - Data server name the tag uses. DDE - Data server name the tag uses. CIP - Unused (<sp>) FTD - Data server name the tag uses.

<ConfigString1> ASCII - String Protocol-specific configuration string: OPC - Read Item Access Path DDE - Read Item Topic Name CIP - Unused (<sp>) FTD - Read Item Access Path

UnitIDUnitTagData



<ConfigString2> ASCII - String Protocol-specific configuration string: OPC - Read Item Name DDE - Read Item Name CIP - Unused (<sp>) FTD - Read Item Name

<ConfigString3> ASCII - String Protocol-specific configuration string. Usage per protocol is: OPC - Write Item Access Path DDE - Write Item Topic Name CIP - Unused (<sp>) FTD - Write Item Access Path

<ConfigString4> ASCII - String Protocol-specific configuration string: OPC - Write Item Name DDE - Write Item Name CIP - Unused (<sp>) FTD - Write Item Name

<Protocol> ASCII - String String indicating communication protocol for the tag: DDE, OPC, CIP or FTD.

<ConfiguredDataType> ASCII - Integer Ordinal indicating data type configured for tag in area model. 1 = FLOAT 2 = INTEGER 3 = STRING 5 = ENUMERATION

<OPCAdviseItem DataType>

ASCII - Integer Protocol-specific string. OPC – Ordinal indicating OLE variant type returned by the data server for advises. These ordinals are defined by Windows. Some common values are: 2 = Two byte integer 3 = Four byte integer 4 = Four byte real 5 = Eight byte real 8 = String 11 = Boolean 17 = Unsigned char (1 byte unsigned integer) DDE – Unused (<sp>) CIP – Unused (<sp>) FTD - Same as OPC

<OPCReadItem DataType>

ASCII - Integer Protocol-specific string. OPC – Ordinal indicating OLE variant type returned by the data server for advises. These ordinals are defined by Windows. Some common values are: 2 = Two byte integer 3 = Four byte integer 4 = Four byte real 5 = Eight byte real 8 = String 11 = Boolean 17 = Unsigned char (1 byte unsigned integer) DDE – Unused (<sp>) CIP – Unused (<sp>) FTD - Same as OPC



<OPCWriteItem DataType>

ASCII - Integer Protocol-specific string. OPC – Ordinal indicating OLE variant type returned by the data server for writes. These ordinals are defined by Windows. Some common values are: 2 = Two byte integer 3 = Four byte integer 4 = Four byte real 5 = Eight byte real 8 = String 11 = Boolean 17 = Unsigned char (1 byte unsigned integer) DDE – Unused (<sp>) CIP – Unused (<sp>) FTD - Same as OPC

<AdviseStatus> ASCII - Integer Ordinal indicating current status of any advise operation associated with the tag. 0 = NOT ADVISED 1 = ADVISED - Advise established and initial value received 2 = PENDING - Pending asynchronous establishment 3 = ENDING - Asynchronously ending advise 4 = FAILED 5 = ESTABLISHED - Advised, but no initial value received 9 = UNDEFINED/ERROR

<LatestAdviseValue> ASCII - String The latest data value received by the tag resulting from an update of an advise or active item. The value of the tag is converted to a string representation. If a data update is not received via an advise mechanism, then this field is empty.

<LatestAdvise ValueQuality>

ASCII - Integer Protocol-specific value. OPC: Quality value per OPC specification DDE: 192 = GOOD 0 = BAD CIP: 0 = GOOD Non-Zero = BAD FTD: Same as OPC If an advise data update is not received, then this field is empty.

<LatestAdviseValue Timestamp> ASCII - String Timestamp associated with the most recent advise value. This is not an OPC timestamp. This timestamp is recorded by the FactoryTalk Batch Server at the time it received the data update. The time is represented by a string in the format: "%m/%d/%Y%H:%M:%S". If no data update has ever been received, then this field is empty.

<ReadStatus> ASCII - Integer Ordinal indicating current status of any read operation associated with the tag. 0 = NOT PENDING 1 = FAILED 2 = PENDING 9 = UNDEFINED/ERROR

<LatestRead Value>

ASCII - String Latest data value received by the tag as the result of a completed read operation. The tag value is converted to a string representation. If a read operation is never successfully completed, then this field is empty.



<LatestRead ValueQuality>

ASCII - Integer Protocol-specific value. OPC – Quality value per OPC specification DDE – 192 = GOOD 0 = BAD CIP – 0 = GOOD Non-Zero = BAD FTD – Same as OPC If a read operation is not successfully executed, then this field is empty.

<LatestReadValueTimestamp> ASCII - String Timestamp associated with the most recently read value. This is not an OPC timestamp. The FactoryTalk Batch Server records this timestamp at the time it receives the read data. The time is represented by a string in the format: "%m/%d/%Y %H:%M:%S". If data is never successfully read, then this field is empty.

<WriteStatus> ASCII - Integer Ordinal indicating current status of any write operation associated with the tag. 0 = NOT PENDING 1 = FAILED 2 = PENDING 9 = UNDEFINED/ERROR

<LastValueWritten> ASCII - String Last value (depicted as a string) the FactoryTalk Batch Server wrote to the tag. If the tag is never successfully written to, this field is empty.

<LastWriteResult> ASCII - Integer Ordinal that indicates the success or failure of the last attempted write. If the tag is associated with an OPC or FTD data server, then the completed set of OPC errors may be received. Refer to the OPC standard for a list of possible return values. If the tag is associated with a DDE data server, then the result is constrained to either an S_OK or E_FAIL status. E_OK = Success E_FAOIL = Failed Additional vendor specific error codes may be returned. It is not possible to know the values of these ordinals in advance. If the tag has not been written to since the FactoryTalk Batch Server startup, this field is empty.

<LastWriteTime stamp>

ASCII - String Time at which the FactoryTalk Batch Server last received the results of a write attempt from the data server. The time is represented as an eight byte float value. The time is represented by a string in the format: "%m/%d/%Y %H:%M:%S". If data is never successfully written, then this field is empty.


Example: A request on object.GetItem(55UnitTagData) could return: NP_MIXER1 \crlf MBR_MIXER_CLS \crlf UNIT_TAG_2 \t OPC_SIM \t \t \t \t \t OPC \t 2 \t \t \t \t 0 \t \t 0 \t \t 0 \t \t 0 \t \t 0 \t \t 0 \t \crlf

See also




The UnitReqIDBindingPreferences item returns the set of binding preferences configured on the specified unit requirement.


Input Format Request: UnitReqIDBindingPreferences

UnitReqID is An ASCII - integer representing the unique ID of a unit requirement. Retrieve this value using the ProcedureIDUnitRequirements data item.

Output Format The UnitReqIDBindingPreferences item returns in this format:

<BindingPreferences> is <NullList> | <BindingPrefList>

<BindingPrefList> is <BindingPref> | <BindingPref> \crlf <BindingPrefList>

<BindingPref> is <BindingPrefType> /t <AssociatedClassName> /t <UnitAttributeName> /t <ExpressionText> /t <ExpressionID>

where:


<BindingPrefType> ASCII - Integer Binding preference type code:

• 1 = Prefer units with this phase class

• 2 = Avoid units with this phase class

• 3 = Prefer units with this unit attribute

• 4 = Avoid units with this unit attribute

• 5 = Prefer units where this Boolean expression is true

• 6 = Prefer units where this expression is maximized

• 7 = Prefer units where this expression is minimized

• 8 = Prefer units with this operation sequence class

• 9 = Avoid units with this operation sequence class

<AssociatedClass Name>

ASCII - String If <BindingPrefType> is equal to: • 1 or 2, name of the phase class.

• 8 or 9, name of the operation sequence class.

If not equal to 1, 2, 8, or 9, this field populates with a space.

<UnitAttribute Name>

ASCII - String If <BindingPrefType> is equal to 3 or 4, name of the unit attribute. If not equal to 3 or 4, this field populates with a space.

<ExpressionText> ASCII - String If <BindingPrefType> is equal to 5, Boolean expression text. If not equal to 5, this field populates with a space.

<ExpressionID> ASCII - Integer If <BindingPrefType> is equal to 6 or 7, unique ID of the expression. If not equal to 6 or 7, this field populates with a space.

UnitReqIDBinding Preferences




Example: A request on object.GetItem(13BindingPreferences) could return: 1\tUNIQUE_TO_MIXER1\t \t \t \crlf 7\t \t \tCAPACITY\t36\r\n 4\t \tMAT_OF_CONSTRUCTION\t \t

See also




The UnitReqIDBindingRequirements item returns the set of binding requirements configured on the specified unit requirement.


Input Format Request: UnitReqIDBindingRequirements

UnitReqID is An ASCII - integer representing the unique ID of a unit requirement. Retrieve this value using the ProcedureIDUnitRequirements data item.

Output Format The UnitReqIDBindingRequirements item returns in this format:

<BindingRequirements> is <NullList> | <BindingReqList>

<BindingReqList> is <BindingReq> | <BindingReq> \crlf <BindingReqList>

<BindingReq> is <BindingReqType> /t <AssociatedClassName> /t <UnitAttributeName> /t <ExpressionText> /t <ExpressionID>

where:


<BindingReqType> ASCII - Integer Binding requirement type code:

• 1 = Phase class inclusion

• 2 = Phase class exclusion

• 3 = Unit attribute inclusion

• 4 = Unit attribute exclusion

• 5 = Boolean expression

• 8 = Operation sequence class inclusion

• 9 = Operation sequence class exclusion

<AssociatedClass Name>

ASCII - String If <BindingPrefType> is equal to: • 1 or 2, name of the phase class.

• 8 or 9, name of the operation sequence class.

If not equal to 1, 2, 8, or 9, this field populates with a space.

<UnitAttribute Name>

ASCII - String If <BindingReqType> is equal to 3 or 4, name of the unit attribute. If not equal to 3 or 4, this field populates with a space.

<ExpressionText> ASCII - String If <BindingReqType> is equal to 5, Boolean expression text. If not equal to 5, this field populates with a space.

<ExpressionID> ASCII - Integer If <BindingReqType> is equal to 5, unique ID of the expression. If not equal to 5, this field populates with a space.

UnitReqIDBinding Requirements




Example: A request on object.GetItem(13BindingRequirements) could return: 5 \t \t \tOUT_OF_SERVICE = "NO"\t45 \crlf 1\tUNIQUE_TO_MIXER1\t \t \t \r\n 3\t \tMAT_OF_CONSTRUCTION\t \t

See also


The UnitsList item returns a list of all units and corresponding equipment IDs and unit classes.


Input Format Request: UnitsList

Output Format The UnitsList item is returned in this format:

<UnitList> is <Unit> \crlf | <Unit> \crlf <UnitList>

<Unit> is <UnitID> \t <UnitName> \t <UnitClass>

where <Unit> is:


<UnitID> ASCII - Integer Unique equipment identifier for a unit.

<UnitName> ASCII - String Unit name.

<UnitClass> ASCII - String Unit class name.


Example: A request on object.GetItem(UnitsList) could return: 3 \tWP_MIXER1 \tMIXER_CLS \crlf 2 \tWP_MIXER2 \tMIXER_CLS \crlf 26 \tSP_MIXER1 \tMIXER_CLS \crlf ... 46 \tMP_MIXERFREEZER2 \tMBR_MIXERFREEZER \crlf

See also


UnitsList



The VerifiedTagCount item returns an integer indicating the total number of verified tags, phases, and equipment operation sequences. This total includes tags, phases, and equipment operation sequences that successfully verified and those that failed verification.


Input Format Request: VerifiedTagCount

Output Format The VerifiedTagCount item is returned in this format: <Count>


<Count> ASCII - Integer Total number of tags, phases, and equipment operation sequences that have been verified, regardless of the outcome of the verification. At the start of a tag verification, the count is set to zero and increments as the verification proceeds.


Example: A request on the object.GetItem(VerifiedTagCount) could return: 156

See also


VerifiedTagCount



The Version item returns the version of the FactoryTalk Batch Server executable (.exe) file.


Input Format Request only: Version

Output Format The Version item returns in this format:

<Version> is <MajorRel>.<MinorRel>.<Compatibility>.<Revision>

where:


<MajorRel> ASCII - Integer Major release number.

<MinorRel> ASCII - Integer Minor release number.

<Compatibility> ASCII - Integer Compatibility identifier shows which releases of executables can communicate. EXE files with the same major release number and the same compatibility identifier can communicate and run together. Changing the compatibility identifier resets the revision number.

<Revision> ASCII - Integer Revision of the release.


Example: A request on object.GetItem(Version) could return: 8.00.00.022

See also


Version



The WarningMessage item returns the most recent warning message in the FactoryTalk Batch Server’s log file.


Input Format Request: WarningMessage

Output Format The WarningMessage item returns in this format: <Time> \t <Description> \t <AdditionalData>

where:


<Time> ASCII - String Time the message generated.

<Description> ASCII – String General message description.

<AdditionalData> ASCII – String More specific message information. May be <NullString> or a blank space character <sp>.


Example: A request on object.GetItem(WarningMessage) could return: 2017.02.24 16:21:12:401 \t PARAMETER DATA SOURCE NOT FOUND \t $LABEL \crlf

See also


WarningMessage


Chapter 3

Execute reference

An Execute commands the FactoryTalk Batch Server to perform some action.

Tip: Use the List Separator and number format for language. Examples used are for English: List Separator: , Number Format: 1,234.56 For Spanish, use a semicolon ( ; ) instead of a comma for the List Separator.

The formatting methods used for each Execute:

Title Description

Execute Format Describes the input format of the Execute statement. IMPORTANT: Do NOT use spaces, unless specifically directed to do so. Use this format: svrobject.Execute strExecute. For Example: svrobject.ACK(Item,STATION5/Operator,1,5)

Action Describes what action is a result of the Execute.

Return Format Describes that data and its format returned by the Execute. All data returns in CFTEXT format, representing either strings or integers.

A list of the key characters and what they symbolize follows:

<TEXT> is Denotes a variable.

<TEXT> is Denotes a variable which will be expanded.

TEXT is Any text that is not enclosed in the < > characters is a keyword and appears as the literal string.

<NullString> is Denotes an empty string, CString.Empty( ), unless otherwise specified.

\t is Denotes a Tab character (ASCII - 9), used as a field delimiter. A space before and after the \t is included for readability. Do NOT include the spaces when formatting the command line.

| is Used to denote an OR situation. Either the text on left of the bar, or the text to the right of the bar used as the output.

\crlf is Denotes a carriage return/line feed character which are used as a record delimiter.

<sp> is Denotes a space character (ASCII – 32).

Chapter 3 Execute reference


Item is The name of the item, as specified by the client. The FactoryTalk Batch Server creates the item. The value stored in the item on the server. The client must Advise on this item and wait for an update. Follow the naming rules listed here:

• Clients should use response item names that are generated to be unique to the client (prepending of node names is common).

• Clients should ensure that they never have 2 or more outstanding EXECUTE instructions with the same response item name.

• Clients should use a fixed set of response item names instead of generating a unique name for each EXECUTE as this will cause a FactoryTalk Batch Server resource leak.

UserID is User identification that will be entered into the event journal associated with this event. For example: Machine Name/UserID.

Example: Defines an example for the EXECUTE statement in this format: Return Format Execute String

Tip: Even though Item is used in examples, follow the naming rules.

See also

Ack on page 219

Acquire on page 220

AddEvent on page 221

AddEvent_CI on page 223

AddEvent_Instruction on page 224

Execute reference Chapter 3


The ACK execute acknowledges an entry in the unacknowledged prompts list.

The following table shows the format and return for this execute.

Execute Format A FactoryTalk Batch Server supports an execute with this format: [ACK(Item,UserID,EventID,EventResponse)]

where: Item The item name, as specified by the client.

UserID User identification entered into the event journal associated with this event.

EventID The unique batch-generated ID for the event.

EventResponse The response to the unacknowledged event: <PromptResponse>

where:

<PromptResponse> is <StandardPromptResponse> | <UnitBindingPromptResponse> | <RecipePhaseBindingResponse >

<StandardPromptResponse> is <ParameterValue>

<UnitBindingPromptResponse> is <UnitID>

<RecipePhaseBindingResponse> is <EqModName> - <ContainerName> - <Capacity> - <EU> - <LotName> - <LabelName>

where:

Field Format Description

<ParameterValue> ASCII - String Value stored into the parameter for the generated unacknowledged prompt.

<UnitID> ASCII – Integer Unit resource ID that binds to the Unit Requirement generated by the bind prompt.

<EqModeName> ASCII – String Equipment phase name that binds to the recipe phase generated by the bind prompt.

<ContainerName> ASCII - String Container name that binds to the recipe phase generated by the bind prompt.

<Capacity> ASCII – Integer Container capacity that binds to the recipe phase generated by the bind prompt.

<EU> ASCII – String <Capacity> value engineering units for the container that binds to the recipe phase generated by the bind prompt.

<LotName> ASCII – String Lot name bound to the recipe phase generated by the bind prompt.

<LabelName> ASCII – String Label name bound to the recipe phase generated by the bind prompt.

Action A successful ACK execute either responds to the specified prompt ID, or queue the response to the prompt ID pending one or more signatures that may have been generated for confirming the prompt response.

Return Format The item populates with this data: SUCCESS: | SUCCESS:<ActionID> | FAIL:<message> | FAILED

where:

Ack




<ActionID> ASCII – Integer Action ID associated with signature(s) generates as a result of the potential prompt response. The prompt response is not processed unless all signature requests are successfully signed off.

<message> ASCII - String Error message appropriately formatted for operator display.

The following table shows an example of the return on this execute.

Example: An execute string consisting of: Ack(Item,Station2/View,2,EP_ADDEGG_M1-COOLER\EGG_PALLET2 –50-KG-GOLDEN_EGGS_SEPT_18-CARTON_9)

Could return: SUCCESS:997

See also


The ACQUIRE execute acquires a resource for the operator.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [ACQUIRE(Item,UserID,OwnerID,ResourceID)]

where: Item Item name as specified by the client.

UserID User identification associated with this event.

OwnerID Identification of the operator.

ResourceID Equipment ID of the resource to be acquired. Configure this value in FactoryTalk Batch Equipment Editor.

Action A successful ACQUIRE execute places operator into the requester’s specified resource list. When the resource determines that the operator can become an owner, then operator moves into the owner’s resource list.

Return Format The item populates with this data: SUCCESS: | FAIL:<message> | FAILED


Example: An execute string: [ACQUIRE(Item,Station5\Operator,0,119)]

See also


Acquire



The ADDEVENT execute allows an external application to append an event in one or all active FactoryTalk Batch electronic batch record files based on the BatchID.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [ADDEVENT(Item,UserID,BatchID,Type,Desc,Value,EU,Cell,Unit,Phase)]

where:

Item Item name as specified by the client.

UserID User ID entered into the event journal with this event.

BatchID Operator entered batch identification. Use ‘*’ to place the event information into all open electronic batch records.

Type Type of event being added.

Desc Description of the event being added.

Value Value of the event being added.

EU (optional) Engineering units associated with the event.

Cell (optional) Process cell which is associated with the event.

Unit (optional) Unit which is associated with the event.

Phase (optional) Phase associated with the event.

Action A successful ADDEVENT execute places the event into the specified electronic batch record(s). The FactoryTalk Batch Server automatically completes these fields: TIME, AREA, RECIPE, PHASE_DESC, and UNIQUE_ID. If, however, the event is targeted at a single batch, and the batch product is configured for signature confirmation of "comments", then the addition of the event record to the event journal is queued pending a successful signature request signoff.

Return Format The item populates with this data: SUCCESS: | SUCCESS:<ActionID> | FAIL:<message>

where:


<ActionID> ASCII – Integer Action ID associated with signature(s) generated as a result of the potential prompt response. The prompt response is not actually processed unless all signature requests are successfully signed off.


AddEvent




Example: An execute string consisting of: [ADDEVENT(Item,Station5\Operator,Batch_100,Comment,OperatorComment,This is a comment)]


See also




The ADDEVENT_CI execute allows an external application to append an event in a FactoryTalk Batch electronic batch record file based on its unique CreateID.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [ADDEVENT_CI(Item,UserID,CreateID,Type,Desc,Value,EU,Cell,Unit,Phase)]

where: Item Response item name as specified by the client.


CreateID Unique batch ID assigned by the FactoryTalk Batch Server.





Cell (optional) Process cell associated with the event.

Unit (optional) Unit associated with the event.

Phase (optional) Phase associated with the event.

Action A successful ADDEVENT_CI execute places the event into the specified electronic batch record. The FactoryTalk Batch Server automatically completes these fields: TIME, AREA, RECIPE, PHASE_DESC, and UNIQUE_ID. If, however, the batch product is configured for signature confirmation of "comments", then adding the event record to the event journal is queued pending successful signoff of a signature request.


where:


<ActionID> ASCII – Integer Action ID associated with signature(s) generated as a result of the potential prompt response. The prompt response will not actually be processed unless all signature requests are successfully signed off.



Example: An execute string: [ADDEVENT_CI(Item,Station5\Operator,11,Comment,OperatorComment,This is a comment]

See also


AddEvent_CI



The ADDEVENT_INSTRUCTION execute allows an external application to append an event associated with an eProcedure control step in an electronic batch record using the name of the equipment phase that is currently executing, the control step index, and the control step reactivation number.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [ADDEVENT_INSTRUCTION(Item,UserID,Phase,Type,Desc,StepIndex,ReactivationNumber,InstructionHTML)]



Phase Phase associated with this event.



StepIndex Step index of the control step associated with this event. This field’s value writes to the PVALUE field in the event journal.

Reactivation Number

Control step reactivation number associated with this event.

InstructionHTML (optional) HTML for the instruction step.

Action A successful ADDEVENT_INSTRUCTION execute places the event into the specified electronic batch record(s). The FactoryTalk Batch Server automatically completes these fields: TIME, AREA, RECIPE, PHASE_DESC, and UNIQUE_ID. If, however, the event targets a single batch, and the batch product is configured for signature confirmation of "comments", then adding the event record to the event journal is queued pending a successful signature request signoff.

Return Format The item populates with this data: SUCCESS| FAIL:<message>| FAILED


Example: An execute string: [ADDEVENT_INSTRUCTION(Item,Earl\ADD_SUGAR,Instruction Complete,Step Completed,1,0,<FORM>Open the big green valve</FORM>]

See also


AddEvent_Instruction



The ADDEVENT_PHASE execute allows an external application to append an event in a FactoryTalk Batch electronic batch record file using a phase name that is currently executing. Unlike other AddEvent executes, the complete recipe path is automatically entered into the electronic batch record.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [ADDEVENT_PHASE (Item, UserID, Phase, Type, Desc, Value, EU)]



Phase Phase associated with this event.





Action A successful ADDEVENT_PHASE execute places the event into the specified electronic batch record associated with the batch using the specified phase (equipment phase). The FactoryTalk Batch Server automatically completes these fields: TIME, AREA, RECIPE, PHASE_DESC, PHASE, PROCCELL, UNIT, and UNIQUE_ID. If the batch product is configured for signature confirmation of comments, then adding the event record to the event journal is queued pending a successful signature request signoff.

Return Format SUCCESS: | SUCCESS:<ActionID> | FAIL:<message>

where:


<ActionID> ASCII – Integer Action ID associated with signature(s) generates as a result of the potential prompt response. The prompt response is not processed unless all signature requests are successfully signed off.



Example: An execute string consisting of: [ADDEVENT_PHASE(Item,Station5\Operator,NP_ADDDAIRY_M1,Comment,OperatorComment,This is a comment)]


See also


AddEvent_Phase



The ARCHIVER execute allows an external application to start the FactoryTalk Event Archiver.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [ARCHIVER (Item,UserID,INI,Queue)]



INI INI file pathname used with FactoryTalk Event Archiver. The default is C:\Program Files\Rockwell\Software\Batch \bin\batcharc.ini.

Queue Pathname to the queue file used with FactoryTalk Event Archiver.

Action A successful ARCHIVER execute initiates FactoryTalk Event Archiver.

Return Format There is no data returned to the item.


Example: An execute string: [ARCHIVER(Item,UserID, C:\Program Files\Rockwell Software\Batch\bin\ batcharc.ini, C:\Program Files\Rockwell Software\Batch\SampleApp\journals\archque.txt)]

See also


Archiver



The AUTOBATCHID_INFO execute returns the batch ID from a call to BatchIDCreation.


Execute Format AUTOBATCHID_INFO(Item, UserID, RecipeName)

where: Item Item name on which to place the execute.

UserID Computer name or user name performing the given execute as well as the user ID who issued the given execute.

Recipe Name String representing the recipe file name without an extension.

Action A successful AUTOBATCHID_INFO execute causes the <BatchIDInfo> value, as defined in the CreateBatchID.dll, to return.

Return Format The item populates with this data: SUCCESS:<BatchIDInfo>$END|FAIL:<Message>$BATCHID:<Default-BatchID>

where:


<BatchID> ASCII Value generated by a custom batch ID implementation; or, if no customization is applied, the default batch ID as defined in the batchsvr.ini file.

<Message> ASCII Custom or generic message specifying the context of an error.

Tip: FAIL: can indicate that an error took place at the boundary between the FactoryTalk Batch Server and BatchIDCreation application (COM failure), or that a failure generates from within the BatchIDCreation code implementation (custom generated error or internal failure). In either case, following the FAIL: identifier is the message specifying the textual context of the error and the default batch ID, as configured in the Equipment Editor Server Options dialog box.

AutoBatchID_Info




Example: An execute string: AUTOBATCHID_INFO (s, dev_bjwallwi01/bjwallwi, MCLS_FRENCHVANILLA)

Example: Output: SUCCESS:FRENCH_VANILLA_012790$END

OR FAIL:DivideByZero$BATCHID:DefaultBatchID

See also




The AUTOREMOVE execute tells the server to automatically remove a batch when its state reaches complete or cancels a previous AUTOREMOVE execute.


Execute Format A FactoryTalk Batch Server supports an execute string with the AUTOREMOVE keyword. The format of the execute string: [AUTOREMOVE(ResponseItem, UserID, CreateID, AutoRemove)]

where: ResponseItem Name of the response item.


CreateID Create ID of the batch to automatically remove.

AutoRemove ON to automatically remove the batch; OFF to allow the batch to stay on the batch list.

Action A successful AUTOREMOVE (... ON) execute causes the FactoryTalk Batch Server to remove the batch when its state reaches COMPLETE. A successful AUTOREMOVE (... OFF) execute does not allow the server to remove the batch without a REMOVE execute.

Return Format SUCCESS: | FAIL: <message>

Tip: When Electronic Signatures are enabled and a Remove Command Verification Policy is configured in the area model, then all AUTOREMOVE executes sent to the FactoryTalk Batch Server fail and an appropriate error message displays.


Example: An execute string: [AUTOREMOVE(Item_1,operator,17,on)]

See also


AutoRemove



The BATCH execute creates a control recipe and adds an entry in the batch list.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [BATCH(<Item>,<UserID>,<RecipeID>,<BatchID>,<Scale>,<Description>,<StepList>PARMS, <ParmList><Mtrl_InfoList>)]

where: <Item> Item name as specified by the client.

<UserID> User identification associated with this event.

<RecipeID> File name, including extension, for the recipe to be used.

<BatchID> Operator-entered batch identification. The BatchID can be comprised of any character except: The defined list separator, single or double quotes, brackets, parentheses, the percent sign (%), the tab character (\t), the carriage return character (\r), or the new line character (\n).

<Scale> Scale factor in percent.

<Description> Description of the recipe.

<StepList> List of steps and their associated units.

<ParmList> List of parameters and their associated values. PARMS must be included in the statement even if there are no parameters required.

<Mtrl_ InfoList>

Optional list of Phase Material Records that begins with $MTRL_INFO and ends with $END.

where: <StepList> is <NullList> | <StepPair><StepList>

<StepPair> is <Step>,<Unit>,

<Step> Path to a step that must be bound to a unit alias or a step

<Unit> Unit to which the step is bound: • > 0 value indicates the Unit ID

• 0, -1, or < -2 value indicates the Operator Prompt binding type.

• -2 value indicates the First Available binding type.

where: <ParmList> is <NullList> | <ParmPair><ParmList>

<ParmPair> is <ParmName>,<Value>,

<ParmName> Parameter name required by the recipe. Must be all upper case.

<Value> Value associated with the parameter.

where:

<Mtrl_InfoList> is <NullList> | $MTRLINFO,<PhaseMaterialList>,$END

<PhaseMaterialList> is <PhaseMaterialRecord>|<PhaseMaterialRecord>, <PhaseMaterialList>

<PhaseMaterialRecord> is <PhasePathName>,<MaterialName>

Batch



<PhasePathName> Full recipe pathname to the phase.

<MaterialName> Name of a material configured in the Material Server.

Action A successful BATCH execute creates a control recipe from the specified master recipe. If the recipe was based upon one or more unit classes and "At Batch Creation" binding was specified, then the recipe will be "bound" to the specified units or binding will be deferred to later, as specified in the execute. If the recipe required one or more parameter values, then the values that were entered will be inserted into the control recipe. The PARMS statement must not include any spaces.

Return Format The item populates with this data: SUCCESS:<CreateID> | FAIL:<message> | FAILED where: <CreateID> specifies the Unique CreateID of the control recipe, and <message> specifies why the FactoryTalk Batch Server could not create a control recipe.

The following table shows an example of the return on this execute for a material-based recipe.

Example: An execute string: [BATCH(Item,STATION5/operator2,MCLS_FRENCHVANILLA.BPC,BATCH_100,100,French Vanilla Premium - class based/material based,MIXER,84,FREEZER,85,PARMS,CREAM_AMOUNT,2001,EGG_AMOUNT,230,FLAVOR_AMOUNT,20,MILK_AMOUNT,1999,SUGAR_AMOUNT,750)]

The following table shows an example of the return on this execute for a class-based recipe.

Example: An execute string: [BATCH(Item,STATION5/operator2,CLS_FRENCHVANILLA.BPC,BATCH_ID,100,FRENCH VANILLA PREMIUM - CLASS BASED,FREEZER,4,MIXER,3,PARMS, CREAM_AMOUNT,2001,EGG_AMOUNT,200,FLAVOR_AMOUNT,50,MILK_AMOUNT,1999,SUGAR_AMOUNT, 750)]



The following table shows an example of the return on this execute for a material class-based recipe.

Example: An execute string: [BATCH( Item, STATION5/operator2, VANILLA_ICE_CREAM.BPC, BATCH_100,100,French Vanilla Premium - class based/material based, MIXER, 84, FREEZER, 85, PARMS, CREAM_AMOUNT, 2001, EGG_AMOUNT, 230, FLAVOR_AMOUNT, 20,MILK_AMOUNT, 1999, SUGAR_AMOUNT, 750, $MTRL_INFO, PROC_1\UNITPROC_1:1\OPER_1:3\ADD:4, MILK, PROC_1\UNITPROC_1:1\OPER_2:1\ADD:1, SUGAR, $END )]

See also




The BIND execute binds and unbinds a unit procedure or operation to or from a specified unit.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [BIND(<Item>, <UserID>, <ProcedureID>, <UnitID>)]

where: <Item > Item name on which to place the response.

<UserID> User ID who issued the execute is entered into the event journal associated with this event.

<ProcedureID> Recipe procedure path being bound to the specified unit: <FullPath>

<UnitID> Unit Resource ID binds to the step. If the recipe is a procedure, use: • -1 to unbind and change to PROMPT (for prompted binding)

• -2 to unbind and change to FIRST_AVAIL (for first available unit)

Prompt (-1) and First_Available (-2) are not valid options for a unit procedure recipe.

where:

<FullPath> is <CreateID> | <CreateID> /t <Path>

<Path> is <StepIdentifier> | <StepIdentifier> /t <Path>

where:



<StepIdentifier> ASCII – String Step identifier (for example, Mix:1)

Action A successful BIND execute results in the specified unit binding to the specified procedure or in the queuing of the bind request pending a signature.


where:


<ActionID> ASCII – Integer Action ID associated with signature(s) generates as a result of the bind request. The bind request will not process unless all signature requests are successfully signed off.


Bind




Example: An execute string for a procedure recipe example: Bind(Item,Station2/View,34 /t sweetcream_up:1,55)

An execute string for a unit procedure recipe example: [BIND(Item,UserID,35,55)]

Either could return: SUCCESS:997

See also


The BINDPHASE execute binds and unbinds a material-enabled phase to or from a specified container and phase. The BINDPHASE execute does not check for valid Phase, Container, Lot, or Label. Ensure that the binding information provided to the FactoryTalk Batch Server is accurate. The phase must not be active for the execute to be processed.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [BINDPHASE(Item,UserID,PhasePath,ContainerName,EqModuleID, Lot,Label)] The unbind requires: [BINDPHASE(Item,UserID,PhasePath, <sp>,PROMPT or AUTOMATIC,<sp>,<sp>)]


UserID User Identification entered into the event journal associated with this event.

PhasePath Recipe phase path to be bound: <FullPath> Hierarchical phase paths: Procedure Level: CreateID \t UnitProcName \t OperName \t PhaseName Unit Procedure Level: CreateID \t OperName \t PhaseName Operation Level: CreateID \t PhaseName

ContainerName Name of the container to be selected for binding. Can be a space character <sp>.

EqModuleID New bind target for the recipe phase: <BindTarget>

Lot Lot name to further specify the container for binding. Can be a space character <sp> or blank to match any lot.

Label Label name to further specify the container for binding. Can be a space character <sp> or blank to match any label.

where: <BindPath> is <ResourceID> | <Prompt> | <Automatic>

where:


<ResourceID> ASCII - Integer Equipment phase resource ID to which the recipe phase is binding.

BindPhase



<Prompt> ASCII – String String literal PROMPT. This indicates that the specified recipe phase is to be unbound and replaced with a prompt based binding mechanism.

<Automatic> ASCII – String String literal AUTOMATIC. This indicates that the specified recipe phase is to be unbound and replaced with a first-available based binding mechanism.

Action A successful BINDPHASE execute results in the binding and unbinding of the specified recipe phase, or in the queuing of the bind request pending a signature.


where:


<ActionID> ASCII – Integer Action ID associated with signature(s) generates as a result of the bind request. The bind request is not processed unless all signature requests are successfully signed off.



Example: An execute string for binding: BINDPHASE(Item,STATION5/Operator,34 \t MCLS_SWEETCREAM _UP:1,TEMP_EGG,NP_ADDEGG_M1,,)

An execute string for unbinding: BINDPHASE(Item,STATION5/Operator,34 \t MCLS_SWEETCREAM _UP:1, ,PROMPT,,) or BindPhase(Item,Station2/View,34 /t SWEETCREAM_UP:1 /t WHIPIT_OP:1 /t DOSE:1, TANK1, 23, LOT_A, LABEL_GOODSTUFF)


See also




The CANCELSIGNATURE execute allows a client to cancel a signature request on an incomplete signature, excluding those that were generated by private interfaces.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [CANCELSIGNATURE(Item, UserID, SignatureID)]

where:


Item ASCII - String Name of the response item, as specified by the client.

UserID ASCII - String User Identification entered into the event journal associated with this event.

SignatureID ASCII - Integer Unique ID of the signature to be cancelled.

Action A successful CANCELSIGNATURE request cancels the specified signature if it is in the incomplete state and not generated by a private interface.

Return Format The response item populates with this data: SUCCESS: | FAIL:<message>

where:




Example: An execute string consisting of: CancelSignature(Item,Station2/View,993)

Could return: SUCCESS:

See also


CancelSignature



The COMMAND execute commands a procedure to a desired state or mode.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [COMMAND(Item,UserID,ProcedureID,Cmd)]



ProcedureID Unique hierarchical path name to the procedure, unit procedure, operation or phase: Procedure: CreateID Unit Procedure: CreateID \t UnitProcIDName Operation: CreateID \t UnitProcIDName \t OperIDName Phase: CreateID \t UnitProcIDName \t OperIDName \t PhaseIDName

Cmd Command either to change the state or mode. Commands which may be issued are: • STARTSTOPAUTO-MODE

• PAUSEHOLDRESTART

• MAN-MODERESUMEABORT

• RESETDOWNLOADCLEAR_FAILURES

• DISCONNECTSEMIAUTO-MODE

• TIMER-CompleteTIMER-Reset

The command must be valid for the procedure level being commanded.

where: <FullPath> is <CreateID> | <CreateID> /t <Path>


where:




Action A successful COMMAND execute results in either the command being issued to the specified procedure element, or in the command being queued pending completion of the confirmation signature. A COMMAND execute results in a failure message when the Command sent is equal to the current batch state. Example: If a batch is running and a START or RESTART execute is issued, the command will return a failure message.


where:


<ActionID> ASCII – Integer Action ID associated with the signature(s) generated in response to the execute.

Command





Example: An execute string consisting of: COMMAND(Item,Station2/View,36,START)


See also




The CONTROLSTRATEGY execute returns a list of control strategies configured for the specified phase.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [CONTROLSTRATEGY(Item,UserID,PhaseID)]



PhaseID Equipment ID for the phase as configured in FactoryTalk Batch Equipment Editor.

Action A successful CONTROLSTRATEGY execute results in a list of control strategies configured for the specified phase.

Return Format The item populates with this data:

<ControlStrategyResponse> is SUCCESS:<sp><ControlStrategyData> | FAIL:<message> | FAILED

<ControlStrategyData> is <NullList> \crlf | <ControlStrategyList>

<ControlStrategyList> is <ControlStrategy> \crlf | <ControlStrategy> \crlf <ControlStrategyList>

<ControlStrategy> is <CStrategyID> \t <CStrategyName>


<CStrategyID> ASCII - Integer ID assigned to the control strategy.

<CStrategyName> ASCII - String Name assigned to the control strategy.


Example: An execute string: [CONTROLSTRATEGY(Item,UserID,68)]

See also


ControlStrategy



The ENUM execute obtains the enumerations from a specified enumeration set, as defined in FactoryTalk Batch Equipment Editor.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [ENUM(Item,UserID,Enumset)]



Enumset Enumeration set name as defined in the Equipment database.

Action A successful ENUM execute places the enumerations into the response item.


<Enums> is <EnumList> \crlf | Cstring.Empty() \crlf | FAIL:<message> | FAILED CString.Empty() is returned for Enumeration Sets that have no enumerations defined.

<EnumList> is <EnumString> | <EnumString> \t <EnumList>

<EnumString> is Enumeration string that belongs to the specified enumeration set.


Example: An execute string consisting of: [ENUM(Station5Enums,Station5\Operator,MATERIALS)]

Could place this data in the item Station5Enums for the client: WATER \t FUDGE \t DARK_CHOCOLATE \t STRAWBERRYWHITE_CHOCOLATE \t RASPBERRY \t IC_GERMAN_CHOCOLATE \t PECAN \t EGG_YOLK \t GOOD_EGG \t IC_TRIPLE_CHOCOLATE \t COCOA \t STRAWBERRY_IM \t SUGAR_GRANULATED \t CHAMBORD \t VANILLANEW \t MILK \t VANILLA \t NULL_MATERIAL \t C_CHOCOLATE_BLK_RBERRY_WC \t CARAMEL \t CREAM \t IC_FRENCH_VANILLA \t COCONUT \crlf

See also


Enum



The EXPRESSION execute obtains the transition data from the server.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [EXPRESSION(Item,UserID,TransitionID)]



TransitionID Element number for the transition.

Action A successful EXPRESSION execute places the transition data into the response item.


<ExpData> is <ExpList> | FAIL:<message> | FAILED

<ExpList> is <Expression> \crlf | <Expression> \crlf <ExpList>

<Expression> is <Level> \t <EvalEnum> \t <LhsExp> \t <Op1> \t <RhsExp> \t <LhsVal> \t <RhsVal>

<ExpList> List of transition expressions for a specified level.

<failure_ message>

Explanation of why the EXPRESSION command failed to process.

where <Expression> is:

<Level> Expressions can contain sub-expressions. The expression treated as a whole is Level 0. Each sub-expression of Level 0 is marked as being Level 1. These sub-expressions are the left hand expression and the right hand expressions (described below) of Level 0. The left and right hand expressions are broken down, level by level, until simple terms are left and the values of those terms are displayed.

<EvalEnum> Evaluation enumeration (for coloring expressions) 0 = FALSE - red 1 = TRUE - green 2 = INFO - black

<LhsExp> Left hand side expression.

<Op1> Operator between left and right.

<RhsExp> Right hand side expression.

<LhsVal> Left hand side value.

<RhsVal> Right hand side value.

Expression




Example: An execute string consisting of: [EXPRESSION(PC2Exps,UserID,641)]

Could place this data in the item PC2Exps for the client: 0 \t 0 \t MCLS_FRENCHVANILLA_UP:1.STATE \t = \t COMPLETE \t RUNNING \t COMPLETE \crlf

See also




The ForceTransition execute allows the operator to force a transition to fire when the only thing preventing it from firing is a TRUE evaluation of its transition expression. The ForceTransition action is a transient and will either succeed immediately or have no effect on the targeted transition object. For example, if a ForceTransition execute targets at a transition that is not in a valid state to fire because not all the preceding steps are active, the ForceTransition execute fails and is not remembered when all preceding steps become active chart elements.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [ForceTransition(Item, UserID, TransitionID)]

where: Item Name of the response item as specified by the client.


TransitionID Unique ID, as assigned by the system, of the transition targeted by the override. The transition ID is typically retrieved by a client application using the ProcedureIDData3 data item.

Action A successful ForceTransition execute causes a transition to fire when it is being prevented from firing by not having a TRUE evaluation of its transition expression.


where:


<message> ASCII-String Error message appropriately formatted for operator display.


Example: An execute string consisting of: ForceTransition(Item,Station2/View,89)


See also


ForceTransistion



The GETCONTAINERDATA execute retrieves a list of container and lot data entries that specify container binding options for the phase to be run using manual phase control.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [GETCONTAINERDATA(Item,UserID,UnitID,EqModID, FeedType, MaterialName)]



UnitID Unit Resource ID containing the phase to be run.

EqModID Resource ID for the phase to be run.

FeedType Type of feed the phase will be performing. This is the literal value "ADDITION" or "DISTRIBUTION".

MaterialName Name of the material that the step adds or distributes.

Action A successful GETCONTAINERDATA execute returns a list of container and lot entries that may be legally bound to.

Return Format The item populates with this data: SUCCESS:<ContainerData> | FAIL:<message>

where:

<ContainerData> is <NullList>|<ContainerList>

<ContainerList> is <BindEntry>|<BindEntry><ContainerList>

<BindEntry> is <ContainerName> \t <ContainerControllerID> \t <Capacity> \t <CEU> \t <LotName> \t <Label>\t

where:


<ContainerName> ASCII Container name.

<ContainerControllerID> ASCII ID for the container.

<Capacity> ASCII For an addition, this is the quantity of material in the container. For a distribution, this is the remaining (available) volume of the container.

<CEU> ASCII Engineering units used to measure a container’s volume.

<LotName> ASCII Name of the lot.

<LabelName> ASCII Label assigned the quantity of material.

GetContainerData




Example: An execute string: GETCONTAINERDATA(DATA,STATION5/ Operator,55,70,ADDITION,EGG_YOLK)

Requesting data from DATA returns: SUCCESS:TEMP_EGG \t 27 \t 660916 \t KG \t EGG_LOT3 \t EGGS3 \crlf

See also




The GETFEEDTYPEANDMATERIALS execute retrieves a feed types and materials list supported by a phase run under manual phase control.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [GETFEEDTYPEANDMATERIALS(Item,UserID,EquipmentModuleName)]



Equipment ModuleName

Name of the phase to retrieve the information from.

Action A successful GETFEEDTYPEANDMATERIALS execute returns a feed types and materials list supported by the current phase.

Return Format The item populates with this data: SUCCESS:<FeedTypeID>\crlf <MaterialsEnmList> | FAIL:<message>

where:


<FeedTypeID> ASCII-Integer 1 = Addition 2 = Distribution 3 = Addition and Distribution

<MaterialsEnmList> is MaterialName \t | MaterialName \t <MaterialsEnmList>

where:


MaterialName ASCII-String Name of the material.

GetFeedTypeAndMaterials




Example: An execute string consisting of: GETFEEDTYPEANDMATERIALS(Item,STATION5/ Operator,NP_ADDEGG_M1)

Requesting data from Item could return: SUCCESS:1 \crlf CARAMEL \t CHAMBORD \t COCOA \t COCONUT \t COLD_STUFF \t CREAM \t DARK_CHOCOLATE \t EGG_YOLK \t FUDGE \t GOOD_EGG \t IC_CHOCOLATE_BLK_RBERRY_WC \t IC_FRENCH_VANILLA \t IC_GERMAN_CHOCOLATE \t IC_STRAWBERRY_IM \t IC_TRIPLE_CHOCOLATE \t MILK \t NULL_MATERIAL \t PECAN \t RASPBERRY \t SAM_STUFF \t STRAWBERRY \t SUGAR_GRANULATED \t TEST \t VANILLA \t VANILLANEW \t WATER \t WHITE_CHOCOLATE \t

See also




The GETLEGALEQMODULES execute retrieves a list of phase-container-lot entries to be considered for manually binding or rebinding a phase step.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [GETLEGALEQMODULES(Item,UserID,PhaseName)]



PhaseName Unique hierarchical path name to the phase: Procedure Level: CreateID \t ProcedureName \t UnitProcName \t OperName \t PhaseName Unit Procedure Level: CreateID \t UnitProcName \t OperName \t PhaseName Operation Level: CreateID \t OperName \t PhaseName

Action A successful GETLEGALEQMODULES execute returns the alias name along with a list of names of the legal binding phase-container-lot entries for a phase step’s manual binding or rebinding.

Return Format The item populates with this data: SUCCESS:[<StepData>, <EqModuleList>,<UseAutoBind>] | FAIL:<message>

where:

<StepData> is <Material>,<Amount>,<MaterialEU>,<FeedType>

<EqModuleList> is <EqModule> | <EqModule>,<EqModuleList>

<EqModule> is <EqModuleName>, <ContainerName>, <Capacity>, <ContainerEU>, <LotName>, <Label>

<UseAutoBind> is "AUTOMATIC,,0,,,,PROMPT,,0,,,,"

where:


<Material> ASCII-String Material name from the phase’s MATERIAL parameter.

<UseAutoBind> ASCII-String Data passed to client applications permitting the operator to manually instruct the phase to use Automatic Phase Binding.

<Amount> ASCII-Integer Material quantity to process from the phase’s AMOUNT parameter. This value is positive for a material addition and negative for a material distribution.

<MaterialEU> ASCII-String Engineering units for measuring the quantities of material.

<FeedType> ASCII-String String "ADD" or "DUMP"

<EqModuleName> ASCII-String Phase name that could be selected for binding.

<ContainerName> ASCII-String Container name that could be selected for binding.

<Capacity> ASCII-String Material Addition: Material quantity available in the container. Material Distribution: Remaining storage capacity in a container.

<ContainerEU> ASCII-String Engineering units for measuring a container’s volume.

GetLegalEqModules



<LotName> Name of the lot assigned to a specific material sublot in a container (if defined or known) - could be blank.

<Label> String label assigned to a sublot (if defined or known) - could be blank.


Example: An execute string consisting of: GETLEGALEQMODULES(Item, Station5\Operator,42 \t MCLS_SWEETCREAM_UP:1 \t MCLS_SWEETCREAM_OP:1 \t MBR_ADD:2)

Requesting data from Item could return: SUCCESS:EGG_YOLK,750,KG,ADD,NP_ADDSWEET_M1,SUGAR_SHACK1,66625366,KG,SUGARCANELOT3, ,AUTOMATIC, ,0, , , ,PROMPT, ,0, , , ,

See also




The GETLEGALUNITS execute retrieves the legal binding options for a non-statically bound unit procedure or operation.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [GETLEGALUNITS(Item,UserID,CreateID \t UnitProcName)]



CreateID Procedure’s unique ID, as assigned by the system, which contains the step that requires binding.

UnitProcName Path to a step representing a Unit Procedure inside of a Batch Procedure. <Path>

where:

<Path> is <CreateID>/t <StepIdentifier>

where:




Action A successful GETLEGALUNITS execute returns the alias name along with a list of IDs and legal binding unit names or binding options for the specified unit procedure or operation.

Return Format The item populates with this data: SUCCESS:[<Units>] | FAIL:<message> | FAILED

<Units> is <UnitAlias>,<UnitList>

<UnitList> is <Unit> | <Unit>,<UnitList>

<Unit> is <UnitName>,<UnitID>

where:


<UnitAlias> ASCII - String Alias associated with the specified unit procedure.

<UnitName> ASCII - String Unit name to which the procedure may be bound, or a legal binding option (Prompt or First Available).

<UnitID> ASCII - String Unit ID associated with the unit name. The legal binding options have this associated Unit ID: Prompt = -1 First Available = -2

GetLegalUnits




Example: An execute string consisting of: GETLEGALUNITS(LegalUnits,UserID,36 \t MCLS_SWEETCREAM_UP:1)

Could place this data in the item LegalUnits for the client: SUCCESS:MIXER,NP_MIXER1,55,NP_MIXER2,84,PROMPT,-1,FIRST AVAILABLE,-2,

See also


The GETPOSSIBLELEGALUNITS execute retrieves the possible binding options for a non-statically bound unit procedure or operation.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [GETPOSSIBLELEGALUNITS(Item, UserID,CreateID \t UnitProcName)]



CreateID Unique ID, as assigned by the system, of the procedure which contains the step which requires binding

UnitProcName Path to a step representing a Unit Procedure inside of a Batch Procedure. <Path>

where:

<Path> is <CreateID>/t <StepIdentifier>

where:




Action A successful GETPOSSIBLELEGALUNITS execute returns the alias name along with a list of IDs and names of the possible binding units or binding options for the specified Unit Procedure or Operation.

Return Format The response item populates with this data: SUCCESS:[<Units>] | FAIL:<message> | FAILED

<Units> is <UnitAlias>,<UnitList>

<UnitList> is <Unit> | <Unit>,<UnitList>

<Unit> is <UnitName>,<UnitID>

where:

GetPossibleLegalUnits




<UnitAlias> ASCII - String Alias associated with the specified Unit Procedure.

<UnitName> ASCII - String Name of a Unit that can be a legal bind target for the Unit Procedure, or a legal binding option (Prompt or First Available)

<UnitID> ASCII - String Unit ID associated with the unit name. The legal binding options have this associated Unit ID: • Prompt = -1

• First Available = -2


Example: An execute string consisting of: GETPOSSIBLELEGALUNITS(Item,Station2/View,36 \t ADDCREAM_UP:1)

Could return: SUCCESS:MIXER,NP_MIXER1,55,NP_MIXER2,84,PROMPT,-1,FIRST AVAILABLE,-2

See also




The INFO execute obtains information about a recipe.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [INFO(<Item>,<UserID>,<RecipeID><PhaseMaterialData>)]



RecipeID File name of the recipe.

<PhaseMaterial Data>

Optional list of Phase-Material pair data.

where:

<PhaseMaterialList> is <PhaseMaterialRecord >| <PhaseMaterialRecord >,<PhaseMaterialList>

<PhaseMaterialRecord> is <PhasePathname>,<MaterialName>

where:

<Phase Pathname> Full recipe pathname to the phase. (for example, PROC_1\UNITPROC_1:1\OPER_1:3\ADD:4)

<Material Name> Name of a material configured in the Material Server (for example, MILK).

Action A successful INFO execute places the recipe information into the item field.

Return Format The item populates with this data: <RecList> \crlf

where:

<RecList> is <StepList> PARMS \crlf <ParmList>

<StepList> is <Step> | <Step> <StepList>

<Step> is <Alias>\t<BindData>\t<BindFlag> \crlf

<BindData> is <Class> | <UnitBindList>

<UnitBindList> is $UNITLIST\t<UnitList>\t$END

<UnitList> is <UnitName> | <UniName>\t<UnitList>

<ParmList> is <ParmInfo> | <ParmInfo> <ParmList>

<ParmInfo> is <Parameter>\t<ResponseType>\t<ParmEdit> \t<EngUnits>\t<MaxValue>\t<MinValue>\t<Default> \crlf

where:

Info




PARMS ASCII - String Keyword to separate the steps from the parameters in the return result.

<Alias> ASCII - String Unit alias which requires binding.

<BindFlag> ASCII - Integer Integer value containing bits indicating what types of late binding are permitted: Bit1 = PROMPT Bit2 = FIRST AVAILABLE

<Class> ASCII - String Unit Class the previous step was configured to use.

$UNITLIST ASCII-String Indicates the beginning of the unit names list that contains references to material-based phases.

$END ASCII-String Indicates the end of the unit names list that contains references to material-based phases.

<UnitName> ASCII-String Name of the unit.

<Parameter> ASCII - String Parameter name required to create the batch.

<Response Type> ASCII - Integer Data type for the response: • 1 = real

• 2 = long

• 3 = string

• 5 = enumeration.

<ParmEdit> ASCII - Integer 1 = obsolete field used to mark parameters as having values that could be edited or not. It always returns the value "1".

<EngUnits> ASCII - String Engineering units for the parameter.

<MaxValue> ASCII - String High range for the parameter. For parameters of type String and Enumeration, this field contains no data.

<MinValue> ASCII - String Low range for the parameter. For parameters of type String and Enumeration, this field contains no data.

<Default> ASCII - String Default value for the parameter.



The following table shows an example of the return on this execute for a non-material based recipe.

Example: An execute string consisting of: [INFO(RCPINFO,STATION5/operator2,CLS_FRENCHVANILLA.BPC)]

Would place this data in the item RCPInfo for the client: FREEZER \t FREEZER_CLS \t 0 \ r \ n MIXER \ t MIXER_CLS \t 0 \ crlf PARMS \crlf MILK_AMOUNT \ t 1 \ t 1 \ t KG \ t 5000 \ t 0 \ t 1999 \ crlf SUGAR_AMOUNT \ t 1 \ t 1 \ t KG \ t 1500 \ t 0 \ t 750 \ crlf CREAM_AMOUNT \ t 1 \ t 1 \ t K G \ t 5000 \ t 0 \ t 2001 \ crlf EGG_AMOUNT \ t 1 \ t 1 \ t KG \ t 500 \ t 0 \ t 200 \ crlf FLAVOR_AMOUNT \ t 1 \ t 1 \ t KG \ t 100 \ t 0 \ t 50 \ crlf

The following table shows an example of the return on this execute for a material-based recipe.

Example: An execute string consisting of: [INFO(RCPINFO,STATION5/operator2,MCLS_FRENCHVANILLA.BPC)]

Would place this data in the item RCPInfo for the client: FREEZER \t $UNITLIST \t NP_FREEZER1 \t NP_FREEZER2 \t $END \t 0 \crlf PARMS \crlf MILK_AMOUNT \t 1 \t 1 \t KG \t 5000 \t 0 \t 1999 \crlf SUGAR_AMOUNT \t 1 \t 1 \t KG \t 1500 \t 0 \t 750 \crlf CREAM_AMOUNT \t 1 \t 1 \t KG \t 5000 \t 0 \t 2001 \crlf EGG_AMOUNT \t 1 \t 1 \t KG \t 500 \t 0 \t 230 \crlf FLAVOR_AMOUNT \t 1 \t 1 \t KG \t 100 \t 0 \t 20 \crlf



The following table shows an example of the return on this execute for a optional phase-material list.

Example: An execute string consisting of: [INFO(item,STATION5/operator2,ADD_SWEET.UOP, ADD_SWEET\MBR_ADD:1,SUGAR_GRANULATED)]

Would return: ALIAS_MBR_MIXER_CLS\t$UNITLIST\tNP_MIXER1\tNP_MIXER2\t$END\t0\\crlf PARMS\\crlf

See also




The INFO2 execute obtains information about a recipe.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [INFO2(<Item>,<UserID><RecipeID>)]




Action A successful INFO2 execute places the recipe information into the item field.

Return Format The item populates with this data: <RecList> \crlf

where:



<Step> is <Alias>\t<BindData>\t<BindFlag>\crlf

<BindData> is <Class> | <UnitBindList>


<ParmInfo> is <Parameter>\t<ResponseType>\t<ParmEdit>\t<EngUnits>\t<MaxValue>\t<MinValue>\t<Default>\t<ERPAlias>\crlf

where:


PARMS ASCII - String Keyword to separate the Steps from the parameters in the return result.



<Class> ASCII - String Unit class the previous step was configured to use.



• 2 = long

• 3 = string

• 5 = enumeration

<ParmEdit> ASCII - Integer 1 = obsolete field used to mark recipe parameters as having values that could be edited or not. It always returns the value "1".

Info2



<EngUnits> ASCII - String Engineering units for the recipe parameter.

<MaxValue> ASCII - String High range for the recipe parameter. For parameters of type String and Enumeration, this field contains no data.

<MinValue> ASCII - String Low range for the recipe parameter. For parameters of type String and Enumeration, this field contains no data.

<Default> ASCII - String Default value for the recipe parameter.

<Response Type> ASCII - Integer Data type for the response • 1 = real

• 2 = long

• 3 = string

• 5 = enumeration

<ERPAlias> ASCII - String R/3 parameter name. Used to map recipe parameters between the FactoryTalk Batch Server and R/3.


Example: An execute string consisting of: [INFO2(RCPINFO,STATION5/operator2,CLS_SWEETCREAM_OP.UOP]

Would place this data in the item RCPInfo for the client: MIXER_CLS \t MIXER_CLS \t 0 \crlf PARMS \crlf MILK_AMOUNT \t 1 \t 1 \t KG \t 5000 \t 0 \t 0 \t ERP ALIAS 3 \crlf SUGAR_AMOUNT \t 1 \t 1 \t KG \t 1500 \t 0 \t 0 \t ERP ALIAS 4 \crlf CREAM_AMOUNT \t 1 \t 1 \t KG \t 5000 \t 0 \t 0 \t ERP ALIAS 1 \crlf EGG_AMOUNT \t 1 \t 1 \t KG \t 500 \t 0 \t 0 \t ERP ALIAS 2 \crlf

See also




The INFOTRIMMED execute retrieves the information necessary for the formatting of a Batch execute that would be used to instantiate a batch.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [INFOTRIMMED(<Item>,<UserID>,<RecipeID><PhaseMaterialData>)]




<PhaseMaterial Data>

Optional list of Phase-Material pair data.

where:

<PhaseMaterialData> is <NULLLIST>|,<PhaseMaterialList>

<PhaseMaterialList> is <PhaseMaterialRecord> | <PhaseMaterialRecord>,<PhaseMaterialList>

<PhaseMaterialRecord> is <PhasePathName>,<MaterialName>

where:


PhasePathName ASCII - String Full recipe pathname to the phase. (for example, PROC_1\UNITPROC_1:1\OPER_1:3\ADD:4)

MaterialName ASCII – String Name of a material configured in the Material Server (for example, Milk).

Action A successful INFOTRIMMED execute places the recipe information into the item field.

Return Format The response item populates with this data: <RecList> | FAIL:<FailData>

where:



<Step> is <Alias> \t <UnitBindList>\t <BindFlag> \crlf

<UnitBindList> is $UNITLIST \t <UnitList> \t $END

<UnitList> <UnitName> | <UnitName> \t <UnitList>


<ParmInfo> is <Parameter> \t <ResponseType> \t <ParmEdit> \t <EngUnits> \t <High> \t <Low> \t <Default> \crlf

<FailData> is <message> | <ZeroTargets>

InfoTrimmed



<ZeroTargets> is <ZeroTargsMarker> \crlf <ZeroTargsList>

<ZeroTargsList> is <ZeroTargs> | <ZeroTargs> \crlf <ZeroTargsList>

<ZeroTargs> is <ZeroTargsText> ':' <Alias> \crlf <UnitErrList> \crlf <EndUnitErrList> \crlf <BindReqList> \crlf <EndBindReqList> \crlf <ExprDataList> \crlf <EndZeroTargsData>

<UnitErrList> is <UnitErr> | <UnitErr> /crlf <UnitErrList>

<UnitErr> is <UnitIdLabel> ':' <UnitID> \t

<UnitNameLabel> ':' <UnitName> \t

<ReasonData>

<ReasonData> is <LegalReason> | <FPathReason> | <FPathRqmReason> | FPathMatReason> | <BindReqReason> | <MaterialReason> | <NotRecordedReason> | <InvalidReason>

<LegalReason> is <ReasonCodeLabel> ':' <ReasonCode> \t <ReasonTextLabel> ':' <ReasonText>

<FPathReason> is <ReasonCodeLabel> ':' <ReasonCode> \t <ReasonTextLabel> ':' <ReasonText>

<FPathRqmReason> is <ReasonCodeLabel> ':' <ReasonCode> \t <ReasonTextLabel> ':' <ReasonText>

<FPathMatReason> is <ReasonCodeLabel> ':' <ReasonCode> \t <ReasonTextLabel> ':' <ReasonText>

<BindReqReason> is <ReasonCodeLabel> ':' <ReasonCode> \t <ReasonTextLabel> ':' <ReasonText>':'<BindRqmtID>

<MaterialReason> is <ReasonCodeLabel> ':' <ReasonCode> \t <ReasonTextLabel> ':' <ReasonText> \t <MaterialLabel> ':' <Material> \t <LotLabel> ':' <Lot> \t <LabelLabel> ':' <Label> \t <UseCodeLabel> ':' <UseCode> \t <UseTextlabel> ':' <UseText> \t <StepLabel> ':' <StepPath>

<NotRecordedReason> is <ReasonCodeLabel> ':' <ReasonCode> \t <ReasonTextLabel> ':' <ReasonText>

<InvalidReason> is <ReasonCodeLabel> ':' <ReasonCode> \t <ReasonTextLabel> ':' <ReasonText>

<BindReqList> is <BindReq> | <BindReq> /crlf <BindReqList>

<BindReq> is <BindReqID> ':' <BindReqText>

<ExprDataList> is <ExprData> | <ExprData> /crlf <ExprDataList>



<ExprData> is <ExprDataUnitIDLabel> ':' <ExprDataUnitID> /t <ExprDataUnitNameLabel> ':' <ExprDataUnitName> /t <ExprBindSpecIDLabel> ':' <ExprBindSpecID> /t <ExpressionValues>

<ExpressionValues> is <ExpressionValue> <LeafValuePairs>




where:


FAIL: ASCII - String Keyword to indicate the InfoTrimmed execute encountered an error.

ASCII - String Error message formatted appropriately for operator display.

PARMS ASCII - String Keyword to separate the Steps from the parameters in the return result.



$UNITLIST ASCII - String Indicates the beginning of the list of unit names that contain references to material-based phases.

$END ASCII - String Indicates the end of the list of unit names that contain references to material-based phases.




• 2 = long

• 3 = string

• 5 = enumeration

<ParmEdit> ASCII - Integer 1 = obsolete field used to mark recipe parameters as having values that could be edited or not. It always returns the value "1".

<EngUnits> ASCII - String Engineering units for the recipe parameter.

<High> ASCII - String High range for the recipe parameter. For parameters of type String and Enumeration, this field contains no data.

<Low> ASCII - String Low range for the recipe parameter. For parameters of type String and Enumeration, this field contains no data.

<Default> ASCII - String Default value for the recipe parameter.

ZeroTargsMarker ASCII - String String constant "$ZEROLEGALBINDTARGSDATA" used to indicate that the response item contains data elaborating the reasons why there are zero legal bind targets for one or more Unit Requirements.

ZeroTargsText ASCII - String Localized displayable error message, indicating that the specified unit requirement (following the ':' character) has zero legal bind targets.



EndUnitErrList ASCII - String String constant "$ENDUNITDATA" marks the end of the set of Unit Instance legality records.

EndBindReqList ASCII - String String constant "$ENDBINDREQDATA" marks the end of the set of Binding Requirement records.

EndZeroTargsData ASCII - String String constant "$ENDUNITRQMTDATA" marks the end of a Unit Requirements expression data records (and the end of the Unit Requirement's data).

UnitIdLabel ASCII - String Non-localized English string label for the Unit ID that follows.

UnitId ASCII - Integer Integer value identifier of the Unit for which bind illegality describes.

UnitNameLabel ASCII - String Non-localized English string label for the Unit name that follows.

UnitName ASCII - String Name of the unit or which bind illegality describes.

ReasonCodeLabel ASCII - String Non-localized English string label for the Reason Code field that follows.

ReasonCode ASCII - Integer Integer field describing the legality of the Unit Instance for binding. Possible values are: 0 - Unit is a legal binding target 1 - Unit invalid due to material requirement 2 - Unit invalid due to binding requirement 3 - Unit invalid due to material requirement on flowpath 4 - Unit Invalid due to static binding requirement on flowpath 5 - Unit Invalid due to flowpath analysis 6 - Invalid reason code 7 - Unit invalidity reason not recorded

ReasonTextLabel ASCII - String Non-localized English string label for the Reason Text field that follows.

ReasonText ASCII - String Non-localized English string that describes the reason the unit is an illegal bind target.

MaterialLabel ASCII - String Non-localized English string label for material name field that follows.

Material ASCII - String Name of the material associated with the material requirement that made the unit instance an illegal bind target.

LotLabel ASCII - String Non-localized English string label for the Lot field that follows.

Lot ASCII - String LOT specifier associated with the material requirement that made the unit instance an illegal bind target.

LabelLabel ASCII - String Non-localized English string label for the Label field that follows.

UseCodeLabel ASCII - String Non-localized English string label for the Use Code field that follows.

UseCode ASCII - Integer Integer value indicating the usage type defined by the material requirement that made the unit instance an illegal bind target. Possible values are: 0 - Distribution 1 - Addition

UseTextLabel ASCII - String Non-localized English string label for the Use Text field that follows.

UseText ASCII - String Localized string describing the usage type defined by the material requirement that made the unit instance an illegal bind target.

StepLabel ASCII - String Non-localized English string label for the Step Path field that follows.

StepPath ASCII - String Full path to the step associated with the material requirement that made the unit instance an illegal bind target.



BindReqID ASCII - Integer Integer value identifier of the Binding Requirement exposed in this record.

BindReqText ASCII - String Non-localized string that is a "readable" description of the binding requirement. Note, this may contain the ':' character.

ExprDataUnitIDLabel ASCII - String Non-localized English string label for the Unit ID field that follows.

ExprDataUnitID ASCII - Integer Integer value identifier of the Unit Resource associated with this data record.

ExprDataUnitNameLabel ASCII - String Non-localized English string label for the Unit Name field that follows.

ExprDataUnitName ASCII - String Name of the Unit Resource associated with this data record.

ExprBindSpecIDLabel ASCII - String Non-localized English string label for the Bind Specifier ID field that follows.

ExprBindSpecID ASCII - Integer Integer value identifier of the Binding Specifier associated with this data record.

ExpressionValue ASCII - Variable Evaluated value of the expression.

LeafName ASCII - String Name of the leaf from the expression.

LeafValue ASCII - Variable Value of the leaf from the expression.


Example: An execute string consisting of: INFOTRIMMED(Item,Station2/View,MAKE_SOUP.BPC)

Could return: FREEZER \t FREEZER_CLS \t 0 \ r \ n MIXER \ t MIXER_CLS \t 0 \ crlf PARMS \crlf MILK_AMOUNT \ t 1 \ t 1 \ t KG \ t 5000 \ t 0 \ t 1999 \ crlf SUGAR_AMOUNT \ t 1 \ t 1 \ t KG \ t 1500 \ t 0 \ t 750 \ crlf CREAM_AMOUNT \ t 1 \ t 1 \ t K G \ t 5000 \ t 0 \ t 2001 \ crlf EGG_AMOUNT \ t 1 \ t 1 \ t KG \ t 500 \ t 0 \ t 200 \ crlf FLAVOR_AMOUNT \ t 1 \ t 1 \ t KG \ t 100 \ t 0 \ t 50 \ crlf

See also




The MATSVRCONTROL execute is used by the Material Server Control dialog to reestablish communication.

Tip: This execute is valid when Option when Material Server Communication is lost is set to Switch to Manual.


Execute Format The FactoryTalk Batch Server supports an execute with this format: [MATSVRCONTROL(Item,UserID,STATE)]

where: Item Name of the item as specified by the client.


State 2 represents the GOOD state. Returning to the GOOD state is the only control currently available.

Action A successful MATSVRCONTROL execute reestablishes communication with the Material Server.

Return Format The MATSVRCONTROL execute populates with this data: SUCCESS:|FAIL:<message>


Example: An execute string: MATSVRCONTROL(PC2matsvrcontrol,PC2/Operator,2)

See also


MatSvrControl



The MESSAGES execute obtains a message list associated with a particular phase.


Execute Format A FactoryTalk Batch Server supports an execute string with the MESSAGE keyword. The execute string format: [MESSAGES(Item,UserID,PhaseID)]



PhaseID Phase’s Equipment ID as configured in FactoryTalk Batch Equipment Editor.

Action A successful MESSAGES execute places the message string into the item.

Return Format The MESSAGES execute returns in this format: <MessageList>

where:

<MessageList> is <Messages> | FAIL:<message> | FAILED | NullString

<Messages> is <ID>, <MessageString> \crlf <MessageList>

where:


<ID> ASCII - String Unique ID of the message string.

<MessageString> ASCII - String Message string associated with the ID.


Example: An execute string consisting of: MESSAGES(PC2Messg,UserID,36)

Could place this data in the item PC2Messg for the client: 1,FV101_OPEN \crlf 2,FV101_CLOSED \crlf

See also


Messages



The MTRL_INFO execute returns the information necessary allowing material selection for a Material Manager phase written as material class-based.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [MTRL_INFO(Item,UserID,RecipeFileName)]



RecipeID Recipe filename.

Action A MTRL_INFO execute returns necessary information to select materials for Material Manager phases that have a MATERIAL_CLASS parameter set to a non-NULL_CLASS value.

Return Format The MTRL_INFO execute returns in this format: SUCCESS:<Phase-MaterialInfo> | FAIL:<Message>

where:

<Phase-MaterialInfo> is <Null List>|< Phase-Material List>

<Phase-MaterialList> is <Phase-Material Record >|<Phase-Material Record>\crlf < Phase-Material List>

<Phase-MaterialRecord> is <Phase Pathname>\t<Material Class Name>\t<Material List>$END

<MaterialList> is < Material Name>|< Material Name>\t<Material List>

where:


<Phase Pathname> ASCII Full recipe pathname to the phase. (for example, PROC_1\UNITPROC_1:1\OPER_1:3\ADD:4)

<MaterialClass Name> ASCII Name of material class referenced by the MATERIAL_CLASS parameter. (for example, SWEETENER)

<MaterialName> ASCII Name of a material of the designated material class. (for example, RAW_SUGAR)

Tip: "SUCCESS:" followed by a null list indicates that no material class references exist to be resolved. "SUCCESS:" followed by a non-null list implies that all Material Lists returned must also be non-empty. If an empty Material List would have resulted (that is, no Material to choose for the Material Class), MTRL_INFO returns "FAIL:".

Mtrl_Info




Example: An execute string consisting of: MTRL_INFO (Item,User,VANILLA_ICE_CREAM.BPC)

Could return: SUCCESS:YUMMY_STUFF\SWEETCREAM_UP:1\SWEETCREAM_OP:2\ADD:1\tSWEETENERS\tRAW_SUGAR\tBROWN_SUGAR\tSYRUP$END\crlf YUMMY_STUFF\CHOCOLATE_UP:1\CHOCOLATE_OP:2\ADD:1\tDARK_CHOCOLATES\t68_PER_CENT_COCOA\t52_PER_CENT_COCOA$END

See also




The ORDER execute reorders the requester’s list for a resource.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [ORDER(Item,UserID,ResourceID,OwnerID,NextOwnerID, Position)]



ResourceID Resource’s Equipment ID whose requester’s list is to be reordered.

OwnerID Resource’s unique ID to be moved in the requester’s list.

NextOwnerID Resource’s unique ID, in the position within the requester’s list, which the OwnerID is requesting. If Position is RELATIVE, the OwnerID resource will be positioned prior to the NextOwnerID resource.

Position Position within the requester’s list in which the resource should be placed:

• RELATIVE - indicates that the resource should be placed somewhere other than at the end of the list.

• TAIL - indicates that the resource should be placed at the end of the list. In this case the OwnerID and NextOwnerID parameters are ignored.

Action A successful ORDER execute results in a change to the requester’s list for the ResourceID.



Example: An execute string: ORDER(Item,UserID,12,22,1,RELATIVE)

See also


Order



The PARAMEXPCLEAR execute allows the operator to remove an override of a specified expression that was created by a prior ParamExpOverride execute. When the override clears, the current expression evaluation determines the value of the parameter expression.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [ParamExpClear(Item, UserID, ParamExpressionID)]

where: Item Name of the response item, as specified by the client.


ParamExpression-ID Unique ID, as assigned by the system, of the parameter expression targeted by the override. The parameter expression ID is typically retrieved by a client application using the ProcedureIDData3 data item.

Action A successful ParamExpClear execute removes an existing expression value force and causes the value of the expression to revert to the value to which the expression currently evaluates.


where:




Example: An execute string consisting of: ParamExpClear(Item,Station2/View,27)


See also


ParamExpClear



The PARAMEXPOVERRIDE execute allows the operator to override the result of a parameter expression evaluation with a specified value. The value of the parameter expression remains overridden until a ParamExpClear execute is used to remove the override or an ensuing ParamExpOverride changes the value to which the expression is overridden. The value to which the expression is overridden is not permitted to violate the configured minimum and maximum limits of the expression's associated parameter.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [ParamExpOverride(Item, UserID, ParamExpressionID, value)]

where: Item Name of the response item, as specified by the client.


ParamExpressionID Unique ID, as assigned by the system, of the parameter expression targeted by the override. The parameter expression ID is typically retrieved by a client application using the ProcedureIDData3 data item.

value Value to which the parameter expression is to be forced.

Action A successful ParamExpOverride execute forces the expression parameter to hold the value specified in the execute and not the value to which the expression currently evaluates.


where:




Example: An execute string consisting of: ParamExpOverride(Item,Station2/View,27,3.14159)


See also


ParamExpOverride



The PARMS execute obtains the parameters of a procedure.


Execute Format A FactoryTalk Batch Server supports an execute string with the PARMS keyword. The format of the execute string: [PARMS(Item,UserID,ProcedureID)]



ProcedureID Unique path name to the procedure, starting with the CreateID and followed by the step name(s), all of which are tab delimited.

Action A successful PARMS execute returns the parameter string into the item specified by the client.

Return Format The PARMS execute s returns in this format: <Parameter> \t <ResponseType> \t <EngUnits> \t <MaxValue> \t <MinValue> \t <Value> \crlf

where:



<Response Type>

ASCII - Integer Data type for the response: • 1 = real

• 2 = long

• 3 = string

• 5 = enumeration


<MaxValue> ASCII - String High range for the parameter.

<MinValue> ASCII - String Low range for the parameter.

<Value> ASCII - String Current value of the parameter.


Example: An execute string consisting of: [PARMS(Item,UserID,41 \t CLS_SWEETCREAM_UP:1 \t CLS_SWEETCREAM_OP:1 \t TEMP_CTL:1)

Could place this data in Item for the client: HOLD_TIME \t 1 \t MINUTES \t 60 \t 0 \t 5 \crlf TEMP_SP \t 1 \t DEG \t C \t 100 \t 0 \t 71.1 \crlf

See also


Parms



The PARMS2 execute obtains the procedure’s parameters.


Execute Format A FactoryTalk Batch Server supports an execute string with the PARMS keyword. The execute string’s format: [PARMS2(Item,UserID,ProcedureID)]



ProcedureID Unique path name to the procedure, starting with the CreateID and followed by the step name(s), all of which are tab delimited.

Action A successful PARMS2 execute returns the parameter string into the item specified by the client.

Return Format The PARMS2 execute returns in this format: <Parameter> \t <ResponseType> \t <EngUnits> \t <MaxValue> \t <MinValue> \t <Value> \t <HighHighHighLimit>\t<HighHighLimit>\t<HighLimit> \t <LowLimit> \t \<LowLowLimit>\t<LowLowLowLimit> \crlf

where:


<Parameter> ASCII - String Name of the parameter.

<ResponseType> ASCII - Integer Data type for the response: • 1=real

• 2=long

• 3=string

• 5=enumeration


<MaxValue> ASCII - String High range for the parameter.

<MinValue> ASCII - String Low range for the parameter.

<Value> ASCII - String Current value of the parameter.

<HighHighHighLimit> ASCII - Integer High-High-High limit.

<HighHighLimit> ASCII - Integer High-High limit.

<HighLimit> ASCII - Integer High limit.

<LowLimit> ASCII - Integer Low limit.

<LowLowLimit> ASCII - Integer Low-Low limit.

<LowLowLowLimit> ASCII - Integer Low-Low-Low limit.

Parms2




Example: An execute string consisting of: [PARMS2(Item,UserID,41 \t CLS_SWEETCREAM_UP:1 \t CLS_SWEETCREAM_OP:1 \t TEMP_CTL:1)

Could place this data in Item for the client: HOLD_TIME \t 1 \t MINUTES \t 60 \t 0 \t 5 \crlf TEMP_SP \t 1 \t DEG \t C \t 100 \t 0 \t 71.1 \t90 \t83 \t78 \t65 \t45 \t35 \crlf.

See also


The PHASE execute commands a phase or an equipment operation sequence to a specified state.

The operator must own the phase or equipment operation sequence in order to change it.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [PHASE(Item,UserID,EquipmentID,Cmd,BatchID,Unit)]



EquipmentID Unique equipment ID for the phase or equipment operation sequence.

Cmd Command for the phase or equipment operation sequence. Valid commands are: START, STOP, RESET, RESUME, HOLD, RESTART, PAUSE, ABORT, DOWNLOAD, DISCONNECT, AUTO-MODE, SEMIAUTO-MODE, CLEAR_ FAILURES

BatchID Identifier for the batch that is required for journals associated with this phase or equipment operation sequence.

Unit Name of the unit to use with the phase or equipment operation sequence.

Phase



Action A successful PHASE execute results in the specified command either being queued pending a signature confirmation, or being issued to the specified phase or equipment operation sequence. If the command is valid and a batch does not already exist for manual control of the phase or equipment operation sequence, then a batch is created using the specified BatchID and Unit. A failure message is generated when the following occurs: • The command was not legal based on the current state or properties of a phase or

equipment operation sequence.

• The phase or equipment operation sequence is under external control.

• The equipment ID that is passed does not match the ID of a phase or equipment operation sequence.


where:


<ActionID> ASCII – Integer Identifier associated with the signature(s) generated in response to the execute.



Example: An execute string consisting of: PHASE(Item,Station2/View,29,START,MAKESTUFF,BIGMIXER)


See also




The PHASE2 execute commands a phase associated with a control strategy to a specified state.

The operator must own the phase to change it.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [PHASE2(Item,UserID,PhaseID,Cmd,BatchID,Unit, ControlStrategyID)]



PhaseID Unique Equipment ID for the desired phase.

Cmd Command for the phase. Valid commands are: START, STOP, RESET, RESUME, HOLD, RESTART, PAUSE, ABORT, DOWNLOAD, DISCONNECT, AUTO-MODE, SEMIAUTO-MODE, CLEAR_ FAILURES, TIMER-Complete and TIMER-Reset

BatchID BatchID required for journals associated with this phase.


Control StrategyID

Value of the control strategy to use with the phase. If the phase is not Control Strategy enabled, this field must contain negative one (-1).

Action A successful PHASE2 execute results in the specified command either being queued pending a signature confirmation, or being issued to the specified phase. If the command is valid and a batch does not already exist for manual control of the phase, then a batch is created using the specified BatchID, Unit, and Control Strategy. A failure message is generated when the following occurs:

• The command was not legal based on the current state or properties of a phase.

• The phase is under external control.

• The equipment ID that is passed does not match the ID of a phase.


where:


<ActionID> ASCII – Integer ActionID associated with the signature(s) generated in response to the execute.


Phase2




Example: An execute string consisting of: PHASE2(Item,Station2/View,29,START,MAKESTUFF,BIGMIXER,2)


See also


The PHASE3 execute commands a phase or equipment operation sequence to a specified state. This execute includes parameters that support the commanding of phases that are configured to use control strategies and those associated with a material-enabled phase class.

The operator must own the phase or equipment operation sequence in order to change it.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [PHASE3(Item,UserID,EquipmentID,Cmd,BatchID,Unit, ControlStrategyID,ContainerName,ContainerControllerID, MaterialName,LotName,LabelName,FeedType)]



EquipmentID Unique equipment ID for the phase or equipment operation sequence.

Cmd Command for the phase or equipment operation sequence. Valid commands are: START, STOP, RESET, RESUME, HOLD, RESTART, PAUSE, ABORT, DOWNLOAD, DISCONNECT, AUTO-MODE, SEMIAUTO-MODE, CLEAR_ FAILURES

BatchID Identifier for the batch that is required for journals associated with this phase or equipment operation sequence.


ControlStrategyID Value of the control strategy to use with the phase. If Control Strategy is disabled, this field must contain negative one (-1).

ContainerName Container name this phase is to bind with. For material-enabled phases, this is required data.

Container ControllerID

Value returned by the GETCONTAINERDATA execute. This is the controller ID for the container. For material-enabled phases, this is required data.

Phase3



MaterialName Name of the material required by the phase. For material-enabled phases, this is required data.

LotName Lot name to filter containers for material additions, optional for material-enabled phases. If the phase is not material-enabled or the execute is being used to command an equipment operation sequence, this field must be blank (single blank space character).

LabelName Label name to filter containers for material additions, optional for material-enabled phases. If the phase is not material-enabled or the execute is being used to command an equipment operation sequence, this field must be blank (single blank space character).

FeedType Specifies whether the phase adds material to the unit or distributes material from the unit. If the phase is not material-enabled or the execute is being used to command an equipment operation sequence, this field must be blank (single blank space character). These are the valid values:

• ADDITION

• DISTRIBUTION

Action A successful PHASE3 execute results in the specified command either being queued pending a signature confirmation, or being issued to the specified phase or equipment operation sequence. • If the command is valid and a batch does not already exist for manual control of the phase

or equipment operation sequence, then a batch is created using the specified BatchID and Unit.

• For a phase using a control strategy, the Control Strategy term is used.

• For material-enabled phases, the ContainerName, ContainerControllerID, MaterialName, LotName, LabelName, and FeedType terms are all used. The PHASE3 execute does not check that the phase is configured to support the specified FeedType (addition or distribution).

A failure message is generated when the following occurs:

• The command was not legal based on the current state or properties of a phase or equipment operation sequence.

• The phase or equipment operation sequence is under external control.

• The equipment ID that is passed does not match the ID of a phase or equipment operation sequence.


where:


<ActionID> ASCII – Integer Action ID associated with the signature(s) generated in response to the execute.




The following table shows an example of the return on this execute to start a material-enabled phase.

Example: An execute string consisting of: PHASE3(Item,Station2/View,29,START,MAKESTUFF,BIGMIXER,2,TEMP_EGG,27,EGG_YOLK, , ,ADDITION)


The following table shows an example of the return on this execute to start a control strategy and material-enabled phase.

Example: An execute string: [PHASE3(Item,STATION5/Operator,71,START, BATCH_ID, NP_MIXER1, Strategy_1,TEMP_EGG,27,EGG_YOLK, , ,ADDITION)]

See also


GetContainerData on page 244



The REACTIVATESTEP execute causes the FactoryTalk Batch Server to journal a Step_Reactivation Request event.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [REACTIVATESTEP(Item,UserID,RecipePath,StepIndex, ReactivationNumber)]



RecipePath Path that represents the part of the recipe where the step originated.

StepIndex Number representing the position of the step within the phase.

Reactivation Number

Number representing the number of times the step has been reactivated.

Action A successful REACTIVATESTEP execute results in a Step_Reactivation_Request event being queued pending a Signature Confirmation or a Step_Reactivation_Request event being written to the event journal.


where:


<ActionID> ASCII – Integer ActionID associated with the signature(s) generated in response to the execute.



Example: An execute string: [REACTIVATESTEP(Item321,JoeOperator,45133:CLS_FRENCHVANILLA\CLS_SWEETCREAM_UP:1\ CLS_SWEETCREAM_OP:1\ADD_EGG:1-1,4,0)]

See also


ReactivateStep



The RECIPELIST execute obtains information about the recipes from FactoryTalk Batch Recipe Editor. To review the recipe information, issue a request against the RecipeList item.


Execute Format A FactoryTalk Batch Server supports an execute string with the RECIPELIST keyword. The format of the execute string: [RECIPELIST(Item,UserID)]



Action A successful RECIPELIST execute returns the recipe list information into the response item on the client.


Tip: When using the DDE protocol, the RecipeList item returns a SUCCESS/FAIL response only. When using the COM interface, the RecipeList item returns the actual Recipe List data.

RecipeList




Example: An execute string consisting of: [RECIPELIST(Item,STATION5/Operator)]

Requesting data from Item could return: 3.0 \t FRENCH_VANILLAPREMIUM1_MEGA_PARLOR_OPT_2_ U1.UPC \t FRENCH_VANILLAPREMIUM1_MEGA_PARLOR_ OPT_2_U1 \t French Vanilla IceCream \t French Vanilla \t FVP-101 \t Premium 1 \t 2/1/2017 11:11:50 AM \t Administrator \t rpmServer ( STAGE1\rpmServer ) on computer STAGE1 \t UNIT PROCEDURE \t Instance \t The general recipe French_Vanilla, Variant= Premium, Version= 1 is successfully converted to master recipe FRENCH_ VANILLAPREMIUM1_MEGA_PARLOR \t 25 \t 50 \t 100 \t KG \t \t TRUE \t \\STATION5\PROGRAM FILES\ROCKWELL SOFTWARE \BATCH\SAMPLEAPP\RECIPES\ICE_CREAM4.CFG \t 2/1/2017 11:04:31 AM \t MP_MIXERFREEZER1 \t 2/1/2017 11:11:44 AM \crlf ... 3.0 \t CLS_STRAWBERRY_ICEMILK.BPC \t CLS_STRAWBERRY_ ICEMILK \t Strawberry Ice Milk - Reduced Fat Ice Cream - class based \t Strawberry Ice Milk \t SIM-101 \t 1.0 \t 2/1/2017 11:11:50 AM \t Mark Shepard \t MSS \t PROCEDURE \t Class \t \t 3000 \t 5000 \t 7000 \t KG \t 45 \t TRUE \t \\STATION5\PROGRAM FILES\ROCKWELL SOFTWARE\BATCH\SAMPLEAPP\RECIPES\ICE_CREAM4.CFG \t 2/1/2017 11:04:31 AM \t \t 2/1/2017 11:11:44 AM \crlf

See also




The RELEASE execute releases a resource from the operator.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [RELEASE(Item,UserID,OwnerID,ResourceID)]



OwnerID ID of the operator configured in the batchsvr.ini file.

ResourceID Equipment ID of the resource to be released. This value is configured in FactoryTalk Batch Equipment Editor.

Action A successful RELEASE execute removes the resource from either the requester’s or owner’s list. (The owner is notified of the action and may elect to re-acquire the resource.)


where:




Example: An execute string: [RELEASE(Item,Station5/Operator,0,68)]

See also


Release



The REMOVE execute removes a batch from the batch list.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [REMOVE(Item,UserID,CreateID)]



CreateID Unique identification number for a batch.

Action A successful REMOVE execute results in the removal of the specified batch from the batch list, or in the queuing of the removal pending a signature. In order to be successfully removed, a batch cannot be in Manual mode and must be in one of these states: • READY

• COMPLETE

• STOPPED

• ABORTED


where:


<ActionID> ASCII – Integer Action identifier associated with the signature(s) generated in response to the execute.



Example: An execute string consisting of: [REMOVE(Item,Station5/Operator,235)]


See also


Remove



The SETALLLABEL execute sets the same label on all material steps within a recipe. The label helps identify specific material sublots for use. In material addition phases the label identifies specific material sublots for use. In material distribution phases, the label is applied to the material sublot distributed.

The SETALLLABEL execute applies only to material-enabled phases.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [SETALLLABEL(Item,UserID,ProcedureID,LabelString)]



ProcedureID Unique hierarchical path name to the procedure, unit procedure, operation or phase: • Procedure: CreateID

• Unit Procedure: CreateID \t UnitProcIDName

• Operation: CreateID \t UnitProcIDName \t OperIDName

• Phase: CreateID \t UnitProcIDName \t OperIDName \t PhaseIDName

LabelString Label to be stored on the phase.

where:



where:




Action A successful SETALLLABEL execute either changes the label values in the specified step(s), or queue the change(s) and return an action ID from which the signature requests generated can be detected.


where:


<ActionID> ASCII – Integer Action identifier associated with signature(s) generated as a result of the potential parameter value change. The parameter value will not actually change unless all signatures are successfully signed.


SetAllLabel




Example: An execute string: [SETALLLABEL(Item,Station5\Operator,887 \t PREMIX_B, CUSTOMJOB2)]

See also


The SETALLLOT execute sets the same lot name on all material phase steps within a recipe. In material addition phases, the lot name helps identify specific material sublots for use. In material distribution phases, the lot name is applied to the material lot distributed.

The SETALLLOT execute applies only to material-enabled phases. The execute results in no changes with non-material phases.

SetAllLot




Execute Format A FactoryTalk Batch Server supports an execute with this format: [SETALLLOT(Item,UserID,ProcedureID,LotString)]



ProcedureID Unique hierarchical path name to the procedure, unit procedure, operation or phase: • Procedure: CreateID




LotString Lot name to be assigned.



where:




Action A successful SETALLLOT execute changes the lot name values in the specified step(s).


where:





Example: An execute string consisting of: SETALLLOT(Item,Station2/View, 99, 53)


See also




The SETPARM execute sets the parameter value(s) of a control recipe step. The SETPARM execute does not change the MATERIAL formula parameter or the MATERIAL_CLASS formula parameter on all material phases. The MATERIAL formula parameter determines how a phase is bound and material availability for binding; because of this the value must not change during recipe execution. If storing the parameter results in deviation limits being violated that require signature confirmations, then an action ID returns identifying the signatures generated as a result of the SETPARM execute.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [SETPARM(Item,UserID,ProcedureID,ParamName,Value)]



ProcedureID Unique hierarchical path name to the procedure, unit procedure, operation or phase:

• Procedure: CreateID




ParamName Parameter name requiring a value assignment.

Value Value to be loaded in the step’s parameter.



where:


<CreateID> ASCII - Integer Unique batch ID assigned by the FactoryTalk Batch Server


Action A successful SETPARM execute either changes the parameter value in the specified step or queue the value change and return an action ID. As a result of deviations triggered by the potential SETPARM, the signature requests generated can be detected.


where:


<ActionID> ASCII – Integer Action identifier associated with signature(s) generated as a result of the potential parameter value change. The parameter value does not actually change unless all signatures are successfully signed.

SetParm





Example: An execute string consisting of: SETPARM(Item, Station2/View, 37/tMakeStuff1:1/tFill1:1/tDose1:1, Amount, 3.14159)


See also


The SIGNOFFSIGNATURE execute allows a client to sign a signature request on an incomplete signature, excluding those generated by private interfaces.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [SIGNOFFSIGNATURE(Item, UserID, SignatureID, SignoffNumber, Domain, Comment, SignerID, Password)]



SignatureID Unique ID of the signature for which the signoff is intended.

SignoffNumber Signoff number for which the signoff is intended (1 or 2).

Comment Comment string being passed with signoff. The locale-specific list separator character should be escaped from the comment argument as follows: The client application shall replace all instances of the ‘/’ character with ‘/FS’. The client application shall then replace all instances of the list separator character with ‘/LS’. The tab character shall be considered illegal for the comment argument. If a tab character is detected in the comment string, the execute shall fail.

Domain Domain to be used when authenticating the SignerID parameter.

SignerID Security-related User ID of the user attempting the signoff (not the full name).

Password Security-related password of the User attempting the signoff.

SignoffSignature



Action A successful SIGNOFFSIGNATURE fulfills a signoff on an incomplete signature.

Return Format The response item populates with this data: SUCCESS: <ActionID>| FAIL:<message> Where action ID = integer value; the Action ID of the action that required the signature. (Only the final sign-off of a Signature returns an Action ID.)

where:





Example: An execute string consisting of: SIGNOFFSIGNATURE(Item,Station2/View,993,1,Italy,What is this,LDVinci, helicopter)

Could return: SUCCESS: or SUCCESS:Action ID

See also


The STEP execute changes the active control step(s) within a control recipe.


Execute Format A FactoryTalk Batch Server supports an execute with this format: [STEP(Item,UserID,ProcedureID,DeactivateList,STEP,ActivateList)]



ProcedureID Unique hierarchical path name to the procedure, unit procedure, or operation: <FullPath>

• Unit Procedure: CreateID

• Operation: CreateID \t UnitProcIDName

• Phase: CreateID \t UnitProcIDName \t OperationIDName

<Deactivate List>

Step name list to be deactivated in the procedure: <DeactivateList> $INITSTEP and $TERMSTEP are recognized as the initial and terminal step names in a procedure and can deactivate the initial or terminal steps.

STEP Literal STEP is passed separating the step list to be deactivated from the list to be activated.

Step



<Activate List>

List of step names to be activated in the procedure: <ActivateList> $INITSTEP and $TERMSTEP are recognized as the initial and terminal step names in a procedure and can activate the initial or terminal steps.

where:



<Deactivate List> is <NullList | <StepList>

<ActivateList> is <NullList> | <StepList>

<StepList> is <StepIdentifier> | <StepIdentifier>, <StepList>




Action A successful STEP execute changes the active steps within a control recipe.


where:





Example: An execute string consisting of: [STEP(Item,STATION5/Operator,9 \t FRENCH_VANILLAPREMIUM1_MEGA_PARLOR_OPT_1_O1:1,TEMP_CTL:2,RECIRC:1,STEP,MBR_DUMP:1)]

or STEP(Item,Station2/View, 17\tMakePreMix:1\tChargeDryMats:1, DoseDust:1, STEP, DoseSand:1)


See also




The TAG_VERIFY execute initiates or aborts the tag verification process. Tags include tags (OPC tags), unit attribute tags, and backing tags for each phase and equipment operation sequence.


Execute Format A FactoryTalk Batch Server supports an execute string with the TAG_VERIFY keyword. The execute string format: [TAG_VERIFY(Item,UserID,Cmd)]

where: Item Name of the item as specified by the client.


Cmd Command to start or stop the tag verification. Valid commands are: • START

• STOP

Action A successful TAG_VERIFY START execute starts the tag verify operation, while a successful TAG_VERIFY STOP execute halts a tag verify operation that is in progress.


where:




Example: An execute string consisting of: [TAG_VERIFY(Verify,Operator,START)]

Could place this data in the item verify for the client: SUCCESS:

See also


Tag_Verify



The USER_VERIFY execute determines if the password provided for the specified Windows user name is correct and if that user belongs to a specified Windows group. This execute verifies Windows users and groups only.


Execute Format A FactoryTalk Batch Server supports an execute string with USER_VERIFY as the keyword. The format of the execute string is as follows: [USER_VERIFY (Item,UserID,Password,Group)]

where: Item Item name on which to place the execute.

UserID ID of the Windows user being verified.

Password Password to be checked for specified Windows user.

Group Windows group name to check for user membership. Formatted as [authority \] principal, where authority is an optional computer or domain name, and principal is a Windows group name. The delimiting backslash should be omitted if the optional authority is not included.

Action A successful USER_VERIFY execute determines if the Windows user and password combination are valid and if the verified user belongs to the specified Windows group.

Return Format SUCCESS | FAIL


Example: An execute string consisting of: USER_VERIFY (Item,Buck,Alligators,MasterRecipeViewer)

Could place this data in Item for the client: SUCCESS

See also


The VERIFICATIONINFO execute is no longer supported by the FactoryTalk Batch Server. Execution of VERIFICATIONINFO returns the server response: FAIL: Bad execute argument.

See also


User_Verify

VerificationInfo


Chapter 4

XML-based item references

An item is a named data structure accessed using any data access technology supported by the FactoryTalk Batch Server like the custom COM interface GetItem method or through OPC. The XML structure and the formatting methods used for each of the Items are below. The schema files are located in the \Batch\Schema folder.

To enable the XML items, modify the DisableResourcesList setting in the [API] section of the batchsvr.ini file.

The valid settings are:

• 0 - Enables ResourcesList guard rail; ResourcesList and ResourcesListX are valid items. (Default)

• 1 - Disables ResourcesList guard rail; disables ResourcesList item, only ResourcesListX is a valid item.

If the DisableResourcesList entry does not exist in the batchsvr.ini file then the FactoryTalk Batch Server defaults internally to 0.

Example:

[API]

DisableResourcesList=1

Important: This value is read during startup only — if the value changed stop and restart the FactoryTalk Batch Server to read the new value.

See also

ResourcesListX on page 294

Chapter 4 XML-based item references


The ResourcesListX data item returns a directory (list) of all resources and their corresponding resource ID and type.

Example Input of ResourcesListX:

object.GetItem(ResourcesListX)

Output of ResourcesListX:

<ResourcesListX>

<ResourceIndexData>

</ResourcesListX>

where ResourceIndexData is:

<Res ID = "Value" Type = "Value" />

where:

Res ID (integer) – A unique Equipment ID for a Resource. Resource IDs can also be zero or negative. Zero is reserved for the Operator object and negative IDs are used for Recipe Procedures.

Type (positive integer) =

• 1 = Process Cell

• 2 = Unit

• 3 = Phase

• 4 = Resource

• 5 = Procedure

See also

ResourcesListX example on page 295

XML-based item references on page 293

ResourcesListX

XML-based item references Chapter 4


A client request to retrieve the value of the ResourcesListX data item could return:

<ResourcesListX >

<Res ID="-82" Type="5" />

<Res ID="2" Type="1" />

<Res ID="3" Type="2" />

<Res ID="7" Type="3" />

<Res ID="20" Type="4" />

<Res ID="-83" Type="5" />

</ResourcesListX>

See also


ResourcesListX on page 294

ResourcesListX example

Chapter 4 XML-based item references


The [ResourceID]ResourceDataX item is a set of items that correspond on a one-to-one basis with the ResourceIndexData entries (ID & Type attributes) exposed in the ResourcesListX data item. The [ResourceID]ResourceDataX data item returns the ID, name, type, and arbitration mask (ArbMask) of a single resource.

Example Input of [ResourceID]ResourceDataX:

object.GetItem([ResourceID]ResourceDataX)

Output of [ResourceID]ResourceDataX:

<ResourceDataX>

<ResourceData>

</ResourceDataX>

where ResourceData is:

<ResourceDataX ID="Value" Type="Value" Name="Value" ArbMask="Value" />

where:

ID (integer) – A unique equipment ID for a resource. Resource IDs can also be zero or negative. Zero is reserved for the operator object and negative IDs are used for recipe procedures.

Type (positive integer) =

• 1 = Process Cell

• 2 = Unit

• 3 = Phase

• 4 = Resource

• 5 = Procedure

Name (string) – The name of the resource

ArbMask (nonNegativeInteger) – The arbitration mask is used as a bitmask, with each bit indicating whether a specific command is valid or invalid.

See also

[ResourceID]ResourceDataX example on page 297



[ResourceID] ResourceDataX

XML-based item references Chapter 4


A client request to retrieve the value of a [ResourceID]ResourceDataX item could return:

<ResourceDataX ID="42" Name="Reactor1007" Type="3" ArbMask="6" />

See also

[ResourceID] ResourceDataX on page 296

[ResourceID]ResourceDataX example


Appendix A

Object reference

This section describes the properties and methods associated with the BatchServer and BatchRemote objects including syntax and examples of Visual Basic code.

See also

GetItem method on page 300

Execute method on page 301

CallTimeout property on page 302

ConnectTimeout property on page 303

Node property on page 304

Appendix A Object reference


The GetItem method retrieves data associated with a specified item within the FactoryTalk Batch Server application. The GetItem method applies to the BatchServer and BatchRemote objects.

Syntax strReturn = object.GetItem itemName

The GetItem method syntax has these parts:

Part Description

object Object expression that evaluates to a BatchServer or BatchRemote object.

strExecute (required) String representing an item supported by the FactoryTalk Batch Server application.

strReturn Data associated with the specified item.

Remarks The data for the item returns synchronously with this method. The FactoryTalk Batch Server waits, at most, a time period equal to the TimeoutPeriod property. If the server does not recognize an item string, then strReturn contains FAILED. If the timeout period expires before the data is collected internally to the FactoryTalk Batch Server, then strReturn contains TIMEOUT.

This code example is Visual Basic 6 syntax.

Example: Dimension a FactoryTalk Batch Server object and two strings: Dim svr As New BatchControl.BatchServer Dim strItem As String Dim strReturn As string

Set the item name to get the time item: strItem = "TIME"

Get the time from the server and display: strReturn = svr.GetItem(strItem) MsgBox strReturn

See also

TimeoutPeriod property on page 305

Available items on page 15



GetItem method

Object reference Appendix A


The Execute method sends an execute command to the FactoryTalk Batch Server and retrieves a response string. The Execute method applies to the BatchServer and BatchRemote objects.

Syntax strReturn = object.Execute strExecute

The Execute method syntax has these parts:

Part Description


strExecute (required) String representing an execute supported by the FactoryTalk Batch Server application.

strReturn Data associated with the specified item. (For the format of this data, refer to the appropriate execute.)

Remarks The data for the item returns synchronously with this method. The FactoryTalk Batch Server waits, at most, for a time period equal to the TimeoutPeriod property. If the server does not recognize an item string, then strReturn contains FAILED. If the timeout period expires before the data is collected internally to the FactoryTalk Batch Server, then strReturn contains TIMEOUT.


Example: Dimension a FactoryTalk Batch Server object and two strings: Dim svr As New BatchControl.BatchServer Dim strExecute As String Dim strReturn As String svr.TimeoutPeriod = 10000

Format an execute string. This example asks the FactoryTalk Batch Server to acquire resource ID number 1: strExecute = "ACQUIRE(response,user,0,1)"

Send the execute and print the response: strReturn = svr.Execute(strExecute) MsgBox strReturn

Message Box should display "SUCCESS:"

See also

TimeoutPeriod property on page 305

Available executes on page 19




Execute method



The CallTimeout property returns or sets a value indicating the number of milliseconds the object waits for the server to return requested data before assuming that communication with the server has been lost. The CallTimeout property applies to the BatchRemote object.

Syntax object.CallTimeout [= value]

The CallTimeout property syntax has these parts:

Part Description

object Object expression that evaluates to a previously defined BatchRemote.RemoteSupport object.

value Numeric expression indicating the number of milliseconds the object waits for the server to return requested data before assuming that communication with the server has been lost. The default is 1000.

Remarks The data for the item returns synchronously with this method. The FactoryTalk Batch Server waits, at most, for a time period equal to the TimeoutPeriod property. If the server does not recognize an item string, then strReturn contains FAILED. If the timeout period expires before the data is collected internally to the FactoryTalk Batch Server, then strReturn contains TIMEOUT.


Example: Dimension a remote FactoryTalk Batch Server object: Dim svr As New BatchRemote.RemoteSupport

Set the CallTimeout period: svr.CallTimeout = 5000

See also


CallTimeout property



The ConnectTimeout property returns or sets the number of milliseconds the control waits for the FactoryTalk Batch Server to acknowledge a connection before assuming that communication with the server cannot be established. The ConnectTimeout property applies to the BatchRemote object.

Syntax object.ConnectTimeout [= value]

The ConnectTimeout property syntax has these parts:

Part Description


value Numeric expression specifying the length of time, in milliseconds, that the control waits for the FactoryTalk Batch Server to acknowledge a connection before assuming that communication with the server cannot be established. The default is 5000.

Remarks Setting this property to a value less than one causes an error.



Set the ConnectTimeout period: svr.ConnectTimeout = 4000

See also


ConnectTimeout property



The Node property returns or sets the machine name or IP address of the specific computer running the FactoryTalk Batch Server application instance with which the control communicates. The default value is empty (a zero-length string). The Node property applies to the BatchRemote object.

Syntax object.Node [= text]

The Node property syntax has these parts:

Part Description


text String expression specifying the IP address or specific computer name.



Set the Node name: svr.Node = "STATION_1"

See also


Node property



The TimeoutPeriod property returns or sets the maximum time period that the FactoryTalk Batch Server client application should allow for responding to a data request. The TimeoutPeriod property applies to the BatchServer and BatchRemote objects.

Syntax object.TimeoutPeriod [= value]

The TimeoutPeriod property syntax has these parts:

Part Description


value Integer specifying the maximum time period that the FactoryTalk Batch Server should attempt to service a data request before giving up. The default is 5000.

Remarks The value is in milliseconds.


Example: Dimension a FactoryTalk Batch Server object: Dim svr As New BatchControl.BatchServer

Set the timeout period: svr.TimeoutPeriod = 1000

See also


TimeoutPeriod property



Use the FactoryTalk Batch Server methods at the command prompt. This is useful for trouble-shooting purposes.

Tip: If the item or execute command line contains any white space, such as tabs or spaces, be sure to enclose the command line in double-quotes. Otherwise, the Item or Execute can be issued as shown in this document.

When using the command prompt, change to the Batch/bin directory and format the Item or Execute commands similar to these examples:

Execute Syntax:

Execute ["]FormattedServerAPIExecuteString["] [options]

Options:

-a or /a enables the ASCII dump of data >filename places the data into a file

Example:

GetItem Syntax:

GetItem ["]ServerAPIItem["] [options]

Options:

-a or /a enables the ASCII dump of data and -t or /t removes any embedded time fields >filename places the data into a file

Command prompt



Example:

See also



Appendix B

Command and arbitration masks

Command and arbitration masks are used as flags to represent available FactoryTalk Batch commands. Commands that cause recipes or phases to change states are included in the Command Masks table. Commands that affect ownership of resources are included in the Arbitration Masks table.

See also



This table includes the individual commands used within the Command Masks table and their numeric values. The mask value in the Command Masks table is the sum of each of the commands’ decimal values.

Command Decimal

RESTART 256

STOP 4

ABORT 1

COMMAND MASK 261

See also

Command values on page 310

Command and arbitration masks on page 309

Command masks

Appendix B Command and arbitration masks


This table includes the command values:

COMMAND DECIMAL BINARY HEX

ABORT 1 0000 0000 0000 0000 0001 0 0 0 0 1

HOLD 2 0000 0000 0000 0000 0010 0 0 0 0 2

STOP 4 0000 0000 0000 0000 0100 0 0 0 0 4

RESET 8 0000 0000 0000 0000 1000 0 0 0 0 8

PAUSE 16 0000 0000 0000 0001 0000 0 0 0 1 0

SEMIAUTO 32 0000 0000 0000 0010 0000 0 0 0 2 0

DOWNLOAD 64 0000 0000 0000 0100 0000 0 0 0 4 0

RESUME 128 0000 0000 0000 1000 0000 0 0 0 8 0

RESTART 256 0000 0000 0001 0000 0000 0 0 1 0 0

START 512 0000 0000 0010 0000 0000 0 0 2 0 0

AUTO 1024 0000 0000 0100 0000 0000 0 0 4 0 0

MANUAL 2048 0000 0000 1000 0000 0000 0 0 8 0 0

STEP 4096 0000 0001 0000 0000 0000 0 1 0 0 0

CLEARFAIL 8192 0000 0010 0000 0000 0000 0 2 0 0 0

REMOVE 16384 0000 0100 0000 0000 0000 0 4 0 0 0

BIND 32768 0000 1000 0000 0000 0000 0 8 0 0 0

DISCONNECT 65536 0001 0000 0000 0000 0000 1 0 0 0 0

CONNECT 131072 0010 0000 0000 0000 0000 2 0 0 0 0

BINDPHASE 262144 0100 0000 0000 0000 0000 4 0 0 0 0

TIMER-RESET 524288 1000 0000 0000 0000 0000 8 0 0 0 0

TIMER-COMPLETE 1048576 0001 0000 0000 0000 0000 0000 1 0 0 0 0 0

This table includes the masks and associated command:

MASK COMMANDS

0 No Commands Enabled

1 ABORT

5 STOP ABORT

7 STOP HOLD ABORT

32 SEMIAUTO

261 RESTART STOP ABORT

512 START

520 START RESET

560 START SEMIAUTO PAUSE

672 START RESUME SEMIAUTO

1024 AUTO

1056 AUTO SEMIAUTO

Command values

Command and arbitration masks Appendix B


MASK COMMANDS

1536 AUTO START

1664 AUTO START RESUME

2080 MANUAL SEMIAUTO

2081 MANUAL SEMIAUTO ABORT

2085 MANUAL SEMIAUTO STOP ABORT

2087 MANUAL SEMIAUTO STOP HOLD ABORT

2341 MANUAL RESTART SEMIAUTO STOP ABORT

3072 MANUAL AUTO

3073 MANUAL AUTO ABORT

3077 MANUAL AUTO STOP ABORT

3079 MANUAL AUTO STOP HOLD ABORT

3207 MANUAL AUTO RESUME STOP HOLD ABORT

3333 MANUAL AUTO RESTART STOP ABORT

4096 ASC

5152 ASC AUTO SEMIAUTO

8192 CLEAR FAIL

10272 CLEAR FAIL MANUAL SEMIAUTO

10273 CLEAR FAIL MANUAL SEMIAUTO ABORT

10277 CLEAR FAIL MANUAL SEMIAUTO STOP ABORT

10279 CLEAR FAIL MANUAL SEMIAUTO STOP HOLD ABORT

11264 CLEAR FAIL MANUAL AUTO

11265 CLEAR FAIL MANUAL AUTO ABORT

11269 CLEAR FAIL MANUAL AUTO STOP ABORT

11271 CLEAR FAIL MANUAL AUTO STOP HOLD ABORT

16392 REMOVE RESET

16928 REMOVE START SEMIAUTO

18472 REMOVE MANUAL SEMIAUTO RESET

18976 REMOVE MANUAL START SEMIAUTO

19464 REMOVE MANUAL AUTO RESET

19968 REMOVE MANUAL AUTO START

24608 REMOVE CLEARFAIL SEMIAUTO

26656 REMOVE CLEARFAIL MANUAL SEMIAUTO

26664 REMOVE CLEARFAIL MANUAL SEMIAUTO RESET

27648 REMOVE CLEARFAIL MANUAL AUTO

27656 REMOVE CLEARFAIL MANUAL AUTO RESET

32768 BIND

32769 BIND ABORT

32773 BIND STOP ABORT

32775 BIND STOP HOLD ABORT

32800 BIND SEMIAUTO

33029 BIND RESTART STOP ABORT



MASK COMMANDS

33280 BIND START

33288 BIND START RESET

33328 BIND START SEMIAUTO PAUSE

33440 BIND START RESUME SEMIAUTO

33792 BIND AUTO

33824 BIND AUTO SEMIAUTO

34304 BIND AUTO START

34432 BIND AUTO START RESUME

34848 BIND MANUAL SEMIAUTO

34849 BIND MANUAL SEMIAUTO ABORT

34853 BIND MANUAL SEMIAUTO STOP ABORT

34855 BIND MANUAL SEMIAUTO STOP HOLD ABORT

35109 BIND MANUAL RESTART SEMIAUTO STOP ABORT

35840 BIND MANUAL AUTO

35841 BIND MANUAL AUTO ABORT

35845 BIND MANUAL AUTO STOP ABORT

35847 BIND MANUAL AUTO STOP HOLD ABORT

35975 BIND MANUAL AUTO RESUME STOP HOLD ABORT

36101 BIND MANUAL AUTO RESTART STOP ABORT

36864 BIND ASC

37920 BIND ASC AUTO SEMIAUTO

40960 BIND CLEARFAIL

43040 BIND CLEARFAIL MANUAL SEMIAUTO

43041 BIND CLEARFAIL MANUAL SEMIAUTO ABORT

43045 BIND CLEARFAIL MANUAL SEMIAUTO STOP ABORT

43047 BIND CLEARFAIL MANUAL SEMIAUTO STOP HOLD ABORT

44032 BIND CLEARFAIL MANUAL AUTO

44033 BIND CLEARFAIL MANUAL AUTO ABORT

44037 BIND CLEARFAIL MANUAL AUTO STOP ABORT

44039 BIND CLEARFAIL MANUAL AUTO STOP HOLD ABORT

49160 BIND REMOVE RESET

49696 BIND REMOVE START SEMIAUTO

51240 BIND REMOVE MANUAL SEMIAUTO RESET

51744 BIND REMOVE MANUAL START SEMIAUTO

52232 BIND REMOVE MANUAL AUTO RESET

52736 BIND REMOVE MANUAL AUTO START

57376 BIND REMOVE CLEARFAIL SEMIAUTO

59424 BIND REMOVE CLEARFAIL MANUAL SEMIAUTO

59432 BIND REMOVE CLEARFAIL MANUAL SEMIAUTO RESET

60416 BIND REMOVE CLEARFAIL MANUAL AUTO

60424 BIND REMOVE CLEARFAIL MANUAL AUTO RESET



MASK COMMANDS

65536 DISCONNECT

65568 DISCONNECT SEMIAUTO

65569 DISCONNECT SEMIAUTO ABORT

65573 DISCONNECT SEMIAUTO STOP ABORT

65575 DISCONNECT SEMIAUTO STOP HOLD ABORT

65584 DISCONNECT SEMIAUTO PAUSE

65585 DISCONNECT SEMIAUTO PAUSE ABORT

65589 DISCONNECT SEMIAUTO PAUSE STOP ABORT

65591 DISCONNECT SEMIAUTO PAUSE STOP HOLD ABORT

65696 DISCONNECT RESUME SEMIAUTO

65697 DISCONNECT RESUME SEMIAUTO ABORT

65701 DISCONNECT RESUME SEMIAUTO STOP ABORT

65703 DISCONNECT RESUME SEMIAUTO STOP HOLD ABORT

65829 DISCONNECT RESTART SEMIAUTO STOP ABORT

65845 DISCONNECT RESTART SEMIAUTO PAUSE STOP ABORT

65957 DISCONNECT RESTART RESUME SEMIAUTO STOP ABORT

66104 DISCONNECT START SEMIAUTO PAUSE RESET

66216 DISCONNECT START RESUME SEMIAUTO RESET

66560 DISCONNECT AUTO

66561 DISCONNECT AUTO ABORT

66565 DISCONNECT AUTO STOP ABORT

66567 DISCONNECT AUTO STOP HOLD ABORT

66688 DISCONNECT AUTO RESUME

66689 DISCONNECT AUTO RESUME ABORT

66693 DISCONNECT AUTO RESUME STOP ABORT

66695 DISCONNECT AUTO RESUME STOP HOLD ABORT

66821 DISCONNECT AUTO RESTART STOP ABORT

66949 DISCONNECT AUTO RESTART RESUME STOP ABORT

67072 DISCONNECT AUTO START

67080 DISCONNECT AUTO START RESET

67208 DISCONNECT AUTO START RESUME RESET

73728 DISCONNECT CLEARFAIL

73729 DISCONNECT CLEARFAIL ABORT

73733 DISCONNECT CLEARFAIL STOP ABORT

73735 DISCONNECT CLEARFAIL STOP HOLD ABORT

73736 DISCONNECT CLEARFAIL RESET

73760 DISCONNECT CLEARFAIL SEMIAUTO

73761 DISCONNECT CLEARFAIL SEMIAUTO ABORT

73765 DISCONNECT CLEARFAIL SEMIAUTO STOP ABORT

73767 DISCONNECT CLEARFAIL SEMIAUTO STOP HOLD ABORT

74752 DISCONNECT CLEARFAIL AUTO



MASK COMMANDS

74753 DISCONNECT CLEARFAIL AUTO ABORT

74757 DISCONNECT CLEARFAIL AUTO STOP ABORT

74759 DISCONNECT CLEARFAIL AUTO STOP HOLD ABORT

74880 DISCONNECT CLEARFAIL AUTO RESUME

74881 DISCONNECT CLEARFAIL AUTO RESUME ABORT

74885 DISCONNECT CLEARFAIL AUTO RESUME STOP ABORT

74887 DISCONNECT CLEARFAIL AUTO RESUME STOP HOLD ABORT

81928 DISCONNECT REMOVE RESET

81960 DISCONNECT REMOVE SEMIAUTO RESET

82464 DISCONNECT REMOVE START SEMIAUTO

82952 DISCONNECT REMOVE AUTO RESET

83080 DISCONNECT REMOVE AUTO RESUME RESET

90120 DISCONNECT REMOVE CLEARFAIL RESET

90144 DISCONNECT REMOVE CLEARFAIL SEMIAUTO

98304 DISCONNECT BIND

98336 DISCONNECT BIND SEMIAUTO

98337 DISCONNECT BIND SEMIAUTO ABORT

98341 DISCONNECT BIND SEMIAUTO STOP ABORT

98343 DISCONNECT BIND SEMIAUTO STOP HOLD ABORT

98352 DISCONNECT BIND SEMIAUTO PAUSE

98353 DISCONNECT BIND SEMIAUTO PAUSE ABORT

98357 DISCONNECT BIND SEMIAUTO PAUSE STOP ABORT

98359 DISCONNECT BIND SEMIAUTO PAUSE STOP HOLD ABORT

98464 DISCONNECT BIND RESUME SEMIAUTO

98465 DISCONNECT BIND RESUME SEMIAUTO ABORT

98469 DISCONNECT BIND RESUME SEMIAUTO STOP ABORT

98471 DISCONNECT BIND RESUME SEMIAUTO STOP HOLD ABORT

98597 DISCONNECT BIND RESTART SEMIAUTO STOP ABORT

98613 DISCONNECT BIND RESTART SEMIAUTO PAUSE STOP ABORT

98725 DISCONNECT BIND RESTART RESUME SEMIAUTO STOP ABORT

98872 DISCONNECT BIND START SEMIAUTO PAUSE RESET

98984 DISCONNECT BIND START RESUME SEMIAUTO RESET

99328 DISCONNECT BIND AUTO

99329 DISCONNECT BIND AUTO ABORT

99333 DISCONNECT BIND AUTO STOP ABORT

99335 DISCONNECT BIND AUTO STOP HOLD ABORT

99456 DISCONNECT BIND AUTO RESUME

99457 DISCONNECT BIND AUTO RESUME ABORT

99461 DISCONNECT BIND AUTO RESUME STOP ABORT

99463 DISCONNECT BIND AUTO RESUME STOP HOLD ABORT

99589 DISCONNECT BIND AUTO RESTART STOP ABORT



MASK COMMANDS

99717 DISCONNECT BIND AUTO RESTART RESUME STOP ABORT

99840 DISCONNECT BIND AUTO START

99848 DISCONNECT BIND AUTO START RESET

99976 DISCONNECT BIND AUTO START RESUME RESET

106496 DISCONNECT BIND CLEARFAIL

106497 DISCONNECT BIND CLEARFAIL ABORT

106501 DISCONNECT BIND CLEARFAIL STOP ABORT

106503 DISCONNECT BIND CLEARFAIL STOP HOLD ABORT

106504 DISCONNECT BIND CLEARFAIL RESET

106528 DISCONNECT BIND CLEARFAIL SEMIAUTO

106529 DISCONNECT BIND CLEARFAIL SEMIAUTO ABORT

106533 DISCONNECT BIND CLEARFAIL SEMIAUTO STOP ABORT

106535 DISCONNECT BIND CLEARFAIL SEMIAUTO STOP HOLD ABORT

107520 DISCONNECT BIND CLEARFAIL AUTO

107521 DISCONNECT BIND CLEARFAIL AUTO ABORT

107525 DISCONNECT BIND CLEARFAIL AUTO STOP ABORT

107527 DISCONNECT BIND CLEARFAIL AUTO STOP HOLD ABORT

107648 DISCONNECT BIND CLEARFAIL AUTO RESUME

107649 DISCONNECT BIND CLEARFAIL AUTO RESUME ABORT

107653 DISCONNECT BIND CLEARFAIL AUTO RESUME STOP ABORT

107655 DISCONNECT BIND CLEARFAIL AUTO RESUME STOP HOLD ABORT

114696 DISCONNECT BIND REMOVE RESET

114728 DISCONNECT BIND REMOVE SEMIAUTO RESET

115232 DISCONNECT BIND REMOVE START SEMIAUTO

115720 DISCONNECT BIND REMOVE AUTO RESET

115848 DISCONNECT BIND REMOVE AUTO RESUME RESET

122888 DISCONNECT BIND REMOVE CLEARFAIL RESET

122912 DISCONNECT BIND REMOVE CLEARFAIL SEMIAUTO

See also




This table includes the arbitration masks:

Mask value Valid command

0 No Commands Enabled

1 ACQUIRE

2 RELEASE

4 REORDER

5 ACQUIRE, REORDER

6 RELEASE, REORDER

See also


Command and arbitration masks on page 309

Arbitration masks


Appendix C

Valid states and modes

Valid states and modes:

Valid states

READY, IDLE, RUNNING, RESTARTING, HOLDING, HELD, STOPPING, STOPPED, ABORTING, ABORTED, and COMPLETE.

Valid modes

O_AUTO The batch is sequencing normally. The operator can send commands to a recipe level that is in the O_AUTO mode. O_AUTO is a valid mode for all recipe levels.

P_AUTO The batch is sequencing normally. The operator cannot send commands to a recipe level that is in the P_AUTO mode. P_AUTO is a valid mode for all recipe levels.

S_AUTO The batch is sequencing normally, but pauses at a True transition and waits for the RESUME command. The operator can only issue a RESUME command to a recipe level that is in the S_AUTO mode. S_AUTO is a valid mode for all recipe levels.

MANUAL The automatic sequencing of the batch is stopped, allowing the operator to issue an Active Step Change command or command a lower recipe level. The operator can only issue the Active Step Change command to a recipe level that is in the MANUAL mode. MANUAL is not a valid mode for the phase level.

See also



Appendix D

FactoryTalk Batch Server API glossary

arbitration

A form of coordination control that determines how a resource should be allocated when there are more requests for the resource than can be accommodated at one time.

Dynamic Data Exchange (DDE)

A form of inter-process communication. When two or more programs that support DDE are running simultaneously, they can exchange information and commands.

execution

The performance of an operation accomplished through processing an instruction, a series of instructions, or a complete program.

mask

A binary value with its bits set to a pattern. The pattern selectively screens out or lets through certain bits, in a data value, to specify the bits to be operated in generating a masking result value.

resource list

When the perspective is resource in the Arbitration Focus window, the roster of resources is the resource list.

resource

A general term for equipment including process cells, units, phases, and shared control modules.


Legal Notices

Copyright notice

© 2017 Rockwell Automation Technologies, Inc. All rights reserved. Printed in USA.

This document and any accompanying Rockwell Software products are copyrighted by Rockwell Automation Technologies, Inc. Any reproduction and/or distribution without prior written consent from Rockwell Automation Technologies, Inc. is strictly prohibited. Please refer to the license agreement for details.

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 on your hard drive.

Trademark Notices

Allen-Bradley, CompactLogix, ControlLogix, Connected Components Workbench, eProcedure, FactoryTalk, GuardLogix, GuardPLC, Micro800, MicroLogix, MobileView, MobileView Guard, PanelBuilder, PanelView, PhaseManager, PlantLink, PlantPAx, PLC-2, PLC-3, PLC-5, PowerMonitor, RSBizWare, RSBizWare BatchHistorian, RSBizWare Historian, RSBizWare MaterialTrack, RSLinx, Rockwell Automation, Rockwell Software, SLC, SoftLogix, Studio 5000, and XMare trademarks of Rockwell Automation, Inc.

Any Rockwell Automation software or hardware not mentioned here is also a trademark, registered or otherwise, of Rockwell Automation, Inc.

For a complete list of products and their respective trademarks, go to: http://www.rockwellautomation.com/rockwellautomation/legal-notices/overview.page?#tab4

Legal Notices

http://www.rockwellautomation.com/rockwellautomation/legal-notices/overview.page?%23tab4


Legal Notices


Warranty

This product is warranted in accordance with the product license. The product’s performance may be affected by system configuration, the application being performed, operator control, maintenance, and other related factors. Rockwell Automation is not responsible for these intervening factors. The instructions in this document do not cover all the details or variations in the equipment, procedure, or process described, nor do they provide directions for meeting every possible contingency during installation, operation, or maintenance. This product’s implementation may vary among users.

This document is current as of the time of release of the product; however, the accompanying software may have changed since the release. Rockwell Automation, Inc. reserves the right to change any information contained in this document or the software at any time without prior notice. It is your responsibility to obtain the most current information available from Rockwell when installing or using this product.

Environmental compliance

Rockwell Automation maintains current product environmental information on its website at http://www.rockwellautomation.com/rockwellautomation/about-us/sustainability-ethics/product-environmental-compliance.page

Contact Rockwell Automation

Customer Support Telephone — 1.440.646.3434

Online Support — http://www.rockwellautomation.com/support/

http://www.rockwellautomation.com/rockwellautomation/about-us/sustainability-ethics/product-environmental-compliance.page


http://www.rockwellautomation.com/support/


A Ack 196 AddEvent 198 AddEvent_CI 199 AddEvent_Instruction 200 AddEvent_Phase 201 Archiver 202 AutoBatchID_Info 203 AutoRemove 204

B BadTagCount 22 Batch (execute) 205 BatchControl.BatchServer 11 BatchOverrides 25 BatchRemote object 12 BatchRemote.RemoteSupport 11, 265 BatchServer Object 12 Bind 207 BindPhase 208 BLBatchID_x 26 BLCMDMask_x 27 BLDesc_x 28 BLFailure_x 29 BLMode_x 30 BLRecipe_x 31 BLStartTime_x 32 BLState_x 33 BLType_x 34

C CallTimeout property 265 CancelSignature 210 COM interface 11 COMClientCount 35 Command (execute) 211 command masks 271 command prompt

use with BatchServer methods 267 ConnectTimeout property 266 conversation status 154 CreateIDBatchStepDataList 36 CreateIDBatchStepDataList2 40

CreateIDEventData 44 CreateIDScale 46

D DataServersList 46 DataServerStatistics 49 DCOM 11 Domains 51

E Enum 213 EquipmentModel 52 EventDataFiles 53 events

overview 11 Execute 12 Execute method 264 Expression 214 ExpressionID_UnitID_Values 54 ExpressionIDParamExprValues 55 ExpressionIDReportExprValue 56

F ForceTransition 215

G GetContainerData 216 GetFeedTypeAndMaterials 217 GetItem method 263 GetLegalEqModules 218 GetLegalUnits 220

H HyperlinkLabels 57

I IncompleteSignaturesCt 59 Info 222 InfoTrimmed 227 international settings 21, 195

Index

Index


internationalization 32, 154 ItemCount 60

L list separator 195 Locale 61 locality 32, 154 localized data 21, 195

M MANUAL 279 Messages (execute) 233 method

definition 11 methods

Execute 12, 264 GetItem 12, 263 overview 11

modes valid 279

Mtrl_Info 234

N Node property 266

O O_AUTO 279 object

BatchRemote 12 BatchRemote.RemoteSupport 11 classes

BatchControl.BatchServer 11 BatchRemote.RemoteSupport 11, 265

definition 11 event 11 method 11 property 11

OPCClientCount 62 Order 235 OwnerIDInfo. See ResourceIDInfo 137 OwnerIDOwned. See ResourceIDOwned 138 OwnerIDRequested. See ResourceIDRequested 139

P P_AUTO 279 ParamExpClear 236 ParamExpOverride 237 Parms 238 Parms2 239 Phase 240 Phase2 241 Phase3 242 PhaseErrs 69 PhaseErrsCt 70 PhaseIDFailure 71 PhaseIDMessage 72 PhaseIDParms 73 PhaseIDParms2 74 PhaseIDPhaseData 76 PhaseIDSS 80 PhaseIDStepIndex 81 PhasesList 82 PhasesList2 83 PhasesList3 84 ProcedureIDData 85 ProcedureIDData2 91 ProcedureIDData3 98 ProcedureIDDevLimits 105 ProcedureIDStatus 107 ProcedureIDStatus2 112 ProcedureIDUnitRequirements 118 ProcessCellIDUnits 120 ProcessCellsList2 122 properties

CallTimeout 265 ConnectTimeout 266 Node 266 overview 11 TimeoutPeriod 267

property definition 11

R ReactivateStep 245 RecipeDir 123 RecipeList 246 Release 247 Remove 248

Index


ResourceDataX 260 ResourceIDEqData 126 ResourceIDHyperlinks 137 ResourceIDOwned 138 ResourceIDOwners 139 ResourceIDRequested 139 ResourceIDRequesters 140 ResourcesList 142 ResourcesListX 259 RunMode 143

S S_AUTO 279 SetAllLot 250 StartTime 149 states

valid 279 StringLabels 151

T Tag_Verify 255 TagVerStatus 152 ThousandsSeparator 153 Time2 154 TimeoutPeriod property 267 TimerIDTimerData 155 TimerIDTimerStatus 158 TimerSteps 160

U UEArea_x 161 UEBatchID_x 162 UEDefault_x 163 UEDesc_x 164 UEEU_x 165 UEEvent_x 166 UEEventID_x 167 UEHigh_x 169 UELow_x 170 UEPhase_x 171 UEProcCell_x 172 UERecipe_x 173 UERespType_x 174 UETime_x 175

UEUnit_x 176 UEValue_x 177 UnAcknowledgedEvents 178 UnitBitMaps 181 UnitIDPhaseBitmaps 183 UnitIDPhases 183 UnitIDPhases2 184 UnitIDUnitTagData 185 UnitReqIDBindingPreferences 189 UnitReqIDBindingRequirements 191 UnitsList 192 User_Verify 256

V valid modes 279 valid states 279 Version 193

W Warning Message 194

X XML items

ResourceDataX 260 ResourcesListX 259

Reference Guide

FactoryTalk® Batch PCD Programmer Technical
















Rockwell Automation Publication FactoryTalk Batch PCD Programmer Technical Reference Guide - February 2017 3

Table of contents

Chapter 1

Document organization .................................................................................................... 11

Chapter 2

Batch manufacturing system ............................................................................................ 14 FactoryTalk Batch ...................................................................................................... 15 Phases ............................................................................................................................ 16

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

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

Chapter 3

Design philosophy .............................................................................................................. 22 FactoryTalk Batch requirements of the phase (PLI and phase logic) ...................... 23

Function of the PLI ................................................................................................... 23 Function of the phase logic ....................................................................................... 24

Chapter 4

State transition diagram .................................................................................................... 26 Phase states .................................................................................................................. 26

Active states ......................................................................................................... 27 Quiescent states .................................................................................................. 29

Communication protocol states .............................................................................. 30 State transitions .................................................................................................................. 31

Chapter 5

Phase logic API tags ........................................................................................................... 34 FactoryTalk Batch commands ......................................................................................... 35

PCD programming introduction

FactoryTalk Batch and PCD phase logic introduction

The FactoryTalk Batch – PCD interface

State transition logic

Tags and commands

Table of contents

4 Rockwell Automation Publication FactoryTalk Batch PCD Programmer Technical Reference Guide - February 2017

Chapter 6

Obey the state transition diagram ................................................................................... 38 Support the command handshake protocol.................................................................. 38

Command handshake protocol ............................................................................... 39 The command tag’s high byte .................................................................................. 40

Example - No command ID in high byte ....................................................... 40 Example - Command ID in high byte ............................................................ 42

Summary of the command handshake protocol .................................................. 45 Tags used in the command handshake protocol .......................................... 46

Follow the phase logic request protocol ......................................................................... 47 Phase logic request protocol ..................................................................................... 48

Example - Request tag immediately reset to zero ......................................... 49 Example - Request tag receives intermediate value ...................................... 52

Abort phase logic requests ........................................................................................ 55 Tags used in the phase logic request protocol ............................................... 56 Miscellaneous ...................................................................................................... 57

Support for Semi-Auto functionality ............................................................................. 57 Semi-Auto functionality ........................................................................................... 59

Tags used with the Semi-Auto functionality ................................................ 60 Support for the NEW_PARAMETERS command ................................................... 61

NEW_PARAMETERS command ........................................................................ 61 Tags used with the NEW_PARAMETERS command ............................. 62

Support for the Program/External attribute ................................................................ 63 Program/External attribute ...................................................................................... 63

Tags used with the Program/External attribute ........................................... 64 Support for the failure protocol ...................................................................................... 65 Support for the watchdog protocol ................................................................................ 66

Standard watchdog protocol .................................................................................... 67 Standard watchdog protocol problems .......................................................... 68

Enhanced watchdog protocol .................................................................................. 70 Watchdog period ........................................................................................................ 72

Tags used in the watchdog protocol ............................................................... 74 Tags used for state transitions .......................................................................................... 75 Optional PLI Boolean communication with the phase.............................................. 76 Tags used in the Failure protocol .................................................................................... 77

PLI communications protocols

Table of contents


Chapter 7

Download parameters ....................................................................................................... 81 Phase parameter tags array ........................................................................................ 82 Types of Download Parameter requests ................................................................ 83 All phase parameter values ........................................................................................ 83 Range of phase parameter values ............................................................................. 84 Range of phase parameter values - Indirect ........................................................... 85 Single phase parameter value .................................................................................... 86 Single phase parameter value - Indirect .................................................................. 86 Single phase parameter value - Specify location ................................................... 87 Single phase parameter value - Indirect/specify location ................................... 88 Subset of parameter values ........................................................................................ 89 Subset of parameter values – Download on Start ................................................ 89 Subset of parameter values – Download on TOC .............................................. 90

Download report limits ..................................................................................................... 90 Types of download Report Limits requests .......................................................... 91 All report limits information ................................................................................... 91 Download single report parameter limits configuration .................................... 91

Upload report values .......................................................................................................... 92 Report array ................................................................................................................. 93 Electronic batch record entries ................................................................................ 94 Types of upload report requests .............................................................................. 94 All report values .......................................................................................................... 94 Range of report parameter values ............................................................................ 95 Range of report values - Indirect ............................................................................. 96 Single report parameter value................................................................................... 97 Single report value - Indirect .................................................................................... 97 Single report parameter value - Specify location .................................................. 98 Single report parameter value - Indirect/specify location .................................. 99 Subset of report values ............................................................................................. 100 Subset of report parameter values - Upload on Terminal State ...................... 101 Subset of report values - Upload on TOC .......................................................... 101

Send messages to the operator and clear messages ..................................................... 102 Send message ............................................................................................................. 102 Send a message - Indirect ........................................................................................ 103 Clear message ............................................................................................................ 103

Acquire resources ............................................................................................................. 103 Types of acquire requests ........................................................................................ 104 Acquire a single resource ......................................................................................... 104 Acquire a single resource - Indirect ....................................................................... 104 Acquire multiple resources ..................................................................................... 105

Request data from the FactoryTalk Batch Server

Table of contents


Release resources ............................................................................................................... 105 Types of release requests ......................................................................................... 105 Release a single resource .......................................................................................... 106 Release a single resource - Indirect ........................................................................ 106 Release multiple resources ...................................................................................... 107 Release all currently acquired resources ............................................................... 107

Send messages to other phases ....................................................................................... 108 Completion of messages .......................................................................................... 108 Process Send and Receive messages ....................................................................... 109 Types of messages to other phases ......................................................................... 109 Send a message .......................................................................................................... 109 Send a message - Indirect ........................................................................................ 110 Send a message and wait .......................................................................................... 110 Send a message and wait - Indirect ........................................................................ 111 Send a message and wait for one receiver ............................................................. 112 Send a message and wait for one receiver - Indirect ........................................... 113

Cancel messages to other phases.................................................................................... 113 Types of cancel message requests ........................................................................... 114 Cancel a single message ........................................................................................... 114 Cancel a message - Indirect ..................................................................................... 114 Cancel all messages ................................................................................................... 115

Receive message from linked phases ............................................................................. 115 Receive a message from a linked phase ................................................................. 115 Receive a message from a linked phase - Indirect ............................................... 116

Abort request .................................................................................................................... 116 Download batch data ...................................................................................................... 117 Generate an electronic signature request ..................................................................... 118

General Signature request - Indirect ..................................................................... 118 Download material-based data ...................................................................................... 119

Chapter 8

Standard attributes ........................................................................................................... 122 Material standard attributes ................................................................................... 122 Lot standard attributes ............................................................................................ 123 Container standard attributes ............................................................................... 124

Custom attributes ............................................................................................................ 125 Material custom attribute fields ............................................................................ 125 Lot custom attribute fields ..................................................................................... 126 Container custom attribute fields ......................................................................... 126

Write a material phase ..................................................................................................... 127 Upload data constraints .......................................................................................... 130

Material server requests ................................................................................................... 130 Use the enhanced phase logic requests ................................................................. 131

Request data from the Material Server

Table of contents


Requests for data from the recipe execution environment ...................................... 133 Download data from container currently in use – 7801 request .................... 134 Download data from material in container currently in use – 7802 request 135 Download data from lot in container currently in use – 7803 request ......... 137 Upload container data into container currently in use – 7811 request ........ 139 Upload material data into material in container currently in use – 7812 request ......................................................................................................................... 141 Upload lot data into lot in container currently in use – 7813 request .......... 142

Identify the lot .................................................................................................. 143 Download the current binding’s container selection priority – 7821 request ...................................................................................................................................... 145 Upload a container selection priority for the current binding – 7822 request ...................................................................................................................................... 146 Download sufficient material data – 7831 request ........................................... 147

Requests for data from the material database ............................................................. 148 Download one attribute of a material - 80NN request series .......................... 149 Download lot attributes – 81NN request series ................................................ 150 Download container attributes – 83NN request series .................................... 152 Download container priority assignments – 84NN request series................. 153 Upload material attributes – 85NN request series ............................................ 155 Upload lot attributes – 86NN request series ...................................................... 157 Upload container attributes – 88NN request series ......................................... 159 Upload container priority assignments – 89NN request series ...................... 160

Chapter 9

About process modules ................................................................................................... 164 Unit ............................................................................................................................. 164 Phase ........................................................................................................................... 165 Control module ........................................................................................................ 165

Define tags ......................................................................................................................... 165 Define resources ............................................................................................................... 165 Modularization criteria ................................................................................................... 166

Purpose ....................................................................................................................... 166 Use ............................................................................................................................... 166 Portability .................................................................................................................. 167 Flexibility ................................................................................................................... 167 Independence ............................................................................................................ 167 Expansion ................................................................................................................... 167 Isolation ...................................................................................................................... 167 Physical process constraints .................................................................................... 168

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

Unit #2 phases ................................................................................................... 169

Modularize the process

Table of contents


Chapter 10

Allocate phase memory tags ........................................................................................... 172 Steps to allocate phase memory tags ..................................................................... 173 Phase memory tags ................................................................................................... 173 Parallel vs. sequential programming for phase logic .......................................... 175 Semi-Auto .................................................................................................................. 176 Pause............................................................................................................................ 177 Treat modules as objects ......................................................................................... 178

Modules of code ................................................................................................................ 179 Obey the state transition diagram ......................................................................... 180 Project-specific phase logic ..................................................................................... 181

Phase logic modules ......................................................................................................... 182 Running logic ............................................................................................................ 183 Holding logic ............................................................................................................. 185 Aborting logic ........................................................................................................... 186 Stopping logic ............................................................................................................ 187 Restarting logic ......................................................................................................... 189

Chapter 11

Communications interface ............................................................................................. 192 Required phase tags .................................................................................................. 193

Communication from the FactoryTalk Batch Server ............................................... 194 Communication from the phase logic ......................................................................... 195 Watchdog communication ............................................................................................ 198 PLI variables ...................................................................................................................... 198 Phase logic variables ......................................................................................................... 201 PLI configuration parameters ........................................................................................ 202 Program the PLI ............................................................................................................... 203

PLI response to watchdog event ............................................................................ 203 Process non-state commands and events for a phase ......................................... 204 PLI response to a CLEAR_FAILURE command ............................................. 204 PLI response to a REQ_COMPLETE command ............................................. 204 PLI response to a REQ_ABORTACK command ............................................ 205 PLI response to a REQ_ABORTFAIL command ............................................ 205 PLI response to a REQ_RESET command ........................................................ 205 PLI response to a REQ_FAILED command ...................................................... 206 PLI response to a SEMI_AUTO command ....................................................... 206 PLI response to a RESUME command ............................................................... 206 PLI response to a NEW_PARAMETERS command ...................................... 207

Program phase logic

Phase Logic Interface

Table of contents


PLI phase state processing ...................................................................................... 207 ABORTING ..................................................................................................... 207 HOLDING ....................................................................................................... 208 STOPPING ....................................................................................................... 209 RESTARTING ................................................................................................ 210 RUNNING ....................................................................................................... 211 HELD ................................................................................................................. 212 COMPLETE .................................................................................................... 213 STOPPED ......................................................................................................... 213 ABORTED........................................................................................................ 214 IDLE ................................................................................................................... 214

Appendix A

SFC graphical structures ................................................................................................. 215 SFC execution ................................................................................................................... 216 Rules for building an SFC .............................................................................................. 217 Benefits of an SFC ............................................................................................................ 217

Appendix B

Appendix C

Appendix D

Legal Notices ..................................................................................................................... 233

Build a sequential function chart

Tag naming conventions

Structured text phase template

Structured text full PLI example

Legal Notices Index


Chapter 1

PCD programming introduction

This document provides information and instructions about the FactoryTalk Batch - PCD interface design. It is intended to be used as a reference guide.

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)

See also

FactoryTalk Batch and PCD phase logic introduction on page 13

Document organization


Chapter 2

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 Logix5000 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.

See also

Batch manufacturing system on page 14

Chapter 2 FactoryTalk Batch and PCD phase logic introduction


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:

See also

FactoryTalk Batch on page 15

Phases on page 16

Basic control on page 20

HMI on page 20

Batch manufacturing system

FactoryTalk Batch and PCD phase logic introduction Chapter 2


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 four main components of FactoryTalk Batch:

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

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

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

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

See also


FactoryTalk Batch



Phases are programmed with the following two components:

• Phase logic interface (PLI)

• Phase logic

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.

See also


PLI on page 17

Phase logic on page 19

Phases



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.

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



A batch PLI consists of two components:

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

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

See also

Phases on page 16



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).

See also

Phases on page 16

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.

See also


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.

See also


Basic control

HMI


Chapter 3

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.

See also

Design philosophy on page 22

FactoryTalk Batch requirements of the phase (PLI and phase logic) on page 23

Chapter 3 The FactoryTalk Batch – PCD interface


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 expected to enforce the state transition diagram and the handshaking protocols.

See also

The FactoryTalk Batch – PCD interface on page 21

Design philosophy

The FactoryTalk Batch – PCD interface Chapter 3


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.

See also

The FactoryTalk Batch – PCD interface on page 21

Function of the PLI on page 23

Function of the phase logic on page 24

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 the FactoryTalk 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.

See also


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

Function of the PLI

Chapter 3 The FactoryTalk Batch – PCD interface


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.

See also


Function of the phase logic


Chapter 4

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.

See also

State transition diagram on page 26

State transitions on page 31

Chapter 4 State transition 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.

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

See also

Phase states on page 26

Communication protocol states on page 30

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

See also


State transition diagram

Phase states

State transition logic Chapter 4


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

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


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

Active states



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


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




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


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



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




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.




Quiescent states



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.

See also


PLI communications protocols on page 37

Communication protocol states



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.

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.

See also


State transitions


Chapter 5

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.

See also

Phase logic API tags on page 34

FactoryTalk Batch commands on page 35

Chapter 5 Tags and commands


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

See also

Tags and commands on page 33

Phase logic API tags

Tags and commands Chapter 5


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.

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.

FactoryTalk Batch commands

Chapter 5 Tags and commands



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:


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.

See also

Tags and commands on page 33


Chapter 6

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

See also

Support the command handshake protocol on page 38

Follow the phase logic request protocol on page 47

Support for the failure protocol on page 65

Support for the watchdog protocol on page 66

Chapter 6 PLI communications protocols


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.

See also


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.

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.

See also

Command handshake protocol on page 39

Summary of the command handshake protocol on page 45

Obey the state transition diagram

Support the command handshake protocol

PLI communications protocols Chapter 6


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 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.

See also


Command handshake protocol



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.

See also


Example - No command ID in high byte on page 40

Example - Command ID in high byte on page 42

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.

The command tag’s high byte

Example - No command ID in high byte



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.

See also

The command tag’s high byte on page 40

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 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.

Example - Command ID in high byte



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.

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.

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 see a change in the command tag’s value to report to the server.

See also

The command tag’s high byte on page 40

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 batch commands. In PLCs and similar devices, this can be done with masks. In DCS platforms, it may be easier to use the remainder function with a divisor of 256 to determine the command value.

2. As soon as a command is detected, clear the low byte of the command word to signal the FactoryTalk Batch Server that it is permissible to write another command into the command tag. In a PLC or similar device, this can be done in a straightforward manner. In a DCS, it may be easier to subtract the command value from the command tag. For example, if a START command (value 100) was received, the user would simply subtract 100 from the command tag to clear the command tag’s low byte.

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.

See also


Tags used in the command handshake protocol on page 46

Summary 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.

See also

Summary of the command handshake protocol on page 45

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 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.

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.

See also

Phase logic request protocol on page 48

Abort phase logic requests on page 55

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.

See also

Example - Request tag immediately reset to zero on page 49

Example - Request tag receives intermediate value on page 52

Phase logic request protocol



We once again face 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:

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.

Example - Request tag immediately reset 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 you can see, 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.

See also




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:




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.

Example - Request tag receives intermediate value



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 you can see from the above analysis, 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.

See also




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 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.

Abort phase logic requests



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.

See also

Tags used in the phase logic request protocol on page 56

Miscellaneous on page 57

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.

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)

See also


Tags used in the phase logic request protocol



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 the equipment ID from the REQDATA_1 memory tag and then acquires the resource 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.

See also


Request data from the FactoryTalk Batch Server on page 79

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.

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

Miscellaneous

Support for Semi-Auto functionality



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.

See also

Semi-Auto functionality on page 59



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, 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.

See also

Tags used with the Semi-Auto functionality on page 60

Semi-Auto functionality



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.

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.

See also

Semi-Auto functionality on page 59

Tags used with the Semi-Auto functionality



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.

See also

NEW_PARAMETERS command on page 61

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.

See also

Tags used with the NEW_PARAMETERS command on page 62

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.

See also

Support for the NEW_PARAMETERS command on page 61

Tags used with 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 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.

See also

Program/External attribute on page 63

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.

Support for the Program/External attribute

Program/External attribute



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.

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.

See also

Support for the Program/External attribute on page 63


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)

See also

Program/External attribute on page 63

Tags used with the Program/External attribute



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 will clear 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 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.

Support for the failure protocol



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.

See also


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.)

See also

Standard watchdog protocol on page 67

Enhanced watchdog protocol on page 70

Watchdog period on page 72

Support for the watchdog protocol



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.

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.

Standard watchdog protocol



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.

See also

Standard watchdog protocol problems on page 68

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 correctly 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.

Standard watchdog protocol problems



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 period of time that the polling data server 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.

See also

Standard Watchdog protocol on page 67



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.

Enhanced watchdog protocol



The following timeline illustrates how the enhanced 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 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.

See also




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 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:

Watchdog period



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.

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.

See also


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.

See also

Watchdog period on page 72

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)

See also


Tags used for state transitions



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)

See also


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.

See also


Tags used in the Failure protocol


Chapter 7

Request data from the FactoryTalk Batch Server

The request protocol is used as a means for phase logic to communicate with the FactoryTalk Batch Server. Much of the work involved with writing phase logic centers around defining a sequence of steps for a phase. Some of these 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 Logix5000 Controllers PhaseManager User Manual.

For example, the phase logic for a charge phase may perform the following 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 cause the server to notice 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.

Chapter 7 Request data from the FactoryTalk Batch Server


The sequence that the phase logic typically needs to follow is:

1. Prepare for request (set reports, for example)

2. Set any request parameters, if needed

3. 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 the following 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)

• 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)

See also

Download parameters on page 81

Request data from the FactoryTalk Batch Server Chapter 7


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.

See also


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.

See also


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

See also


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

See also


Types of Download Parameter requests

All 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

See also


Range of phase parameter values



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

This request is functionally identical to the previously described 11NN (or 111NN) request. 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

See also


Range of phase parameter values - Indirect



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

See also



This request is functionally identical to the previously described 12NN (or 112NN) request. 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 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

See also


Single phase parameter value

Single phase parameter value - Indirect



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_RQ 13NN (or 113NN) Request a single phase parameter value

PHASEQ01 >=1 Index into the phase parameter array

See also


Single phase parameter value - Specify location




This request is functionally identical to the previously described 13NN (or 113NN) request. 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:


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

See also


Single phase parameter value - Indirect/specify location



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_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

See also


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.

See also


Subset of parameter values

Subset of parameter values – Download on Start



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 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.

See also


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

See also


Subset of parameter values – Download on TOC

Download report limits



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

See also

Download report limits on page 90

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.

See also


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.

See also


Types of download Report Limits requests

All report limits information

Download single report parameter limits configuration



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.

See also


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.

See also

Upload report values on page 92

Report array



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

See also


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

See also


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.

See also


Electronic batch record entries

Types of upload report requests

All report values



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_RQ 21NN (or 121NN) Upload a range of report parameters

PHASEQ01 Report ID of 1st report

PHASEQ02 Index into the report array

See also


Range of report parameter values




This request is functionally identical to the previously described 21NN (or 121NN) request. 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, 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

See also


Range of report values - Indirect



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_RQ 22NN (or 122NN) Upload a single report parameter

See also



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_RQ 2200 (or 12200) Upload single report parameter

PHASEQ01 >=1 Report ID of report

See also


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_RQ 23NN (or 123NN) Upload a single report parameter


See also


Single report parameter value - Specify location




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_RQ 2300 (or 12300) Upload single report parameter


PHASEQ02 NN Report ID of report

See also


Single report parameter value - Indirect/specify location



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.

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_RQ 2500 (or 12500) Request a subset of report values.

PHASEQ01 >=1 or 2 Index into the report array.

See also


Subset of report values



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_RQ 2501 (or 12501) Request the Upload on Terminal State subset of report parameter values.

See also


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_RQ 2502 (or 12502) Request the Upload on TOC subset of parameter values.

See also


Subset of report parameter values - Upload on Terminal State

Subset of report values - Upload on TOC



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 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.

See also


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

See also

Send messages to the operator and clear messages on page 102

Send messages to the operator and clear messages

Send message



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_RQ 3000 (or 13000) Send a message to the operator

PHASEQ01 NN>=1 Message ID

See also


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

See also


During batch execution, phase logic can issue a request to the FactoryTalk Batch Server to acquire a pre-configured resource. Each resource configured 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.

See also


Send a message - Indirect

Clear message

Acquire resources



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.

See also

Acquire resources on page 103

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_RQ 40NN (or 140NN) Send a request to acquire a single resource

See also


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_RQ 4000 (or 14000) Acquire a single resource

PHASEQ01 >=1 Equipment ID

See also


Types of acquire requests

Acquire a single resource

Acquire a single resource - Indirect



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.

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


PHASE_RQ 41NN (or 141NN) Acquire multiple resources

PHASEQ01 >=1 Equipment ID to acquire



See also


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.

See also


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.

See also

Release resources on page 105

Acquire multiple resources

Release resources

Types of release requests



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_RQ 42NN (or 142NN) Release a single resource

See also


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.

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

See also


Release a single resource

Release a single resource - Indirect



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




See also


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

See also


Release multiple resources

Release all currently acquired resources



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 to ensure that multiple phases are in agreed upon states before they 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 that one phase of the synchronization group has passed a certain point in its phase logic before other phases can proceed.

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

See also


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.

See also

Send messages to other phases on page 108

Send messages to other phases

Completion of messages



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.

See also


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

See also

Send a message on page 109

Send a message and wait on page 110

Send a message and wait for one receiver on page 112

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


See also


Process Send and Receive messages

Types of messages to other phases

Send a message



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




See also


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.

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



See also


Send a message - Indirect

Send a message and wait



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


PHASEQ02 >=1 Number of receivers for which to wait




See also


Send a message and wait - Indirect



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.

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



See also


Send a message and wait for one receiver



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




See also


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.

See also

Types of cancel message requests on page 114

Cancel a single message on page 114

Cancel a message - Indirect on page 114

Cancel all messages on page 115

Send a message and wait for one receiver - Indirect

Cancel messages to other phases



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.

See also

Cancel messages to other phases on page 113

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.

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

See also


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


See also


Types of cancel message requests

Cancel a single message

Cancel a message - Indirect



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

See also


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.

See also

Receive a message from a linked phase on page 115

Receive a message from a linked phase - Indirect on page 116

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:


PHASE_RQ 55NN (or 155NN) Wait for a message from another phase




Cancel all messages

Receive message from linked phases

Receive a message from a linked phase



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




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

Receive a message from a linked phase - Indirect

Abort request



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:


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.

Download batch data



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:


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

Generate an electronic signature request

General Signature request - Indirect



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

See also

Request data from the Material Server on page 121

Download material-based data


Chapter 8

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 Logix5000 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 and containers.

• Custom Attributes: Custom attributes are the properties of the materials, 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. 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.

See also

Download parameter on page 81


Chapter 8 Request data from the Material Server


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

See also

Material standard attributes on page 122

Lot standard attributes on page 123

Container standard attributes on page 124

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

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

See also

Standard attributes on page 122

Standard attributes

Material standard attributes

Request data from the Material Server Chapter 8



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

See also


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


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

See also


Container standard attributes



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.

See also

Material custom attribute fields on page 125

Lot custom attribute fields on page 126

Container custom attribute fields on page 126


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


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

See also

Custom attributes on page 125

Custom attributes

Material custom attribute fields




ID Unique Primary Key for a lot attribute String 1 Read

Name Lot property name String 2 Read


Description Lot attribute description String 4 Read/Write



• 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

Value The attribute value. Real, Integer or String.

9 Read/Write

See also



ID Unique Primary Key for a container attribute String 1 Read

Name Container property name String 2 Read


Description Container attribute description String 4 Read/Write

EU Engineering Units for measuring the contents of the container String 5 Read


• Integer = 1

• String = 2

Integer 6 Read

Value The attribute value. Real, Integer or String.

7 Read/Write

See also


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 and FEED_COMPLETE report parameters. The sign of the value in the ACTUAL_AMOUNT report parameter must match the configured feed type: Additions are positive or zero; Distributions are negative or zero. Deviating from this results in an error and the batch being HELD.

Write a material phase



• The Automatic Upload/Download functionality can be used to meet this protocol requirement. When used, the AMOUNT parameter is downloaded by the FactoryTalk Batch Server before the phase is commanded to start and the ACTUAL_AMOUNT and FEED_COMPLETE report parameters is uploaded after the phase logic runs 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.

The following diagram is an example of a phase process:



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

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

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

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

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

6. The FEED_COMPLETE and ACTUAL_AMOUNT parameters are uploaded 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 execution will 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 the Material Server. The inventory levels in the material database are updated, and for material additions, the sublot or sublots of inventory used are identified.

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

See also

Upload data constraints on page 130



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 that may be changed at runtime will support uploading values.

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

See also


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 (or 178XX)

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

See also

Use the enhanced phase logic requests on page 131

Upload data constraints

Material server requests



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, which requests a download of data from the material database and asks for the improved phase logic request error handling.

2. The FactoryTalk Batch Server detects the 17801 request and attempts to access 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 the PHASE_OC tag of the equipment phase.

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

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

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

Use the enhanced phase logic requests



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.

See also

Material server requests on page 130



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:

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.

See also


Requests for data from the recipe execution environment



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.

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

Download data from container currently in use – 7801 request



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


7801 (or 17801) 1017 4 4323

See also



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


Phase_RQ 7802 (or 17802) Download data about the current material inside the container currently in use


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:


MATERIALS CAUSTIC

AMOUNT 100

CONTAINER DRY_BIN1

LOT ABC-123

LABEL --

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



Material Standard Attributes (subset)

Attribute Name ID Name Controller ID Description EU

Attr. Index 1 2 3 4 5

Value 36428736476 Caustic 2003 -- Lbs.

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


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


7802 (or 17802) 1007 1 3.5

See also





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


PhaseQ02 >0 The phase parameter tag number the value is to be downloaded into

Examples:

The recipe step is using the optional material-based parameters:


MATERIALS CAUSTIC

AMOUNT 100

CONTAINER DRY_BIN1

LOT ABC-123

LABEL --

Lot Standard Attributes (subset)


Attr. Index 1 2 3 4 5

Value 3772836327 ABC-123 6473 -- lbs.

Download data from lot in container currently in use – 7803 request



Lot Custom Attributes

Property Name ID Name Controller ID

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


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


7803 (or 17803) 1009 3 3.35

See also





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.

Examples:

The recipe step is using the optional material-based parameters; their values are:


MATERIALS CAUSTIC

AMOUNT 100

CONTAINER DRY_BIN1

LOT ABC-123

LABEL --

Container Standard Attributes (subset)


Index 1 2 3 4 5

Value 53672635252 Tank101 25784 Non-Volatile lbs.


Property Name ID Name Controller ID Description EU Data Type Value

Index 1 2 3 4 5 6 7


1000 -- -- 1 (int) 3

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

Upload container data into container currently in use – 7811 request



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_RQ PhaseQ01 PhaseQ02 PhaseR08 Caustic’s Clean With Value

7811 (or 17811)

1017 8 4323 4323

See also





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_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

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)


Property Name

ID Name Controller ID Description EU Data Type Max Min

Index 1 2 3 4 5 6 7 8



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)

Upload material data into material in container currently in use – 7812 request



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_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.

See also



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.

See also

Identify the lot on page 143



Upload lot data into lot in container currently in use – 7813 request



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 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.

Identify the lot




Property Name ID Name Controller ID Description EU Data Type

Max Min Value

Index 1 2 3 4 5 6 7 8 9



Example 1: Upload an updated state value (index 11) for the Lot from Tag 13.


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_RQ PhaseQ01 PhaseQ02 PhaseR33 Caustic. Color.Value

7813 (or 17813)

1019 33 Green Green

See also





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


7821 (or 17821)

2 999 100

See also



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_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.


Example:

The container, Tank101, has a new selection priority of 95 in Tag 8 to be uploaded:


Phase_RQ PhaseQ01 PhaseQ02 PhaseR08 Selection Priority

7822 (or 17822)

8 999 95 95

See also



Upload a container selection priority for the current binding – 7822 request



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_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.


Tip: The FactoryTalk Batch Server will also, when running without the Material Server, return a ‘0’ or ‘1’ depending on when communication is lost.

Example:

The step requires 500 gallons of Material B, there is 1250 available across all the valid binding candidates.

Phase Tags Result


7831 (or 17831) 10 999 1

See also



Download sufficient material data – 7831 request



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

See also


Requests for data from the material database



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.

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.


Property Name

ID Name Controller ID Description EU Data Type

Max. Min.

Index 1 2 3 4 5 6 7 8



Download one attribute of a material - 80NN request series



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


8001 (or 18001)

2003 1008 999 3.1

See also



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



Download lot attributes – 81NN request series



Examples:

For the material Caustic, there exists a lot named ABC-123 that has the following standard attributes and custom attributes:

Lot Standard Attributes


ID 1 3772836327

Name 2 ABC-123


Description 4 --

EU 5 lbs.


Property Name

ID Name Controller ID Description EU Data Type Max. Min. Value

Index 1 2 3 4 5 6 7 8 9



Example 1: Download the lot’s EU attribute into tag 2.

Phase Tags Result


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


8103 (or 18103)

6473 1009 999 3.35

See also


Lot Custom Attribute fields on page 126



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.


Phase_RQ 83NN (or 183NN) Download Container Data to phase parameter tag number NN

PhaseQ01 >0 Container’s Controller ID



Examples:

There is a container, Tank101 that has the following standard attributes and custom attributes:

Container Standard Attributes


ID 1 53672635252

Name 2 Tank101


Description 4 Vessel for storing non-volatile materials

EU 5 lbs.



Index 1 2 3 4 5 6 7


1000 -- -- 1 (integer) 3

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

Download container attributes – 83NN request series



Example 1: Download the container’s Name attribute into tag 22.

Phase Tags Result


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


8304 (or 18304)

25784 1017 999 4323

See also



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.

Download container priority assignments – 84NN request series



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

See also





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.


Phase_RQ 85NN or 185NN Upload Material Data from report parameter tag number NN

PhaseQ01 >0 Material’s Controller ID



Examples:


Material Standard Attributes


ID 1 36428736476

Name 2 Caustic


Description 4 --

EU 5 lbs.

Classification 10 0 (raw)


Property Name

ID Name Controller ID Description EU Data Type Max. Min.

Property Index 1 2 3 4 5 6 7 8



Upload material attributes – 85NN request series



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.

See also





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



Examples:


Lot Standard Attributes


ID 1 36428736476

Name 2 Caustic


Description 4 --

EU 5 lbs.

State 11 0 (raw)


Property Name

ID Name Controller ID Description EU Data Type Max. Min. Value

Property Index

1 2 3 4 5 6 7 8 9



Upload lot attributes – 86NN request series



Example 1: Upload an updated state value (index 11) for the Lot from tag 13.


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

See also





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




Examples:

The container Tank101 has the following standard attributes and custom attributes:

Container Standard Attributes


ID 1 53672635252

Name 2 Tank101


Description 4 Vessel for storing non-volatile materials

EU 5 lbs.

Upload container attributes – 88NN request series





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_RQ PhaseQ01 PhaseQ02 PhaseQ03 PhaseR08 Caustic.Clean With. Value

8808 (or 18808)

25784 1017 999 4328 4328

See also



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


PhaseQ03 Positive or negative number

Feed Type: 1 = Addition 2 = Distribution

Upload container priority assignments – 89NN request series



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_RQ PhaseQ01 PhaseQ02 PhaseQ03 PhaseR02 Selection Priority

8902 (or 18902) 10001 20065 1 95 95

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_RQ PhaseQ01 PhaseQ02 PhaseQ03 PhaseR01 Selection Priority

8901 (or 18901) 10110 20222 2 70 70

See also




Chapter 9

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."

See also

About process modules on page 164

Define tags on page 165

Define resources on page 165

Modularization criteria on page 166

Identify the phases in the selected process on page 168

Chapter 9 Modularize the process


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

See also

Unit on page 164

Phase on page 165

Control module on page 165

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.

See also


About process modules

Unit

Modularize the process Chapter 9


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.

See also


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.

See also


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.

See also

Modularize the process on page 163

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.

See also


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

See also


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.

See also


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.

See also


Modularization criteria

Purpose

Use



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.

See also


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.

See also


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.

See also


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.

See also


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.

See also


Portability

Flexibility

Independence

Expansion

Isolation



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.

See also


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.

See also


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:

Physical process constraints

Identify the phases in the selected process

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 10

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.

See also



Define resources on page 165

Chapter 10 Program 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.

• Before allocating the phase memory tags, have a good understanding of 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.

See also


Allocate phase memory tags

Program phase logic Chapter 10


The following lists the steps necessary to allocate phase memory tags:

1. Identify the phase memory tags, including the number of array elements for the phase report values, phase parameter values, and request data values.

2. Assign the memory location and associate a symbol or a tag name to each memory location depending on the type of process controller being 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.

See also

Allocate phase memory tags on page 172

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

Paused Req [PHASE NAME]_PD

Owner Req [PHASE NAME]_W

Steps to allocate phase memory tags

Phase memory tags



Phase Memory Tag Recommended Naming Convention

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

See also




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.

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.

See also


Parallel vs. sequential programming for phase logic



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:

IF PHASE_P THEN

PHASE_PD:= TRUE;

END_IF;

The Paused flag is then used to disable the processing of the phase logic.

See also


Semi-Auto



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.

See also


Pause



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.

Phase logic to CM Communication

See also


Treat modules as objects



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.

Modules of Code in Phase Logic

See also

Obey the state transition diagram on page 180

Project-specific phase logic on page 181

Modules of code



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.

See also


Obey the state transition diagram



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

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 from previous status.

See also

Modules of code on page 179

Project-specific phase logic



An example phase, shown below, is used to illustrate the sequence in each phase logic module.

This section provides sequential function chart representations of the RUNNING, HOLDING, ABORTING, STOPPING and RESTARTING logic for the sample charge phase.

See also

Build a sequential function chart on page 215

Phase logic modules



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

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.

Running logic



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.

See also

Phase logic modules on page 182



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.

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.

See also


Holding logic



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.


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.

See also


Aborting logic



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.

See also




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.

Restarting logic




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

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.

See also



Chapter 11

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

See also


Support for the Watchdog protocol on page 66

Follow the phase logic request protocol on page 47

Support the Command Handshake Protocol on page 38

Chapter 11 Phase Logic Interface


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 Example

See also

Required phase tags on page 193

Communications interface

Phase Logic Interface Chapter 11


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

See also

Phase Logic Interface on page 191

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

See also

FactoryTalk Batch commands on page 35

Communication from the FactoryTalk Batch Server



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 recommended in the implementation of the PLI. The tag names shown here are used throughout this document.


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

Communication from the 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

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

See also

Required phase tags on page 193



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.

See also


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.


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.

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.

Watchdog communication

PLI variables




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.

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.

See also




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.


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_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 logic variables




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

See also


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.

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.

See also


PLI configuration parameters



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.

See also


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:

See also

Program the PLI on page 203

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;

See also


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;

See also


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;

See also


Process non-state commands and events for a phase

PLI response to a CLEAR_FAILURE command

PLI response to a REQ_COMPLETE command



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;

See also


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;

See also


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;

See also


PLI response to a REQ_ABORTACK command

PLI response to a REQ_ABORTFAIL command

PLI response to a REQ_RESET command



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;

See also


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;

See also


The RESUME command clears the PAUSED (_PD) flag.

Example: IF (PHASE_CD = 80) THEN PHASE_PD = FALSE;

ENDIF;

See also


PLI response to a REQ_FAILED command

PLI response to a SEMI_AUTO command

PLI response to a RESUME command



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;

See also


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.

See also


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;

See also

PLI phase state processing on page 207

PLI response to a NEW_PARAMETERS command

PLI phase state processing

ABORTING



While HOLDING, an ABORT or STOP command are acted upon as is a HOLD COMPLETE (_HC) from the phase logic.

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 PHASE_ST = 60; ENDIF;

ENDIF;

See also


HOLDING



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 PHASE_ST = 80; ENDIF; ENDIF;

See also


STOPPING



While RESTARTING, an ABORT, HOLD, or STOP command are acted upon as is a RESTART COMPLETE (_TC) from the phase logic.

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 PHASE_RQ[PHASE_NUM] := 6000; ENDIF; 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} 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

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 PHASE_RQ[PHASE_NUM] := 6000; ENDIF;

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;

See also


RESTARTING



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 PHASE_ST = 70; ENDIF;

ENDIF;

See also


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 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} 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 PHASE_RQ[PHASE_NUM] := 6000; ENDIF;

ENDIF;

See also


HELD



While COMPLETE, a RESET or MANUAL command is the only thing acted upon.

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

See also


While STOPPED, a RESET or MANUAL command is the only thing acted upon.

Example: 80: {STOPPED} 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

See also


COMPLETE

STOPPED



While ABORTED, a RESET or MANUAL command is the only thing acted upon.

Example: 90: {ABORTED} 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

See also


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

See also


ABORTED

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.

See also

SFC graphical structures on page 215

SFC execution on page 216

Rules for building an SFC on page 217

Benefits of an SFC on page 217

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.

SFC graphical structures

Appendix A Build a sequential function chart


OR Structure Represents decisions.

AND Structure Represents parallel procedures.

See also


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.

SFC execution

Build a sequential function chart Appendix A


Step 5 Step 6

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.

See also


The sequential function chart must follow a step - transition - step sequence.

See also


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

See also


Rules for building an SFC

Benefits of an SFC


Appendix B

Tag naming conventions

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.

Appendix B Tag naming conventions


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.

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

Structured text phase template

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 *) (******PUT THE TRANSITIONS OUT OF STEP 1 HERE*) (*IF CONDITIONX THEN*) PHASE_SI:= 2; (*END_IF*)

(1) The Single-Step attribute is set when the SEMI_AUTO command is received.

Appendix C Structured text phase template


ELSIF (PHASE_SI= 2) AND (NOT PHASE_PD) THEN (*PERFORM STEP 2*) (******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 *) (******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 STEP1 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; (******INSERT THIS CODE IF AFTER THIS STEP IS A PAUSE POINT*) (*IF PAUSE_COMMAND THEN PHASE_PD:= TRUE; END_IF;*) ELSIF (PHASE_SI= 2) AND (NOT PHASE_PD) THEN (*PERFORM STEP 2*) (******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 (*THIS PAUSES THE PHASE AFTER THIS STEP IF SINGLE STEP21 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; (****INSERT THIS CODE IF AFTER THIS STEP IS A PAUSE POINT*)

Structured text phase template Appendix C


(*IF PHASE_P THEN PHASE_PD:= TRUE; END_IF;*) ELSIF (PHASE_SI= 2) AND (NOT PHASE_PD) THEN (*PERFORM STEP 2*) (******PUT THE WORK FOR RUN STEP 2 HERE *)

(******PUT THE TRANSITIONS OUT OF STEP 2 HERE*) (*IF CONDITIONX THEN*) PHASE_SI:= 3; (*END_IF*) (*THIS PAUSES THE PHASE AFTER THIS STEP IF SINGLE STEP21 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; (******INSERT THIS CODE IF AFTER THIS STEP IS A PAUSE POINT*) (*IF PHASE_P THEN PHASE_PD:= TRUE; END_IF;*) ELSIF (PHASE_SI= 3) AND (NOT PHASE_PD) THEN (*PERFORM STEP 3*) (******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*) IF PHASE_SS THEN PHASE_PD:= TRUE; END_IF;


(******INSERT THIS CODE IF AFTER THIS STEP IS A PAUSE POINT*) (*IF PHASE_P THEN PHASE_PD:= TRUE; END_IF;*) ELSIF (PHASE_SI= 4) AND (NOT PHASE_PD) THEN (*PERFORM STEP 4*) (******PUT THE WORK FOR RUN STEP 4 HERE *) (******PUT THE TRANSITIONS OUT OF STEP 4 HERE*) (*IF CONDITIONX THEN*) PHASE_SI:= 5; (*END_IF*) (*THIS PAUSES THE PHASE AFTER THIS STEP IF SINGLE STEP22 IS ACTIVATED*) (***THIS CODE SHOULD BE DELETED IF SEMI-AUTO ISN’T ALLOWED

Appendix C Structured text phase template


AT THIS POINT*) IF PHASE_SS THEN PHASE_PD:= TRUE; END_IF; (******INSERT THIS CODE IF A PAUSE POINT IS AFTER THIS STEP *) (*IF PHASE_P THEN PHASE_PD:= TRUE; END_IF;*) ELSIF (PHASE_SI= 5) AND (NOT PHASE_PD) THEN (*PERFORM STEP 5*) PHASE_RQ:= 2000; (*UPLOAD ALL REPORTS*) (****ONLY WRITE ON TIME****) (******PUT THE WORK FOR RUN STEP 2 HERE *) (******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 will cause the phase logic to fail. Failures will hold batches according to configured Hold Propagation settings


Appendix D

Structured text full PLI example

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;

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 PHASE_ST[PHASE_NUM] := 80; ENDIF; 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]; PHASEQ02[PHASE_NUM] := PHASEB02[PHASE_NUM]; PHASEQ03[PHASE_NUM] := PHASEB03[PHASE_NUM]; PHASEQ04[PHASE_NUM] := PHASEB04[PHASE_NUM]; PHASEQ05[PHASE_NUM] := PHASEB05[PHASE_NUM]; ENDIF; ENDIF; ENDIF;

Structured text full PLI example Appendix D


{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 PHASE_ST[PHASE_NUM] := 70; ENDIF; 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 PHASE_RQ[PHASE_NUM] := 6000; ENDIF; 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_SI[PHASE_NUM] := PHASE_IS[PHASE_NUM]; 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]; PHASEB02[PHASE_NUM] := PHASEQ02[PHASE_NUM]; PHASEB03[PHASE_NUM] := PHASEQ03[PHASE_NUM]; PHASEB04[PHASE_NUM] := PHASEQ04[PHASE_NUM]; PHASEB05[PHASE_NUM] := PHASEQ05[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 PHASE_SB[PHASE_NUM] := PHASE_SI[PHASE_NUM]; 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_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; 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 PHASE_RQ[PHASE_NUM] := 10; ENDIF;

{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 PHASE_RQ[PHASE_NUM] := 20; ENDIF;



{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 PHASE_RQ[PHASE_NUM] := 30; ENDIF;

{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;


Legal Notices

Copyright notice





Trademark Notices




Legal Notices



Legal Notices


Warranty












1 1601

11601 91

A abort 35

complete 207 abort request 116 aborted 29, 214 aborting 27, 181, 207

logic 186 phase logic requests 55

acquire multiple resources 105 resources 103 single resource 104

acquire requests types 104

active states 27 all phase parameter values 83 all report parameter limits 91 all report parameters 94 allocating phase memory tags 172 AND structure 215 attribute ID 133

B basic control 20 Batch

Equipment Editor 15 Recipe Editor 15 Server 15 View 15

batch parameters download 117

boolean communication with the phase 76 boolean variables 219 BS_COMMAND 198 BS_REQUEST 198

C cancel

message indirect 114

message requests 114 message types 114 messages to other phases 113

canceling a message 114

indirect 114 all messages 115

clear message 103 CLEAR_REQUEST 201 clearfailure 35 COMMAND 198 command handshake protocol 39 communication

from the Batch Server 194 from the phase 195 interface 195 protocol states 30

communication failure with Server 131 communications interface 17, 192 complete 29, 213 completion of messages 108 container heel 124 control module 165 controller ID 121 custom attributes 121

D data transfer 108 define resources 165 define tags 165 download 198

batch parameters 117 on start 89 on TOC 89, 90 phase parameter types 83 phase parameter value requests 83

download on start 89

Index

Index


E electronic batch record entries 94 enhanced phase logic requests 131 enhanced watchdog protocol 70 equipment module 165 example phase

phase logic modules 182 EXT_COMMAND 198 EXT_REQUEST 198 external command tag 194 external request tag 194

F FAILURE 201 failure detection 181 failure number tag 195 failure tag 193 final step 215 follow the phase logic request protocol 47 function of the phase logic 24 function of the PLI 23

G general signature request

indirect 118

H heel

container 124 held 29, 212 high byte 40 HMI 20 hold 35 hold complete 208 HOLD_ACTIVE 202 HOLD_ON_WATCHDOG 202 HOLDING 27, 181, 208 holding logic 185 Human-Machine Interface 20

I identifying the phases in the selected process 168 idle 29, 214 IDLE_INIT 202 initial step 215 INITIAL_STEP 202 interface design 22

L logic

aborting 186

M material database 121 material database classifications 121 material phase 127

diagram 127 Material Server requests 130 message

cancel 114 indirect 114

cancel all 115 cancel to other phases 113 clear 103 send to other phase 109

indirect 110 send to other phase and wait 110

indirect 111 send to other phase and wait for one receiver 112

indirect 113 send to other phases 108 wait for message from another phase 115

indirect 116 messages

cancel 113 cancel all 115 to other phases, types 109

modularization criteria 166 modules of code in phase logic 179 multiple resources

acquiring 105

Index


N NEW_PARAMETERS command 61 newparameters 35

O obey the state transition diagram 38 OR structure 215 OWNER 198 owner tag 193, 194, 195

P P & ID drawing 168 PAUSE 198 pause tag 193, 195 PAUSED 198 paused tag 195 permissive 108 phase API tags 34 phase communication

data transfer 108 permissive 108 synchronization 108

phase components 16 phase logic

aborting 181, 186 failure detection 181 holding 181, 185 project specific 19 purpose 24 restarting 181 restarting logic 189 running 181, 183 stopping 181, 187

phase logic interface 191 phase logic modules 182 phase logic request protocol 48 phase logic requests

aborting 55 phase logic variables 201 phase logic, programming 171 phase memory tags 173

phase parameter download parameter types 83 download value requests 83

phase parameter tags array 82 phase parameters

request/range 84 request/single 86

phase tags 33 phase tags, required 193 PHASE_AC tag 201 PHASE_CD tag 198 PHASE_CR tag 201 PHASE_DL tag 198 PHASE_EC 194 PHASE_EC tag 198 PHASE_ER 194 PHASE_ER tag 198 PHASE_F 77, 193, 195 PHASE_F tag 201 PHASE_HA 202 PHASE_HC tag 201 PHASE_HI tag 198 PHASE_II 202 PHASE_IS 202 PHASE_OC 46, 56, 60, 62, 76, 77, 193, 194 PHASE_OC tag 198 PHASE_OR tag 198 PHASE_P 60, 193, 195 PHASE_P tag 198 PHASE_PD 60, 193, 195 PHASE_PD tag 198 PHASE_RB tag 198 PHASE_RC tag 201 PHASE_RE 202 PHASE_RQ 56, 62, 193, 194 PHASE_RQ tag 201 PHASE_RR tag 201 PHASE_SB tag 198 PHASE_SC tag 201 PHASE_SI 193, 195 PHASE_SI tag 201 PHASE_SS 60, 193, 195 PHASE_SS tag 198 PHASE_ST 75, 193, 195 PHASE_ST tag 198 PHASE_TC tag 201

Index


PHASE_UN 193, 194 PHASE_UN tag 198 PHASE_W 64, 193, 194, 195 PHASE_W tag 198 PHASE_WC 202 PHASEBXn tag 198 PHASEPNN 194 PHASEQ## 56, 62 PHASEQXn tag 201 PHASERNN 195 PKID 143 PLI 17, 191

multiple instances 17 purpose 23 single instance 17

PLI communications protocols 37 follow the phase logic request protocol 47 obey the state transition diagram 38 support program/external attribute 63 support semi-auto functionality 57 support the command handshake protocol 38 support the failure protocol 65 support the NEW_PARAMETERS command 61 support the watchdog protocol 66

PLI phase state processing 207 PLI response

to CLEAR_FAILURE command 204 to NEW_PARAMETER command 207 to REQ_ABORTACK command 205 to REQ_ABORTFAIL command 205 to REQ_COMPLETE command 204 to REQ_FAILED command 206 to REQ_RESET command 205 to RESUME command 206 to SEMI_AUTO command 206 to watchdog event 203

PLI variables 198 priority for selecting containers 121 process modules

control module 165 equipment module 165 unit 164

processing non-state commands and events for a phase 204 processing send and receive messages 109 program/external attribute 63 programming the PLI 203

project-specific phase logic 19, 181 protocol states

communication 30

Q quiescent states 29

R range of report parameters 95 REEXECUTE_HOLD 202 release requests, types 105 release resources 105 releasing a single resource 106 releasing all acquired resources 107 releasing multiple resources 107 report parameter array 93 report parameter requests, types 94 reqabortack 35 reqabortfail 35 reqcomplete 35 REQDATA_# 195 request 195, 201

1000 83 1100 85 11000 83 11100 85 111NN 84 11200 86 112NN 86 11300 88 113NN 87 11500 89 11501 89 11502 90 11NN 84 1200 86 12000 94 12100 96 121NN 95 12200 97 122NN 97 12300 99 123NN 98 12500 100 12501 101

Index


12502 101 12NN 86 1300 88 13000 103 130NN 102 13100 103 13NN 87 14000 104 140NN 104 141NN 105 14200 106 142NN 106 143NN 107 14400 107 1500 89 15000 110 1501 89 1502 90 150NN 109 15100 111 151NN 110 15200 113 152NN 112 15300 114 153NN 114 15400 115 15500 116 155NN 115 16000 116 171NN 117 172NN 117 173NN 117 174NN 117 175NN 117 17600 117 17700 117 17900 118 179NN 118 2000 94 2100 96 21NN 95 2200 97 22NN 97 2300 99 23NN 98 2500 100

2501 101 2502 101 3000 103 30NN 102 3100 103 4000 104 40NN 104 41NN 105 4200 106 42NN 106 43NN 107 4400 107 5000 110 50NN 109 5100 111 51NN 110 5200 113 52NN 112 5300 114 53NN 114 5400 115 5500 116 55NN 115 6000 116 71NN 117 72NN 117 73NN 117 74NN 117 75NN 117 7600 117 7700 117 7900 118 79NN 118

request data buffer 195 request register

reset to zero 79 request tag 195 REQUEST_BUFFER 198 requesting a range of phase parameters 84 requesting a single phase parameter 86 requesting a single phase parameter value 87 requesting all phase parameter values 83 requesting report parameters/all 94 requesting report parameters/range 95 requesting report parameters/single

specify location 98

Index


requesting subset of parameter values 89 download on start 89 download on TOC 90

requesting subset of report values 100 upload on terminal state 101 upload on TOC 101

requests abort request 116 acquire resources 103 acquiring resources/multiple 105 acquiring resources/single 104 cancel messages to other phases 113 canceling a message 114

indirect 114 canceling all messages 115 clear message 103 download batch parameters 117 enhanced phase logic 131 parameter subsets 89

download on start 89 download on TOC 90

phase parameters/all 83 phase parameters/range 84 phase parameters/single 86 release resources 105 releasing resources/all acquired 107 releasing resources/multiple 107 releasing resources/single 106 report parameters/all 94 report parameters/range 95 report parameters/single

specify location 98 report value subsets 100

upload on terminal state 101 upload on TOC 101

send message 102 send message to other phases 108 sending a message 109

indirect 110 sending a message and wait 110

indirect 111 sending a message and wait for one receiver 112

indirect 113 single phase parameter/specify location 87 upload report values 92 wait for message from another phase 115

indirect 116 RESET 35 resources

acquire 103 restart 35 restart complete 210 restarting 27, 181, 210 restarting logic 189 RESTORE_REQUEST 201 resume 35 rules for building an SFC 217 run complete 211 running 27, 211 running logic 183

S sample code 207 Selection Priority 153 semiauto 35 semi-auto functionality 59 send message 102 send message wait and receive message wait request pair 108 send messages to other phases 108 sending a message 109

indirect 110 sending a message and wait 110

indirect 111 sending a message and wait for one receiver 112

indirect 113 SFC execution 216 SFC graphical structures 215 single report parameter

specify location 98 single report parameter limits 91 single step tag 193, 195 single_step 35, 198 standard attributes 121 standard watchdog protocol 67 START 35

download on 89 state transition logic 17 state transitions 31 STATUS 198 status tag 195 step 215 step index tag 195

Index


STEP_BUFFER 198 STEP_INDEX 201 stop 35 stop complete 209 stopped 29, 213 stopping 27, 181, 209 stopping logic 187 structured text full PLI example 225 subset of parameter values 89

download on start 89 download on TOC 90

subset of report values 100 upload on terminal state 101 upload on TOC 101

support program/external attribute 63 support semi-auto functionality 57 support the command handshake protocol 38 support the failure protocol 65 support the NEW_PARAMETERS command 61 support the watchdog protocol 66 synchronization 108

T tag naming conventions 219 terminal state

upload on 100, 101 TOC

download on 89, 90 upload on 100, 101

transfer of control 35, 61, 92, 108, 198, 225 download on 89, 90

transition 215 transition logic 17

U unable to communicate with Material Server 131 unit 164, 198 unit tag 193, 194 upload on terminal state 100, 101 upload on TOC 100, 101 upload report values 92 using enhanced phase logic requests 131

V variables, PLI 198

W wait for a message from another phase 115

indirect 116 WATCHDOG 74 watchdog communication 198 watchdog protocol 72

enhanced 70 standard 67

WATCHDOG tag 198

Reference Guide

FactoryTalk® Batch System Files
















Rockwell Automation Publication FactoryTalk Batch System Files Reference Guide - February 2017 3

Table of contents

Chapter 1

Document organization ....................................................................................................... 5 Batch file type descriptions.................................................................................................. 6

Chapter 2

Area model file format ...................................................................................................... 10 Field definitions .................................................................................................................. 25

Chapter 3

Header table configuration .............................................................................................. 46 Recparam table configuration .......................................................................................... 49 Step table configuration .................................................................................................... 50 Recipeapprovalsteps table configuration ....................................................................... 51 Signaturetemplates table configuration ......................................................................... 51 Approvalsignoffs table configuration ............................................................................. 52 Securitypermissions table configuration ........................................................................ 53 Transition table configuration ........................................................................................ 54 Link table configuration ................................................................................................... 55 Formula table configuration ............................................................................................ 56 Transfer table configuration ............................................................................................ 58 Unitreq table configuration ............................................................................................. 59 Materialrequirements table configuration .................................................................... 60 Reportlimits table configuration ..................................................................................... 61 Bindpreferencespecifiers table configuration ............................................................... 62 Bindrequirementspecifiers table configuration ............................................................ 63 Textbox configuration ...................................................................................................... 64 LNF: language neutral format ......................................................................................... 65

Batch file types

Area model files

Recipe database (RDB) recipes

Table of contents

4 Rockwell Automation Publication FactoryTalk Batch System Files Reference Guide - February 2017

Chapter 4

Electronic batch record fields .......................................................................................... 67 Electronic batch record entries ........................................................................................ 69

End of batch entries ................................................................................................... 76 Electronic signatures .......................................................................................................... 77 Event journal signatures .................................................................................................... 77

Enable event journal signatures ............................................................................... 78 Verify the event journal ............................................................................................. 79

Legal Notices ....................................................................................................................... 81

Electronic batch records

Legal Notices Index


Chapter 1

Batch file types

This document provides technical information for the configuration and maintenance of a FactoryTalk Batch system and is a reference guide for implementation engineers and the system administrator.

See also

Document organization on page 5

Batch file type descriptions on page 6

This document contains detailed information on the structure and purpose of the various files used by the FactoryTalk Batch software.

Document organization

Chapter 1 Batch file types


FactoryTalk Batch uses a variety of input, output, and configuration files, each associated with a unique one- to four-letter file extension. The following is a description of all batch-specific files and file extensions, including files installed by or created by FactoryTalk Batch:

File extension File name Description

.axml Configuration Contains the area model structure for a single physical area. Created using FactoryTalk Batch Equipment Editor. XML format.

.bmp Bitmap Image Unit, Unit Backgrounds, Process Cell and Phase icons displayed in FactoryTalk Batch Equipment Editor are stored as bitmap images.

.bpc Procedure Contains the recipe structure for a single procedure level recipe. Created using FactoryTalk Batch Recipe Editor. Binary format.

.c Source Code Supports the building of client software in C or C++.

.cfg Configuration Contains the area model structure for a single physical area. Created using FactoryTalk Batch Equipment Editor.

.chm Help Displays the online help topics.

.cp Check Point Contains supplemental batch data for use during warm restarts with eProcedure.

.dat Data Contains supplemental batch data for use during FactoryTalk Batch Server warm restarts.

.dir Recipe Directory Contains a list of all recipes, created in the Rebuild Recipe Directory.

.dll Dynamic Link Library Extensions to the FactoryTalk Batch application programs (.exe files) that contain utility functions used between multiple applications.

.doc WordPad Document Contains the Readme document that contains information about using FactoryTalk Batch.

.dsdf Data Server Definition Contains configuration information for a specific type of data server used by FactoryTalk Batch. Every data server type must have a corresponding data server.

.eva Uploadable Image Contains a formatted record of batch events for a single batch, based on specified event filtering and formatting.

.evt Electronic Batch Record Contains a complete record of events for a single batch. Created by the FactoryTalk Batch Server during batch execution.

.fmt Report Formatting Contains information used by the report server to format uploadable image files and report text files. Created using FactoryTalk Batch Recipe Editor.

.h Header Supports the building of client software.

.ini Initialization Contains important configuration information used by a specified application upon startup.

.log Log Contains log entries pertaining to the activity of a particular FactoryTalk Batch component. Log files are created by FactoryTalk Event Archiver, FactoryTalk Batch Server, FactoryTalk Batch View, and upon installation of FactoryTalk Batch.

.ocx ActiveX Control Library A library of ActiveX controls for managing control recipes and the functions of the FactoryTalk Batch Server application.

.oxml Operation Contains the recipe structure for a single operation level recipe. Created using FactoryTalk Batch Recipe Editor. XML format.

Batch file type descriptions

Batch file types Chapter 1


File extension File name Description

.pxml Procedure Contains the recipe structure for a single procedure level recipe. Created using FactoryTalk Batch Recipe Editor. XML format.

.reg Registration Entry Registers a specific application or service in the Windows registry.

.sim Simulator Data file used by the FactoryTalk Batch Simulator.

.sql SQL Scripts SQL scripts used to create tables in SQL Server or Oracle.

.tlb Type Library Enables COM communication between FactoryTalk Batch components.

.txt Text Document Contains a document in ASCII text format viewed using Microsoft Notepad, WordPad, or another word processing application.

.uop Operation Contains the recipe structure for a single operation level recipe. Created using FactoryTalk Batch Recipe Editor. Binary format.

.upc Unit Procedure Contains the recipe structure for a single Unit Procedure level recipe. Created using FactoryTalk Batch Recipe Editor. Binary format.

.uxml Unit Procedure Contains the recipe structure for a single Unit Procedure level recipe. Created using FactoryTalk Batch Recipe Editor. XML format.

See also

Batch file types on page 5


Chapter 2

Area model files

The following is an example of the structure detail of an area model exported using FactoryTalk Batch Equipment Editor. The area model exports to a text file or an XML format (.axml). Use the same file format to import an area model file into FactoryTalk Batch Equipment Editor. The first line in the file is always blank with a carriage return or line feed (crlf). Between each configured component and the next component heading is another blank line with a carriage return or line feed.

Important: Use the XML format (.axml) when importing/exporting area models in FactoryTalk Batch Equipment Editor. The text file format is unsupported, not tested and used here for demonstration purposes only.

See also

Area model file format on page 10

Field definitions on page 25

Chapter 2 Area model files


The text file representation of the area model uses the following file format. An area model can be converted to XML. See the FactoryTalk Batch Equipment Editor User Guide for more information. Data items are described in a table following the area model representation. The fields are organized in the order that they appear within the text file of the area model.

Tip: <unique ID> is used for Logix Designer synchronization.

\crlf

<AREA STRUCTURE>

AREA \t NAME \t REVISION \crlf

<AREA>

\t <area model name> \t <area model revision number> \crlf

\crlf

<PROCESS CELL CLASS STRUCTURE>

PROCESS CELL CLASS \t NAME \t ICON PATH \crlf

<PROCESS CELL CLASSES> <NULL LIST> | <PROCESS CELL CLASS LIST>

where

<PROCESS CELL CLASS LIST> <PROCESS CELL CLASS> \crlf | <PROCESS CELL CLASS> \crlf <PROCESS CELL CLASS LIST>

where

<PROCESS CELL CLASS>

\t <process cell class name> \t <process cell icon path> \crlf

\crlf

<PROCESS CELL STRUCTURE>

PROCESS CELL \t NAME \t CLASS \t ID \t MAXOWNERS \t X \t Y \t GENERIC_STR1 \t GENERIC_STR2 \t GENERIC_STR3 \t GENERIC_STR4 \t GENERIC_STR5 \t ERP_ALIAS \t HYPERLINK1 \t HYPERLINK2 \t HYPERLINK3 \t HYPERLINK4 \t HYPERLINK5 \t UID \crlf

<PROCESS CELLS> <NULL LIST> | <PROCESS CELL LIST>

Area model file format

Area model files Chapter 2


where

<PROCESS CELL LIST> <PROCESS CELL> \crlf | <PROCESS CELL> \crlf <PROCESS CELL LIST>

where

<PROCESS CELL>

\t <process cell name> \t <class name of process> \t <process cell resource ID> \t <process cell max owners> \t <process cell X coordinate> \t <process cell Y coordinate> \t <process cell cross invocation string 1> \t <process cell cross invocation string 2> \t <process cell cross invocation string 3> \t <process cell cross invocation string 4> \t <process cell cross invocation string 5> \t <process cell ERP alias> \t <process cell hyperlink 1> \t <process cell hyperlink 2> \t <process cell hyperlink 3> \t <process cell hyperlink 4> \t <process cell hyperlink 5> \t <unique ID> \crlf

\crlf

<SERVER STRUCTURE>

SERVER \t NAME \t DSDF FILE NAME \t APPLICATION \t TOPIC \t WATCHDOG ITEM \t BADVALUE \t LCID \t WATCHDOG PROTOCOL \t READ ACCESS PATH \t READ ITEM NAME \t WRITE ITEM PATH \t WRITE ITEM NAME \t ON_CNTRL_SCANRATE \t OFF_CNTRL_SCANRATE \t LOCAL SERVER \t REMOTE SERVER LOC \t DEFAULT ACCESS PATH \t CIP FILE PATH \t CIP NETWORK PATH \t CIP TIMEOUT \t CIP RETRIES \t CONTROLLER TYPE \t LOGIX5000 REV \t DRIVER NAME \t RAW COMM PATH \t SYNC TIME \t SYNC STATUS \crlf

<SERVERS> <NULL LIST> | <SERVER LIST>

where

<SERVER LIST> <SERVER> \crlf | <SERVER> \crlf <SERVER LIST>

where

<SERVER>

\t <server name> \t <data server definition file name> \t <server application> \t <server topic> \t <server watchdog item> \t <server bad value> \t <server locale ID> \t <watchdog protocol> \t <watchdog read item access path> \t <watchdog read item name> \t <watchdog write item access path> t <watchdog write item name> \t <on control scan rate> \t <off control scan rate> t <local server> \t <remote server location> \t <default access path> \t < project file path> \t < controller network path > \t <controller timeout> \t <controller retries> \t <controller type> \t <controller revision> \t <driver name> \t <raw communication path> \t <CIP server synchronization time> \t <CIP server synchronization status> /crlf

\crlf

<RESOURCE CLASS STRUCTURE>

RESOURCE CLASS \t NAME \crlf



<RESOURCE CLASSES> <NULL LIST> | <RESOURCE CLASS LIST>

where

<RESOURCE CLASS LIST> <RESOURCE CLASS> \crlf | <RESOURCE CLASS> \crlf <RESOURCE CLASS LIST>

where

<RESOURCE CLASS>

\t <resource class name> \crlf

\crlf

<RESOURCE STRUCTURE>

RESOURCE \t NAME \t CLASS \t ID \t MAXOWNERS \t GENERIC_STR1 \t GENERIC_STR2 \t GENERIC_STR3 \t GENERIC_STR4 \t GENERIC_STR5 \t HYPERLINK1 \t HYPERLINK2 \t HYPERLINK3 \t HYPERLINK4 \t HYPERLINK5 \crlf

<RESOURCES> <NULL LIST> | <RESOURCE LIST>

where

<RESOURCE LIST> <RESOURCE> \crlf | <RESOURCE> \crlf <RESOURCE LIST>

where

<RESOURCE>

\t <resource name> \t <class name of resource> \t <resource ID> \t <resource max owners> \t <resource cross invocation string 1> \t <resource cross invocation string 2> \t <resource cross invocation string 3> \t <resource cross invocation string 4> \t <resource cross invocation string 5> \t <resource hyperlink 1> \t <resource hyperlink 2> \t <resource hyperlink 3> \t <resource hyperlink 4> \t <resource hyperlink 5> \crlf

\crlf

<TAG CLASS STRUCTURE>

TAG CLASS \t NAME \t TYPE \t ENUM SET \t GLOBAL\t DESCRIPTION \t TAG CLASS EU \crlf

<TAG CLASSES> <NULL LIST> | <TAG CLASS LIST>

where

<TAG CLASS LIST> <TAG CLASS> \crlf | <TAG CLASS> \crlf <TAG CLASS LIST>

where

<TAG CLASS>

\t <tag class name> \t <tag class type> \t <tag class enum set> \t <tag class description> \t <tag class engineering units> \crlf

\crlf <ENUMERATION SET STRUCTURE>



ENUMERATION SET \t NAME \t TYPE \crlf

<ENUMERATION SETS> <NULL LIST> | <ENUMERATION SET LIST>

where

<ENUMERATION SET LIST>

<ENUMERATION SET> \crlf | <ENUMERATION SET> \crlf <ENUMERATION SET LIST>

where

<ENUMERATION SET>

\t <enumeration set name> \t <enumeration set type> \crlf

\crlf

<ENUMERATION STRUCTURE>

ENUMERATION \t SET \t NAME \t VALUE \crlf

<ENUMERATIONS> <NULL LIST> | <ENUMERATION LIST>

where

<ENUMERATION LIST>

<ENUMERATION> \crlf | <ENUMERATION> \crlf <ENUMERATION LIST>

where

<ENUMERATION>

\t <enumeration type name> \t <enumeration name> \t <enumeration value> \crlf

\crlf

<UNIT CLASS STRUCTURE>

UNIT CLASS \t NAME \t ICON PATH \crlf

<UNIT CLASSES> <NULL LIST> | <UNIT CLASS LIST>

where

<UNIT CLASS LIST> <UNIT CLASS> \crlf | <UNIT CLASS> \crlf <UNIT CLASS LIST>

where

<UNIT CLASS>

\t <unit class name> \t <unit class icon path> \crlf

\crlf

<UNIT STRUCTURE>

UNIT \t NAME \t CLASS \t ID \t MAXOWNERS \t X \t Y \t GENERIC_STR1 \t GENERIC_STR2 \t GENERIC_STR3 \t GENERIC_STR4 \t GENERIC_STR5 \t ERP_ALIAS \t HYPERLINK1 \t HYPERLINK2 \t HYPERLINK3 \t HYPERLINK4 \t HYPERLINK5 \t DEFAULT SERVER \t UID \crlf

<UNITS> <NULL LIST> | <UNIT LIST>



where

<UNIT LIST> <UNIT> \crlf | <UNIT> \crlf <UNIT LIST>

where

<UNIT>

\t <unit name> \t <unit class> \t <unit resource ID> \t <unit max owners> \t <unit X coordinate> \t <unit Y coordinate> \t <unit cross invocation string 1> \t <unit cross invocation string 2> \t <unit cross invocation string 3> \t <unit cross invocation string 4> \t <unit cross invocation string 5> \t <unit erp alias> \t <unit hyperlink 1> \t <unit hyperlink 2> \t <unit hyperlink 3> \t <unit hyperlink 4> \t <unit hyperlink 5> \t <default server> \t <unique ID>3 \crlf

\crlf

<PHASE STRUCTURE>

PHASE \t NAME \t CATEGORY \t ICON PATH \t NO OF PARAMETER TAGS \t NO OF REPORT TAGS \t NO OF REQUEST TAGS \t MESSAGE PARTNERS \t TYPE \t TAG_LOCK \t SYSTEM_CREATED\crlf

<PHASES> <NULL LIST> | <PHASE LIST>

where

<PHASE LIST> <PHASE> \crlf | <PHASE> \crlf <PHASE LIST>

where

<PHASE>

\t <phase name> \t <phase category> \t <phase icon path> \t <number of parameter tags> \t <number of report tags> \t <number of request tags> \t <message partners> \t <phase type> \t <phase tag lock> \crlf

\crlf

<EQUIPMENT MODULE STRUCTURE>

EQUIPMENT MODULE \t NAME \t PHASE \t ID \t MAXOWNERS \t X \t Y \t GENERIC_STR1 \t GENERIC_STR2 \t GENERIC_STR3 \t GENERIC_STR4 \t GENERIC_STR5 \t ON_CNTRL_SCANRATE \t OFF_CNTRL_SCANRATE \t AUTO_UPDNLOAD_FLAGS \t AUTOMATED PHASE \t INSTRUCTION FILE \t ERP_ALIAS \t HYPERLINK1 \t HYPERLINK2 \t HYPERLINK3 \t HYPERLINK4 \t HYPERLINK5 \t UID \t CIPSERVER \t CIP_PARM_LIMIT_TAGS \t CIP_RPT_LIMIT_TAGS \crlf

<EQUIPMENT MODULES> <NULL LIST> | <EQUPMENT MODULE LIST>

where

<EQUIPMENT MODULE LIST> <EQUIPMENT MODULE> \crlf | <EQUIPMENT MODULE> \crlf <EQUIPMENT MODULE LIST>



where

<EQUIPMENT MODULE>

\t <equipment module name> \t <equipment module phase> \t <equipment module resource ID> \t <equipment module max owners> \t <equipment module X coordinate> \t <equipment module Y coordinate> \t <equipment module cross invocation string 1> \t <equipment module cross invocation string 2> \t <equipment module cross invocation string 3> \t <equipment module cross invocation string 4> \t <equipment module cross invocation string 5> \t <equipment module on-control scan rate> \t <equipment module off-control scan rate> \t <equipment module auto upload/download flags> \t <equipment module automated phase> \t <equipment module instruction file> \t <equipment module erp alias> \t <equipment module hyperlink 1> \t <equipment module hyperlink 2> \t <equipment module hyperlink 3> \t <equipment module hyperlink 4> \t <equipment module hyperlink 5> \t <unique ID>4 \t <CIP server name> \t <CIP parameter limit tag indication> \t <CIP report limit tag indication> \crlf

\crlf <SIGNATURE TEMPLATE STRUCTURE>

SIGNATURE TEMPLATE \t NAME \t INDEX \t LAST SIGNOFF \crlf

<SIGNATURE TEMPLATES> <NULL LIST> | <SIGNATURE TEMPLATE LIST>

where

<SIGNATURE TEMPLATE LIST> <SIGNATURE TEMPLATE> \crlf | <SIGNATURE TEMPLATE> \crlf <SIGNATURE TEMPLATE LIST>

where

<SIGNATURE TEMPLATE>

\t <signature template name> \t <signature template index> \t <signature template last signoff> \crlf

\crlf

<SIGNOFF STRUCTURE>

SIGNOFF \t NAME \t INDEX \t MEANING \t COMMENT \crlf

<SIGNOFFS> <NULL LIST> | <SIGNOFF LIST>

where

<SIGNOFF LIST> <SIGNOFF> \crlf | <SIGNOFF> \crlf <SIGNOFF LIST>

where

<SIGNOFF>

\t <signoff name> \t <signoff index> \t <signoff meaning> \t <signoff comment> \crlf



\crlf

<SIGNOFF PERMISSION STRUCTURE>

SIGNOFF PERMISSION \t NAME \t INDEX \t DomainOrComputer \t UserOrGroup \t UserIsGroup \crlf

<SIGNOFFS> <NULL LIST> | <SIGNOFF PERMISSION LIST>

where

<SIGNOFF PERMISSION LIST> <SIGNOFF PERMISSION> \crlf | <SIGNOFF PERMISSION> \crlf <SIGNOFF PERMISSION LIST>

where

<SIGNOFF PERMISSION>

\t <signoff permission name> \t <signoff permission index> \t <signoff permission domainorcomputer> \t <signoff permission userorgroup> \t <signoff permission userisgroup> \crlf

\crlf

<COMMAND STRUCTURE>

COMMAND VERIFICATION POLICY \t ABORT \t ACK \t AUTO \t BIND \t BIND AC \t FAI \t COMMENT \t DISCONNECT \t HOLD \t MANUAL \t PARAM CHANGE \t PAUSE \t REMOVE \t REACTIVE \t RESET \t RESTART \t RESUME \t SEMI AUTO \t SET LABELS \t SET LOTS \t START \t STEP \t STOP\t TIMER COMPLETE \t TIMER RESET \crlf

<COMMANDS> <NULL LIST> | <COMMAND LIST>

where

<COMMAND LIST> <COMMAND> \crlf | <COMMAND> \crlf <COMMAND LIST>

where

<COMMAND>

\t <command verification policy> \t <command abort> \t <command ack> \t <command auto> \t <command bind> \t <command bind ac> \t <command fail> \t <command comment> \t <command disconnect> \t <command hold> \t <command manual> \t <command param change> \t <command pause> \t <command remove> \t <command reactivate> \t <command reset> \t <command restart> \t <command resume> \t <command semi auto> \t <command set labels> \t <command set lots> \t <command start> \t <command step> \t <command stop> \crlf

\crlf

<GLOBAL UNIT BINDING REQUIREMENTS STRUCTURE>

GLOBAL UNIT BINDING REQUIREMENT \t EXPRESSION \crlf

<GLOBAL UNIT BINDING REQUIREMENTS> <NULL LIST> | <GLOBAL UNIT BINDING REQUIREMENT LIST>



where

<GLOBAL UNIT BINDING REQUIREMENT LIST> <GLOBAL UNIT BINDING REQUIREMENT> \crlf | <GLOBAL UNIT BINDING REQUIREMENT> \crlf <GLOBAL UNIT BINDING REQUIREMENT LIST>

where

<GLOBAL UNIT BINDING REQUIREMENT>\t <global unit binding requirement> \crlf

\crlf

<MESSAGE STRUCTURE>

MESSAGE \t NAME \t PHASE \t ID \t ARCHIVE \crlf

<MESSAGES> <NULL LIST> | <MESSAGE LIST>

where

<MESSAGE LIST> <MESSAGE> \crlf | <MESSAGE> \crlf <MESSAGE LIST>

where

<MESSAGE>

\t <message name> \t <message phase> \t <message ID> \t <message archive flag> \crlf

\crlf

<PARAMETER STRUCTURE>

PARAMETER \t NAME \t PHASE \t ID \t TYPE \t EU \t DEFAULT \t MIN \t MAX \t SCALE \t ENUMERATION SET \t DOWNLOAD_FLAGS \t VERIFICATION METHOD \t SCALE LIMIT \t NORMAL ACTION \t NORMAL_SIGNATURE \t HL_ACTION \t HL_SIGNATURE \t HIGH VALUE \t LOW VALUE \t HHLL_ACTION \t HHLL_SIGNATURE \t HIGH_HIGH VALUE \t LOW_LOW VALUE \t HHHLLL_ACTION \t HHHLLL_SIGNATURE TEMPLATE \t HHHLLL_HIGH \t HHHLLL_LOW \crlf

<PARAMETERS> <NULL LIST> | <PARAMETER LIST>

where

<PARAMETER LIST> <PARAMETER> \crlf | <PARAMETER> \crlf <PARAMETER LIMIT>



where

<PARAMETERS>

\t <parameter name> \t <parameter phase> \t <parameter ID> \t <parameter type> \t <parameter engineering units> \t <parameter default value> \t <parameter minimum value> \t <parameter maximum value> \t <parameter scalable flag> \t <parameter enumeration set name> \t <parameter download flags> \t <parameter verification method> \t <parameter scale limit> \t <parameter normal action> \t <parameter normal_signature> \t <parameter hl_action > \t <parameter hl_signature> \t <parameter high value> \t <parameter low value> \t <parameter hhll_action> \t <parameter hhll_signature> \t <parameter high_high value> \t <parameter low_low value> \t <parameter hhhlll_action> \t <parameter hhhlll_signature template> \t <parameter hhhlll_high> \t <parameter hhhlll_low> \crlf

\crlf

<REPORT STRUCTURE>

REPORT \t NAME \t PHASE \t ARCHIVE \t OPERATOR \t ID \t TYPE \t EU \t ENUMERATION SET \t UPLOAD_FLAGS \t VERIFICATION METHOD \t LIMIT CALCULATION \t TARGET PARAMETER \t SCALE LIMIT \t NORMAL ACTION \t NORMAL_SIGNATURE \t HL_ACTION \t HL_SIGNATURE \t HIGH VALUE \t LOW VALUE \t HHLL_ACTION \t HHLL_SIGNATURE \t HIGH_HIGH VALUE \t LOW_LOW VALUE \t HHHLLL_ACTION \t HHHLLL_SIGNATURE TEMPLATE \t HHHLLL_HIGH \t HHHLLL_LOW \t ERP_ALIAS \crlf

<REPORTS> <NULL LIST> | <REPORT LIST>

where

<REPORT LIST> <REPORT> \crlf | <REPORT> \crlf <REPORT LIST>



where

<REPORT>

\t <report parameter name> \t <report parameter phase> \t <report parameter archive flag> \t <report parameter operator flag> \t <report parameter ID> \t <report parameter type> \t <report parameter engineering units> \t <report parameter enumeration set> \t <report parameter upload flags> \t <report parameter verification method> \t <report parameter limit calculation> \t <report parameter target parameter> \t <report parameter scale limit> \t <report parameter normal action> \t <report parameter normal signature> \t <report parameter hl_action> \t <report parameter hl_signature> \t <report parameter high value> \t <report parameter low value> \t <report parameter hhll_action> \t <report parameter hhll_signature> \t <report parameter high_high value> \t <report parameter low_low value> \t <report parameter hhhlll_action> \t <report parameter hhhlll_signature template> \t <report parameter hhhlll_high> \t <report parameter hhhlll_low> \t <report parameter erp_alias> \crlf

\crlf

<CONTROL STRATEGY STRUCTURE>

CONTROL STRATEGY \t NAME \t PHASE \crlf

<CONTROL STRATEGIES> <NULL LIST> | <CONTROL STRATEGY LIST>

where

<CONTROL STRATEGY LIST> <CONTROL STRATEGY> \crlf | <CONTROL STRATEGY> \crlf <CONTROL STRATEGY LIST>

where

<CONTROL STRATEGY>

\t <control strategy name> \t <control strategy phase> \crlf

\crlf

<CONTROL STRATEGY PARAMETERS STRUCTURE>

CONTROL STRATEGY PARAMETERS \t NAME \t STRATEGY \t PHASE \t ID \t TYPE \t EU \t DEFAULT \t MIN \t MAX \t SCALE \t ENUMERATION SET \t DOWNLOAD_FLAGS \t VERIFICATION METHOD \t SCALE LIMIT \t NORMAL ACTION \t NORMAL_SIGNATURE \t HL_ACTION \t HL_SIGNATURE \t HIGH VALUE \t LOW VALUE \t HHLL_ACTION \t HHLL_SIGNATURE \t HIGH_HIGH VALUE \t LOW_LOW VALUE \t HHHLLL_ACTION \t HHHLLL_SIGNATURE TEMPLATE \t HHHLLL_HIGH \t HHHLLL_LOW \crlf



<CONTROL STRATEGY PARAMETERS> <NULL LIST> | <CONTROL STRATEGY PARAMETER LIST>

where

<CONTROL STRATEGY PARAMETER LIST> <CONTROL STRATEGY PARAMETER> \crlf | <CONTROL STRATEGY PARAMETER> \crlf <CONTROL STRATEGY PARAMETER LIST>

where

<CONTROL STRATEGY PARAMETER>

\t <control strategy parameter name> \t <control strategy parameter strategy> \t <control strategy parameter phase> \t <control strategy parameter ID> \t <control strategy parameter type> \t <control strategy parameter engineering units> \t <control strategy parameter default value> \t <control strategy parameter minimum value> \t <control strategy parameter maximum value> \t <control strategy parameter scale flag> \t <control strategy parameter enumeration set> \t <control strategy parameter download flags> \t <control strategy parameter verification method> \t <control strategy parameter scale limit> \t <control strategy parameter normal action> \t <control strategy parameter normal signature> \t <control strategy parameter hl_action> \t <control strategy parameter hl_signature> \t <control strategy parameter high value> \t <control strategy parameter low value> \t <control strategy parameter hhll_action> \t <control strategy parameter hhll_signature> \t <control strategy parameter high_high value> \t <control strategy parameter low_low value> \t <control strategy parameter hhhlll_action> \t <control strategy parameter hhhlll_signature template> \t <control strategy parameter hhhlll_high> \t <control strategy parameter hhhlll_low> \crlf

\crlf

<CONTROL STRATEGY REPORTS STRUCTURE>

CONTROL STRATEGY REPORTS \t NAME \t STRATEGY \t PHASE \t ARCHIVE \t OPERATOR \t ID \t TYPE \t EU \t ENUMERATION SET \t UPLOAD_FLAGS \t VERIFICATION METHOD \t LIMIT CALCULATION \t TARGET PARAMETER \t SCALE LIMIT \t NORMAL ACTION \t NORMAL_SIGNATURE \t HL_ACTION \t HL_SIGNATURE \t HIGH VALUE \t LOW VALUE \t HHLL_ACTION \t HHLL_SIGNATURE \t HIGH_HIGH VALUE \t LOW_LOW VALUE \t HHHLLL_ACTION \t HHHLLL_SIGNATURE TEMPLATE \t HHHLLL_HIGH \t HHHLLL_LOW \crlf

<CONTROL STRATEGY REPORTS> <NULL LIST> | <CONTROL STRATEGY REPORT LIST>



where

<CONTROL STRATEGY REPORT LIST> <CONTROL STRATEGY REPORT> \crlf | <CONTROL STRATEGY REPORT> \crlf <CONTROL STRATEGY REPORT LIST>

where

<CONTROL STRATEGY REPORT>

\t <control strategy report name> \t <control strategy report strategy> \t <control strategy report phase> \t <control strategy report archive flag> \t <control strategy report operator flag> \t <control strategy report ID> \t <control strategy report type> \t <control strategy report engineering units> \t <control strategy report enumeration set> \t <control strategy report upload flags> \t <control strategy report verification method> \t <control strategy report limit calculation> \t <control strategy report target parameter> \t <control strategy report scale limit> \t <control strategy report normal action> \t <control strategy report normal signature> \t <control strategy report hl_action> \t <control strategy report hl_signature> \t <control strategy report high value> \t <control strategy report low value> \t <control strategy report hhll_action> \t <control strategy report hhll_signature> \t <control strategy report high_high value> \t <control strategy report low_low value> \t <control strategy report hhhlll_action> \t <control strategy report hhhlll_signature template> \t <control strategy report hhhlll_high> \t <control strategy report hhhlll_low> \crlf

\crlf

<TAG STRUCTURE>

TAG \t NAME \t CLASS \t TYPE \t ENUM SET \t SERVER \t ITEM \t EQUIPMENT MODULE/UNIT \t READ ACCESS PATH \t READ ITEM NAME \t WRITE ITEM PATH \t WRITE ITEM NAME \t STATIC VALUE \t TAG EU \crlf

<TAGS> <NULL LIST> | <TAG LIST>

where

<TAG LIST> <TAG> \crlf | <TAG> \crlf <TAG LIST>

where

<TAG>

\t <tag name> \t <tag class> \t <tag data type> \t <tag enumeration set> \t <tag server name> \t <tag item name> \t <tag equipment module/unit> \t <read access path> \t <read item name> \t <write item path> \t <write item name> \t <tag static value> \t <tag engineering units> \crlf



\crlf

<UNIT FLOWPATH STRUCTURE>

UNIT FLOWPATH LIST \t NAME \t DESTINATION \crlf

<UNIT FLOWPATHS> <NULL LIST> | <FLOWPATH LIST>

where

<FLOWPATH LIST> <FLOWPATH> \crlf | <FLOWPATH> \crlf <FLOWPATH LIST>

where

<FLOWPATH>

\t <flowpath source unit> \t <flowpath destination unit> \crlf

\crlf

<PROCESS CELL UNITS STRUCTURE>

PROCESS CELL UNIT LIST \t NAME \t UNIT \crlf

<PROCESS CELL UNITS> <NULL LIST> | <PROCESS CELL UNIT LIST>

where

<PROCESS CELL UNIT LIST> <PROCESS CELL UNIT> \crlf | <PROCESS CELL UNIT> \crlf <PROCESS CELL UNITS>

where

<PROCESS CELL UNIT>

\t <process cell unit list process cell name> \t <process cell unit list unit name> \crlf

\crlf <UNIT EQUIPMENT NEEDED STRUCTURE>

UNIT EQUIPMENT NEEDED \t NAME \t EQUIPMENT \crlf

<UNIT EQUIPMENT NEEDED> <NULL LIST> | <UNIT EQUIPMENT NEEDED LIST>

where

<UNIT EQUIPMENT NEEDED LIST> <UNIT EQUIP NEEDED> \crlf | <UNIT EQUIP NEEDED> \crlf <UNIT EQUIPMENT NEEDED LIST>

where

<UNIT EQUIP NEEDED>

\t <unit equipment needed unit name> \t <unit equipment needed equipment name> \crlf

\crlf

<RESOURCE EQUIPMENT NEEDED STRUCTURE>

RESOURCE EQUIPMENT NEED \t NAME \t EQUIPMENT \crlf

<RESOURCE EQUIPMENT NEEDED> <NULL LIST> | <RESOURCE EQUIP NEEDED LIST>

where

<RESOURCE EQUIP NEEDED LIST> <RESOURCE EQUIP NEEDED> \crlf | <RESOURCE EQUIP NEEDED> \crlf <RESOURCE EQUIP NEED LIST>



where

<RESOURCE EQUIP NEEDED>

\t <resource equipment needed resource name> \t <resource equipment needed equipment name> \crlf

\crlf

<PROCESS CELL EQUIPMENT NEEDED STRUCTURE>

PROCESS CELL EQUIPMENT NEEDED \t NAME \t EQUIPMENT \crlf

<PROCESS CELL EQUIPMENT NEEDED> <NULL LIST> | <PROCESS CELL EQUIPMENT NEEDED LIST>

where

<PROCESS CELL EQUIPMENT NEEDED LIST> <PROCESS CELL EQUIP NEEDED> \crlf | <PROCESS CELL EQUIP NEEDED> \crlf <PROCESS CELL EQUIPMENT NEEDED LIST>

where

<PROCESS CELL EQUIP NEEDED>

\t <process cell equipment needed process cell name> \t <process cell equipment needed equipment name> \crlf

\crlf

<EQUIPMENT MODULE EQUIPMENT NEEDED STRUCTURE>

EQUIPMENT MODULE EQUIPMENT NEEDED \t NAME \t EQUIPMENT \crlf

<EQUIPMENT MODULE EQUIPMENT NEEDED> <NULL LIST> | <EQUIPMENT MODULE EQUIPMENT NEEDED LIST>

where

<EQUIPMENT MODULE EQUIPMENT NEEDED LIST> <EQUIPMENT MODULE EQUIP NEEDED> \crlf | <EQUIPMENT MODULE EQUIP NEEDED> \crlf <EQUIPMENT MODULE EQUIPMENT NEEDED LIST>

where

<EQUIPMENT MODULE EQUIP NEEDED>

\t <equipment module equipment needed equipment module name> \t <equipment module equipment needed equipment name> \crlf

\crlf

<UNIT EQUIPMENT MODULE STRUCTURE>

UNIT EQUIPMENT MODULE LIST \t NAME \t PHASE \t RESOURCE \crlf

<UNIT EQUIPMENT MODULES> <NULL LIST> | <UNIT EQUIPMENT MODULE LIST>

where

<UNIT EQUIPMENT MODULE LIST> <UNIT EQUIP MODULE> \crlf | <UNIT EQUIP MODULE> \crlf <UNIT EQUIPMENT MODULE LIST>



where

<UNIT EQUIP MODULE>

\t <unit equipment module list unit name> \t <unit equipment module list phase name> \t <unit equipment module list resource name> \crlf

\crlf

<CONTAINER ASSOCIATIONS STRUCTURE>

CONTAINER ASSOCIATIONS \t NAME \t EQUIPMENT MODULE \t RESOURCE \t FEED TYPE \t SUPPORTED FEED TYPE \crlf

<CONTAINER ASSOCIATIONS> <NULL LIST> | <CONTAINER ASSOCIATIONS LIST>

where

<CONTAINER ASSOCIATIONS LIST> <CONTAINER ASSOCIATION> \crlf |<CONTAINER ASSOCIATION> \crlf <CONTAINER ASSOCIATIONS LIST>

where

<CONTAINER ASSOCIATION>

\t <container name> \t <equipment module name> \t <container resource> \t <container feed type> \t <supported container feed type> \crlf

\crlf

<RECIPE APPROVAL PROCESS> <RECIPE APPROVAL STEP> <RECIPE APPROVAL STEP> <RECIPE APPROVAL STEP> <RECIPE APPROVAL STEP> <RECIPE APPROVAL STEP> <RECIPE APPROVAL STEP>

where

<RECIPE APPROVAL STEP>

\t<Name>\t<Id>\t<Required>\t<Approve Signature Template Name>\t<Revert Signature Template Name>\t<Description>\clrf

\clrf

<EXPEDITED APPROVAL PROCESS> <RECIPE APPROVAL STEP> <RECIPE APPROVAL STEP>

where

<RECIPE APPROVAL STEP>

\t<Name>\t<Id>\t<Required>\t<Approve Signature Template Name>\t<Revert Signature Template Name>\t<Description>\clrf

\clrf

<RECIPE APPROVALS PROCESS CONFIGURED>

\t<Configured>\clrf

\clrf



The following table defines the individual fields contained within the text file of the area model:

Data Description

Area

area model name The name of the area model, as assigned by the user.

area model revision number The version number of the area model, as assigned by the user.

Process Cell Classes

process cell class name The name of the process cell class defined in the PROCESS CELL CLASS record.

process cell icon path The name of the icon associated with the process cell class defined in the PROCESS CELL CLASS record, preceded by the letter C (for cell). Example: Cprocess0.bmp

Process Cells

process cell name The name of the process cell defined by the PROCESS CELL record.

class name of process cell The name of the process cell class to which the process cell defined by the PROCESS CELL record belongs. The named process cell class must also be found among the process cell classes defined in the PROCESS CELL CLASS records.

process cell resource ID This string represents an integer value that is the resource ID of the process cell defined by the PROCESS CELL record.

process cell max owners This string represents an integer value that defines the maximum number of owners of the process cell defined by the PROCESS CELL record.

process cell X coordinate This string represents an integer value that is the on-screen X coordinate of the process cell defined by the PROCESS CELL record.

process cell Y coordinate This string represents an integer value that is the on-screen Y coordinate of the process cell defined by the PROCESS CELL record.

process cell cross invocation string # Where # is a number 1 through 5. This is a cross invocation string associated with the PROCESS CELL record.

process cell erp alias An ERP alias string associated with the PROCESS CELL record.

process cell hyperlink # Where # is a number 1 through 5. This is a hyperlink string associated with the PROCESS CELL record.

unique ID Unique ID for the Process Cell (currently set to zero). For future use.

Servers

server name The name of the server as defined by the SERVER record.

data server definition file name The name of the Data Server Definition (DSDF) file that defines the data server type.

server application The DDE application name of the data server defined by the SERVER record.

server topic The DDE topic name of the server defined by the SERVER record.

server watchdog item The item name used for watchdog communication with the server defined by the SERVER record.

server bad value The bad value string used by the server defined by the SERVER record.

server locale ID This string represents an integer value that defines the locale ID of the server defined by the SERVER record.

Field definitions



Data Description

watchdog protocol This string represents an integer value that defines the watchdog protocol used to communicate with this data server. Valid values are:

• 0 – Standard

• 1 – Enhanced

watchdog read item access path The watchdog read item access path used for OPC communication.

watchdog read item name The watchdog read item name used for OPC communication.

watchdog write item access path The watchdog write item access path used for OPC communication.

watchdog write item name The watchdog write item name used for OPC communication.

on control scan rate This string represents an integer value that is the on-control scan rate used for communications with the defined OPC server.

off control scan rate This string represents an integer value that is the off-control scan rate used for communications with the defined OPC server.

local server This string represents an integer value that defines whether the specified data server definition file (DSDF) is located on the local machine or on a remote machine. Valid values are:

• 0 – Remote

• 1 – Local

remote server location The path and name of the remote machine where the data server definition file (DSDF) is located. Use either the UNC or DNS naming convention to specify the remote server location.

default server The currently assigned default data server.

default access path This sets item access paths.

project file path The full pathname of the Logix Designer project file (for CIP servers only).

controller network path The network path to the Logix Designer controller (for CIP servers only).

controller timeout The user-configured timeout for the Logix Designer controller (for CIP servers only). Valid values are 500 to 1000000 and are inclusive.

controller retries The user-configured retries for the Logix Designer controller (for CIP servers only). Valid values are: 4, 8, 16, 32, and 64.

controller type The type of Logix Designer controller (for CIP servers only).

controller revision The revision of the Logix Designer controller (for CIP servers only).

driver name The RSLinx Classic driver name. It is the first part of the controller network path (for CIP servers only).

raw communication path The internal (binary) version of the controller network path (for CIP servers only).

CIP server synchronization time The time of the last synchronization of this server with the project file indicated by the project file path (for CIP servers only). Valid values are date and time in the following format: yyyy.mm.dd HH:MM:SS When CIP server synchronization status is NEVER SYNCHRONIZED, the value is ----- (5 dashes).



Data Description

CIP server synchronization status The status of the last synchronization of this server with the project file indicated by the project file path (for CIP servers only). Valid values are:

• NEVER SYNCHRONIZED

• SUCCESSFUL

• INCOMPLETE.

Resource Classes

resource class name The name of the resource class defined in the RESOURCE CLASS record.

resource name The name of the resource defined by the RESOURCE record.

class name of resource The name of the resource class to which the resource defined by the RESOURCE record belongs. The named resource class must be located among the resource classes defined in the RESOURCE CLASS records.

resource ID This string represents an integer value that is the ID of the resource defined by the RESOURCE record.

resource max owners This string represents an integer value that is the maximum number of owners of the resource defined by the RESOURCE record.

resource cross invocation string 1 Where # is a number 1 through 5. This is a cross invocation string associated with the resource.

resource hyperlink # Where # is a number 1 through 5. This is a hyperlink string associated with the resource.

Tag Classes

tag class name The name of the tag class defined by the TAG CLASS record.

tag class type The type of the tag class defined by the TAG CLASS record. (INTEGER, ENUMERATION, REAL, or STRING)

tag class enum set The enumeration of the TAG CLASS record.

tag class global The global identification of the TAG CLASS record.

tag class description The description of the TAG CLASS record.

tag class engineering unit The engineering unit of the TAG CLASS record.

Enumeration Sets

enumeration set name The name of the enumeration set defined by the ENUMERATION SET record.

enumeration set type This string represents an integer value that defines the enumeration set type. Valid values are: • 0 – Normal

• 1 – System

• 2 – Control Strategy

• 3 – Material-Enabled

Enumerations

enumeration type name The name of the enumeration set of which the enumeration defined by the ENUMERATION record is a member. The named enumeration set must be located among the enumeration sets defined in the ENUMERATION SET records.

enumeration name The enumeration defined by the ENUMERATION record.

enumeration value This string represents an integer value that is the ordinal of the enumeration defined by the ENUMERATION record.



Data Description

Unit Classes

unit class name The name of the unit class defined by the UNIT CLASS record.

unit class icon path The name of the icon associated with the unit class defined in the UNIT CLASS record, preceded by the letter U (for unit). Example: Ufilter.bmp

Units

unit name The name of the unit defined by the UNIT record.

unit class The name of the unit class to which the unit defined by the UNIT record belongs. The named unit class must be located among the unit classes defined in the UNIT CLASS records.

unit resource ID This string represents an integer value that is the ID of the unit resource defined by the UNIT record.

unit max owners This string represents an integer value that is the maximum number of owners of the unit resource defined by the UNIT record.

unit X coordinate This string represents an integer value that is the X coordinate of the unit resource defined by the UNIT record.

unit Y coordinate This string represents an integer value that is the Y coordinate of the unit resource defined by the UNIT record.

unit cross invocation string # Where # represents a number 1 through 5. This is a cross invocation string associated with the unit.

unit erp alias This is an ERP alias associated with the unit.

unit hyperlink # Where # represents a number 1 through 5. This is a cross invocation string associated with the unit.

default data server User-configured default server assignment for any phases subsequently created under the unit.

unique ID The unique ID for the unit (currently set to zero). For future use.

Phases

phase name The name of the phase defined by the PHASE record.

phase category The category of the phase defined by the PHASE record.

phase icon path The name of the icon associated with the phase defined in the PHASE record, preceded by the letter P (for phase). Example: Pagitator.bmp

number of parameter tags This string represents an integer value that is the number of message parameter tags associated with the phase defined by the PHASE record.

number of report tags This string represents an integer value that is the number of report parameter tags associated with the phase defined by the PHASE record.

number of request tags This string represents an integer value that is the number of request parameter tags associated with the phase defined by the PHASE record.

message partners This string represents an integer value that is the number of message partners associated with the phase defined by the PHASE record.

phase type This string represents an integer value that defines the phase type. Valid values are: • 0 - Normal

• 1 - Control Strategy Enabled

• 2 - Material-Enabled



Data Description

phase tag lock This string represents an integer value that defines whether the tag lock functionality is enabled or disabled. Valid values are:

• 0 - Disabled

• 1 - Enabled

Equipment Modules

equipment module name The name of the phase or operation sequence defined by the EQUIPMENT MODULE record.

equipment module phase The phase or operation sequence defined by the EQUIPMENT MODULE record. The name must be located among the phases or operation sequences defined in the PHASE records.

equipment module resource ID The resource ID of the phase or operation sequence defined by the EQUIPMENT MODULE record.

equipment module max owners This string represents an integer value that is the maximum number of owners of the phase or operation sequence defined by the EQUIPMENT MODULE record.

equipment module X coordinate This string represents an integer value that is the X coordinate of the phase or operation sequence defined by the EQUIPMENT MODULE record.

equipment module Y coordinate This string represents an integer value that is the Y coordinate of the phase or operation sequence defined by the EQUIPMENT MODULE record.

equipment module cross invocation string #

Where # represents a number 1 through 5. This is a cross invocation string associated with the equipment module.

equipment module on control scan rate

This string represents an integer value that is the on-control scan rate used for communications with the defined OPC server.

equipment module off control scan rate

This string represents an integer value that is the off-control scan rate used for communications with the defined OPC server.

equipment module auto upload/download flags

This string represents an integer value that defines the auto upload/download flag for the phase. The default is 0 (zero).

equipment module automated phase This string indicates if the phase is automated or instruction based. • 0 = Instruction based

• 1 = Automated

equipment module instruction file The instruction file defined by the EQUIPMENT MODULE record.

equipment module erp alias This is an ERP alias associated with the phase.

equipment module hyperlink # Where # represents a number 1 through 5. This is a hyperlink string associated with the phase.

unique ID The unique ID for the unit set by synchronization with the associated Logix Designer server. This exported integer value is intended for debugging purposes only and is set to zero on importation (CIP phases only). Valid values are 0 to 4294967295 [232 -1]

CIP server name This is the name of the user-configured CIP server assigned to this phase or operation sequence (CIP phases or operation sequences only).

CIP parameter limit tag indication Indicates whether parameter limit tags are enabled for this phase (CIP phases only). Valid values are:

• TRUE

• FALSE



Data Description

CIP report limit tag indication Indicates whether report limit tags are enabled for this phase (CIP phases only). Valid values are:

• TRUE

• FALSE

Signature Templates

signature template name The name of the signature template defined by the SIGNATURE TEMPLATE record.

signature template index The unique integer index of the signature template defined by the SIGNATURE TEMPLATE record.

signature template last signoff The last signoff of the signature template defined by the SIGNATURE TEMPLATE record. Valid values are: • None

• 1

• 2

• 3

The default value is None.

Signoffs

signoff name The name of the signoff defined by the SIGNOFF record.

signoff index The unique integer index of the signoff defined by the SIGNOFF record.

signoff meaning The short phrase attached to a signoff that describes the signoff.

signoff comment The comment for the specific signoff defined by the SIGNOFF record. Comments are required or optional.

Signoff Permissions

signoff permission name The name of the signoff permission defined by the SIGNOFF PERMISSION record.

signoff permission index The unique integer index of the signoff permission defined by the SIGNOFF PERMISSION record.

signoff permission domainorcomputer The name of the domain or computer defined by the SIGNOFF PERMISSION record.

signoff permission userorgroup The name of the user or group defined by the SIGNOFF PERMISSION record.

signoff permission userisgroup Boolean value that identifies whether the signoff permission defined by the SIGNOFF PERMISSION record is a single user or a user group. TRUE = The Signoff Permission is defined for a user group. FALSE = The Signoff Permission is defined for a single user.

Commands

command verification policy abort The ABORT Command Verification Policy defined by the COMMAND record.

command verification policy ack The ACK Command Verification Policy defined by the COMMAND record.

command verification policy auto The AUTO Command Verification Policy defined by the COMMAND record.

command verification policy bind The BIND Command Verification Policy defined by the COMMAND record.

command verification policy bind ac The BIND ACK Command Verification Policy defined by the COMMAND record.

command verification policy clear fail The CLEAR FAIL Command Verification Policy defined by the COMMAND record.



Data Description

command verification policy comment The COMMENT Command Verification Policy defined by the COMMAND record.

command verification policy disconnect

The DISCONNECT Command Verification Policy defined by the COMMAND record.

command verification policy hold The HOLD Command Verification Policy defined by the COMMAND record.

command verification policy manual The MANUAL Command Verification Policy defined by the COMMAND record.

command verification policy param change

The PARAM CHANGE Command Verification Policy defined by the COMMAND record.

command verification policy pause The PAUSE Command Verification Policy defined by the COMMAND record.

command verification policy remove The REMOVE Command Verification Policy defined by the COMMAND record.

command verification policy reactivate step

The REACTIVATE Command Verification Policy defined by the COMMAND record.

command verification policy reset The RESET Command Verification Policy defined by the COMMAND record.

command verification policy restart The RESTART Command Verification Policy defined by the COMMAND record.

command verification policy resume The RESUME Command Verification Policy defined by the COMMAND record.

command verification policy semi auto The SEMI AUTO Command Verification Policy defined by the COMMAND record.

command verification policy set labels The SET LABELS Command Verification Policy defined by the COMMAND record.

command verification policy set lots The SET LOTS Command Verification Policy defined by the COMMAND record.

command verification policy start The START Command Verification Policy defined by the COMMAND record.

command verification policy step The STEP Command Verification Policy defined by the COMMAND record.

command verification policy stop The STOP Command Verification Policy defined by the COMMAND record.

command verification policy timer complete

The TIMER COMPLETE Command Verification Policy defined by the COMMAND record.

command verification policy timer reset

The TIMER RESET Command Verification Policy defined by the COMMAND record.

Global Unit Binding Requirements

expression The global unit binding requirements created by the user.

Messages

message name The name of the message defined by the MESSAGE record.

message phase The name of the phase with which the message defined by the MESSAGE record is associated. The named phase must be located among the phases defined in the PHASE records.

message ID This string represents an integer value that is the ID of the message defined by the MESSAGE record.

message archive flag This field is always populated with the string FALSE.

parameter name The name of the parameter defined by the PARAMETER record.

parameter phase The name of the phase or operation sequence with which the parameter defined by the PARAMETER record is associated. The name must be located among the phases or operation sequences defined in the PHASE records.

parameter ID This string represents an integer value that is the ID of the parameter defined by the PARAMETER record.



Data Description

parameter type The data type of the parameter defined by the PARAMETER record. Valid values are: • REAL

• INTEGER

• STRING

• ENUMERATION

parameter engineering units The engineering units of the parameter defined by the PARAMETER record.

parameter default value The default value of the parameter defined by the PARAMETER record.

parameter minimum value The minimum value of the parameter defined by the PARAMETER record.

parameter maximum value The maximum value of the parameter defined by the PARAMETER record.

parameter scalable flag This string represents a Boolean value that indicates whether the parameter defined by the PARAMETER record is scalable. A value of TRUE indicates that the value is scalable, while a value of FALSE indicates that the value is not scalable.

parameter enumeration set name The name of the enumeration set associated with the parameter defined by the PARAMETER record. This field is only necessary when the "parameter type" field has a value of ENUMERATION. When this field is required, the named enumeration set must be located among the enumeration sets defined in the ENUMERATION SET records.

parameter download flags This bitmask value defines the auto download flag for the parameter.

parameter verification method The type of verification method used for the specified parameter. Valid values are: • 0 = No_Limits

• 1 = High/Low Limits

• 2 = High-High/Low-Low Limits

• 3 = High-High-High/Low-Low-Low Limits

The default value is No_Limits.

parameter scale limit flag This flag determines whether the absolute limits scale with the batch scale for the specified parameter. The default value is set to OFF.

parameter normal action The enumerated value indicates the normal action type for the parameter. Valid values are: • 0:None

• 1:Signature Template

• 2:Not Allowed

parameter normal_signature This string indicates the Windows User Group allowed to sign.

parameter hl_action The enumerated value indicates the high-low action type for the parameter. Valid values are: • 0:None


• 2:Not Allowed

parameter hl_signature This string indicates the Windows User Group allowed to sign.

parameter high value The high limit of the parameter on the specified recipe phase.

parameter low value The low limit of the parameter on the specified recipe phase.



Data Description

parameter hhll_action The enumerated value indicates the high_high low_low action type for the parameter. Valid values are:

• 0:None


• 2:Not Allowed

parameter hhll_signature This string indicates the Windows User Group allowed to sign.

parameter high_high value The high_high limit of the parameter on the specified recipe phase.

parameter low_low value The low_low limit of the parameter on the specified recipe phase.

parameter hhhlll_action The enumerated value indicates the high_high_high low_low_low action type for the parameter. Valid values are:

• 0:None


• 2:Not Allowed

parameter hhhlll_signature template The signature template assigned to the high_high_high low_low_low verification method of the parameter.

parameter hhhlll_high The highest limit value in the high_high_high low_low_low range set for the parameter.

parameter hhhlll_low The lowest limit value in the high_high_high low_low_low range set for the parameter.

Reports

report parameter name The name of the report parameter defined by the REPORT record.

report parameter phase The name of the phase or operation sequence with which the report parameter defined by the REPORT record is associated. The name must be located among the phases or operation sequences defined in the PHASE records.

report parameter archive flag This string always holds the value FALSE.

report parameter operator flag This string always holds the value FALSE.

report parameter ID This string represents an integer value that is the ID of the report parameter defined by the REPORT structure.

report parameter type The data type of the report parameter defined by the REPORT record. Valid values are: • REAL

• INTEGER

• STRING

• ENUMERATION

report parameter engineering units The engineering units of the report parameter defined by the REPORT structure.

report parameter enumeration set The name of the enumeration set associated with the report parameter defined by the REPORT record. This field is only necessary when the report parameter type field has a value of ENUMERATION. When this field is required, the named enumeration set must be located among the enumeration sets defined in the ENUMERATION SET records.

report parameter upload flags This bitmask value defines the auto upload flag for the report parameter.



Data Description

report parameter verification method The type of verification method used for the specified report parameter. Valid values are: • 0 = No_Limits


• 2 = High_High/Low_Low Limits

• 3 = High_High_High/Low_Low_Low Limits


report parameter limit calculation The limit calculation defines how the verification method is calculated for the specified report parameter. Three types are supported for reports: • 0 = Absolute

• 1 = Percent

• 2 = Relative

report parameter target parameter The recipe report parameter's name used in the Percent or Relative limit calculation. Recipe parameter must be Real or Integer.

report parameter scale limit flag This flag determines whether the absolute limits scale with the batch scale for the specified report parameter. The default value is set to OFF.

report parameter normal action The enumerated value indicates the normal action type for the report parameter. Valid values are: • 0:None


• 2:Not Allowed

report parameter normal signature This string indicates the Windows User Group allowed to sign.

report parameter hl_action The enumerated value indicates the high-low action type for the report parameter. Valid values are: • 0:None


• 2:Not Allowed

report parameter hl_signature This string indicates the Windows User Group allowed to sign.

report parameter high value The high limit of the report on the specified recipe phase.

report parameter low value The low limit of the report on the specified recipe phase.

report parameter hhll_ action The enumerated value indicates the high_high low_low action type for the report parameter. Valid values are:

• 0:None


• 2:Not Allowed

report parameter hhll_signature This string indicates the Windows User Group allowed to sign.

report parameter high high value The high-high limit of the report on the specified recipe phase.

report parameter low low value The low-low limit of the report on the specified recipe phase.



Data Description

report parameter hhhlll_ action The enumerated value indicates the high_high_high low_low_low action type for the report parameter. Valid values are:

• 0:None


• 2:Not Allowed

report parameter hhhlll_signature template

The signature template assigned to the high_high_high low_low_low verification method of the report parameter.

report parameter hhhlll_high The highest limit value in the high_high_high low_low_low range set for the report parameter.

report parameter hhhlll_low The lowest limit value in the high_high_high low_low_low range set for the report parameter.

report parameter erp alias The ERP alias string associated with the REPORT record.

Control Strategies

control strategy name The name of the control strategy defined by the CONTROL STRATEGY record.

control strategy phase The name of the phase with which the control strategy defined by the CONTROL STRATEGY record is associated. The named phase must be located among the phases defined in the PHASE records.

control strategy parameter name The name of the control strategy parameter defined by the CONTROL STRATEGY PARAMETERS record.

control strategy parameter strategy The name of the control strategy with which the control strategy parameter defined by the CONTROL STRATEGY PARAMETERS record is associated. The named control strategy must be located among the control strategies defined in the CONTROL STRATEGY records.

control strategy parameter phase The name of the phase with which the control strategy parameter defined by the CONTROL STRATEGY PARAMETERS record is associated. The named phase must be located among the phases defined in the PHASE records.

control strategy parameter ID This string represents an integer value that is the ID of the control strategy parameter defined by the CONTROL STRATEGY PARAMETERS record.

control strategy parameter type The data type of the control strategy parameter defined by the CONTROL STRATEGY PARAMETERS record. Valid values are:

• REAL

• INTEGER

• STRING

• ENUMERATION

control strategy parameter engineering units

The engineering units of the control strategy parameter defined by the CONTROL STRATEGY PARAMETERS record.

control strategy parameter default value

The default value of the control strategy parameter defined by the CONTROL STRATEGY PARAMETERS record.

control strategy parameter minimum value

The minimum value of the control strategy parameter defined by the CONTROL STRATEGY PARAMETERS record.

control strategy parameter maximum value

The maximum value of the control strategy parameter defined by the CONTROL STRATEGY PARAMETERS record.

control strategy parameter scale flag This string represents a Boolean value that indicates whether the control strategy parameter defined by the CONTROL STRATEGY PARAMETERS record is scalable. A value of TRUE indicates that the value is scalable, while a value of FALSE indicates that the value is not scalable.



Data Description

control strategy parameter enumeration set

The name of the enumeration set associated with the control strategy parameter defined by the CONTROL STRATEGY PARAMETERS record. This field is only necessary when the control strategy parameter type field has a value of ENUMERATION. When this field is required, the named enumeration set must be located among the enumeration sets defined in the ENUMERATION SET records.

control strategy parameter download flags

This bitmask value defines the auto download flag for the control strategy parameter.

control strategy parameter verification method

The type of verification method used for the specified control strategy parameter. Valid values are: • 0 = No_Limits


• 2 = High_High/Low_Low Limits

• 3 = High_High_High/Low_Low_Low Limits


control strategy parameter scale limit flag

This flag determines whether the absolute limits scale with the batch scale for the specified control strategy parameter. The default value is set to OFF.

control strategy parameter normal action

The enumerated value indicates the normal action type for the report parameter. Valid values are: • 0:None


• 2:Not Allowed

control strategy parameter normal_signature

This string indicates the Windows User Group allowed to sign.

control strategy parameter hl_action The enumerated value indicates the high-low action type for the control strategy parameter. Valid values are:

• 0:None


• 2:Not Allowed

control strategy parameter hl_signature


control strategy parameter high value The high limit of the control strategy parameter on the specified recipe phase.

control strategy parameter low value The low limit of the control strategy parameter on the specified recipe phase.

control strategy parameter hhll_action The enumerated value indicates the high_high low_low action type for the control strategy parameter. Valid values are:

• 0:None


• 2:Not Allowed

control strategy parameter hhll_signature


control strategy parameter high_high value

The high-high limit of the control strategy parameter on the specified recipe phase.



Data Description

control strategy parameter low_low value

The low-low limit of the control strategy parameter on the specified recipe phase.

control strategy parameter hhhlll_action

The enumerated value indicates the high_high_high low_low_low action type for the control strategy parameter. Valid values are: • 0:None


• 2:Not Allowed

control strategy parameter hhhlll_signature template

The signature template assigned to the high_high_high low_low_low verification method of the control strategy parameter.

control strategy parameter hhhlll_high

The highest limit value in the high_high_high low_low_low range set for the control strategy parameter.

control strategy parameter hhhlll_low The lowest limit value in the high_high_high low_low_low range set for the control strategy parameter.

Control Strategy Reports

control strategy report name The name of the report parameter defined by the CONTROL STRATEGY REPORTS record.

control strategy report strategy The name of the control strategy with which the control strategy report parameter defined by the CONTROL STRATEGY PARAMETERS record is associated. The named phase must be located among the phases defined in the CONTROL STRATEGY records.

control strategy report phase The name of the phase with which the control strategy report parameter defined by the CONTROL STRATEGY PARAMETERS record is associated. The named phase must be located among the phases defined in the PHASE records.

control strategy report archive flag This string always holds the value FALSE.

control strategy report operator flag This string always holds the value FALSE.

control strategy report ID This string represents an integer value that is the ID of the control strategy report parameter defined by the CONTROL STRATEGY REPORTS structure.

control strategy report type The data type of the control strategy report parameter defined by the CONTROL STRATEGY REPORTS record. Valid values are:

• REAL

• INTEGER

• STRING

• ENUMERATION

control strategy report engineering units

The engineering units of the control strategy report parameter defined by the CONTROL STRATEGY REPORTS structure.

control strategy report enumeration set

The name of the enumeration set associated with the control strategy report parameter defined by the CONTROL STRATEGY REPORTS record. This field is only necessary when the control strategy report type field has a value of ENUMERATION. When this field is required, the named enumeration set must be located among the enumeration sets defined in the ENUMERATION SET records.

control strategy report upload flags This bitmask value defines the auto upload flag for the control strategy report parameter.



Data Description

control strategy report parameter verification method

The type of verification method used for the specified control strategy report parameter. Valid values are:

• 0 = No_Limits


• 2 = High_High Low_Low Limits

• 3 = High_High_High Low_Low_Low Limits


control strategy report parameter limit calculation

The limit calculation defines how the verification method calculates for the specified control strategy report parameter. Three types are supported for reports: • 0 = Absolute

• 1 = Percent

• 2 = Relative

control strategy report parameter target parameter

The recipe control strategy report parameter's name used in the Percent or Relative limit calculation.

control strategy report parameter scale limit flag

This flag determines whether the absolute limits scale with the batch scale for the specified control strategy report parameter. The default is set to OFF.

control strategy report parameter normal action

The enumerated value indicates the normal action type for the control strategy report parameter. Valid values are: • 0:None


• 2:Not Allowed

control strategy report parameter normal signature


control strategy report parameter hl_action

The enumerated value indicates the high-low action type for the control strategy report parameter. Valid values are:

• 0:None


• 2:Not Allowed

control strategy report parameter hl_signature


control strategy report parameter high value

The high limit of the report on the specified control strategy recipe phase.

control strategy report parameter low value

The low limit of the report on the specified control strategy recipe phase.

control strategy report parameter hhll_ action

The enumerated value indicates the high_high low_low action type for the control strategy report parameter. Valid values are: • 0:None


• 2:Not Allowed

control strategy report parameter hhll_signature




Data Description

control strategy report parameter high high value

The high-high limit of the control strategy report on the specified recipe phase.

control strategy report parameter low low value

The low-low limit of the control strategy report on the specified recipe phase.

control strategy report parameter hhhlll_ action

The enumerated value indicates the high_high_high low_low_low action type for the control strategy report parameter. Valid values are:

• 0:None


• 2:Not Allowed

control strategy report parameter hhhlll_signature template

The signature template assigned to the high_high_high low_low_low verification method of the control strategy report parameter.

control strategy report parameter hhhlll_high

The highest limit value in the high_high_high low_low_low range set for the control strategy report parameter.

control strategy report parameter hhhlll_low

The lowest limit value in the high_high_high low_low_low range set for the control strategy report parameter.

Tags

tag name The name of the tag defined by the TAG record.

tag class The name of the tag class to which the tag defined by the TAG record belongs. The named tag class must be located among the tag classes defined in the TAG CLASS records.

tag data type The data type of the tag defined by the TAG record. Valid values are:

• REAL

• INTEGER

• STRING

• ENUMERATION

tag enumeration set The name of the enumeration set associated with the tag defined by the TAG record. This field is only necessary when the tag data type field has a value of ENUMERATION. When this field is required, the named enumeration set must be located among the enumeration sets defined in the ENUMERATION SET records.

tag server name This string is the name of the server with which the tag defined by the TAG record is associated. The named server must be located among the servers defined in the SERVER records.

tag item name The item name of the tag defined by the TAG record.

tag equipment module/unit The name of the equipment phase, equipment operation sequence, or unit with which the tag defined by the TAG record is associated. When the tag class value of the tag is UNIT, COMMAND, STATUS, REQUEST, OWNER, PAUSE, PAUSED, SINGLESTEP, STEP INDEX, FAILURE, or one of the numbered phase classes, PARMTR##, REPORT##, or REQUST##, then this value must be the name of an equipment phase or equipment operation sequence. The named enumeration set must be located among the enumeration sets defined in the ENUMERATION SET records. If the tag class value of the tag is anything else, then this field must contain the name of a unit. The named unit must be located among the units defined in the UNIT records.

read access path The access path used for subscriptions and asynchronous reads when using the OPC communication protocol.



Data Description

read item name The item name used for subscriptions and asynchronous reads when using the OPC communication protocol.

write item path The access path used for asynchronous writes when using the OPC communication protocol.

write item name The item name used for asynchronous writes when using the OPC communication protocol.

tag static value The static value for the tag.

tag engineering units The engineering units for the tag.

Unit Flowpaths

flowpath source unit The name of the unit from which the flowpath defined in the FLOWPATH record begins. The named unit must be located among the units defined in the UNIT records.

flowpath destination unit The name of the destination unit of the flowpath defined in the FLOWPATH structure. The named unit must be located among the units defined in the UNIT records.

Process Cell Units

process cell unit list process cell name The name of the process cell for which an assigned unit is defined by this PROCESS CELL UNIT record. The named process cell must be located among the process cells defined in the PROCESS CELL records.

process cell unit list unit name The name of a unit assigned to a process cell by this PROCESS CELL UNIT record. The named unit must be located among the units defined in the UNIT records.

Unit Equipment Needed

unit equipment needed unit name The name of a unit for which required equipment is defined by this UNIT EQUIPMENT NEEDED record. The named unit must be located among the units defined in the UNIT records.

unit equipment needed equipment name

The name of a resource assigned to a unit by this UNIT EQUIPMENT NEEDED record. The named resource must be located among the resources defined in the RESOURCE records.

Resource Equipment Needed

resource equipment needed resource name

The name of a resource for which required equipment is defined by this RESOURCE EQUIPMENT NEEDED record. The named resource must be located among the resources defined in the RESOURCE records.

resource equipment needed equipment name

The name of a resource assigned to a resource by this RESOURCE EQUIPMENT NEEDED record. The named resource must be located among the resources defined in the RESOURCE records.

Process Cell Needed Equipment

process cell equipment needed process cell name

The name of a process cell for which required equipment is defined by this PROCESS CELL EQUIPMENT NEEDED record. The named process cell must be located among the process cells defined in the PROCESS CELL records.

process cell equipment needed equipment name

The name of a resource assigned to a process cell by this PROCESS CELL EQUIPMENT NEEDED record. The named resource must be located among the resources defined in the RESOURCE records.

Equipment Module Equipment Needed

equipment module equipment needed equipment module name

The name of a phase or operation sequence for which required equipment is defined by this EQUIPMENT MODULE EQUIPMENT NEEDED record. The name must be located among the phases or operation sequences defined in the EQUIPMENT MODULE records.



Data Description

equipment module equipment needed equipment name

The name of a resource assigned to a phase or operation sequence by this EQUIPMENT MODULE EQUIPMENT NEEDED record. The name must be located among the resources defined in the RESOURCE records.

Unit Equipment Modules

unit equipment module list unit name The name of a unit for which an associated phase or operation sequence is defined by this UNIT EQUIPMENT MODULE record. The named unit must be located among the units defined in the UNIT records.

unit equipment module list phase name

The name of a phase that is assigned to a unit by this UNIT EQUIPMENT MODULE record.

unit equipment module list resource name

The name of the resource that is assigned to a unit by this UNIT EQUIPMENT MODULE record.

Container Associations

container name The name of the container.

equipment module name The phase or operation sequence associated with the container.

container resource The resource for the container.

container feed type The feed type for the container.

supported container feed type The container's supported feed type(s).

Recipe Approval

approval step • Name: The name of the Recipe Approval Step (50 character limit).

• Id: The negative identification number of an approval step (-1 through -8).

• Required: Whether the step is needed (TRUE or FALSE).

• Step Order: The step of the Approval Step in the Approvals Process (1 to 5).

• Approve Signature Template Name: The name of the signature template to approve the Approval Step (50 character limit).

• Revert Signature Template Name: The name of the signature template to revert the Approval Step (50 character limit).

• Description: The description of the Recipe Approval Step (128 character limit).

expedited process • Name: The name of the Recipe Approval Step (either Release Recipe as Step, or Release Recipe to Production).

• Id: The negative identification number of an approval step (-7 through -8).

• Required: Whether the step is needed (TRUE or FALSE).

• Step Order: The step of the Approval Step in the Approvals Process (nominally 1).

• Approve Signature Template Name: The name of the signature template to approve the Approval Step (50 character limit).

• Revert Signature Template Name: The name of the signature template to revert the Approval Step (50 character limit).

• Description: The description of the Recipe Approval Step (128 character limit).

recipe approvals process Configured: Flag that indicates if the Recipe Approvals process is enabled or not (TRUE or FALSE).

Recipe Versioning

enable recipe versioning Configured: Flag that indicates whether recipe versioning is enabled or not (TRUE or FALSE).



Data Description

Security Authority

security approval identifier Value: Contains a security authority identifier (SAI) retrieved from the Network FactoryTalk Directory when FactoryTalk Batch Equipment Editor starts. When the area model is exported to text or XML format, this field will always contain the string NOT_AVAILABLE (as only non-secured area models can be exported). Any value placed here is ignored on import into FactoryTalk Batch Equipment Editor.

See also

Area model files on page 9


Chapter 3

Recipe database (RDB) recipes

The information necessary to generate a FactoryTalk Batch recipe (when combined with information in the area model) is contained in a series of relational database tables named MasterRecipes. This database must be located on the node specified in the FactoryTalk Batch Equipment Editor Server Options dialog box.

Both the FactoryTalk Batch Server and FactoryTalk Batch Recipe Editor requires that recipes stored in database format be stored in a Microsoft SQL Server database. Table entries are associated with a specific recipe using a unique recipe ID.

Chapter 3 Recipe database (RDB) recipes


The batch RDB recipe format is composed of these tables:

• approvalsignoffs

• bindpreferencespecifiers

• bindrequirementspecifiers

• formula

• header

• information

• link

• materialrequirements

• recipeapprovalsteps

• recparam

• recreport

• reportlimits

• signaturetemplates

• signoffsecuritypermissions

• step

• textbox

• transfer

• transition

• unitreq

For a given recipe, observe these restrictions:

• There is one row in the header table for each batch procedure, unit procedure, or operation used in the recipe.

• There are as few as five rows, and as many as eight rows, in the recipeapprovalprocess table for each recipe (0 rows when the Recipe Approvals Process is not active).

• There are two signatures for each row in the recipeapprovalprocess table.

• There is at least one row, and as many as three rows, in the approvalsignoffs table for each signature in the signaturetemplates table.

For all other tables, there are as many rows as needed to provide complete information about the recipe.

Recipe database (RDB) recipes Chapter 3


Adhering to documented table configurations maximizes access speed, and minimizes erroneous entries and conflicting data. All table names and their respective column names must match the examples provided in this document exactly, including case.

Do not use the tilde (~) character in a recipe name unless the recipe is versioned.

The following characters are not allowed in any of the string columns:

• ' (apostrophe, or single tick)

• " (quotation mark, or double tick)

• TAB

• CRLF (carriage return/line feed)

• Spaces

See also

Header table configuration on page 46



Fields that are read as is are not checked for illegal characters or erroneous data. The following assumptions are made when reading recipes from an RDB:

• All columns marked optional are read as is.

• All time stamps are read as is.

• author is read as is.

• Missing releasedasstep is assumed to be FALSE (zero).

• Missing or invalid recipetype aborts the read request.

• Missing or invalid schema is assumed to be the current schema.

• areamodel is read as is.

• Missing classbased is assumed to be FALSE (zero).

• Missing resource is set to NULL.

The following is the table configuration used for the header table. The table header indicates the dimensioning. The recipeid column should be configured as the primary key and as a unique index.

Field Name DataType Description

recipeid (unique)

nvarchar(139) The name of the procedure (bpc/pxml), unit procedure (upc/uxml), or operation (uop/oxml).

abstract (Nulls)

nvarchar(255) An abstract (background) of the recipe.

approvedby (Nulls)

nvarchar(255) The name of person who approved the recipe.

areamodel (Nulls)

nvarchar(255) The area model for verification. Must include the full path and file name.

areamodeldate datetime(8) The time stamp of the Area Model file used for verification.

author (Nulls)

nvarchar(255) The author of the recipe. This entry is required during recipe verification.

beingeditedby (Nulls)

nvarchar(255) Reserved for future use.

classbased int(4) Is the recipe class-based (TRUE) or an instance (FALSE)? Used only with unit procedures and operations.

dbschema (Nulls)

int(4) The schema associated with the FactoryTalk Batch release (version) used to build the recipe. Release 5.0 schema = 3515.

defaultsize (Nulls)

float(8) The default size of the batch.

description (Nulls)

nvarchar(255) A description of the given recipe.

Header table configuration




duration (Nulls)

nvarchar(50) The estimated length of time it takes to make the batch, in minutes.

localeid (Nulls)

int(4) The locale ID associated with this recipe. The numerical values are based on the Windows internal locale ID. • Language-Neutral-Format (LNF) = -1

• US English = 1033

• German (Germany) = 1031

• Spanish (Modern Sort) = 3082

maxsize (Nulls)

float(8) The maximum size of the batch.

minsize (Nulls)

float(8) The minimum allowed size of the batch.

productcode (Nulls)

nvarchar(255) A unique identification code for the given recipe.

productid (Nulls)

nvarchar(255) The name (ID) of the product.

produnits (Nulls)

nvarchar(50) The unit of measurement for the batch output.

recipetype int(4) The level associated with this recipe: • 41 = batch procedure

• 42 = unit procedure

• 43 = operation

released (Nulls)

int(4) Released for production (TRUE < > 0; FALSE = 0).

releaseasstep (Nulls) int(4) Missing releasedasstep is assumed as FALSE (zero). Released as a step (TRUE<>0; FALSE=0).

resource (Nulls)

nvarchar(128) The resource or equipment name associated with the given recipe. Used only with unit procedures and operations.

verificationdate (Nulls)

datetime(8) The date the recipe was verified (validated) against the Area Model. (verificationdate = 4/19/50 when recipe has not been verified.)

version nvarchar(50) The version number (assigned by recipe author) associated with the recipe.

versiondate (Nulls)

datetime(8) The date (and time) the recipe was generated.

obsoleted (Nulls)

int(4) Boolean that determines if the recipe is obsolete or not (TRUE < > 0; FALSE = 0).

nextWIPnumber (Nulls) int(4) The next work-in-progress (WIP) recipe version number.

versiondescription nvarchar(255) Description the user entered when checking in a version.

parentname (Nulls) nvarchar(255) Name of the parent recipe from which the version was created.

parentversiondescription (Nulls)

nvarchar(255) Description of the parent recipe--including versiondate, date parent recipe was versioned, and other information.

parentversiondate datetime(8) Date and time the parent recipe was versioned.




parentverificationdate datetime(8) Date and time the parent recipe was verified.

parentareamodeldate datetime(8) Date and time the parent recipe's area model had Recipe Versioning enabled.

parentareamodelname (Nulls)

nvarchar(255) Name of the parent recipe's area model.

securityauthority (Nulls)

nvarchar(255) The value of the security authority identifier (SAI) retrieved from the Network FactoryTalk Directory when a recipe is secured in FactoryTalk Batch Recipe Editor. When the recipe is exported to XML or RDB format, this field will always contain the string NOT_AVAILABLE (as only non-secured recipes can be exported). Any value placed here is ignored on import into FactoryTalk Batch Recipe Editor.

See also

Recipe database (RDB) recipes on page 43



The recparam table is used to describe all parameters that are global with respect to the given recipe. The following assumptions are made when reading recipes from an RDB:

• Missing type defaults to REAL.

• Missing scale is assumed as FALSE.

• engunits is read as is.

• Missing or erroneous values default as follows: Type real and integer: low = 0; default = 0; high = 100 Type string: default = IDS_DEFLT_STR_VALUE (string when using U.S. English) Type enumeration: if missing causes the recipe parameter to be ignored.

The following is the table configuration used for the recparam table. Dimensioning is indicated in the table header. The recipeid column must be configured as a non-unique index. The paramid and recipeid columns must be combined as primary keys.

Field Name Data Type Description

recipeid nvarchar(139) The name (ID) of the recipe to which this parameter belongs.

paramid nvarchar(128) The name (ID) of the parameter. paramid is used as the paramvalue input for all deferred formula parameters using a given recipe parameter. engunits also contains the name of the enumeration set when type is equal to enumeration.

type int(4) Data type; By definition: • 1 = real

• 2 = long integer

• 3 = string

• 5 = enumeration

scale (Nulls)

int(4) For real and integer values, whether the parameter value is scaled (TRUE < > 0; FALSE = 0).

engunits (Nulls) nvarchar(128) Engineering units associated with this parameter. Not used for strings and enumeration sets.

defaultvalue (Nulls) nvarchar(128) Default value displayed.

highvalue (Nulls) nvarchar(128) Maximum value allowed when using numeric data.

lowvalue (Nulls) nvarchar(128) Minimum value allowed when using numeric data.

number (Nulls) int(4) PLC reference number

Erpalias nvarchar(128) ERP Alias

See also


Recparam table configuration



The step table is used to describe all steps, including beginning and ending, within a recipe. The following assumptions are made when reading recipes from an RDB:

• Ensure that there are only one INIT and TERM steps, respectively. If more than one of either is found, the first one found is used.

• Missing steprecipeid aborts the read of the given step.

• Erroneous type aborts the read of the given step.

• Missing or erroneous resource (unit requirement) aborts the read of the step.

• Ensure xpos/ypos are >= 0.

The following is the table configuration used for the step table. The recipeid column must be configured as a non-unique index. The stepid and recipeid columns must be combined as primary keys.


recipeid nvarchar(139) The name (ID) of the recipe to which this step belongs.

stepid nvarchar(143) The name (ID) of the element. Must be unique within the recipe. The step must be named following the examples shown in the table above: the characters to the left of the colon (:) represent the phase on which the step is based; the number to the right of the colon represents the instance of the step.

steprecipeid (Nulls)

nvarchar(143) The name (ID) of the recipe that is used to execute this step. • phases require this field to be the class on which the step is based.

• UOPs and UPCs require the name of the corresponding recipe (not used for init/term steps).

unitalias (Nulls)

nvarchar(143) Name of unit class or instance required by this step. This entry corresponds to the resource column in the Unit Requirements table. (Not used by init/term steps.)

type int(4) Step type. By definition: • 11 = step [BPC; UPC; UOP]

• 12 = start of recipe

• 13 = end of recipe

xpos (Nulls) int(4) The X coordinate position as the step drawn in the SFC. (>= 0)

ypos (Nulls) int(4) The Y coordinate position as the step drawn in the SFC. (>= 0)

acquireunit (Nulls)

int(4) Acquire unit resource when procedure is started. Only applies to unit procedure steps within batch procedures. (Yes < > 0; No = 0)

systemstep int(4) Reservedstep type: • 0 = Not a system step

• 1 = Null step

• 2 = Timer step

See also


Step table configuration



The recipeapprovalsteps table specifies each of the approval steps configured for the recipe. The recipeid column must be configured as a non-unique index. The recipeid and generatedstepid columns must be combined as primary keys.

The following table configuration is used for the recipeapprovalprocess table:


recipeid nvarchar(139) The name of the procedure, unit procedure, or operation that contains this approval step.

approvalstepname nvarchar(50) The name of the approval step.

descriptions (Nulls) nvarchar (128) Any description put onto the approval step.

stepid int(4) Contains the unique negative number ID. (-1 to -9).

orderid int(4) Contains the step order ID. (0-5).

generatedstepid int(4) This is automatically generated and maintained by the SQL Server.

See also


The signaturetemplates table holds the information about each signature template for each approval step.

The recipeid column must be configured as a non-unique index. The recipeid and generatedtemplateid columns must be combined as primary keys.

The following table configuration is used for the signaturetemplates table:


recipeid nvarchar(139) The name of the procedure, unit procedure, or operation that contains this signature template.

signaturename nvarchar(80) The name of the signature template.

isrevert int(4) Indicates that this signature is for either the approval signature template or the revert signature template. (0 or 1).

generatedstepid int(4) This entry is automatically generated and maintained by the SQL Server.

generatedtemplateid int(4) This entry is automatically generated and maintained by the SQL Server.

See also


Recipeapprovalsteps table configuration

Signaturetemplates table configuration



The approvalsignoffs table holds basic signoff information on each signoff for every signature template configured in the approval step. The recipeid column must be configured as a non-unique index. The recipeid and generatedsignoffid columns must be combined as primary keys.

The following table configuration is used for the approvalsignoffs table:


recipeid nvarchar(139) The name of the procedure, unit procedure, or operation that contains this signoff.

signum int(4) The number of this signoff, used to place the signoff back in the proper position on the signature template (1-3).

meaning nvarchar(80) Describes the significance of the signoff, as entered in the signature template when configured in FactoryTalk Batch Equipment Editor.

approver (Nulls)

nvarchar(128) The user name of the approver that signed off (if any).

datetime (Nulls)

nvarchar(20) The date that the user signed off (if any).

comment (Nulls)

nvarchar(1024) Any comments on this signoff (if any).

commenttype (Nulls)

nvarchar(20) The comment type (Optional, Required, Not Allowed).

lastsignoff int(4) The indicator that this must be the final signoff after all other, required approvers have signed off on this signature template (0 or 1).

generatedtemplateid int(4) This ID is automatically generated and maintained by the SQL Server.

generatedsignoffid int(4) This ID is automatically generated and maintained by the SQL Server.

See also


Approvalsignoffs table configuration



The securitypermissions table holds all of the detailed security permissions of each signoff. The recipeid column must be configured as a non-unique index. The recipeid and generatedpermissionid columns must be combined as primary keys.

The following table configuration is used for the securitypermissions table:


recipeid nvarchar(139) The name of the procedure, unit procedure, or operation that contains this security permission.

compordomain nvarchar(80) The name of the computer or domain that this permission is configured on (can be blank).

userorgroup nvarchar(100) The name of the user or group that has permission to signoff.

userisgroup int(4) Indicates that this security permission is for a user, or a group (0 = Group, 1 = User).

generatedsignoffid int(4) This ID is automatically generated and maintained by the SQL Server.

generatedpermissionid int(4) This ID is automatically generated and maintained by the SQL Server.

See also


Securitypermissions table configuration



The transition table is used to describe all of the transitions within a recipe. The following assumptions are made when reading recipes from an RDB:

• Ensure xpos/ypos are >= 0.

The following is the table configuration used for the transition table. The recipeid column must be configured as a non-unique index. The transitionid and recipeid columns must be combined as primary keys.


recipeid nvarchar(139) The name (ID) of the recipe to which this transition belongs.

transitionid nvarchar(143) The name (ID) of the transition. The transitionid must be unique within a recipe.

xpos (Nulls)

int(4) The X coordinate position of the transition as it is drawn in the SFC (>= 0).

ypos (Nulls)

int(4) The Y coordinate position of the transition as it is drawn in the SFC (>= 0).

condition nvarchar(1023) The condition to satisfy transition state. Condition can be stored in either language neutral format (LNF; default) or language specific format (LSF). The use of LNF or LSF must be consistent throughout a recipe.

See also


Transition table configuration



The link table is used to describe all of the links within a recipe. The following assumptions are made when reading recipes from an RDB:

• linkid is read as is.

• Missing any other entries abort the read of the given link.

• If the fromelementid or toelementid is not found in the transition or step tables, the link record is ignored.

The following is the table configuration used for the link table. Dimensioning is indicated in the table header. The recipeid column must be configured as a non-unique index. The linkid, recipeid, fromelementid, and toelementid columns must be combined as primary keys.


recipeid nvarchar(139) The name (ID) of the recipe to which this parameter belongs.

linkid nvarchar(25) The name (ID) of the link. Must be unique within the recipe.

fromelementid nvarchar(143) The beginning (upstream) element name (ID) of this link.

toelementid nvarchar(143) The ending (downstream) element name (ID) of this link.

fromtype int(4) Element type of the fromelementid. By definition: (21 = step; 22 = transition;)

totype int(4) Element type of the toelementid. By definition: (21 = step; 22 = transition;)

See also


Link table configuration



The formula table is used to describe all of the formula parameters within a recipe. The following assumptions are made when reading recipes from an RDB:

• Invalid origin defaults to Operator.

• stepid not found in the map of recipe elements aborts the read of the given parameter.

• Missing type defaults to REAL.

• Missing paramvalue defaults as follows: Type real and integer: = 0; Type enumeration: causes the formula parameter to be ignored.

The table is processed according to the following guidelines:

• For origin of type operator, the paramvalue column is used as the default, and the operator is prompted for acknowledgment of this value, or entry of a new value.

• When formulatype is enumeration, the paramvalue column contains the enumeration, and the paramengunits column contains the enumeration set.

• For origin of type defer, the parameter is deferred to the recipe parameter indicated in the paramvalue column (paramvalue contains the paramid from the RecParam table).

• Engineering units, low value, and high value are obtained from the area model during the verification process.

The following is the table configuration used for the formula table. Dimensioning is indicated in the table header. The recipeid column must be configured as a non-unique index. The recipeid, stepid and paramid columns must be combined as primary keys.


recipeid nvarchar(139) The name (ID) of the recipe to which the associated stepid belongs.

stepid nvarchar(143) The ID of the step, almost always a phase.

paramid nvarchar(128) The name (ID) of the parameter. This is the name of the parameter as assigned in the Area Model (when editing the phase, for example).

origin int(4) Origin of the formula. By definition:

• 31 = operator

• 32 = defer

• 33 = value

• 34 = equation

Formula table configuration




formulatype int(4) The data type of the parameter. This parameter is ignored (set = 0) when the origin is deferred to a recipe parameter. By definition:

• 1 = real


• 3 = string

• 5 = enumeration

paramvalue (Nulls)

nvarchar(128) The value associated with the parameter, if appropriate.

paramengunits (Nulls)

nvarchar(128) The engineering units associated with the parameter when displayed in the SFC. paramengunits contains the enumeration set when formulatype is equal to enumeration.

display (Nulls)

int(4) Display the formula parameter in the SFC. Only one parameter per step can be displayed. If more than one parameter for a given step is set to TRUE, the last one read will be the one set for display. (TRUE < > 0; FALSE = 0)

lowlowlow (Nulls)

float The Low-Low-Low Limit value of the specified parameter.

lowlow (Nulls)

float The Low-Low Limit value of the specified parameter.

low (Nulls)

float The Low Limit value of the specified parameter.

high (Nulls)

float The High Limit value of the specified parameter.

highhigh (Nulls)

float The High-High Limit value of the specified parameter.

highhighhigh (Nulls)

float The High-High-High Limit value of the specified parameter.

verification (Nulls)

int(4) Verification method. • 0 = No_Limits

• 1 = High_Low

• 2 = HighHigh_LowLow

• 3 = HighHighHigh_LowLowLow

See also




The transfer table is used to describe all of the phases that communicate and work together within a recipe. The unitproc_stepid column is blank if the transfer group is located at the unit procedure level. Both the unitproc_stepid and unitop stepid columns are blank if the transfer group is located at the operation level. As a result, a recipeid column is included to ensure that the group can easily be associated with its recipe.

The following assumptions are made when reading recipes from an RDB:

• Invalid groupid aborts the read of the group.

• All others are read as is.

The following is the table configuration used for the transfer table.


recipeid nvarchar(139) The name (ID) of the recipe (either batch procedure, unit procedure, or operation) that contains this group. The recipeid used in the header table must be used here.

uniqueid (int)4 The 32-bit unsigned integer unique number that identifies the specific instance of a batch.

groupid nvarchar(64) The name (ID) of the group. This column is used to match all phases that are part of the transfer or link group.

phase_stepid nvarchar(143) The phase step associated with the link group. The stepid used to describe the step (phase) in the Step table must be used here.

unitop_stepid (Nulls)

nvarchar(143) The name (ID) of the operation that contains the phase. If the group resides at the batch or unit procedure level, this column contains the name of the step used in the unit procedure recipe.

unitproc_stepid (Nulls)

nvarchar(143) The name (ID) of the unit procedure associated with this group. This column is blank if the group resides at the unit procedure or operation level. If the group resides at the batch procedure level, this column contains the name of the step used in the batch procedure recipe.

See also


Transfer table configuration



The unitreq table is used to describe all of the unit requirements as they pertain to the allocation of units to a recipe. There is one record for every downstream unit referenced by a given unit requirement. A step always references a unit requirement by use of a resource column.


• Missing resource aborts the read of the given unit requirement record.

• Missing or unknown bindingmethod default to batch creation.

• Invalid unitalias aborts the read of the unit requirement record.

The following is the table configuration used for the unitreq table.


unitreqid int(4) Unique number.

recipeid nvarchar(139) The name (ID) of the recipe to which this unit requirement belongs.

resource nvarchar(128) The unit class or instance which identifies this unit requirement (from the Area Model). This column is used to tie unit procedures and operations to a given unit requirement.

unitalias nvarchar(143) Alias name for the unit requirement.

bindingmethod int(4) Type of binding method used by this unit requirement. • 51 = static

• 52 = first available

• 53 = prompt

• 54 = batch creation

• 55 = operator choice

classbased int(4) Whether the recipe is class based. • TRUE (<> 0)= yes

• FALSE (= 0) = no [instance-based])

downstreamresource (Nulls)

nvarchar(143) The list of unit aliases downstream from the unit referenced as the resource. The name used in this column must have been used as the resource of another unit requirement record.

See also


Unitreq table configuration



The materialrequirements table records information on material-based phases. There is one record for every step that represents a phase that uses material.


• Invalid stepid aborts the reading of the recipe.

• Invalid PhaseBindType defaults to Standard.

The following is the table configuration used for the materialrequirements table. The recipeid and stepid columns must be combined as primary keys.


recipeid nvarchar(139) The name (ID) of the recipe that is used to execute this step.

stepid nvarchar(143) The step associated with the material requirement.

materialname nvarchar(100) Name of the material as defined in the material database.

lot (Nulls)

nvarchar(255) Material Lot

label (Nulls)

nvarchar(255) Material Label

AddOrDump (Nulls)

float(8) Indicates if the material is an addition or distribution. Additions are positive (>=0), Distributions are negative(<=0)

PhaseBindType (Nulls)

int(4) The binding method for this material requirement. • 0 = Standard

• 1 = Automatic

• 2 = Prompt

PhaseClassName (Nulls)

nvarchar(128) The name of the phase class on the step to be bound.

See also


Materialrequirements table configuration



The reportlimits table specifies the means of verification required by eProcedure for each report parameter on an instruction based phase.

The following is the table configuration used for the reportlimits table. The recipeid, stepid, and reportname fields must be combined as primary keys.


recipeid nvarchar(139) The name (ID) of the recipe that is used to execute this step.

stepid nvarchar(143) The step associated with the link group.

reportname nvarchar(128) Name of the report parameter.

high nvarchar(128) The High Limit value in the LowLow to Low to High to HighHigh range.

low nvarchar(128) The Low Limit value in the LowLow to Low to High to HighHigh range.

highhigh nvarchar(128) The HighHigh Limit value in the LowLow to Low to High to HighHigh range.

lowlow nvarchar(128) The LowLow Limit value in the LowLow to Low to High to HighHigh range.

verification int(4) Verification method. • 0 = No_Limits

• 1 = High_Low

• 2 = HighHigh_LowLow

• 3 = HighHighHigh_LowLowLow

highhighhigh nvarchar(128) The HighHighHigh Limit value in the LowLowLow to LowLow to HighHigh to HighHighHigh range.

lowlowlow nvarchar(128) The LowLowLow Limit value in the LowLowLow to LowLow to HighHigh to HighHighHigh range.

targetparameter nvarchar(128) Name of the specified report parameter to be used in the Percent or Relative limit calculation. An empty string when the Limit Calculation is Absolute.

verificationtype int The data type of the specified report parameter. By definition:

• 1 = real


• 3 = string

• 5 = enumeration

See also


Reportlimits table configuration



The bindpreferencespecifiers table is used to describe all of the binding preferences within a recipe.

The following is the table configuration used for the bindpreferencespecifiers table. The recipeid column must be configured as a non-unique index. The recipeid and unitreqid columns must be combined as primary keys.


recipeid nvarchar(139) The name of the procedure, unit procedure, or operation that contains the bind preference.

unitreqid nvarchar(143) The unit requirement name that owns the bind preference.

specifiertype int(4) The bind preference type: • 0 = Expression

• 1 = Attribute

• 2 = Phase

orderid int(4) The order of the preferences.

affinityspecifier int(4) Affinity specifier:

• 0 = Require / Prefer

• 1 = Reject / Avoid

attributename nvarchar(128) The unit attribute name.

phasename nvarchar(128) The phase name.

expressiontype int(4) Expression type: • 0 = Boolean

• 1 = Minimize

• 2 = Maximize

LNFexpression nvarchar(1023) Expression in language neutral format.

See also


Bindpreferencespecifiers table configuration



The bindrequirementspecifiers table is used to describe all of the binding preferences within a recipe.

The following is the table configuration used for the bindrequirementspecifiers table. The recipeid column must be configured as a non-unique index. The recipeid and unitreqid columns must be combined as primary keys.


recipeid nvarchar(139) The name of the procedure, unit procedure, or operation that contains the bind requirement.

unitreqid nvarchar(143) The unit requirement name that owns the bind requirement.

specifiertype int(4) The bind requirement type: • 0 = Expression

• 1 = Attribute

• 2 = Phase

orderid int(4) The order of the requirements.

affinityspecifier int(4) Affinity specifier:

• 0 = Require / Prefer

• 1 = Reject / Avoid

attributename nvarchar(128) The unit attribute name.

phasename nvarchar(128) The phase name.

expressiontype int(4) Expression type: • 0 = Boolean

• 1 = Minimize

• 2 = Maximize

LNFexpression nvarchar(1023) Expression in language neutral format.

See also


Bindrequirementspecifiers table configuration



The textbox table is used to hold information regarding text box comments that are made on recipes.

The following is the table configuration used for the textbox table. The leftpos must be less than the rightpos and the toppos must be less than the bottompos. The recipeid column must be configured as a non-unique index. The recipeid and textboxid columns must be combined as primary keys.


recipeid nvarchar(139) The name (ID) of the recipe to which this transition belongs.

textboxid nvarchar(10) The identifier of the text box.

associationid nvarchar(143) The name of the transition or step the text box is associated with.

comment nvarchar(1024) The comment that was entered for this text box.

leftpos int(4) The left most X coordinate of the text box in the SFC View.

toppos int(4) The top most Y coordinate of the text box in the SFC View.

rightpos int(4) The right most X coordinate of the text box in the SFC View.

bottompos int(4) The bottom most Y coordinate of the text box in the SFC View.

See also


Textbox configuration



LNF allows a recipe designer (designing a recipe stored in a database) to write a recipe in one language that can be read in another language without translating the recipe's reserved words. The LNF representation is an internal representation of the reserved words (listed below) in a transition's condition expression. FactoryTalk Batch Recipe Editor and the FactoryTalk Batch Server read this internal representation and translate it to the language specified by the locale of the system.

FactoryTalk Batch Recipe Editor automatically stores the recipe's transition conditions in the LNF representation. For example, the expression MIX:1.STATE = COMPLETE is saved as MIX:1.[21] = [14].

Reserved Word LNF Representation Description

UNKNOWN [0]

NOT [1] Logical NOT operator

OR [2] Logical OR operator

AND [3] Logical AND operator

TRUE [4] Symbolic constant for Boolean TRUE value

FALSE [5] Symbolic constant for Boolean FALSE value

EXTERNAL [6] Value for step attribute OWNERID when the step is not under batch control

PROGRAM [7] Value for step attribute OWNERID when the step is under batch control

ABORTING [8] Value for step attribute STATE when the step is in the ABORTING state

HOLDING [9] Value for step attribute STATE when the step is in the HOLDING state

STOPPING [10] Value for step attribute STATE when the step is in the STOPPING state

RESTARTING [11] Value for step attribute STATE when the step is in the RESTARTING state

RUNNING [12] Value for step attribute STATE when the step is in the RUNNING state

HELD [13] Value for step attribute STATE when the step is in the HELD state

COMPLETE [14] Value for step attribute STATE when the step is in the COMPLETE state

STOPPED [15] Value for step attribute STATE when the step is in the STOPPED state

ABORTED [16] Value for step attribute STATE when the step is in the ABORTED state

IDLE [17] Value for step attribute STATE when the step is in the IDLE state

STARTING [18] Value for step attribute STATE when the step is in the STARTING state

LNF: language neutral format



Reserved Word LNF Representation Description

READY [19] Value for step attribute STATE when the step is in the READY state

OWNERID [20] Step attribute: indicates who is controlling the step

STATE [21] Step attribute: indicates the value of the step's STATE tag

FAILURE [22] Step attribute: indicates the value of the step's FAILURE tag

SINGLESTEP [23] Step attribute: indicates the value of the step's SINGLESTEP tag

ERROR [24] Step attribute: indicates the value of the step's ERROR tag

PAUSE [25] Step attribute: indicates the value of the step's PAUSE tag

PAUSED [26] Step attribute: indicates the value of the step's PAUSED tag

ACTIVE [27] Step attribute: indicates the value of the step's ACTIVE tag

STEPINDEX [28] Step attribute: indicates the value of the step's STEPINDEX tag

DECIMAL [29] Decimal point

CONTROL STRATEGY [30] Name of CONTROL STRATEGY parameter

MATERIAL [31] Name of MATERIAL parameter

AMOUNT [32] Name of AMOUNT parameter

ACTUAL AMOUNT [33] Name of ACTUAL_AMOUNT parameter

FEED COMPLETE [34] Name of FEED_COMPLETE parameter

CONTAINER [35] Name of CONTAINER parameter

LOT [36] Name of LOT parameter

LABEL [37] Name of LABEL parameter

NULL STEP [38] Name of a step whose attached procedure is a Null Procedure.

MATERIAL-CLASS [39] Name of MATERIAL CLASS parameter

See also



Chapter 4

Electronic batch records

An electronic batch record is a record of the creation of a batch of material. Among other uses, this record can be used for regulatory and reporting purposes. The ISA S88.01 standard defines batch history as a collection of data describing or related to a batch.

For every batch executed, FactoryTalk Batch creates and maintains an electronic batch record during the execution of the batch procedure. Entries are appended to the electronic batch record as events occur. The electronic batch record is accessible from FactoryTalk Batch View.

FactoryTalk Batch stores the electronic batch data in a simple ASCII format file (.evt) that may be viewed with a word processor or spreadsheet application.

See also

Electronic batch record fields on page 67

Electronic batch record entries on page 69

Electronic signatures on page 77

Event journal signatures on page 77

Each electronic batch record entry contains the following fields (all data is in ASCII format but may represent a time, integer, real number, string, or enumeration):

Important: When using a version older than 6.02, please read carefully as the contents of .evt files have changed.

Schema name Description

LclTime The time and date of the event that triggered the electronic batch record entry. The format is YYYY.MM.DD HH:MM:SS and cannot be modified.

BatchID The batch identification (an alphanumeric string) entered by the operator when the batch is created.

Electronic batch record fields

Chapter 4 Electronic batch records


Schema name Description

Recipe The recipe element that was executing at the time of the electronic batch record entry. The field in the event journal appears as follows: <UniqueID>:[<Procedure>\][<Unit Procedure>:Instance\]<Operation>:Instance-LoopCounter The data in the brackets is optional, depending on the level of the recipe.

Descript A description of the entry; for example, mode change, step activation, bound unit.

Event The type of event defined in Descript (system generated).

PValue A value appropriate for the event type. May be integer, real, string, or enumeration.

EU The engineering units, if any, appropriate for the value.

Area The name of the area associated with the batch.

ProcCell The process cell associated with the event.

Unit The unit, if any, associated with the event.

Phase The phase, if any, associated with the event.

PhaseDesc A description of the type of phase entered by the user from FactoryTalk Batch Equipment Editor; for example, MAT ADD.

UserID Login name of user commanding FactoryTalk Batch, in the following format: Windows Computer Name/Windows User Name.

UniqueID The 32-bit unsigned integer unique number that identifies the specific instance of a batch.

MaterialName The common name of the material.

MaterialClassName The name assigned to a class of materials.

MaterialID The inventory control system material ID used to track the material.

LotName The name assigned to a lot of material.

Label The ID assigned to a distributed portion of a lot.

Container The name of the container to which the material and lot were distributed.

PromiseID A unique ID used as a key to allow grouping of separate event entries all resulting from a single material addition or the unique ID of a bind event used to link this event with associated bind event records.

ReactivationNumber The reactivation number of an eProcedure instruction step. Used with events related to a specific step.

InstructionHTML HTML of a completed eProcedure instruction step. This data is not displayed in the Event Viewer but is used in BatchSIG calculations when checking the signature field.

SignatureID A unique ID assigned to a Signature request.

ActionID A unique ID assigned to a queued Execute request that is awaiting completion of one or more signature requests.

Signature Used for Event Journal Signatures. Information stored here is in hexadecimal or a single space character.

See also

Electronic batch records on page 67

Electronic batch records Chapter 4


An electronic batch record can contain a variety of entries, based on event types.

The following table describes each type of event. Text that is not literal is indicated in < >. Information that is defined in the area model is indicated by a †. Data that is used in the recipe is indicated by a ‡.

Value of Event field Value of Descript field PValue Description

Active Step Change Commencing

Active Step Change Command Attempted

Records the beginning of an active step change

Arbitration Equipment Module Acquired Name of the acquired phase or operation sequence defined in the area model.

Arbitration Equipment Module Released Name of the released phase or operation sequence defined in the area model.

Arbitration Unit Acquired Name of the acquired unit defined in the area model.

Arbitration Unit Released Name of the released unit defined in the area model.

Attribute Change Attribute Change Description of how an object’s PAUSED attribute has changed

Automatic Removal Setting Changed TRUE or FALSE

Batch Deletion Removal Requested Removal of batch requested, or request to remove batch repeated

Bind <unit class name> ‡ Name of unit instance defined in the area model.

Comment Operator Comment Comment entered by the operator regarding the batch (created through FactoryTalk Batch View or an HMI)

ControlStep START Control Step Activity Step number Used for FactoryTalk eProcedure only.

ControlStep STOP Control Step Activity Step number Used for FactoryTalk eProcedure only.

Creation Bind <unit class alias name> ‡ Name of the unit class defined in the area model.

Event File Name <null> Path and file name of the electronic batch record

Instruction Complete Instruction Completed Step Number Used for FactoryTalk eProcedure only.

Loss of Material Server Arbitration - Equipment Module Acquired

Name of the acquired phase defined in the area model.

Loss of Material Server Arbitration - Unit Acquired Name of the acquired unit defined in the area model.

Loss of Material Server Bind Name of unit instance defined in the area model.

Loss of Material Server Creation Bind Name of the unit class defined in the area model.

Electronic batch record entries




Loss of Material Server Material Bound Name of phase bound defined in the area model.

Loss of Material Server Material Reporting Material Feed Report Number Incremented

Loss of Material Server Material Unbound Name of phase unbound defined in the area model.

Loss of Material Server Promise Event - Promise ID Completed 0

Loss of Material Server UnBind Prompt Bind

Loss of Material Tracking Material Tracking - Material Addition

Loss of Material Tracking Material Tracking - Material Addition Promised

Loss of Material Tracking Material Tracking - Material Distribution

Material Bound <phase name> ‡ Name of phase bound defined in the area model

Material Reporting Material Tracking report number incremented

Material Tracking Containers Specified by Operator

Material Tracking Material Addition Actual amount of material used

Material Tracking Material Addition Promised Amount of material promised

Material Tracking Material Distribution Actual amount of material distributed

Material Tracking Material Distribution Promised Amount of material promised

Material Tracking Material Promise unable to be established

Material Tracking Phase Binding Selected by Operator

Material Tracking Unable to mark container as default for use

Material Tracking Unable to update actual amount fed

Material Tracking Unit Binding Selected by Operator

Material Unbound <phase name> ‡ Name of phase unbound defined in the area model.

Message Actual message string This is the message configured in the phase class that is sent to the operator

Mode Change Mode Changed: A procedural element mode change; for example, O-AUTO, MANUAL

Mode Command Mode Commanded: A request to a procedural element to change mode sent by the operator or the recipe; for example, MAN-MODE

Owner Change Owner Changed: A request to a step to change the owner; for example, EXTERNAL, OPERATOR

Param Download Verified <parameter tag name> † Enters value of actual parameter after successful download

Param Download Verify Fail <parameter tag name> † A failure on a download of a parameter is recorded here

Phase Link Permissive Canceled

Phase Link message canceled Records when a Send Message Without Wait request is canceled

Phase Link Permissive Received Phase Link message canceled Records when a Send Message Without Wait request is received




Phase Link Permissive Sent Numbers representing the data Records when a Send Message Without Wait is sent

Phase Logic Arbitration Resource Acquired /Resource Released Records when a phase acquires or releases resources

Promise Event Promise ID completed Records when a promise event has been completed

Prompt Name of parameter A request from a phase to the operator to provide information for the completion of the phase logic

Prompt Response <parameter name> † Operator response to a prompt

Recipe Description <null> Not currently used

Recipe Header Area Model File Name Name and path of the Area Model this recipe was written against

Recipe Header Area Model Validated Against Time and Date stamp for the last saved time of the Area Model

Recipe Header Author Name of the author of the recipe

Recipe Header Class or Instance Indicates whether the recipe is a class-based or instance-based recipe

Recipe Header File Name Path and name of the recipe

Recipe Header Product Code User defined product code entered in the Recipe Header section of a recipe

Recipe Header Product Description Text entered into Description field of recipe header data during recipe creation

Recipe Header Recipe Type Indicates if the recipe is an Operation (OP), Unit Procedure (UP), or Procedure (BP)

Recipe Header Validation Time Time and date stamp for when the recipe was last validated against the Area Model

Recipe Header Version Version of the recipe as entered during recipe creation

Recipe Header Version Date Date this version of the recipe was last saved

Recipe Parameter Deviation Parameter Name Stores all the deviation information. • Deviated Value = Value

• Limit Violated = LimitDescriptor

• Limit Value = Value

Report Parameter Deviation Report Parameter Name Stores all the deviation information.

• Deviated Value = Value

• Limit Violated = LimitDescriptor

• Limit Value = Value

• Limit Calculation = CalculationDescriptor

• Target Value = Value

Recipe Value <parameter name> † Value of the recipe parameter. Material parameters store the material name.

Recipe Value Change Change Recipe Data: Any change in the recipe value

Report <report parameter name> † A single data value collected by the phase logic

Report Comment <report parameter name>




Scale Factor Scale Scale entered by operator during batch creation. Scale is a percentage of the original default values of the equipment phase parameters, equipment operation sequence parameters, and recipe formula parameters. Only those parameters that were marked as scalable during the creation of the equipment phases, equipment operation sequences, and recipe are proportionally adjusted when the batch is run. Parameters that were not designated as scalable always retain their original value no matter what the scale factor of the batch is.

Signature Request Canceled Cancelled

Signature Request Completed

Signature Request Created Command The command value received in the Command execute.

Signature Request Created General Usage The Step Index to be reactivated in the Recipe Phase.

Signature Request Created Recipe Parameter Deviation The parameter name targeted by the SetParm execute, the value that will be stored in parameter if signature completes, the current value of parameter, the type of deviation, the high deviation limit, the high high deviation limit, the high high high deviation limit, the low deviation limit, the low low deviation limit, the low low low deviation limit.

Signature Request Created Parameter Value Ack The name of the parameter targeted by the SetParm execute, the value stored in parameter if signature completes, the default value of the parameter.

Signature Request Created Report Parameter Deviation The name of the report parameter reported, the reported value, the name of the parameter from which the report deviation limits are calculated, the value of the parameter from which the report deviation limits are calculated, the type of deviation, the high deviation limit, the high high deviation limit, the high high high deviation limit, the low deviation limit, the low low deviation limit, the low low low deviation limit.

Signature Request Created Unit Bind The ID of a Unit to be used for the bind function, Step Identifier.

Signature Request Created Unit Bind Ack The ID of a Unit to be used for the bind function, Step Identifier.

Signature Request Created Phase Bind The ID of the equipment phase for the bind, container, material, the Lot value to be used in the Recipe Phase Bind, the Label value to be used in the Recipe Phase Bind.




Signature Request Created Phase Bind Ack The ID of the equipment phase for the bind, container, material, the Lot value to be used in the Recipe Phase Bind, the Label value to be used in the Recipe Phase Bind.

Signature Request Created Batch Removal <Null list>

Signature Request Created Active Step Change Null or Step Identifier.

Signature Request Created Add Event The Type argument, the Description argument and the Value passed in the AddEvent execute.

Signature Request Created Set Parameter The name of the parameter targeted by the SetParm execute, the Value that is stored in the parameter if the signature completes, current Value of the parameter.

Signature Request Created SetAllLabel The value stored in the parameter if the signature completes.

Signature Request Created SetAllLot The value stored in the parameter if the signature completes.

Signature Request Created Reactivate Step The Step Index to be reactivated in the Recipe Phase, the reactivation number.

Signature Request Created eReport Parameter Deviation The name of the report parameter reported, the reported value, the name of the parameter from which the report deviation limits are calculated, the value of the parameter from which the report deviation limits are calculated, the type of deviation, the high deviation limit, the high high deviation limit, the high high high deviation limit, the low deviation limit, the low low deviation limit, the low low low deviation limit.

Signature Request Created Step Verification The Step Index to be reactivated in the Recipe Phase and the reactivation number.

Signature Request Created Phase Disconnect The command value received in the Command execute and a human readable localized string representing the command value.

Signature Request Created Phase Reset The command value received in the Command execute and a human readable localized string representing the command value.

Signature Request System Canceled

Illegal State for Command


Action Aborted by Signature Cancelation


Unacknowledged Event Terminated


Illegal Bind Target


Illegal Remove Target





Illegal ReactivateStep Target


Request Cancelled


Warm Restart

Successful Signoff The comment argument passed in the Signoff execute.

A structure recording the signoff number, full user name, and the userID <SignoffSuccessContext>.

Unsuccessful Signoff The comment argument passed in the Signoff execute.

A structure recording the signoff number, full user name, and the userID <SignoffFailureContext>.

State Change State Changed: A procedure element state change

State Command State Commanded: A request to a procedure element to change its state

Step Activity Step Activated Records whenever a procedure step is activated

Step Activity Step Deactivated Records whenever a procedure step is deactivated

Step Reactivation Step Reactivated Step number Used for FactoryTalk eProcedure only.

Step Reactivation Request Step Reactivation Requested Step number Used for FactoryTalk eProcedure only.

System Message <Procedure description> Contains the version number of server this is running against

System Message <Procedure description> An indicator of the beginning of the batch

System Message <Procedure description> An indicator of the end of the batch

System Message <Procedure description> Batch terminated by COLD boot of FactoryTalk Batch Server

System Message <Procedure description> Batch terminated due to error attempting to restore batch during WARM restart

System Message <Procedure description> Batch terminated due to error attempting to restore batch during WARM-ALL restart

System Message Failure indicator Contains any step errors or failures

System Message Operation Finished Indicates an operation was completed

System Message Operation Started Indicates an operation was started

System Message Procedure Failure Detected: Error text displays if it is available

Error message

System Message Procedure Finished Indicates a procedure was completed

System Message Procedure Started Indicates a procedure was started

System Message Unit Procedure Finished Indicates a unit procedure was completed

System Message Unit Procedure Started Indicates a unit procedure was started

Unbind <unit class name> Prompt Bind




Unit Bind Candidate Legality <unit requirement name> Indicates the legality of the Unit instance for binding against the Unit Requirement specified in the Descript field. Possible values are: LEGAL, Excluded by Material requirements, Excluded by Flowpath Requirements, Excluded by Static Binding Requirement of Downstream Flowpath Requirements, and Excluded by Binding Requirement.

Unit Bind Reason <unit requirement name> Indicates the reason for the Bind of the Unit Requirement. Possible reasons are: Batch Creation Bind Manual Bind Recipe Execution - Prompt Bind Recipe Execution - First Available Bind

Unit Bind Candidate Preference <unit requirement name> Indicates the preferential value of the Unit for binding to the Unit Requirement specified in the Descript field. 1 = most preferred.

Unit Verified <unit tag name> † Name of unit tag Equipment ID

User User Defined Users can define their own events to be saved in the electronic batch record with the ADDEVENT execute

See also




The electronic batch record contains entries if the batch is terminated by a cold boot of the FactoryTalk Batch Server, or if the batch is terminated due to an error when attempting to restore the batch from a warm restart or warm-all restart of the server.

The following table is an example of a termination of a batch during a Warm Restart.

Descript Event PValue

Event File Name \\ComputerName\PROGRAM FILES\ ROCKWELLSOFTWARE\BATCH\YourProject\ JOURNALS\4125.evt

YourBatchDescription System Message Batch terminated due to error attempting to restore batch during WARM restart.

YourBatchDescription System Message End Of BATCH

The following table is an example of a termination of a batch during a Warm-All Restart.



YourBatchDescription System Message Batch terminated due to error attempting to restore batch during WARM-ALL restart.


The following table is an example of termination of a batch due to Cold Boot.



YourBatchDescription System Message Batch terminated by COLD boot of Batch Server.


See also

Electronic batch record entries on page 69

End of batch entries



Electronic signatures are used to secure control over runtime FactoryTalk Batch processes by configuring signature requirements. These signature events are then recorded in an electronic batch record which includes the name of the signer, the date and time the signature was executed and the meaning associated with the signature. The types of signatures may include report parameter verification for automated and manual phases, recipe parameter change verification, eProcedure step verification, batch and phase command verification, and a general usage signature that will allow a phase to request a signature whenever needed.

FactoryTalk Batch Equipment Editor is used to configure signature templates which consist of signoffs, meanings, security permissions, and comment requirements. Once configured signature templates can be associated with command verification policies to control specific batch processes. An example would be assigning a signature template to the HOLD command verification policy to require signoffs when a HOLD command is issued during batch execution. In this scenario, the HOLD command would not be executed until the signoffs were complete. Electronic signatures can also be used to require signature signoffs when a parameter value is too low or too high.

For more information, see Electronic signatures in the FactoryTalk Batch Equipment Editor User Guide.

See also


Event Journal Signatures detects any unauthorized changes (changes not made by the FactoryTalk Batch Server) to electronic batch records (.evt files). Each record in the electronic batch record file contains a signature field that is used for verification. When a batch is removed from the Batch List, either by an operator or automatically by the AUTOREMOVE execute, an event record is written to the journal with an additional signature for the entire batch. This final record prevents the insertion or deletion of event records at the end of an event journal. The final signature record will not be present in batches currently executing (on the Batch List), batches not restored to the Batch List after warm booting the server with errors, or batches not restored to the Batch List after a warm-all restart attempt (for example, if the area model name had been changed since the server was started).

See also

Enable event journal signatures on page 78

Verify the event journal on page 79

Electronic signatures

Event journal signatures



Event Journal Signatures must be enabled through Server Options in FactoryTalk Batch Equipment Editor.

To enable event journal signatures:

1. From FactoryTalk Batch Equipment Editor, go to the Options menu and select Server Options.

2. In the Server Options dialog box, click the Batch Server tab.

3. Select the Enable Event Journal Signatures check box and click OK.

Tip: When Event Journal Signatures are enabled, specify Archiver (End-of-Batch) archiving to verify that all event journal records are properly archived.

See also


Enable event journal signatures



A command line tool, Batchsig.exe, is used to verify event journal files based on the signature. The event journal only verifies correctly if it has not been modified in any way after being written by the FactoryTalk Batch Server.

Tip: If a batch is removed from the batch list due to any abnormal termination of the FactoryTalk Batch Server, the EVT cannot be verified using BatchSig.

Tip: Verification does not depend on the network environment in which the event journal was created. Back up the event journal files and verify them on another network. Move the Batchsig.exe file to another computer to verify the event journal files.

The Batchsig.exe file takes one or more file names, including wildcards, as arguments. If a file path is not specified for a given file, the tool searches the working directory and searches the configured event journal directory if the verification is done on the same computer as the server. For each file specified, including all files specified by wildcards, the tool prints a message to the console. Console output can be redirected to a text file for permanent storage or printing. The message generated is determined by the following:

• If the file passes verification, the message indicates success for that file.

• If the file fails verification, the message indicates failure for that file. The message includes a list of the line numbers of the first 32 records failing verification.

• If the file does not contain a final journal signature record, the message includes a warning.

Verify the event journal



To verify the event journal:

1. From Start > Programs > Accessories, select Command Prompt.

2. In the Command Prompt window, navigate to the Batch\bin directory.

3. If installed to the default directory, type cd C:\Program Files\RockwellSoftware\batch\bin and press Enter.

4. Type batchsig.exe "C:\Program Files\Rockwell Software\batch\YourProjectName\journals\yourfilename.evt" and press Enter.

OR

Add the following command to redirect the output to a text file: >filename.txt

The path to the .evt file can contain wildcards. To verify all event journal files in the specified journal directory use *.evt instead of the name of a single event journal file. For example, batchsig.exe "C:\Program Files\Rockwell Software\Batch\SampleDemo1\journals\*.evt">C:\batchsig.txt verifies all of the event journals for the SampleDemo1 project and prints the results to the batchsig.txt file.

See also



Legal Notices

Copyright notice





Trademark Notices




Legal Notices



Legal Notices


Warranty












A ADDEVENT 67 area model

fields 9 file format example 9

E electronic batch records

description 65 entries 67

event journal 65 entries 67 fields 65

events customize 67

execute ADDEVENT 67

F file types 5

L Language Neutral Format (LNF) 62

M material parameters 67

P parameters

material 67

R RDB tables 45

bindpreferencespecifiers table configuration 60 bindrequirementspecifiers table configuration 60 formula table configuration 54 header table configuration 46 link table configuration 54 recparam table configuration 49

step table configuration 50 transfer table configuration 56 transition table configuration 53 unitreq table configuration 57

Index

Rockwell Automation Publication BATCH-RM111D-EN-P - February 2017

Supersedes BATCH-RM111C-EN-P - November 2014 Copyright © 2017 Rockwell Automation Technologies, Inc. All rights reserved. Printed in the U.S.A.

Rockwell Automation support

Rockwell Automation provides technical information on the web to assist you in using its products. At http://www.rockwellautomation.com/support you can find technical and application notes, sample code, and links to software service packs. You can also visit our Support Center at https://rockwellautomation.custhelp.com for software updates, support chats and forums, technical information, FAQs, and to sign up for product notification updates.

In addition, we offer multiple support programs for installation, configuration, and troubleshooting. For more information, contact your local distributor or Rockwell Automation representative, or visit http://www.rockwellautomation.com/services/online-phone .

Installation assistance

If you experience a problem within the first 24 hours of installation, review the information that is contained in this manual. You can contact Customer Support for initial help in getting your product up and running.

United States or Canada 1.440.646.3434

Outside United States or Canada Use the Worldwide Locator available at http://www.rockwellautomation.com/locations , or contact your local Rockwell Automation representative.

New product satisfaction return

Rockwell Automation tests all of its products to ensure that they are fully operational when shipped from the manufacturing facility. However, if your product is not functioning and needs to be returned, follow these procedures.

United States Contact your distributor. You must provide a Customer Support case number (call the phone number above to obtain one) to your distributor to complete the return process.

Outside United States Please contact your local Rockwell Automation representative for the return procedure.

Documentation feedback

Your comments will help us serve your documentation needs better. If you have any suggestions on how to improve this document, complete the feedback form, publication RA-DU002.

http://www.rockwellautomation.com/support

https://rockwellautomation.custhelp.com/

http://www.rockwellautomation.com/services/online-phone

http://www.rockwellautomation.com/locations

http://literature.rockwellautomation.com/idc/groups/literature/documents/du/ra-du002_-en-e.pdf

Documents

FactoryTalk Batch Technical Reference Guide Volume 1literature.rockwellautomation.com/idc/groups/literature/documents/... · FactoryTalk Batch PCD Programmer Technical Reference Guide