Reliance 4 – example projects for download

The ZIP archive contains all example projects shipped with the Reliance 4 SCADA/HMI system. Unpack the archive contents to the folder where you have installed Reliance 4.

AirCondition is an interactive visualization project designed to demonstrate functions of basic graphical components. Simple scripts are also used in the project to simulate the environment in an office. The project is translated into several languages (English, Russian, Czech, Dutch, and Turkish).

You are enabled to control the input and output fan, recuperator, cooler, heater, humidifier and to simulate the cleanliness of both the input and output filter or errors. A simple physical model of the office environment (temperature and humidity) is simulated with three scripts.

BoilerRoom is an interactive project designed to demonstrate functions of basic components, such as Button, Display, Active Picture, Pipe, Progress Bar, and Real-Time Trend, for the visualization of the water-heating process in a central heating gas boiler. The project also demonstrates how to use alarms, trends, reports, and event and periodic scripts. Within the project, several users with different access rights are defined through the User Manager (you can log on with an empty password). A similar visualization project is created step by step during the Reliance 4 training courses.

Factory is an interactive project designed to demonstrate functions of basic components, such as Button, Display, Pipe, Picture, Progress Bar, for the visualization of a simple chemical production process. Four basic chemicals are mixed together in a boiler (the mixing ratio can be defined manually or via recipes). The final product is stored in a tank and fed to moving tank trucks. A truck is represented as a picture and a progress bar grouped together. The movement of the truck is achieved by dynamically changing the X coordinate using scripts.

At runtime, the project starts in the automatic mode (script-controlled), but you can switch the mode by clicking on the Manual mode button located on the bottom part of the visualization window. Based on the data table (database) to which all important process values are logged, you can easily create a trend or report.

SMS is a project designed to demonstrate sending and processing text messages via scripts. To successfully run the project, it is required that SMS Driver be installed and a GSM modem connected (e.g., Siemens M20 Terminal).

The project contains the periodic script StatusSMS and two event scripts – RecievedSMS and SendSMS. To select a type of GSM modem and specify the communication options including the SMS service center number, bring up the Project Structure Manager and choose the SMS page for the selected computer.

Tannery is a project designed to demonstrate how to use the Reliance SCADA/HMI system for the control of the chemical process of leather tanning. The project contains about 250 tags and is based on a real industrial process.

After the project is started, select the top left drum to run the process visualization. The visualization window contains a set of tanks interconnected via pipes with valves and pumps. The toolbar contains control (Pause, Restart, Recipe) and configuration commands (Settings). The Time shrink option allows you to specify the speed of the simulation. The visualization runs in an automatic mode (script-controlled).

SendAlarmsUsingGroups_Simple is a project designed to demonstrate how to send alarm/event information to certain users based on the alarm/event group defined in the project. The alarm/event information can be sent via E-mail or SMS (text messages) as the alarms/events occur, end, get acknowledged.

In the Project Options dialog box, an alarm/event group named AlarmsToSend is defined (Project > Alarms/Events > Groups).

A device named PLC1 is defined via the Device Manager. In the device, alarms named TrivialAlarm1, SeriousAlarm1, and CriticalAlarm1 are defined to be simulated through the buttons in the visualization window. On the Advanced page, each alarm's Alarm/event groups property determines whether the alarm belongs to the AlarmsToSend group depending on its severity (TrivialAlarm1 does not belong to this group because it is not severe).

Four users are defined via the User Manager. On the Notification page, each user's Alarm/event groups property determines whether the user should receive information on the alarms/events that belong to the AlarmsToSend group. The method of sending the information is specified by the Notify via E-mail and Notify via SMS options (the Notification page). Some users (technicians) are notified via E-mail and SMS, others (the directors and technical managers) are only notified via E-mail. For the users to be notified via E-mail, it is necessary to enter a valid E-mail address (the Basic page, the E-mail property). For the users to be notified via SMS, it is necessary to enter a valid phone number (the Basic page, the Phone number property).

A computer named PC1 is defined via the Project Structure Manager. On the Notification page, the Notify via E-mail, Notify via SMS, On start, and On end options are active. The Message text property contains the necessary information and doesn't have to be altered.

To send information via E-mail, it is necessary to configure the options on the E-mail page, especially the SMTP server address.

To send information via SMS, it is necessary to activate the Start SMS driver option on the SMS page and configure the other properties.

SendAlarmsUsingGroups_TwoAreas is a project designed to demonstrate how to send alarm/event information to certain users based on the alarm/event groups defined in the project. The alarm/event information can be sent via E-mail or SMS (text messages) as the alarms/events occur, end, get acknowledged.

In the Project Options dialog box, 5 alarm/event groups are defined (Project > Alarms/Events > Groups). The groups are defined based on two criteria: alarm severity (the TrivialAlarms, SeriousAlarms, CriticalAlarms groups) and alarm area (Area1, Area2).

The Area1 and Area2 folders are defined through the Device Manager to represent the areas where particular devices (PLCs, telemetry systems, etc.) are located. In each folder, one device is defined. In each device, alarms named TrivialAlarm1, SeriousAlarm1, and CriticalAlarm1 are defined to be simulated through the buttons in the visualization window. Each alarm has an enumeration of the groups it belongs to (the Advanced page, the Alarm/event groups property) based on alarm severity and the area where the respective device is located.

Users are defined within the Area1 and Area2 folders via the User Manager. Each user has an enumeration of the groups of alarms/events (the Notification page, the Alarm/event groups property) that he/she should be notified of. The group enumeration depends on alarm severity and the area that the user belongs to. The alarms that belong to the TrivialAlarms group are not sent to any users. The method of sending the information is specified by the Notify via E-mail and Notify via SMS options (the Notification page). Some users (technicians) are notified via E-mail and SMS, others (the directors and technical managers) are only notified via E-mail. For the users to be notified via E-mail, it is necessary to enter a valid E-mail address (the Basic page, the E-mail property). For the users to be notified via SMS, it is necessary to enter a valid phone number (the Basic page, the Phone number property).

A computer named PC1 is defined via the Project Structure Manager. On the Notification page, the Notify via E-mail, Notify via SMS, On start, and On end options are active. The Message text property contains the necessary information and doesn't have to be altered.

To send information via E-mail, it is necessary to configure the options on the E-mail page, especially the SMTP server address.

To send information via SMS, it is necessary to activate the Start SMS driver option on the SMS page and configure the other properties.

DataGrid is a simple project designed to demonstrate basic features of the Data Grid component. There are several tags defined within the System device that are displayed in the data grid's columns (Array_Value, Array_FgColor, and Array_BgColor) and tags that control the global behavior of the component (Offset, Position, and RowCount). The Array_FgColor tag controls the font color. The Array_BgColor tag controls the background color. These tags are initialized in scripts.

After the project is started in the runtime software, you are enabled to set values in the data grid's cells.

DataGrid_SelectItemDialog is a project designed to demonstrate how to use the Data Grid component when selecting an item from the list available in the Select Item dialog box. To bring up the dialog, click the Select Item button located in the main window (MainWindow). After closing the dialog, the main window displays whether an item has been selected or not (Yes/No

the System/SelItemFromList tag's value; the item's name

the System/SelItemName tag's value).

The Select Item dialog is a dialog window named SelectItemDialog. This window is displayed in exclusive mode (modally). A Data Grid component and two buttons (OK and Cancel) are placed into the SelectItemDialog window. The Data Grid component consists of a single column that is linked to the System/ItemNames tag of type Array of String containing the list of items. The System/ItemNames tag is filled with values in the BeforeSelectItemDialog script executed by pressing the Select Item button. The selection results, i.e., the values of the System/SelItemFromList and System/SelItemName tags, are set in the AfterSelectItemDialog script executed by pressing the OK button.

DataTree_ControlArea is a project designed to demonstrate how to use the Data Tree component for the visualization of the control area tree structure. Tags of all basic data types listed in the tree structure (the Tags subtree) are defined within the System device. Two data tables are defined via the Data Table Manager to log the System device's tags. Two trends and two reports are also defined via the Trend Manager and the Report Manager to visualize historical data. In addition, actions to display current and historical alarms/events, tables, and trends are defined via the Action Manager. These actions are connected to the data tree nodes. The Data Tree component's structure simulates the structure of the control area.

The Display cell is used to view the tag parameters (the Tags subtree). At runtime, you can also edit tag values using the displays located to the right of the tree. To activate commands or change the structure of the Data Tree component, it is required to log on. If you log on as the Edit user, you are allowed to edit the Data Tree structure (no password is required). If you log on as the Command user, you can execute actions, such as view trends, reports, or alarms/events list.

DataTree_Grid is a project designed to demonstrate how to use the Data Tree component to display non-array tags in a tabular format. The project contains ten virtual devices defined via the Device Manager. All virtual devices contain the identical set of tags. For each virtual device, one data table is defined via the Data Table Manager to log the tag values. The same number of trends are defined via the Trend Manager to display historical data.

An action is defined for each trend via the Action Manager. These actions are connected to the data tree nodes. Within the Data Tree component, a node is defined to display all tag values. For each tag displayed in the node's row, a cell is defined.

At runtime, you are enabled to change the tag values and to show trends via actions (a trend can be displayed by double-clicking on the trend icon).

DataTree_Localized is an example project designed to demonstrate how to use text strings in the Data Tree component that are translated into several languages.

The component is used to display the list of actions. For individual tree nodes, aliases are specified to be localized into different languages.

The tree nodes are connected to actions. At runtime, an action can be executed by double-clicking on the alias (the node description).

IPCamera_Axis is a project designed to demonstrate how to use the Axis IP Camera component to display and record data received from the Axis IP camera connected to the computer. To successfully run the project, it is required to have IP camera drivers installed on your computer (they are part of the Reliance Add-On Pack installer).

Within the System device, the record and standby tags of type Bool are defined. The visualization window contains an Axis IP Camera component and two Button components. Before you run the project, the camera's URL or IP address and login information for the connected IP camera must be specified on the Functions page of the component's Properties dialog box.

IPCamera_Pelco is a project designed to demonstrate how to use the Pelco IP Camera component to display data received from the Pelco IP camera connected to the computer. To successfully run the project, it is required to have IP camera drivers installed on your computer (they are part of the Reliance Add-On Pack installer).

Within the System device, a tag of type Bool named standby is defined. The visualization window contains a Pelco IP Camera component and a Button component. Before you run the project, the camera's RTSP URL must be specified on the Functions page of the component's Properties dialog box.

IPCamera_Vivotek is a project designed to demonstrate how to use the Vivotek IP Camera component to display and record data received from the Vivotek IP camera connected to the computer. To successfully run the project, it is required to have IP camera drivers installed on your computer (they are part of the Reliance Add-On Pack installer).

Within the System device, the Input and Output tags of type Word and the Record and Standby tags of type Bool are defined. The visualization window contains a Vivotek IP Camera component and four Button components. Before you run the project, the camera's URL or IP address and login information for the connected IP camera must be specified on the Functions page of the component's Properties dialog box.

RealTimeChart_Stacked is a project designed to demonstrate how to configure the Real-Time Chart component to show a horizontal stacked bar chart. Each bar of the chart consists of two differently colored parts whose size can be changed separately using a Display component. The total bar size is the sum of each part's size.

The component is configured in the following way:

1. Bring up the component's Properties dialog box and select the Horizontal bar type (Series > Properties > Type).

2. According to the example, the X/Y-value property must be specified for each point of the chart (Series > Data > X/Y-value).

3. Select the Stacked property as follows: Static > Properties > Series > Format > Multiple Bar.

SimpleTimeProgram is a project designed to demonstrate how to use the Simple Time Program component. Within the System device, the DataArray tag is defined to store the time program's configuration data. The remaining tags (auxiliary tags

stored in folders) are used to display this data in the visualization window.

The DecodeData event script is defined via the Script Manager to extract the data from the DataArray tag to the auxiliary tags. To configure the time program at runtime, click on the Configuration button. Upon configuration, the data from the DataArray tag is automatically decoded and displayed in the visualization window. The DataArray tag values are displayed in the table on the left side of the visualization window.

AppendRecordsToDb is a project designed to demonstrate how to use the RDb.AppendRecord method to add a group of records into a data table. One record (row) in the Data1 data table contains the values of the following tags (columns): RecordTimeStamp, LongInt, String, and Word.

The data that will be logged to the data table is stored in array-type tags named LongArray5, StringArray5, and WordArray5. The RecordTimeStamp value is assembled from the tags MinuteArray5, HourArray5, DayArray5, and the constants c_Month and c_Year before the record is logged to the data table. The BlockSamplingData tag is connected to the Blocking tag property of the data table and to the corresponding button in the visualization window.

The sampling method of the data table is set to Script-controlled (by RDb.AppendRecord procedure) – this means the data can be logged only from a script by calling the RDb.AppendRecord method. The time stamp source is linked to the RecordTimeStamp tag – records don't have to be logged in a chronological sequence.

The InitArrays script is defined via the Script Manager and initializes the array-type tags. This script is executed at project startup via the AfterStartProject script. The SaveArray script is started by pressing the Save array of records button in the visualization window and performs the logging of records to the data table. The values of the RecordTimeStamp, Word, LongInt, and String tags are set and the RDb.AppendRecord method is called inside the "for" statement (this sequence is performed five times). You can view the data logged in the data table via the trend or report viewer.

AppendRecordToDb is a project designed to demonstrate how to use the RDb.AppendRecord method to add a new record into a data table.

Tags named LongInt, String, and Word are defined within the System device. The values of these tags will be logged to the data table. The following tags are also defined: RecordTimeStamp, which contains the current time (the RSys.Now method), and BlockSamplingData, which is linked to a button in the visualization window (you can enable/disable data logging with this button).

The Data1 data table contains three fields connected to the three tags mentioned above. The sampling method is set to Script-controlled (by RDb.AppendRecord procedure). The Time stamp source property is set to Tag (RecordTimeStamp) and Blocking tag is set to BlockSamplingData. The SaveRecord event script is defined via the Script Manager. This script sets the RecordTimeStamp tag to the current time and calls the RDb.AppendRecord method. To start the script, press the Save record button.

LogDataToSQLServer is a project designed to demonstrate how to log tag values to an external SQL server and how to visualize this data in the trend viewer. The example requires access to an SQL server (MS SQL Server is part of the Reliance Add-On Pack installer).

Four tags of type Word are defined within the System device. The tag values are logged with a period of 5 seconds to the Pressures and Temperatures data tables defined via the Data Table Manager (the Database type property is set to SQL). The SQLServer connection is defined on the SQL page of the Project Options dialog box (you may have to update some of the parameters). Notice that the defined SQL connection is selected in the Project Structure Manager as a parameter for the connected data tables (the SQL connection property on the Basic page).

The main visualization window contains four Edit Box components connected to the Word-type tags and two Button components that display trends.

ODBCFromScript is a project designed to show how to access the ODBC databases in the Reliance 4 SCADA/HMI system via scripts. The Define script defined in the project contains the ReadDataFromSQLTable and WriteDataToSQLTable procedures. The procedures work with the "ADODB.Connection" object and related objects. The procedures are called from the ReadDataFromSQLTable and WriteDataToSQLTable scripts with the parameters defined by the constants c_ConnectString and c_TableName.

You have to alter these constants according to your database. To help you construct the c_ConnectString constant, see the Connection string text box (Project Options > SQL). Configure the connection via the Edit Connection String command before you copy the string.

RandomAccessToDataTable is a project designed to demonstrate how to manually (randomly) read/write data from/to a data table of type dBASE. The Records data table is defined via the Data Table Manager. The Data acquisition method property of this data table is set to Not specified and the Archive files property on the Advanced page is set to None. The table contains the following fields: Number, Length, Color, and Material. The fields are linked to the same-named tags of different types defined through the Device Manager. The records in the data table are accessed manually from a script. You can view the records stored in the data table via the record viewer (the Report1 report).

The Init script defined via the Script Manager contains the procedure and function definitions and is executed only once before all other scripts in a thread. The RDb.CreateTableObject command is used to create an instance of an object that will be used to access the Records data table. For example, to add a new record to the data table (the AppendRecord procedure), the following methods of the object are called: OpenTable, Append, SetFieldValue, Post, and CloseTable. For more information on the TTable object used to access data tables, see the Scripts help file.

SQLFromScript is a project designed to demonstrate how to read and write data from/to an SQL database via methods of the "ADODB.Command" and "ADODB.Connection" objects. The ReadDataFromSQLTable, WriteDataToSQLTable, and Define scripts are defined in the project. The first two scripts are event scripts calling the procedures defined within the Define script (the script is started only once before all other scripts at the process – script engine – initialization). You have to set the Connection string in the Define script according to your SQL server. The usage of the SELECT and INSERT SQL commands is demonstrated in the procedures.

CommWithExternalProgram is a project designed to demonstrate how to transfer data between the Reliance system and an external application via the COM interface. The RandomValue and Seconds tags defined in the project are used to hold the data received from the external application. The project also contains the RelianceValue tag, which is used to send the data to the external program (you can set its value in the visualization window). The external application is located in the <Project>\Main\Apps folder and it is automatically started upon project startup (the Project Options > Scripts > Other > After run project property specifies the Create_GlobalObject script, which is to run the program). Before the project is started for the first time, the external program needs to be started manually to register the COM object.

The project's main visualization window contains two buttons connected to the scripts that are used to start or terminate the external application. The window also contains three Display components linked to the RandomValue, Seconds, and RelianceValue tags. The Create_GlobalObject and Free_GlobalObject event scripts defined through the Script Manager are designed to start and terminate the external application (the CreateObject method is used to start the external application). The SendNewValue script is designed to send the value of the RelianceValue tag to the external application (this can be achieved by calling the SetValue method of the external application). The last object defined via the Script Manager is a periodic script named Read_ObjValues (its period is 0.3 seconds), which is used to read the values from the external program (the GetRandomValue and GetSeconds methods of the external program are used to read the values).

The external application, which is part of the example project, shows the current values of the two dynamically generated tags and the list of values received from the visualization application. The external program is written in Borland Delphi (Pascal) and supplied including the source code (the source code is located in the <Project>\Main\Apps\Source\External.zip directory).

DDE_Client is a project designed to show how to use the DDE protocol to exchange data between two Reliance projects. The DDE_Client project needs to be started in the Reliance Control software (and, simultaneously, the DDE_Server project needs to be started in the Reliance Control Server software). If both projects are running successfully, you can set a value in the DDE_Server project and the change is instantly visible in the DDE_Client project (and vice versa).

A DDE device named R_CtlSrv_DDEServer is defined through the Device Manager. The DDE server property is set to R_CtlSrv (it is the DDE server's filename without an extension). Within the DDE device, there are tags defined in the Tags folder. These tags correspond to the tags defined in the DDE_Server project. For clarity's sake, the tags are divided into the T0 and T1 folders. For each tag, the DDE Item property is configured so that it corresponds to the configuration of the same property in the DDE_Server project. The R_CtlSrv_DDEServer device is connected to the DDEClient computer via the Project Structure Manager. The DDE topic property is set to DdeServer (this is if the DDE server is the Reliance runtime software, i.e., Reliance View, Reliance Control, Reliance Server, or Reliance Control Server).

DDE_Server is a project designed to show how to use the DDE protocol to exchange data between two Reliance projects. The DDE_Server project needs to be started in the Reliance Control Server software (and, simultaneously, the DDE_Client project needs to be started in the Reliance Control software). If both projects are running successfully, you can set a value in the DDE_Server project and the change is instantly visible in the DDE_Client project (and vice versa).

Two virtual devices (T0_Server and T1_Server) defined through the Device Manager contain internal tags (in the Tags folder within each device). The tags are configured for DDE sharing (the Sharing page). The two virtual devices are connected to the DdeServer computer via the Project Structure Manager.

ExportImportXLS is a project designed to demonstrate how to access MS Excel files via the COM interface (the MS Excel application has to be installed on the same computer as the Reliance SCADA/HMI system). The Var_Float, Var_Int, and Var_Str tags defined through the Device Manager are linked to the corresponding Display components in the main visualization window (the Enable setting value option is active). The values of these tags are exported/imported from/to an *.xls or *.xlsx file. The ExportToExcel and ImportFromExcel event scripts (activated by pressing the respective button in the visualization window) are defined through the Script Manager. The Excel file named Values is located in the <Project> folder.

At the beginning of the ExportToExcel script, an instance of the "Excel.Application" object is created. Afterward, a new workbook (WorkBook) and a new worksheet (WorkSheet) are successively created. The Cells method is used to write the data to the required cells. The workbook is stored by calling the SaveAs method and all created objects are released from memory.

At the beginning of the ImportFromExcel script, an instance of the "Excel.Application" object is created and the Values file is opened with the Open method of this object. The values stored in the file are loaded via the Cells method.

ExportHistDataToCSV is a project designed to show how to export historical data from a relational database to a text file in the CSV format. It is assumed that the computer on which this project runs is equipped with Microsoft SQL Server with its instance named SQLEXPRESS and credentials preset when installing SQL Server from Reliance Add-On Pack. In case SQL Server has been installed in another way, it is necessary to customize the connection string (Project Options > SQL) and the value of the constant c_ConnectionString in the Define_DataExport script. A data table named IncrementalData is defined through the Data Table Manager. The Reliance SCADA system logs the table's data to the table named IncData contained in the database R_ExportHistDataToCSV in Microsoft SQL Server running on the same computer (both the database and the table will be created with Reliance once the project is started for the first time).

To export the historical data to the file, scripts defined through the Script Manager are used. The export itself is performed by calling the ExportHistDataToCSV procedure, whose definition is contained in the Define_DataExport script. The name of a physical table (in this case, it is "IncData", see the ExportHistDataToCSV script) is passed as a parameter to the procedure. In the same way, it would be possible to export historical data from any other table if multiple tables were contained in the database (it would be enough to pass the name of this table as a parameter to the procedure).

You can export either all the data logged to the table or data from a specific time period (time range). This can be configured in the visualization window named MainWindow. To export all data, deactivate the options Start and End. Otherwise, activate the options Start and/or End and enter the time range's start and/or end. Data export can be invoked by clicking on the Export button (this will run the ExportHistDataToCSV script).

ImportFromCSV is a project designed to demonstrate how to use scripts to import data from a text file (CSV). The project contains the following tags: RoomNumber, Occupied, Date, and Time. The ImportCsvFile event script is designed to load the data from a file to these tags. The visualization window contains a Button component used to start the script and four Display components that display the imported data after the script is finished. The values are imported from the <Project>\Import.csv file.

LogDataToFileAndDb is a project designed to show how to log tag values to a file and database via a script. The main visualization window contains three Display components (displaying the sine and cosine of a periodically incremented angle) and two Button components used to activate/deactivate data logging to the file or data table. The data will be logged to the <Project>\ History\Data\AngleData.txt file and/or to the AngleData data table (the sampling method of the data table is set to Script-controlled (by RDb.AppendRecord procedure)). You can view the data logged to the data table via the report viewer (the AngleData report).

An event script named Define is defined via the Script Manager. The script starts before all other scripts and sets the constants (the Run on thread initialization option on the Advanced page is enabled). A periodic script named Calc_and_log calculates the sine and cosine and increments the Angle tag by one degree every 200 ms. The script contains the Log_to_file procedure, which uses the "Scripting.FileSystemObject" object to log the data to the file, and the Log_to_database procedure, which uses the RDb.AppendRecord method to log the data to the AngleData data table.

AMiT is a project designed to demonstrate basic features of the AMiT PLC connected to the visualization application, i.e., reading/writing tag values, logging values to a data table, bit access, etc. Within the AMiT1 device, a group of tags containing current values (Sawtooth_1, Sawtooth_2, Sine, ARC_index) and current digital values (Bit1, Bit2, Bit3), and a group of array-type tags used to display the Real-Time Trend component are defined via the Device Manager. The current tag values are logged to the Database1 data table and can be displayed in Trend1 defined through the Trend Manager. Via the Real-Time Trend Manager, Trend1_RT is defined to be displayed directly in the visualization window.

The main visualization window contains several Display components connected to the Sawtooth_1, Sawtooth_2, and Sine tags whose values can be changed even if the AMiT1 device is not in the online mode, i.e., the Online property is not enabled (Project Structure Manager > PC1 > AMiT1 > Basic > Online), e.g., for testing purposes. If the device is not in the online mode, tag values can be set, but a connection with the device is not made.

BACnet is a project designed to demonstrate how a device is connected via the BACnet communication driver. BACnet is not only used for defining communication services. Among other things, it is also used to define a number of objects and their properties through which data is presented. In this project, there are tags representing the properties of all Reliance-supported objects.

A device named BACnet1 is defined via the Device Manager. Within the device, several tags are defined and divided into folders based on individual BACnet objects. Each folder contains tags whose value allows you to read or write the properties of an object.

The type of object is specified by the Object type option, the property is specified by the Property identifier option. The Instance number option is used to distinguish the objects. The data type of a tag is changed automatically depending on the selected property. However, it can be changed subsequently. To test the example with a real BACnet device, it is necessary to configure these properties based on the real program of the device. Not all objects need to be used within the program and the Instance number option can differ for each object. Not all properties within BACnet objects are compulsory. Thus, some tags might not be updated successfully.

Upon project startup, the tray-type window on the left side contains several buttons used to switch between the windows defined within the project. Individual project windows contain displays and data grids showing objects' data based on tag data types.

DeviceCommErrorAlarm is a project designed to demonstrate how to replace the alarm automatically triggered by a device communication error with a custom alarm defined through the Device Manager. This alarm will remain active for the duration of the communication error. This is the difference from the alarm that is automatically triggered by Reliance when an error in the communication with a device occurs. It is an "event" type of alarm – it is triggered, but it does not remain active; Reliance does not check to see if the error condition still exists – this is a drawback).

Within the Modbus1 and Modbus2 devices, the CommError tag of type Bool is defined via the Device Manager. It is an internal tag (not a physical tag from a PLC). In addition, the CommError alarm defined within the same devices is linked to the CommError tag. The alarm is triggered by the leading edge of the tag value (the off-to-on transition).

The Modbus1 and Modbus2 devices are connected to the PC1 computer via the Project Structure Manager. The communication options are defined through the Channel1 object that represents a communication channel. On the Advanced page of the channel properties, there are links to scripts to be executed when communication with the respective device is started, interrupted due to an error, and restored. The full name of the communication channel (device name/channel name, e.g., Modbus1/Channel1) is automatically passed to these scripts. This information is available in the scripts as the value of the SenderName property. This allows you to choose the same scripts for both devices' communication channels.

The Define script, which contains the definition of the SetDeviceCommError procedure, is defined via the Script Manager. On the Advanced page of the script's Properties pane, the Run on thread initialization option is active to execute the script prior to any other script supposed to run in the same thread of execution. The SetDeviceCommError procedure is called from a script named DeviceCommError, which executes every time that an error in communication with the device occurs, and from a script named DeviceCommStarted, which executes every time that communication with the device is started or restored. The SetDeviceCommError procedure has the following parameters:

FullChannelName: the full name of the communication channel (device name/channel name, e.g., Modbus1/Channel1)

CommError: the value of True or False (determines whether there is an error in communication)

The SetDeviceCommError procedure first splits the value of the FullChannelName parameter into the device name and the channel name and then writes the value of the CommError parameter to the internal tag CommError in the respective device by calling the RTag.SetTagValue method. This results in triggering a new alarm or ending the existing one.

Generic_SimpleText is a project designed to demonstrate how the Generic device is used to read data from any device in the form of a text string. A device named Generic1 is defined via the Device Manager. Within the device, several special tags whose values are used for the communication are defined.

The InCount tag's value specifies the number of characters (bytes) received by the tag of type Input buffer.

The InBuffer tag is an array of bytes containing received data.

The InString tag is a string containing received data in a text format.

The OutCount tag's value specifies the number of characters (bytes) sent from the tag of type Output buffer.

The OutBuffer tag is an array of bytes containing data to send.

The Control tag's value is used to control sending data.

In this example project, no data is sent, the Control and OutCount control tags are only used to open the communication port.

The main visualization window contains a button used to open the communication port. To do so, the Control tag's value is set to logical 1 and the number of bytes to send in the OutCount tag is set to 0 via a script.

The two Display components are used to show the received character count and received data in the form of a text string.

The other button is used to reset the received character count and delete the input buffer.

Generic_Teco is a project designed to demonstrate how a communication protocol is implemented and how a device is connected via the Generic communication driver. In this example project, the EPSNET protocol of the Tecomat PLC is chosen.

A device named Generic1 is defined via the Device Manager. Within the device, several special tags whose values are used for the communication are defined.

The InCount tag's value specifies the number of characters (bytes) received by the tag of type Input buffer.

The InBuffer tag is an array of bytes containing received data.

The OutCount tag's value specifies the number of characters (bytes) sent from the tag of type Output buffer.

The OutBuffer tag is an array of bytes containing data to send.

The Control tag's value is used to control sending data.

The PacketName tag provides an easy way to identify the communication packet in the communication statement or in the log file. If this tag is not used, its default name Packet is displayed in the statement.

In addition, an internal tag named Ethernet is defined. Its value determines whether a serial cable or Ethernet is used for communication. The value should be reflected when creating custom communication packets.

The main visualization window contains several controls intended for configuring and controlling the communication itself. The following communication packets can be sent: a packet for establishing communication, a packet for reading a data block from any register and address, a packet for reading/writing data from/to a tag of the selected data type from any address. By pressing the respective button, a communication packet will be created via a script according to the specified configuration settings and sent to the communication channel.

In the middle part of the window, sent and received data is displayed in a tabular format. In the top right corner, the control and status tags' values are shown.

In the bottom right corner, the checking tags' values read from the PLC by the Teco native communication driver are displayed (these tags lie on randomly selected addresses).

In order for the example project to be fully functional, it is necessary that the Ethernet option's value be set in compliance with the channel type specified through the Project Structure Manager.

OPC_DeviceCommStatus is a project designed to demonstrate how to use a script to determine the state of an OPC server by testing the quality of a tag. Via the Device Manager, you have to configure the OPCDevice1 device according to your local OPC server. The OPC group of this device contains an internal tag that is periodically tested in the script (if the tag quality is not 'Good', it means that the OPC server is not connected). For this purpose, the Random_UInt1 tag is used in the project. The project also contains the OPCDevice1Connected tag that, after the script is evaluated, contains information regarding the OPC device connection status and is linked to the Active Text component placed in the visualization window.

In addition, the Define script, which is executed at the thread initialization, is defined via the Script Manager. This script defines the procedure that evaluates the tag quality (it is more effective to define a procedure than to write the code directly into the script's body). The script reads the Random_UInt1 tag value with the RTag.GetTagValue method. Each method of the Reliance objects sets the value of the RError.Code property. If the value of this property is not equal to zero, an error occurs. To ensure that 'Bad' quality of the value is considered an error, the Treat invalid tag value as error option must be enabled (Project Options > Scripts > Other). The procedure is called from the UpdateOPCDeviceCommStatus script with the period of one second.

OPC_RemoteServer is a project designed to demonstrate how to connect Reliance's runtime software to an OPC server that is not running locally. The OPC1 device of type OPC is defined via the Device Manager. The OPC server Prog ID property allows you to select the OPC server for the device (e.g., from the local network). The PC1 computer, to which OPC1 is connected, is defined via the Project Structure Manager. On the Driver page of the device's Channel1, the Connect to driver property is set to On remote computer. Also the computer name is specified (RemotePC). The RemotePC computer is the second computer defined via the Project Structure Manager. This computer's only purpose is to identify the remote computer on which the OPC server is running. It holds the IP address of the OPC server (the Basic page).

Note: This type of connection to a remote OPC server is not advised because of certain drawbacks. The recommended way to connect to an OPC server is via Reliance's runtime software running on the remote computer. This means that the Reliance data server is running on the same computer as the OPC server and connection to other computers of the visualization project is provided via Server Connection Groups or via thin clients.

Teco_Databox is a project designed to demonstrate how to transfer data from/to the Databox memory of the Teco device. Via the Device Manager, the Tecomat1 device of type Teco and its IP address are defined. On the Databox page, the Enable reading/writing Databox option is active and the links to the respective tags defined within the System device are specified. The following tags are defined within the System device: The Control of type Byte tag is used to control the data transfer from/to the databox (0 – ready, 1 – read, 2 – write). The Status tag of type LongInt is connected to the Active Text component placed in the visualization window and indicates the activity that is being performed with the databox (Ready/Reading/Reading completed/Read error/Writing/Writing completed/Write error). The DataLength and DataOffset tags are used to define the range of data to be transferred from/to the databox. The current data range is accessed via the DataBuffer tag of type Array of Byte.

The visualization window contains a Data Grid component (Databox data) that displays the values of the DataBuffer tag and the corresponding index of the data in the databox (the IndexArray tag). The latter tag is automatically updated in the InitIndexArray script every time the databox is accessed (read or written).

Teco_ModemComm is a project designed to demonstrate how to make a connection to the Teco PLC via a modem connected to the computer's serial port. Within the System device, several tags of type Word are defined to monitor and control the state of the modem and the PLC device. The Modem1Control tag is used to control Modem1 – it connects the Combo Box component placed in the visualization window and the Modem1 object defined via the Project Structure Manager (on the Basic page, the Control property must be active and the tag specified). The Tecomat1Control tag is used to control Tecomat1 (allows selecting one of the following commands: Disconnect, Connect, 'Connect, read data and disconnect') – it connects the Combo Box component placed in the visualization window and the Channel1 object defined via the Project Structure Manager. The Tecomat1Status tag, which is also connected to the Channel1 object, is processed in the Tecomat1StatusChanged script and the result is shown in the visualization window. The Tecomat1Status tag is linked to the Status property via the Project Structure Manager (Tecomat1 > Channel1 > Advanced). Similar tags exist for Modem2 and Tecomat2. Also, the Tecomat1 and Tecomat2 devices and the required tags are defined via the Device Manager.

Through the Project Structure Manager, the Channel type of the Tecomat1 device is set to Dial-up (modem), the required Phone number is specified, and the Tecomat1Control and Tecomat1Status tags are connected on the Advanced page. In the Modems folder, the Modem1 object is defined and the Modem1Control tag is connected to the Control property of this object. The Tecomat1StatusChanged script is defined via the Script Manager. The script uses bit masking to extract information about the Tecomat1 device's state from the Tecomat1Status tag. Similar objects are defined for the Tecomat2 device.

BoilerRoom_WindowTemplate is a project designed to demonstrate how to use data structures and window templates. The visualization project represents a boiler room with a gas boiler. Information related to individual devices (e.g., pump and burner), measured quantities (water and air temperature), and control parameters is arranged into data structures (Pump, Burner, MeasuredTemperature, ControlParameters

see the Data Structure Manager). These elementary structures are then contained in more complex data structures: Boiler and BoilerRoom. Based on the BoilerRoom data structure, structured tags named Data are defined within the BoilerRoom1 and BoilerRoom2 devices (see the Device Manager). Then, there are window templates corresponding to the Pump, Burner, MeasuredTemperature, and ControlParameters data structures. These elementary templates are then contained in more complex templates (Boiler and BoilerRoom). Subsequently, the BoilerRoom template is repeatedly used in the normal visualization windows (BoilerRoom1, BoilerRoom2). Each time the template is used, the respective structured tag of type BoilerRoom must be specified.

MotorDetails_WindowTemplate is another project designed to demonstrate how to use data structures and window templates. The main visualization window (MotorOverview) is an overview window displaying 4 engine symbols. By double-clicking a symbol, detailed information on the respective motor (ID, status, speed) and its controls (speed setpoint, start/stop button) is displayed.

Information on the device of type motor is arranged in the Motor data structure through the Data Structure Manager. This data structure corresponds to the same-named window template defined via the Window Manager (the Templates folder). Based on the Motor data structure, structured tags named Motor1, Motor2, Motor3, and Motor4 are defined within the System device (see the Device Manager). Subsequently, the Motor template is repeatedly used in the modal visualization windows Motor1, Motor2, Motor3, and Motor4 defined via the Window Manager (the Motors folder). Each time the template is used, the respective structured tag of type Motor must be specified.

BoilerRoom_ClientServer is a project that adds the network functionality to the BoilerRoom demo. A new computer named Client1 has been created through the Project Structure Manager. The already defined users, trends, and reports are connected to this computer (objects are only accessible from a specific computer if they are connected to it). In addition, a new server connection group with a new server connection (named Server1) have been created. The Server computer property of the server connection is set to Server1. This connection is used to connect the BoilerRoom1 and BoilerRoom2 devices and the same-named data tables to the Client1 computer (the Data transfer property is set to Network instead of Direct and directories for the data tables are set to $(HistoryData)\Client1\). The Address property (Server1 > Basic) is set to 127.0.0.1, which is the local address (if you want to run the project on different computers over the network, set this property to a real IP address or hostname).

To run the project, create shortcuts by using the Project > Create Shortcut command (for Client1, use Reliance Control, for Server1, use Reliance Control Server).

BoilerRoom_MultipleServers is a project that adds a second server computer (Server2) to the BoilerRoom_ClientServer project. Server2 communicates to the BoilerRoom2 device. In this case, Server1 only communicates to the BoilerRoom1 device. This project demonstrates how to configure a client computer to access data from both servers at the same time. Each server provides the client with the data and alarms/events from a different device. The most important thing is creating two server connection groups for Client1 through the Project Structure Manager. Each group contains one server connection (Server1, Server2). To avoid displaying the top tray on the Server1 and Server2 computers, the TopTray window is disabled on the Display page (Disabled windows).

To run the project, create shortcuts by using the Project > Create Shortcut command (for Client1, use Reliance Control, for Server1 and Server2, use Reliance Control Server).

BoilerRoom_RedundantServers is a project that adds a second server computer (Server2) and a second client computer (Client2) to the BoilerRoom_ClientServer project. The computers are defined through the Project Structure Manager.

The Server1 and Server2 computers are redundant servers. Server2 is a secondary server to Server1 (primary server). The respective settings have been configured on the Redundancy page of Server2 (redundancy can be switched on/off through the Secondary server option). Only the server that has the active role provides (in this project) the following functions: simulation of tag data using scripts (analogy to communication with devices in a real project), historical data acquisition, alarm/event generation. Under normal circumstances (i.e., if both servers are running and connected with each other), the primary server has the active role. The secondary server has the standby role, i.e., it does not simulate data, all data (current and historical) and alarms/events are acquired from the primary server (it acts as a client towards the primary server). In the event of a primary server failure, the secondary server will assume the active role. Once the connection with the primary server is reestablished, the secondary server will again assume the standby role.

The Client2 computer has been created by duplicating Client1. A second server connection (pointing to Server2) has been added to the server connection group (named Servers) of the Client1 and Client2 computers. The connection priority is set so that Client1 is primarily connected to Server1 and Client2 is primarily connected to Server2. This setup provides load balancing. If one of the servers is not available (e.g., Server1 is terminated), its client automatically connects to the other server. If a client is not connected to its preferred server, the availability of the server with a higher priority is periodically tested. At runtime, you can view the connection status on the Network connections page in the System Information window.

ThinClientListFromScript is a project designed to demonstrate how to access the list of connected thin clients from a script. After the project is started in the runtime software, the main window contains a Display component with the number of connected thin clients (the ThinClients_Count tag) and a Data Grid component with detailed information about all connected thin clients. The Data Grid component is connected to array-type tags that are periodically updated in the GetThinClientList script. The script is started every 5 seconds and uses the RWS.GetThinClientList method to load the information about the thin clients to the ClientList array. Subsequently, this information is transferred to the array-type tags (ThinClients_xxxx) to be displayed by the Data Grid component.

ThinClientRequestHandlingFromScript is a project designed to demonstrate how to handle requests from thin clients (Reliance Web Client or Reliance Smart Client). In the Web section of the Project Options dialog box, there is the HandleThinClientRequest script set to be executed when a thin client request is received by a data server (Reliance Server or Reliance Control Server). The client's request information (request type, unique session identifier, client IP address, etc.) is obtained using the RScr.GetCurrentScriptDataEx function. This information is written to the corresponding tags in the System device. The values of these tags are shown in the Display components in the visualization window.

CustomReport_ADODatabase is a project designed to demonstrate how to use a custom report of type FastReport to visualize data from an SQL database in the form of a data grid. The project contains three virtual devices defined via the Device Manager. Each of these devices contains five tags (Tag1, ..., Tag5). Also, three SQL-type data tables are defined via the Data Table Manager. Each of this tables contains items corresponding to the tags in the virtual devices and has different settings of the Time stamp base property.  The SQL server is named (LOCAL)\SQLEXPRESS. It is a standard name set when Microsoft SQL Server 2005 Express Edition is installed with setup.bat.

Three custom reports designed to display data from the corresponding virtual devices are defined via the Custom Report Manager. The reports differ in the way the time stamp is decoded. Depending on the way a time stamp is logged, the Int64TimeToDateTime or UTCDateTimeToLocalDateTime conversion function is used. The ADODatabase and ADOTable components are used to make a link between a custom report and an SQL database. You have to set the database parameter of the ADODatabase component in the same way as the Connection string in the Project Options > Project > SQL dialog.

At runtime, you can set the tag values logged to the database and preview the reports via the corresponding buttons.

CustomReport_ADOChart is a project designed to demonstrate how to use a custom report of type FastReport to access an SQL database and to draw a trend based on this data. The TimeRange_From and TimeRange_Till tags (used to specify the time range) are defined via the Device Manager. A sample tag of type Word is also defined. The SQL-type data table defined via the Data Table Manager is used to log the values of the sample tag. The SQL server is named (LOCAL)\SQLEXPRESS. It is a standard name set when Microsoft SQL Server 2005 Express Edition is installed with setup.bat.

A custom report named TemperatureReport is defined through the Custom Report Manager. The ADODatabase component is used to make a link between the custom report and the SQL database. You have to set the database parameter of this component in the same way as the Connection string in the Project Options > Project > SQL dialog. The values from the data table are accessed via a dynamically generated SQL query (the query is generated in the FastReport script).

After the SQL connection is properly configured, you can start the project in the runtime software. Log some records in the database (the value of the word-type tag is logged to the data table every 6 seconds). Select the Time range and display the custom report via the Show Report button.

CustomReport_AVG is a project designed to demonstrate how to use a custom report of type FastReport to access an SQL database and to display a data grid containing hourly average values based on this data. A sample tag named ActFlow is defined via the Device Manager. The SQL-type data table defined via the Data Table Manager is used to log the values of the sample tag. The SQL server is named (LOCAL)\SQLEXPRESS. It is a standard name set when Microsoft SQL Server 2005 Express Edition is installed with setup.bat.

Two custom reports are defined through the Custom Report Manager. The CustomReport_RealData object is used to display all historical data. The CustomReport_AVG object is used to calculate and display the sample tag's hourly average values for the last 24 hours. The ADODatabase component is used to make a link between a custom report and the SQL database. You have to set the database parameter of the ADODatabase component in the same way as the Connection string in the Project Options > Project > SQL dialog. The values from the data table are accessed via a dynamically generated SQL query (the query is generated in the FastReport script).

At runtime, you can change the tag value logged to the database and preview the reports via the corresponding buttons.

CustomReport_dBASE is a project designed to demonstrate how to use a custom report of type FastReport to visualize data from a dBASE database in the form of a data grid. Within the System device, the DatabaseName tag of type String is defined via the Device Manager. It is an auxiliary tag that is used to store the dBASE data table's directory. A script named Init is defined via the Script Manager. The script is used for setting the dBASE data table's directory in the DatabaseName tag. The script is run after project startup. A custom report named Report is defined via the Custom Report Manager. It contains an item named DatabaseName linked to the same-named tag from the System device. The BDETable component is used to make a link between the custom report and the data table. BDETable's DatabaseName property can be set using the DatabaseName custom report item. The data table's file name is set in the TableName property.

At runtime, the custom report can be displayed by clicking on the Show Report button.

CustomReport_DynamicPicture is a project designed to show how to use a custom report of type FastReport to print a picture selected from the list. The available pictures are not stored in the custom report, but they are loaded dynamically from a file when generating the custom report. In the visualization window, there is a Combo Box component in which the pictures are specified. The picture files are located in the <Project>\Pictures folder.

Tags named PictureFileName, PictureName, and PictureDir are defined via the Device Manager. They are used to build up the picture file names. Two scripts are defined through the Script Manager. The Init script is used to set the picture file directory in the PictureDir tag. The PictureFileName script is used to build up the path to the selected picture's file.

The visualization window contains two Display components that display the values of the PictureDir and PictureFileName tags. The Combo Box component is used to select a picture from the list. The Picture component allows you to show the selected picture.

A custom report of type FastReport is defined via the Custom Report Manager. For this report, an item named PictureFileName is defined. This item is linked to the PictureFileName tag. In the report design work space, a picture object is inserted. A script is then used to load the selected picture to this object when generating the report.

CustomReport_EquithermalCurve is a project designed to demonstrate how to print an equithermal curve via a custom report of type FastReport. To define the equithermal curve, fourteen tags are defined via the Device Manager. A custom report of type FastReport named Report1 is defined through the Custom Report Manager – the items of this report correspond to the tags defined within the System device. You can edit the report template via the Edit Report command. The template file is located in the <Project>\Main\CustomReports folder. At runtime, you can change the tag values in the visualization window using the Equithermal Curve or Display components.

The following script is used to draw the trend in the FastReport template:

with ECChart do

begin

  SeriesData[0].XSource :=VarToStr(<TempA$6>)+';'+VarToStr(<TempB$7>);

  SeriesData[0].YSource :=VarToStr(<TempEkvA$10>)+';'+VarToStr(<TempEkvB$11>);

end;

CustomReport_Form is a project designed to show how to use a custom report of type FastReport to print a simple form. The main visualization window contains a form assembled of several Edit Box components. The components are linked to the corresponding tags defined within the System device. The CustomReport_CertificateOfPosting object is defined through the Custom Report Manager and contains items corresponding to the tags from the System device. At runtime, you are enabled to enter values to the form. To switch among the Edit Box components, use the Tab button. To preview and/or print the form, press the Display button. The project also demonstrates the use of multilanguage support. It is localized into Czech and English. If you switch the language of the project, the language is also changed in the text strings of the custom report.

CustomReport_HTML is a project designed to demonstrate how to use a Web page as a template for the custom report. The project contains several sets of tags organized to folders according to the technological unit (see the Device Manager). A Web custom report named WebReport is defined via the Custom Report Manager. The custom report contains items connected to the corresponding tags from the System device. The custom report template files are located in the <Project>\Main\CustomReports folder. This folder also contains a Microsoft Office Word document, which is a source for the custom report template. The visualization window contains several components forming a table. You can set the tag values via this table.

CustomReport_Text is a project designed to demonstrate how to use a text custom report. Within the System device, five tags that contain water level values in tanks are defined.The TextReport custom report is defined via the Custom Report Manager. The custom report contains five items linked to the corresponding tags from the System device. The file Template.txt (custom report template) is located in the <Project>\Main\CustomReports folder. At runtime, you can set the tag values and generate the text report based on the current values.

CustomReport_AlarmsEvents_File is a simple project designed to show how to use a custom report to display alarms/events stored in a file-based database. Within the System device, a main tag named Level and an auxiliary tag named RAEFileName are defined. The Level tag has its operating limits fixed. The RAEFileName tag is used for storing the path to the current file of the alarm/event database. There are also four alarms defined within the System device. The alarms are triggered when the main tag's operating limits are exceeded. A script named Init is defined via the Script Manager. The script is used for setting the file path in the RAEFileName tag. The script is run after project startup. A custom report named Report – basic is defined via the Custom Report Manager. It contains an item named RAEFileName linked to the same-named tag from the System device.

To retrieve data from the database, an object named RAETable is used in the FastReport Designer. Using a FastReport script, the RAETable object's FileName property is set to the value of the RAEFileName item. The appearance of the alarm/event table is specified through two bands. The top band named PageHeader specifies the column header and the bottom band named MasterData specifies the data to display. To display data in the bands, objects of type TfrxRAEMemoView are used (Alarm/Event Table Column Text object). To configure the displayed table, there are two important properties named RAEDataField and RAETitle in those objects. The RAEDataField property specifies the data field (column) of an alarm/event's record, the RAETitle property determines whether to display the data field's title instead of data. The RAETitle property is active in the PageHeader band.

At runtime, you can change the main tag's value in the visualization window.

CustomReport_AlarmsEvents_SQL is a simple project designed to show how to use a custom report to display alarms/events stored in an SQL database. Within the System device, a tag named Level is defined. This tag has its operating limits fixed. There are also four alarms defined within the System device. The alarms are triggered when the Level tag's operating limits are exceeded. A custom report named Report – basic is defined via the Custom Report Manager.

To retrieve data from the database, objects named ADODatabase1 and ADOQuery1 are used in the FastReport Designer. The connection to the SQL database defined in the ADODatabase1 object is automatically synchronized with the setting defined via Reliance's Project Options dialog box. The appearance of the alarm/event table is specified through two bands. The top band named PageHeader specifies the column header and the bottom band named MasterData specifies the data to display. To display data in the bands, objects of type TfrxRAEMemoView are used (Alarm/Event Table Column Text object). To configure the displayed table, there are two important properties named RAEDataField and RAETitle in those objects. The RAEDataField property specifies the data field (column) of an alarm/event's record, the RAETitle property determines whether to display the data field's title instead of data. The RAETitle property is active in the PageHeader band.

At runtime, you can change the Level tag's value in the visualization window.

AccessDLLFromScript is a project designed to show how to call functions exported by DLL (dynamic-link library) from a script. The VBScript language, which is used for writing scripts in Reliance projects, does not itself support calling DLL functions. This limitation can be worked around by using a utility called DynaCall, which can, at runtime, create an object-like wrapper around any DLL so that its functions could be called even from VBScript code.

DynaCall utility installation instructions:

1. Unpack the ZIP archive named DynaCall.zip (located in AccessDLLFromScript\Main\Apps) to any directory, e.g., c:\Program Files (the following directory will be created: c:\Program Files\DynaCall).

2. From the command prompt (cmd.exe), register the file c:\Program Files\DynaCall\dynwrap.dll by the following command: regsvr32.exe "c:\Program Files\DynaCall\dynwrap.dll".

Note: If the above command ends with an error, it is necessary to use the following steps:

3. Create a shortcut to cmd.exe.

4. From the context menu of the shortcut, choose the Run as Administrator command and confirm launching the program.

5. Repeat step 2.

The project contains a script named Example1_user32.dll_MessageBox, which makes it clear how to call DLL functions from scripts. The script demonstrates calling the MessageBoxA function from user32.dll (one of the fundamental DLLs of Windows) and can be run by clicking a button located in the main window of the project.

In the script, the below steps are used:

1. Create the DLLWrapper object by the following statement: Set DLLWrapper = CreateObject("DynamicWrapper").

2. Register the respective function by calling the Register method.

3. Call the function as a method of the DLLWrapper object, e.g., Result = DLLWrapper.MessageBoxA.

The steps taken to register the MessageBoxA function must be repeated for all other functions that are to be called.

Important:

1. The object variable DLLWrapper must be declared as local (inside a procedure) in the same way as in the example. If it were declared as global and the DLLWrapper object were not freed (by using Set DLLWrapper = Nothing) before ending the project, the runtime software would hang during ending the program.

2. The DynaCall utility is free of charge and its authors deny any responsibility for damage caused by possible malfunctions of the utility.

AutomaticUserLogOff is a project designed to demonstrate how to automatically log off the current user from the runtime software after a certain time of mouse and keyboard inactivity.

The LogoffUser script defined via the Script Manager is used to log off the current user by calling the RUser.LogoffUser method. In order for the script to be run after a certain time of inactivity, some parameters in the project's main file (the one with an .rp4 extension) must be altered. The project's main file is a text file that can be opened, for example, with the Notepad program (Notepad.exe). The parameters are stored in a section named [Section50] and have the following meaning:

Param0 – the inactivity time period (in milliseconds) after which the script specified by Param2 should be run

Param1 – determines whether to run the script specified by Param2 (0 – disabled, 1 – enabled)

Param2 – the ID of the script to be run

Note: The script ID is displayed in the bottom left corner of the Select Script dialog box.

Example:

[Section50]

Param0=20000

Param1=1

Param2=10

CustomRecipeEditor is a project designed to demonstrate how to use visualization windows and scripts to implement the features of the Recipe Editor, which is available at runtime. This should be done in cases where a customer requires to edit recipes through a form (not by editing values on the list of recipe items through the Recipe Editor).

A recipe type named Product01 is defined via the Recipe Manager. This recipe type contains 4 items named Param01, Param02, Param03, and Param04. Each item is connected to the corresponding same-named tag defined within the PLC1 device. When loading a stored recipe into the PLC1 device, the value of the respective item is written into these tags. To edit the recipe through visualization windows, one auxiliary tag must be defined for each recipe item (this auxiliary tag is of the same type as the corresponding tag in PLC1). The auxiliary tags are called editing tags. They are defined within the System device with the same names as the tags in PLC1. Each recipe item is connected to the corresponding editing tag. Also, each editing tag is connected to the corresponding Display component located in the EditRecipe_Product01 window. The Display components allow you to edit the values of the recipe items. To show the EditRecipe_Product01 window, click on the Edit Recipe button in the main visualization window (Product01). The EditRecipe_Product01 window can be used to choose a recipe from the list of already stored recipes, edit it, and save it under the specified name. The Product01 window can also be used to load or delete the selected recipe by clicking on the respective buttons.

DeclareArrayVar is a project showing how to define and use global and local array variables. The main visualization window contains two buttons that start the UseGlobalArrayVar and UseLocalArrayVar scripts.

An event script named Define used to declare the global variable GlobalArrayVar1 is defined via the Script Manager. This script is executed only once and prior to all other scripts, because the Run on thread initialization property on the Advanced page is enabled. The script is also executed upon a possible forcible termination of the thread. Each global array variable has to be declared only once to avoid the Type mismatch error.

The UseGlobalArrayVar script writes data to the global variable GlobalArrayVar1, whereas the UseLocalArrayVar script modifies only a local variable named LocalArrayVar declared inside the DoSomethingWithLocalArrayVar procedure.

DownloadAndSaveFile is a project designed to show how to download and save a file defined by a URL to a local computer. The project's main functionality is done in the DoDownloadAndSaveFile script. This script downloads the file based on the string values of the FileURL and FileName tags. The FileURL tag is linked to the corresponding Display component in the visualization window and defines the source file name and address (the URL has to be entered with the leading http://). The FileName tag is linked to the second Display component and defines the target file. To execute the script, press the Download File button.

The CreateObject command is used to create an instance of the MSXML2.XMLHTTP object. The open and send methods of this object are used to make the connection. The file is saved to the disk via the methods of the "ADODB.Stream" object.

ExtractBits is a project designed to demonstrate how to use scripts to extract bits from an integer tag and store the bit values in tags of type Bool.

Within the System device, the following tags are defined via the Device Manager: Status01 and Status02 of type Byte, Bits_Status01 and Bits_Status02 of type StatusBits, which is a data structure (defined via the Data Structure Manager). The Bits_Status01 (or Bits_Status02) tag is a structured tag that contains several nested tags of type Bool to which a script will write the value of the respective bits of the Status01 (or Status02) tag.

The Define script, which contains the definition of the ExtractBits procedure, is defined via the Script Manager. On the Advanced page of the script's Properties pane, the Run on thread initialization option is active to execute the script prior to any other script supposed to run in the same thread of execution. The ExtractBits procedure is called from the StatusChanged procedure that is called from the same-named script. The StatusChanged script executes every time the value or quality (validity) of the Status01 tag (or Status02) changes. This is ensured by linking the Status01 and Status02 tags to this script on the Device Manager's Scripts page. The quality (validity) is always changed upon project startup.

The following parameters are passed to the ExtractBits procedure:

The name of the device in which the source tag is defined: System

The name of the source tag: Status01 (or Status02)

The name of the device in which the target tag is defined: System

The name of the target tag (including the character used to separate the structured tag and its nested tags): StatusBits01/ (or StatusBits02/)

The array containing the numbers of bits to extract: BitNumbers_StatusBits = Array(0, 1, 4, 5)

The array containing the names of the fields of the StatusBits data structure (in the same order as bit numbers in the BitNumbers_StatusBits array): BitTagNames_StatusBits = Array("ManualMode", "EmergencyMode", "CheckDevice", "Error")

To display the data of the structured tags of type StatusBits, the same-named window template is used (see the Window Manager). This template contains Display components linked to particular fields of the StatusBits data structure. The template is embedded into the window named MainWindow through a Container component. The window also contains a Display component that is used to display the value of the Status01 (or Status02) tag and enables you to change it.

The solution described above has proven to be very convenient. There may be many tags like Status01 each of which contains status information on a machine used in the industrial process being visualized. It is very easy to add a new status tag. Simply duplicate the Status02 and Bits_Status02 tags. There is no need to modify the existing scripts and add new scripts.

GetCurrentScriptDataEx is a project designed to show how to pass a parameter from the Reliance SCADA/HMI system to a script and how to access it inside the script. A tag of type LongInt named ScriptParamValue is defined via the Device Manager. It is linked to the Display component. A script named EventScript defined through the Script Manager is linked to the three buttons located in the visualization window. If you click a button, the number associated with the button is passed to the script, accessed inside the script, stored in the ScriptParamValue tag, and shown in the Display component located below.

GetFolderContents is a project designed to demonstrate how to list the contents of a directory. The main visualization window contains a Display component (enter the name of the directory you want to list), a Button component (which starts the GetFolderContents script), and two Data Grid components. After the script is finished, the left data grid displays the list of subdirectories and the right one shows the file list.

The GetFolderContents script defined via the Script Manager uses an object named "Scripting.FileSystemObject" to get the directory listing. The SubFolderNames and FileNames array tags are populated with the names of subfolders and files in this script. The SubFolderCount and FileCount tags hold the length of the corresponding lists.

CheckHDSerialNumber is an example project designed to demonstrate how to easily protect a project from being launched on an unauthorized computer. After the protection is activated, the project is bound to the hard disk serial number and cannot be run on another computer. Two tags named HDSerialNumber and CheckEnabled are defined through the Device Manager. The first one contains the serial number, the other one is used to activate/deactivate the protection.

Three scripts are defined through the Script Manager. The UpdateHDSerialNumber script is intended for updating the disk serial number in the HDSerialNumber tag. The ExitRuntimeModule script is used to terminate the project. The ProjectRun script is used to compare the current disk serial number to the value of the HDSerialNumber tag. If the numbers do not match, the Dlg_ProjectCannotRun dialog window is displayed. After the dialog is confirmed by clicking the OK button, the project is terminated.

All instructions listed below are also shown in the visualization window.

Disk check activation instructions:

1. Start the runtime software.

2. Save the current hard disk serial number to the HDSerialNumber tag (click on the Save HD serial number button).

3. Terminate the runtime software.

4. Bring up the Device Manager. On the Advanced page of the CheckEnabled tag's properties, activate the Save last value option.

5. Start the runtime software.

6. Start checking the hard disk serial number (click on the Check serial number check box).

7. Terminate the runtime software.

Disk check testing instructions:

1. Start the runtime software.

2. Change the saved value of the HDSerialNumber tag (using the Display component).

3. Terminate the runtime software.

4. Start the runtime software.

Disk check cancel instructions:

1. Bring up the Device Manager. On the Advanced page of the CheckEnabled tag's properties, deactivate the Save last value option.

LogMessage is a project designed to demonstrate how to log a text string to a file from a script. The button located in the main visualization window is used to start the LogMessageTest script that contains the LogMessage procedure. This procedure is defined within the Define script (also the functions for custom date and time formatting are defined within this script). Access to the file is done via an object named "Scripting.FileSystemObject" (the OpenTextFile method of this object is used). If this method is called with the filename as a parameter, a new object is created (the numerical parameter defines the opening method, 1 – read only, 2 – write, 8 – append, and the logical parameter defines whether the file should be created if it doesn't exist). Now, you can call the WriteLine method of this object and write an arbitrary text string to the file.

If the button located in the main visualization window is pressed at runtime, a new directory named Logs is created in the <Project> directory. The ScriptLog.txt file is created in this directory. The file contains lines with a current date, time, and example text string.

MoveTagElementValues is a project designed to demonstrate how to use an event script (started via a button in the visualization window) to copy the first 10 elements from the WordArray20 array to the positions 50–59 in the WordArray100 array. The RTag.MoveTagElementValues method is used to copy the values of the array-type tags.

MoveTagValue is a project designed to demonstrate how to copy a tag value between two devices. The project contains the AfterStartProject script that is run after project startup (Project Options > Scripts > Other > After run project). This script initializes the DateTime1 tag. In addition, there are several scripts defined in the project used to copy tags from the System device to the Virtual1 device. They are event scripts linked to the buttons in the main visualization window; the window contains Display components that display the values of source and target tags. To copy the tags of a different type, the RTag.MoveTagValue method is used.

ScriptDebugging is an example project that requires a debugging tool installed on your computer. You can use the Microsoft Script Debugger application (it is part of the Reliance Add-On Pack installer). The visualization window contains two buttons that enable/disable the script debugging function. This is done in the Windows Registry via actions that execute the ScriptDebuggerEnabled.reg and ScriptDebuggerDisabled.reg files. The runtime program has to be restarted before the change takes place. Since Reliance 4.1.3, you can also enable/disable the script debugging function via the Environment Options dialog box in the development environment. If the debugging is enabled and the Run Script button is pressed, the debugging tool is opened.

ScriptTypes is a project designed to demonstrate how to use different script types. The main visualization window contains five panes, each demonstrating features of one script type. The first pane introduces the Periodic script – the angle value is periodically incremented. The second pane introduces the Data change script – if you change the value of A, B, or C, the result is automatically recalculated. The third pane introduces the features of the Key script – if you press the F5 button, a dialog window is shown (all scripts run in the same thread and, therefore, other scripts are paused if the dialog is shown).

The fourth pane introduces the Condition script – if you enter a number greater than 10 into the Display component, a dialog window is shown. The last pane introduces the Event script – the buttons are linked to the digital tags. An alarm/event is defined and starts if the tag value changes from logical 0 to logical 1. The Alarm script is linked to the event of alarm/event start. The script reads the text of this alarm and shows it in a dialog window.

SendEmail is a project designed to demonstrate how to send an email message from a script. Before any email can be sent, you have to set the information about the SMTP server. This can be done via the Project Structure Manager on each project computer's E-mail page. The main visualization window of the project contains Display components where the email's recipient, subject, attachments, and body can be specified. The Send Email button is used to activate the script that sends the email. The core part of the script is the RInet.SendMail method.

Stopwatch is a project designed to demonstrate how to measure the amount of time elapsed from a particular time (similarly as done by a stopwatch). The main visualization window contains two buttons named Start Measuring Time and Stop Measuring Time. After clicking on the Start Measuring Time button, the amount of elapsed time begins to be displayed by the Display components. It is displayed in two ways:

1. As a single piece of data in milliseconds.

2. In hours, minutes, and seconds.

To measure the amount of elapsed time, a periodic script named MeasureTime is used. By default, this script is disabled (the Enable execution property is inactive). Upon clicking on the Start Measuring Time button, the StartMeasuringTime script gets executed. This script enables the MeasureTime script to get executed periodically at the specified Repeat interval. Upon clicking on the Stop Measuring Time button, the StopMeasuringTime script gets executed. This script disables the MeasureTime script.