system platform 3 - oee platform 3 - implementing best pract… · system toolset (this template is...
TRANSCRIPT
REV 1 [2008-09-18] [email protected]
Ground floor Block D Gillooly’s View Office Park 1 Osborne Road Bedfordview
Tel: 0861-WONDER Fax: (011) 607-8478
System Platform 3.0
Implementing Best Practices
2
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.
3
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. Create the toolsets ______________________________________________________________ 10 1.2. Derive the Base Level Templates __________________________________________________ 11 1.3. Derive S95 Master level templates _________________________________________________ 12
2. The Project _______________________________________________________________ 13 2.1. The Plant _____________________________________________________________________ 13 2.2. Control Modules _______________________________________________________________ 14
2.2.1. Control Valve _____________________________________________________________ 14 2.2.2. Solenoid Valve ____________________________________________________________ 14
2.3. Transmitters __________________________________________________________________ 14 2.3.1. Level Transmitter __________________________________________________________ 14
2.4. Top level S95 _________________________________________________________________ 14 2.5. Shared Functionality ____________________________________________________________ 15
Lab 2 – Building the Master level templates ________________________________________ 17 2.1. Derive the templates ____________________________________________________________ 17 2.2. Enable Basic functionality ________________________________________________________ 17
Module 2 ________________________________________________________________ 19
3. The Application and Types of System objects ___________________________________ 19 3.1. The Application Level ___________________________________________________________ 19 3.2. PLC IO addressing _____________________________________________________________ 19 3.3. System Objects ________________________________________________________________ 19
3.3.1. $Area ___________________________________________________________________ 20 3.3.2. $WinPlatform _____________________________________________________________ 20 3.3.3. $AppEngine ______________________________________________________________ 20 3.3.4. $ViewEngine _____________________________________________________________ 21
Lab 3 – Building the Application level templates ____________________________________ 22 3.1. Creating the System Objects ______________________________________________________ 22 3.2. Create Application level objects ___________________________________________________ 24 3.3. Implement auto IO addressing_____________________________________________________ 24 3.4. Set-up Redundancy _____________________________________________________________ 26
4. Instantiation and Deployment _______________________________________________ 27 4.1. Instantiation ___________________________________________________________________ 27 4.2. Deployment ___________________________________________________________________ 28
Lab 4 – Making it work ________________________________________________________ 29
4
4.1. Instantiate the Top level and System objects __________________________________________ 29 4.2. Instantiate One Mix Line _________________________________________________________ 29 4.3. Utilise galaxy dump/load_________________________________________________________ 30 4.4. Set up the deployment ___________________________________________________________ 31
Module 3 ________________________________________________________________ 33
5. Graphics _________________________________________________________________ 33 5.1. Graphic Toolbox _______________________________________________________________ 33
Lab 5 – Creating the standards __________________________________________________ 35 5.1. Create a Panel standard __________________________________________________________ 35 5.2. Build Button standard ___________________________________________________________ 37 5.3. Build Valve standard ____________________________________________________________ 39 5.4. Build a Level Transmitter Standard _________________________________________________ 40 5.5. Build Master level Control Valve __________________________________________________ 40 5.6. Build Master level, Solenoid Valve _________________________________________________ 41 5.7. Build Master level, Level Transmitter _______________________________________________ 41 5.8. Build Application level tank graphic ________________________________________________ 41 5.9. Preparing to create InTouch Screens ________________________________________________ 42 5.10. Create the Overview graphics _____________________________________________________ 42
6. The InTouch Application ___________________________________________________ 44 6.1. Navigation ____________________________________________________________________ 44 6.2. Data transfer __________________________________________________________________ 44
Lab 6 – Build the InTouch ______________________________________________________ 45 6.1. Create a new InTouch Application _________________________________________________ 45 6.2. Build the Navigation system ______________________________________________________ 45 6.3. Build a Standard Show Window Button _____________________________________________ 46 6.4. Build a Navigation Bar __________________________________________________________ 46 6.5. Create the InTouch Windows _____________________________________________________ 47
Module 4 ________________________________________________________________ 48
7. Assistant Graphics _________________________________________________________ 48
Lab 7 – Creating and using an Assistant graphic ____________________________________ 49 7.1. Create an assistant Button ________________________________________________________ 49 7.2. Using an assistant button _________________________________________________________ 49
8. Popup graphics ___________________________________________________________ 50 8.1. Show symbol__________________________________________________________________ 50 8.2. InTouch Windows ______________________________________________________________ 50
Lab 8 – Creating Popups _______________________________________________________ 51 8.1. Creating the popups _____________________________________________________________ 51 8.2. Creating object specific pop-ups ___________________________________________________ 53 8.3. Change Equipment Symbols ______________________________________________________ 54 8.4. Enable the Level Transmitters popup _______________________________________________ 54
5
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.
6
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
7
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 SIA’s. Even though both SI’s
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
8
1.2. Toolset Organisation
Toolsets in the Toolbox should be created to reflect at least the Base-
Master-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.
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,
Collectively known as Work
Centres
Collectively known as Work
Units
9
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.
10
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”
11
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
12
1.3. Derive S95 Master level templates
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.
Will create SystemsAreas Later
13
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
14
2.2. Control Modules
2.2.1. Control Valve
Outputs
Status.Position
Status.Open
Status.Closed
Status.TravellingTime
Inputs
Cmd.Position
Control Valve
2.2.2. Solenoid Valve
Outputs
Status.Open
Status.Closed
Inputs
Cmd.Open
Cmd.Close
Solenoid Valve
2.3. Transmitters
2.3.1. Level Transmitter
Outputs
PV
Inputs
Transmitter
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).
15
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 client’s 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)
16
Description Naming convention Security/Category
Set-up parameter – set during design time (Typically Startup scripts use them)
Setup.[Attribute].Parameter Setup.[XML].Folder
(Folder is created the first time the object deploys)
Read Only
Configurable parameter – Object must be set off scan to change (typically OnScan scripts use them)
Cfg. [Attribute].Parameter Cfg.[OrderDataBase].ServerName
(Connection is established every time the Engine goes on
Scan)
Configure
Engineering Set Point – Only certain personnel can change these
Eng. [Attribute].SetPoint Eng.[Feeder].Speed.Maximum
(Only Tune permitted users can change the maximum speed)
Tune
Calculate value – Cannot be changed by anything but a script
Calc. [Attribute].Parameter Calc.[Cable].Length
(Length is calculated from measured weight)
Calculated
Set point – Operational set points that can be changed by operators
SP. [Attribute].SetPoint SP.[Feeder].Speed
(Operating set point speed of feeder)
Operate
Commands – When set to TRUE, a function is performed. On completion the value returns to FALSE
Cmd.[Attribute].Command Cmd.[Feed].Start
(Start the Feed sequence)
Depends on command
Mode Select – Indicates a specific mode. Stays in state until mode is changed.
Select.[Attribute].Mode Select.[Mode].Auto
(Selects the Auto mode)
Depends on mode
Process value – Typically an Analogue value that is measured with and instrument.
[Attribute].PV [Level].PV
(Process value of the Level)
Object Writable
Status value – Indicates status of something in the field (typically not an Analogue value)
Status.[Attribute].Status Status.[InletValve].Open
(Indicates when the valve is open)
Object Writable
Alarms flag – Indicates that something is in alarm
[Attribute/Status/PV].AlarmType.Alarm [Tank].Level.High.Alarm
(Indicates Tank is in alarm because level is high)
Object Writable
Interlock flag – Indicates that something is interlocked
[Attribute/Status/PV].InterlockType.Interlock [Pump].ValveClosed.Interlock
(Indicates Pump is interlocked because valve is closed)
Object Writable
Simulation Attributes – Used to simulate something. An object should still be functional if all Simulation Attributes and Scripts are removed
Sim.RestofNameparts Sim.Eng.SimulatedPV.Maximum
(Change the maximum simulated PV value)
Depends on simulation
17
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
18
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
19
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:
20
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.
21
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.
22
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
23
o 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
o Save and Close
24
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”
25
o Select the Trigger type as “WhileFalse”
o Lock all of the Locks
On all three add the following code:
Add the specific code pieces as indicated:
o Control Valve
o Solenoid Valve
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;
'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";
'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";
26
o Level Transmitter
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)
'FA Inputs me.PV.Input.InputSource = ThePrefix + "PV";
27
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.
28
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.
29
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:
30
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
31
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
32
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
33
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 standard’s 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
34
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
35
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 150×150
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 button on the Toolbar
Click the More Gradients item
Set up the colours as shown
36
Selected the line size as shown
The resultant panel is shown
Save and Close the Panel
37
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
o Rename the Panel to “UnPressedButton”
o Set its width to 150
o Set its height to 50
o Double-Click the UnPressedButton Panel
o Click the button to add an animation
o Select the Visibility animation
o Set the Expression to “Pressed”
o 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)
38
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 textbox’s 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:
o Drop down the Trigger Type and select “On left /Key Up”
o Add this script:
o Drop down the Trigger Type and select “On Mouse Over”
o Change the After value to 1 ms
o Add this script:
o Drop down the Trigger Type and select “On Mouse Leave”
o Change the After value to 1 ms
o Add this script:
Add the following Animations to the Textbox and configure them as shown:
o Fill Style (Almost Transparent)
o Location Horizontal
Pressed = TRUE;
Pressed = FALSE;
MouseOver = TRUE;
MouseOver = FALSE;
39
o Location Vertical
o Value Display
Select all three elements (PressedButton, UnPressedButton and the txtbx_But-
tonText) 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
40
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 ValveSSBasic’s Value attribute always
references the outer S_Valve’s 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
41
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 graphic
(LevelTransmitter) and embed the S_Level_Transmitter standard
Remember descriptions
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
42
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
43
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 2’s 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
44
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.
45
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 double-
clicking in it and then selecting the tag from the tagname dictionary.
Change the Condition Type to “On True”
Add the following script
Click OK
In the Scripts pane right-click Key
Click New
Click Key
Click F5
Show Requested_WindowName; Trigger_ShowWindow = 0;
Hide Requested_WindowName; Hide "NAV_Navbar"; Show "NAV_Navbar";
46
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_Win-
dowName
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
Change all the embedded S_Button’s properties to Private.
Change the ButtonText property’s 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.
IF NOT Int_Trigger_ShowWindow THEN Int_Requested_WindowName = Cfg_WindowName; Int_Trigger_ShowWindow = TRUE;
ENDIF;
47
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
48
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.
49
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:
o Drop down the Trigger Type and select “On left /Key Up”
o Add this script:
o Drop down the Trigger Type and select “On Mouse Over”
o Change the After value to 1 ms
o Add this script:
o Drop down the Trigger Type and select “On Mouse Leave”
o Change the After value to 1 ms
o Add this script:
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_Button’s properties to Private.
Change the ButtonText property’s 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.
Pressed = TRUE;
Pressed = FALSE;
MouseOver = TRUE;
MouseOver = FALSE;
50
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.
51
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
52
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:
Create a Close Command button with the same steps (script below)
Change the ButtonText property’s 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:
CmdOpen = TRUE;
CmdClose = TRUE;
53
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.
54
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
Click OK
Open S_Level_Transmitter
IF Trigger_ShowPopup == 1 THEN Show Requested_PopupName; ELSE Hide Requested_PopupName; ENDIF;
55
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
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
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;
56
o 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
Add a script and call it OwnObjectChange and configure it as follows:
o Expression = INT_Requested_OwningObject
o Trigger = DataChange
o Script
Add another script and call it SetOwningObject and configure it as follows:
o Expression = Cmd_SetOwningObject
o Trigger = WhileTrue
o Period = 50ms
o Script
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
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 right-
clicking on it.
IF NOT Cmd_SetOwningObject THEN Cmd_SetOwningObject = TRUE; ENDIF;
IF NOT Cmd_SetOwningObject THEN Cmd_SetOwningObject = TRUE; ENDIF;
IF IsGood(INT_Requested_OwningObject) THEN IF INT_Requested_OwningObject <> "" THEN P_LevelTransmitter1.OwningObject = INT_Requested_OwningObject; Cmd_SetOwningObject = FALSE; ENDIF; ENDIF;
Trigger_ShowPopup = 0;