OVERVIEW

Starting in the 2023 version of Historian Server, users have the ability to apply mathematical and logistical operations to tag data. This is accomplished by using the wwExpression retrieval option. The wwExpression option can be used with the following Retrieval Modes:

• Cyclic Retrieval
• Delta Retrieval
• Full Retrieval
• Best Fit Retrieval

NOTE: Using the wwExpression retrieval option requires an “Advanced” Historian Server license. If an Advanced license is not available, the query will result in a error and no results will be returned.

APPLIES TO

• Historian Server 2023 and later

EXPLANATION

An Expression is made up of the following components:

VALUES
Comprised of a base value (of Boolean, Integer, Double or String data tyles), a date and time in UTC format, and a 16-bit integer representing the OPC quality of the value.

STREAMS
A time-ordered collection of values. In the context of an expression, a stream is represented by the Historian tag name. For example: Level_001.PV represents a stream consisting of the stored historical values for the Level_001.PV tag. Level_001.PV + 10 is an expression that adds 10 to the values in the Level_001.PV stream. Streams have either a star-step or linear interpolation model and an associated engineering unit.

ARITHMETIC AND LOGICAL OPERATORS
Standard mathematical operators and logic operators for comparisons.

SCALAR FUNCTIONS
A variety of functions for manipulating data, such as rounding values or converting engineering units.

TIME-SERIES FUNCTIONS
A variety of time series functions for comparing data such as calculating minimum/maximum values or time in state.

ARITHMETIC OPERATORS

AVEVA Historian Server supports the use of standard mathematical functions in expressions:

+	Addition
–	Subtraction
*	Multiplication
/	Division
^	Exponentiation
%	Modulo
()	Grouping operations

DimensionMath Table

The DimensionMath database table defines the relationship between engineering unit dimensions (i.e. volume, speed, temperature) when they are multiplied or divided by each other. For example, dividing gallons (gal) by minutes (min) provides results in gallons per minute (gal/m).

When adding or subtracting streams with the same dimension, the engineering units are converted to the same as the first stream, then operations are performed.

When multiplying or dividing streams where both units are related by a dimension relationship in the DimensionMath table, the results are in the associated Result Dimension’s units.

If a dimension relationship is not defined, the results cannot be implicitly converted and the results are in “Unknown” units.

LOGICAL OPERATORS

AVEVA Historian Server supports the use of standard logical operators in expressions:

=	Equal to
>	Greater than
>=	Greater than or equal to
<	Less than
<=	Less than or equal to
<>	Not equal to

AVEVA Historian Server also supports the use of the following logical functions in expressions:

AND (arguments)	TRUE if all arguments evaluate to True, otherwise FALSE
OR (arguments)	TRUE if any arguments evaluate to True, otherwise FALSE
NOT (arguments)	Evaluates the arguments to a TRUE or FALSE value, then returns the opposite

SCALAR FUNCTIONS

AVEVA Historian Server also supports using scalar functions in expressions. These functions have a 1:1 relationship between values in the input and output streams.

ABS	Calculates the absolute value of a stream
CASTUOM	Changes the stream’s unit of measure without changing the values
IF	Produces a stream based on the results of a logical expression
IFBAD	Overrides “bad” quality values in a stream
LOG	Calculates the base 10 logarithm of a stream’s values
ROUND	Rounds a stream’s values to the nearest integer
SIGN	Replaces a stream’s value with 1 or -1 based on the current value’s sign
SQRT	Calculates the square root of a stream’s values
TIMESHIFT	Shifts the time stamps of a stream by a specified interval
TRUNCATE	Removes the fractional portion of a stream’s values
UOM	Converts the stream’s values to a specific unit of measure

TIME-SERIES FUNCTIONS

AVEVA Historian Server allows you to use the following time-series functions in expressions to compare and manipulate data:

AVERAGE	Calculates the time-weighted average for a stream
AVERAGES	Calculates the statistical average for a stream
DURATION	Calculates the duration of TRUE states in an expression
MIN/MAX	Selects the minimum/maximum value of a stream
PREV/PREVGOOD	Returns the last value from the previous time period
TOTAL	Calculates the time-weighted total for a stream
TOTALS	Calculates the statistical total for a stream

For more information on the proper syntax and arguments for any of the above functions, please refer to the AVEVA Historian Retrieval Guide.

QUERY EXAMPLES

In this section we will look at a few examples of using the wwExpression option in SQL Queries.

Example 1: Adding the values of two tags. In this example we will add the values of two temperature tags together for the past 10 minutes.

SELECT DateTime, Value, QualityDetail
FROM History
WHERE wwExpression = 'Temperature_001.PV + Tempeature_002.PV'
AND DateTime >= Dateadd(mi, -10, GetDate())
AND DateTime < GetDate()

Example 2: Using the ROUND function. In the next example, we will apply the ROUND() scalar function to round the results of the previous query to the nearest integer.

SELECT DateTime, Value, QualityDetail
FROM History
WHERE wwExpression = 'ROUND(Temperature_001.PV + Tempeature_002.PV)'
AND DateTime >= Dateadd(mi, -10, GetDate())
AND DateTime < GetDate()

Example 3: Using the DURATION function. This query will return the amount of time (in seconds) per hour that the tank’s level was above 80 litres.

SELECT DateTime, Value, QualityDetail, wwUnit
FROM History
WHERE wwExpression = 'DURATION( Mixer100.Level.PV > 80, hour )'
AND DateTime >= Dateadd(hh, -4, GetDate())
AND DateTime < GetDate()

Example 4: Converting Unit of Measure. We will take the results of the previous query and convert the results from seconds to minutes.

SELECT DateTime, Value, QualityDetail, wwUnit
FROM History
WHERE wwExpression = UOM( 'DURATION( Mixer100.Level.PV > 80, hour ), Minute )'
AND DateTime >= Dateadd(hh, -4, GetDate())
AND DateTime < GetDate()

Example 5: Using the IF statement. This query will return the value of the temperature tag if the pump is running, otherwise it will return a value of zero.

SELECT DateTime, Value, QualityDetail
FROM History
WHERE wwExpression = 'IF( Pump1_001.PV = 1, Temperature_001.PV, 0 )'
AND DateTime >= Dateadd(mi, -10, GetDate())
AND DateTime < GetDate()

Example 6: Using the AVERAGE function. This query will calculate the time-weighted average temperature each hour.

SELECT DateTime, Value, QualityDetail
FROM History
WHERE wwExpression = 'AVERAGE(Temperature_001.PV , 1 hour)'
AND DateTime >= Dateadd(hh, -8, GetDate())
AND DateTime < GetDate()

For more examples, please refer to the AVEVA Historian Retrieval Guide.

The post Retrieving Historical Data Using wwExpression appeared first on Industrial Software Solutions.

OVERVIEW

An Object Wizard can be added to any derived template to provide a simplified user interface for configuring instances (assets) derived from the template. When configuring an instance derived from a template with Object Wizards, it may have a series of user selectable Choices and Options that guide you through the process of the configuration. Each Choice and Option may have one or more attributes, symbols, and/or scripts associated with it.

Object Wizards can integrate a wide variety of configuration possibilities, which can reduce many levels of the template derivation hierarchy. The result is fewer templates to manage and a simpler process to create and configure instances.

APPLIES TO:

• AVEVA Application Server 2017 and later

EXPLANATION

There are different ways of modeling templates, including building super objects with all possible attributes, symbols, and scripts within one template, using multiple derivations to add necessary attributes, symbols, and scripts to each level of derived template, and creating Object Wizards.

The following tables compare building super objects and multiple derivations to using Object Wizards. As examples, the comparisons are based on building templates with attributes only.

Building Super Objects	Using Object Wizards
Add all possible attributes to templates	Add all possible attributes to templates
All derived objects have all attributes	Derived objects only include necessary attributes as determined by Object Wizard configuration
All attributes deployed to runtime	Only necessary attributes deployed to runtime

 

Using Multiple Derivations	Using Object Wizards
Add common attributes to first-level template	Add all possible attributes to templates
Add attributes and features to each derived object to meet requirements	Attributes and features are determined by the Object Wizard configuration for each derived object
More levels of derivation, harder to maintain	Reduced levels of derivation, easier to maintain

Wizard Options

The Object Wizard presents a series of prompts and questions, from which you can select answers to build an instance as needed. For example, you might be building an instance that represents a piece of field equipment, such as a pump, motor, or valve. You can configure the instance by selecting an answer for each prompt or question listed in the Wizard Options panes.

An Object Wizard can have Choice Groups and Options. A Choice Group is presented with a drop- down list of two or more responses (Choices), from which you can select a response. An Option is presented as a check box that can be checked (true or on) or unchecked (false or off).

Along with configuring each available Wizard Option by selecting a Choice of a Choice Group or checking the check box of an Option, the associated attributes, symbols, and/or scripts can be set to be available or not for the instance.

Additionally, based on the configured Wizard Options, the settings of an attribute or a symbol might be configured as well. For example, checking an Option might enable the History feature for the associated attribute or the value of a custom property might be set to a new value.

IMPLEMENTATION

For our example, we will add Object Wizard options to a pre-built Counter object which already has all the attributes, scripts and symbols for three different counter variations built into it.

You can download a copy of the aaPKG file and import it into your galaxy from here ($Counter.zip).

Add and Configure a Choice Group

1. Launch the IDE.  In the Template Toolbox \ Training \ Project toolset, double-click the $Counter template to open its configuration editor.NOTE: If the Choices and Options and Settings panes are not visible, click the Configure Wizard Options button located above the Attributes pane.

2. In the Attributes tab, Choices and Options pane, click Add ChoiceGroup.
   
   A Choice Group with two Choices is added in the Choices and Options pane. By default, the Choice Group Prompt is Group #1 and the Choices are Choice #1 and Choice #2. You will add another Choice in the next step.Notice that the Prompt, Description, and Visibility fields appear at the bottom of the Choices and Options pane. These fields can be used to configure the Choice Group, Choices, and Options.
   

3. In the Choices and Options pane, click the Add Choice button to add another Choice for the Choice Group.
   
   A new Choice named Choice #3 is added to Group #1.
   

4. In the Choices and Options pane, select Group #1.
   

5. In Prompt, enter the prompt for the group as Counter Type and press Enter.
   The Group #1 prompt changes to Counter Type.

6. In Description, enter Select the type of counter and press Enter.Descriptions are used as tooltips for the settings.
   

7. Repeat steps 5 & 6 to configure prompts and descriptions for the Choices:
   

   Default Prompt	New Prompt	Description
   Choice #1	Scan	Counter is triggered every scan
   Choice #2	Trigger	Counter is triggered when the Trigger attribute is set to True
   Choice #3	Input	Counter is triggered when the data changes in the Value attribute

Associate Attributes, Scripts, and Symbols to Choices

Now you will associate attributes, scripts, and symbols to the Scan, Trigger, and Input Choices.

8. In the Choices and Options pane, select the Scan Choice.

9. If the Scripts pane is not visible, you will need to show Click the Show Scripts button just above the Attributes pane.
   
   The Scripts pane appears below the Symbols pane. If needed, resize the Scripts pane to see the scripts.

10. In the Scripts pane, select the CountByScan script and drag it into the AssociationsNote: For the Scan type, the counter is triggered by the AppEngine’s scan period.  It is not triggered by a specific attribute, so no attributes need to be associated with this choice.

11. In the Symbols pane, select CounterDisplay and drag it to the Associations

12. In Associations, ensure CounterDisplay is selected.

13. In Settings, from the drop-down list for CounterType, select Scan.
    By associating the symbol to the Choice, it is possible to override the default settings of the symbol’s properties when that choice is selected.Notice that the visibility of the CounterType setting is automatically set to hidden, as reflected in the Visible icon for the setting. When an instance is set to count by scan, the symbol will be set to Scan automatically and will not be changeable when it is embedded in another symbol, because the setting has been set to hidden.

14. In the Choice and Options, select the Trigger Choice.

15. In Attributes, select the Trigger attribute and drag it to the Associations pane.

16. In the Scripts pane, select CountByTrigger and drag to the Associations pane.

17. In the Symbols pane, select CounterDisplay and drag it to the Associations pane.
    

18. In Associations, make sure CounterDisplay is selected.

19. In Settings, set CounterType to Trigger.
    

20. In Choices and Options, select the Input Choice.

21. In Attributes, select the Value attribute and drag it to the Associations pane.

22. In Scripts, select CountByInput and drag it to the Associations pane.

23. In Symbols, select CounterDisplay and drag it to the Associations pane.

24. In Associations, make sure CounterDisplay is selected.

25. In Settings, set CounterType to Input.
    

Add and Configure an Option

Now you will add an Option to show a reset button for the counter.

26. In Choices and Options, click the Add Option button.
    
    An option named Option #1 is added.
    

27. With Option #1 selected, configure the option as follows:
    

    Prompt:	Has Reset Command
    Description:	Check to include a reset control for the counter

28. In Attributes, select ResetCmd and drag it to Associations.

29. In Scripts, select ResetCounts and drag it to Associations.

30. In Symbols, select CounterDisplay and rag it to Associations.

31. With CounterDisplay selected, in Settings set ShowReset to True.
    

Test the Configuration

Finally, you will test what you have built.

32. In Choice and Options, click the Test button.
    
    The display changes to testing mode.
    

33. In Choices and Options, select a different Counter Type and check and uncheck Has Reset Command to see the behaviors.For example, if you check Has Reset Command, you can see the ResetCmd attribute in Attributes list, a Reset button appears on the CounterDisplay symbol in the Symbols pane, and a ResetCounts script in the list of scripts.

34. Click the Test button again to exit testing mode.

The post Introduction to Object Wizards appeared first on Industrial Software Solutions.

This document provides a high-level overview of remote clients and their configuration using Mobile Access. It covers the prerequisites to run remote clients and how to deploy an HTML5-enhanced web interface for smartphones and tablets. Additionally, it outlines the key controls available in the Mobile Access web interface, such as Alarm, Process Values, Trend, and Screens.

NOTE: Internet Explorer is not a supported browser.

APPLIES TO

• AVEVA Edge HMI

EXPLANATION

Mobile Access allows you to remotely view AVEVA Edge runtime on a mobile device or in any HTML5 web browser. The configuration process involves setting up the Mobile Access web interface, which facilitates remote access using HTML5-enhanced web pages designed for smartphones and tablets.

To get started with Mobile Access, you must have the Mobile Access Runtime software installed on the runtime server, in addition to ensuring you have network connectivity and proper security measures. Once these requirements are in place, users can proceed to configure the Mobile Access web interface.

Mobile Access Web Interface

• Alarm Control: This control resembles the Alarm/Event Control screen object. It displays active alarms and allows users to acknowledge alarms.
• Process Values Control: Similar to the Symbols library, the Process Values control utilizes premade widgets like gauges and switches to visually represent project tag values. Users can interact with these widgets to change values during runtime, based on how they’re configured.
• Trend Control: This control operates similarly to the Trend Control screen object. It graphs process value changes over specified time durations. The control also maintains a history of these changes.
• Screens Control: The Screens Control allows users to access selected project screens from the web interface. Screens typically function the same as screens published in other remote clients, but limitations exist.

These controls are presented as green tiles within the Mobile Access web interface. When users click or tap on a tile, they are directed to a new page that provides access to the corresponding control.

IMPLEMENTATION

1. First, publish the screens as HTML to support mobile access. In AVEVA Edge Studio, close any opens screens. Then go to File -> Save All As HTML

2. A message appears asking you to enable the TCP/IP server if not already enabled. Click Yes.

3. If security is not enabled, a warning message appears. Click OK.

4. On the Project tab -> Web group -> Mobile Access. The Mobile Access Configuration screen appears.

5. At the bottom right, click Area Settings.

6. In the Trend and Process Values group, add a tag and choose a widget to be used in the Process Values control. This will display that tag during runtime in the chosen widget. You can access this at runtime by clicking the Process Values Mobile Access tile.

7. In the Screens group, choose a screen and define a label for it to be shown in the Screens control. This control presents project screens that you have selected to include in the web interface. You can access this at runtime by clicking the Screens Mobile Access tile.

8. To test it out, run any HTML5-compatible browser and enter http://<host-name-or-IP-address>/AVEVAEdge2020/?screen=<group-folder.sg-or-screen>

host-name-or-IP-address: name or IP address of the AVEVA Edge server

group-folder.sg-or-screen: the designated startup group or screen

8. The Logon window appears. Once logged-in, observe the Mobile Access interface.

The post Configuring Mobile Access in AVEVA Edge appeared first on Industrial Software Solutions.

Communication Drivers in AVEVA Edge allow you to configure the HMI to communicate with various external devices, such as PLCs and transmitters. AVEVA Edge comes with pre-installed drivers for a wide range of common and uncommon devices. This training document will explain what communication drivers are and how to configure them in Edge Studio, as well as how to configure the Driver sheet(s) associated with the driver(s) to define I/O tags.

This document will provide implementation steps for:

• Adding the Communication Driver
• Configure the Main Driver Worksheet

This document assumes understanding of creating tags in AVEVA Edge Studio.

APPLIES TO

• AVEVA Edge

EXPLANATION

In order to implement I/O Connectivity, you first add a Communication Driver, and then configure the Driver sheet(s).

Adding a Driver

To configure a communication driver, users must specify the necessary interface parameters and equipment addresses, linking them to project tags. There are two methods to add or remove a driver:

1. Through the Insert tab on the ribbon, in the Communication group, by clicking Add/Remove Driver.
2. By right-clicking the Drivers folder in the Project Explorer and selecting Add/Remove drivers.

Configuring Drivers

Users can configure communication drivers using two interfaces provided by AVEVA Edge:

1. Main Driver Sheet: This interface offers a simple way to set up communication between project tags and device addresses. It automatically groups tags for optimal runtime performance but does not allow individual control over scanning time.
2. Standard Driver Sheets: These sheets provide additional fields to control communication, allowing users to manage the scanning time of individual tags.

Main Driver Sheet

The Main Driver Sheet is automatically inserted into the driver folder when adding a driver to the project. It consists of two areas:

• Header area (top section): Contains parameters affecting all tags configured in the Body area.

• Body area (bottom section): Used to define the relationship between project tags and their corresponding field equipment addresses.

The Header area parameters allow users to add descriptions, enable/disable communication, and monitor read/write commands. The Body area parameters include project tag names, equipment station numbers, field equipment addresses, communication directions, and scan conditions.

Standard Driver Sheets

Users can create multiple Standard Driver Sheets for each driver. These sheets provide more granular control over communication triggers and commands. The number of rows in a Standard Driver Sheet is limited, with the maximum block size supported by the driver protocol affecting the practical limit.

It consists of two areas:

• Header area (top section): Contains parameters that affect all the tags configured in the Body area of this worksheet

• Body area (bottom section): Used to define the relationship between tags in the project and their field equipment address

IMPLEMENTATION

Adding the Communication Driver

For the purposes of this training document, we will be using the Modbus driver, MOTCP.

1. Open AVEVA Edge Studio and close any open windows. Then, go to the ribbon’s Insert tab and find the “Communication” group. Click on Add/Remove Driver.

2. The Communication Drivers dialog box will appear.

3. Scroll through the list of Available drivers and select the MOTCP driver. Click on Select. The MOTCP driver will be added to the Selected drivers list.

5. Click OK to close the Communication Drivers dialog box.

Configure the Main Driver Worksheet

1. In the Project Explorer, go to the Global tab, expand the Project Tags folder, and right-click Datasheet View. Then, select Open to access the Project Tags worksheet.

2. First we will create some tags that we’ll use in our Read/Write Completed/Status fields for triggering and reading the Driver Sheet. Create the following tags in the Project Tags worksheet:

3. Close the Project Tags worksheet. In the Project Explorer, go to the Comm tab -> Drivers folder, ->  MOTCP folder. Right-click MAIN DRIVER SHEET and click Open to access the MOTCP – MAIN DRIVER SHEET worksheet.

4. In the Read Completed field, enter “bReadComplete,” and in the Read Status field, enter “iReadStatus.” Then, in the Write Completed field, enter “bWriteComplete,” and in the Write Status field, enter “iWriteStatus.”

5. You would then create any I/O tags by adding them to the rest of the driver worksheet. You can refer to the Main Driver Sheet section for more information on the specific fields.

The post Configuring I/O Connectivity in AVEVA Edge appeared first on Industrial Software Solutions.

AVEVA Historians uses two potential authentication modes: Windows OS security and Microsoft SQL Server security.

SQL Server authentication is provided for backward compatibility – Windows authentication is recommended for improved security.

Since Historian uses a relational database, Runtime,  the Historian requires passing through both Windows and SQL Server security levels. The Historian Management Console within the System Platform Management Console adds an extra security layer, restricting access to only  authorized users for the starting/stopping of Historian processes. Some historian components also require Windows and SQL Server logins.

Security for AVEVA Historian is managed using these tools:

• Microsoft SQL Server Management Studio: Manage access to SQL Server and databases.
• Windows Local Users & Groups: Manage permissions for the Historian. It can be an alternative to configuring database permissions with Windows authentication.
• Change Network Account utility: Modify the Windows login for the historian services.

To access AVEVA Historian as a client, users must log on to the Windows operating system using a valid user account with a login ID and password. This Windows user account also grants access to network resources in the domain.

In this training document, we will cover essential aspects of managing Historian users and security in SQL Server Management Studio. We will also include some steps on common actions performed in SQL Server Management Studio:

• Verifying your Authentication Mode in SQL Server
• Viewing a Login
• Adding a Login

NOTE: SQL Server Management Studio is not installed by default with System Platform in later versions. The program can be downloaded from Microsoft.

In addition, you must be logged in as a SQL System Administrator (sysadmin) in order to perform modifications in SQL Server Management Studio. Should you encounter a scenario where no user is a sysadmin, please follow the guidelines from Microsoft on Connecting to SQL Server When System Administrators are Logged Out.

APPLIES TO

• AVEVA Historian Server

EXPLANATION

SQL Server Authentication Modes

Microsoft SQL Server authenticates users using individual login account and password combinations. After successful authentication, users can connect to a SQL Server instance. There are two types of authentication:

• Windows authentication
  • Users connect to the SQL Server using a Windows user account (Windows login ID and password provided during the Windows login session).
• SQL Server authentication
  • Users connect to the SQL Server using a SQL Server login account (SQL Server login ID and password).

SQL Server operates in either of two security modes, controlling the type of accounts used for server access:

• Windows authentication mode
  • SQL Server uses only Windows authentication.
• Mixed mode
  • SQL Server uses both Windows authentication and SQL Server authentication. Windows security mechanisms handle validation if the login name matches the Windows network username. If not, Microsoft SQL Server security mechanisms are used.

NOTE: SQL Server authentication is provided for backward compatibility. Microsoft recommends using Windows authentication whenever possible. For more information about authentication, refer to your Microsoft SQL Server documentation.

Windows Security Groups and SQL Server Roles

The following Windows security groups are created by default on the AVEVA Historian computer. Use these groups to assign different levels of database permissions to users. This user management is done through Local Users and Groups.

• aaAdministrators
• aaPowerUsers
• aaUsers
• aaReplicationUsers

Each group is automatically configured to be a member of the SQL Server database role with the same name. For example, the aaAdministrators Windows security group is a member of the default aaAdministrators SQL Server database role. If you add Windows users to the aaAdministrators security group, they will automatically be given permissions of the aaAdministrators SQL Server database role.

SQL Server Roles and Permissions

The following table describes the SQL Server database roles and what permissions they have in the Runtime DB.

IMPLEMENTATION

The following section explains how to do a number of key actions in SQL Server Management Studio.

Verifying your Authentication Mode in SQL Server

1. Go to Windows Start -> Microsoft SQL Server Tool # -> Microsoft SQL Server Management Studio.

2. Connect to your Historian Server name. In the Object Explorer console tree, locate and right-click on your SQL Server instance -> Properties.

3. Click on the Security tab in the Properties dialog box.

4. Verify the authentication mode displayed.

If it shows “SQL Server and Windows,” it means mixed mode authentication is enabled. If you want to change the authentication mode, remember to stop and restart the SQL Server after making the change. Also, note that modification tracking in the historian, if enabled, will not occur until you restart the historian.

The AVEVA Historian services log on to SQL Server using the ArchestrA user account, which is a Windows account. This comes from the Change Network Account utility.

5. Click “OK” to apply any changes and close the SQL Server Properties dialog box.

Viewing a Login

NOTE: For information on connecting to SQL Server Management Studio, please see steps 1 and 2 from the Verifying your Authentication Mode in SQL Server section

1. In SQL Server Management Studio, in Object Explorer, expand SQL Server instance associated with the AVEVA Historian.

2. Expand Security and then click the “+” by Logins to expand the folder. The default logins appear in the details pane.

3. Double-click the login (user or group) for which you want to see the properties. The SQL Server Login Properties dialog box appears.

4. Here you can access their server roles, database membership mapping, status, etc.

Adding a Login

NOTE: For information on connecting to SQL Server Management Studio, please see steps 1 and 2 from the Verifying your Authentication Mode in SQL Server section

1. In SQL Server Management Studio, in Object Explorer, expand SQL Server instance associated with the AVEVA Historian.

2. Expand Security and then right-click Logins.-> New Login

3. In the dialog box, enter the following information:

Name: Type the name of the new login. For Windows authentication, click “Search” to browse the network for a Windows user account.

Authentication: Choose between Windows authentication or SQL Server authentication. If you select SQL Server authentication, provide a password for the login.

Database: Select the default database that the login will use. You can choose “Runtime”.

Language: Choose a language or leave it as “<default>” to use United States English.

5. Click on the Server Roles tab. To assign the new login to an existing server role(s), select the appropriate checkbox(es) in the list. This is usually not required unless you are defining a power user with specific administrative capabilities on the server.

6. Switch to the User Mapping tab. The User column contains the username mapped to the login ID, if it exists. By default, the username is the same as the login name.

7. Select the databases accessible by the new login. Typically, AVEVA Historian users need access to the Runtime and Holding databases. Access to the master database is necessary only if administrative privileges are required.

Available database roles for the selected database(s) will appear in the Database Roles list. By default, all new logins are members of the Public database role, but you can choose an additional or different role for a specific database.

8. Once you have configured the login, click OK.

9. If you created a login with a SQL Server password, you will be prompted to confirm the new password. Confirm the password and click OK.

The post Working with Historian-related SQL Permissions in SQL Server Management Studio appeared first on Industrial Software Solutions.

This training document provides an introduction to Tags and Classes in AVEVA Edge.  Tags are essential elements within a project, serving as variables to store data from communication with plant I/O devices, calculations, and user input. Classes play a vital role in organizing tags and creating complex structures.

This document will explain both concepts and provide implementation steps on:

• Creating Project Tags
• Creating Class Tags

APPLIES TO

• AVEVA Edge

EXPLANATION

Tags

Tags offer versatile functionality, including displaying information, manipulating screen objects, and controlling runtime tasks. Tags are organized into categories on the Global tab of the Project Explorer, which includes Project Tags, Shared Tags, and System Tags.

• Project Tags
  • Created during project development, project tags encompass various types, including screen tags, field equipment read/write tags, control tags, and auxiliary tags used for mathematical calculations.
• Shared Tags
  • Created in a PC-based control program and then imported into AVEVA Edge’s tags database. Modification of shared tags must be done in the original PC-based control program and reimported into the Tags database.
• System Tags
  • Predefined tags with predetermined functions used for AVEVA Edge supervisory tasks, such as holding the current date and time. Most system tags are read-only and cannot be edited or removed from the database.

Tag Properties

Tag properties are metadata associated with each project tag, providing various configurations during project runtime. They go beyond simple variable storage, offering functionalities like alarm conditions, quality assessment, unit conversion, access to individual bits, historical data storage, and more. The tags can be configured and modified in the the Datasheet View.

• Tag Name
  • Must be unique and comply with specific naming rules. Names can include uppercase and lowercase letters, accented forms, standard numerals, and the underscore character.
• Data Type
  • Identifies the type of data the tag will receive, which include Boolean, Integer, Real, or String.
• Scope
  • Determines whether a tag resides on the project server or on each remote client station. Server scope affects the entire project, while local scope affects only the station where the change was made.
• Array Tags
  • Tags can be single values or arrays of values. Array tags group multiple tags with the same name but unique array indexes. They are used for simplifying configurations, multiplexing, and saving development time. Each array position (including the
    position 0) counts as one tag for licensing restrictions because each position has an independent value.
• Indirect Tags
  • Support indirect access to tags in the database by pointing to other database tags. Indirect tags save development time by avoiding duplicate tags and logic. You can create an indirect tag by entering the @ symbol in front of the tagname: @TagName

Not all tag properties are shown by default in Datasheet View. To show/hide additional columns for other tag properties, you can right-click anywhere in the datasheet and choose the desired properties:

• Name (cannot be hidden)
• Size (shown by default)
• Type (shown by default)
• Description (shown by default)
• Scope (shown by default)
• More Columns:
  • Startup
  • Min
  • Max
  • Unit
  • Retentive Value
  • Retentive Parameters
  • Dead Band
  • Smoothing
  • UA External Availability (shown by default)
  • I-Value
  • I-Alarm
  • I-Historian

Classes

Classes are compound tags that offer encapsulation within the Tags database. Basic tags are designed to receive a single value, whereas classes are designed to receive multiple values. Class-type tags provide sets of values for their members, simplifying configurations and organizing repetitive groups of variables.

Defining a Class

The Classes folder contains project classes and their respective members. To create a class, you define its members and their types. Class members are variables that store values for objects with specific characteristics. This is particularly useful for projects with repeating groups of variables. A Class icon appears in the Tag List subfolder when you create a class folder in the Project Tags folder.

Once a class and it’s members have been defined, you can access the members of a class using the following syntax: TagName.MemberName.

Class Member Properties

The following class member properties are editable:

• Name
  • Name for the member or member property. Must begin with a letter and can be up to 255 characters.
• Type
  • The data type for the member, which include Boolean, Integer, Real, or String. Members of a class cannot be another class type.
• Description
  • A description of the member for documentation purposes.

IMPLEMENTATION

Creating Project Tags

There are two possible methods for creating a tag. Both will both noted below.

1. First, we will create just a single tag. In AVEVA Edge Studio, click the Insert tab and select Tag from the “Global” group. Alternatively, go to Project Explorer -> Global Tab -> right-click Project Tags -> Insert Tag.

2. The New Tag dialog appears. Enter a Name for your tag (example: “TestTag”).

3. Provide a Description (example: This is a Test Tag).

4. Click OK. Observe the new tag in the Project Tags -> Tag List in Project Explorer.

5. To create multiple tags, go to Project Explorer -> Global tab ->  expand Project Tags -> right-click Datasheet View -> Open.

6. Here, you can enter multiple tags in the Project Tags worksheet.

Creating Class Tags

There are two possible methods for creating a class. Both will both noted below.

1. In AVEVA Edge Studio, click the Insert tab and select Class from the “Global” group. Alternatively, go to Project Explorer -> Global Tab -> right-click Classes -> Insert Class.

2. The Insert Class dialog appears. Enter a Name for your class (example: “TestClass”).

3. Click OK. The Class worksheet appears in the workspace.

4. Here, you can configure members of your class. Configure a few as an example.

5. Close the Class worksheet. Go to Project Explorer -> Global tab ->  expand Project Tags -> right-click Datasheet View -> Open.

6. The Project Tags worksheet appears. Create a new Class tag. Here is an example:

Name: TestClassTag

Array Size: 0

Type: TestClass

Description: TestClass tag

The post AVEVA Edge Tags and Classes Overview appeared first on Industrial Software Solutions.

AVEVA Historian Client includes a few Microsoft Office Add-Ins which offer enhanced functionality in processing and analyzing your stored data. These add-ins require 32-bit Microsoft Office and can be added during installation of System Platform or via modification of an existing installation.

This training document will explain how to install 32-bit Microsoft Office if needed and how to install the Add-Ins whether during an initial installation or via “Modify”.

APPLIES TO

• AVEVA Historian Client

EXPLANATION

The two main add-ins available are:

Historian Client Workbook:

• • Requires 32-bit versions of Microsoft Excel.
  • Allows users to display and analyze historical and recent data from the Historian database using Microsoft Excel.
  • Enables users to create Excel-based reports and perform data analysis.

Historian Client Report:

• • Requires 32-bit versions of Microsoft Word.
  • Provides advanced reporting for historical and recent data from the Historian database using Microsoft Word.
  • Allows users to generate richly formatted reports and document historical data trends using a Word document.

IMPLEMENTATION

Install 32-bit Microsoft Office

1. Confirm the version of your current Microsoft Office installation. It must be 32-bit to work with the Historian Office Add-Ins. You can confirm that, you can follow these steps from Microsoft.

2. If you have 64-bit Office installed, you will need to uninstall this first.

3. Then, go to www.office.com and if you’re not already signed in, select Sign in.

4. On office.com, click the dropdown menu on the Install Apps button and choose “Other Install Options”.

5. From the My Account page, under Offices apps & devices, click the “View apps & devices” button.

6. From Apps & devices, within the Office subsection, click the “Version” dropdown and select 32-bit. Then click Install Office.

7. Proceed with using this installer on the desired computer.

Installing the Microsoft Office Add-Ins in a New Installation

1. With an unblocked copy of the System Platform installation media, run setup.exe on the desired computer.

2. Confirm your System Compatibility if needed and click Next.

3. For Select Installation Type, choose Product Based Selection and click Next.

4. Scroll down to Historian Client and check the box for Microsoft Office (32 Bit) Addins

5. Proceed with the rest of the installation to install the add-ins.

6. To confirm the add-ins have been installed, open either Excel or Word and confirm the Historian menu appears.

Adding the Microsoft Office Add-Ins to an Existing Installation

1. On an existing System Platform installation, run setup.exe from the installation media or choose uninstall/change from Programs & Features  to run the installation media.

2. The installer begins. When prompted, choose the Modify option.

3. Scroll down to Historian Client and check the box for Microsoft Office (32 Bit) Addins.

NOTE: Do not uncheck any products. Any products unchecked during a modify will be uninstalled.

4. Proceed with the rest of the modification to install the add-ins.

5. To confirm the add-ins have been added, open either Excel or Word and confirm the Historian menu appears.

The post Installing Microsoft Add-Ins for Historian Client appeared first on Industrial Software Solutions.

AVEVA InTouch HMI 2020 and later now provides two ways to store historical data from InTouch tags. This training document will explain the two methods, the pros and cons of each, and provide implementation steps for them. The two methods are:

• InTouch Enable Storage to Historian 
• Tag Importer Wizard

This document assumes understanding of WindowMaker and Tagname Dictionary.

APPLIES TO

• AVEVA Historian
• AVEVA InTouch HMI (2020 and newer)

EXPLANATION

NOTE: Both methods allow you to store data from InTouch tags and then later retrieve it for furthering analysis and trending.

Enable Storage to Historian

The Historian Client Access is a built-in feature of InTouch HMI that allows WindowViewer to send historical data to Historian.  This feature is known as “Enable Storage to Historian” and can be configured in the Historical Logging Properties dialog box in WindowMaker -> Special -> Configure -> Historical Logging.

In this method, tag values are pushed over to Historian directly from the WindowViewer session over HCAL (Historian Client Access Layer). This is more similar to how Application Server pushes over data. The InTouch tags are imported to Historian as MDAS tags. Tags are only recorded into Historian when WindowViewer is running.

To enable the Enable Storage to Historian feature, go to the Historical Logging Properties dialog box. There, you need to specify the name of the Historian server in the Historian node name box. You can use the computer’s node name or IP address. Special characters like period (.), underscore (_), and hyphen (-) are allowed.

You can also enable “Store and Forward” which allows data to be locally stored should WindowViewer lose connection to Historian for a period of time. To do so, specify the storage location path in the History store forward directory field. Once the connection is reestablished, the Historian server syncs with these files and preserves all the information.

In addition, any tags you want to store to Historian via this method must have Log Data enabled.

Advanced Settings and Dealing with Conflicts

For more configuration options, you can access the Advanced Settings from the dialog box. These settings can be used to help optimize the transmission of data from WindowViewer to Historian.

There are also some settings to help handle multiple instances of WindowViewer storing data to Historian via the Always affix unique string option. A good practice is to use the node name or location name of each WindowViewer instance as the prefix or suffix, making all tags in Historian unique. This is especially important for built-in System tags in WindowViewer, as every instance has the same 34 built-in System tags.

Tag Importer Wizard

The Tag Importer Wizard allows you to easily import configuration information, such as tags and I/O Servers, from an InTouch HMI application. In this method, tags are pushed over to Historian from the I/O servers themselves. When a tagname dictionary file is imported, InTouch pulls the I/O configuration and creates IDASs, Historian Data Acquisition Services that accept data values from one or more I/O servers.

Tag Importer Wizard saves time by eliminating the need for manual tag configuration. This method allows you to import tag name databases from multiple InTouch nodes. It also automatically maps the data from the InTouch application to the appropriate tables in the Historian Runtime database during the import process.

If you need to update only the changed tags since the last import, you can perform a Delta Reimport. This is faster and retains existing storage settings for the tags.

Once the tags have been imported, you can view properties for imported InTouch nodes and the list of tags associated with each node in the System Management Console under Configuration Editor > System Configuration > Storage > Imported Nodes and Public Groups > InTouch Nodes.

Import Considerations

• Ensure you have administrative permissions for the Historian Runtime and Holding databases.
• Set the AllowOriginals system parameter to 1 before importing .lgh original data.
• Close InTouch WindowMaker before importing the Tagname.x file.

Considerations Between Both Methods

While Enable Storage to Historian is easier to configure, using Enable Storage to Historian instead of the Import Tags Wizard has some important differences to consider.

First, Enable Storage to Historian requires WindowViewer to be running continuously so that it can continuously provide data to Historian. On the other hand, the Import Tags Wizard creates IDAS which connect directly to the I/O servers and don’t require WindowViewer be running. So, if you use Enable Storage to Historian and WindowViewer closes, there will be gaps in the historical data during that downtime. For more continuous data storage that doesn’t require WindowViewer running, Import Tags Wizard would be the recommended method.

Another consideration is that Message tags in WindowViewer won’t be recorded in Historian when using Enable Storage to Historian. However, the Import Tags Wizard can record string data, including Message tags.

If you want to store Alarms and Events to History Blocks (2020 R2 and newer), you would need to use Enable Storage to Historian. If you use the Import Tags Wizard, historical alarms/events will still need to be stored in a database.

Finally, Enable Storage to Historian may cause issues with multiple WindowViewer sessions. Enabling the prefix requires access to WindowMaker which most client computers do not have. In addition, the affixed tags will add extra tag counts in Historian. If you have multiple WindowViewer clients, it’s recommend to only have one of them storing to Historian via this method, or to use Import Tags Wizard to pull directly from the I/O Servers.

IMPLEMENTATION

Enable Storage to Historian

1. Open WindowMaker and navigate to the Tools -> Configure -> Historical Logging, or go to Special -> Configure -> Historical Logging.

2. The Historical Logging Properties dialog box opens.

3. In the Historical Logging Properties dialog box, check the option “Enable Storage to Historian.”

4. In the Historian node name field, enter the name of your Historian Server. Specify a valid History store forward directory as well.

5. Click OK to save the changes and close the dialog box.

6. Make sure any tags you wish to store to Historian via this method have Log Data checked.

Tag Importer Wizard

1. Open the System Platform Management Console (SMC) and expand Historian -> Historian Group -> <HistorianName> -> Configuration Editor.

2. Right-click Configuration Editor -> Import Tags.

3. The Tag Importer Wizard opens. Click Next and choose the InTouch tagname database (Tagname.x) you want to import by clicking Add to browse to an InTouch application path.

4. Verify the InTouch computer name and application path during the import. Click Next.

5. Configure how the Tag Importer handles duplicate tags (if any) to ensure unique tag names in the Historian. Click Next.

6. The Tag Importer Wizard – Filter Tags dialog opens. Select the categories of tags you want to import (e.g., Plant I/O, Memory, System). You can also just choose specific Access Names to import or not import by clicking the Topics button. Then click Next.

7. The Tag Importer Wizard – Tag Storage dialog appears. Select storage options, such as cyclic or delta storage rates, for the imported tags. Click Next.

8. The Tag Importer Wizard – Final Confirmation dialog appears. Note that it is advisable to backup the Runtime database before continuing. Click Finish to import tags.

9. The import begins and provides a report. Click OK to close.

10. Under Configuration Editor -> System Configuration -> Data Acquisition, note that IDAS(s) have been created with the list of InTouch tags.

11. Under Configuration Editor -> Public Groups -> InTouch Nodes, note that the InTouch node has been created with a list of InTouch tags.

The post Using Historian with InTouch HMI appeared first on Industrial Software Solutions.

This training document provides an overview of the Configuration Export and Import utility, also known as Historian Database Export/Import Utility (aahDBDump.exe). It explains the benefits of exporting and importing AVEVA Historian configuration information to a text file. The utility allows bulk modifications to the configuration instead of just using the Configuration Editor for individual database entities. It also facilitates the transfer of configuration information between historians.

The document will also walk you through:

• Exporting a Configuration
• Importing a Configuration

APPLIES TO

• AVEVA Historian Server

EXPLANATION

Importing or Exporting Tag Information

The Historian Database Export/Import Utility allows exporting or importing various Historian configuration items, including analog, discrete, string, and event tags, system parameters, I/O servers, topics, and more. It is a versatile tool for managing Historian configuration. The utility does not export InTouch node information or tags with their current editor set to be AVEVA Application Server.

You can specify Unicode or ASCII as the preferred encoding format when exporting configuration information. Select Unicode when exporting data with double-byte characters (e.g., Japanese tag names).

Using the Utility

Use the Historian Database Export/Import Utility to export configuration information. You can choose to export all objects or specific entities from the Historian Configuration. Additional options are provided for tag-specific filtering. The export process generates a text file containing the configuration data. By editing the configuration text file, you can insert new objects, modify existing ones, or delete entities. The order of entities in the file is crucial for successful importing.

The import process requires a client connection to the SQL Server used by the historian. The utility allows importing text files, and you can choose to insert, update, delete, or ignore data based on mode indicators.

The utility also keeps track of errors encountered during an import, providing a detailed error log (aahDBDumpLog.Txt) containing information such as date, input file name, line numbers, and SQL Server error messages.

IMPLEMENTATION

Exporting a Configuration

To export configuration information, follow these steps:

1. Go to the Windows Start menu -> AVEVA Historian -> Configuration Export and Import. This will open the Historian Database Export/Import Utility Wizard.

2. Select “Export from Historian to a text file.” and click Next to proceed. The”Connect” dialog appears.

3. Provide the following information:

Server Name: type the name of the AVEVA Historian for which you want to export the configuration

Authentication: Provide login credentials for the historian. You can either use Windows authentication or SQL Server authentication.

Text File: Type the path for the text file to which you want to export the configuration. Alternatively, you can browse to the desired location.

NOTE: If you want to encode the data as Unicode when exporting, select the “Save file as Unicode” check box. This is useful for exporting data with double-byte characters like Japanese tag names.

Options: To export configuration information for all database entities (e.g., tags, engineering units, summary operations), select “Export all objects” and skip to step 6. Otherwise, do not check this option and then follow the proceeding steps.

4. Click “Next” to continue, and the “Select Objects” dialog will be displayed. Provide the following information:

Data acquisition and miscellaneous: Choose one or more groups of definitions to export. These include IDAS, I/O servers, topics, system parameters, storage locations, engineering units, extended property names, messages, snapshot tags, summary operations, summary tags, replication servers, replication schedules, extended property values, replication groups, replication tag entities, tag history, structure tags, auto-tags, and auto-tag history.

Analog Tags: To export analog tag definitions, select “Include Analog Tags.” Note that system tags are not included in the export.

Where tagname like: Use this box to filter tags by name. Leave it blank or use the wildcard symbol (%) to include all tag names. The exporter recognizes SQL Server wildcard characters.

Acquisition Type: Choose the filter for the source of tag values. You can select “All acquisition types” (no filter set), “IOServer only” (to include only I/O Server data source tags), or “Manual only” (to include MDAS, HCAL, or manually acquired tags).

Storage Type: Select the filter for the storage type, which determines how often the value for an analog tag is stored (either cyclic or delta).

5. Click Next to proceed. The”Select Objects” dialog is displayed. Configure the filters for discrete, string, and event tag definitions. System tags are not included in these options, and the process is similar to filtering analog tags.

6. Click Next to move to the “Confirm” dialog.

7. Click Next to begin the export process. The “Status” dialog box will appear, showing the results of the export and the number of objects exported.

8. Finally, click Finish to exit the wizard. The configuration data is now exported to the specified text file.

9. Browse to the path designated in step 3 and confirm the file exists. You can open this file to review the contents. A CSV editor is recommended.

Importing a Configuration

1. Go to the Windows Start menu -> AVEVA Historian -> Configuration Export and Import. This will open the Historian Database Export/Import Utility Wizard.

2. Select “Import from a text file to Historian.” and click Next to proceed. The “Connect” dialog appears.

3. Provide the following information:

Server Name: type the name of the AVEVA Historian for which you want to export the configuration

Authentication: Provide login credentials for the historian. You can either use Windows authentication or SQL Server authentication.

Text File: Type the path for the text file from which you want to import the configuration. Or, click the ellipse to browse to the location.

4. Click Next. The “Confirm” dialog appears.

5. Click Next to start the import process.

NOTE: If the text file includes delete mode indicators, the utility will prompt you to verify each entity to delete, unless you choose to turn off subsequent delete warnings.

6. The “Status” dialog will display the results of the import, including the number of objects imported.

7. Click Finish to exit the wizard and complete the import process.

The post Exporting and Importing Historian Configuration appeared first on Industrial Software Solutions.

This training document provides an overview of I/O Auto-Assignment in AVEVA Application Server. It explains how the I/O feature allows configuration of data input and output for attributes, along with advanced properties. I/O Auto-Assignment eliminates the need for manual configuration or scripting of I/O references, streamlining the deployment process.

This document assumes understanding of Device Integration (DI) Objects and OI-Servers.

APPLIES TO

• Application Server

EXPLANATION

The I/O Feature

The I/O feature can be applied to attributes in application objects to enable the configuration of data input and output for attributes.

The feature allows specifying I/O types such as:

• Read (Input)
• Read/Write (Input/Output)
• Write (Output)

Advanced I/O properties are available based on the attribute’s data type and I/O type.

I/O Auto Assignment

I/O Auto Assignment is a time-saving alternative to manually configuring I/O references or scripting them at runtime. By enabling I/O Auto Assignment, you can prepare input or output attributes for automatic assignment, eliminating the need to edit individual objects for I/O configuration and reduce cumbersome scripting for setting I/O. When using auto-assignment, your object name format must follow the same syntax as the actual item in the PLC.

NOTE: I/O Auto Assignment is the default setting for application and other system objects like area objects, but Device Integration (DI) Objects still must be manually configured.

When input or output attributes are added to an area or application object in the Object Editor’s Attributes tab, the default setting prepares these attributes for I/O Auto Assignment. The auto assignment reference appears in the I/O section of the Attributes tab when the I/O attribute feature is enabled.

The default string for an input reference is:

IODevice.[ObjectName].[AttributeName].InputSource

For an output reference:

IODevice.[ObjectName].[AttributeName].OutputDest.

Where IODevice is a placeholder for automatically building the I/O reference when the object is linked to a scan group and DI object, without manual entry or scripting.

For instance, the reference <IODevice>.Mixer.Tank.Inlet.InputSource is transformed to OPC001.Fast.Mixer.Tank.Inlet.InputSource after assigning the object to the scan group “Fast” under DI object “OPC001.”

NOTE: Do not lock InputSource or OutputDest attributes when using I/O Auto Assignment, as locking these attributes in the parent template will prevent the resolved reference from updating during object deployment.

Validating I/O Assignments and References

The IO Device Mapping view displays I/O Auto Assignment references for application and system objects linked to DI object scan groups. Manually configured references are not shown, nor are attributes associated with objects not yet assigned to a scan group.

In the IO Device Mapping view, you can view and validate I/O references for each auto-assigned attribute and override the generated references. You can also select multiple items, filter, sort, or group the attributes as needed. The view also is divided into columns displaying information for each auto-assigned I/O attribute. You can customize the display by sorting, grouping, or filtering the attributes.

To ensure the accuracy of I/O assignments without needing to check out objects, you can validate auto-assigned I/O attributes in the IO Device Mapping view by pressing the “Validate References” button.

IMPLEMENTATION

Optional Section – Configuring a DI Object for Data Simulation

This section will walk you through configuring the OI-Simulator (OI.Sim), which we will use in this training document. This document assumes the OI-Server, OI.Sim, is installed on the same computer as the GR node/where these objects are being deployed. Any references to “server node” will use “localhost”.

If you already have a designated DI Object, you can jump to Configuring I/O Auto-Assignment.

1. In the IDE, create a new instance of $OPCClient from Template Toolbox -> Device Integration. Name the instance “Simulator“

NOTE: “Simulator” is the required name in order for this object to connect to the OI-Simulator.

2. Double-click “Simulator” to open its configuration editor. On the General tab, enter “localhost” for the Server node and choose “OI.SIM.1” for the Server name.

3. On the “Scan Group” tab, add three scan groups with the following configuration:

4. Save and close the editor.

5. Assign “Simulator” to an app engine for deployment.

6. Right-click “Simulator” -> Deploy with the default options. Deploy the platform and app engine before doing so.

7. Once deployed, navigate to the SMC and verify that the OI.Sim driver has started. The driver will auto-start once an $OPCClient instance named “Simulator” is deployed.

Configuring I/O Auto-Assignment

1. To begin, create an instance of $UserDefined. Name the instance “Test”.

2. Open “Test for editing. Add a new attribute configured as follows:

Name: PV

Description: Test PV value

Data Type: Float

Writeability: Object writeable

Initial Value: 0.0

Features: I/O

3. Note when you enable I/O, the Read from/Write to field automatically populates with: Simulator.Fast.Test.PV

This is because objects with I/O enabled use auto-assignment by default. This means that at runtime, Test.PV will resolves it’s I/O source through the “Fast” topic on the Simulator DIObject.

NOTE: Since we are using the Simulator, our reference can be anything. In practice, you’d need to ensure your object naming convention lines up with the item syntax from the PLC in order to successfully  use I/O Auto-Assignment.

4. Assign “Test” to an $Area instance hosted on an app engine and platform and deploy.

5. Right-click “Test” -> View in Object Viewer. Add “PV” to the Watch Window and observe the value change.

6. You can also assign objects to other I/O devices easily. In IDE go the View menu -> IO Devices to show the IO Devices pane. Expand Simulator -> Fast and observe that “Test” is assigned here.

7. Undeploy “Test”. Then, in IO Devices, move “Test” to the “Normal” device group by dragging and dropping. Then, open up “Test” for editing. Observe that the I/O feature for the PV attribute has been revised to: Simulator.Normal.Test.PV

The post I/O Auto Assignment Overview appeared first on Industrial Software Solutions.