PI Batch End-Triggering Event combinations Data Source PIBatch End-Triggering Event(s) DeltaV EVT The batch recipe event containing [Event] field = “State Change” and [Pvalue] field = “REMOVED” DeltaV EVT with /ubr switch enabled The first out of two recipe events is used to set an End Time for PIBatch object. The batch recipe event containing [Event] field = “System Message” and [Pvalue] field = “End Of BATCH” The batch recipe event containing: [Event] field = “State Change” and [Pvalue] field = “REMOVED”/ ”COMPLETE” / ”ABORTED” DeltaV SQL The batch recipe event containing: [EventType] field = “State Change” and [EventDescript] field containing substring “REMOVED” is used to set the End Time for PIBatch. This event is retrieved from “dbo.brecipestatechangeview” or “dbo.batcheventview” views. DeltaV SQL with /ubr switch enabled Uses source batch object [DeactivateTime] retrieved from SQL “dbo.batchview” table. Batch Recipe type is provided for each object by the data source. DeltaV OPCAE The BATCH-EVENT event with Event Attribute [6] = “REMOVED” is used to set an End Time for PIBatch object (0 based index) Note, batch recipe type is determined by any of the BATCH-EVENT’s containing explicit action, such as Procedure Started/Finished, UnitProcedure Started/Finished, etc. PIUnitBatch A PIUnitBatch is created for each unit procedure as defined in the data source. The start and end times of a PIUnitBatch are intended to reflect the onset and completion of physical processing within a unit. The PIUnitBatch properties do not change if the parent object is a merged PI Batch. PIUnitBatch always contains original BatchID and Procedure name as it is defined in the source unless /tbid parameter was specified in command line parameters. This parameter enforces a stripped BatchID to be used for PIUnitBatch objects and for all events to be stored in PIPoints and PIProperties. When Operation or Phase level recipes are run, the interface uses the Operation/Phase name as the PIUnitBatch Procedure name.
DELTAV SQL +OPCAE (NO /ubr switch available) DeltaV SQL +OPCAE required English definitions: Category Can be found in SQL Column OPCAE BATCH-EVENT attribute index English Definitions Equipment Arbitration N/A Attr[6] Resource Acquired by recipe N/A Attr[6] Resource Released by recipe Batch Recipe N/A Attr[6] Procedure Started N/A Attr[6] Procedure Finished N/A Attr[6] Unit Procedure Started N/A Attr[6] Unit Procedure Finished N/A Attr[6] Operation Started N/A Attr[6] Operation Finished N/A Attr[6] Phase Started N/A Attr[6] Phase Finished [EventType] N/A State Change N/A Attr[6] State Changed State Changes N/A Attr[6] LOAD [EventDescr] N/A CREATED [EventDescr] Attr[8] RUNNING [EventDescr] Attr[8] COMPLETE [EventDescr] Attr[6], Attr[8] REMOVED [EventDescr] Attr[8] STOPPED [EventDescr] Attr[8] ABRORTED Additional (if /ras switch is used) [EventType] N/A Report Sample German EVT required and optional event translations (when /ubr is used): // [S88 Levels] translate: “Grundrezept” = “Procedure” translate: “Teilrezept” = “Unit Procedure” translate: “Grundoperation” = “Operation” translate: “Grundfunktion” = “Phase” // [Batch Header info] translate: “Rezeptkopf” = “Recipe Header” translate: “Produktcode” = “Product Code” translate: “Formelkopf” = “Formula Header” translate: “Formelname” = “Formula Name” // [Arbitrations]
Tag[#].UnitAlias Optional Same as for Name property This property defines the unit level alias name structure for specific template tag. The contained field can be defined as exact phrase or mask. If resulting Alias Name contains illegal characters such as * ‘ ? | ` “ then these characters are replaced by “_” character. Starting with interface version 1.0.1.0 optional sub unit module path can be specified in alias name. “\” symbol should be used to separate parent\child modules and “|” symbol should be used to separate module path and the actual alias name. Default: uses Name property as unit level alias name and [unit] module as alias location. Note: The names for PI Aliases must be unique. Starting from version 1.0.2.0, interface allows creating aliases on PI modules based on absolute module path. This can be achieved by placing the ‘$’ sign as the first module in module path. ‘$’ stands for root module. If /smp=<Start Module Path> switch is used – then ‘$’ is the leaf node of the hierarchy created from start module path. If no /smp switch in command line, then ‘$’ is the actual PI MDB root node. Example 1: Tag[1].UnitAlias = [phasemodule] State alias This alias is going to be created on particular [Unit] module with alias name as [phasemodule] State alias Example 2: Tag[2].UnitAlias = ABC\def | [phasemodule] State alias This alias is going to be created under [Unit]\ABC\def module tree with alias name template as [phasemodule] State alias Example 3: Tag[3].UnitAlias = $ \[Area] | [phasemodule] State alias In this example, assume no /smp switch is defined in command line and [Area]=”AREA_A” and [PhaseModule]=”PH101”. Then the interface is going to create hierarchy as (PI MDB) \ AREA_A And place an alias named “PH101 State alias” under AREA_A node.
expression, which can be defined as Event Type itself (Example below: event type – Comment) or combination of placeholders, which is treated with AND logic. Providing multiple trigger expressions as below is treated with OR logic. Tag[12].Name = [Unit] Tester Tag[12].Value =[pval]-[Event] Tag[12].Type = string Tag[12].Trigger = [Event, value=”Report”] Tag[12].Trigger = [Event, value=”State Change”] Tag[12].Trigger = Comment Tag[12].unitalias = Testing [Unit] Tag[12].phasealias = Testing phase alias Note: In this example we do not have the [PhaseModule] placeholder or actual phase name embedded in the Tag Template Name. Therefore, phasealias will not be created or verified. Assume that we have 4 incoming events: Event 1 contains the following fields populated as: [Time]=08/12/2008 13:00:05.123 [Event]=Report [Unit]=U101 [Pval]=123.456 Event 2 contains the following fields populated as: [Time]=08/12/2008 15:20:01.998 [Event]=State Change [Unit]=U101 [Pval]=HOLDING Event 3 contains the following fields populated as: [Time]=08/12/2008 18:49:12.020 [Event]=Comment [Unit]=U101 [Pval]=Discard Product and Event 4 contains the following fields populated as: [Time]=08/12/2008 21:49:14.025 [Event]=Comment [Unit]= [Pval]=Discard Product As result, the Tag Template only gets triggered for the first 3 events. The last incoming Event 4 does not have the [Unit] field populated; therefore the Tag Name structure is not complete and cannot be processed. All events result in tag name as “U101 Tester” and tag unit level alias name as “Testing U101”. The resulting events are stored to PI as follows: Event TimeStamp Event Value (string) 08/12/2008 13:00:05.123 123.456-Report 08/12/2008 15:20:01.998 HOLDING-State Change
2000.05.17 14:07:45 Unit Procedure Finished System Message 0 2000.05.17 14:09:05 Procedure Finished. System Message 0 2000.05.17 14:09:05 System Message End Of BATCH Procedure End time assigned to the PIBatch.
/maxstoptime=<seconds> Optional Default: 120 seconds The /maxstoptime parameter is used to set the maximum time allowed for the Interface to properly shutdown. The value must be given in seconds. If the Interface shutdown process takes longer than the specified time, the Interface will be forced to terminate immediately. /MaxQTF=<days> Optional (affects only DeltaV SQL source) Maximum Query Time Frame. This parameter sets the maximum time frame for each query made to source. The value can be fractional. Valid range of values: 0.001 to 180 Default: 30 Example: if /rst=01/01/2005 and /ret=12/30/2007, then the actual data time frame to be processed is ~2 years. This can be very memory intensive and potential run out of memory. With the help of this parameter, the interface is going to break 2year query into smaller sub queries with time frame = 30 days each by default. So the actual queries will be performed with the following time frames: [01/01/2005 – 31/01/2005] [31/01/2005 – 02/03/2005] [02/03/2005 - 01/04/2005] Etc.
Sample INI file – DeltaV German EVT Source [SOURCE TEMPLATE] source[1].evtdir = D:\TEST\evt german\evt [GENERAL] ExcludeStates = NONE [TAG TEMPLATE] tag[1].Name = German Report tag[1].Value = [Descript]:[event][pVal] tag[1].Type = string tag[2].Name = German Bericht tag[2].Value = [Descript]:[event][pVal] tag[2].Type = string tag[3].Name = German Bericht float tag[3].Value = [pVal] tag[3].Type = float [PROPERTY TEMPLATE] Property[1].Value = [Time] Bericht [Unit] [phasemodule] [descript]-[Pval] Property[2].Value = [Time] report [Unit] [phasemodule] [descript]-[Pval] [TRANSLATIONS] // [S88 Levels] translate: “Grundrezept” = “Procedure” translate: “Teilrezept” = “Unit Procedure” translate: “Grundoperation” = “Operation” translate: “Grundfunktion” = “Phase” // [Batch Header info] translate: “Rezeptkopf” = “Recipe Header” translate: “Produktcode” = “Product Code” translate: “Formelkopf” = “Formula Header” translate: “Formelname” = “Formula Name” // [Arbitrations] translate: “Rezeptzuteilung” = “Recipe Arbitration” translate: “Betriebsmittel belegt durch Rezept” = “Resource Acquired by recipe” translate: “Betriebsmittel freigegeben durch Rezept” = “Resource Released by recipe” translate: “Teilanlage” = “Unit” // [Recipe Logic, Comment needed only if there is an extra column in DeltaV, so event can be converted to // Comment event] translate: “Zustands\E4\nderung” = “State Change”
“TemplateModuleList::Verify: Error, <error description>” The errors containing message above mean that there is an incorrect data provided while defining Equipment module structure. Refer to error description for hints and check your input in initialization file. “[REQUIRED PARAMETERS]: <error description>” OR “[MISSING REQUIRED COMMAND LINE PARAMETERS] : <error description>” The errors containing message above generally mean that there are missing parameters in either command line or in initialization file required for interface startup. Please refer to error description to resovle the error. “Main: Error, Failed to set Numerical Settings to : [anguage]” The value provided for /ns switch in command line parameters is invalid, please check your input. “check_SDK_version: Error: Too Many fields in PI SDK Version” The interface failed to identify the PI SDK version number. Please consult with OSIsoft technical support to resolve this error. “check_SDK_version: Error, This is an Old PI SDK Version, Please upgrade to <minimum SDK version> or higher.” The PI SDK version installed on the interface node is lower than the minimum required by the interface version of the PI SDK. Please download and install new version of PI SDK. “set_PISDK_GUID: Error, The Interface failed to identify itself to the PI Server, appID = NULL. Terminating.” The interface failed to broadcast its Global Unique ID to the PI server. Please contact OSIsoft technical support to resolve this error. “OpenPIConnection: Error, PI Server <collective name\PI server name> is a SECONDARY Server. The interface is designed to run only against PRIMARY PI Server. Terminating.” The current version of the interface is designed to run only against primary server if used in the Collective configuration. Change the /host switch value and restart the interface. “netsafe::FindCreateMonitorTags: ERROR, Failed to Add <object description>” Errors, containing the messages above, are memory allocation related errors. Generally mean that the Interface node is out of memory. Release some memory by closing unused applications and restart the interface. “StartHealthMonitor: Error, Failed to start health monitor thread. [error number]:<error description>” This is windows related error, check error description.