Ground floor Block D Gilloolys View Office Park 1 Osborne Road Bedfordview

Tel: 0861-WONDER Fax: (011) 607-8478

System Platform 3.0

Implementing Best Practices

REV 1 [2008-09-18]

ERNST.VANWYK@WONDERWARE.CO.ZA

Objectives
The objective of this training is to focus attention on project building by touching on all steps required and explaining some of the best practices and reasoning behind it. This training is not intended as a first glance at InTouch or ArchestrA. In fact: It is recommended that the student have at least some familiarity with the IDE, InTouch as well as ArchestrA graphics.

Table of contents
Module 1 _________________________________________________________________ 5
1. The Basics _________________________________________________________________ 5
1.1. Base object derivation ____________________________________________________________ 5 1.1.1. Base level _________________________________________________________________ 5 1.1.2. Master Level _______________________________________________________________ 6 1.1.3. Application Level ___________________________________________________________ 6 1.2. Toolset Organisation _____________________________________________________________ 8 1.3. S95 __________________________________________________________________________ 8

Lab 1 Building the Base Galaxy ________________________________________________ 10

1.1. 1.2. 1.3. Create the toolsets ______________________________________________________________ 10 Derive the Base Level Templates __________________________________________________ 11 Derive S95 Master level templates _________________________________________________ 12 13 14 14 14 14 14 14 15

2.

The Project _______________________________________________________________ 13

2.1. The Plant _____________________________________________________________________ 2.2. Control Modules _______________________________________________________________ 2.2.1. Control Valve _____________________________________________________________ 2.2.2. Solenoid Valve ____________________________________________________________ 2.3. Transmitters __________________________________________________________________ 2.3.1. Level Transmitter __________________________________________________________ 2.4. Top level S95 _________________________________________________________________ 2.5. Shared Functionality ____________________________________________________________ 2.1. 2.2.

Lab 2 Building the Master level templates ________________________________________ 17

Derive the templates ____________________________________________________________ 17 Enable Basic functionality________________________________________________________ 17

Module 2 ________________________________________________________________ 19
3. The Application and Types of System objects ___________________________________ 19
3.1. The Application Level___________________________________________________________ 3.2. PLC IO addressing _____________________________________________________________ 3.3. System Objects ________________________________________________________________ 3.3.1. $Area ___________________________________________________________________ 3.3.2. $WinPlatform _____________________________________________________________ 3.3.3. $AppEngine ______________________________________________________________ 3.3.4. $ViewEngine _____________________________________________________________ 3.1. 3.2. 3.3. 3.4. Creating the System Objects ______________________________________________________ Create Application level objects ___________________________________________________ Implement auto IO addressing_____________________________________________________ Set-up Redundancy _____________________________________________________________ 19 19 19 20 20 20 21 22 24 24 26

Lab 3 Building the Application level templates ____________________________________ 22

4.

Instantiation and Deployment _______________________________________________ 27

4.1. 4.2. Instantiation___________________________________________________________________ 27 Deployment___________________________________________________________________ 28

Lab 4 Making it work ________________________________________________________ 29

3

4.1. 4.2. 4.3. 4.4.

Instantiate the Top level and System objects __________________________________________ Instantiate One Mix Line_________________________________________________________ Utilise galaxy dump/load_________________________________________________________ Set up the deployment ___________________________________________________________

29 29 30 31

Module 3 ________________________________________________________________ 33
5. Graphics _________________________________________________________________ 33
5.1. 5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 5.7. 5.8. 5.9. 5.10. Graphic Toolbox _______________________________________________________________ 33 Create a Panel standard __________________________________________________________ Build Button standard ___________________________________________________________ Build Valve standard ____________________________________________________________ Build a Level Transmitter Standard_________________________________________________ Build Master level Control Valve __________________________________________________ Build Master level, Solenoid Valve _________________________________________________ Build Master level, Level Transmitter _______________________________________________ Build Application level tank graphic ________________________________________________ Preparing to create InTouch Screens ________________________________________________ Create the Overview graphics _____________________________________________________ 35 37 39 40 40 41 41 41 42 42

Lab 5 Creating the standards __________________________________________________ 35

6.

The InTouch Application ___________________________________________________ 44

6.1. 6.2. 6.1. 6.2. 6.3. 6.4. 6.5. Navigation ____________________________________________________________________ 44 Data transfer __________________________________________________________________ 44 Create a new InTouch Application _________________________________________________ Build the Navigation system ______________________________________________________ Build a Standard Show Window Button _____________________________________________ Build a Navigation Bar __________________________________________________________ Create the InTouch Windows _____________________________________________________ 45 45 46 46 47

Lab 6 Build the InTouch ______________________________________________________ 45

Module 4 ________________________________________________________________ 48
7. Assistant Graphics _________________________________________________________ 48
7.1. 7.2. Create an assistant Button ________________________________________________________ 49 Using an assistant button _________________________________________________________ 49 Show symbol__________________________________________________________________ 50 InTouch Windows______________________________________________________________ 50 Creating the popups_____________________________________________________________ Creating object specific pop-ups ___________________________________________________ Change Equipment Symbols ______________________________________________________ Enable the Level Transmitters popup _______________________________________________ 51 53 54 54

Lab 7 Creating and using an Assistant graphic ____________________________________ 49

8.

Popup graphics ___________________________________________________________ 50

8.1. 8.2. 8.1. 8.2. 8.3. 8.4.

Lab 8 Creating Popups _______________________________________________________ 51

Module 1
Derivation and Model
1. The Basics
Before a project is attempted it is necessary to perform some basic steps. This will result in a base galaxy that should always be the starting point of a new project. These steps require some thought and include the following: Base object derivation Toolset organisation Modelling standard

1.1. Base object derivation

System Platform galaxies ship with several default templates (e.g. $WinPlatform, $UserDefined etc.). These templates should never be instantiated directly as they cannot be modified.

Best Practice
Never instantiate objects directly from top level (default) templates
Top level (default) templates cannot be modified this means that all changes must be made in instances (of which there may be many)

It should always be remembered that derivation implies the sharing of functionality. Derivation view indicates which objects share functionality and capability with which. A parent objects capabilities are inherited by a child object.

1.1.1. Base level

All Default templates that will be required should be derived to a first level of derivation called the Base Level derivation. These templates should be prefixed with b_. These templates will normally be an unmodified version of the default templates but it does provide the opportunity to implement certain capabilities to all descendants of them, for instance a Debug Property. Examples would be: $b_UserDefined and $b_WinPlatform.

1.1.2. Master Level

Master objects are the standards of the enterprise. They are prefixed with an m_. Master objects are derived from base objects and not from top-level (default) objects. Master objects are normally enforced Standards (e.g. what properties should at a minimum be present in the template) or Enterprise specific standards (i.e. an object representing a physical asset that is used in all parts of the enterprise and should be standard e.g. $m_LIMS). Master objects can also be lower derivatives of the abovementioned objects, but should contain no Application specific functionality (e.g. $m_Valve $m_ControlValve).

Generally IO assignment can be viewed as Application specific (since various sites/applications might have different PLCs). IO assignment can be present in Master templates, however, if the method of this assignment should be standardised. Note that if a complex object is required to be standard across all Applications, it should be built in the Master level. This means that Master level templates can already be containers with contained objects.

1.1.3. Application Level

Application type objects are specific to an application this might be functionally specific or PLC specific. Application objects are prefixed with a#_ and are always derived from master objects. The # in the prefix should identify the Application. This can be a project code. Application level objects will be used to instantiate objects. This means that Application level objects can be contained objects. If application specific functionality (such as IO
6

assignment) exists for a master object another a-level derivation is needed. In other words: If all pumps in this application have something in common (such as PLC addressing) but differ from pumps in other applications in the enterprise then an $a#_Pump is required. In this case the derivation will look as shown.

In the following example System Integrator A (SIA) designed a Mixing Tank with an Agitator. They designed their own Agitator with their custom code ($a0_Agitator). Later System Integrator B (SIB) designed a Reactor for the company it also requires an Agitator, but this one has some differences to that of SIAs. Even though both SIs standardised on $m_Agitator, they have made different implementations of it.

Best Practice
Create three levels of derivation (Base, Master and Application)
Base level templates allow propagation of asset independent functionality across the entire galaxy/enterprise. Master level templates allow the setting of standards without restricting the implementation of those standards. Application level standards allow the individual implementation of master level standards while also providing for splitting different implementations

1.2. Toolset Organisation

Toolsets in the Toolbox should be created to reflect at least the BaseMaster-Application derivation. Toolsets should be numbered to reflect organisation. Further division of toolsets can also be made and again numbering can be used to sort toolboxes into the desired position. When a number is assigned to a specific toolset in one level (e.g. Master level) this number should be used in other levels as well to keep continuity.

Best Practise
Create Numbered Toolsets and hide unused toolsets
Numbered Toolsets can be sorted alphabetically Navigation to standardised tools are easier if they organised into a well-defined structure Hiding unused toolsets prevents the usage of incorrect templates

1.3. S95
It is desirable to have a standard for modelling and the S95 standard is recommended for the top levels.

Collectively known as Work Centres

Collectively known as Work Units

The concept is implemented in the three levels (Base, Master and Application). The Base level has no relevance here except for the fact that a decision needs to be made as to which S95 levels should derive from $b_Area and which ones from $b_UserDefined. Usually the distinction is made between Work Centres and Work Units in the S95 model,
8

with Work Centres and higher hierarchical objects deriving from $b_Area and Work Units and lower objects from $b_Userdefined.

Best Practice
Implement the S95 standard for the plant model
This standard is international and will make an application more understandable for other users/developers. The standard has been well thought through and alleviates the developer from this responsibility.

Lab 1 Building the Base Galaxy

Notice that at this point no clue has been given as to what application will be built or who the end-user is. Not even a P&ID drawing has been made available yet. The point is this: This part of the galaxy is application independent.

1.1. Create the toolsets

To create a new toolset called 0. Base Templates: o Open the Template Toolbox o Right-Click the Galaxy Name o Click New Template Toolset o Type 0. Base Templates (without the Quotes) o Press Enter Create two more toolsets called o 1. Master Templates o 2. Application 0 Templates Under each of these toolsets create three more toolsets o 1. System o 2. Application o 3. Device Integration Under the 1. Master Templates | 2. Application toolset create the following toolsets: o 1. S95 Top Level o 2. S95 Wok Centres o 3. S95 Work Units o 4. S95 Modules Due to time constraints it is not possible to let everyone create every toolset. Instead, follow this procedure to create the toolsets quickly: o Delete the 0. Base Templates by following this procedure Click on 0. Base Templates Press the Delete button Click Yes to delete the toolset and all the subsets o Delete the following toolsets 1. Master Templates 2. Application 0 Templates o Click on Galaxy | Configure | Customise Toolsets o Select the Toolset called Super Secret hidden Toolset o Click on the Close Button o Click and drag the Toolsets below Super Secret hidden Toolset onto the Galaxy o Delete Super Secret hidden Toolset

10

1.2. Derive the Base Level Templates

To Derive a base-level Template for $UserDefined: o Right-click $UserDefined o Navigate to New | Derived Template o Rename the new template to b_Userdefined Derive new base-level templates for: o AppEngine o Area o ViewEngine o WinPlatform o Sequencer o OPCClient Move the base level templates into their respective toolsets as shown.

Move $InTouchViewApp into the 0. Base Templates |1. System Toolset (this template is the InTouch application and can only be derived once) Hide the Original System toolset o Right-click the System toolset o Click Hide Hide the other original toolsets: o Application o Device Integration

11

1.3. Derive S95 Master level templates

Will create SystemsAreas Later

From $b_Area derive a $m_Enterprise with the following procedure: o Right-click $b_Area o Click on New | Derived Template o Change the name to m_Enterprise Derive the following S95 templates from $b_Area o $m_Site o $m_Area o $m_WorkCentre Derive the following S95 templates from $m_WorkCentre: o $m__ProcessCell (Notice the double Underscore) o $m__ProductionLine o $m__ProductionUnit o $m__StorageZone Derive the following from $b_UserDefined o $m_WorkUnit o $m__ControlModule o $m__EquipmentModule o $m__Transmitter Derive the following from $m_WorkUnit o $m__ContinuousUnit o $m__StorageCell o $m__Unit o $m__WorkCell Move the Templates to their correct toolsets as shown Notice that the double underscore used in some of the templates will ensure that those templates always appear at the top of the particular toolset.

12

2. The Project 2.1. The Plant

The End-client is a company called GummiBears Incorporate. The company has several production sites, some bottling sites and two packaging sites. This project will be the pilot project for the complete enterprise. Production sites have several distinct areas with the biggest being the Extract Mixing Area. The Pilot project is for the Extract Mixing Area in one of the production sites. The Sherwood Forest site has been selected for the Pilot. The Extract Mixing Area consists of several Mixing Lines (The

Sherwood Forest one has four designated S_E_MX001 to S_E_MX004). Each mixing line has two tanks used to premix extracts used in production. A P&ID is shown for one mix line (all four are identical). The client also supplied a list of PLC blocks for the various equipment types. Notice that the Solenoid Valve PLC block does not calculate the travelling time. The client has however requested that this calculation be made in the ArchestrA framework. The client has also indicated that other Sites have tanks that contain more or less inlet valves. The PLC block naming scheme is built using one or two letter acronyms for Process cells (PC), Units (UN), Control Modules (CM) and Transmitters (TX) and three figure numbers for each of these (###). These numbers are separated by underscores. A generic example would look as follows: PC###_UN###_CM### Some of the acronyms are listed below Mixing Line = MX Tank = T Inlet Valve = IV Outlet Valve = OV Level Transmitter = LT

13

2.2. Control Modules

2.2.1. Control Valve

Control Valve
Inputs
Cmd.Position

Outputs
Status.Position Status.Open Status.Closed Status.TravellingTime

2.2.2. Solenoid Valve

Solenoid Valve
Inputs Cmd.Open Cmd.Close Outputs Status.Open Status.Closed

2.3. Transmitters
2.3.1. Level Transmitter

Transmitter
Inputs Outputs PV

From the PLC block it is evident that all transmitter types look the same.

2.4. Top level S95

The S95 Enterprise is obviously GummiBears Inc. There seem to be three different types of S95 sites (Production, Bottling and Packaging). There also seem to be different types of S95 areas (at least there is an Extract Mixing Area). The plant in question is most definitely batch orientated this means that Process Cells and Units should be identified. A natural division is presented for this namely the Mixing lines (Process Cells) and Tanks (Units).

14

2.5. Shared Functionality

The Derivation structure in ArchestrA implies shared functionality. When comparing the Solenoid valve and the Control Valve several common capabilities are revealed: Open limit switch Closed limit switch

From the clients request it is also implied that the travelling time should be present in both the valve types. These three properties should be added to a template (called $m_Valve). From this template the Control and Solenoid valves can be derived. A well-defined naming convention should be used for attributes. A suggested naming convention is provided on the next page.

Best Practice
Use a well defined naming convention for all attributes
This will help identify the purpose of an Attribute. It will also identify its context which will assist with the security assignment. It will also allow better sorting (for instance when locating all UDAs that must be configured in design time)

15

Description Set-up parameter set during design time (Typically Startup scripts use them) Configurable parameter Object must be set off scan to change (typically OnScan scripts use them) Engineering Set Point Only certain personnel can change these Calculate value Cannot be changed by anything but a script Set point Operational set points that can be changed by operators Commands When set to TRUE, a function is performed. On completion the value returns to FALSE Mode Select Indicates a specific mode. Stays in state until mode is changed. Process value Typically an Analogue value that is measured with and instrument. Status value Indicates status of something in the field (typically not an Analogue value) Alarms flag Indicates that something is in alarm Interlock flag Indicates that something is interlocked Simulation Attributes Used to simulate something. An object should still be functional if all Simulation Attributes and Scripts are removed

Naming convention Setup.[Attribute].Parameter

Setup.[XML].Folder (Folder is created the first time the object deploys)

Security/Category Read Only

Cfg. [Attribute].Parameter
Cfg.[OrderDataBase].ServerName (Connection is established every time the Engine goes on Scan)

Configure

Eng. [Attribute].SetPoint
Eng.[Feeder].Speed.Maximum (Only Tune permitted users can change the maximum speed)

Tune

Calc. [Attribute].Parameter
Calc.[Cable].Length (Length is calculated from measured weight)

Calculated

SP. [Attribute].SetPoint
SP.[Feeder].Speed (Operating set point speed of feeder)

Operate

Cmd.[Attribute].Command
Cmd.[Feed].Start (Start the Feed sequence)

Depends on command

Select.[Attribute].Mode
Select.[Mode].Auto (Selects the Auto mode)

Depends on mode

[Attribute].PV
[Level].PV (Process value of the Level)

Object Writable

Status.[Attribute].Status
Status.[InletValve].Open (Indicates when the valve is open)

Object Writable

[Attribute/Status/PV].AlarmType.Alarm
[Tank].Level.High.Alarm (Indicates Tank is in alarm because level is high)

Object Writable Object Writable Depends on simulation

[Attribute/Status/PV].InterlockType.Interlock
[Pump].ValveClosed.Interlock (Indicates Pump is interlocked because valve is closed)

Sim.RestofNameparts
Sim.Eng.SimulatedPV.Maximum (Change the maximum simulated PV value)

16

Lab 2 Building the Master level templates

The next step is to start designing enterprise wide standards.

2.1. Derive the templates

Derive the following templates: o $m_MixLine (from $m__ProcessCell) o $m_Tank (from $m__Unit) o $m_Valve (from $m__ControlModule) o $m_ControlValve (from $m_Valve) o $m_SolenoidValve (from $m_Valve) o $m_LevelTransmitter (from $m__Transmitter)

2.2. Enable Basic functionality

Open $m_Valve On the Field Attributes page add a Status.Open Field attribute with this procedure: o Click the button. o Type Status.Open as the Name o Change the Access Mode to Input o Supply a description o Leave the Input source as ---.--- Leaving this will cause an error if the $m_valve is instantiated directly this is correct since there is no auto addressing scheme and directly instantiating the template will cause a problem. Only change the address to --- if an auto addressing scheme is present on that level. Add another identical Field Attribute called Status.Closed

17

Click on the Object Information tab and supply a valid description Click on the UDAs tab Create a Status.TravelTime UDA with the following procedure: o Click the button o Type the name Status.TravelTime o Select the data type as ElapsedTime.

Save and close $m_Valve Open $m_ControlValve Add an Analogue (Float) Field Attribute called Cmd.Position Enter a Description Make the Engineering Units % Add another Analogue (Float) Field Attribute called Status.Position Change the access mode to Input Enter a Description Make the Engineering Units % Save and close $m_ControlValve Open $m_SolenoidValve Add a Discrete Field Attribute called Cmd.Open Enter a Description Add an identical Field Attribute called Cmd.Close Save and close $m_SolenoidValve Open $m__Transmitter Add an Analogue (Float) Field Attribute called PV Change the access mode to Input Enter a Description Make the Engineering Units Litres Save and close $m__Transmitter

18

Module 2
Functionality and Deployment
3. The Application and Types of System objects 3.1. The Application Level
The next step is the implementation of the Application level templates. The Application level templates implement functionality specific to the application. The application can be interpreted as an implementation: By the same System Integrator For the same PLCs For the same Project For the same Area/Type of plant

The lowest level in the Master level should always be derived as the top level of the Application level. At this level the tank can now also be assembled with its contained control modules and transmitters. The Container template should contain only one of each type of control module or transmitter. The tanks in this system contain one or more identical inlet valves, one outlet valve and a level transmitter. The Application level tank template should only contain one inlet valve. This will allow the developer to instantiate the number of valves required while maintaining a derivation structure that does not become unmanageable.

3.2. PLC IO addressing

Typically the PLC addressing scheme is also handled in the Application level. This allows the same standard (e.g. $m_VSD_Motor) to be implemented on different PLCs ($aSiemensS7_VSD_Motor, $aABCIP_VSD_Motor etc.). In this project the PLC used is a DreamPLC and the OPC server is an ArchestrA Dream PLC DA Server. In the ArchestrA model a $b_OPCClient derivative will be used. The derivative is once again not instantiated directly but derived to a Master template (specifying enterprise wide standards) and an Application level template (specifying Application specific configuration). Auto addressing implies that an object (such as a transmitter) can identify itself and its PLC IO address on start-up and automatically assign its addresses. Several methods can be used but a simple one is shown here. It presumes a per object/application prefix indicating the PLC and scan group and a per engine OPC client (which allows a developer to move objects across engines without having to change addressing).

3.3. System Objects

One part that has been neglected up till now is the system objects ($b_WinPlatform, $b_AppEngine etc.). A System Platform implementation usually consists of:

19

Galaxy Repository At least one Application Server At least one View Client

This leads to the following derivations of System objects.

3.3.1. $Area
A $m_SystemsArea template (with its corresponding $a0SystemsArea) is required. This template will be used to house the system objects (Platforms, Engines etc.) in the model view.

Best Practice
Create a Systems Area on an engine running on the GR to contain system objects
This allows rolling up diagnostic data It also provides a logical place for system objects in the model (which would otherwise be hosted under Unassigned Area)

3.3.2. $WinPlatform
There should be at least the following Master level derivations of $b_WinPlatform: $m_GRPlatform $m_AppServerPlatform $m_ViewClientPlatform

Following the BMA derivation scheme this means that the at least the same set of Application level derivations should be made.

3.3.3. $AppEngine
Several types of application engines are also needed. The most obvious is the $m_AppEngine with its corresponding $a0_AppEngine. Two other engines are also required: $m_GREngine ( $a0_GREngine): This engine will house the centralised objects (S95 Enterprise, may be the S95 Site as well as the Systems Area). This engine can also be used to calculate some diagnostic data on the system objects $m_TestEngine ($a0_TestEngine): This engine is used to temporarily host areas with objects still being tested. This engine has a big advantage in that objects can be tested in an environment that can interact with the real environment while only risking the Test Engine and in extreme cases the server hosting the Test Engine. The Test Engine can usually be run on the Galaxy Repository, since the system can function without the Galaxy repository for a fair period of time.

All engines should have a tag pointing to its corresponding Device Integration Object.

20

3.3.4. $ViewEngine
The $b_ViewEngine is derived twice once to the Master level and then to the Application level in keeping with the BMA derivation scheme.

21

Lab 3 Building the Application level templates

In this lab a set of application level objects will be created for the system including Application Engines, Platforms as well as Device Integration objects. The auto addressing scheme is also addressed.

3.1. Creating the System Objects

Open the $b_AppEngine and create a UDA called Cfg.DIObjectName of type String. Set the value to DreamPLCClient Save and close the $b_AppEngine Derive the following Templates o $m_SystemsArea (from $b_Area) o $m_AppServerPlatform (from $b_WinPlatform) o $m_GRPlatform (from $b_WinPlatform) o $m_ViewClientPlatform (from $b_WinPlatform) o $m_AppEngine (from $b_AppEngine) o $m_GREngine (from $b_AppEngine) o $m_TestEngine (from $b_AppEngine) o $m_ViewEngine (from $b_ViewEngine) o $a0_SystemsArea (from $m_SystemsArea) o $a0_AppServerPlatform (from $m_AppServerPlatform) o $a0_GRPlatform (from $m_GRPlatform) o $a0_ViewClientPlatform (from $m_ViewClientPlatform) o $a0_AppEngine (from $m_AppEngine) o $a0_GREngine (from $m_GREngine) o $a0_TestEngine (from $m_TestEngine) o $a0_ViewEngine (from $m_ViewEngine) Place them in the correct toolsets as shown

Derive $m_DreamPLCClient from $b_OPCClient and open it. o Leave the Server Node name blank (this will use the local machine) o Drop down the Server name and select ArchestrA.DreamPLC.1 o Lock the two attributes mentioned above as per Figure on the next page

22

Save and Close

Derive $a0_DreamPLCClient_ExtractMixing from $m_DreamPLCClient. Open $a0_DreamPLCClient_ExtractMixing Click on the Scan Group Tab Add a new ExtractMixing Scan group using this procedure: o Click the button o Type ExtractMixing o Leave the update interval at 500ms

Save and Close

23

3.2. Create Application level objects

Derive the following objects and assign then to the correct Toolsets o $a0_Enterprise from $m_Enterprise o $a0_ProductionSite from $m_Site o $a0_ExtractMixingArea from $m_Area o $a0_MixLine from $m_MixLine (Assign to Work Centre) o $a0_ControlValve from $m_ControlValve o $a0_SolenoidValve from $m_SolenoidValve o $a0_Level_Transmitter from $m_Level_Transmitter o Change all the input Sources for the three above mentioned templates from ---,--- to --o Add an input source extension to the $a0_ControlValve for UDA Status.TravelTime Create a $a0_Tank container using this procedure and assign it to the correct Toolset o Derive $a0_Tank from $m_Tank o Derive a template from $a0_ControlValve and call it InletValve o Drag and drop the InletValve template to the $a0_Tank o Derive a template from $a0_SolenoidValve and call it OutletValve o Drag and drop the OutletValve template to the $a0_Tank o Derive a template from $a0_Level_Transmitter and call it Level o Drag and drop the Level template to the $a0_Tank

3.3. Implement auto IO addressing

For templates $a0_Level_Transmitter, $a0_ControlValve and $a0_SolenoidValve implement the following auto addressing scheme: Create these UDAs o Cfg.IOAssign.Prefix as String (set value to ExtractMixing.PLC.001. excluding quotes but including dots) This indicates the PLC and Scangroup to use. o Cfg.IOAssign.ScanCycle as Integer (set the value to 2 This will determine on which scan cycle the IO addressing takes place) o Status.IOAssign.Complete as Boolean This will indicate that the addressing is complete Create a script called Script.IOAssign with this procedure o Click on the Scripts tab o Click the button o Type Script.IOAssign o In the Expression type me.Status.IOAssign.Complete

24

o o

Select the Trigger type as WhileFalse Lock all of the Locks

On all three add the following code:

IF me.Script.IOAssign.ExecutionCnt >= me.Cfg.IOAssign.ScanCycle THEN DIM ThePrefix AS STRING; ThePrefix = myEngine.Cfg.DIObjectName + "." + me.Cfg.IOAssign.Prefix + StringRight(me.Tagname,StringLen(me.Tagname)-4)+"."; {Add Template specific code here} me.Status.IOAssign.Complete = TRUE; ENDIF; Add the specific code pieces as indicated: o Control Valve

'FA Inputs me.Cmd.Position.Input.InputSource = ThePrefix + "Cmd.Position"; me.Cmd.Position.Output.OutputDest = ThePrefix + "Cmd.Position"; 'FA Inputs me.Status.Position.Input.InputSource = ThePrefix + "Status.Position"; me.Status.Closed.Input.InputSource = ThePrefix + "Status.Closed"; me.Status.Open.Input.InputSource = ThePrefix + "Status.Open"; 'UDAs me.Status.TravelTime.InputSource = ThePrefix + "Status.TravelTime"; o Solenoid Valve

'FA In and Outs me.Cmd.Open.Input.InputSource = ThePrefix + "Cmd.Open"; me.Cmd.Open.Output.OutputDest = ThePrefix + "Cmd.Open"; me.Cmd.Close.Input.InputSource = ThePrefix + "Cmd.Close"; me.Cmd.Close.Output.OutputDest = ThePrefix + "Cmd.Close"; 'FA Inputs me.Status.Closed.Input.InputSource = ThePrefix + "Status.Closed"; me.Status.Open.Input.InputSource = ThePrefix + "Status.Open";
25

Level Transmitter

'FA Inputs me.PV.Input.InputSource = ThePrefix + "PV";

Best Practice
Prefix all Scripts with an identifier such as Script. and give descriptive names
The prefix will help identify scripts (and sort them together) in Object Viewer. Descriptive names always give a first indication as to the purpose of a script

3.4. Set-up Redundancy

Open the $a0_AppEngine Go to the Redundancy tab Select the Enable Redundancy tick (Application engines in this system will be redundant by default)

26

4. Instantiation and Deployment 4.1. Instantiation

Single instantiations of objects are very intuitive (drag and drop) and the S95 model can be followed until the lower levels are reached: These are usually addressed by the P&ID drawings. The tedious part is usually the instantiation of many instances. This can be accomplished by using the Galaxy Dump/Load operations. The concept is fairly simple: Create a single instance each of the repeated items and then export the Galaxy to CSV format. The CSV can then be modified to only retain the relevant columns. Duplicate the entries and set up the multiple instances in the CSV. This CSV can then be imported resulting in the correct configuration.

Best Practice
Use Galaxy load function with minimum columns to create multiple instances
This method allows a developer to leverage the power of Excel to design the model. The method also provides better consistency as it is easier to recognise discrepancies in Excel.

The Galaxy load function will also assist in getting the correct contained names of objects. All objects have at least one name called the Tag name. Contained objects also have a second name called the Contained name. When referencing any object or tag in an ArchestrA galaxy the first object of the reference should always be a Tag name except if the reserved relative referencing words are used (me, mycontainer, myarea, myEngine etc). Only one Tag name can be used in a reference. An example would be: ATagname.ContainedName1.ContainedName2.ContainedName3.Attribute The tag name is the objects identity no other object may have the same tag name. A tag name uniquely identifies an object in the galaxy. A solid naming convention is highly recommended. A good example of this would be the ANSI ISA S5.1/1984 (R1992) standard. A contained name uniquely identifies an object within its container other objects in the galaxy may have the same contained name but not if they are in the same container. It is desirable to make the contained name descriptive of its role or function in the container e.g. Fan_Motor, Jacking_Oil_Pump, Inlet_Valve etc.

Best Practice
Make contained names descriptive
This allows a user to easily navigate into an object without the need to know the exact name of the contained object e.g. T001.Level might mean more than LT003

The actual instantiation is done from the Application level templates.

27

Best Practice
Always instantiate objects from the Application level
This is done for consistency It also helps future proof the solution by always providing a level for implementing a standard and a level for implementing specific customisation.

4.2. Deployment
Once the galaxy is in a state to commence with the first deployment, consideration should be given to future performance. System Platform can utilise multiple CPUs and CPU cores on a server and the best way of leveraging that capability is to split instantiate two engines per CPU core (these include backup engines). Ensure that each engine has its own OPC client to the PLC.

28

Lab 4 Making it work

This lab is about getting it all to work i.e. instantiating the objects and deploying them.

4.1. Instantiate the Top level and System objects

Instantiate a $a0_Enterprise object called GummiBearsInc with the following procedure: o Right-Click $a0_Enterprise o Navigate to New | Derived Instance o Type GummiBearsInc and press Enter Now instantiate the following: o SherwoodForest from $a0_ProductionSite o Drop SherwoodForest onto GummiBearsInc Use Shift F2 to change the contained name to ProductionSite_001 o S_ExtractMixing [ExtractMixing_001] from $a0_ExtractMixingArea (Contained name in Square brackets) o Drop S_ExtractMixing onto SherwoodForest o SystemsArea [SystemsArea] from $a0_SystemsArea o Drop SystemsArea onto GummiBearsInc Derive the following Instances: o From $a0_GRPlatform GRPlatform o From $a0_AppServerPlatform AOS_01 AOS_02 o From $a0_ViewClientPlatform ViewClient_01 o From $a0_AppEngine AppEngine_001 AppEngine_002 AppEngine_003 AppEngine_004 o From $a0_GREngine GREngine o From $a0_TestEngine TestEngine_001 o From $a0_ViewEngine ViewEngine_001 o From $a0_DreamPLCClient_ExtractMixing DreamPLCClient_001 DreamPLCClient_002 DreamPLCClient_003 DreamPLCClient_004 DreamPLCClient_GR DreamPLCClient_Test Organise them as shown

4.2. Instantiate One Mix Line

Set the S_ExtractMixing Area as the Default with these steps:
29

o Right-click S_ExtractMixing o Click Set as Default Derive the following Instances: o From $a0_MixLine S_E_MX001 [MixLine_001] note that it appears under S_ExtractMixing Set S_E_MX001 as default o From $a0_Tank S_E_MX001_T001 note that the Inlet, outlet valves and transmitters are automatically created S_E_MX001_T002 o From $a0_Tank.InletValve S_E_MX001_T001_IV002 [InletValve_002] S_E_MX001_T002_IV002 [InletValve_002] Drag S_E_MX001_T001_IV002 into S_E_MX001_T001 Drag S_E_MX001_T002_IV002 into S_E_MX001_T002 Rename o InletValve_001 to S_E_MX001_T001_IV001 Change Contained name to InletValve_001 o InletValve_002 to S_E_MX001_T002_IV001 Change Contained name to InletValve_001 o Level _001 to S_E_MX001_T001_LT001 o Level _002 to S_E_MX001_T002_LT001 o OutletValve_001 to S_E_MX001_T001_OV001 o OutletValve_002 to S_E_MX001_T002_OV001 o Make sure that the two second InletValves have the correct contained Names Note that errors are present o Right-click any object with an error (e.g. S_E_MX001_T001_OV001) o Click Properties o Click on the Errors/Warnings Tab o Note the warning states that the Cfg.DIObjectName could not be found on myEngine. This is because these objects have not been assigned to an Engine yet (i.e. myEngine does not exist for them).

4.3. Utilise galaxy dump/load

Select everything under S_ExtractMixing Right-click anywhere on the selection Navigate to Export | Galaxy Dump Supply a file name for the CSV file o Do not overwrite the existing ExtractMixing.CSV file Open Explorer (Windows Key + E) Navigate to the CSV file Double-click the file

30

Caution
Double-clicking a CSV file to open in Excel can sometimes take a very long time to open. This is due to a bug that was re-introduced into the Office suite with version 2007. Do not attempt to close the Excel as it will continue loading the document and then when it is done close
Select the A column by clicking on the A On the menu click Data In the Data Tools Group, click Text to Columns Select the Delimited option Click Next Select the Comma delimiter Click Finish For multiple instantiation, everything up to column E (Contained Name) is required delete the rest they are optional The Excel file can now be manipulated to create multiple named instances.

Caution
The initial export is done in Unicode but Excel does not save the Unicode in the same format. One should always use the Save as function and select the output type as CSV.
Creating the Excel file can be time consuming so a pre-built CSV is supplied under My Documents\The Lazy Folder Import the ExtractMixing.CSV file into the Galaxy with these steps o Click on Galaxy on the Menu o Navigate to and click Import | Galaxy Load o When completed check in Mixing line 001 objects

4.4. Set up the deployment

Assume the client has 2 application servers with single Duo Core CPUs. The total number of cores will therefore be 4 (2 per server). This means 8 Engines (4 Primary and 4 Backup). It is for this reason that 4 Application Engines (AppEngine_001 to 004) have already been instantiated Click on the Deployment View Drag and drop the following Application Engines onto their respective platforms o GREngine onto GRPlatform o TestEngine_001 onto GRPlatform o AppEngine_001 onto AOS_01 o AppEngine_002 onto AOS_01 o AppEngine_003 onto AOS_02 o AppEngine_004 onto AOS_02 o AppEngine_001 (backup) onto AOS_02 o AppEngine_002 (backup) onto AOS_02 o AppEngine_003 (backup) onto AOS_01 o AppEngine_004 (backup) onto AOS_01
31

Drag ViewEnginew_001 onto ViewClient_01 Drag and drop the OPC clients to their respective Application Engines Open each engine end ensure that the Cfg.DIObjectName on each engine is set to the respective OPC client. o DreamPLCClient_Test onto TestEngine_001 o DreamPLCClient_GR onto GREngine o DreamPLCClient_001 onto AppEngine_001 o DreamPLCClient_002 onto AppEngine_002 o DreamPLCClient_003 onto AppEngine_003 o DreamPLCClient_004 onto AppEngine_004 Drag the following areas onto the GREngine o GummiBearsInc o SherwoodForest o S_ExtractMixing o SystemsArea The Areas would normally now be split between the Application engines to even the load among the Engines. However, since only a Galaxy Repository Server is available, all the areas will be deployed to the Test Engine on the Galaxy Repository. o Drag and drop the four mixing lines (S_E_MX001 to S_E_MX004) onto the TestEngine_001. At this point the Simulation is also required Import the simulation objects into the galaxy with these steps: o Click on Galaxy o Navigate to Import | Objects o Navigate My Documents\The Lazy Folder o Double-Click Simulation.aaPkg Right-Click on the GRPlatform Click Deploy Ensure Cascade Deploy is selected Click OK

32

Module 3
Graphics
5. Graphics 5.1. Graphic Toolbox
All graphics should begin their lives in the Graphic toolbox. The Graphic Toolbox contains, by default, the ArchestrA Symbol Library. This library should be left intact and a new library should be created and appropriately named. This library can contain several types of graphics. A simple division of the toolbox would look as follows: Independent Graphics: These graphics have specific functions but work independently from the ArchestrA Galaxy. Typically navigational tools are examples of these. Standard Graphics: These graphics are used as parts or components of Independent graphics or object specific graphics. These graphics are built as self contained graphics exposing only those custom properties required to use the graphic. Assistant Graphics: These graphics are typically implemented standard graphics which require additional action scripting as such the scripting in the standard needs to be exposed to the end-user. This is accomplished by reapplying the standards scripting on the standard (which is set to be treated as an icon which will override the original scripts). This is then stored as an assistant graphic. To use it: Embed it, Convert it to a group and ungroup it.

Best Practice
Create self contained graphics in the graphic toolbox with only one level of custom properties exposed
This allows the implementation of standards changes are made in a central place These graphics are embedded wholly into objects and only configured there this allows the developer to set the owning object of the graphic thereby making it dynamic Custom properties from embedded graphics should be propagated to the main graphic and marked as private in the embedded graphic This will hide confusing multi-level properties from end-users.

Graphics can have multiple levels of embedment. Although this is a very powerful function, it presents some opportunities for confusion if not treated with respect. The following is a list of things to do when working with graphics: Always name elements (embedded graphics or graphical elements) with descriptive names Supply descriptions for graphics

33

If a graphic that is embedded has public custom properties, create those properties in the outside graphic and let the embedded graphic reference those properties mark them as private in the embedded graphic Always supply descriptions with custom properties especially public properties.

These same rules can be applied to using graphics from the ArchestrA Symbol Library.

Best Practice
If a symbol library symbol is used as a standard and changes are to be made to it, make a copy of the symbol and use the copy. If no changes are to be made: use the symbol directly
Using a symbol directly allows the user to benefit from any future upgrades made to the symbol by Wonderware

34

Lab 5 Creating the standards 5.1. Create a Panel standard

As an example of the usage of standards, most of the system built here will be built on a single Panel. Open the Graphic Toolbox Click on Galaxy | Configure | Customise Toolsets Select the Toolset called Super Secret hidden Toolset (notice it is on the Graphic tab) Click and drag the Toolsets below Super Secret hidden Toolset onto the Galaxy Delete Super Secret hidden Toolset Navigate to this toolset: Custom Graphics | 2. Standards | 1. Building Blocks | 1. Visual Standards Right-Click 1. Visual Standards Click New | Symbol Type the name S_Panel Open S_Panel Supply a Description (Standard Framed Panel) Use the Rectangle tool and create a rectangle of size 150150 Click on the Rectangle Supply a name for the rectangle (ThePanel) Click the arrow next to the button on the Toolbar Click the More Gradients item Set up the colours as shown

Click the arrow next to the Click the More Gradients item Set up the colours as shown

button on the Toolbar

35

Selected the line size as shown

The resultant panel is shown

Save and Close the Panel

36

5.2. Build Button standard

Create a graphic called S_Button in the 2. Buttons Toolset Supply a Description (Standard button) Add a new Boolean Custom Property called Pressed with this procedure: o Press Ctrl+M o Click the button o Type the Name (Pressed) o Drop down the Data type list and select the type (Boolean) o Supply a Description (If this value is true the button is being pressed. If this Button is treated as an icon this value must explicitly be set to true to indicate that the button is pressed) Add the following Custom Properties: o MouseOver DataType = Boolean Description = If this value is true the mouse is over the button. If this Button is treated as an icon this value must explicitly be set to true to indicate that the mouse is over the button o ButtonText DataType = String Description = Text displayed on the button Embed an S_Panel graphic with these steps: o Click the button o Select the S_Panel Graphic

Rename the Panel to UnPressedButton Set its width to 150 Set its height to 50 Double-Click the UnPressedButton Panel Click the button to add an animation Select the Visibility animation Set the Expression to Pressed Select the False option (This panel is visible when the button is not pressed) o Click OK Duplicate the UnPressedButton by selecting it and pressing Ctrl+D Name the new button to PressedButton Turn it 180 Send this panel to the back by pressing F9 Double-click the PressedButton o Change the visibility animation to True (This panel is visible when the button is pressed) o o o o o o o o
37

Use the Textbox tool and create a Textbox of size 150 50 Type #### Centre the text by Clicking the button Select the centre, centre button

Change the textboxs name to something descriptive such as txtbx_ButtonText Change the line thickness to No Line Change the Fill Colour to No Fill Double-click the Textbox and add an Action Script o Drop down the Trigger Type and select On left click/Key Down o Add this script: Pressed = TRUE; o o o o o o o o Drop down the Trigger Type and select On left /Key Up Add this script: Drop down the Trigger Type and select On Mouse Over Change the After value to 1 ms Add this script: Drop down the Trigger Type and select On Mouse Leave Change the After value to 1 ms Add this script:

Pressed = FALSE;

MouseOver = TRUE;

MouseOver = FALSE; Add the following Animations to the Textbox and configure them as shown:

o o

Fill Style (Almost Transparent) Location Horizontal

38

Location Vertical

Value Display

Select all three elements (PressedButton, UnPressedButton and the txtbx_ButtonText) by pressing the F2 key Centre all three elements by pressing the button. Save and Exit from the graphic

5.3. Build Valve standard

Under the 5. Control Modules toolset create a new graphic called S_Valve. Supply a description (Standard Valve) Embed the ValveSSBasic under the ArchestrA symbol Library | Valves | SoftShadow. Click on a blank area and press Ctrl+M. Add a Boolean Custom Property called Value and set its description to When set to True the valve indicates that it is open Click on the ValveSSBasic Press Ctrl+M

39

Change the FillColor to Blue (Notice the extreme usefulness of attribute descriptions) Change the FillColor Visibility to Private (this valve will always fill blue) For the value property select the --- in the Default Value box Click the Ellipse () In the Elements Panel click the S_Valve On the right side pane click Value Click OK Change the Value Visibility to Private (the ValveSSBasics Value attribute always references the outer S_Valves Value attribute)

5.4. Build a Level Transmitter Standard

Under the 6. Transmitters toolset create a S_Level_Transmitter graphic o Add description o Draw something that represents a level transmitter o Rename the elements o Exit and save

5.5. Build Master level Control Valve

In the Template Toolbox, open the $m_ControlValve Click on the Graphics tab Add a new graphic using these steps o Click the button o Supply the name as ControlValve o Supply a description (e.g. m_ControlValve specific ControlValve) Open the new graphic Embed the S_Valve Standard Click on the S_Valve embedded graphic Press Ctrl+M For the Value property, select the default value (False) Type NOT and a space (The valve should show open when the closed limit is not made) Click the Ellipse Select the Relative Reference ( ) Click on the Me reference Select Status.Closed

40

Click OK Select the visibility as Private Click OK Save and Close the Graphic

5.6. Build Master level, Solenoid Valve

Repeat the steps above for the Solenoid valve (SolenoidValve)

5.7. Build Master level, Level Transmitter

Create a $m_Level_Transmitter specific Level Transmitter (LevelTransmitter) and embed the S_Level_Transmitter standard Remember descriptions graphic

5.8. Build Application level tank graphic

Open the $a0_Tank template Create a Tank graphic (remember a description) Embed a Library tank graphic (e.g. SSTank4Supports) or draw something that looks like a tank Add Text to the centre of the tank o Set Font size to 20 pt o Add value display animation o Select Name (Tagname) Click the embed graphic button o Go to relative references o Embed the LevelTransmitter graphic in Me.Level Use the same procedure to embed a Me.OutletValve OutletValve Use some embedded pipes to connect the Outlet Valve Note that the Inlet valves cannot be embedded at this level because the number of inlet valves have not been determined at the Application level yet

Save and Exit

41

5.9. Preparing to create InTouch Screens

The first step to take is to expand the idea of a standard panel. The idea is to create a standard background that will be used on all screens. This background will be used to create sized standards that will fix the size of the screen that can be developed. Create a new Standard graphic called S_Background For demonstration purpose just embed an S_Panel and resize it to 500 500 Save and Exit Create a new Standard graphic called S_FullScreenBack Embed an S_Background Resize it to 1024 602 Click on the embedded S_Background Unselect the Dynamic sizing option o This means that if the original graphics (S_Panel or S_Background) should change size, this one will not.

5.10.Create the Overview graphics

Two screens will be developed namely Mixing Line 1 and 2 as well as Mixing Line 3 and 4. Overview graphics are built in specific instances (usually ArchestrA Area types). Open the S_ExtractMixing instance Add two graphics (remember descriptions) o WIN_MixLine1And2 o WIN_MixLine3And4 Open the WIN_MixLine1And2 graphic Embed the S_FullScreenBack Standard Lock its position and size with the button this will prevent a user from accidentally moving or resizing the background. Embed a graphic and select Instances ( ) Embed the Tank graphic on the S_E_MX001_T001 Tank. Embed the ControlValve graphic on the S_E_MX001_T001_IV001 Valve. Duplicate this valve (press Ctrl+D) Change the owning instance of the copied graphic with this procedure: o Right-Click on the Valve o Navigate to Embedded Symbol | Select Alternative Instance o Select the S_E_MX001_T001_IV002 instance Using some embedded piping symbols build a complete tank

42

Select all of the components and group them Duplicate the group three times and space evenly on the background Ungroup all the graphics Change the owning instances so that Mixing Line 1 and 2s tanks are on the page Put a Text box with a heading on the page

Repeat the complete procedure for Mixing line 3 and 4

43

6. The InTouch Application

The main part of the Human Machine Interface (HMI) is InTouch. Even though the graphics can be built into objects, all graphics are displayed by InTouch. Navigation should therefore be built into InTouch. InTouch can also serve as a medium for data exchange between various graphic elements.

6.1. Navigation
The navigation system can be built completely in InTouch, but this bypasses some of the ArchestrA graphic capability which is usually not desirable. To leverage the full graphic capability, the navigation system can be built around a trigger system. Since ArchestrA graphics can reference InTouch tags, it is possible to pass a requested window name to an InTouch tag and then trigger a condition (or data change script) to show the requested window. Other requests can be made in the same way (e.g. Window position, Headings, Messages, Current showing window, Owning object etc.). In its simplest form it consists of two InTouch tags: Trigger_ShowWindow (a Memory Discrete) and Requested_WindowName (Memory Message).

6.2. Data transfer

There are two ways to get information or data from one ArchestrA graphic to another. One is to write it to an Attribute somewhere in the ArchestrA framework and then read it from there. The other is to write it into a Memory tag in the InTouch system and then read it from there. Both methods are valid but they should never be confused. The distinction between Application Server (ArchestrA framework) and InTouch is an extremely important one and if misunderstood can cause some frustration. The distinction can be summarised as follows: Application Server: One version of the data exists and is the same across all platforms. Application Server is therefore completely unaware of any users InTouch: Data only exists in a particular InTouch instance (and is therefore aware of the user). Different versions of the data can exist for different users.

44

Lab 6 Build the InTouch

In this lab the InTouch application will be built.

6.1. Create a new InTouch Application

Under 0. Base Templates | 1. System right-click the $InTouchViewApp template Navigate to and click on New | Derived Template Supply a name for the application Move it to the 4. View Applications toolset Double-click it Make sure that Create New InTouch Application option is selected Click Next Supply a description Click Next

6.2. Build the Navigation system

Create a new Memory Discrete tag called Trigger_ShowWindow with these steps o In Window Maker click Special o Click Tagname Dictionary o Click New o Supply a tagname (Trigger_ShowWindow) o Click Type o Select Memory Discrete o Click OK o Supply a comment o Click Save Create a new Memory Message tag called Requested_WindowName Locate the scripts pane Right-click Condition item Click New In the Condition box supply the tag name Trigger_ShowWindow either by typing it, or clearing the block and doubleclicking in it and then selecting the tag from the tagname dictionary. Change the Condition Type to On True Add the following script Show Requested_WindowName; Trigger_ShowWindow = 0; Click OK In the Scripts pane right-click Key Click New Click Key Click F5 Hide Requested_WindowName; Hide "NAV_Navbar"; Show "NAV_Navbar";

45

Click OK

6.3. Build a Standard Show Window Button

In this section a Standard graphic is built for a button to show a Window using the Navigation system previously built. In the IDE Create a new graphic called S_ShowWindowButton in the 3. Navigation Standards toolset and open it remember a description! Add three custom properties (Remember descriptions): o INT_Requested_WindowName Type = String Reference = InTouch:Requested_WindowName Visibility = Private Description = Reference to the InTouch Tag Requested_WindowName o INT_Trigger_ShowWindow Type = Boolean Reference = InTouch:Trigger_ShowWindow Visibility = Private Description = Reference to the InTouch Tag Trigger_ShowWindow o Cfg_WindowName Type = String Text = [Blank] Visibility = Public Description = The name of the InTouch window that this button should show Embed an S_Button Attempt to add an action script to S_Button note that it is not immediately possible: S_Button needs to be treated as an Icon o Select S_Button o On the right-hand properties pane, locate the Treat as Icon attribute (under Runtime behaviour) o Double-click Treat as Icon to change to true (This overrides the built-in scripts) o Now add a new action script Trigger Type = On Left/Key Up Add the following script IF NOT Int_Trigger_ShowWindow THEN Int_Requested_WindowName = Cfg_WindowName; Int_Trigger_ShowWindow = TRUE; ENDIF; Change all the embedded S_Buttons properties to Private. Change the ButtonText propertys reference on the embedded S_Button to Cfg_WindowName (The button will show the configured Windowname) Save and close

6.4. Build a Navigation Bar

The navigation bar is an independent (stand-alone) graphic. It is not embedded in an object/template. It has no context in the ArchestrA framework, only in InTouch.
46

Under 1. Independent Graphics | 1. Navigation Graphics create a graphic called Navigationbar and open it (Remember the description) Embed an S_BackGround standard and change its size to Width = 1024, Height = 100 Embed an S_ShowWindowButton and place it on the Navigation Bar Rename it to ShowMixLine1And2 Configure the Cfg_WindowName property to contain the following text: WIN_MixLine1And2 Duplicate the ShowMixLine1And2 button and name it ShowMixLine3And4 Configure its Cfg_WindowName property to contain the following text: WIN_MixLine3And4 Save and Exit

6.5. Create the InTouch Windows

In InTouch WindowMaker create a window called NAV_Navbar with this procedure: o Click on File | New Window o Supply the name (NAV_Navbar) o Set the X-location to 0 o Set the Y-location to 602 o Set Width to 1024 o Set Height to 100 Create two more windows (WIN_Mixline1And2 and WIN_Mixline3And4) o (WIN_MixLine1And2) (WIN_MixLine3And4) o Set the X-location to 0 Set the X-location to 0 o Set the Y-location to 0 Set the Y-location to 0 o Set Width to 1024 Set Width to 1024 o Set Height to 602 Set Height to 602 On the NAV_Navbar window, embed the NavigationBar by clicking the button On the WIN_MixLine1And2 window embed the S_ExtractMixing graphic called WIN_MixLine1And2 On the WIN_MixLine3And4 window embed the S_ExtractMixing graphic called WIN_MixLine3And4 Close all the windows in Window Maker Click the Runtime menu item (Top Right) Once WindowViewer has started press F5 to open the Navigation bar Click the WIN_MixLine1And2 button Notice that the Mouse Over and Mouse Pressed buttons do not work

47

Module 4
Advanced Graphics
7. Assistant Graphics
Graphics often contain scripts and/or other action animations. When these graphics are embedded somewhere but require additional action animation, they need to be set to be treated as an icon. This means that any added action animation will override the original. This can sometimes be a problem (as has been shown in the labs). To overcome this problem one can easily add the required scripts to the embedded symbol however, this can be very tedious and repetitive if several different types of buttons are required. For this reason, it is sometimes necessary to create Assistant graphics. These graphics are prefixed with an A_ and are embedded as per usual. The embedded graphic is then converted into a group and ungrouped. This leaves a graphic that already has the required scripting. The best way to demonstrate is with a Lab.

48

Lab 7 Creating and using an Assistant graphic 7.1. Create an assistant Button
Create a graphic called A_Button under the 3. Assistant Graphics | 1. Buttons toolset. Embed an S_Button on it Change the name to ChangeMyName On the right-hand properties pane, locate the Treat as Icon attribute (under Runtime behaviour) Double-click the Button and add the Action Script animation o Drop down the Trigger Type and select On left click/Key Down o Add this script: Pressed = TRUE; o o o o o o o o Drop down the Trigger Type and select On left /Key Up Add this script: Drop down the Trigger Type and select On Mouse Over Change the After value to 1 ms Add this script: Drop down the Trigger Type and select On Mouse Leave Change the After value to 1 ms Add this script:

Pressed = FALSE;

MouseOver = TRUE;

MouseOver = FALSE; Save and Exit

7.2. Using an assistant button

Open S_ShowWindowButton Leave the original button for now Embed an A_Button Right-click the embedded A_Button Navigate to and Click on Embedded Symbol | Convert to Group Ungroup the resultant group (Press Shift+F3) Double-click the original embedded button and copy the script from it Delete the original button Double-click the new button On the action scripts drop down the trigger type and select On Left/Key up Below the existing script, paste the copied script Rename the embedded button (TheButton) Change all the embedded A_Buttons properties to Private. Change the ButtonText propertys reference on the embedded A_Button to Cfg_WindowName (The button will show the configured Windowname) Save and Exit In Window Viewer, Press the F5 key (this will hide and show the Navigation panel updating it with the changes) o The buttons animation should now work.
49

8. Popup graphics
Some of the most important graphics are popup or faceplate graphics. These are usually control panel or information display panels that are displayed when a specific piece of equipment is clicked. With ArchestrA graphics there are two ways to handle these graphics.

8.1. Show symbol

A Show symbol animation exists that can display a symbol directly if the element is clicked. This type of popup works for simple one-of graphics.

8.2. InTouch Windows

This method is similar to the Navigation scheme proposed earlier. The Name of the popup and a trigger is passed to the InTouch side which handles the display of the Popup. This method is more customisable and drill-through type of capability is available. These graphics can be made dynamically by changing the owning object of a graphic. This method takes planning and thought and some coding to accomplish but is sometimes preferable or the only option. A drawback of this method is that only one popup of a type (for instance a motor faceplate) can be displayed at a time if multiple faceplates must be displayed simultaneously, one window per possible faceplate must be created and the implementation should keep this in mind.

50

Lab 8 Creating Popups 8.1. Creating the popups

Create a new graphic called P_SolenoidValve under the 2. Standards | 7. Popups Open it Create the following Custom Properties o Closed Limit Default = FALSE Visibility = Public Type = Boolean Description = True if Closed limit is made o Open Limit Default = FALSE Visibility = Public Type = Boolean Description = True if Open limit is made o CmdClose Default = FALSE Visibility = Public Type = Boolean Description = Command to Close Valve o CmdOpen Default = FALSE Visibility = Public Type = Boolean Description = Command to Open Valve o Heading Default = [Blank] Visibility = Public Type = String Description = Heading to be displayed o TravellingTime Default = 00:00:00.0000000 Visibility = Public Type = ElapsedTime Description = The Time expired to travel from previous position to required position Embed an S_Panel Embed a SquareLightRed and change custom properties as follows: o Blink Reference = NOT ClosedLimit Visibility = Private o Value Reference = ClosedLimit OR CmdClose Visibility = Private Embed a SquareLightGreen and change custom properties as follows: o Blink Reference = NOT OpenLimit Visibility = Private o Value Reference = OpenLimit OR CmdOpen
51

Visibility = Private Create a Open Command button with these steps o Embed an A_Button o Convert it to a group o Ungroup o Change the name to CmdOpenButton o Change the action script for On Left/key up by adding the following script: CmdOpen = TRUE;

Create a Close Command button with the same steps (script below) CmdClose = TRUE;

Change the ButtonText propertys of both command buttons to a hardcoded text of Open and Close respectively. Create a Textbox and add the value display animation (string) to it to show the Heading attribute Add a Textbox and add the value display animation (time) to it to show the TravellingTime attribute Add descriptive text for the following: o Green button Open o Red button Closed o TravellingTime textbox Travelling Time Arrange the popup more or less as shown:

52

Save and Close Import the P_Popups.aaPKG in the My Documents\The Lazy Folder o Creates a S_AnalogueDisplay o Creates a P_ControlValve graphic o Creates a P_Level_Transmitter graphic

8.2. Creating object specific pop-ups

Create the following object specific graphics o $m_ControlValve ControlValvePopup o $m_SolenoidValve SolenoidValvePopup o $m_Level_Transmitter LevelTransmitterPopup Embed the corresponding P_ graphics in each of these setting the properties as follows (remember to set them all to private): o P_ControlValve ActualValue = Me.Status.Position ClosedLimit = Me.Status.Closed ControlValue = Me.Cmd.Position Heading = Me.Tagname OpenLimit = Me.Status.Open TravellingTime = Me.Status.TravelTime o P_SolenoidValve ClosedLimit = Me.Status.Closed CmdClose = Me.Cmd.Close CmdOpen = Me.Cmd.Open Heading = Me.Tagname `OpenLimit = Me.Status.Open TravellingTime = Me.Status.TravelTime o P_Level_Transmitter CmdClose = False Heading = Me.Tagname Level = me.PV

Caution
Custom Properties of type string, time and elapsedtime have to set to reference/text mode explicitly by clicking the or buttons. The issue is when a reference is typed but the property is in text mode, no error will be thrown (as a reference is a valid string) but the property will off course have the wrong value.

53

8.3. Change Equipment Symbols

On $m_ControlValve open the ControlValve symbol Treat the embedded symbol as an icon Double click the embedded symbol to add an animation Add a Show Symbol animation and set it up as shown:

Do the same for the $m_SolenoidValve template. In WindowViewer Press F5 and test the faceplates

8.4. Enable the Level Transmitters popup

Open InTouch Window Maker Create a new Memory Discrete tag called Trigger_ShowPopup with these steps Create a new Memory Message tag called Requested_PopupName Create a new Memory Message tag called Requested_OwningObject Locate the scripts pane Right-click Data Change item Click New In the Tagname box supply the tag name Trigger_ShowPopup. Add the following script IF Trigger_ShowPopup == 1 THEN Show Requested_PopupName; ELSE Hide Requested_PopupName; ENDIF; Click OK Open S_Level_Transmitter

54

Add the following Custom Properties: o Cfg_OwningObject Type = String Description = Configured popup's owning object o Cfg_PopupName Type = String Description = Configured popup to display o INT_Requested_OwningObject Type = String Description = InTouch Tag for the requested owning object Reference = InTouch:Requested_OwningObject o INT_Requested_PopupName Type =String Description = InTouch Tag for the requested popup name Reference = InTouch: Requested_PopupName o INT_TriggerPopup Type = Boolean Description = InTouch Tag used to show a popup Reference = InTouch: Trigger_ShowPopup Double-click the element and add this action script to the Right-Click event IF INT_TriggerPopup THEN IF INT_Requested_PopupName == Cfg_PopupName THEN INT_Requested_OwningObject = Cfg_OwningObject; ENDIF; ELSE INT_Requested_PopupName = Cfg_PopupName; INT_Requested_OwningObject = Cfg_OwningObject; INT_TriggerPopup = TRUE; ENDIF;

Save and close Open the LevelTransmitter in the $m_Level_Transmitter Click on the embedded S_Level_Transmitter and change its properties as follows: o Cfg_OwningObject Visibility = Private Reference = me.Tagname o Cfg_PopupName Visibility = Private POP_LevelTransmitter o All the rest should just be set to private Open the LevelTransmitterPopup in the $m_Level_Transmitter Add the following Custom Properties: o Cmd_SetOwningObject Type = Boolean Description = Internal command that forces the owning object to be set o INT_Requested_OwningObject Type = String Description = InTouch Tag for the requested owning object Reference = InTouch:Requested_OwningObject o INT_TriggerPopup Type = Boolean Description = InTouch Tag used to show a popup Reference = InTouch: Trigger_ShowPopup
55

Click on the embedded Graphic and edit the following Property (Ctrl+M) CmdClose = INT_TirggerPopup Click anywhere on the blank canvas of the graphic and press F10 to add some graphic scripts Under Predefined scripts ensure the trigger type is OnShow and add the following script IF NOT Cmd_SetOwningObject THEN Cmd_SetOwningObject = TRUE; ENDIF;

Add a script and call it OwnObjectChange and configure it as follows: o Expression = INT_Requested_OwningObject o Trigger = DataChange o Script IF NOT Cmd_SetOwningObject THEN Cmd_SetOwningObject = TRUE; ENDIF;

Add another script and call it SetOwningObject and configure it as follows: o Expression = Cmd_SetOwningObject o Trigger = WhileTrue o Period = 50ms o Script IF IsGood(INT_Requested_OwningObject) THEN IF INT_Requested_OwningObject <> "" THEN P_LevelTransmitter1.OwningObject = INT_Requested_OwningObject; Cmd_SetOwningObject = FALSE; ENDIF; ENDIF;

Save and close In WindowMaker create a new Window and call it POP_LevelTransmitter Add a Window script to the POP_LevelTransmitter Window and configure it as follows: o Trigger = OnHide o Script Trigger_ShowPopup = 0; On this window embed the LevelTransmitterPopup graphic contained in S_E_MX01_T001_LT001 Note: this is a specific instance (the owning object will be changed by the popup itself) Close and save all windows Close and Open WindowViewer, Press F5 and test the Level Transmitter by rightclicking on it.

56