1. How To Create a Microsoft SQL Server Install for NextGen Archiving
2. How to Configure NextGen Archiving in WinCC OA to use Microsoft SQL Server

Table of Contents:

1. Notes/Prerequisites
2. WinCC OA
   • 3.1 Project Setup 
   • 3.2 NGA Configuration 
   • 3.3 Archive Group Configuration 
   • 3.4 DPE Archive Configuration 
   • 3.5 Data Retrieval 
3. Further Reading/References 

1. Notes/Prerequisites

Required Programs:

• Microsoft SQL Server (installation instructions in part 2a)
• Microsoft SQL Server Management Studio
• Microsoft SQL Server Configuration Manager (installed alongside Microsoft SQL Server)

This demo was implemented using:

• WinCC OA 3.18 P006
• Microsoft SQL Server 2022 Express
  • NOTE: Other versions of MS SQL may work with NGA, but it has not yet been verified by DMC.
• Microsoft SQL Server Management Studio 18
• Windows 11

Assumptions:

• Proper licensing for NGA is configured.
• The OS user has Windows administrator privileges.

3. WinCC OA

3.1 Project Setup

• Create a new project with NGA configured
  • When creating a new project, proceed with the project setup as normal
  • Under the “General Settings” step, ensure that the Use NextGenArchiver option is selected
  • For this demo, I’m creating a project titled NGA_Demo located in the “C:/WinCC_OA_Proj” directory

If converting an existing project from HDB/RDB to NGA, then follow these steps in the “Converting existing project to NextGen Archiver Project” section: NGA Notes and Restrictions

3.2 NGA Configuration

It’s time to fire up OA and open GEDI

1. Create new back-end

• Navigate to the “Database Engineering” window via “SysMgm/Database/Database Engineering”
• Under the “Backend list”, click the + icon (Add new backend)
• Name the Backend a user-friendly name
  • I used the title MSSQLEXPRESS
  • NOTE: The Backend name does not need to match the server name, so use a name that makes most sense for your application

2. Configure the MS SQL Backend “General Settings – Basic Configuration”

• Specify the following parameters

• Notes:
  • The Profile option cannot be changed later
  • If using a redundant server, use the MSSQL option for Profile
  • Don’t worry about specifying the Password, the field will clear upon initial configuration saving

• Click the Password field, enter the winccoaPassword from db.windows.config, and click OK

3. Configure the MS SQL Backend “Extended Settings”

• Specify the following parameters

4. Finish MS SQL Backend setup

• Select the Active option
• Click Save

3.3 Archive Group Configuration

Now that the database connection has been established, we can set up Archive Groups

1. Create new archive group
   • Navigate to the “Runtime Engineering” window via “SysMgm/Database/Runtime Engineering”
   • Under the “Archive Groups”, click the + icon (Add a new group)
   • Name the Archive Group
     • I used the title DEMO
     • Ensure the Active option is selected
     • Configure the “Storage Settings” section as desired
     • Click Save

2. Verify SQL Archive Group Creation

• Open Microsoft SQL Server Management Studio,
• Right-click dbo.archive_groups and select the Select Top 1000 Rows option
  • The new archive group should be visible in the “Results” section

3.4 DPE Archive Configuration

Now that we’ve created an archive group, we can apply the archive group to a DPE so that its historical data can be logged and tracked.

1. Insert_archive config
   • Within PARA, right-click the target DP or DPE and select the Insert config option
   • Select Archive settings
   • Click OK

2. Select archive group

• Underneath the target DP/DPE, select the new _archive option
• Select the desired archive group in the “Archive Group” drop-down
• Ensure the Active option is selected
• Click OK

3. Verify SQL Archive Group Application

• Open Microsoft SQL Server Management Studio
• Right-click dbo.elements and select the Select Top 1000 Rows option
  • The newly-configured DPE(s) should be visible in the “Results” section

3.5 Data Retrieval

Now that DPEs have been configured with archiving capabilities, we can now retrieve DPEs’ historical data

1. Verify SQL DPE Archiving
   • Open Micorosft SQL Server Management Studio
   • Right click dbo.event_<segment_id>_a and select Select Top 1000 Rows
     • The segment_id for each archive group can be found in the dbo.segments table
   • If values have been changed since archiving was configured, entries should be visible in the “Results” section

2. Retrieve historical data

• The WinCC OA functions dpGetPeriod() and dpQuery() can be used to retrieve historical data
  • The two examples below demonstrate a test panel running each of the two aforementioned functions and printing the results to the Log Viewer
  • The returned data should reflect that viewed in the Micorosft SQL Server Management Studio tables
• Be sure to understand your server’s backup and retention policy to determine what data and how much historical information can be accessed

NOTE: For help writing SQL queries, use the SQL Panel found in SysMgm/Reports/SQL-Query

3. Further Reading/References

• MS SQL® Server Installation guide
• Software requirements
• Configure the Windows Firewall to allow SQL Server access

The post How to Configure NextGen Archiving in WinCC OA to use a Microsoft SQL Server appeared first on DMC, Inc..

1. How to Create a Microsoft SQL Server Install for NextGen Archiving
2. How to Configure NextGen Archiving in WinCC OA to use a Microsoft SQL Server

Table of Contents:

1. Notes/Prerequisites
2. MS SQL Server and Database
   1. 2.1 MS SQL Server and Installation 
      • Basic Installation
      • Custom Installation
   2. 2.2 MS SQL Server Configuration
      • SQL Server Configuration Manager
      • Microsoft SQL Server Management Studio
   3. Database Creation
3. Further Reading/References

1. Notes/Prerequisites

Required Programs:

• Microsoft SQL Server (Installation instructions in part 2a)
• Microsoft SQL Server Management Studio
• Microsoft SQL Server Configuration Manager (installed alongside Microsoft SQL Server)

This demo was implemented using:

• WinCC OA 3.18 P006
• Microsoft SQL Server 2022 Express
  • NOTE: Other versions of MS SQL may work with NGA, but it has not yet been verified by DMC.
• Microsoft SQL Server Management Studio 18
• Windows 11

Assumptions:

• Proper licensing for NGA is configured
• The OS user has Windows administrator privileges

2. MS SQL Server and Database

2.1 MS SQL Server and Installation

Back to Table of Contents

1. Begin the SQL server installation
   • Download Microsoft SQL Server setup application from Microsoft’s SQL Server Downloads page
   • Run the application and proceed with the Basic or Custom installation.  

Basic Installation

If implementing the basic installation:

2. On the installation confirmation screen, select the Customize option

3. Configure the “Installation Type” Window properties

• Select the Add features to an existing instance of SQL Server <Year> option
• Select the server you wish to use for NGA connection

NOTE: If a specific server setup window is not specified, feel free to use the default options

4. Configure the “Azure Extension for SQL Server” Window properties

• Un-check the Azure extension for SQL Server option

5. Configure the “Feature Selection” Window properties

• Select the SQL Server Replication option
  • NOTE: Installing this option is the primary purpose of customizing the server
• Click Next to begin installation

NOTE: If implementing the basic installation, a Mixed Authentication Mode will need to be specified for the server. This will be handled in the 2.2 MS SQL Server Configuration section.

Custom Installation

If implementing the custom installation, follow the steps outlined in the WinCC OA MS SQL® Server Installation documentation.

2.2 MS SQL Server Configuration

Back to Table of Contents

Steps for configuring the SQL server will take place in both the SQL Server Configuration Manager and Microsoft SQL Server Management Studio programs (installed in 2.1 MS SQL Server Installation)

SQL Server Configuration Manager

Within the SQL Server Configuration Manager…

1. Configure the Server’s TCP/IP Properties
   • Navigate to “SQL Server Network Configuration/Protocols for <SERVER NAME>”
   • Double-click the TCP/IP item in the “Protocol Name” column to open the “TCP/IP Properties” window
   • In the “Protocol” tab, toggle the Enabled option to Yes
   • In the “IP Addresses” tab, specify 1433 for the IPAll/TCP Port option
   • Click OK to apply and close the window
     • NOTE: A warning will appear indicating that changes will be applied only after the server is restarted

2. Restart the SQL Server

• Navigate to “SQL Server  Services”
• Right-click the “SQL Server (<SERVER NAME>)” row and click Restart

Microsoft SQL Server Management Studio

Within Microsoft SQL Server Management Studio…

1. Connect to the SQL Server

• Click the “Connect Object Explorer” icon within the “Object Explorer”
• Specify the following parameters in the “Connect to Server” window and click Connect

NOTE: If the “Custom” SQL Server installation was implemented, then a connection can be made using the “SQL Server Authentication” method and the specified credentials

2. Enable dual authentication mode

1. Right-click the server name in the “Object Explorer” and select Properties
2. Navigate to the “Security” page in the “Select a Page” menu
3. Under the “Server Authentication” section, select SQL Server and Windows Authentication Mode option
4. Click OK to apply changes
5. NOTE: A warning will appear indicating that changes will be applied only after the server is restarted
6. Restart the SQL Server via the SQL Server Configuration Manager using the steps outlined in Step 2 of the SQL Server Configuration Manager instructions

3. Configure the System Administrator Credentials

• Under the “Object Explorer”, navigate to “<Database Name>/Security/Logins”
• Right-click the sa (System Administrator) option and select the Properties option
• Under the “General” page of the Login Properties window, specify a password in the Password: and Confirm password: fields
  • For this demonstration, I’ll use the password $martPeople3xpertSolutions
• Optional: Toggle the other general properties as needed or deemed necessary by your security need
• Click OK to apply changes

4. If a red “X” appears next to the sa user in the “Object Explorer” , then enable sa (System Administrator) login

• Within the “Login Properties” window from step 3, navigate to the “Status” page
• Under the Settings/Login: option, select Enabled
• Click OK to apply changes

NOTE: You may need to refresh the Object Explorer to see the red “X” disappear

5. Optional: Create a WinCC OA user account
NOTE: This step can be done now, or the user can be automatically created upon database generation (recommended)

• Under the “Object Explorer”, navigate to “<Database Name>/Security/Logins”
• Right-click the “Logins” folder or any of its elements and select the New Login… option
• Within the “General” page
  • Click the SQL Server authentication radio button
  • Specify the user’s name in the Login name: field
    1. For this demonstration, I’ll use the username winccoa
  • Specify the user’s password in the Password: and Confirm password: fields
    1. For this demonstration, I’ll use the password $martPeople3xpertSolutions
• Within the “Server Roles” page
  • Check the public server role
  • Click OK to apply changes

2.3 Database Creation

The database used for NGA will be auto-generated using files that can be found in OA’s base project

1. Locate and copy the required database generation files

• Navigate to the “<winccoa>/data/NGA/MSSQLServer/sql folder” within Windows Explorer
  • Where <winccoa> is the base WinCC OA project
  • The default install location of the base project is typically “C:\Siemens\Automation\WinCC_OA\3.18”
  • Therefore, the path I’m using is “C:\Siemens\Automation\WinCC_OA\3.18\data\NGA\MSSQLServer\sql”
• Copy the relevant files
  • schema.sql
  • db.windows.config
  • create_database_windows.bat
• If your NGA project already exists, copy the relevant files into the same directory in your project
  • You may need to manually create the relevant folders for “<project>/data/NGA/MSSQLServer/sql”
  • It should be noted that the files can be copied anywhere, but it’s organizationally preferable to use the location specified above
  • If you haven’t created a project yet, copy the files into a temporary location and move said files into your project upon project creation (outlined in the 2a. Project Setup instructions)

2. Modify the config file parameters
NOTE: The db.windows.config file will be used to specify the parameters needed to auto-generate the appropriate database

• Open the db.windows.config file and with your favorite text-editing tool like Notepad or Notepad++
• Modify the parameters as needed.

3. Generate the SQL database

• Run the Windows Command Prompt as administrator
  • In the Windows search bar, search “Cmd”
  • Right-click the Command Prompt application and select “Run as administrator”
• Navigate to the location of the create_database_windows.bat file (in the “<project>/data/NGA/MSSQLServer/sql” folder)
  • Use cd <folder> in the command prompt to navigate to the appropriate directory
• Run the create_database_windows.bat file
  • Run the create_database_windows prompt to generate the appropriate database

4. Verify that the appropriate database and users were created

• Within Microsoft SQL Server Management Studio, you should see:
  • The newly created database
  • The generated server-level winccoa user (if it did not already exist)
  • The generated/mapped database-level winccoa user

Explore part 2 for more information:

• How to Configure NextGen Archiving in WinCC OA to use a Microsoft SQL Server

The post WinCC OA – How to Create a Microsoft SQL Server Install for NextGen Archiving appeared first on DMC, Inc..

The group had a pre-flight sandwich lunch from Green Bowl Cafe in La Jolla.

Perched upon the cliffs overlooking Blacks Beach rests the Torrey Pines Gliderport: “the most historic aviation site in North America and Southern California’s premiere location for paragliding, hang gliding, remote control models and sailplanes.” It was here that, on one sunny Saturday afternoon, DMC San Diego took to the skies.

After checking in with our friend Rae – who works at the gliderport – we met our instructor pilots on a grassy field with their paragliders. Before long, we were airborne. With the beach below and the cliffs and ocean on either side, we soared, dipped, and glided through the air.

Nicoli checking in with Rae

Nicoli and his instructor pilot preparing for flight

Nicoli just hanging out

Nick pretending to be a bird

Nick and Nicoli’s post-flight smiles

Good news! Nick and Rae found a dog.

Learn more about DMC's corporate culture and explore our open positions!

The post DMC San Diego Takes to the Skies appeared first on DMC, Inc..

With the ocean and mountains dominating the area around San Diego, it only made sense that those of us in “DMC’s Finest Office” should take advantage of these two amazing natural features. That’s just what we did; one beautiful April weekend, we took on both surf and summit.

Saturday – Surf

The California coast boasts some of the most epic surf spots in the world, and we aimed to take advantage of them. With dreams of hanging ten and crushing barrels dancing in our heads, we took to the beach, donned some tight wet suits, and grabbed our boards.

Squad goals – Pictured from left to right: Nikhil (San Diego), Nick (San Diego), Nicoli (San Diego), Eli (Dallas), and Greg (our instructor)

Although we lacked prior surfing experience, Greg from Pacific Surf had us covered. A quick land-based surf lesson featured the basics of paddling, standing up on the board, and walking through shallow water in a manner known as the sting ray shuffle.

Once we were deemed prepared and worthy, we hit the waves. In no time, Greg had us up on our feet and surfing like pros (correction: surfing like beginners).

Hanging ten and high fiving – Pictured from left to right: Nick (San Diego) and Nikhil (San Diego)

Sunday – Summit

In addition to beautiful beaches and stellar surf, Southern California is home to rolling hills and towering mountains that are perfect for hiking. Just a day after our surfing adventure, the DMC crew arose in the wee hours of the morning and set off towards Palm Springs and Coachella Valley with one goal in mind: conquering San Jacinto Mountain.

Upon arriving to San Jacinto State Park, we laced up our hiking boots and boarded the Palm Springs Aerial Tramway. The large cable car featured a rotating floor that offered a stunning 360-degree view of the mountains and valley floor below. We eventually reached the Mountain station (8,516’ above sea level) and began our hike.

Through snow and ice, the DMC crew trekked 6 miles and roughly 2,600 ft of elevation gain to reach the San Jacinto summit. Though the hike was tough and the trails a bit sketchy at times, the views were well worth the effort.

Learn more about DMC's corporate culture. 

The post DMC San Diego Takes on Surf and Summit appeared first on DMC, Inc..

• Part 1: Creating and Opening a Project
• Part 2: Folder Structure and Gedi Layout
• Part 3: Panels | The Basics
• Part 4: Panel Scripting Environments and QuickTest
• Part 5: Scripting Syntax
• Part 6: Para Overview and Datapoint Creation
• Part 7: Interacting with Datapoints via Scripting
• Part 8: Libraries
• Part 9: Color Database & High-Performance Best Practices
• Part 10: Panels | Panel Nesting and $-Parameters
• Part 11: Panels | Child Panels (Popups)

What is a Module?

As noted in Part 11 of “Getting Started with WinCC OA”:

“Modules represent their own program window, meaning that the child panel is disjointed from the calling panel and its respective calling module. If the calling panel is changed/closed, the child panel/module will remain opened.”

Modules can be hidden, minimized, maximized, zoomed, and much more. While these topics aren’t pertinent to get started with WinCC OA, they’re still helpful to note. With that said, we’ll now focus on embedded modules and their applications.

Embedded Modules

Like child panels, embedded modules are used to display sub-panels in conjunction with a main panel. On the contrary, while a child panel opens in front of the calling panel, an embedded module exists within an allocated space on the main panel itself.

These embedded modules are helpful for presenting dashboards, portioning out screen real estate, displaying alarm buffers, and more.

For example, one of the default templates located in the base project (Panels/para/PanelTopology/templates/TEMPLATE3/basePanel_1024_768) uses embedded modules to divide the screen into three functional areas. The template contains three primary embedded modules with names that dictate their general purposes:

While we won’t go into too much detail on templates here, it’s important to note that when implemented during runtime, the embedded modules allocate a certain quantity of real estate and present certain sub-panels on the overall display.

• mainModule: Displays the general user-defined screens
• naviModule: Displays the UI’s navigation controls
• infoModule: Displays pertinent information (alarms buffer, date/time, user, etc.)

During runtime, the naviModule and infoModule continuously display their respective content while the mainModule displays the main panels, as defined in the project’s Panel Topology (Panel Topology will be discussed in a later blog installment).

Embedded Module Functions

The most relevant embedded module functions are as follows:

• RootPanelOnModule()
  • Opens a panel in a specified module.
  • Arguments include:
    • FileName – File within the “panels” folder to open.
    • PanelName – Name given to panel.
    • ModuleName
      • Name of module in which the panel will open.
    • Parameters
      • Panel $-Parameters; see Part 10 for information on $-Parameters and Part 11 for how to pass them into panels from calling functions.
• PanelOffModule()
  • Closes the panel in a specified module.
  • Arguments include:
    • PanelName – Name of panel to close.
    • ModuleName – Name of module in which the specified panel is open.
• rootPanel()
  • Returns the name of the panel open in the given module.
  • Arguments include:
    • ModuleName – Name of the root panel open in the specified module.

Fortunately, embedded modules are relatively straightforward to work with. One item to note, however, is that the argument “ModuleName” for relevant functions pertains to the “ModuleName” property (located under the “Extended” properties tab) rather than the embedded module object’s “Name” (located under the “Standard” properties tab).

In addition to its explicit string value, the “ModuleName” can be referenced in scripting using the notation:

<object name>.ModuleName

Example

We’ll continue working with our evolving example from prior blogs to create a dashboard using embedded modules.

Better Naming Practices

First, we’ll do a brief rename of our current panels/DPTs, since names like “TestPanel” and “ChildPanel” are not very descriptive. Please make the following panel changes:

• Rename: ChildPanel.pnl → SetSpeedLimitPopup.pnl
• Rename: TestPanel.pnl → MotorInfoPanel.pnl
• Delete: ParentPanel.pnl (it will not be needed anymore) 

Note: the “ChildPanel.pnl” string in the MotorInfoPanel’s “settingsButtonClicked()” function will need to be changed as well.

In addition, we’ll change the DPT name “myDatapointType” to “Motor” by right-clicking on the DPT in Para and selecting “Edit Datapoint Type.”

Dashboard

Create a new panel called “main.pnl.” This will represent a main/home screen on a SCADA system. Please adjust your panel dimensions according to your screen resolution:

At the top of the panel, we’ll add three objects with the following specified properties:

• A simple border for our “dashboard”:
  • Object: Rectangle
  • Name: “dashboardBackground”
• An embedded module frame for one of our dashboard items:
  • Object: Embedded module
  • Name: “motorInfoDashboard”
  • ModuleName: “motorInfoEmbeddedModule”
  • Size: Make identical to the “MotorInfoPanel.pnl” panel size
• An object to use in embedded module interaction:
  • Object: Button
  • Name: “nextMotorButton”
  • Button text: “Next Motor”

Within our panel’s scopeLib, we’ll have a few constants and variables defined.

Constants:

• MOTOR_INFO_PANEL = name of the motor info panel to open.
• DP_MOTOR_LIST = list of all DPs of type “Motor”.
• NUM_MOTORS = number of motor DPs.

Variables:

• _dpCurrentMotorInfo – panel-scoped variable keeps track of the currently displayed motor DP.

Functions:

• motorInfoDashboardInitialized() – called by the panel’s “Initialize” event; establishes the first motor displayed by calling “displayNextMorotInfoPanel()”.
• nextMotorButtonClicked() –  called by the “nextMotorButton” button’s “Ckicked” event; calls the “displayNextMotorInfoPanel()”.
• displayNextMotorInfoPanel() – Displays the next motor DP defined in the DP_MOTOR_LIST into the motor info panel.

// Display the next motor in the Motor Info Dashboard
displayNextMotorInfoPanel()
{
    // Only attempt to display a dashboard if motors exist
    if (NUM_MOTORS > 0)
    {
        // Determine the next motor in the motor list
        int iNextMotorIndex =
            (dynContains(DP_MOTOR_LIST, _dpCurrentMotorInfo) % NUM_MOTORS) + 1;

        _dpCurrentMotorInfo = DP_MOTOR_LIST[iNextMotorIndex];

        // Open the Motor Info panel for the selected motor
        RootPanelOnModule(
            MOTOR_INFO_PANEL,
            "MotorInfoPanel" + _dpCurrentMotorInfo,
            motorInfoDashboard.ModuleName,
            "$motorDpe:" + dpSubStr(_dpCurrentMotorInfo, DPSUB_DP)
        );
    }
}

// Display the next motor in the Motor Info Dashboard
displayNextMotorInfoPanel()
{
    // Only attempt to display a dashboard if motors exist
    if (NUM_MOTORS > 0)
    {
        // Determine the next motor in the motor list
        int iNextMotorIndex =
            (dynContains(DP_MOTOR_LIST, _dpCurrentMotorInfo) % NUM_MOTORS) + 1;

        _dpCurrentMotorInfo = DP_MOTOR_LIST[iNextMotorIndex];

        // Open the Motor Info panel for the selected motor
        RootPanelOnModule(
            MOTOR_INFO_PANEL,
            "MotorInfoPanel" + _dpCurrentMotorInfo,
            motorInfoDashboard.ModuleName,
            "$motorDpe:" + dpSubStr(_dpCurrentMotorInfo, DPSUB_DP)
        );
    }
}

When running the main.pnl panel in QuickTest, we can iterate through the relevant motor DPs by clicking the “Next Motor” button.

So far, we’ve worked with panels of static widths and heights; however, developers can adjust panel reference dimensions, and users can sometimes resize a given window. OA provides functionality to accommodate for the positioning of objects within a panel when the overall panel dimensions shift.

In the next edition of “Getting Started with WinCC OA,” we’ll take a brief look at panel layouts and how we can use them to dictate the real estate of a panel.

Topics to look forward to in this series: 

• Part 12: Modules & Embedded Modules

Contact DMC to get started on your next WinCC project and learn more about our Siemens SIMATIC WinCC Programmingas well as our WinCC Open Architecture Development.

The post Getting Started with WinCC OA: Part 12 – Modules and Embedded Modules appeared first on DMC, Inc..

• Part 1: Creating and Opening a Project
• Part 2: Folder Structure and Gedi Layout
• Part 3: Panels | The Basics
• Part 4: Panel Scripting Environments and QuickTest
• Part 5: Scripting Syntax
• Part 6: Para Overview and Datapoint Creation
• Part 7: Interacting with Datapoints via Scripting
• Part 8: Libraries
• Part 9: Color Database & High-Performance Best Practices
• Part 10: Panels | Panel Nesting and $-Parameters

In Part 10 of this series, we’ll be exploring popups. Known as “Child Panels” in WinCC OA, popups are an extremely useful aspect of any SCADA system. They can be used for displaying critical alarm information, configuring settings, receiving secondary confirmation — and so much more.

Types of Child Panels

Before we start creating child panels, let’s familiarize ourselves with the different types of popups we have at our disposal. The base keyword of all child panel/popup calling functions is “ChildPanelOn.” With a quick search of “ChildPanelOn” in the documentation’s index tab, we can see there are a variety of child panel functions available.

There are seven main keywords that a “ChildPanelOn” function may implement:

• Central
• Modal
• Return
• Module
• CheckPos
• Parent
• Relative

Central

The “Central” keyword simply indicates that a child panel will be opened and centered in the calling parent panel. In this case, no panel coordinates need to be specified.

Modal

When a “Modal” child panel is opened, the user becomes physically unable to interact with objects outside of the child panel. The child panel must first be closed before continuing operation. This can be helpful for displaying essential warning messages that the user must acknowledge before continuing operation.

Return

A “Return”-designated child panel can return values to the calling script in the form of in/out arguments. We will investigate “Return” panels later in the example.

Module

The “Module” keyword indicates that instead of opening within the calling panel, the child panel will open in its own module.

Modules represent their own program window, meaning that the child panel is disjointed from the calling panel and its respective calling module. If the calling panel is changed/closed, the child panel/module will remain open.

If you would like to know more about modules, they will be discussed at length in the next installment of this series, “Getting Started with WinCC OA.”

CheckPos

This “CheckPos” keyword is exclusively used with the “ChildPanelOnModuleCheckPos()” function. In this case, the “CheckPos” indicates that the opened module will be checked for valid positioning and size. This keyword is very specific and not applicable in many situations, especially when you’re just getting started with WinCC OA, so we won’t dig too deep into it.

Parent

A “Parent” keyword indicates that the child panel is opened within a specified panel. The panel can either be the calling panel or another opened panel.

Relative

The “Relative” keyword dictates that the child panel’s specified coordinates will not be an absolute location, but rather a relative position based on the calling panel.

Calling/Opening Child Panels – Function Parameters

Depending on which of the aforementioned “ChildPanelOn” functions are used, the user will have the opportunity to pass in a variety of parameters. These parameters, amongst other “ChildPanelOn” function properties, are outlined in the WinCC OA Documentation. The more common parameters include:

• FileName
  • File path of the panel to be used as the child
• PanelName
  • Name of the child panel that is to be opened
• ModuleName
  • Name of the module that is to be created for the child panel
  • Used in "Module" "ChildPanelOn" functions
• ParentName
  • Name of the parent panel on which the child opens
  • Used in "Parent" "ChildPanelOn" functions
• Parameters
  • Items passed into the child panel as $-parameters
  • Can be an empty dyn_string
  • Each item in the dyn_string parameter list uses the format "$<parameter>:<value>"
• x, y
  • Position on the parent panel where the child panel is opened
  • Not relevant for "Central" "ChildPanelOn" functions
• resultFloat, resultText
  • Retuned values from child panels called by "Return" "ChildPanelOn" functions
  • Child panels must write their return values to the following DPEs before the child panel is closed:
    • "_Ui_<UiNumber>.ReturnValue.Float"
    • "_Ui_<UiNumber>.ReturnValue.Text"
  • <UiNumber> is a number unique to the active user interface (Gedi or Vision) that can be determined by the function myUiNumber().
  • Alternatively, the "_Ui_<UiNumber>" DP can be provided using the myUiDpName() function
  • Lastly, the function "PanelOffReturn()" can be used to both close the child panel and write the return values to the correct DPEs.

Closing Child Panels

Almost as important as opening a child panel is closing it once the panel’s purpose has been served. To close a child panel, there are two main functions:

• “PanelOff”
  • Closes the opened panel/module from which the function is called
• “PanelOffReturn”
  • Closes the opened panel/module while also providing a return values (dyn_float and dyn_string) to the child panel's calling "Return"-designated "ChildPanelOn" function.

Example

Let’s revisit our example from prior blogs. Instead of entering our “Motor Speed Limit” directly into the corresponding text field, we’ll call a popup and enter the value in there. Before calling a child panel, though, there must first be a child panel to call!

I’ll let you use your creative freedom to make a panel at your artistic discretion. Give it hot-rod flames and bunnies, make it monochromatic, or do something in between. Whatever you choose, make sure the panel has a button labeled “Cancel,” a button labeled “OK,” and a text field to enter the speed limit. I named my panel “ChildPanel.pnl” and it looks like this:

If this was a panel I was working on myself and not just using as an example, the logic approach I’d probably take would be to:

• Pass in the appropriate DPE path as a dollar parameter
• Initialize the speed limit text field with said DPE value (using dpGet)
• Upon pressing “OK” button, set the DPE value to the text field’s value using dpSet() and then close the panel
• Upon pressing the “Cancel” button, close the panel

However, we’ll be utilizing a “Return”-designated child panel in this example. This means that a value(s) will be returned to the calling function. As such, the approach we’ll take for the example is:

• Pass in the current DPE value as a dollar parameter
• Initialize the speed limit text field with said DPE value
• Upon pressing the “OK” button, return the text field’s value in the return dyn_string and TRUE in the return dyn_float to the calling function
• Upon pressing the “Cancel” button, return FALSE in the return dyn_float to the calling function
• If the child panel returns TRUE (“OK” clicked) within the calling function, use dpSet() to set the returned string to the appropriate DPE speed-limit value. If the child panel returns FALSE (“Cancel” clicked), do nothing.

In our child panel’s ScopeLib, we have three functions defined:

• “initializePanel()” – called by the panel’s “Initialize” event; populates the text field with the passed-in dollar parameter
• “okButtonClicked()” – called by the “OK” button’s “Clicked” event; returns the text field’s value and a TRUE to the calling function
• “cancelButtonClicked()” – called by the “Cancel” button’s “Clicked” event; returns a FALSE to the calling function

//Initial speed limit
string sInitialSpeedLimit = $initialSpeedLimit;

void initializePanel()
{
  titleBar(FALSE);

  //Initializes text field with passed-in $-parameter
  maxSpeedTextbox.text(sInitialSpeedLimit);
}


void okButtonClicked()
{
  //Returns TRUE and max speed, closes panel
  PanelOffReturn(
      makeDynFloat(TRUE),
      makeDynString(maxSpeedTextbox.text));
}

void cancelButtonClicked()
{
  //Returns FALSE, closes panel
  PanelOffReturn(
      makeDynFloat(FALSE),
      makeDynString());
}

Note: The “titleBar()” function used within “initializePanel()” determines whether a called child panel will have a title bar or not.

Child panel with title bar vs. without title bar

In the calling panel (TestPanel.pnl), we’ll make the following modifications to the “maxSpeedTextBox”:

• Remove the scripting from the “Command” event
• Update the following properties:
  • Background Color -> "lightgrey"
  • Editable -> FALSE

Note: I also swapped out the “speedTextbox” label shape with a text-field shape so that my “Motor Speed” and “Motor Speed Limit” text fields were visually consistent.

Next, we’ll add a simple button that will be used to call our child panel. I gave mine a fun gear icon (via the “Button Label” property; image path of C:\Siemens\Automation\WinCC_OA\3.16\pictures/test_en.gif)

• Add the “settingsButtonClicked()” function call to the button’s “Clicked” event

My TestPanel.pnl now looks like this:

In ScopeLib, we’ll make the following modifications:

• Remove the “textboxCmd()” function
• Add the following “settingsButtonClicked()” function:

//=============================== Button Clicks =========================================
void settingsButtonClicked()
{
  //Acquire the current max speed
  float maxSpeedValue;
  dpGet(motorDpe + ".rMaxSpeed", maxSpeedValue);

  //Call the child panel "ChildPanel.pnl"
  dyn_float resultFloat;
  dyn_string resultText;
  ChildPanelOnCentralModalReturn(
      "ChildPanel.pnl", "SettingsPanel",
      makeDynString("$initialSpeedLimit:" + maxSpeedValue),
      resultFloat, resultText);

  //Determine the returned values of the child panel
  bool returnOk;
  float returnMaxSpeed;

  //If the returnFloat/Text has items populate the returnOk and returnMaxSpeed appropriately,
  if(dynlen(resultFloat) > 0) returnOk = resultFloat[1];
  if(dynlen(resultText) > 0)  returnMaxSpeed = resultText[1];

  //If the child panel returned TRUE (i.e. "OK" button pressed, then set max speed to returned string value
  if(returnOk == TRUE)
    dpSet(motorDpe + ".rMaxSpeed", returnMaxSpeed);
}

This new function:

1. Acquires the motor’s maximum speed
2. Opens a child panel (of types “Central”, “Modal”, and “Return”) with the motor’s current maximum speed passed in as a $-parameter. Recall that:
   1. Central = Child panel will be centered on calling panel
   2. Modal = The user may only interact with the opened child panel
   3. Return = The child panel returns a set of value that may be used by the parent panel
3. Interprets the child panel’s returned dyn_string and dyn_float data
   1. If the popup's "OK" button was clicked ("returnOk")
   2. The returned user-entered max speed ("returnedMaxSpeed")
4. If the child panel returned TRUE, sets the max speed DPE to the “returnedMaxSpeed” value

Running ParentPanel.pnl in Quick Test, we can modify the motor speed limit of “myMotor3” (or any of our other motors) using the gear icon and the corresponding child panel.

Child panels are extremely useful for using popups to display additional information, notify users of certain warnings, receive secondary confirmation from the user, and so on. However, we may want to display additional information or panel references in a similar way, but without overlaying additional popup panels on top of the current ones. For this, we’ll use embedded modules.

Topics to look forward to in this series: 

• Part 12: Modules & Embedded Modules

In the next edition of “Getting Started with WinCC OA”, we’ll explore the concept of modules and learn how to utilize embedded modules to dynamically open and close reference panels.

Contact DMC to get started on your next WinCC project and learn more about our Siemens SIMATIC WinCC Programmingas well as our WinCC Open Architecture Development.

The post Getting Started With WinCC OA: Part 11 – Panels | Child Panels (Popups) appeared first on DMC, Inc..

• Part 1: Creating and Opening a Project
• Part 2: Folder Structure and Gedi Layout
• Part 3: Panels | The Basics
• Part 4: Panel Scripting Environments and QuickTest
• Part 5: Scripting Syntax
• Part 6: Para Overview and Datapoint Creation
• Part 7: Interacting with Datapoints via Scripting
• Part 8: Libraries
• Part 9: Color Database & High Performance Best Practices

Way back in Part 3 of “Getting Started with WinCC OA”, we investigated the basics of panel creation and development by adding objects and configuring their properties. In Part 10, we’ll dive back into the world of panels by looking at panel nesting and the mechanism with which we pass information from one panel to its nested counterpart: $-Parameters.

Panel References/Embedded Panels

Panel references are used to insert or nest existing panels (reference panels) into other panels (parent panels). This is useful for creating commonly repeated objects like valves or motors and utilizing them in larger systems. If changes are made to the original panel, all references will similarly update within their parent panel.

To create a panel reference, simply drag a panel from the Project View tree onto the working space of another panel.

$-Parameters

Often, developers will want a reference panel to receive specific properties from its parent panel (including, but not limited to, colors, types, and text); This is done via $-Parameters(dollar parameters). $-Parameters are defined in reference panel scripting simply by placing a “$” in front of a variable name. Whenever a reference panel is added to a parent panel, a “Reference Defining” popup will appear and the user can configure $-Parameters as they choose. $-Parameters can be later changed by either:

1. Double-clicking the panel reference to bring up the “Reference Defining” popup
2. Changing the $-Parameters directly in the panel properties

Example

To continue with our evolving example panel from prior “Getting Started with WinCC OA” installments, let’s now assume that we now have three motors that we want to use with our TestPanel. With two additional motors, we must first add additional datapoints in Para to represent the new motors’ PLC tags. Simply add two new datapoints (“myMotor2” and “myMotor3”) underneath our “myDatapointType” datapoint type.

Now that we have our additional motors configured in Para, we’ll want to create three references of TestPanel in another parent panel. However, our current TestPanel is configured to work only with the “myMotor” datapoint.

To utilize our TestPanel as a re-usable reference, we must first incorporate flexibility and allow the panel to use a variety of datapoints, not just “myMotor”. How might we do this? With $-Parameters.

To implement a $-Parameter within our TestPanel script, we’ll assign the $-Parameter “$motorDpe” to the internal string variable “motorDpe” and then replace every occurrence of the text “myMotor” with the variable “motorDpe.” With this modification, we may pass in “myMotor”, “myMotor2”, and “myMotor3” into the TestPanel to substitute for the string “motorDpe.”

#uses "OpenLibrary/Enums/MotorStatusType"
#uses "ColorConst"

string motorDpe = $motorDpe;

//=============================== Panel initialization =========================================
initializePanel()
{
  //Whenever rSpeed or rMaxSpeed changes, call the function "onSpeedChange"
  dpConnect("onSpeedChange", motorDpe + ".rSpeed", motorDpe + ".rMaxSpeed");

  //Whenever iStatus changes, call the function "onStatusChange"
  dpConnect("onStatusChange", motorDpe + ".iStatus");

  //Set rectangle's label text to its motor dpe
  setValue("motorLabel", "text", motorDpe);
}


//=============================== Text Field Command =========================================
//Textbox is selected and user keys "Enter"
void textboxCmd()
{
  //Assign the textbox's text value to rMaxSpeed
  dpSet(motorDpe + ".rMaxSpeed", maxSpeedTextbox.text);
}


//=============================== On Speed / Max Speed Value Change =================================
void onSpeedChange(string speedDp, float speedValue, string maxSpeedDp, float maxSpeedValue)
{
  //Define the variable whose value will be assigned to iStatus
  int iStatusValue;

  //Determine what value to assign iStatusValue (and subsequently "myMotor.iStatus")
  switch (speedValue)
  {
    //If "myMotor.rSpeed" is 0, set iStatusValue to 0
    case 0:
      iStatusValue = (int)MotorStatusType::Stopped;
      break;

    //Otherwise, if "myMotor.rSpeed" > "myMotor.rMaxSpeed", set iStatusValue to Estop status int
    //           if not, set iStatusValue to Forward status int
    default:
      iStatusValue = ((speedValue >= maxSpeedValue) ? (int)MotorStatusType::Estop : (int)MotorStatusType::Forward);
      break;
  }

  //Assign iStatusValue's value to "myMotor.iStatus"
  dpSet(motorDpe + ".iStatus", iStatusValue);

  //Set the maxSpeedTextbox and speedTextbox's test to their respective values
  //NOTE: dpValToString ensures the units we assigned earlier in the series are displayed.
  //      Simply using <Textbox>.text = <speedValue> will work, but will not display appropriate units
  maxSpeedTextbox.text = dpValToString(motorDpe + ".rMaxSpeed", maxSpeedValue, true);
  speedTextbox.text = dpValToString(motorDpe + ".rSpeed", speedValue, true);
}

//=============================== On Status Change =========================================
void onStatusChange(string statusDp, int statusValue)
{
  //Define the variable whose value will be assigned to the rectangle's color property
  string rectangleColor;

  //Determine color to assign to rectangle based off iStatus
  if (statusValue == (int)MotorStatusType::Stopped)
  {
    rectangleColor = STOPPED_COLOR;
  }

  if (statusValue == (int)MotorStatusType::Estop)
  {
    rectangleColor = ESTOPPED_COLOR;
  }

  if (statusValue == (int)MotorStatusType::Forward)
  {
    rectangleColor = FORWARD_COLOR;
  }

  //Assign selected color to rectangle
  setValue("rectangle", "backCol", rectangleColor);
}

#uses "OpenLibrary/Enums/MotorStatusType"
#uses "ColorConst"

string motorDpe = $motorDpe;

//=============================== Panel initialization =========================================
initializePanel()
{
  //Whenever rSpeed or rMaxSpeed changes, call the function "onSpeedChange"
  dpConnect("onSpeedChange", motorDpe + ".rSpeed", motorDpe + ".rMaxSpeed");

  //Whenever iStatus changes, call the function "onStatusChange"
  dpConnect("onStatusChange", motorDpe + ".iStatus");

  //Set rectangle's label text to its motor dpe
  setValue("motorLabel", "text", motorDpe);
}


//=============================== Text Field Command =========================================
//Textbox is selected and user keys "Enter"
void textboxCmd()
{
  //Assign the textbox's text value to rMaxSpeed
  dpSet(motorDpe + ".rMaxSpeed", maxSpeedTextbox.text);
}


//=============================== On Speed / Max Speed Value Change =================================
void onSpeedChange(string speedDp, float speedValue, string maxSpeedDp, float maxSpeedValue)
{
  //Define the variable whose value will be assigned to iStatus
  int iStatusValue;

  //Determine what value to assign iStatusValue (and subsequently "myMotor.iStatus")
  switch (speedValue)
  {
    //If "myMotor.rSpeed" is 0, set iStatusValue to 0
    case 0:
      iStatusValue = (int)MotorStatusType::Stopped;
      break;

    //Otherwise, if "myMotor.rSpeed" > "myMotor.rMaxSpeed", set iStatusValue to Estop status int
    //           if not, set iStatusValue to Forward status int
    default:
      iStatusValue = ((speedValue >= maxSpeedValue) ? (int)MotorStatusType::Estop : (int)MotorStatusType::Forward);
      break;
  }

  //Assign iStatusValue's value to "myMotor.iStatus"
  dpSet(motorDpe + ".iStatus", iStatusValue);

  //Set the maxSpeedTextbox and speedTextbox's test to their respective values
  //NOTE: dpValToString ensures the units we assigned earlier in the series are displayed.
  //      Simply using <Textbox>.text = <speedValue> will work, but will not display appropriate units
  maxSpeedTextbox.text = dpValToString(motorDpe + ".rMaxSpeed", maxSpeedValue, true);
  speedTextbox.text = dpValToString(motorDpe + ".rSpeed", speedValue, true);
}

//=============================== On Status Change =========================================
void onStatusChange(string statusDp, int statusValue)
{
  //Define the variable whose value will be assigned to the rectangle's color property
  string rectangleColor;

  //Determine color to assign to rectangle based off iStatus
  if (statusValue == (int)MotorStatusType::Stopped)
  {
    rectangleColor = STOPPED_COLOR;
  }

  if (statusValue == (int)MotorStatusType::Estop)
  {
    rectangleColor = ESTOPPED_COLOR;
  }

  if (statusValue == (int)MotorStatusType::Forward)
  {
    rectangleColor = FORWARD_COLOR;
  }

  //Assign selected color to rectangle
  setValue("rectangle", "backCol", rectangleColor);
}

NOTE: $-Parameters can be interspersed throughout our code; wherever a $-Parameter is referenced, the value passed in from the parent panel will take its place. DMC’s best practices, however, entail using a $-Parameter only once by assigning an internal variable to the $-Parameter and then using said variable within the panel’s script. In the case a $-Parameter needs to have its name changed, the modification only needs to be made once in the panel code.

Now that our TestPanel is configured to accept a variety of datapoints (of type “myDatapointType”), we may now begin creating panel references.

1. Create a parent panel called “ParentPanel.”
2. Drag a “TestPanel” into the “ParentPanel” working space
3. Add the datapoint “myMotor” to the “$motorDpe” value field
   • This can be done in the reference panel’s “Reference defining” popup
   • Or in the reference panel’s Property editor
4. Repeat steps 2 and 3 for the datapoints “myMotor2” and “myMotor3.”

Or

Congratulations! You’ve created a parent panel with three reference panels. If any changes are made to TestPanel, those changes would propagate into the parent panels’ references. Let’s test this.

Since it’s not evident which panel reference refers to which motor, we’ll make a couple of modifications within TestPanel. We’ll first add a primitive text object over our rectangle (name ‘motorLabel’, set Foreground Color to ‘Base_White’, change the text to ‘Motor Dpe’, and center the text over the ‘rectangle’ object) to serve as a label.

Additionally, we’ll add a setValue command to the panel initialization in Scope Lib to populate the label with the correct motor dpe.

Upon opening ParentPanel (if ParentPanel is already open, close it so that the working space’s reference panels can be updated) and running QuickTest, you’ll notice the new panel titles are now labeled “myMotor”, “myMotor2”, and “myMotor3.”

Furthermore, you’ll notice that changing rSpeed and rMaxSpeed in each of the datapoints (myMotor, myMotor2, and myMotor3) all reflect on their appropriate panels.

Additional $-Parameter Features

Optional parameters

By default, $-Parameters are required to be passed down from parent panel to reference panel. When a reference panel is created, its dollar parameters will, by default, be self-defined.

If no alternative $-Parameter is provided, the panel in runtime will generate an error (assuming the parent panel does not become a reference panel itself).

However, if an underscore is placed directly after the “$”, the parameter then becomes optional. When a reference panel is created, its optional dollar parameters are not automatically defined.

Optional parameters are accessible in the “Reference defining” popup under the “optional” tab or along with other $-Parameters in the Property Editor.

Specifying $-Parameter Data Types

$-Parameters can be designated to have specific data types according to their names’ prefixes:

Specifying $-Parameter Parameter Types

Fun Fact of the Day: Clicking the ellipsis in the reference defining panel calls a popup that assists the user in a $-Parameter selection. This is only done, however, if a $-Parameter does not adhere to a data-type-specifying convention (and is therefore labeled as “[unknown]”). From this “Menu” popup, one can choose to open the “DP-Selector”, “DPE-Selector”, “Color-Selector”, “Panel-Selector”, “Font-Selector”, or “Keyword-Selector” (if applicable).

NOTE: The “DP-Selector” only allows the user to select the highest level of a datapoint structure while the “DPE-Selector” allows the user to select the datapoint or any of its respective elements.

Reference Defining Panel

DP-Selector

DPE-Selector

Color-Selector

Panel-Selector

Font-Selector

Similar to how the naming convention allows $-Parameters to be defined as specific datatypes, the naming convention also allows users to specify $-Parameters’ parameter types. If a $-Parameter contains the name “dp”, “dpe”, “color”, “panel”, or “font”, the ellipses click will bypass the “Menu” panel and navigate directly to the appropriate selector.

NOTE: If a user were to specify a data type and a parameter type for a specific $-Parameter, the parameter type would take precedence and the $-Parameter would be considered an “[unknown]” data type.

For example, “$sMyDpe” would be considered an unknown (as opposed to a string) and open the DPE-Selector.

NOTE 2: If a user has a lack of foresight and includes multiple parameter types in their $-Parameter name, then a selector will open in the following priority:
Dpe > dp > panel > color > font

For example, “$myColorDpe” would open the DPE-Selector as opposed to the Color-Selector.

Now that we’ve reviewed the wonders of panel embedding and started learning the magic of $-Parameters, it’s time to further our knowledge of panels. In the next edition of “Getting Started with WinCC OA”, we’ll dive into another form of panel references, Child Panels (i.e. Popups), and how $-Parameters are used in that context.

Topics to look forward to in this series: 

• Part 11: Panels | Child Panels (Popups)
• Part 12: Modules & Embedded Modules

Contact DMC to get started on your next WinCC project and learn more about our Siemens SIMATIC WinCC Programming as well as our WinCC Open Architecture Development.

The post Getting Started with WinCC OA: Part 10 – Panel Nesting and $-Parameters appeared first on DMC, Inc..

• Part 1: Creating and Opening a Project
• Part 2: Folder Structure and Gedi Layout
• Part 3: Panels | The Basics
• Part 4: Panel Scripting Environments and QuickTest
• Part 5: Scripting Syntax
• Part 6: Para Overview and Datapoint Creation
• Part 7: Interacting with Datapoints via Scripting
• Part 8: Libraries

In Part 9 of “Getting Started with WinCC OA,” we’ll look at the Color Database and the implementation of color-based concepts presented in “The High Performance HMI Handbook” by Bill R. Hollifield, Dana Oliver, Eddie Habibi, and Ian Nimmo.

What is a Color Database?

The color database is where project colors are defined and stored. Project colors can be separated into and organized via different databases. Recall the OA folder structure and panel view tree outlined in Part 2: Folder Structure and Gedi Layout, color databases are stored within the ColorDB folder and can be accessed in Gedi via the Color Database element in the Project View tree.

Creating a Database

To create a color database, simply right click the “Color Database” Project View tree element and select “Add New Color Database.” For our example, we’ll call this color database “Project Base.”

Creating a Color Database Color

To add a color, right-click the color database that will house said color and select “Add New Color.” For our example, we’ll create the following colors within the “Project Base” database:

If following along, feel free to adjust the colors’ RGB values as you see fit.

Creating Color Database Aliases

Programmers use aliases to identify color database colors under different names. Using aliases helps maintain color consistency throughout a project, makes code more readable, and prevents cluttering within color databases

DMC’s best practices involve creating a color database of base colors to serve as a project color foundation. All other color databases will consist of aliases of these base colors.

Before creating an alias, we’ll first create a new color database called “Device Status.” Within the “Devices Status” color database, we’ll create an alias called DeviceStatus_Estopped and assign it Base_Red.

In addition, we’ll create DeviceStatus_Stopped as Base_Blue and DeviceStatus_Running as Base_Green.

Now that we’ve created new device status colors let’s apply them to our example from Parts 7 and 8. In Part 7 – Interacting with Datapoints via Scripting, we created a simple rectangle (represents a motor device) and assigned it a “Red” background-color within its project properties. Now that we have designated status colors, let’s give it a DeviceStatus_Stopped default color.

In reality, this color will only be visible while editing in Gedi as the example code automatically assigns the rectangle a new color in runtime. Regardless, we’ll still apply the color.

Recall that in Part 08 – Libraries, we created a control file that defined a variety of color constants. Instead of defining the constants as primary OA colors “red,” “blue,” and “green,” we can re-define them as our newly created aliases in the “ColorConst.ctl” file.

The High Performance HMI

The High Performance HMI is a concept presented in “The High Performance HMI Handbook” by Bill R. Hollifield, Dana Oliver, Eddie Habibi, and Ian Nimmo. The book focuses on developing human-machine interfaces in a way that maximizes operators’ situational awareness and increases HMI functionality and efficiency. Though topics in the book stretch from ideal screen topology to control room distractions, I found it worthwhile to highlight some basic ideas on color selection in this blog post.

According to “The High Performance HMI Handbook”

• Color should be used to draw the operators’ attention and highlight abnormal situations
• Color blindness is a prevalent condition that must be taken into account when selecting colors. For those that are color blind, color combinations such as green + red and blue + purple are often hard to differentiate.

For example, consider the following color schemes in device objects in DMC’s WinCC OA Open Library:

The standard color scheme is generally what those unfamiliar with High Performance HMI concepts might consider ideal and preferable. However, note what the same layout looks like when passed through a color-blind simulator application:

Note that the standard “Active” and “Fault” states are nearly indistinguishable to those with deuteranopia (green-blindness). All High Performance HMI colors are easily differentiable. Also, the High Performance scheme uses color to draw an operator’s attention to a faulted state and leaves normal operation in greyscale colors.

Creating Alternative Color Schemes

Color schemes allow users to overwrite color definitions and allows for color transitioning. This can be helpful when shifting between “day” and “night” modes, for example. For the purposes of this tutorial, we’ll create a High Performance color scheme that that overwrites our DeviceStatus_Stopped and DeviceStatus_Forward aliases with alternative high performance colors.

To create a color scheme, right-click the Color Databases element and select “Add New Color Scheme Folder.” We’ll name this color scheme, “High Performance Colors.”

Within a color scheme folder, you can define colors and their respective color databases. Within the “High Performance Colors” color scheme folder, we’ll create a color database titled “DeviceStatus” and define aliases DeviceStatus_Stopped as Base_DarkGrey and DeviceStatus_Forward as Base_White.

Everything under the Color Databases element and not in a color scheme folder is considered the default color/database. When a color scheme is “Active,” any conflicting colors within the color scheme folder will overwrite its default color counterpart.

Since DeviceStatus_Running and DeviceStatus_Stopped are defined within the High Performance Colors, the Base_White and Base_DarkGrey will represent those color aliases respectively when the “High Performance Colors” are active. Base_Red will continue to represent the Device_Status_Estopped since there is no definition within the “High Performance Colors” scheme.

Activating Color Schemes

There are several ways of activating color schemes within a project:

Activate in Gedi
To activate a color scheme in Gedi, simply right click its respective folder and select “Activate Color Scheme.” To activate the default scheme, simply perform the same action but right-clicking on a default color. This is a good way of testing different color schemes during development.

Activate via Scripting

Color schemes can be altered during runtime by using the function

colorSetActiveScheme(<Color Scheme>)Show more lines

colorSetActiveScheme(<Color Scheme>)Show more lines

Where <Color Scheme> is a string of the folder name. To activate the default color scheme, simply use empty quotes. Enabling color schemes via scripting is ideal for switching between color schemes during runtime.

Activate via Config File

The config file will be covered more in-depth in subsequent “Getting Started with WinCC OA” installments. However, it’s important to note that a color scheme can be activated by implementing the following line within the [ui] section of the config file:

activeColorScheme = <Color Scheme>

activeColorScheme = <Color Scheme>

Where <Color Scheme> is a string of the folder name. Like activating color schemes via scripting, the default color scheme is represented with empty quotes. With that said, it is not necessary to activate the default color scheme via the config file since, as the default, it’s already active upon startup.

Activating color schemes via the config file is ideal if a project will use only one non-default color scheme.

Example Project Colors

Going back to the example project, we can run a quick test of our panel to view our new default colors. Since we’re working primarily in Gedi, we can activate the High Performance color scheme by right-clicking the “High Performance Colors” folder and activating the color scheme. Here’s how our rectangle’s color has changed over time:

_dpdoesnotexist

WinCC OA comes with an array of accessible and usable colors that can be found within the base OA project. While most colors aren’t important enough to know, the “_dpdoesnotexist” color bears heavy significance in the development and debugging. In default OA objects (and ideally any other user-generated content like DMC’s WinCC OA Open Library), the “_dpdoesnotexist” color will display if the object’s user-specified datapoint or datapoint element does not exist within the project.

Native OA Object in GEDINative OA Object with Invalid DPE in QuickTest

Now that we’ve covered colors and color databases, let’s jump back to panel development. In the next edition of “Getting Started with WinCC OA,” we’ll cover panel nesting and passing parameters from panel to reference panel using $-parameters.

Topics to look forward to in this series: 

• Part 10: Panels | Panel Nesting and $-Parameters
• Part 11: Panels | Child Panels (Popups)
• Part 12: Modules & Embedded Modules

Contact DMC to get started on your next WinCC project and learn more about our Siemens SIMATIC WinCC Programming as well as our WinCC Open Architecture Development.

The post Getting Started with WinCC OA: Part 9 – Color Database and High Performance Best Practices appeared first on DMC, Inc..

For some, this trip marked their ~32,767^th time rock climbing. For others, this DMC expedition served as the first opportunity to put their chalky hands to the rock walls and a chance to try something new.

“I had never done rock climbing as an adult before, but I have a lot of friends that love it and have it as a hobby. I took their word for it and gave it a shot. Despite having some sore arms the next day, it was such a cool, new experience for me! 10/10 would do it again!” – Elisha Harris

Throughout the evening, we partook in:

Bouldering:

Top-Roping:

Belaying (how’s that for trusting your coworkers?):

And having fun!

All-in-all, we had a blast and look forward to our next DMClimbing adventure!

DMC Rockers’ Testimony: 

 “This was my first activity fund event. Being new to the company, it was a cool way to meet some of my coworkers. I love climbing, and doing it with fun people makes it even better.” – Andrew Williams

“Jumping off the top of the wall is going against years of human survival instinct!” – Corey Zheng

Learn more about DMC’s Company Culture. 

The post DMC Chicago Hangs Out at the Rock Walls appeared first on DMC, Inc..

• Part 1: Creating and Opening a Project
• Part 2: Folder Structure and Gedi Layout
• Part 3: Panels | The Basics
• Part 4: Panel Scripting Environments and QuickTest
• Part 5: Scripting Syntax
• Part 6: Para Overview and Datapoint Creation
• Part 7: Interacting with Datapoints via Scripting

Now that we have a basic understanding of scripting and how to interact with datapoints, we’re ready to move beyond panel scripting environments and create globally accessible code. In Part 8 of “Getting Started with WinCC OA,” we’ll explore how we can use libraries to create globally accessible functions, enumerations, constants, etc.

What are Libraries?

Control libraries are files that hold code that may be accessed by other scripts within a project. Simply put, they hold globally usable code. One may ask, “Why would we want to use libraries?”

Libraries prevent developers from having to rewrite or copy/paste existing code, allow changes to be made quickly and efficiently, and ensure consistency within a project. Let’s jump back quickly to the example used in “Part 7: Interacting with Datapoints via Scripting.” Say we used the same enumeration “StatusType” in several panels in addition to the one we created.

Without libraries, we’d need to copy and paste this enumeration in all of our panels’ ScopeLibs for further use. If we wanted to alter the enumeration to:

We’d need to remember every instance of where this function was used, go back in the code, and modify StatusType appropriately. When the number of places we use StatusType increases, the more re-work would be needed to make the change.

How are Libraries Made?

To create a control library, simply right click “Libraries” in the project view tree and select “Add New CTRL Library.”

Anything created in the resulting .ctl file can be appropriately referenced throughout the program. To continue from Part 7’s example, we’ll generate two .ctl files: one for a global StatusType and another for device colors.

StatusType.ctl should contain:

ColorConst.ctl should have:

None of these libraries do anything, however, if they’re not implemented within a program.

How is Library Content Implemented?

Libraries are not initially accessible from a program’s script. The control library file must first be loaded into a project for it to be usable. To do so, you must implement the following line:

	#uses <.ctl file>

Once a control file is specified, a script may use any and all items within said .ctl file. To implement our control libraries within our example, we’ll modify our ScopeLib’s code as follows:

#uses "StatusType"
#uses "ColorConst"

//=============================== Panel initialization =========================================
initializePanel()
{
  //Whenever rSpeed or rMaxSpeed changes, call the function "onSpeedChange"
  dpConnect("onSpeedChange", "myMotor.rSpeed", "myMotor.rMaxSpeed");

  //Whenever iStatus changes, call the function "onStatusChange"
  dpConnect("onStatusChange", "myMotor.iStatus");
}


//=============================== Text Field Command =========================================
//Textbox is selected and user keys "Enter"
void textboxCmd()
{
  //Assign the textbox's text value to rMaxSpeed
  dpSet("myMotor.rMaxSpeed", maxSpeedTextbox.text);
}


//=============================== On Speed / Max Speed Value Change =================================
void onSpeedChange(string speedDp, float speedValue, string maxSpeedDp, float maxSpeedValue)
{
  //Define the variable whose value will be assigned to iStatus
  int iStatusValue;

  //Determine what value to assign iStatusValue (and subsequently "myMotor.iStatus")
  switch (speedValue)
  {
    //If "myMotor.rSpeed" is 0, set iStatusValue to 0
    case 0:
      iStatusValue = (int)StatusType::Stopped;
      break;

    //Otherwise, if "myMotor.rSpeed" > "myMotor.rMaxSpeed", set iStatusValue to Estop status int
    //           if not, set iStatusValue to Forward status int
    default:
      iStatusValue = (speedValue >= maxSpeedValue) ? (int)StatusType::Estop : (int)StatusType::Forward;
      break;
  }

  //Assign iStatusValue's value to "myMotor.iStatus"
  dpSet("myMotor.iStatus", iStatusValue);

  //Set the maxSpeedTextbox and speedTextbox's test to their respective values
  //NOTE: dpValToString ensures the units we assigned earlier in the series are displayed.
  //      Simply using <Textbox>.text = <speedValue> will work, but will not display appropriate units
  maxSpeedTextbox.text = dpValToString("myMotor.rMaxSpeed", maxSpeedValue, true);
  speedTextbox.text = dpValToString("myMotor.rSpeed", speedValue, true);
}

//=============================== On Status Change =========================================
void onStatusChange(string statusDp, int statusValue)
{
  //Define the variable whose value will be assigned to the rectangle's color property
  string rectangleColor;

  //Determine color to assign to rectangle based off iStatus
  if (statusValue == (int)StatusType::Stopped)
  {
    rectangleColor = STOPPED_COLOR;
  }

  if (statusValue == (int)StatusType::Estop)
  {
    rectangleColor = ESTOPPED_COLOR;
  }

  if (statusValue == (int)StatusType::Forward)
  {
    rectangleColor = FORWARD_COLOR;
  }

  //Assign selected color to rectangle
  setValue("rectangle", "backCol", rectangleColor);
}

#uses "StatusType"
#uses "ColorConst"

//=============================== Panel initialization =========================================
initializePanel()
{
  //Whenever rSpeed or rMaxSpeed changes, call the function "onSpeedChange"
  dpConnect("onSpeedChange", "myMotor.rSpeed", "myMotor.rMaxSpeed");

  //Whenever iStatus changes, call the function "onStatusChange"
  dpConnect("onStatusChange", "myMotor.iStatus");
}


//=============================== Text Field Command =========================================
//Textbox is selected and user keys "Enter"
void textboxCmd()
{
  //Assign the textbox's text value to rMaxSpeed
  dpSet("myMotor.rMaxSpeed", maxSpeedTextbox.text);
}


//=============================== On Speed / Max Speed Value Change =================================
void onSpeedChange(string speedDp, float speedValue, string maxSpeedDp, float maxSpeedValue)
{
  //Define the variable whose value will be assigned to iStatus
  int iStatusValue;

  //Determine what value to assign iStatusValue (and subsequently "myMotor.iStatus")
  switch (speedValue)
  {
    //If "myMotor.rSpeed" is 0, set iStatusValue to 0
    case 0:
      iStatusValue = (int)StatusType::Stopped;
      break;

    //Otherwise, if "myMotor.rSpeed" > "myMotor.rMaxSpeed", set iStatusValue to Estop status int
    //           if not, set iStatusValue to Forward status int
    default:
      iStatusValue = (speedValue >= maxSpeedValue) ? (int)StatusType::Estop : (int)StatusType::Forward;
      break;
  }

  //Assign iStatusValue's value to "myMotor.iStatus"
  dpSet("myMotor.iStatus", iStatusValue);

  //Set the maxSpeedTextbox and speedTextbox's test to their respective values
  //NOTE: dpValToString ensures the units we assigned earlier in the series are displayed.
  //      Simply using <Textbox>.text = <speedValue> will work, but will not display appropriate units
  maxSpeedTextbox.text = dpValToString("myMotor.rMaxSpeed", maxSpeedValue, true);
  speedTextbox.text = dpValToString("myMotor.rSpeed", speedValue, true);
}

//=============================== On Status Change =========================================
void onStatusChange(string statusDp, int statusValue)
{
  //Define the variable whose value will be assigned to the rectangle's color property
  string rectangleColor;

  //Determine color to assign to rectangle based off iStatus
  if (statusValue == (int)StatusType::Stopped)
  {
    rectangleColor = STOPPED_COLOR;
  }

  if (statusValue == (int)StatusType::Estop)
  {
    rectangleColor = ESTOPPED_COLOR;
  }

  if (statusValue == (int)StatusType::Forward)
  {
    rectangleColor = FORWARD_COLOR;
  }

  //Assign selected color to rectangle
  setValue("rectangle", "backCol", rectangleColor);
}

Note that:

• I added the #uses prompts
• I removed StatusType enum definition from ScopeLib (since it’s applied via library)
• I added color constants (also applied via library)

With the color constants and StatusType enum defined in libraries, other panels and scripts may use them at will.

Now that we have a solid understanding of how to make and implement control libraries, we’ll continue in our OA exploration by investigating color databases and learning how we can use them to create and use custom colors.

Topics to look forward to in this series: 

• Part 9: Color Database & High-Performance Best Practices
• Part 10: Panels | Panel Nesting and $-Parameters
• Part 11: Panels | Child Panels (Popups)
• Part 12: Modules & Embedded Modules

Contact DMC to get started on your next WinCC project and learn more about our Siemens SIMATIC WinCC Programming as well as our WinCC Open Architecture Development.

The post Getting Started with WinCC OA: Part 8 – Libraries appeared first on DMC, Inc..