The Siemens Open Library is a tool in helping industrial companies face the opportunities and challenges of modernization. DMC added HMI elements and faceplates for Siemens SIMATIC WinCC Unified, an integrated visualization system, to the code library to help users improve the digitalization and transparency of their industrial machines and operations. 

“From the start, our goal has been to help standardize and accelerate Siemens PLC and HMI development among integrators, OEMs, and end-users when modernizing their automation and control systems and solutions,” said Nick Shea, DMC Senior Director, Automation. 

Device Faceplates in the Siemens Open Library

What is WinCC Unified? 

WinCC Unified is a visualization system that links data from production’s operational technology (OT) with IT enterprise intelligence systems and other parallel PC applications running at the control system layer. This data is displayed in a holistic operating concept offering transparency across operations. 

DMC decided to upgrade the Siemens Open Library after Siemens released its SIMATIC WinCC Unified System in 2022 as part of TIA Portal v16. The library is now updated for TIA Portal V18 and V19. 

“With WinCC Unified’s feature-rich Javascript functions, the Library is much more usable for future-proofing PLC and HMI automation capabilities,” said Carl Remler, DMC Senior Project Engineer. “It also makes cross-platform development much easier and faster by enabling the programming of lightweight and maintenance-free HTML5 web clients.” 

According to Remler, “WinCC Unified enables a near object-oriented engineering approach to designing and configuring production lines and processes. This means engineers can define the characteristics of plant assets just once and reuse them as instances in hierarchically structured operations.” 

WinCC Unified folder in the Siemens Open Library

Advantages of WinCC in the Siemens Open Library 

SIMATIC WinCC Unified brings three key advantages to the Siemens Open Library. 

• Single visualization system  
  Featuring open interfaces with continuous scalability, WinCC Unified can scale for all use cases. It can provide HMIs for control panels on machines or for complex solutions where PCs communicate via API with third-party OT and IT systems. 

• Future-proofing applications 
  Whether they’re used onsite or remotely, WinCC Unified offers functionality across all HMI platforms. Using the latest technology like HTML5, JavaScript and SVG, WinCC Unified powers HMI platforms from tablets to machine control panels to system PCs. 

• Consistent usability  
  WinCC Unified delivers faster and easier training for engineers and operators by using the same controls across all platforms. This simplifies engineering and ensures the best user experience. 

Pump, Motor, and Tank Graphics in the Siemens Open Library

Other benefits that DMC has found using WinCC Unified include easier script debugging and modernized out-of-the-box styles. Additionally, the “openFaceplateInPopup” function automatically creates faceplate popups during runtime to speed up development and improve project organization.  

 
Left: hopper level bar; Right: VFD pop-up

Opening the Siemens Open Library in TIA Portal V19

DMC looks forward to more opportunities help users modernize their industrial plants and operations using the Siemens Open Library and WinCC Unified. According to Shea, “With all the many advanced capabilities WinCC Unified provides DMC, we can expand our creative horizons on keeping our customers competitive and profitable today and futureproofing them with the flexibility and scalability they need for [tomorrow].” 

The post DMC Updates Siemens Open Library with SIMATIC WinCC Unified appeared first on DMC, Inc..

The DMC Drinkbot is a robotic bartender powered by Siemens automation hardware. It was originally created in the DMC Denver office in 2016 using a Siemens S7-1200 PLC interfaced by a 7″ SIMATIC Comfort Panel.

Eight years after creation as Siemens has begun to phase out their COMFORT HMI Panels, DMC wanted to give Drinkbot an HMI upgrade. We received a new MTP700 Unified Comfort Panel that runs TIA Portal V19 WinCC Unified programs to show off the latest and greatest of Siemens HMI technology. This guide will walk through the steps taken to upgrade Drinkbot and the new features developed.

Background and Operational Overview

The DMC Drinkbot uses PROFINET communication for a Siemens G120 VFD drive controlled by an S7-1200 PLC. The user can choose drinks on a SIMATIC key panel or the MTP700 Unified Comfort Panel HMI that this blog focuses on. The user can choose between 44 standard drink recipes made from 8 bottles of alcohol and 6 mixers. There is also a custom drink option where the user can select any ingredient available based on the current configuration of the Drinkbot. 

Without replacing any bottles on the machine, the ability to make alcoholic drinks can be toggled. If the Drinkbot is taken to an event where alcohol is not permitted, the bottles may also be swapped out for flavored syrups and soda water to make “Italian sodas”. The Italian soda switch overrides the selectable recipes limiting the machine to the new available ingredients. The settings screen for these configurations is accessible by selecting the DMC logo in the upper left corner where the user can view alarms and diagnostics and change the machine mode. The motion axis of the Drinkbot can also be manually operated for demonstration and debugging purposes.

For a detailed history of the development of Drinkbot, refer to the following two blogposts.

DMC Engineers Serve up a Siemens S7 Powered DrinkBot

Adding Siemens MindSphere Tracking to the DMC DrinkBot

Data 2 Unified

About half of the work for creating the Unified program was accomplished using the Data2Unified tool by Siemens. This tool does a great job taking an older Comfort program and converting it to Unified, maintaining the basic layout and functionality of most HMI Elements and Controls. For some deprecated elements, the tool will even generate custom VBA scripting to maintain original functionality.

There are current limitations to this tool as the conversion will notably not create alarm lists, faceplates, and navigation elements. Additionally, due to WinCC Unified’s aspect flexibility, it is typically worth touching up the screens’ layout and aesthetics. The custom scripting that is auto-generated may also need to be redone as more efficient element functions can be created manually without scripts. Typically, the automatically generated scripts will function as intended, but the script will be written in unconventional and overcomplicated language. Double-checking these scripts and replacing them with standard functions where applicable is good practice.

After running the conversion, most of the Drinkbot settings screens were recreated to match the previous comfort program to maximize the ease of configuring the system during events. The cleaning sequence screens that use basic elements were converted seamlessly into Unified. Settings screens, like the alarms and diagnostics, were easily replaced with drop-in standard Siemens resources.

The bulk of the work left out by the tool was completed when modernizing the faceplates for drink selection and the recipe management system talked about in the following section.  

Recipe Conversion

In the Comfort program, there was a built-in recipe management feature that the developer could create their own data type and store recipes locally on the HMI panel to be written onto the PLC when selected. In the Drinkbot Comfort HMI the recipe list included 44 drinks detailing their ingredients and quantities.

This recipe feature was a convenient way to store information and access data to be written into the instructions of the PLC. In WinCC Unified, this feature was removed, so this storage was recreated using a user-defined type and a data block on the PLC.

The dbHMI data block stores all of the original recipe data using integers to signify ingredient quantities and a single string for the name of the recipe. Memory on the PLC is conserved by these simple UDTs, provided that the bottle setup in the Drinkbot is always the same. For simplicity, to set up the Drinkbot, the user consults a printout that lists all of the ingredient bottle positions. The string and 18 integers are then fed to the HMI through a multiplexed array 11 recipes at a time.

The 11 recipes are selected to be read based on the page of the HMI drink list the user is currently reading. The last display recipe on the page is number 12 that is left intentionally blank. A custom drink faceplate is opened when the custom button is pressed that displays all possible ingredients in the Drinkbot. The user can select how many of each ingredient to make their drink based on if alcohol is toggled on or the Drinkbot is displaying Italian Sodas. Once completed the ‘Make Drink’ button populates the display recipe 12 and once the Drinkbot completes the cycle the recipe is cleared.

To access standard drinks that access one of the stored recipes, 11 faceplate buttons are displayed on each page. These simple faceplates display the drink name based on page number and intake the recipe parameters once selected. They serve as an in between display button to open a nested faceplate that will display the selected drink in detail. The nested standard drink faceplate used in reading and writing recipe data is talked about in the next section.

Faceplates and Scripting

In the Comfort HMI, having a local way to manage the recipes within the HMI made development simpler as a single popup recipe screen could read the ingredients for each drink and display all possible options at once in a matrix.

The Drinkbot is intended to be used at live events in a fast paced setting so for the WinCC update, the drink recipe popup should prioritize readability and information efficiency. The new Unified program uses a standard drink faceplate that only displays ingredients used in a particular drink recipe.

The maximum ingredient amount in the original 44 drinks was 3 alcohols and 3 mixers. Custom scripting is used to take the recipe fed into the faceplate and populate the drink name plus the ingredients with their amounts. The script takes in the name and amount of each drink in ounces and automatically fills out each box for how many ingredients exist in each recipe. The user then has controls to make the drink and stop the process midway if needed.

For taking Drinkbot to events where alcohol is not an option, the machine can also be configured to dispense “Italian sodas” using soda water and flavored syrup. Selecting this mode locks the display page to an Italian soda mode and makes the button faceplates open a nested Italian soda faceplate. All Italian soda recipes only include up to two syrups and eight ounces of soda so the faceplate is simplified and resized.

For information on how to create a faceplate in WinCC unified, refer to the guide here: Creating Faceplates in WinCC Unified

Conclusion

The updated HMI program improves the usability and functionality of the COMFORT version. The custom scripted nested faceplates using the new recipe storage system in Unified make it easier to order a drink. To celebrate the completion of the WinCC Unified upgrade the DMC Chicago office had a happy hour party to have the Drinkbot make cocktails and entertain.

The post DMC’s Drinkbot Gets an HMI Upgrade to WinCC Unified appeared first on DMC, Inc..

The Simatic Step 7 manager uses the S7ONLINE access point for communication on the PC/PG interface. By default, the access path on S7ONLINE is set to none as simulating a WinCC HMI program will run disconnected of the PLC program through Simatic manager. The HMI in this state will not display tags read from the PLC but will use HMI local tags and should be fully navigable.

Connection Parameters

The easiest tool to use for establishing a simulator connection is the Siemens Communication Settings tool located in the control panel. Opening the tool will provide you with all possible connection modules on the computer as well as their respective parameters and diagnostics tools. From the address menu you can configure your IP address in the network connections menu of your PC.

To establish simulator-hardware connection, open the Access points menu. Select S7ONLINE and open the dropdown arrow. From here you can select the interface parameter which should match the same pathway that the PC uses to communicate with the hardware. The module property should auto populate and match the network connection name you configured.

In older versions of TIA Portal there is an interface configuration tool found in the Windows control panel named Set PG/PC Interface. From here, you can set the same pathway that will enable communication between the simulator and PLC.

After opening the tool, navigate to the Access path tab and select S7ONLINE as the access point. In the box below you will see all available interfaces for the path to take. Select the module in the list that matches the communication method you are using to talk to your hardware.

After selecting the correct module, you can close the tool and launch your WinCC simulation from Simatic Manager or TIA Portal. Provided that you are in contact, the S7ONLINE point should update your simulation with real data coming from the PLC.

Troubleshooting

If the Set PC/PG tool opens but does not display the S7ONLINE access point, it may be resolved by downloading a Siemens PC_Identifier hotfix support package linked below.

SIMATIC S7-PLCSIM Advanced V4.0

Troubleshooting the PLC connection can follow the same path as a typical process to go online with hardware. Ensure that you have a stable ethernet connection to the PLC you are attempting to communicate with. On the S7ONLINE path that you configured, note the module name that auto populated when the interface parameter was assigned. In your Windows taskbar search “view network connections.” Then, in this menu locate the ethernet driver that has the same module name as on the S7ONLINE path you are trying to use. In the popup window, go to properties then IPv4 and assign your own IP address on the same subnet and mask as the desired PLC. Once complete you should be able to ping the IP of your PLC from the command prompt.

If the simulated instance of your HMI still does not communicate with the PLC, stop the simulation and verify that the PC/PG interface selected when trying to go online with the PLC is the same as configured in either of the tools. Redownloading the program and verifying run mode is active may also assist with troubleshooting measures.

The post Simulating Siemens WinCC Unified HMI with Real PLC Data 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..

• 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..

• 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

Now that we have a solid understanding of datapoints and basic scripting, it’s time to combine the two! In Part 7 of the “Getting Started with WinCC OA,” we’ll investigate utilizing and manipulating datapoints within our OA scripts.

Referencing A Datapoint Element

A datapoint element is referenced by: <parent dp(s)>.<dpe>

For example, the elements of the dp “myMotor” are given by:

• “myMotor.iStatus”
• “myMotor.rSpeed”
• “myMotor.rMaxSpeed”

Using Datapoint Values within Scripts

Using scripts, we can link items in our panels to the datapoints that live in the db folder. The fundamental functions utilized in datapoint-scripting interaction include:

• dpGet()
• dpSet()
• dpConnect()

dpGet()

dpGet() is used to assign a datapoint element’s value to an existing script variable and takes the form: dpGet(<dpe>, <variable>);

With this dpGet, the variable iStatus will take on the value of myMotor.iStatus.

dpSet()

dpSet() is used to assign a value or a script variable’s value to a datapoint value and takes the form: dpSet(<dpe>, <value>);

With this dpSet, the dpe value of myMotor.iStatus will be set to 1.

dpConnect()

dpConnect() is used to call a function whenever a specified dp value changes. It takes the form:
dpConnect(string <callback function>, string <dpe>)

The callback function of a dpConnect must be defined in a specific manner:
<returnType> <callbackFunction>(string <dpe>, <type> <dpeValue>)

With this dpConnect, the function “onStatusChange” will execute when the value of myMotor. iStatus changes. When “onStatusChange” executes, the function will have the string “myMotor.iStatus” (given by the variable statusDp) and the value of myMotor. iStatus (given by the variable statusValue) at its disposal.

Example

Setting Up the Panel

Let’s revisit our lovely red/green square example and pair it with our newly-created datapoints! Our example will include the following three main objects and their respective behavioral objectives:

• Rectangle (i.e. our motor device icon)
  • Color is blue (stopped color) when rSpeed is 0
  • Color is green (forward color) when 0 < rSpeed < rMaxSpeed
  • Color is red (errored color) when rSpeed > rMaxSpeed
• Speed textbox
  • Displays rSpeed
• Max speed textbox
  • Displays rMaxSpeed
  • User can set rMaxSpeed value

We’ll start out by removing the previously-used buttons and adding in some primitive text, a label (used for value display), and text field (used for value display and modification).

Writing the Script

1. Ensure the panel’s “Initialize” event still has the following code:

   
   	main()
   {
     initializePanel();
   }
   

2. Insert the following code within maxSpeedTextbox’s “Command” event:

   
   	main()
   {
     textboxCmd();
   }
   

3. Add the following script to the panel’s “ScopeLib”:

   
   enum StatusType
   {
     Stopped = 0,
     Estop   = 1,
     Forward = 2
   };
   
   //=============================== 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 1
       //           if not, set iStatusValue to 2
       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 = "blue";
     }
   
     if (statusValue == (int)StatusType::Estop)
     {
       rectangleColor = "red";
     }
   
     if (statusValue == (int)StatusType::Forward)
     {
       rectangleColor = "green";
     }
   
     //Assign selected color to rectangle
     setValue("rectangle", "backCol", rectangleColor);
   }
   

4. Be sure to review and understand the example script

Running the Example Code

Run the panel in QuickTest Module and open/view the “myMotor” datapoint in Para. Upon modifying the Motor Speed Limit textbox and pressing 'Enter' on the keyboard, we can see the rMaxSpeed value change in Para.

Upon modifying rSpeed in Para (simulating a linked PLC tag change), we can see the rectangle’s color change from green as 0 < rSpeed < rMaxSpeed and then to red as rSpeed > rMaxSpeed:

Now that we have a basic understanding of scripting and how to interact with datapoints, we’re ready to expand our horizons beyond the boundaries of panel scripting environments and write code that is accessible globally in our OA program.

Topics to look forward to in this series: 

• Part 8: Libraries
• 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
• 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 7 – Interacting with Datapoints via Scripting appeared first on DMC, Inc..

Creating an Alarm

The first thing we need to do is create an alarm in WinCC. This is done through the “HMI Alarms” editor in TIA Portal. WinCC accesses all alarms by specifying a bit address in an HMI tag. This means you can group alarms in a couple of ways:

1. Add all alarms to an unoptimized data block as Booleans, then create a single HMI tag that is a word array with the same length as the block

Data block – Unoptimized 

HMI tag – this is an array of word with the appropriate size

Alarms – this is a link to the correct address of the relevant alarm

2. Group alarms into other data types, such as Word, DWord, Dint, etc.

DMC developed the Siemens Open Library, which has a function that automatically will combine 16 bits into a word

Move alarms into the bits of the alarm word

Each alarm corresponds to a bit in the word

Option one can be effective when you’re creating alarms for a large number of devices. The Siemens Open Library includes a windows application that will automatically generate a list of alarms from an unoptimized DB that can be directly imported into the alarm editor. This eliminates the hassle of having to create each of the alarms individually. Option two can be useful when you want to group alarms by device or subsystem. Each word can correspond to a specific device, which can be useful for checking device state on the PLC or displaying it on the HMI.

Local Acknowledgement on HMI

If you do no other configuration, the default acknowledgment setup is that all information about alarm state/acknowledgment is stored locally on the HMI. There are a few possible states for an alarm:

1. Incoming
   • An alarm condition is present; no acknowledgement has occurred
2. Incoming/Acknowledged
   • An alarm condition is present; acknowledgment has occurred
3. Incoming/Outgoing
   • Alarm condition was present, then went away before the alarm was acknowledged

Alarm display colors

Using the Alarms group tab of the editor, you can customize colors and display information for each of these acknowledgment states. Important note: you must enable colors in runtime settings or they will not be displayed.

Alarm Groups

By default, each alarm must be acknowledged individually. To change this, assign the alarms to groups in the alarm editor. Acknowledging one alarm in the group will acknowledge all the other alarms in that group as well.

Acknowledgment Button

There are two ways to acknowledge alarms. The first is using the button built into the alarm viewer. The other way is by configuring a custom button with the “AlarmViewAcknoweldgeAlarm” event.

HMI Acknowledgement Bit – Pass Acknowledgment Information from HMI to PLC

The HMI acknowledgment word is used to pass the acknowledgment status of an alarm from the HMI to the PLC. It must be a bit in a tag that is different than the alarm’s trigger tag. When acknowledgment of the alarm occurs on the HMI, the bit on the PLC is set to one. It will stay high until the alarm condition goes away, then occurs again. A diagram displays this below:

This bit is useful if you want to use the acknowledgment status as a pre-requisite for clearing the alarm condition on the PLC.

Multiple HMI Considerations

If multiple HMIs are part of the project, and each has a separate alarm viewer, any of the HMIs can acknowledge the alarm and set the HMI Acknowledgment bit. However, this information is stored locally on each HMI – the acknowledgement is not passed to the other HMIs. This disparity in information means that if one HMI acknowledges an alarm, it will still display as unacknowledged on a different HMI until this is also acknowledged there.

PLC Acknowledgment Bit – Pass Acknowledgement Information from PLC to HMI

The PLC acknowledgment bit is used to acknowledge alarms by passing down a bit from the PLC. When you set the bit on the PLC, the acknowledgement status of the associated alarm is updated on the HMI. This is useful as it allows multiple HMIs to keep their alarm acknowledgments in sync. A single PLC tag/bit is used as the PLC acknowledgement bit on all the HMIs, so each of them receives acknowledgements in sync.

One disadvantage of this approach is that it makes individual alarm acknowledgment, that is the ability to choose which alarm is going to be acknowledged by highlighting it in the alarm viewer, more difficult. When using the built-in acknowledgment in the alarm viewer (as you must with the HMI ack bit), a user can highlight/select a specific alarm to acknowledge.

However, there is no way to tell the PLC which alarm is currently highlighted, which prevents individual acknowledgement via PLC. Generally, when using this acknowledgment scheme, we have used a global alarm acknowledge button that automatically acknowledges all available alarms. Alternatively, we’ve grouped the alarms by system, and had a separate acknowledgement button for each system.

Important note: the acknowledgment bit must stay high long enough for the HMI to see it. We will normally pulse it on for a short duration (e.g. 1 second if the HMI tag update rate is 1s). This ensures each of the HMIs has time to see the tag’s value change.

The PLC acknowledgment bit is required to be in the same tag as the actual alarm bit. We have a couple of approaches to get around handle this:

Approach 1: Unoptimized db with Structs

The first way is to create an unoptimized DB with all alarm conditions at the top, and an identical structure at the bottom for alarm acknowledgment.

You can then access this DB as an array of words on the HMI, as discussed above. To configure the acknowledgment, use the bit in the first structure as the alarm bit, and the bit in the second structure as the plc acknowledgment bit. Then, set the plc acknowledgment bit high on the PLC to globally acknowledge the alarm on all HMIs.

Approach 2: Alarm Word

Another approach is to use Words for your alarms and keep them in a normal db. In this case, we generally group alarms by system or device, and use the first half of the word for the alarm conditions and the second half of the word for acknowledgments:

Overall, WinCC Comfort and Advanced give you several options for alarm acknowledgment. I hope this blog helps you implement it in your project!

Learn more about DMC’s WinCC Expertise and contact us today to get started on your next project.

The post Alarm Acknowledgment in WinCC Comfort and Advanced 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

db Folder Recap

Before we dive into Para, let’s review the db folder. In Part 2 of the “Getting Started with WinCC OA” series, we described the db folder as:

“The db folder contains all of OA’s user-defined datapoints and internally-used datapoints. These datapoints, analogous with PLC “tags,” hold and retain values that can be used by OA as well as connected PLCs. The user interface for these datapoints is called ‘Para’.”

What is Para?

Para is a graphical interface in Gedi used to view, create, and edit datapoint types, datapoints, and datapoint elements that are stored in the db folder. “What are datapoint types, datapoints, and datapoint elements?” you may ask.

• Datapoint type (dpt): A datapoint type is a defined structure consisting of variable types, substructures, and/or other data point types.
• Datapoint (dp): Data points are instances of a specified data point type. These data points physically hold the information outlined by their respective types.
• Datapoint element (dpe): Data point elements are the components of a specific data point. Data point elements and data points are fairly synonymous and can often be used interchangeably.

If this only makes partial sense, fear not. Things will become more clear as we walk through the following example:

Creating a Datapoint Type

1. To access Para, simply click the “Para” icon located within the project toolbar.

   

   

2. To create a data point type, right-click the Para Tree and select “Create datapoint type.”
   

   

3. The first “folder” structure in the Dp-Type Editor will be the name of the datapoint type, so name it accordingly.
4. To add elements to the data point type, right-click the dpt and select “Add node.”
   

   

5. Added nodes, by default, take the form of a structure. By right-clicking on a node and hovering over “Element – Type”, the user can configure each node to take on a desired variable type or even another datapoint type.

   

6. Through adding, renaming, and re-typing nodes, the following datapoint type can be configured:

   

We’ve successfully made a datapoint type! However, this structure doesn’t physically exist as a usable entity to store data. For that, we must create a datapoint.

Creating a Datapoint

1. To create a datapoint, simply right-click the datapoint type and select “Create datapoint”
   

   

2. Once named (our example names the datapoint “myMotor”), a new datapoint will appear underneath its respective datapoint type.
   Note that the datapoint contains all the elements defined in the datapoint type. These elements of a specific datapoint are called datapoint elements.

   

3. To manipulate a datapoint element’s value, simply click on the dpe, change its “Original value”, and click “Apply”.

   

Datapoint Configuration

Once created, datapoints and their respective elements can be configured to have specific user-defined properties such as units, ranges, and descriptions, addresses, trending archives, etc. To get started with OA, most of these configurations will not be covered. However, it’s beneficial to note their existence and how to change datapoint properties. For this blog series, we’ll look simply at unit configuration as a relevant example.

1. Under rSpeed’s dropdown, click “_common”
2. Under the “Unit” field, type in “rpm” and click “Apply”
3. Repeat for rMaxSpeed

NOTE: The underscore in “_common” or any other config/datapoint signifies that the item is an internal, non-user-defined datapoint.

WinCC OA Import Tag Tool

For WinCC OA projects that communicate with and use tags of PLCs, it becomes extremely tedious to create, edit, and link OA tags in the manner outlined above. Luckily, DMC has created a WinCC OA Import Tool that aids in importing tags from a TIA Portal project into WinCC OA. Find more info on it in our Siemens Open Library.

Now that we have a few datapoints configured, it’s time to utilize and manipulate them within our scripts! We’ll explore interacting with datapoints in the next installment of “Getting Started with WinCC OA.”

Topics to look forward to in this series: 

• 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)
• 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 6 – Para Overview and Datapoint Creation 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

In Part 5 of the “Getting Started with WinCC OA,” we’ll investigate the basics of OA’s scripting syntax. Once scripting syntax is understood, we can begin programming and adding functionality to our panels.

The Basics

• Every executable statement must end with a semicolon;
• // Use two forward slashes to comment out the remaining portion of a line
• Ctrl + D will comment out a line of code
• Ctrl + Shift + D will un-comment out a line of code
• Ctrl + E will open all of a selected panel’s scripts

Variables

OA supports many types of variables. The most used of which are:

Variable definitions take the form of:

<Type> <variableName>;

<Type> <variableName>;

Variables can be given initial values:

<Type> <variableName> = <intialValue>;

<Type> <variableName> = <intialValue>;

Multiple variables can be defined for a single type:

<Type> <variable1Name>, <variable2Name>, …;

<Type> <variable1Name>, <variable2Name>, …;

Variables must be defined before use, but can be so:

• At the beginning of a script
• Within a function
• Within a statement
• Within a function’s parameter structure

Best practice tip: Variable names should utilize camelCase or PascalCase and clearly indicate the variable’s function.

Casting
Casting is a way of interpreting a variable or value as an alternate type. This is done simply by preceding the target variable with “(<target type>)”. Casting is especially helpful with enumerations (which will be discussed later in this blog post).

Constants
Constants are defined in a manner similar to that of variables. However, by designating something as a constant, OA ensures that the value cannot be modified within a script. To designate a variable as a constant, simply place “const” before the type name.

Note: DMC’s best practice standards include capitalizing all constants.

Functions

Functions take the following form:

<returnType> <functionName>(<parameterType> <parameter>, ...)
{
    // Function content

    return <returnedItem>;
    // Required unless the return type is "void"
}

<returnType> <functionName>(<parameterType> <parameter>, ...)
{
    // Function content

    return <returnedItem>;
    // Required unless the return type is "void"
}

Note: returnType takes the form of any variable type or is “void”

Logic Operators
The following operators can be used in WinCC OA scripting:

Statements

WinCC utilizes the traditional of IF, ELSE, FOR, WHILE, and SWITCH statements as follows:

IF and ELSE statements:

 if(<Boolean condition>)
{
    <code>;
}
else
{
    <code>;
}

 if(<Boolean condition>)
{
    <code>;
}
else
{
    <code>;
}

FOR Loop:

for(<initialization of condition>; <Boolean testing condition>; <target variable modification>)
{
    <code>;
}

for(<initialization of condition>; <Boolean testing condition>; <target variable modification>)
{
    <code>;
}

WHILE Loop:

while(<Boolean condition>)
{
    <code>;
}

while(<Boolean condition>)
{
    <code>;
}

SWITCH Statement

switch(<target variable>)
{
    case <value 1>:
        <code>
        break;
    •••
    case <value n>:
        <code>
        break;
}

switch(<target variable>)
{
    case <value 1>:
        <code>
        break;
    •••
    case <value n>:
        <code>
        break;
}

Bonus Round: Ternary Statements

Ternary statements are condensed ways of writing simple if-else statements. They take the form:

<conditional statement> ? <value returned if true> : <value returned if false> 

<conditional statement> ? <value returned if true> : <value returned if false> 

Enumerations
Enumerations should be used to make code easier to interpret. For example, say there exists an integer variable, called iStatus, that indicates the condition of a motor where:

• 0 = stopped
• 1 = Error
• 2 = Running Forward

Say we want the rectangle from our prior example (representing the motor) to change color based on the iStatus variable. A series of IF statements could be written:

The program will work as expected, setting the rectangle’s background color to either grey, red, or white depending on the iStatus value. But someone troubleshooting or reviewing the code may be slowed as the code isn’t explicit as to what each iStatus case represents. This is where enumerations come in.

The enumeration “StatusType” has been implemented to make the code more explicit. Note that the enumeration has been cast as an integer to ensure that iStatus is given an integer to which it can compare.

Even further, constants have also been utilized for redundant clarity and (for reasons we’ll discuss later in this series) consistency.

What would even improve the code further? If you guessed “switch statement”, you’d be correct. While, in theory, this would be true, an unfortunate “feature” of WinCC OA is that its switch statements can’t handle casting. So while the following code would be optimal, saving and implementing it is not possible.

Now that the basics of scripting syntax have been covered, we’re ready to progress to the next aspect of scripting in WinCC OA: Para. In the next installment of “Getting Started with WinCC OA”, we’ll investigate the Para tool, OA tags, and how to interact with said tags.

Topics to look forward to in this series: 

• 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)
• 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 5 – Scripting Syntax appeared first on DMC, Inc..