This blog is Part 3 of a multi-part series. Make sure to check out the other blogs on this topic:

1. Beckhoff Setup Basics: IPC Configuration Steps
2. Beckhoff Setup Basics: Getting Started with a Beckhoff PLC
3. Beckhoff Setup Basics: HMI Configuration Steps

Term Definitions

Throughout this blog series, I refer to two devices repeatedly. For clarity, those devices are as follows:

1. “Beckhoff IPC” – The industrial PC that will run the PLC and HMI server. Device configuration will occur on this device. Beckhoff sells these directly. Third-party IPCs can also be used, but licensing is more expensive.
2. “Programming Computer” – A computer, such as an engineer’s laptop, where the TwinCAT XAE development environment is installed. Programming happens on this device, as well as some of the configuration of the Beckhoff IPC.

Configure HMI Server

First, we’ll need to configure the HMI server so we can publish to it. On the Beckhoff IPC, find the HMI server tray icon, and click on it.

Note: If you do not see this icon, double-check that TE2000 HMI Server is installed on the Beckhoff IPC following the instructions in Part 1 of this blog series.

Select “Service Configuration.”

The webpage http://127.0.0.1:19800/ should open in the default browser.

On that page, add a new Server Instance by entering the information in the form and creating an HMI administrator password.

In the menu that appears, select the HMI Instance we created and select “Config.” (If there are issues, you may need to restart the HMI server through the same menu).

The default startup page will open.

If you get a “License Expired” error page, then double-check that you have a valid or trial license for TE2000.

In XAE Shell, ensure that TF2000 is selected and there is an active trial license.

If you have created a new trial license but still experience this error, then restart the HMI Server Instance.

Once the HMI Server has a valid or trial license, the Config page will show this. Enter the HMI administrator password created on the “Server Configuration” page.

The configuration will open. Navigate to TcHmiSrv > Webserver.

Expand the Endpoints menu and select “Add.”

Add the IP address of the HMI Server where it will be accessed externally (an external browser or HMI) and use your HTTPS port.

For this guide, we will assume the HMI server is on the Beckhoff IPC and use the URL: https://192.168.42.42:1021/.

An “Add successful” message will appear at the top of the page if it is successful. If not, make sure the URL is correct and you’ve used https:// as a prefix to the IP address.

Publish HMI Program

Now that the HMI server is configured, we can create the HMI Project in XAE Shell on the Programming PC.

Once the HMI project is complete, we can publish it to the HMI server.

To do this, select the HMI program in the project tree.

At the top of XAE Shell, change the platform dropdown to “TwinCAT HMI.”

At the top of XAE Shell, select TwinCAT HMI > Publish to TwinCAT HMI Server.

If you have not created any profiles, TwinCAT will prompt you to enter a profile name. Different profiles can be used for different environments (ex: development, release, etc)

Enter the IP address of the HMI endpoint created earlier, the appropriate port (1020), and the administrator password for the HMI Server set up earlier in this guide.

You can also click the “…” button to open a pop-up of available HMI servers to connect to.

It’s a good idea to click “Validate Connection” to ensure all information is correct and a connection is successful. If an error occurs during validation, you will not be able to publish until you correct it.

Then click “Publish” in the top-right corner to publish the HMI project to the Server.

It may take a long time for the project to publish. You can track progress in the bottom bar of XAE Shell.

Full-Screen HMI Start in Chrome/Firefox

When our Beckhoff IPC is booted, we usually want it to immediately open the HMI screen instead of requiring an operator to start the HMI manually. This can be accomplished with a very simple batch script.

Open Notepad on your Beckhoff IPC and paste in the following code:

@echo off
start "" "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --kiosk -fullscreen --incognito http://127.0.0.1:1010/
exit

@echo off
start "" "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --kiosk -fullscreen --incognito http://127.0.0.1:1010/
exit

Save this file as “StartHMI.bat” in your startup folder. For convenience, if the HMI screen ever does need to be started manually, create a shortcut for this batch script and place it on the desktop.

This will automatically open Chrome in full screen on startup. You may want to do this step after you’ve finished other setup steps, as it can be a bit of a nuisance after restarts.

Make sure the path for Chrome in the batch file is correct. The above is the default location, but it may not be correct.

Note: Similar instructions are available for Firefox.

Once the HMI is published on the server and starts in kiosk mode on startup, you are now complete with your Beckhoff PLC and HMI.

The post Beckhoff Setup Basics: TwinCAT HMI Configuration Steps appeared first on DMC, Inc..

This blog is Part 2 of a multi-part series. Make sure to check out the other blogs on this topic:

1. Beckhoff Setup Basics: IPC Configuration Steps
2. Beckhoff Setup Basics: Getting Started with a Beckhoff PLC
3. Beckhoff Basics: HMI Configuration

Summary

This is the second installment of a three-part blog series covering all you need to know about getting started with a Beckhoff PLC/HMI. In this blog, we’ll be covering how to configure and license the PLC to run your code.

Term Definitions

Throughout this blog series, I refer to two devices repeatedly. For clarity, those devices are as follows:

1. “Beckhoff IPC” – The hardware, likely obtained from Beckhoff, that will run the PLC and HMI server. Device configuration will occur on this device.
2. “Programming Computer” – A computer, such as an engineer’s laptop, where the TwinCAT XAE development environment is installed. Programming happens on this device, as well as some of the configuration of the Beckhoff IPC.

Connect to the IPC Via a Programming Computer

First, we’ll need to check if TwinCAT XAE is able to communicate with the IPC. If you’ve done this before, feel free to skip this step.

Next, make sure your programming computer is connected to the Programming Port on the Beckhoff IPC. On the programming computer, right-click on the TwinCAT gear icon and select Router > Edit Routes.

On the TwinCAT Static Routes popup, select “Add.” The Add Route Dialog will appear. Check the Advanced Settings box at the bottom left to expose the full connection settings.

The most reliable method to find the IPC is to enter the IP address in the field at the top, then click “Enter Host Name / IP.” If the Beckhoff IPC doesn’t appear, make sure you can ping it (if the firewall pinging rules are enabled) and check your IPC’s or network’s firewall settings.

Select the Beckhoff IPC. The most reliable way to add a route is to set the address info to reference the IP address, not the hostname. This is because many plant networks don’t have DNS set up in such a way that allows access of factory devices via hostname. Select this option, then “Add Route.” Enter the proper credentials for your IPC in the popup and click “Okay.” Default credentials for Beckhoff IPCs are:

• User: Administrator
• Password: 1

If you have changed these, use the appropriate credentials. If the connection process succeeds, you should see an X or a small lock appear under the Connected column in the Add Route Dialog and the TwinCAT Static Routes window. You can exit these windows now.

From within TwinCAT XAE Shell, open your project. Then use the target dropdown menu and select “Choose Target System.”

Note: these instructions will show screenshots from 32-bit XAE Shell, but can be followed the same in XAE Shell 64-bit.

In the window that pops up, expand the browser tree and select the Beckhoff IPC. Click “OK.”

If you are prompted to change the solution platform, do so.

Set IPC Boot Settings

Before the TwinCAT project can be downloaded to the PLC, a few boot settings need to be configured. First, right-click on the PLC project in the solution explorer and make sure “Autostart Boot Project” is checked. This ensures the project starts automatically when the Beckhoff IPC boots.

Next, double-click on “SYSTEM” in the solution explorer, then navigate to the Settings tab. Select “Run Mode (Enable)” under Boot Settings (Target). This will make sure the PLC enters run mode on boot.

If you want to enable auto-login for the Beckhoff IPC, check the Auto Logon box. Enter the username and password for the IPC and click Apply to save the boot settings to the IPC.

Confirm Hardware Configuration and Activate Configuration

Next, we will need to activate the PLC configuration. Make sure your IO cards are powered and connected to the IPC before continuing with this step.

To do this, first navigate to I/O > Devices > [YourEtherCATMasterDeviceName]. For example, in this project, the EtherCAT Master device is named “Device 1.”

Double-click to open the device settings. On the Adapter tab, click “Search…”

The pop-up window should include a list of NICs with the TwinCAT RT Ethernet Driver installed. Select the NIC that will be used to connect to IO.

If no Ethernet adapters are listed, then please return to the “Install the Beckhoff Real-Time Ethernet Driver” section in Part 1 of this blog series.

If EtherCAT devices are already connected to the PLC, you can add them to the I/O tree by either manually adding the devices in the correct topology or scanning for devices. To scan, right-click the EtherCAT Master and select “Scan.”

Note: Scanning is only possible when the PLC is in Config mode.

Now you can activate the hardware configuration using the steps icon in the top ribbon:

If the button is grayed out, make sure you have selected the correct target in the TwinCAT XAE software and have a valid route.

When the Activate Configuration confirmation window appears, click “OK.”

If issues arise during this step, you may need to troubleshoot your hardware setup and verify that your TwinCAT project is configured correctly.

If your Beckhoff IPC does not have runtime licenses installed, which is common during an initial setup, TwinCAT XAE will prompt you to generate trial licenses. Click “Yes” and follow the prompts.

If you have purchased full runtime licenses, you can install them in a later step to replace the trial licenses.

Enter the Captcha required for trial licenses.

You can now click the login button to log in to the PLC. Once logged in, you can also click the start button if you need to start the PLC’s runtime.

You can now click the login button to log in to the PLC. Once logged in, you can also click the start button if you need to start the PLC’s runtime. 

Activating Licenses

Activating licenses in TwinCAT can be somewhat tricky, and this walkthrough will cover the basics. For further help with licensing, your contact at Beckhoff is a great resource.

First, you’ll need to select the proper license device. If using a USB dongle or card, it is critical that you select the right device before sending your license request file to Beckhoff. License request/response files are tied to device IDs, and so once a request has been sent and a response received, that license can only be used with that device. To change devices, you’ll have to get in touch with Beckhoff headquarters in Germany, and depending on your location, that might take some time. So try to avoid that by getting the license device correct first!

To select the proper device, go to System > License.

If you’re using a dongle and it’s already in the project, you can select it from the License Device dropdown in the “Order Information (Runtime)” tab.

If you are not using a dongle, select Target from the dropdown to bind the licenses to the Beckhoff IPC’s hardware ID. In this case, you can skip the remaining dongle-related steps and proceed directly to generating a license request.

We do recommend the use of a dongle when possible, so the IPC can be replaced without losing licenses.

If the dongle is not already configured in your project, click “Add…” to the right of the dropdown to add it. The dongle will then appear under License in the project tree.

After you click “Add…”, the License Device window will open. From here, you can select the appropriate dongle on your target Beckhoff IPC by clicking “Search in I/O Configuration…” or “Search USB Dongle on Target…”.

To use either option, TwinCAT must be in Config mode. You can switch to Config mode by clicking the blue gear icon in the TwinCAT engineering environment. After selecting the correct dongle, return TwinCAT to Run mode by clicking the green gear icon.

If the dongle doesn’t appear while searching, be sure your IO is configured correctly and the IPC recognizes the dongle. When the dongle has been selected, the dongle status information should populate.

Now that the dongle is in your project, you can go back to the License window, and you should be able to select it in the license device dropdown. Make sure that when you select it from the dropdown, the system ID changes (indicating the dongle system ID is different from the target system ID). Also ensure the system ID of the dongle is something reasonable (e.g., not a bunch of 0s; this might indicate you’re not communicating properly with the dongle).

If you have multiple license devices (e.g. target and a dongle), a “License Device” column will appear in the table at the bottom of the window. Make sure to select the correct device that you’d like to store each license on (most likely choose the dongle for all licenses).

Now that we’ve selected the correct license device, we need to generate a license request file. To do this we’ll first need to enter a license ID (provided by your contact at Beckhoff) in the license ID box. You can also enter a customer ID and a comment, but these are optional. Once you’ve entered a license ID, click “Generate File…”.

TwinCAT will prompt you to save the license request file to your programming computer. Save the file, then, when prompted to “Send license request to Beckhoff,” select “No”. We’ll send the file manually instead.

Note: This is your last chance to turn back before tying licenses to a device ID! Check over your license hardware setup and make sure everything is in order. If there are problems, regenerate the license file with the corrected settings before sending to Beckhoff.

Locate the license request (*.tclrq) file you just saved. Create a new email, attach the file, and send it to tclicense@beckhoff.com.

If everything is set up correctly and your license request is valid, Beckhoff will respond with an automatically generated email that has a license response file (*.tclrs). Save this file to your programming computer.

If the file is not attached to the email, the email will include whatever issues the automated system had with your license request, and you may need to work this out with your Beckhoff contact.

Back in the license window, use the “License Response File” button to select the license response file. For the new license response to take effect, you’ll need to restart TwinCAT on the target, which you can do with the green gear icon.

If everything worked properly, the Current Status column in the License window should be green and read valid for every license. You may need to refresh the window (close it and re-open it) to see this status change.

Now that we’ve correctly activated and configured the licenses, we are ready to configure the HMI server, which we cover in part three of this blog series.

The post Beckhoff Setup Basics: Getting Started with a Beckhoff PLC appeared first on DMC, Inc..

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

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

AutoHotkey is a simple scripting tool that allows you to program custom keystrokes and commands. Though simple in design, it’s a very powerful tool; it’s able to perform tasks such as launching apps, making mouse movements, scheduling tasks, and so much more. AutoHotkey has some great documentation for writing scripts, so I’ll cover the applications I’ve found to be the most useful and some relevant examples.

Comment Tag

The script that I use most often is a comment tag. This script grabs the current time and date, types them out in a clean format, and adds “DMC:[my initials].” Now, you can track changes at the click of a button. For my example, It would end up looking like this:   -12/06/2019-DMC:JAK-

;CommentTag.
^!d::
FormatTime, Time,, MM/DD/YYYY h:mm
SendInput -%A_MM%/%A_DD%/%A_YYYY%-DMC:JAK-
return

Multi-Device Monitoring

 An example of when I used this script was when adding device blocks in PLC programming.  In my use case, we had hundreds of devices. We wanted to link the output of the block to its instance memory, so we could monitor the status of these outputs. Therefore, I made a script that would paste what was in my clipboard (the base struct), append each output, and finally link it to each output of that device.  It took me only about 90 seconds to write the script and saved me a ton of blood, sweat, and tears.

;Simocode Motor.
^!s::
Send, ^v
Send, .bOutForward {Enter}
Send, ^v
Send, .bOutAuto {Enter}
Send, ^v
Send, .bOutAlarm {Enter}
Send, ^v
Send, .bOutPLCControl {Enter}
Send, ^v
Send, .rOutCurrent {Enter}
Send, ^v
Send, .rOutCurrent_L1 {Enter}
Send, ^v
Send, .rOutCurrent_L2 {Enter}
Send, ^v
Send, .rOutCurrent_L3 {Enter}
Send, ^v
Send, .wOutStatusWord {Enter}
Send, ^v
Send, .bOutInterlocksOK {Enter}
return

Shortcuts

Another great use case is when there are tools or functions that don’t have hotkeys. A project I was working on had a button that changed the view of the window but had no keyboard shortcut back to the main view. Since we can script mouse movements, I was able to navigate to the button and simulate a click—returning to the main view.

;main view in GRAPH
^!q::
Send ^1
MouseMove, 71, 148, 0
MouseClick
Send ^1
return

If you are using mouse movements, you can use the WindowSpy.ahk script in the installation folder to figure out where you need to move the mouse!

Changing Tags While in Run Mode

Another time I used this script was on a Rockwell project. There were many of us working off the same PLC, so it had to be in run mode. This made it impossible to do a “Find and Replace” function since each rung must be put into edit mode before any changes can be made. This made my job of updating hundreds of old tag references and add g_ to the beginning (pointing to the new tag) a lot more difficult.  Since I couldn’t use the “Replace” function, I made an AutoHotkey script to help me out. To use this script, I used the “Find” feature and once the relevant tag is found, I ran the script to edit the rung and change the tag. I didn’t even have to move the mouse off the next button!

+\::
SendInput {Control Down}{Shift Down}{s Down}{Control Up}{Shift Up}{s up}
send {Enter}
Send {Home}
Send g
Send _
return

As you can see, AutoHotkey is an incredibly versatile, essential tool for speeding up workflows and creating additional functionality to your automation tools.

Learn more about DMC’s expertise in PLC programming and contact us today to get started on your next project. 

The post Using AutoHotkey in PLC Programming appeared first on DMC, Inc..

In this scenario, I will be using VMWare as our virtual machine software, RSLogix as our automation software, and an eWON module as our remote access hardware. Other solutions such as Virtual Box, TIA Portal, and Tosibox should have similar setup. However, I will not cover them here.

Step One:

Start eCatcher on your host machine and connect to your remote eWON module. This should add an additional network adapter when you open Network and Sharing Center in your host.

The eWON module should automatically set a static IP address. You can find this by clicking the blue text next to Connections.

Step Two:

Select Properties and find Internet Protocol Version 4. Select that option and click into its properties.

You should see something like this:

Step Three:

Next, you will setup a NAT connection on you VM. To do this, open the Virtual Network Editor. It is important to set this up through the VNE because sometimes issues can result from simply selecting a NAT connection through the Settings tab. The example below is how it should look when set up through the VNE.

Step Four:

Go to the settings tab and make sure that you are connected to the VMNet that we just configured to be NAT.

Just to double check that the network settings were properly applied, hover your mouse over the your network connection in the bottom right corner of your VM. You should see Network Adapter: Custom (VMNetX) in the tool tip.

Step Five:

Go to the Network and Sharing Center of your VM to ensure that your IP settings are set to automatic. It should look like this:

Step Six:

Open your RSLogix Project as well as RSLinx. Inside of RSLinx, go to the Communications tab and click Configure Drivers.

Add a new Ethernet Devices Driver to the Configured Drivers list.

Now, inside of RSLogix, click the Communications tab and select who active. Here, you should find the ethernet driver and the station you entered earlier. 

Select the PIC to complete the process and go online.

FAQ:

Q: Why is browsing the network is taking a such a long time?

A: Try connecting to the PLC directly and not browsing the whole subnet.

Q. My device has a yellow question mark next to it and I can’t go online because the button is grayed out (shown below).

A: This means that you do not have the EDS file installed. By right clicking the device you can select install EDS and then walk through the installation steps.

Learn more about DMC’s Allen Bradley PLC Programming services and contact us with any inquiries. 

The post Connecting to an Allen-Bradley PLC through an eWON Module appeared first on DMC, Inc..

What?

Multi-User Server (MUS) Commissioning Mode is a TIA Portal tool used to ease the commissioning process when multiple engineers are making online changes and downloading concurrently.

Why?

The main advantage of using Commissioning Mode is the ability to ensure consistency between the server project and the PLC while multiple users are downloading to the PLC. This feature will also alleviate the headache of having to coordinate download efforts and ensure a consistent program between many local sessions or even single-user sessions.

One common theme of using MUS while commissioning is the potential to see offline/online differences with the PLC when they aren’t really there. Timestamp differences are not handled automatically, so if someone performs a download to the PLC that comes with a timestamp, other engineers (even after refreshing from the server copy) will see differences between their project and the project downloaded to the PLC.

Without Commissioning Mode

After downloading to the PLC from the Session B project, it shows offline/online consistency, but Session A now shows conflicts. This typically happens when the order of Download/Check-in/Refresh is not done in the correct order and is usually a result of a timestamp difference between the projects. When downloading from Session A at this point, Session B (even when up to date with the server copy) will still show online/offline differences.

If you complete a comparison in Project A for what’s different, it will show consistency between the online and offline projects. This can be attributed to timestamp differences that pop up depending on the order of operations mentioned above.

Commissioning Mode Enabled

To incorporate changes made when commissioning mode is turned on, simply download the changes to the server. This will also check the changes into the server copy to ensure consistency. This process will also make time stamps consistent across projects, eliminating mystery offline/online discrepancies.

When Commissioning mode is active, downloading the program will show the need to refresh the server in other local sessions.

How?

You can turn on Commissioning Mode with a single click in MUS Administration, provided you meet certain conditions. Siemens lists these conditions as:

• All local session changes checked in and updated (current with server copy)
• No selections (flags) are made in the local sessions
• The PLC is downloaded with the most recent version of the server project

When you have met these conditions, and you click the Multiuser Commissioning, you’ll see the operating mode change to ‘Commissioning Mode.’ Siemens recommends leaving the ‘Check for different data…’ option checked (which it is by default) and should only be deactivated if using an S7-300/400 CPU.

Caveats?

This feature is available for TIA Portal V15.1 and will not be available for older versions of Portal. Multiuser server features go back a few versions, but this is new as of 15.1.

Learn more about our Siemens Expertise and TIA Portal Development Services. Contact us with any project inquiries.

The post Advantages of Siemens Multiuser Commissioning Mode appeared first on DMC, Inc..

Our application had some lag when loading new screens because of the large amount of tags required to populate the screens. FTV SE can pull up to about 200 tags from a Micro 850 per second; with larger PLC programs taking more time to send tags.

For smaller HMI/PLC applications, all of the PLC tags from a Micro 850 can easily be pulled quickly while loading a screen. For larger applications, there may be some delay after opening a screen before all of the tags on a screen are loaded from the PLC and ready to populate their indicators.

However, FactoryTalk lets you load screens snappily, even when talking to smaller PLCs or when large amounts of data need to be loaded.

A few tips and tricks are below!

1. Decrease Maximum Tag Update Rate (per Screen) – This rate controls the shortest possible time it will take the FactoryTalk application to acquire or send a tag. This is important for buttons and indicators that need to have a fast response, as well as for loading screens quickly.
   1. To access this setting, right-click on a screen, select Display Settings, and under the Properties window, select the drop-down for Maximum Tag Update Rate. The default setting is 1 second; this may appear slow for most applications. A rate of 0.25 or 0.1 seconds will usually allow the screen to react without visible lag.
      
   2. This may have different levels of impact with different PLC platforms – this should be a good solution for fast performance with the Logix line of processors. We found that additional steps were needed with the smaller Micro800 line.
   3. Keep in mind that your application may not be able to keep up with faster Tag Update Rate setpoints. This is dependent on the number of tags you have on the screen and the number of tags that are being fetched in the background (read on to learn more about background fetching!)
2. Add Screen Caching – FactoryTalk View Site Edition's default behavior is to close any screens that aren't actively being displayed. This minimizes PC resource usage and allows you to edit screens in an active application (one of my favorite features). However, you can individually configure each screen to be cached, so that the screen is kept in memory even when it isn't shown on the screen. This greatly improves behavior for laggy screens.
   1. To access this setting, right-click on a screen, select Display Settings, and under the Properties window, choose Yes for Cache After Displaying.
   2. You also have the option to select whether the screen is Always Updating or not. Always Updating is a good selection for screens that don't populate immediately even when cached – we found this was the best choice for most of our larger screens with lots of tags. Keep in mind that if the screen is Always Updating, it will always be polling tags from the PLC. This may influence the update rate of tags on other screens in your application.
      
3. Add Screen Pre-Caching – If Screen Caching improved your application's performance, you may also want to consider Pre-Caching your screens! Pre-Caching pre-loads the screens while the application is starting up, without displaying them on the PC. Cached screens without pre-caching may still be slow to load the first time they're displayed; pre-caching makes the display pull from an already cached screen the first time that it's loaded.
   1. This can be done via a Startup Macro. Create a macro in the Explorer pane under Logic and Control > Macros. Right-click to create a New Macro.
      
   2. In the Macro editor, add a call to the "Display" function for each screen that you'd like to precache. Use the \Z flag to cache a screen without marking it as Always Updating. Use the \ZA flag to cache a screen and set the screen to Always Update. (A full description of this function and possible flags is available in the FTV help files as "FactoryTalk View Site Edition Help > FactoryTalk View commands > Graphics commands > Display")
      
   3. When launching or creating your FTV SE Client with the FactoryTalk View SE Client Wizard, include your macro as the Startup Macro.
      

If you follow these tips, you should have a fast and snappy HMI!

Learn more about DMC's Rockwell Programming Services.

The post Maximizing FactoryTalk View Site Edition Performance appeared first on DMC, Inc..

We’ll assume you have either a stepper motor or servo with a built-in encoder that can be actuated by controller pulses. First, add the PLC to the project.

Once added, go to Device configuration to do a standard setup, like setting the IP Address, and then enable the first pulse generator, PTO1/PWM1.

Be sure this pulse generator has the PTO signal type.

Note that the Pulse output will be at Q0.0, and the direction output will be located at Q0.1. We can then wire these to our motor.

Next, we need to create a tech object. Click “Add new object” under the Technology objects folder, and then select “TO_AXIS_PTO.”

Next, when you create the text object, select “Pulse_1”. Also, be sure to choose the correct position unit; Here I’ve chosen degrees.

Finally, at a minimum, you should enter the pulses per motor revolution and the load movement per motor revolution into the extended parameters. This step will ensure that your commanded speeds and positions are correct.

If you are interested, now you have the full power of the technology object to go in much greater depth with your motion control configuration. For now, we want to get this done quickly, so we’ll leave it at the mechanics' parameters.

Now our tech object is configured, and we can program some motion. We can now build up a lot of complicated ladder logic, but if all we want is to make the drive spin, we only need two blocks: MC_Power to enable it, and MC_MoveVelocity to get it moving.

Here, for the “Axis” inputs, I entered the Technology object. I put a “true” in the enable input for MC_Power for it to always be on, set the Velocity to 360.0 degrees per second (60 RPM), and then wired up a pushbutton from the first PLC digital input to the execute demand. I can now download the project to the PLC, press the button, and have a spinning motor!

Of course, in a real production setting, you’d want to have the ability to reset the drive if there is a fault, make absolute and relative position moves, and probably want a more thought out and formal structure to your code.

I hope this example showed you how simple it is to get basic motion working on the S7-1200, so you can avoid headaches and spend more of your engineering effort on the specifics of your own use cases. There is quite a lot of cool stuff you can do with simple motion control. If you’d like help with any of your motion problems simple or complex, please feel free to contact DMC.

Learn more about our Motion Control expertise and PLC programming services. 

The post Simple Motion Control With an S7-1200 PLC and a Pulse Train Output (PTO) appeared first on DMC, Inc..

Cyclic vs. Interrupt Code

Code on a PLC is called either cyclically or by an interrupt. Cyclic code runs start to finish repeatedly as fast as possible, so long as the CPU is not interrupted by an interrupt call. Interrupts pause the code currently running on CPU, call the interrupt code, and then once the interrupt code is complete, resume what the CPU was doing. Most PLCs can tie interrupts to cyclic timers, startup, value changes, and/or errors. Interrupts can also interrupt other interrupts if they are of a higher priority.

The diagram above shows what a PLC’s CPU spends its time doing. The pink represents cyclic code that would take the CPU 5ms to complete if it weren’t interrupted. The green represents the communication load on the CPU taking up to 0.15ms of every 1ms, and blue is the motion control code called every 5ms by a cyclic interrupt. In this example, the motion control interrupt is the highest priority, meaning it can interrupt communication and cyclic code.

Cyclic code is commonly referred to as the main PLC code. Siemens refers to cyclic code as a program cycle or OB1, and Allen-Bradley calls it a continues task. Interrupts, other organizational blocks in Siemens or event tasks in Allen-Bradley, allow the designer to specify precisely when the interrupt code should run in relation to an event or a timer.

For example, high-speed counters are typically tied to hardware interrupts, allowing a hardware input to increase the count in the PLC immediately. View this blog for examples of high-speed counters. This means that the high-speed counter can count multiple inputs before the PLCs main code has completed a full cycle. Similarly, PID control loops and motion control code are offend tied to cyclic interrupts, with varying cycle times. Physical systems that are slow to respond can be tied to cyclic interrupts with long cycles. This, in turn, reduces the CPU load. Systems that are quick to respond can be tied to much faster cycles allowing for tighter control, at the cost of CPU load.

Cycle Time

PLC cycle time is defined as the time it takes to run the cyclic code start to finish once with interrupts. Because of the number and frequency of interrupts between cycles, cycle times also very. In most cases, we are concerned with the maximum cycle time since this corresponds to how long it will take the PLC to respond. A general rule of thumb is to assume that the PLC could take as long as twice the maximum cycle time to respond. This means if we have a running signal indicator light, it could be up to twice the max cycle time between when the PLC gets the running signal and the light turns on.

Most PLCs monitor the cycle time and will alarm if the cycle time exceeds a maximum threshold. The specific threshold should be configured based on the application and the maximum acceptable response time of the PLC. Cycle times are particularly important in safety applications where the PLC’s response time can add to the response times of other components.

Reducing Cycle Time

There are a few methods to decrease the PLC's response time if cycle times must be reduced. Firstly, consider if the PLC’s CPU can be upgraded. A faster CPU will execute code faster and reduce the overall cycle time. This method is particularly effective for projects that have a lot of motion control and PID control loops, as these functions are generally very CPU intensive.

Siemens 1511 CPU (14.9ms Cycle Time)

Siemens 1517 CPU (6.3ms Cycle Time)

The next aspect to consider is the communication load. Communication load is defined as how much of the CPU’s time is spent communicating with other devices, and typically ranges from 15% to 50%. Upgrading the CPU can help reduce the communication load some, but for the most part, reducing communication load is a function of the communication method(s) and quantity. Consolidating the number of devices the PLC must communicate with and/or using communication methods with less overhead can both help but are often harder to implement.

Another method for reducing cycle time is optimizing the code itself. Moving pieces of code that do not have to run every cycle into cyclic or other interrupts can help reduce mean cycle times, but may not have much effect on the maximum cycle time. Moving code into interrupts can also make testing the cycle time more difficult as the interrupts may or may not occur in every cycle.

Monitoring Cycle Time

Siemens' S7 TIA Portal PLCS:

TIA Portal has a built-in tool that allows you to monitor the cycle time of a physical PLC or a simulation of the PLC. To monitor the cycle time, first, go online with the PLC, upload the PLCs code, and then open Online & Diagnostics. Under Diagnostics>Cycle time, you’ll see a bar chart with the current PLC cycle time. The light blue box represents the allowable cycle time, and a red bar indicates that cycle time has exceeded the maximum. This is shown in the diagram below. 

To change the allowable cycle time, open the PLC’s Device configuration and under General>Cycle, update the maximum cycle time. You will have to be offline with the PLC to change this value and then redownload to the PLC for the change to take effect. Remember that the max observed cycle time may not be the actual max cycle time. This can happen if the code running on the PLC has many interrupts, or long and looping pieces of code called by interrupts.

Allen-Bradley and Other PLCs:

Finding the cycle time of other PLCs can be done more manually, although it’s no less relevant or useful for developing well-optimized code. The simplest way is to check the system time at the start of each cyclic call and compare the current system time to the previous system time. This method will include the overhead time the PLC takes to communicate and scan I/O. With a little more logic, you can easily find the min, max, and mean cycle times.

Understanding cycle time, cyclic calls, and interrupt calls is key to architecting successful PLC code and just one of the areas DMC excels at. Good architecture early on in a project can save time and allow the uses of more cost-effective hardware, while still meeting project requirements explicit and implicit.

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

The post PLC Cycle Time appeared first on DMC, Inc..