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

This blog is Part 1 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 first 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 initially set up your Beckhoff IPC to run PLC code and a TCHMI server.

Within DMC, we often find ourselves setting up a new IPC, and it has proved very helpful to have a standardized guide to start with. So, we’ve compiled this guide to serve as a resource both within our organization and externally, and we’ve updated it for TwinCAT build 3.1.4026. Some key steps have changed significantly with build 4026, so if you are using an earlier version, please consult the version notes on the package install steps.

Note: If you aren’t planning to use TwinCAT HMI, you may disregard any steps specific to it. If you find yourself needing to use it in the future, you can perform those steps at any point.

The process below was developed and documented on a Windows 10 development machine, but the process will be functionally identical for Windows 11.

Term Definitions

Throughout this blog series, we 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.

Power-On and Connection

Most Beckhoff IPCs do not have a power button; rather, they power on as soon as power is supplied. When ready, supply power. A keyboard, mouse, and monitor will also be useful for first power-on and initial configuration.

Beckhoff Device Manager

If your device is a Beckhoff IPC, Beckhoff Device Manager will generally run on startup. For a basic setup, you can step through the wizard with default options, and on the last page, uncheck the box that says “Run Beckhoff Security Wizard on next startup,” so it won’t run on startup in the future.

Change NIC Settings

We’ll begin with some basic network setup. Open up the IPC’s adapter settings by right-clicking on the Network Icon in the system tray and selecting “Open Network & Internet settings”.

From this window, select “Change adapter options” (“Change adapter settings” on the left side of the window in Windows 7).

This window should display the Network Interface Connections (NICs) available on your Beckhoff IPC. There are often two (though there may be more or less) – one that you can use to connect a programming computer and another that can be used to connect to IO racks/devices. Before you proceed, identify which NIC you will be using for each purpose and the IP addresses that you’d like to assign to these NICs. A helpful (but optional) step is to rename each NIC to describe its purpose.

To do this, right-click on a NIC and select Rename. In this example, Programming Port will be used for programming, and EtherCAT Master will be used to connect to IO.

To change IP addresses for these NICs, right-click on them and select Properties. Then navigate to Internet Protocol Version 4 (TCP/IPv4) and select Properties. You can then input your selected IP addresses. For advanced network configurations, the subnet mask can also be changed at this point.

For this tutorial, we will be using:
Programming Port: 192.168.42.42
EtherCAT Master: 192.168.43.43

(Optional) Rename PC

While this step isn’t necessary, it can be helpful to rename your PC so if it’s connected to a network in the future, it can be easily identified. To do so, navigate to Start Menu > Settings > System > About > Rename PC.

After you rename your IPC, it will prompt you for a restart. You may postpone this to save time, as some of the following steps will also require a restart.

Install Chrome or Firefox If Using TwinCAT HMI

Google Chrome and Mozilla Firefox work well with TwinCAT 3, and we’ve seen issues with other browsers in the past. So, we recommend you install one of these browsers if you’re going to be using TwinCAT 3 HMI on this IPC.

If you’re working on an IPC that cannot be connected to the internet during setup, you will need a standalone installer.

• Chrome requires a special installer for this.
  • At the time of writing, Google does not make it clear on the webpage whether the installer is standalone or not.
  • The downloaded file from the given link should contain “Standalone” in its filename, which confirms it is correct.
• Firefox install files are generally standalone by default.

Download or transfer the install files to the IPC and follow the instructions in the installer. Once installed, you may want to launch the browser and disable distracting features such as suggested homepage links or password-manager prompts.

Create a Beckhoff Account

If you do not already have a Beckhoff account, you must register so you can download software. Beckhoff generally requires an account for any software downloads, so this will be useful going forward as well. Go to https.www.beckhoff.com, where you can register for an account as shown below.

Setup Packages

The installation process has changed significantly for build 4026. Package Manager is a new feature that streamlines downloading and installing packages, and it must be used when working with 4026.

Legacy 4024 installation notes

If you are using 4024, you have two options. You may install legacy packages through Package Manager. Or, you may follow the legacy installation procedure using EXEs.

The legacy installation procedure:

1. Visit https://beckhoff.com/, log in, and navigate to Download finder > Software and tools.
2. On your programming PC, you will need eXtended Automation Engineering (XAE) and the engineering versions of any TwinCAT functions.
3. On the Beckhoff IPC, you will need eXtended Automation Runtime (XAR) and the runtime versions of any TwinCAT functions.
   • Note: If you require a build of 4024 not available on the website, you will need to reach out to Beckhoff support for assistance.
   • TwinCAT Functions are Beckhoff-developed applications that allow for special functionality on the PLC. They will have their own separate EXE to install.
   • Common TwinCAT Functions include the following–install the ones required based on your project; you can install more functions later if required.
     • TF2000: TwinCAT HMI
     • TF3300: TwinCAT Scope
     • TF5000: TwinCAT NC PTP
     • TF6100: OPC UA Server
     • TF6250: Modbus TCP
     • TF6255: Modbus RTU
     • TF6310: TCP/IP
4. For any Engineering EXEs, install them onto your programming PC.
5. For Runtime EXEs, transfer the EXEs to your IPC, then install them. Install XAR first, then the remaining packages.

You cannot use the legacy EXE installation along with the newer Package Manager-based installation. If you need to upgrade or change versions, you must carefully follow the instructions in this Infosys page before installing the other version.

Install Package Manager

You will need Package Manager on the IPC–it should come preinstalled with Beckhoff 4026 IPCs. You will likely also need Package Manager on your programming computer.

Once you have registered or logged in on Beckhoff.com, go to Download Finder as boxed in the figure below.

Package manager should be the first option at the top of the page; if it isn’t, search for it in the download finder.

Download the available version as an EXE, and install it on your programming computer and IPC if it is not already installed.

Configure Feeds

Feeds are repositories of packages that Beckhoff provides. Beckhoff provides a Stable Feed, Outdated Feed, and Testing Feed. We recommend using the Beckhoff Stable Feed for any production systems. See this Infosys page for details on each feed.

If your IPC is (or can easily be) connected to the internet directly, you will likely find it easiest to download and install your required packages from the online feeds.

If the IPC cannot be connected to Beckhoff’s servers, then you can follow these instructions from Beckhoff to transfer the packages onto your offline IPC. Beckhoff supports using a file directory with package files as a personal feed. Beckhoff also supports a compressed file containing all selected packages, transferred from a programming computer.

To configure the feeds, launch Package Manager.

Click the “+ Add new feed” button to add a new feed.

As discussed, you may enter the Beckhoff online feeds if connected to the internet, or if offline, you may use any local folder as a feed.

If selecting the outdated feed, you may get a disclaimer as shown. If you are comfortable with the disclaimer, you may accept it by clicking “Yes,” and the feed will be added.

Multiple feeds can be added, as necessary, and will be used in the priority order displayed.

Package Manager will next ask to integrate with Visual Studio (if installed), or XAE Shell or XAE Shell 64-bit. XAE Shell 64-bit is a more modern, faster version of XAE Shell, newly added with the release of 4026.

Select a location to install the TwinCAT Packages.

Note: This is a different default location than legacy 4024 XAE/XAR installations.

Use Package Manager to Install TwinCAT Packages

Once Package Manager is set up, we can now install packages onto the IPC.

If the IPC is connected to the internet and can access the Beckhoff-hosted feeds, you will see a list of available packages to install.

The packages can be filtered by Engineering Packages and Runtime Packages:

• Engineering Packages are meant to be installed on your programming computer and will allow you to connect, modify, or control the PLC.
  • Common examples include:
    • TwinCAT Standard
    • TwinCAT XAE Shell / XAE Shell 64-bit
    • TE9000: Safety Editor
    • TE1300: TwinCAT Scope
    • TE2000: TwinCAT HMI
• Runtime Packages provide applications that will run on the Beckhoff IPC.
  • Common examples include:
    • TwinCAT Standard
    • TC1000: TwinCAT ADS
    • TF2000: TwinCAT HMI Server
    • TF3300: TwinCAT Scope Server
    • TF5000: TwinCAT NC PTP
    • TF6100: OPC UA Server
    • TF6250: Modbus TCP
    • TF6255: Modbus RTU
    • TF6310: TCP/IP
    • Beckhoff Device Manager

Select all the packages that you need for your system. Then either click Install (Blue Download button) to install locally, or Download to send to an offline IPC (Press 3 dots button, then “Download”).

Once all the packages are selected, either click “Apply Modifications” to install them locally, or click “Start Download” or “Start Download as a Zip”. Please refer to Infosys for more information on installing offline feeds.

Install the Beckhoff Real-Time Ethernet Driver

Next, you will need to install the Beckhoff Real-Time Ethernet Driver on the NIC to which you plan to connect your IO. This will allow the Beckhoff IPC to communicate with said IO.

Navigate to C:\TwinCAT\3.1\System and run TcRteInstall.exe.

In the Compatible devices section, select the NIC that you will use for IO (EtherCAT Master if you configured your NIC settings as described earlier) and click Install.

After the process is completed, the NIC should move to the Installed and ready-to-use devices (real-time capable) section. You can close out of the application.

Set Firewall Settings

It’s important to maintain secure firewall settings on industrial devices to avoid allowing unwanted access to an industrial network, especially if said devices will be connected to the internet. But we must allow communication to the TwinCATTwinCAT runtime/HMI server via a programming computer to download code. To do this, we will enable a few rules within the firewall. Beckhoff will pre-configure certain ports on IPCs, but we recommend going through these steps to confirm that no traffic will be blocked. You may also need to refer to this section if firewall settings are inadvertently changed or reset.

Navigate to Start Menu > Settings. In the search bar, search “firewall” and open Windows Defender Firewall.

In the window that appears, select Advanced Settings on the right.

In the Windows Defender Firewall with Advanced Security window, select Inbound Rules on the left and click New Rule on the right.

Details on important TCP/UDP ports required for TwinCAT Services can be found on Infosys, but in our experience, the most important ports are:

• TCP 48898 (TwinCAT ADS Not Secure)
• UDP 48899 (TwinCAT ADS Discovery)
• TCP 8016 (TwinCAT ADS Secure)
• TCP 1010 (TwinCAT HMI <=1.12 Local)
• TCP 1020 (TwinCAT HMI <=1.12 Incoming)
• TCP 2010 (TwinCAT HMI >=1.14 Local)
• TCP 2020 (TwinCAT HMI >=1.14 Incoming)

Step through the wizard, using Port as the rule type, and add rules for all required ports.

Change AMS Net ID

The AMS Net ID is used by the TwinCAT XAE programming suite to identify specific PLC runtimes, and to connect to that runtime. It is made up of 6 values from 0-255, period-delimited. At DMC, we usually set the AMS Net ID to be the same as the IP address of the programming port of the Beckhoff IPC, followed by “.1.1”, for instance, “192.168.42.42.1.1”. This makes it easier to remember than using an entirely different number (though any value technically works).

Click on the TwinCAT gear icon in the system tray and select Router > Change AMS Net ID. If this gear icon does not appear in the system tray, you may need to restart your IPC first. After typing in your selected AMS Net ID and confirming, you will be prompted to restart. Now is a good time to do so.

Legacy Troubleshooting Steps

In the past, when using build 3.1.4024, we have sometimes seen an error message when trying to put the PLC into Run Mode:

Init4\RTime: Start Interrupt: Ticker started >> AdsWarning: 4115 (0x1013, RTIME: system clock setup fails)

We have not seen this yet with build 3.1.4026 but have preserved the resolution here. If you encounter this error, you can navigate to C:\Program Files (x86)\Beckhoff\TwinCAT\3.1\System and run win8settick.bat as administrator. This sets some TwinCAT-required clock settings and resolves the error.

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

Such is the fate of the InGear NET.LOGIX Driver.

This post explores this recent shift in the tech ecosystem; what exactly happened to InGear, why support has ended, and what you should use instead if your application still relies on NET.LOGIX today.

InGear Drivers End-Of-Life

Once a common choice for communicating between .NET software and Allen-Bradley LOGIX series PLCs, all software drivers have been fully discontinued. This isn’t a “maintenance mode” situation; driver development has stopped, and the license servers used to establish new development environments are no longer available, making ongoing support impossible.

Where did InGear go?

InGear NET.LOGIX was designed at a time when .NET drivers were the primary method for communicating with Allen-Bradley Logix controllers. Since then, the ecosystem has evolved:

• Rockwell has extended its native support for other communication options.
• Open-source libraries like libplctag have gained greater adoption among developers.
• Security and deployment expectations have increased significantly, changing driver demands.

With this shift, InGear NET.LOGIX’s developer decided that it was better to focus its efforts and investments in other areas.

And don’t feel bad if you missed the announcement that support for InGear NET.LOGIX driver has ended. There was no formal public EOL date; their website simply displays an unprotected 404 page with no documentation, downloads, or publicly available support channels.

Which Driver Should I Use Now?

If your application still relies on InGear Net.LOGIX, the good news is, you’re not stuck. We have successfully migrated systems to modern, actively maintained alternatives. In a previous post, we walked through a free and open-source option: Replacing the NET.LOGIX InGear Driver with libplctag.NET, including considerations to make about system architecture as well as migration tips.

This is just one of the many instances in which DMC engineers regularly modernize PLC communication layers as part of broader automation and application development projects, helping teams reduce technical debt and maintain system reliability and efficiency.

The post Support Ended for InGear NET.LOGIX Driver appeared first on DMC, Inc..

To address this, DMC applies modern version control, continuous integration, and continuous deployment practices widely used in traditional software development. These processes, and the software that enables these processes, seek to lower the barrier between development (Dev) and operations (Ops). This blog will review how to apply the foundational DevOps principle of version control to Rockwell PLCs.

Version Control and Git

Version control systems (VCS) are essential for applying modern DevOps practices to Rockwell PLC development. These systems help create a standardized and reliable way for teams to collaboratively develop, manage, and test code efficiently.

Git, which is a distributed version control system (DVCS) originally created by Linus Torvalds, enables effective collaboration among developers through useful features such as branching and merging. Some of the key concepts to understand in Git include the following:

Local/Remote Repository

A full copy of the entire code base is synchronized to a developer’s local repository. This means that each developer has their own complete version of the project on their computer. Developers can then synchronize their code changes with others by pushing their updates to the remote repository and pulling changes from it into their local repository. This process allows multiple developers to collaborate effectively by keeping their work up to date and integrated with the team’s overall progress.

Non-Linear Development

Multiple developers can work on different features simultaneously without interfering with each other. Git facilitates this by allowing branching, merging, and pulling code changes. It also has built-in data integrity mechanisms that help prevent lost changes and keep the history consistent

The main branch of code is called “main” or, in legacy systems, “master”. This branch should generally be the head of development and is the only branch present when first starting a project.

Other branches of development branch off from main, usually with a focus on implementing a specific feature or fixing a specific bug. After this code is completed, it is merged back into main (which can be configured to require appropriate permissions), and then usually either deleted or compressed into a single commit.

Local Repository Command

These core Git commands interact directly with your PC’s local repository. It is important to note that these commands do not affect the remote repository, which requires a different set of commands that will be covered next.

• Branch: This command allows you to create a copy of an existing branch, usually the main branch, so you can work on new features separately without affecting the main codebase.
  • This command stages your changes, preparing them for commit to the active branch. It essentially tells Git which changes you want to include in the next commit.
• Commit: This command saves the staged changes to the active branch, creating a new snapshot of your project at that point in time.
• Merge: This command combines two branches into a single branch, allowing you to integrate changes from different lines of development.

The following additional commands are also commonly used as part of the normal git workflow. These commands are typically utilized by more experienced developers who are comfortable with advanced git operations and want to manage their code more effectively.

• Stash: This command allows you to temporarily save the changes you have made to your modified files in your current working branch without committing them. This is useful when you want to switch contexts or branches but are not yet ready to commit your work.
• Switch: This command is used to move between different active branches of development within your repository. It enables you to quickly and efficiently switch your working branch, making it possible to work across features or fixes.
• Diff: This command compares two different branches and highlights the differences between the files contained in each. It is particularly useful for reviewing changes, understanding what has been modified, and preparing for merges or code reviews.

Remote Repository Commands

These commands and concepts are commonly used to facilitate interaction between the local repository on your personal computer and a remote repository hosted on a server. They help synchronize and manage changes efficiently across different environments:

• Fetch: This command downloads commits, branches, and tags from a remote repository into your local repository. It allows you to see changes made by others without merging them into your working branch immediately.
• Pull: This command fetches changes from the remote branch and then merges those changes directly into your current working branch. It is a convenient way to update your local branch to the latest remote changes in a single step.
• Push: This command sends your committed changes from the local working branch to the designated remote branch. It is used to share your updates with others and keep the remote repository up to date with your work.

Merging

When developing, code differences and conflicts can arise when multiple developers work on the same file across different branches. When this occurs during a merge, it is called a merge conflict and must be resolved.

This is easily handled in traditional text-based programming environments using standard compare-and-merge tools like VSCode (free), which includes functionality for merging text files.

The following example shows a basic Python merge in VS Code. In this example, we had a main branch that was split off into another development branch, foo, which had its own function and function call added. During that time, the bar function and function call were added to our main branch. Because both branches modified the same file, a merge conflict was created. To resolve this conflict, we called git mergetool -t vscode to bring up the VS Code merge functionality. Git automatically understood what files to merge and what program to call because we configured the VS Code merge tool earlier.

The image of VS Code shows both branches (left/right) being merged, as well as the final merge result at the bottom of the screen. It is important to note that the developer could have chosen to merge the calls to the foo/bar functions without actually merging the function definitions. This makes this tool very powerful, but not error-proof.

For programs that are not text-based or are overly complicated to merge by hand, additional merge tools can be configured to simplify these conflicts.

Git and Logix Designer Compare Tool

As part of their standard product offering, Rockwell provides the Logix Designer Compare Tool to allow visual merging of Rockwell PLC code and to identify differences between PLC code. See the full Getting Results Guide from Rockwell.

This application not only offers a GUI for starting compare/merge operations, but also provides a full command-line interface to run them automatically. Based on our previous example with VS Code, the Logix Designer Compare Tool can be configured as a full git merge tool using the following commands. The path to the application can vary depending on where the tool is installed, which is accounted for by the additional path command.

git config --global merge.tool rockwell_merge

git config --global mergetool.rockwell_merge.path 'C:\Program Files (x86)\Rockwell Software\\'

git config --global mergetool.rockwell_merge.cmd 'RSLCompare.exe -m \$LOCAL \$REMOTE \$BASE'

After configuring the Rockwell merge tool, the development workflow operates exactly the same as if developing with a text-based language like Python, i.e., using standard commit, branch, merge, and push/pull commands.

Repeating the foo and bar example from earlier with Rockwell, I created a Studio 5000 ACD project with a single program/rung. From there, I created two branches of development:

• Foo – JSR to a new Foo routine, with basic logic
• Bar – JSR to the new Bar routine, with basic logic

When merging these branches, I encountered a merge conflict because the ACD file in both branches had been modified. I can resolve this by calling git mergetool -t rockwell_merge. This will tell git to take the file from both branches, as well as the base file they both originated from, and perform a three-way merge. The left content is the local branches, the right content is the remote branch, and the center content is the base branch that the local/remote branches diverged from. The following images show how this merge works:

After selecting all of our changes, we will select File → Save As… to save the resulting ACD file over our existing ACD file in our local repository. After we close the merge application, we can commit the merge result and push to our remote repository. Once this change is in the remote repository, other developers can use the same method to synchronize their code changes, enabling accelerated system development and programming.

Next Steps in DevOps

This tutorial introduced the basic concepts of Git, how to configure merge tools, and how to leverage them for Rockwell-based PLC development. Over the next few blogs in this series, we will review how to leverage Git and GitLab for continuous integration and continuous deployment (CI/CD).

In the meantime, you can work on refining your git skills and workflow with the following free resources:

• Git – Learn
• Git and GitHub learning resources – GitHub Docs
• Git Tutorials and Training | Atlassian Git Tutorial

The post Rockwell PLC DevOps: Modernizing Version Control appeared first on DMC, Inc..

What is libplctag.NET?

libplctag is an open-source C library that enables EthernNet/IP and Modbus TCP reading and writing tags on Rockwell/Allen-Bradley ControlLogix, Micro 850, and SLC 500 and MicroLogix PLCs. libplctag.NET is its .NET wrapper and is available on NuGet. You can find the libplctag repository and the libplctag.NET repository as well.

Advantages of libplctag.NET

One of the biggest advantages of libplctag.NET is that, because it is open source, it does not cost anything! Specifically, the library is dual-licensed under the Mozilla Public License 2.0 (MPL 2.0) and the GNU Lesser/Library General Public License 2+ (LGPL 2+). As mentioned above, libplctag.NET supports EtherNet/IP and Modbus TCP. The provided API is stable and is actively being supported and upgraded. The driver is lightweight, high-performance, and low on memory usage. The documentation and wiki provided in the repositories linked above are very robust and full of examples.

Example Tag Read and Write

Below is an example that demonstrates reading and writing a tag to an Allen-Bradley CompactLogix/ControlLogix PLC that was taken from the libplctag.NET documentation.

As can be seen in the above example, a new tag can be configured using a simple constructor. Read() gets the current value, and Get[Type]([default]) converts this value to [Type]; in the above example, that would be GetInt32(0), which converts the value to an int. Similarly, writing a new value is as simple as Set[Type]([default], [new_value]), which is SetInt32(0, updatedValue) in the above example, and then calling Write().

The post Replacing the NET.LOGIX InGear Driver with libplctag.NET appeared first on DMC, Inc..

Project Setup

We will start by creating a new project in TIA Portal, navigating to the “Devices & Networks” page, and adding our chosen PLC from the catalog. For this example, we will be using a `6ES7 212-1BE40-0XB0` more commonly known as a 1212C AC/DC/RLY.

Once the PLC is added, a pop-up will appear asking you to configure PLC security settings for the project. If you clicked cancel or had previously checked the box to prevent this pop-up from being shown, you can access it by clicking on the PLC in the Devices & networks page (the actual PLC, not the gray box around it), selecting the Properties and General tabs, selecting the Protection & Security dropdown, and clicking the Start security wizard button.

The first step is creating a password to protect the PLC project and data on the PLC. Both DMC and Siemens recommend setting this password to improve OT security, and since we will be enabling a web server on this device (while presumably connecting it to a larger IT network), it is a critical step towards protecting the PLC. It is important to note that once applied, this password cannot be removed – make sure it is documented in a secure place like a password manager available to everyone on your team. A Post-it on your monitor is not a great place to store this password.

The next security setting is the mode for PG/PC and HMI communication. Unless you know you will be communicating with a legacy device, you should leave this at the default option to only allow secure communication.

The next setting will be for setting up access control. This should be enabled to restrict who can perform actions on the PLC, such as changing the run mode or accessing our user pages.

The “access levels” option is a legacy option that was the only security option before V20. If setting up a new project, it is recommended to leave this unchecked and use the new User Management and Access Control (UMAC) feature.

In the next step, we will create one or more administrator users. This user will be able to perform all actions on a PLC that may be restricted, such as changing the mode between run/stop, updating safety settings (if available on your selected PLC model), changing drive parameters, or downloading new programs. It is important to store the login information in a secure place, and having a backup administrator user is a good idea.

The next security setting is selecting whether anonymous access should be enabled. This could be useful to provide read-only access to any user without logging in, but it does reduce security slightly. For this demo, we will leave it disabled.

The next page will need no changes as we are not using access control levels, and the last page will provide an overview of the settings you have chosen.

At this point, we can click Finish and get started changing PLC settings for the web server.

Getting Started

Back in Devices & Networks, open up the PLC properties. Each section below will guide you through the settings that need to be changed specifically for the web server.

General

• Here we can set the PLC name, plant information, and other designators.

PROFINET Interface [X1]

• Here, we will need to set an IP address and Subnet Mask.
• If this device will be accessible from an IT network, make sure the router address is set so that the PLC can be accessed outside the immediate local network.
• If the PLC will be performing any tasks where the time of day needs to be known, or if you would like logs to have accurate timestamps, enable the time-of-day synchronization and enter NTP addresses. For this example, we will use several NIST servers located in different geographic regions.

• At the bottom of this tab, make sure to enable the web server on this interface (we will enable the web server module later).

• Note: if your PLC has multiple interfaces, one may be set up for connecting to local devices such as drives, remote IO, or local HMIs, and the other may be configured for connection to a larger IT network. The router address, NTP server, and web server access would only be needed on the interface used for IT network access.

Web Server

• Check the box to enable the web server on all modules of the device and to permit access with HTTPS only.

• Certificate Type: Hardware-generated
  • For this blog post, we will skip the differences between the two.
• Further updates will be made here once we create an actual web page.

Time of Day

• Set the time zone and daylight savings settings according to your location.

Adding Users and Web Server User Roles

Before we download and test our setup so far, we will need to configure user roles to allow access to the web server and create some non-administrator users who can access it.

User Roles

In the project tree, open Security settings > Users and roles and then select the Roles tab.

We will create two new roles: the first is a Web Server Admin, who can perform all tasks through the web server. The existing administrator users will be added to this.

The second role will be a Web Server User role with permission to open only the user-defined pages we create.

Users

At this point, we can go back to the Users tab. The administrator users created during the project security setup should be added to the Web Server Admin role. We will “forget” to add the second administrator user to demonstrate what the web server looks like if these permissions are not given to the administrator.

Clicking <Add a new user> lets you create a new non-administrator user with only the “Web Server User” role assigned, which we created earlier.

Testing our Setup So Far

To confirm that all our security settings are working, we can download the hardware and software to the PLC and try accessing its webpage.

By entering the previously set IP address of our PLC in a browser window, we should be greeted by a Siemens landing page, and we can press Enter to view our PLC’s webpage. Make sure to enter `https://`/ before the IP address, and click your browser’s “accept the risk and continue” button if you’re prompted with a certificate warning.

By logging in with our first administrator login (dmcAdmin1) we can see that we can access all pages as well as change the run mode of the PLC.

Logging out and back in as our “incorrectly configured” admin account shows that the user can log in, but because none of the web server runtime rights were granted, we cannot perform any actions that an authenticated user can.

Finally, by logging in as the standard user with permissions to only access the User Pages, we can see that the user can access the user defined pages tab, but is unable to perform administrator actions such as switching the PLC operating mode, downloading or backing up the program, etc.

Optimization

We have now shown that the Siemens PLC web server is enabled and secured, but if you spend any time navigating even the existing pages, you may notice that the web pages feel sluggish and slow to respond. There are two options that can be changed to speed up the pages.

Communication Load

By default, the PLC is set to spend no more than 20% of its CPU cycles performing communications. For some use cases, you may not have a large or complicated PLC project and would prefer a more responsive web server, at the cost of a slower scan time. By navigating to the PLC properties and increasing the limit from 20% to 50%, the project will become noticeably faster. During testing with one of my customers’ projects, web page loading time was approximately halved, while scan times went from 3-5ms to 4-11ms.

Enabling HTTP Communications

During the web server setup process, we checked a box to enable only HTTPS (secured and encrypted) communications. Doing so requires the PLC to spend significantly more of the Communication Load time encrypting and decrypting web traffic and less time transferring web pages. Disabling this option will make the web pages load much faster. If your PLC is properly secured behind a VPN or is fully disconnected from the internet, then the decrease in security is not too severe, but keep in mind that anyone with access to the network could theoretically read the unencrypted HTTP information as it is transferred. This means that login information and everything displayed will be transferred in unsecured, plain text.

Changing this setting had the most significant impact on page loading time, making the PLC-hosted web page feel almost as responsive as any site on the web, but comes with the cost of the greatest impact on security.

Next Steps

At this point, our PLC project and user permissions are correctly configured to enable user-defined pages. For more details on writing custom HTML pages that interface with the PLC program, check out Tim’s excellent write-up, which is mentioned at the start of this post.

The post Siemens S7-1200 Web Server appeared first on DMC, Inc..

1. How to set up retained memory for local labels, global labels with no device assignment, and global labels with device assignment 

2. Adjusting the allotted device memory if you run out of a certain type of device memory 

3. Minimizing program memory 

Retained Memory

It is straightforward to set non-device assigned labels such as local labels within a program or a global label that doesn’t have a device assignment to retain memory. Locate the label and within the class drop down select ‘VAR_RETAIN’ or ‘VAR_GLOBAL_RETAIN’ as shown below for the two types of labels.  

It takes a couple of extra steps to set a device assigned global label to retain. After you have decided on which device you want to use to assign to your label, you can assign the device to the label as normal, then select ‘VAR_GLOBAL_RETAIN.’

In the example below, I have assigned a trend array to a device section starting at D12000 up to D12399.  

Next, the D memory registers D12000-D12399 must be designated as retain memory in the ‘Device/Label Memory Area Detailed Setting’ area. To navigate here using the navigation tree, double-click on ‘Parameter’ -> ‘CPU Parameter’ -> ‘Memory/Device Setting’ -> ‘Device/Label Memory Area Setting’ -> ‘<Detailed Settings>.’ 

This will display the window shown below.

From here, double-click on any of the cells circled in the screenshot above. This will open the Latch Range Setting, where we will set what memory registers should be retained or latched.  

Here, we can see that I have a couple of ranges set for both M and D registers including the range D12000-D12999 to include the trend array from our example. After you have set the ranges you need for your project, press ‘OK’ and then you are done.  

Note, if you assign global labels that are not set to retain registers you defined in the Latch Range Setting or vice versa, you will receive a compile error reminding you to correct this.

Adjusting Device Memory Allotment Size

Depending on the size of your PLC memory and the size of your project, there are times when you might run out of a particular device type. In this situation, if you are unable to upgrade your PLC memory, you can attempt to reallocate your device types if there are some device memory types that you are not using.  

To do this, navigate to the Device/Label Memory Area Setting Detail Settings screen as mentioned in the section above. Starting in the navigation tree, double-click on ‘Parameter’ -> ‘CPU Parameter’ -> ‘Memory/Device Setting’ -> ‘Device/Label Memory Area Setting’ -> ‘<Detailed Settings>.’ 

Under the Device/Points column is where you can see the amount of points allocated to a given device. For example, for the D device, there are 20k points allocated which means the range of usable D devices spans from D0 – D20000. You can modify these allocations as needed as long as the total adds up to the ‘Total Device’ at the bottom as that is the limit of the PLC. After you are done, click on the ‘Check’ button at the bottom to verify that your new allocations are ok.  

Minimizing Program Memory

The screenshot above was from a previous Mitsubishi GxWorks3 PLC project where we almost ran out of program memory. Since upgrading the PLC memory was not an option, we had to consider other ways to save memory.  

For this project, we were programming from scratch and adhering to DMC’s best practices by using named Global Labels and UDTs for maximum code clarity and ease of maintenance. However, we discovered that moving data directly between UDTs using its symbolic name used a lot of program memory compared to directly manipulating the data using its device memory address. In the screenshots below you can see the massive difference in program steps used between using the symbolic name vs. the direct device address in rung 17.  

Due to the project hardware constraints, we had to sacrifice some code readability to fit the entire program within the allotted memory available. We used the instructions, BMOV (Transferring 16 – bit block data) and BLKMOV (Transferring n-bit data) on some of the bigger data transfers to help us achieve this. In the end, we were able to fit our program onto the PLC.  

I hope that you find these tips for setting up retained memory, adjusting the allotted device memory, and minimizing program memory helpful when working with GxWorks3. 

The post Memory Manipulation Tips For Mitsubishi PLCs using GxWorks3  appeared first on DMC, Inc..

For an overview of the groov EPIC and its features, check out the rest of this blog series.

• Part 1: groov EPIC Introduction
• Part 2: Ignition Edge

Setting Up the CODESYS Environment 

The groov EPIC supports a handful of programming environments, including PAC Control, Node-RED, and the CODESYS IDE. In this demo, we will use CODESYS to develop a simple program for the EPIC. CODESYS is an IEC 61131-3 compliant environment commonly used across many PLC manufacturers, with a user-friendly interface and support for multiple common IEC standard languages. 

To enable CODESYS on the EPIC, first open the groov manager web app and enable CODESYS (Controller > CODESYS Controller > Runtime Enable). Note that while the CODESYS application is running, we can no longer control the outputs from the screen made in blog 2, as the outputs are being controlled from the CODESYS program instead. To switch back to controlling IO from the previous screen, simply disable the CODESYS application from groov manager. This ability to easily switch back and forth between the two modes can be a huge help during I/O checkout and testing of a large, complex system. 

Next, open the CODESYS development environment on a PC that is on the same network as your EPIC and configure your device connection. Create a new project and add a new device connection to your groov EPIC by entering your device IP and scanning the network. Once connected, your device connection will look something like this. 

You can now click the “Login” button on the top toolbar to go online with your EPIC and monitor tag values directly. 

Configuring Controller Logic in CODESYS 

Our sample PLC program represents a machine that must not be left running unattended for longer than a set time interval (default of 10 seconds). PB_UPPER represents the “On” command to the machine, while PB_LOWER is an additional button that must be held down for the machine to continue running. This input could also be tied to a proximity sensor that determines whether an operator is present at the station. Our buzzer output alerts the operator if the machine has been running unattended for too long. 

Our simple application consists of two programs – the “main” program, PLC_PRG calls the subroutine “TurnOnBuzzer”. TurnOnBuzzer takes in both PB statuses, as well as the buzzer delay setpoint, and outputs the desired buzzer on/off state. These two programs illustrate how both text and ladder logic can be used to program your groov EPIC in CODESYS. 

To map your controller, I/O to tags within your programs, configure a mapping on the “State” tag of each I/O point, as shown below. Then, add a “Symbol Configuration” object to your application. This is where you control permissions for OPC UA read & write access of your PLC tags from Ignition or other applications. You can configure tags to be read-only or read/write based on the needs of your application. 

Now that our CODESYS program is configured, click the “Login” button and download changes. Next, we’ll set up our Ignition Edge HMI to interact with the CODESYS program. 

Using Ignition Edge as an HMI for a CODESYS Program

Now that our CODESYS OPC server is configured, add a new OPC Connection to your Ignition gateway under Config > OPC Connections. Enter the discovery endpoint of the new CODESYS OPC UA server. If you are using defaults, this will be opc.tcp:https://static.dmcinfo.com/ Once this is configured, you will see the new tags you added in CODESYS Symbol Configuration available in Ignition. 

For this demo, we are building onto the Ignition HMI that was developed in part 2 of this blog series, with three new pages. The “Alarm Status” page provides an interface to monitor the status of the two push buttons, and contains an indicator of machine runtime, displaying as it counts towards our “buzzer on delay” value. 

The “Config” tab provides an input field that is linked to our “buzzer on delay” PLC parameter. Here the user can configure the limit for continuous machine runtime before the buzzer is triggered. This provides an example of a tag with read/write permissions between CODESYS and Ignition. 

Finally, the “Trends” tab highlights the internal tag historian functionality of Ignition Edge. Without any extra database connections, tags from the groov EPIC (both PLC program tags or direct IO points) can be stored to the Edge historian and trended to monitor values over time. Here, we have configured the temperature reading from our Thermocouple and the voltage reading from our dial input as historical tags. With Ignition’s sleek and powerful trending tools, these trends can be configured and displayed in minutes. 

Thanks for reading this Getting Started series for Opto 22 groov EPIC! Now you’re ready to begin programming your own groov EPIC using CODESYS and Ignition Edge.  

The post Getting Started with Opto 22 groov EPIC Part 3: CODESYS & Ignition Edge appeared first on DMC, Inc..

For an overview of the groov EPIC and its features, check out the rest of this blog series.

• Part 1: groov EPIC Introduction
• Part 3: CODESYS & Ignition Edge

Setting up Ignition Edge on groov EPIC 

The groov EPIC GRV-EPIC-PR2 model ships with a license for onboard Ignition Edge version 8. This can be enabled from the groov Manage web server under http://<EPIC/ address>/manage/local/ignition. Toggle on “Enable Ignition Edge” and click save. It will take a few minutes for the gateway to start.  

Once Ignition Edge has been enabled, simply click the “Open Ignition Edge” link and follow the prompts displayed to configure your Edge gateway. 

Once your gateway is configured, you can add its designer in the Ignition Designer Launcher application by manually entering the gateway URL. From here, you are ready to create your first groov EPIC Ignition Edge project.

Configuring the groov EPIC OPC UA Server

Open the groov Manage webserver from a PC connected to the groov EPIC. From here, follow the instructions below to configure the OPC UA server.

1. Enable public access for all desired I/O.

a. Navigate to “I/O”, select an I/O point and click “Configure” in the top-right.

b. Under “Public Access” turn on “State (Read)” and “Writable” then click “Save.”

c. Repeat the above steps for each desired I/O point. Alternatively, save time by configuring many I/O points at once under I/O > I/O Services > I/O Batch Operations. 

2. Configure data service

a. In groov Manage, navigate to “Data Service” and click “Configure” in the top right. 

b. Under “Scanned Devices”, click “Add Local PAC Controller.” 

c. Configure desired settings (ensure OPC UA Server is on) and save.

d. Navigate back to the Data Service configuration page and add an OPC UA server. Set the following settings.

e. Return to the Data Service status page and enable Data Service Runtime. 

Connecting the groov EPIC OPC UA Server to Ignition

Now that we have an OPC UA server configured, we will next connect this to our local Ignition Edge gateway. 

1. In the Ignition Edge gateway, navigate to Config > OPC Connections. 

2. Click “Create new OPC connection.”

3. Copy the Discovery Endpoint from your previously configured OPC UA server into the “Endpoint URL” field. 

4. Follow the remaining configuration prompts to set up your connection. 

5. Give your connection a name and click “Save Changes.”

Once this connection is configured, you should be able to see your new OPC UA connection under Config>OPC Connections with a Status of “Connected.” You can now browse OPC UA tags from the Ignition designer and add your groov EPIC I/O tags to your Ignition project. 

From here, Ignition Edge screens can be easily developed to monitor and control the EPIC’s local I/O. In our demo setup, we monitor these I/O tags directly on the Main screen, as shown below.  

Ignition’s powerful scripting capabilities may be used to implement control logic directly, without a need for a PLC program. For the next part of this demo, however, the CODESYS controller onboard the EPIC was leveraged. In part 3, we will explore using CODESYS and Ignition Edge together on a groov EPIC. 

The post Getting Started with Opto 22 groov EPIC Part 2: Ignition Edge appeared first on DMC, Inc..