Prerequisites 

1. TwinCAT XAE installed 
2. TwinCAT HMI installed 
3. PLC Project built and running (see bonus information for the PLC Code used in this example)

Project Setup

Creating the Project

With the prerequisites checked off, we can start the basic project setup for the HMI. Begin by right-clicking the solution in the Solution Explorer project tree and selecting Add > New Project. When the Add New Project window launches, navigate to TwinCAT HMI > TwinCAT HMI Project and name it whatever you like.

Linking Tags 

The first step in setting up a TwinCAT HMI project is linking PLC symbols to the user interface. This is done by exposing symbols to the TwinCAT HMI Server and binding them directly to HMI control properties.

Navigate to TwinCAT HMI > Windows >  TwinCAT HMI Configuration.

From TwinCAT HMI Configuration, navigate to All symbols > ADS > PLC, and wherever you have your variables defined, in my case ‘MAIN’.

Note: If ADS is not appearing, check your ADS Route (review the bonus information to learn how). 

From here, you can right-click on a variable and hit ‘Map Symbol’. You can also simply double-click on a symbol to map it. We have now successfully pulled the PLC data into the HMI Server.

Now, we can bind these tags to controls in the HMI screen. Navigate to ‘Desktop.view’. This is the main screen on which we will develop.

Creating Controls 

On the right pane, we have properties and the toolbox. These are used to add and edit controls within the project. We’ll start by dragging a Button into the project.

After your component is added, you can then select it to edit the Properties tab. For a basic button, we will want to create a data binding for the state symbol. Click the square to the right of the text field to link tags and select ‘Create data binding’.

This opens the symbol browser where you can select mapped PLC variables. On my screen, some variable groups include ‘ADS’, ‘PLC1’, ‘Global_Version’, and ‘MAIN’. Within the ‘MAIN’ category, we’ll select the bRun variable. It is worth noting that you can also map symbols from this screen using the same method as in HMI configuration.

You should now see the name for that symbol populated in the ‘StateSymbol’ box. You can also hover over property names to see a description of what they do. Now, we will drag in an Ellipse to show how the Events tab works.

With your ellipse selected, navigate over to the Events tab indicated by the lightning bolt symbol. From here, you can see that there are many built-in events to configure, like .onMouseDoubleClick, .onMouseEnter, .onMouseLeave, etc. You also have the option to configure a custom event.

Click the small square next to the Custom field to map a symbol to this control. In our case, we will select ‘bState’. Once that symbol is mapped, click the pencil icon to open and edit the custom event associated with the control.

In the Events tab, you will see a drag-and-drop interface that allows you to define logic for the controller’s behavior. This visual workflow makes it easy to configure interactions without writing traditional code. For this example, we will use a Condition block. Drag the condition into the steps section, then begin populating the auto-generated fields.

Here, we want to check whether the boolean variable bRun is set to ‘True’. If the condition evaluates to true, we will update the ellipse’s appearance to indicate an active state. To do this, drag the FillColor property into both the ‘then’ and ‘else’ branches. Set the ‘then’ color to green to represent a running state, and the ‘else’ color to grey to indicate that the system is not running.

Testing in Live View

After configuring this logic, it’s also important to establish your screen’s behavior. Return to the Desktop.View, where you will see a set of controls on the right-hand side. Click the ‘L’ button to launch the live view.

As you interact with the interface, observe the ellipse once again. When the button is pressed and held, the condition should evaluate to true, and the circle should toggle from red to green in real time. This confirms that your event logic is working as expected and that the control is properly responding to changes in the mapped variable.

User Controls 

As your HMI projects grow in size and complexity, maintaining reusability and consistency becomes increasingly important. TwinCAT HMI addresses this need through User Controls, which are reusable templates that combine multiple HMI elements into configurable, modular components.

To get started, create a new folder in your project called ‘UserControls’. This helps keep your project organized as your library of reusable components expands. Within this folder, add a new item and select ‘User Control’. From here, you can begin building a custom control that can be reused across screens, reducing development time and ensuring a consistent user interface.

Once again, on the right‑hand side of the screen, you’ll see a set of small buttons. Selecting the ‘P’ button opens the User Control parameters. These parameters are configurable values that are passed into each instance of the User Control, allowing multiple instances to be created without modifying the control’s internal layout, grouping, or logic. 

We are going to create two parameters:

• One for the HMI_PbLight struct
• One String for the name of the component

Note: If your struct does not show up, try closing parameters, adding a button to your user control, and linking HMI_PbLight. Return to the parameters and the datatype should now appear as PLC1.HMI_PbLight, with String for sName.

With the User Control parameters defined, we can now build the control in much the same way as before, with one key difference: instead of binding directly to PLC symbols, we bind each element to properties exposed by the User Control. The pushbutton is configured so its state and behavior reference the bRun member of the HMI_PbLight parameter, allowing each instance of the control to respond to its own data source.

In the same way, the ellipse used as a status indicator is bound to the bState variable within the same struct, and simple logic is applied to drive its fill color, green when the run condition is true and grey when it is false. Finally, we’ll add a text element and bind its Text property to the sName string parameter, enabling each instance to display a unique label.

Notice that none of the elements inside the User Control are bound directly to PLC symbols. Instead, each element references the variables exposed by the HMI_PbLight struct parameter. This indirection is what makes the control reusable.

After saving the User Control, switch back to Desktop.View and you will see it appear in the toolbox alongside the standard HMI elements. From there, drag the control onto a screen, bind the HMI_PbLight parameter to a specific instance of the struct, and assign a name. Boom! With that single step, the control is fully configured, and you can now drop in as many instances as needed while maintaining consistent behavior, appearance, and logic across your HMI.

Bonus Information

Adding a Combobox

This section introduces a Combobox that allows the operator to change the light’s color behavior within the User Control. Rather than hard-coding the color logic, the Combobox provides a simple, configurable way to select between predefined color states at runtime.

To add the Combobox, navigate to SrcData, click the three dots on the right-hand side, and create a new data source that will hold the selected value. This data source is then bound to the Combobox and referenced by the User Control logic, allowing the selected option to drive how the indicator is displayed. By handling the color selection this way, the control remains flexible and reusable while giving each instance the ability to behave differently based on user input.

Next, define the selectable color options for the Combobox. Add three entries labeled Green, Yellow, and Red, and assign each one a corresponding hex color value in the Value category. These values will be used directly by the User Control logic to drive the appearance of the status indicator.

Once the options are in place, navigate back to the ellipse inside the User Control and update its custom action. For the bRun true condition, set the fill color using a function binding that references the Combobox selection: ({ color: %ctrl%TcHmiCombobox_1::SelectedValue%/ctrl% })

This binding allows the ellipse color to be determined dynamically based on the selected Combobox value rather than fixed logic. With that complete, you can add additional instances of the User Control to your screen, bind each one to a different HMI_PbLight [HO16.1] struct instance, and select the desired color from the Combobox. Each control now behaves independently, while still leveraging the same reusable design.

Basic PLC Project 

This section walks through setting up a simple PLC project to support a basic pushbutton and light, which will later be consumed by the TwinCAT HMI. Start by creating a new solution and selecting ‘TwinCAT XAE Project’. This initializes the TwinCAT environment and provides the framework needed to add PLC logic and HMI communication.

Once the project is created, navigate to the Solution Explorer, right-click on PLC, and add a new PLC project. This creates the runtime environment where the control logic will live. With the PLC project in place, we can define the shared data structure used by the HMI. Right-click on DUTs, select Add > DUT, and choose Structure. Name this structure HMI_PbLight and add two boolean members: bRun to represent the pushbutton command, and bState to represent the resulting status of the light.

Next, navigate to POUs > MAIN (PRG) and declare an instance of the HMI_PbLight struct along with any supporting variables. Add simple logic that drives bState based on the value of bRun, mimicking the behavior of a pushbutton controlling a status light. This keeps the PLC logic intentionally straightforward while clearly demonstrating the data flow between the PLC and HMI.

With the code in place, activate the configuration and log in to the PLC. If you are running TwinCAT on a local host, be sure to execute the required .bat script before logging in. At this point, the PLC is ready, and the HMI_PbLight structure can be bound to the HMI elements and User Controls created in the previous sections.

Updating to User Mode Runtime ADS Route

This final step ensures that the TwinCAT HMI Server is communicating with the correct runtime by updating the ADS route to point to the User Mode Runtime. Begin by opening the TwinCAT HMI Server configuration by going to TwinCAT HMI > Windows > TwinCAT Server Configuration. From there, navigate to ADS > Runtimes > AMSNetId. This setting defines which TwinCAT runtime the HMI will connect to for symbol access and data exchange.

Verify that the AMSNetId is set to the AmsNetId of your User Mode runtime, if that is the runtime you are using.

This is especially important when running TwinCAT locally or when multiple runtimes are present, as an incorrect AMSNetId will prevent the HMI from resolving PLC symbols and binding data correctly.

Once the AMSNetId is confirmed, the HMI and PLC are fully aligned, allowing the User Controls and bindings configured in the previous sections to function as expected at runtime.

Conclusion

This tutorial walked through the foundational steps required to build a simple, reusable TwinCAT HMI project, starting with PLC structure design and basic HMI bindings, then expanding into User Controls and runtime configuration. By introducing the HMI_PbLight struct and gradually abstracting symbol bindings into User Control parameters, we demonstrated how to move from a single hard-coded screen toward a scalable, modular HMI architecture. The use of events, visual logic blocks, and configurable parameters highlights how TwinCAT HMI enables powerful interaction design without requiring custom scripting.

By the end of this project, you should have a working HMI that connects cleanly to a PLC, supports multiple instances of a reusable control, and allows runtime configuration via simple UI elements such as a Combobox. These same concepts scale directly to larger applications, where consistency, maintainability, and development speed become critical. Whether you are building a small operator interface or a plant-wide visualization system, following these patterns will help you create HMIs that are flexible, readable, and easy to extend.

The post Getting Started with Beckhoff TwinCAT HMI: Simple Project Setup Tutorial appeared first on DMC, Inc..

We’ve picked up some pointers while helping clients migrate their existing WinCC projects. These are our best practices for navigating that transition, with practical tips and tricks to make the process as smooth as possible.

Why Upgrade from Comfort to Unified?

Comfort is Phasing Out: As WinCC Comfort is gradually being retired, moving to WinCC Unified will ensure that your projects remain supported and functional.

Scarcity of Technology and Hardware: Comfort hardware will become increasingly rare, making upgrading worthwhile to maintain project viability and avoid future headaches.

While this blog isn’t a full-blown tutorial on WinCC Unified, it focuses on providing useful tips, tricks, and common pitfalls you might encounter when converting your projects. Our primary focus is on version 18 of Unified, though many of these insights are relevant for earlier versions like V16 and V17, which come with their own set of challenges, and also future versions.

Using the Data2Unified Conversion Tool

The Data2Unified Conversion Tool from Siemens is a great starting point for converting your projects. This tool handles about 50%-90% of the conversion process for you, depending on what elements are present in your project.

How to Use the Tool:

1. Install the Data2Unified Conversion Tool.
2. In Portal, ensure you’ve added a Unified panel to your original Comfort project.
3. Right-click on your Comfort panel in the project, find the Data2Unified tool in the context menu, and select “Start.” The tool will begin processing your project.

4. Once your project loads, you’ll choose what you want to convert. Be sure to select the Unified panel as your target. Update the file name and path if needed, and then click “Save file.” For larger projects, this process might take a while, so it can be a good idea to run it overnight.

Limitations to Keep in Mind:

• Basic Navigation: The tool often produces basic navigation outputs that may need refinement.
• Faceplates: These aren’t converted automatically, so they’ll need manual attention.
• Displays and Lists: Alarm lists, trend displays, graphic displays, and similar elements require manual adjustment.
• VBA Scripts: Review and convert these scripts manually if necessary.
• Artifacts: Be on the lookout for issues like blinking elements or rotated vertical text.

Advantages of WinCC Unified

1. Improved Navigation:

• Screen Windows: WinCC Unified allows you to design screens larger than your display and embed them in smaller windows, which automatically adds scroll bars. This feature helps keep your project organized and user-friendly. In the below example, notice the scroll bar at the bottom of the zone section that lets you slide between different zones.

• Consistent Navigation: Set up a main screen with different windows for the header, content, and navigation. This setup creates a cohesive user experience and makes navigation more intuitive.

2. Simplified Popup Architecture:

• Faceplate Popups: You can use scripting to open faceplates as popups. This reduces the number of screens you need and simplifies your project. However, if you need to handle multilingual text, be aware that the OpenFaceplateInPopup function doesn’t support text arguments in multiple languages.

Tips for Converting Faceplates

When moving faceplates from Comfort to Unified, direct copying won’t work. Here’s a step-by-step approach to make the conversion easier:

1. Copy Visual Elements: Move elements from the faceplate definition to a blank screen.
2. Run the Conversion Tool: Use the tool on this new screen to convert sizes, positions, fonts, and colors (all aesthetic properties).
3. Create a New Faceplate: Group select all objects from the conversion tool, and create a new faceplate.
4. Re-link Dynamics: Manually update dynamizations and tag linking.
5. Event Interface: Configure it as needed.

If your faceplates are complex, this approach can save a lot of time, as the conversion tool will handle all visual properties, allowing programmers to focus on quickly re-linking tags.

Leveraging JavaScript Scripting in Unified

WinCC Unified supports JavaScript, adding a new level of flexibility. You can use it to enhance screens, events, and object properties, making your HMI more powerful and customizable.

1. Nested Faceplates:

• Benefits: Nested faceplates allow for advanced graphics and cleaner architecture.
• Cautions: Avoid overusing nested faceplates and complex scripts to prevent performance issues. Efficiently manage variables and use Global Definitions to keep your code organized and avoid artifacts in the HMI simulator.

Additional Resources

For further reading and detailed guidance, check out these resources:

• SIMATIC WinCC Unified Tips and Tricks for Scripting (JavaScript)
• Data2Unified Tool Documentation
• “Getting Started with WinCC Unified”
• Developing Unified JavaScript with VSCode

Upgrading from WinCC Comfort to Unified might seem like a big task, but with the right approach and tools, you can handle the transition smoothly.

Are you looking to upgrade your existing systems to WinCC Unified? DMC’s team of Automation engineers have extensive experience and can help with conversions and migrations of any size. Contact us today to discuss your project needs.

The post Upgrading from WinCC Comfort to 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..

This past week, I took on the challenge of turning one of our IO demo kits connected to a Siemens PLC into a working game system. I chose to program the classic games Bop It and Simon Says as they would be easy to understand while still presenting their own challenges in both programming and playing.

I first created a simple infrastructure that would allow users to select which game they would like to play using one of the two colored push buttons on the IO kit. I associated each game with a different LED flash sequence to indicate which game had been selected.

The first game I decided to tackle was Bop It. In place of the original game’s “Twist it,” “Pull it,” etc., I used the IO kit’s toggle switches and push buttons.  I wrote a simple logic sequence that would randomly illuminate one of the four colored LEDs and wait for the user to press/toggle the corresponding button/switch. Like the original game, if the user waited too long or selected the wrong button or switch, they would lose the game and the program would play a failure LED sequence and return to the game selection sequence. After enough correct button pushing and switch flipping, the program would display a winning LED sequence and return to game selection.

Simon Says used similar code but with a few differences. These changes were needed due to the game’s sequence, stored using an array, which would be flashed by the LEDs then input by the user. The LED flash was accomplished using a counter up to the current length of the sequence, reading the index of the array at the current count and flashing the corresponding LED. The user input used similar logic, comparing the user’s selection to the array after each button push or switch flip. After successfully repeating a sequence of 10 LED flashes the program displays the winning sequence and returns to the game selection.

User Interface

I created a project in Ignition to graphically display the state of the game and monitor some key statistics. This endeavor added some useful functionality to the PLC code through the powerful tools provided by Ignition Perspective.

The perspective session has three main views: an overview screen and two screens for the games. It is set up so that additional games can be added easily. The overview screen offers navigation to both games, as well as a leaderboard and a popup that explains the games. Each game screen displays a brief description of the game, the status of each digital output, and the player’s current progress. Additionally, a timer shows the player how much time is remaining to make a move, a feature that is not available on the physical kit. Each game screen displays the current high score for that game. This data is pulled from a PostgreSQL database of player initials, scores, and dates. This database is also used to populate the leaderboard.

This project utilizes several of Ignition’s powerful features. Perspective can pull data from the PLC with OPC tags. These tags are then used with both built-in and custom graphics, in combination with Ignition scripting to display the status of the game. Ignition also connects to the database to create the leaderboard and high score features, through additional scripting and SQL queries. Additionally, popups are used in combination with scripts and event handlers to provide a seamless navigation experience for the user. This project uses one PLC, one database, and six windows, but these features can easily be applied to much larger automation applications.

Currently, the Perspective session only reads data from the PLC. An interesting next step could be to use Ignition to write to the plc, maybe with inputs more realistic to Bop It (i.e. twisting and pulling). This project takes advantage of some of the functionality of Ignition, but there are numerous other features that could be utilized for additional functionality.

The post Programming a PLC to be a Game Console appeared first on DMC, Inc..

If you’ve chosen GX Works3 as your development environment, you’re in for a treat. In this blog, we’ll guide you through the initial steps of starting a project in GX Works3, from installation to writing your first program, setting you on the path to automation success!

Table of Contents:

1. Installation
2. Importing CSP/CSPP Files for Devices
3. Creating a New Project
4. Navigating the Interface
5. Hardware Configuration
6. Writing Your First Program
7. Simulation and Debugging
8. Final Thoughts

1. Installation

Back to Table of Contents

System Requirements

Before installing GX Works3, make sure that your system meets the following requirements:

• Windows 7 or later
• At least 2 GB RAM
• 5 GB of free disk space

Before you can dive into creating a project, ensure that GX Works3 is installed on your system. Follow the installation wizard’s prompts and, once complete, launch the software.

2. Importing CSP/CSPP Files for Devices

Back to Table of Contents

CSP/CSPP files are the Mitsubishi equivalent of ‘EDS’ files (like in Rockwell). These files are usually provided on the device manufacturers website.

Open GX Works3. Do not open a project. If you have a project open, you must close it.

In the top menu bar, click “Tool,” then “Profile Management,” and then “Register.” Select the files you want to import and then “Register.”

3. Creating a New Project

Back to Table of Contents

Steps to Create a New Project

Click on “File” and then “New Project,” or on the icon circled below:

Choose the type and series of PLC you’re using. In our project we used an R08SF. Most of the programming will be done in ladder, so leave the Program Language as “Ladder.”

Name your project and select a storage location.

Click “Finish.”

Next, you will be prompted to set up a new user.

You will need to re-enter your chosen username and password every time you open the program and when you go online with the PLC to read or write for the first time in an online session, so choose your username and password wisely.

Note: You can go back to change this later if needed.

After this, you will be prompted to name your project. Then, your new project will open.

4. Navigating the Interface

Back to Table of Contents

Here are some important areas of the GX Works3 interface:

Navigation

This is where you’ll find all the elements related to your project such as programs, function blocks, devices, labels (AKA Tags), and parameters (for hardware configuration).

Workspace

This is where you’ll write and edit your code

Output Window

This window shows the output of compile-time or run-time actions. There are some other tabs here that are helpful for online debugging, but we will look at those later on.

5. Hardware Configuration

Back to Table of Contents

Adding Devices and Modules

To add devices and modules:

Right-click on the “Module Information” under Parameter in the Navigation.

Next, select “Add Module,” and choose the specific device or module you’re working with.

It is ok to leave “Start I/O No. Specification” as “Not Set” if you want GX Works3 to handle assigning these values automatically based on slot number.

If there are specific values you want a module to start at, you can choose ‘set’ and pick your Start I/O.

For this example project, we will choose a digital input card RX42C4 in slot 1 and a digital output card RY42PT1P in slot 2 to start.

In addition, the R08SFCPU requires an R6SFM, a safety function module, which we will put in slot 0 here.

PLC Configuration and Setup

IP Address

Double click on “Module Parameter” under R08SFCPU or your chosen PLC series. This will open the screen below:

Here you can set the IP Address information for your PLC. Press “Apply” on the bottom right side of the screen to save.

CPU Module Operation Setting at Error Detection

While debugging programs later, if any of your programs encounter an operation error (ex. array index out of bounds, invalid function input data when using direct addresses), the PLC will default to a “stop” error state: which requires a full reset of the PLC to clear (sometimes includes a power cycle if there is a safety module involved).

This can be very annoying when debugging and testing code; however, there is a setting that you can change that allows the PLC to continue running with the operation error allowing you to track down the error, make an adjustment, and continue testing.

Double click on CPU Parameter under R08SFCPU or your chosen PLC series. This will pull up the parameter window.

In the “Setting Item List,” click on “RAS Setting,” and then navigate to the “Operation Error” line item in the window on the right.
 
The default setting is “Stop.” Click on the drop down and change it to “Continue” to prevent the PLC from stopping. Click “Apply” on the bottom right corner before exiting this tab.

There are a couple of other types of execution errors here that can also be set to “Continue” if desired. After testing and debugging, remember to switch these settings back to “stop.”

Timer Setup

Double click on CPU Parameter under R08SFCPU or your chosen PLC series. This will pull up the parameter window.

In the “Setting Item List,” click on the “Operation Related Setting.”

This will pull up the “Timer Limit Setting,” which controls the units that each of the three timer instructions: OUTL, OUTH, and OUTHS. 

Note: We typically set one of these to 1ms, so it is easier to keep track of how long timers are.

Labels, Data Types, and Memory Address Mapping

Labels are what you use for your program variables. They can be defined locally in a program or function and only accessible in that particular program or function, or they can be defined globally and accessed anywhere. 

They are equivalent to “tags” in a Rockwell PLC.

You can create multiple global label lists with different names, but there is no way to differentiate which global label list a global label is defined in. Each program/function can only have one local label list.

Here is a helpful table showing the available data types for labels:

In Gx Works3, you can choose to assign memory addresses to your labels explicitly or let Gx Works automatically assign them when converting your program.

Below are the commonly used memory addresses available in Gx Works3:

• X: Input
  • Inputs coming to the PLC through any devices or modules will be mapped to the X device addresses.
• Y: Outputs
  • Outputs being sent from the PLC to any devices will be mapped through the Y device addresses.
• M: Internal Relay
  • These are bits internal to the PLC. These are similar to memory bits in a Siemens PLC.
• D: Internal Word
  • These are words internal to the PLC.

Although you can reference device addresses directly in your program as normally open/closed contacts, outputs, etc., it is best practice to define helpfully named labels and use those in your program instead.

This makes it significantly easier to read and follow along whether you are revisiting your program at a later date or if another programmer is helping review your program.

One more thing to keep in mind is that, if you do wish to assign device addresses to any of your labels, you will need to keep track of how many registers each data type will take up.

For example, if you assign a float/real label a device address of D1000, since a float is 32 bits long, it will take up registers D1000 and D1001. Gx Works3 will not tell you explicitly that this is happening, so it is up to you to keep track and avoid unintentionally double assigning device addresses.

6. Writing Your First Program

Back to Table of Contents

Now that you’re familiar with the interface, it’s time to write some code.

First, we can start by adding a normal scan program.

Note: We also have the option of adding other types of programs, if desired, such as ‘Initial,’ ‘Fixed Scan,’ ‘Event,’ etc. Right clicking on any of the other options under the ‘Program’ tree will allow you to add new data to those types of programs.

In this blog we’ll cover the basics of ladder since that is the most frequently used.

Right-click on the “MAIN” under the “SCAN” dropdown in the Navigation and select “Add New Data.”

A “New Data” window will pop up. Here you can name your program and choose the language (ladder, ST, SFC, FBD/LD).

This will open the Local Label list and Program Body for the new program. You can define any program specific labels in the Local Label List before starting to write the program.

Alternatively, you can define your labels as your program as well. If you enter in label name that isn’t defined, it will open the dialogue window below, and you can choose to define it.

If you have an undefined tag, it will be gray instead of pink.

Next, to start writing your program, navigate to the “ProgramBody.” Make sure to set the drop down on the top left to “Write:”

The “Read” option will not allow editing, and you cannot copy lines of code in “Read” mode either. “Write Mntr” and “Read Mntr” are for monitoring the program while online with the PLC.

There are some display options that can be set to make the ladder editor easier to read. Click on “Tool” > “Options.”

Next, click on “Ladder Editor:”

Here are some settings that I think are helpful to have on; these will display any comments you add to labels or any comments you add to your ladder rungs.

One other setting that is useful to have on is the “Wrapping Ladder Display.” This will wrap a long label name and show the whole name.

To start writing logic, you can double click on a cell or select a cell and just start typing a label name or instruction. The drop down here shows the type of basic instruction you can assign to a cell.

Note: If you don’t choose anything, it will default to a normally open contact.

The easiest way to program is to type out the instruction and labels for each cell and then press enter.

Typically, the syntax is: Instruction Input1 Input2 …. Here is an example for a move instruction where an integer value 1 is moved into iCount. Here I typed: MOV K1 iCount.

Each instruction might have different inputs. If you need details, you can right click and select “Open Instruction Help.”

Here are some basic, commonly used shortcuts and instructions:

F5: NO
F6: NC
F7: OUT

Set: latch a Boolean

RST: unlatch a Boolean

Unlike Siemens and Rockwell, Gx Works3 requires different versions of instructions when using different data types. Here are some examples:

=, >=, <=, <>, Instructions for comparing 16-bit data.

+, -, *, /, Instructions for basic math with 16-bit data.

MOV, to transfer 16-bit data.

D=, D>=, D<=, D<>, Instructions for comparing 32-bit data.

D+, D-, D*, D/, Instructions for basic math with 32-bit data.

DMOV, to transfer 32-bit data.

E=, E>=, E<=, E<>, Instructions for comparing single precision real numbers

E+, E-, E*, E/, Instructions for basic math with single precision real numbers

EMOV, to transfer single precision real numbers.

ED=, ED>=, ED<=, ED<>, Instructions for comparing double precision real numbers

ED+, ED-, ED*, ED/, Instructions for basic math with double precision real numbers

EDMOV, to move double precision real numbers.

$+, to concatenate strings.

$MOV to transfer character strings.

Next, we will go over basic timers.

Earlier in this blog we set timer units in the CPU parameters. The instructions for each of the timers are OUT, OUTH, and OUTHS.

These timers will run based on what was set earlier. OUT is the instruction for a normal output coil, but, when the first input is a label of type “Timer” and the second input is a 16-bit unsigned integer, this instruction behaves as a timer. Here is an example of how this would look like:

This timer is enabled when Input1 goes high and starts counting to 100*10ms (default setting). When the time is reached, the label Timer1 can be used directly as a contact and will go high turning on Output1.

Finally, we will cover how to comment in Gx Works3.

The three icons below can be toggled on and off. When toggled on, double clicking on a rung or a cell will pull up a window where you can add a comment.
 
The leftmost icon allows you to comment on your labels (you can also do this in the label lists), the middle icon is for commenting an entire rung, and the last one will add a comment to an output.

Adding comments to entire rungs is the most useful.

If you check “Display in Navigation Window,” text you write here will become subtitles in the Navigation window: which can be helpful for organizing your code.

You can add multiple comments above a rung, like this:

7. Simulation and Debugging

Back to Table of Contents

This section will focus on how to simulate a PLC and go online to test your program.

We have created a basic sample program. Anything that hasn’t been compiled yet will show up as gray in the ladder editor and red in the Navigation window.

To check and compile code, click on “Convert,” then press the “Convert(B).”

Alternatively, you can click the convert button in the tool bar shown below.

If there are no errors in the code, after converting, the rungs in the ladder editor will turn white, and the titles in the Navigation will also turn white. If there are any errors, they will be displayed in the Output Window.

Next, click on the “Start Simulation” icon to start a PLC simulation. The button immediately to the right is “Stop Simulation” and will end the simulated PLC.

The first time you start a simulation, the program will automatically write to the simulation PLC. It will open the window below. which is the simulated PLC.

Now, you can switch to “Read Mntr” or “Write Mntr” to test your programs live.

If you make a change to your program, you will need to write these changes to the PLC. If you only changed your program, you could do an online change by pressing the icon below.

If you make a change to any Structured Data Types or Parameters, you will have to rebuild/recompile your project and then do a full download. To do a download, press the red arrow icon shown below. It will open a window where you can select exactly what you want to write to the PLC.

If you have multiple people working on the same PLC, anytime someone writes a change to the PLC, all other people will need to read from the PLC to obtain that change. It doesn’t automatically update. To read from the PLC, press the blue arrow button shown below. It will open a window where you can choose what you want to read.

Basic debugging and troubleshooting

The last part of this blog will go over some debugging and troubleshooting tools in Gx Works3.

After going online with the PLC and monitoring your selected program, the ladder editor will display the values in any referenced labels, and any contacts that are true will be colored blue.

In our sample program here, Input1 is true and iCount = 1.

There are two main ways to modify labels.

For a Boolean, you can right click on the label, go to “Debug,” then click on “Modify Value.” This will flip the value of the Boolean.

The other way to modify labels is to right click, go to “Register to Watch Window” and then add the label to a watch window of your choice. The selected watch window will open.

If no values are being displayed on the watch window, you can right-click on a label in the watch window and click “Start Watching.”

You can monitor and modify any label values in the watch window. After entering in the desired value, press “Enter” on your keyboard to confirm the value modification.

To cross reference a tag, right click on the tag and click on “Cross Reference.”

The cross-reference window will open and show all instances of the label.

One important thing to note is that no matter what value is present at a certain index in an array, the GX Works3 ladder editor will show that it is -1. To see its actual value, you can use a watch window.

In the example below, IntArray[Index] should equal 2, but the value shown in the ladder editor is -1.

The icons shown below near the top right corner show the statuses of the PLC.

If there are any errors, there will be a yellow exclamation mark present. To check on any PLC or module errors, clicking on the check mark will bring up the diagnostic window below.

One last useful tool for debugging is the Device/Buffer Memory Batch Monitor which can be accessed by pressing the icon below:

Here you can type a device name (ex. D10, or X100) or buffer memory unit and monitor the bits at those places in memory.

After you are done with simulating your program, make sure to stop the simulation before connecting to a real PLC.

To get connected with a real PLC, start off by pinging the PLC IP address using command prompt. After that is successful, press the icon shown below:

This will open the following window:

Double click on “Ethernet Board” to specify your adapter and hit OK.

Double click on “PLC Module.”

The first time you connect to the PLC, you will have to connect through the ethernet port directly on the PLC to write an IP address to the PLC. 

Choose “Ethernet Port Direct Connection.”

If you have connected to the PLC before, set the IP address already, and are now connected through an ethernet switch, click on “Connection via HUB” and enter in the IP address of the PLC. Next, press “OK.”

Next, click on “Connection Channel List.”

There are many different routes to connect to the PLC, the most common is “19 Ethernet Board Communication PLC Module Connection.”

If you have a different network topology, you may need to choose a different setting here. Selecting different options will change the graphic shown to help illustrate the topology. After choosing your setting, click “OK.”

Finally, we can test our connection to the PLC by clicking on “Connection Test.” A dialog box will show up to display whether the connection is successful or not.

If this is the first time you are connecting to a fresh PLC, make sure to write your entire project to the PLC to set the IP address of the PLC for future connections.

8. Final Thoughts

Back to Table of Contents

GX Works3 provides an integrated environment for developing and managing automation projects. While navigating and programming in GX Works3 may present challenges, mastering its key functionalities and insights can significantly alleviate the frustration, paving the way for a smoother and more efficient experience in harnessing its power for industrial automation.

Happy programming!

The post Starting a Project in GX Works3: A Beginner’s Guide appeared first on DMC, Inc..

To accomplish this task in the PLC code, a duplicate datablock can be created to store on the SD card, data can be split up into readable and writeable chunks, and triggers can be created for reading and writing to the SD card. The steps to implement this solution are below:

Step 1: Creating the datablock that will be stored on the SD card

Duplicate the datablock that is to be periodically saved to the SD card. In the duplicated datablock’s properties, set the attribute for “Only store in load memory” to true. This will make sure the datablock is stored on the SD card. All other options can remain the same.

Step 2: Splitting up your data

The “WRIT_DBL” instruction will be used to write the data in a later step. When using this instruction, data with the datatype “Struct” cannot be written. Only UDTs and arrays can be written to another data block. To accommodate this, split the data into sections that can be written to the SD card, and write each section inside of a datablock writing sequence.

Step 3: Writing the Data to the SD Card

To write the data to the SD card, the source block of the “WRIT_DBL” should be set to the data block that is being backed up; the destination block should be set to the corresponding data block on the SD card. If the data was split into sections, make sure to specify the section being copied and written on both the source and destination parameters.

The busy signal is an important component of the reading and writing process. The sequence should only move on to writing the next section when the busy signal is low. The busy signal can be high for several scans, and each write instruction should be given time to finish before moving on to the next one to avoid problems with the writing process.

Step 4: Reading the Data from the SD Card

Reading data from the SD card works similarly to the writing process. Just use the “READ_DBL” instruction. To trigger a read from the SD card on startup, use the Memory bit for “FirstScan” as one of the triggers for the read sequence. The same guidance from the data writing step on using the busy signal applies to the read sequence.

Step 5: Create the Trigger for Reading and Writing

To make a trigger for the reading or writing of the sequence, the timer, button, or any other kind of trigger should be tied to a Boolean. Use that Boolean to set off the write or read sequence. The active signal latches ON using the busy signal and the sequence trigger to complete the sequence without getting interrupted. If the sequence is running, the “bActive” boolean is ON until the sequence is completed.

Stepping through the sequence is controlled by the busy signal. The final step of the sequence should reset the sequence back to the beginning to wait for the next trigger.

Learn more about our Siemens PLC Programming expertise and contact us today for your next project.

The post Using an SD Card for Retentive Memory – Siemens PLC appeared first on DMC, Inc..

Common questions that may have led you here:

The Basics

In this section, we will cover how to do the minimum viable work to get display changes working. This process will cover the basics and allow you to get working on your own, but feel free to stick around if you want to improve your coding and architecting skills.

Creating a Trigger

In this section, I am going to explain how to create a global trigger. This just means that we are going to set up a display such that the trigger is always being updated so you can initiate a change from any display.

Firstly, we are going to create a new display. You can call this display PopupHandler if you want it to be sufficiently descriptive. On this display, we are going to add a numeric input. Set the expression to be your trigger condition.

Once you’ve got the numeric input set up, right click the background of the display and select Display Settings... . Make sure the following properties match between your displays:

Now, we are going to make the PopupHandler silently load and stay cached and updated so the numeric input we have created is always loaded. Create a macro and call it startup. When the macro opens, add the following command on a new line:

Display PopupHandler /ZA

Now that we have the macro ready, we are going to add it to our client runtime. Edit your .cli file and make sure you’ve got the startup macro selected to run on startup. Once this is done, the macro should execute on startup and load the PopupHandler display into our cache.

Using VB to Set a Display

Now that we have the trigger ready, we are going to add the corresponding VB Script. Select the numeric input on your PopupHandler display, right click, and select VBA Code... . You should see the following:

The subroutine (sub) you see of the form NumericDisplayName_Change is the script that is going to run when our condition changes. To trigger our display change, we are going to add the following line of code inside the subroutine (replace “DisplayName” with the display you want to appear).

ExecuteCommand ("Display DisplayName")

With that, you should be ready to go. Go ahead and restart your client and try triggering your condition. Ideally, you should see the popup or display you specified appear when the condition changes. If you do, you’ve got the minimum viable product and should proceed to the “Let’s Make it Better” section to refine your implementation.

Let’s Make it Better

We can do better and you know it. If you want to impress the future engineers who will look at your work, then I suggest you get to the end of this section.

Better Naming Practice

Let’s start by changing the name of our component. Go into the component properties and set the name to something more descriptive — in this case, we will use PopupEventTrigger. If we observe the VB Script again, then we will see the name of the subroutine has been changed to reflect what was done in FactoryTalk View Studio.

Let’s also leave a clear visual indication of the work we have done. Next to the numeric input you are using, go ahead and add a text box and describe what is happening here. This will make it readily apparent to other engineers that there is VB Scripting going on behind the scenes.

Case-By-Case Events

Instead of triggering any time we see the value change, let’s consider the value we are seeing. In this case, we are going to nest another condition that checks if the value of our trigger is “1”. With this new implementation, we should only see our change when we have a rising edge signal.

Private Sub PopupEventTrigger_Change()
    ' If trigger value is rising '
    If PopupEventTrigger.Value = 1 Then
        ' Change Display '
        ExecuteCommand ("Display Popup")
    End If
End Sub 

Private Sub PopupEventTrigger_Change()
    ' If trigger value is rising '
    If PopupEventTrigger.Value = 1 Then
        ' Change Display '
        ExecuteCommand ("Display Popup")
    End If
End Sub 

Private Sub PopupEventTrigger_Change()
    ' If trigger value is rising '
    If PopupEventTrigger.Value = 1 Then
        ' Change Display '
        ExecuteCommand ("Display Popup")
    ' If trigger value is falling '
    ElseIf PopupEventTrigger.Value = 0 Then
        ' Close Display '
        ExecuteCommand ("Abort Popup")
    End If
End Sub

Private Sub PopupEventTrigger_Change()
    ' If trigger value is rising '
    If PopupEventTrigger.Value = 1 Then
        ' Change Display '
        ExecuteCommand ("Display Popup")
    ' If trigger value is falling '
    ElseIf PopupEventTrigger.Value = 0 Then
        ' Close Display '
        ExecuteCommand ("Abort Popup")
    End If
End Sub

Error Handling

Let’s prevent errors from interfering with our operation. If there is an issue with the connection to the PLC, then the numeric display may have an error value. Unfortunately for us, this change to an error value counts as a value change and will trigger our display change subroutine. To avoid this, we will wrap our logic in an if statement that checks if there is an error value in our component.

Private Sub PopupEventTrigger_Change()
    ' Make sure there is no error '
    If Not IsError(PopupEventTrigger.Value) Then

        ' If trigger value is rising '
        If PopupEventTrigger.Value = 1 Then
            ' Change Display '
            ExecuteCommand ("Display Popup")
        End If

    End If
End Sub

Private Sub PopupEventTrigger_Change()
    ' Make sure there is no error '
    If Not IsError(PopupEventTrigger.Value) Then

        ' If trigger value is rising '
        If PopupEventTrigger.Value = 1 Then
            ' Change Display '
            ExecuteCommand ("Display Popup")
        End If

    End If
End Sub

Alternatively, we could exit the subroutine early if there is an error.

Private Sub PopupEventTrigger_Change()
    ' Make sure there is no error '
    If IsError(PopupEventTrigger.Value) Then
        Exit Sub
    End If

    ' If trigger value is rising '
    If PopupEventTrigger.Value = 1 Then
        ' Change Display '
        ExecuteCommand ("Display Popup")
    End If
End Sub

Private Sub PopupEventTrigger_Change()
    ' Make sure there is no error '
    If IsError(PopupEventTrigger.Value) Then
        Exit Sub
    End If

    ' If trigger value is rising '
    If PopupEventTrigger.Value = 1 Then
        ' Change Display '
        ExecuteCommand ("Display Popup")
    End If
End Sub

Let’s Make it Scalable

While this solution works great for changing to one specific display, it doesn’t work great at scale. Imagine, for a moment, having to repeat the process of creating a new numeric input and writing the Visual Basic subroutine for every display you want to change to. Needless to say, this proposition elicits feelings of dread.

To avoid this monotonous task, we are going to discuss a couple possible architecture changes to support additional display changes.

Potential Architectures

There are, of course, more options than the two I will address here; however, they should generate some considerations for designing the architecture that fits best for your uses.

Custom Display Indexing

The numeric display we have been using to trigger our subroutine is not limited to a 1 or 0, so let’s make use of it. Change the expression to read an int on the PLC, and let’s move to a display based on what int is shown.

Private Sub PopupEventTrigger_Change()
    ' Make sure there is no error '
    If IsError(PopupEventTrigger.Value) Then
        Exit Sub
    End If

    Select Case PopupEventTrigger.Value
        Case 1
            ExecuteCommand ("Display Popup1")
        Case 2
            ExecuteCommand ("Display Popup2")
        Case 3
            ExecuteCommand ("Display Popup3")
    End Select
End Sub

Private Sub PopupEventTrigger_Change()
    ' Make sure there is no error '
    If IsError(PopupEventTrigger.Value) Then
        Exit Sub
    End If

    Select Case PopupEventTrigger.Value
        Case 1
            ExecuteCommand ("Display Popup1")
        Case 2
            ExecuteCommand ("Display Popup2")
        Case 3
            ExecuteCommand ("Display Popup3")
    End Select
End Sub

This approach is handy as it allows you to map integer values to displays, similar to how the process works in ME. All the display changes are handled here in this subroutine; however, you will have to manually add each new display you want to transition to. To avoid this, we can have the PLC pass a string indicating a destination display.

Passing Strings from the PLC

By setting a string on the PLC for the HMI to read, we can indicate any display we want to transfer to! For simplicity, let’s create a string display on our PopupHandler screen to reference in our VBA. There, we can change our command to display whatever display is referenced in the string. Make sure that the string display has plenty of characters, as it will trim the PLCs string to the specified character amount. Additionally, make sure to expose the string display to VBA from the property panel with the option “VBA Control”.

Private Sub PopupEventTrigger_Change()
    ' Make sure there is no error '
    If IsError(PopupEventTrigger.Value) Then
        Exit Sub
    End If

    ' If trigger bit rising '
    If PopupEventTrigger.Value = 1 Then
        ' Trigger display change based on the value of the passed string '
        ExecuteCommand ("Display " & DisplayNameString.Value)
    End If
End Sub

Private Sub PopupEventTrigger_Change()
    ' Make sure there is no error '
    If IsError(PopupEventTrigger.Value) Then
        Exit Sub
    End If

    ' If trigger bit rising '
    If PopupEventTrigger.Value = 1 Then
        ' Trigger display change based on the value of the passed string '
        ExecuteCommand ("Display " & DisplayNameString.Value)
    End If
End Sub

If you want help with your FactoryTalk View SE project or PLC development, contact us today for your next project — we would love to help!

The post Triggering Popups and Display Changes in FactoryTalk View Site Edition from the PLC appeared first on DMC, Inc..

Unfortunately, our client didn’t have TIA Portal software available at the time. They were afraid that this made it impossible to download the new version of the code to the PLC in the field.

Fortunately, Siemens offers the SIMATIC Automation Tool as a free download (just sign up for an account first) on their website. The SIMATIC Automation Tool was perfect for our client’s situation. It allowed them to seamlessly download the updated PLC code and commission the machine on schedule. 

This blog will walk you through the entire process of downloading a new PLC program to an S7-1200 or S7-1500 CPU using the SIMATIC Automation Tool.

First, you will learn how to connect a computer to the same network as the PLC. I will then show you how to save the PLC program in a format that the SIMATIC Automation Tool can use. Next, I will walk through using the SIMATIC Automation Tool itself. Finally, I’ll review some of the other capabilities of the SIMATIC Automation Tool. 

0. Connect your computer to the same network as the PLC

Connect an Ethernet cable directly from the S7-1200 or S7-1500 PLC to your computer. Next, set your computer’s IP address to be on the same network as the PLC. In order to do this, click the Start button and search for Network and Sharing Center. Open the Network and Sharing Center. On the left, there should be an option that says Change Adapter Settings. Click that.

Now you should see a connection that says Ethernet or Local Area Connection. Double click on it.

In the dialog box that opens, click Properties

In the next dialog box that comes up, there will be an option that says Internet Protocol Version 4 (TCP/IPv4). Double click on this option. 

In the next dialog box, select Use the Following IP Address. You need to enter an IP address that is on the same network as the PLC you are going to connect to.

This means the first three numbers of your computer’s IP Address must be the same as the first three numbers of the PLC’s IP Address. In this case, our PLC IP Address is 192.168.0.1, so we assign our computer to be 192.168.0.100. In the subnet mask field, 255.255.255.0 is typically used. Click ok.

1. Generate the S7S File using TIA Portal

In order to download to a PLC using the SIMATIC Automation Tool, you need the PLC program in an S7S File Format. Whoever wrote the PLC program should follow these steps using TIA Portal to generate the S7S File for you to use.

First, map a file directory on the TIA Portal computer to a Card Reader/USB Memory location. To do this, open the PLC project in TIA Portal and click Project -> Card Reader/USB Memory -> Add user-defined Card Reader:

Select your desired file location in the dialog box that follows. 

Once you have mapped the Card Reader/USB Location, select the PLC in the project tree.

Then click Project -> Card Reader/USB memory -> Write to memory card…

Select the file location you mapped earlier and press the green check mark.

Click Load: 

Send the resulting S7S File to the computer that is running SIMATIC Automation Tool.

2. Using the SIMATIC Automation Tool 

On the SIMATIC Automation Tool computer, save the S7S File in the following directory: 

C:\ProgramData\Siemens\SIMATIC Automation Tool\Programs

In our situation, DMC simply emailed the S7S file to our client and they saved it in the proper location on their computer. 

Now that your computer is connected to the same network as the PLC and the new program is saved in the correct location, launch the SIMATIC Automation Tool.

Scan for the PLC by clicking Network -> Scan: 

If everything is configured correctly, you will find the PLC and the SIMATIC Automation Tool should look like this: 

Now select the Program Update Tab. In the Program Update area, open the dropdown and you should see the name of the folder that you saved the S7S File in. Select that: 

Now check the box next to the PLC, and then select Network -> Download: 

The program will take a minute or two to download to the PLC. Once it is done downloading, the PLC will be in STOP mode. To put the PLC back into RUN mode, select Network -> RUN.

The PLC should now be running the newest version of the program! 

3. Other Functions of the SIMATIC Automation Tool

According to the Siemens website, the SIMATIC Automation Tool can also perform the following functions: 

• Assign addresses (IP, subnet, gateway) and station name (PROFINET device)
• Set the time in a CPU to the current time in your PG/PC
• Backup/Restore CPU data to/from a backup file (no failsafe)
• Flash the lights on a CPU to help physically locate the CPU
• Upload fault information from a CPU
• Read the diagnostic log from a CPU
• Reset a CPU to factory default settings
• Update firmware in a CPU and attached modules

These functions make the SIMATIC Automation Tool a useful asset for any facility running an S7-1200 or S7-1500 PLC. It allows you to perform basic maintenance functions in a simple interface. 

Learn more about DMC’s PLC Programming services and contact us to get started on your next PLC Programming project.

The post How to Update a Siemens PLC without TIA Portal using the SIMATIC Automation Tool appeared first on DMC, Inc..

When V13 SP1 was first released, one of the features I was most excited about was the ability to multiplex arrays of custom UDTs on a PLC using a simple index tag on an HMI. This feature allowed me to use a single faceplate or screen to display or modify data from multiple objects by simply changing a single tag. I was so excited, I even wrote a blog post about it then! Unfortunately, it was a feature to be short lived and, due to some unexpected consequences, mysteriously disappeared with the release of Update 3.

Now that TIA Portal V14 has been released, the very first thing I did was look to see if it was back. And I'm in luck!

While I've gone into some detail in my previous blog, and all of the same information is relevant, here's a really quick demo to set up multiplexing of an array of UDTs from your HMI.

First, I've created a really simple project with a S7-1200 (FW v4.0) and a TP700 Comfort panel (Version 14.0.0.0). To make things simple, I've grabbed a UDT (udtHMI_VFD_Control) from the Siemens Open Library, and added it as a type to my Project Library (this will allow me to use it within a faceplate later), and then copied from my Project Library to my PLC (under PLC Data Types). Next, create a new data block on your PLC – I've called mine "dbDemo." Inside of my Data Block I've created a single array of VFD's.

Next, open up the Default Tag Table on the HMI. Add a new internal tag called "Index" of type "UINT." Now, in your project tree, select the DB you previously created, and from the details view, drag any one item from your array of VFDs into your tag table to create a new tag of type "udtHMI_VFD_Control" – you can use the blue 'tag' icon that shows up in the detail view to grab the tag. I've named mine "Indexed_VFD."

Note that as of right now, this tag is linked directly to a fixed item within your array – in my case, "dbDemo.VFD[1]." We want to modify this so that our "Index" tag will change which item in the array we want the tag to link to so we can multiplex this tag across multiple VFDs from our HMI. To do this, select the "Address" dropdown under the properties of the tag. For "Index Tag," change the selection to "HMI Tag" and choose the "Index" tag we created earlier.

Notice that in your tag table the address has changed to indicate the position in the array is defined by our"Index" tag.  And that's it! Now, we can change "Index," either through a script or by a control on the HMI, and our multiplexed tag will look at a different item in our array. In the screenshot below, note that our "Indexed_VFD" is now linked to any VFD in our array using the "Index" tag.

To take this a step further in your quest for object oriented programming, take another look at my previous blog. It will take you through linking your multiplexed tag to faceplates and popups – which is where this feature will really help you develop better, more powerful, HMIs.

One more helpful hint – you will find that your index on the HMI will be zero based, regardless of the way you define your array on the PLC. For example, if I defined my array (on the PLC) to be [1 .. 20], an "Index" of 0 will actually access the first element, [1], in my array.

Enjoy!

Learn more about DMC's PLC Programming services and contact us to get started on your next PLC Programming project.

The post Multiplexing Arrays of UDTs in TIA Portal V14 appeared first on DMC, Inc..