IBM PlantWorks: Application Automation Edition
Using PlantWorks PTF-2 New Functionality
Version: 1.00
Release Date: 30 December, 1997
(c) Copyright IBM Corporation 1997.
Document Owner:
IBM Corporation
Global Embedded and Production Solutions
Product and Project Support Services
Boca Raton, Florida
Document Abstract
This document provides the enhancement descriptions made to PlantWorks Applications Automation Edition PTF-2. This document is intended to address all design issues and specify the work which was done. This document is not intended in any way to supersede the documentation provided for the products involved or their accompanying README files.
Table of Contents
I. Software Prerequisites PlantWorks PTF-2
III. Using PlantWorks PTF-2 Features
V. End-Of-Document
I. SOFTWARE PREREQUISITES PLANTWORKS PTF-2
Prior to the installation of PlantWorks PTF-2 the customer must first assure that the
following PlantWorks Licensed Software Products are Installed...
The following feature listing represents those functional additions which are actual IBM Licensed Program Software Product Extensions and Modifications contained in PlantWorks(TM) Release 2.3 hereafter referred to as PlantWorks PTF-
2 as of 30 December, 1997.
III. USING PLANTWORKS PTF-2 FEATURES
PlantWorks Data History Definition and Data Logger Task
Function Provided:
Data History Definition and Data Logger Task will be enhanced to define and use cascaded logsets. These logsets will log either raw data or averaged data depending on the configuration.
Logsets will be created and logged internally without the use of chains.
Figure 1
Using DLT Engine Cascaded Logset
A new option will be added to the create logset dialog box in Data History Definition. This option is a 'Cascade' check box which will indicate if cascaded logsets are created from a base logset.
This cascaded check box can only be clicked if the base logset is defined as periodic. If it is not defined as periodic then the button will be grayed out. If this button is checked then it will enable the 'SETUP' push-button. This push-button will bring up a second dialog box called 'Cascaded Logset Setup' (Figure 2).
Figure 2
This dialog box will prompt the user for information on four time intervals for logging data. This means that the user can define up to four cascaded logsets for each base logset defined. If only two cascaded logsets are needed, then leave the last two are time fields at the default zero value. However, if a time deviation is zero then all subsequent time deviations must also be zero. These entry fields require data to be in multiples of previous time deviations and have a range of 0-255. Two examples shown below.
| Base Logset: APP:CASCADE | |
| Base Sample Rate = 15 seconds | - Define as periodic with a start and stop time |
| First Deviation = 2 | -15 sec x 2 = 30 sec |
| Second Deviation = 20 | - 30 sec x 20 = 10 min |
| Third Deviation = 6 | - 10 min x 6 = 1 hour |
| Fourth Deviation = 24 | - 1 hour x 24 = 24 hour = 1 day |
| Base Logset: APP:ENHANCED | |
| Base Sample Rate = 15seconds | - Define as periodic with a start and stop time |
| First Deviation = 240 | - 15 sec x 240 = 3600 sec = 1 hour |
| Second Deviation = 8 | - 1 hr x 8 = 8 hours |
| Third Deviation = 3 | - 8 hr x 3 = 24 hours |
| Fourth Deviation = 0 | - Logset not created |
The internally defined logsets (deviations) will be named using up to seven characters of the base logset name. Appended to the end of these seven characters will be the deviation number. If the base logset is not eight characters in length then all characters of the base logset will be used with the appended deviation number. Two examples are shown below. The first example has a base logset name 'ENHANCED' = 8 characters. The second example has 'CASCADE' = 7 characters.
| Base logset name: APP:ENHANCED | |
| First Deviation: APP:ENHANCE1 | - Will log at 1 hour |
| Second Deviation: APP:ENHANCE2 | - Will log at 8 hours |
| Third Deviation: APP:ENHANCE3 | - Will log at 24 hours |
| Fourth Deviation: Not Created | - Logset not created |
| Base logset name: APP:CASCADE | |
| First Deviation: APP:CASCADE1 | - Will log at 30 seconds |
| Second Deviation: APP:CASCADE2 | - Will log at 10 minutes |
| Third Deviation: APP:CASCADE3 | - Will log at 1 hour |
| Fourth Deviation: APP:CASCADE4 | - Will log at 1 day |
It will be the responsibility of the user to verify that no items exist which would cause a naming conflict. If a conflict does occur, then the conflicting logset will not be installed. When the conflict is resolved the installation will be successful.
In addition, there will be two radio buttons which will allow the user to create either actual or averaged logsets. Only one can be selected at a time. If actual is selected, then at the defined logging intervals raw data samples will be logged. The child logsets using this option will log based on time. The other option is averaged logsets. Using the example above; 240 base samples will be averaged and logged to APP:ENHANCE1. This will continue until 8 averages are logged. Then these 8 will be averaged and logged to APP:ENHANCE2. This will continue until 3 averages are logged . Then these 3 will be averaged and logged to APP:ENHANCE3. The result will be averaged data in viewable logsets without the use of chains. The child logsets using this option will log based on counts.
| Base logset name: APP:ENHANCED | - 15 seconds (Time base interval) |
| First Deviation: APP:ENHANCE1 | - 240 counts (1st Child) |
| Second Deviation: APP:ENHANCE2 | - 240 x 8 = 1920 counts (2nd Child) |
| Third Deviation: APP:ENHANCE3 | - 1920 x 3 = 5760 counts (3rd Child) |
| Fourth Deviation: Not Created | - No logging done |
As shown above these counts are based on the previous child logset which is based on his previous child logset which is eventually based on the time base interval. Therefore, the time intervals shown in 'Cascaded Logset Setup' for average logsets is an approximation. The approximation will vary, the further out in time a average child logsets is defined from its base time interval.
The data logged to each logset will always be the same data type as the variable being logged. Therefore, if the 240 samples averaged above are of data type INT1. Then the averaged value will be logged as an INT1. The data will be rounded to the nearest integer. However, for data integrity this value will stay in memory as a float until logged to disk. The data types supported are INT1, INT2, INT4, FLOAT and FLAG.
If the computer is taken down these counts will be reset to zero. Since DLT will reset all registers when the computer is down no bad data will be used to compute an average.
The logset files will be disk based, fixed length and created at runtime initialization. The files will be 1/2 Mbyte each in size able to contain just over 9200 data records.
| Default PlantWorks File Size........ | 512254 bytes |
| Record Content (10 Float Vars)........ | 54 bytes (Worst Case) |
| Records In Log File........ | 9259 records |
| At 10-Second Base Rate........ | 25 hours (10 Sec Data) |
| At 1-Minute First Deviation........ | 6 days ( 1 Min Data) |
| At 10-Minute Second Deviation........ | 2 months (10 Min Data) |
| At 1-Hour Third Deviation........ | 1 year ( 1 Hr Data) |
| At 8-Hour Fourth Deviation........ | 8 years ( 8 Hr Data) |
When the logset file becomes full it will be backed up to the \ff\vision\files\dlt\sav directory. After it is backed up a new file will be created and logging will continue. When this happens a message will be logged in the Warning Browser to inform the user. When the logset file becomes full again it will repeat the process overwriting any existing logset file in the \ff\vision\files\dlt\sav directory. The trender will look for the latest information from this directory if the /ff/vision/files/dlt/cur directory does not contain enough information. For this reason the 'Chain Trigger when Logset is Full' has been disabled for cascaded logsets.
Modules Affected/Replaced:
The modules that are expected to be replaced in the implementation of the DLT Cascaded Logset Support are:
PlantWorks PTF-2 Runtime Monitor Trend Object and Display Definition
Function Provided:
The ability to create a trend object in a display has been added into PlantWorks. In Display Definition, a user will now be able to embed a trend object. This will allow the Runtime Monitor to show trends along with any existing user defined objects.
Figure 3
Using the Trend Object in Runtime Monitor
To create a Trend Object in Runtime Monitor, the object must be embedded into a display. In order to do this, a user must first create and save a "trend" in Trend Analysis. After the trend file (.TRN) has been saved we can create the trend object through Display Definition.
The "trend" is created the same way it was introduced with PlantWorks 2.3 GA. In the PlantWorks Service Control window, select Trend Analysis from the Runtime pull-down menu. The trending screen will come up. Select File, then Create. A dialog box appears that asks for the details of this particular trend as shown by figure 4. Type in the history (logset) file name or the variable names that are to be displayed by the trending tool. Then associate the logset variables that are to be logged with the line color to represent them. When the user is finished, the file should be saved. To save the file, choose File then Save. Enter the name of the file (.TRN), then click on OK. Note that the Min Value should not be negative.
Figure 4
Figure 5
Embedding the Trend Object in Display Definition
Once the user has created a trend and assigned it a file name, the display can then be created or edited to include a trend object. The user must start Display Definition then Get or Create a display. Once a display is ready to be
modified, a user should select Composites from the pull-down menu. The selection "Trend Object..." should then be selected. This will bring up a dialog box that allows a user to put in up to five .TRN files as shown in
figure 6. These names should be files that were created previously in Trend Analysis. Along with the file names, a description should be entered for each of the files. If a user does not have a need to fill all five files, they may be left blank.
A check box at the bottom of the dialog box controls whether or not the to display the trend legend at runtime. By putting a check in this box, a legend displaying the current value of each point run time will be on the top of the trend object. At
runtime, the display of the legend will take a lot of the graph's space. Once this form is completed, the 'OK' button should be pressed. A cross-hair pointer, which can be moved by the mouse, will indicate where the object will be placed. The size
of the object can be modified, although making it any smaller will render the graph's display ineffective. Keep in mind, that as in 2.3GA both the .TRN and logset files need to reside on the same node that the trend will be displayed on.
Once the display is complete, it can be saved, then installed.
The significance of the description field in the entry dialog is for run time purposes. Once the display contains a trend object in it and is running in the Runtime Monitor, an operator may select one of the five trending files entered
at definition. A drop-down list will appear at the top of the trending object, displaying one to five descriptions that were entered in Display Definition. When the user highlights the one to be viewed it will then be displayed.
See figure 3.
Figure 6
Figure 7
Viewing the Trending Object in Runtime Monitor
When the display is brought up, the trending object should be embedded in it. The object will, by default, show the first file that was entered in Display Definition. To change the file to be displayed, click the mouse on the top
portion of the object and a drop-down menu will appear. By highlighting the trend object desired and entering, the trend tool will show the corresponding file. Another way of switching which trend is displayed, double click anywhere on the object.
This will display the next file on the list. One can cycle through the entire list doing this. When the last trend is reached, the first one is displayed next.
The functionality of this trend object is very similar to what was introduced in PlantWorks 2.3 GA with some enhancements. Previously, the trend object was not capable of updating the display in real-time when a history file (logset) was
specified. Now the trend object will update its display at the same rate as the history file is updated.
VCONFIG Options for Trend Object
To use the new trend object add the following lines to the bottom of your \ff\vision\files\vconfig file.
####################################################################################
#
# Section IX.
# ------------------
#
# DLT- data buffer time. Data is written to disk by dlt a default of every minute. Overwrite this default
# value with a value in seconds. Only accepts values > 0, but < 61. Invalid values default to 60.
#
# TND- indicate how many decimal places float variables should have when displayed by the trender
#
####################################################################################
dlt_store_rate: 8
trend_decimal_places: 1
The new trend object loads data differently from Trend Analysis. For performance reasons only 300 points from each of the five (.TRN) definitions will be loaded. To go further back in time, click the horizontal scroll bar shown below the
trend. A dialog box will be displayed which notifies the user that real time trending will be temporarily halted. Click OK. At that time your mouse will become a clock while potentially ½ megabytes of data loads. The progress of the loading of data
can be seen at the top left corner of the trend object. When the loading of data is complete the mouse pointer will return. Depending on the activity and work load of your system this can take up to 30 seconds.
If the performance of the Runtime Monitor becomes an issue, you will need to reduce the loading time of the data. To reduce the loading time when initially bringing up a display, reduce the number of trend files in Display Definition.
Another feature of the trend object is its ability to automatically load data from the \ff\vision\files\dlt\sav directory.
When a logset file becomes full it is automatically backed up to this directory. When that happens a new logset file is created in the \ff\vision\files\dlt\cur directory. This could cause problems if the trend object only focused on the \
ff\vision\files\dlt\cur directory. However, the trend object will automatically open up the backup file if more data is needed to complete the visual display (up to ½ megabytes). Modules Affected/Replaced:
The modules that have been replaced in the implementation of the Runtime Monitor Trend Object are:
PlantWorks PTF-2 Runtime Monitor Object Setup Operations
\FF\BIN\DDF.EXE
\FF\MSG\DDF.MSG
\FF\DLL\DSS.DLL
\FF\BIN\RTM.EXE
\FF\MSG\RTM.MSG
\FF\BIN\TND.EXE *
* \FF\BIN\TND.EXE will be broken out into two files: \FF\BIN\TND.EXE
and \FF\DLL\TND.DLL.
Figure 8
Figure 9
PlantWorks PTF-2 Runtime Monitor 'Goto Last Display' Action
Function Provided:
The ability to create a 'Goto Last Display' object directly from Display Definition.
The new object will be added to the Operation Setup list box as shown in Figure 8 and 9.
Using the 'Goto Last Display' Object in Runtime Monitor
The 'Goto Last Display' object will allow the user to return to the previous display without using accelerator keys or drop-down menus. This object will be provided in Display Definition and will be associated with a graphical object. Thi s object if selected will work similar to CTRL+L in Runtime Monitor.
PlantWorks PTF-2 Runtime Monitor 'Goto Alarm Manager' Action
Function Provided:
The ability to create a 'Goto Alarm Manager' object directly from Display Definition. The new object will be added to the Operation Setup list box as shown in Figure 8 and 9.
Using the 'Goto Alarm Manager' Object in Runtime Monitor
The 'Goto Alarm Manager' object will allow the user to go directly to Alarm Management Services without using accelerator keys or drop-down menus. This object will be provided in Display Definition and will be associated with a graphical object. This object if selected will work similar to CTRL+A in Runtime Monitor.
PlantWorks PTF-2 Runtime Monitor 'Supervisory Logon/Logoff' Action
Function Provided:
The ability to create a 'Supervisory Logon/Supervisory Logoff' object directly from Display Definition. The new object will be added to the Operation Setup list box as shown in Figure 8 and 9.
Using the 'Supervisory Logon/Logoff' Object in Runtime Monitor
The 'Supervisory Logon/Logoff' object will allow the user to perform a logon/logoff without the use of accelerator keys or drop-down menus. This object will be provided in Display Definition and will be associated with a graphical object. This object if selected will work similar to CTRL+O and CTRL+E in Runtime Monitor. A dialog box will appear if a logon is being performed.
PlantWorks PTF-2 Runtime Monitor 'I/O Point Name Select'' Action
Function Provided:
The ability to create a 'I/O Point Name Select' object directly from Display Definition. The new object will be added to the Operation Setup list box as shown in Figure 8 and 9.
Using the 'I/O Point Name Select' Object in Runtime Monitor
The 'I/O Point Name Select' object will allow the user to find a specific I/O Point without using accelerator keys or drop-down menus. This object will be provided in Display Definition and will be associated with a graphical object. This object if selected will work similar to CTRL+N in Runtime Monitor. A dialog box will appear when using this object allowing the user to enter an I/O Point.
Modules Affected/Replaced:
The modules that are expected to be replaced in the implementation of the Runtime Monitor 'Goto Last Display', 'Goto Alarm Manager', 'Supervisory Logon/Logoff', 'I/O Point Name Select' Actions are:
END OF DOCUMENT
This page formally marks the end of this document.