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

A client is currently using an overhead track of MagneMover Lite (MML) motors and vehicles to store and transport their product. When the product is ready for operations at the ground level, the MagneMotion vehicles carrying the product are sent to elevators that bring them in groups of three to the factory floor, where operators can unload from two racks: an upper and a lower rack.

Since the elevator needs to interface with both the ground racks and the overhead track, we must split the elevator and each ground rack into separate paths with their path beginnings defined by terminus nodes. A Terminus node defines the start or end of a path where vehicles move to or from their current path. When a vehicle is moving from the elevator to a ground rack, it must exit from the elevator terminus node and enter the ground rack terminus node, which accepts the vehicle onto the path. This process is repeated for all three vehicles in either direction, both boarding and departing the elevator.

While the elevator is lowering to the ground racks, a stack light flashes and emits an audible warning to alert operators that vehicles are arriving. Still, the client requested adding two photoeye (PE) sensors and a stop to prevent vehicles from colliding with any operators who are in the way of the arriving vehicles. We worked on a similar MagneMover Lite solution with an elevator system during the pandemic, helping Ginkgo Bioworks optimize their manufacturing process for developing RNA.

Ginkgo Bioworks is working on optimizing the manufacturing process for RNA – the key ingredient in vaccines produced by Pfizer/BioNtech and Moderna. RNA instructs cells to produce proteins that trigger the body to fight the coronavirus. https://t.co/w7tcvlUjpz pic.twitter.com/ZKpIY8Bwb8

— 60 Minutes (@60Minutes) March 1, 2021

Path Suspension

To help our client with this specific motion control request, we initially implemented logic to issue a path suspend command when the PE sensors were tripped. A suspend command causes any vehicle in motion on the path to decelerate and stop based on its current velocity and commanded acceleration.

It is not recommended to issue a stop command to a path while a vehicle is either entering or exiting terminus nodes. Due to this, if a PE sensor was tripped after the first vehicle had departed the elevator and while the second vehicle was in the process of exiting the elevator, there would be a delay before a suspension command could be issued to the ground rack path, causing the first vehicle to continue moving even after the PE was tripped.

Implementing the Stop Command

MML does not contain an explicit “stop” command; instead, you can issue a move command with a velocity of zero, keeping all other parameters (acceleration, path number, position, move direction, PID set) the same. Once you are ready for the vehicle to move again, you issue another move command with a nonzero velocity.

To implement the stop command, we cached the velocity, targeted position, and MoverID (unique ID assigned to MM vehicle) of each vehicle that was on a ground rack when the PE sensor was triggered. The cached velocity was used to ensure that any vehicle with a non-zero velocity was issued the “stop” command when a PE sensor was triggered. The targeted position was then used to reissue the same move before the vehicle was ordered to stop. The MoverID of each vehicle was cached after it was commanded to stop, allowing us to confirm all carriers on the path have been commanded to stop if the PE sensor has been triggered.

This solution was implemented across four elevators, each with two ground racks, and our Automation team has received only positive feedback from the client about the vehicles’ improved stopping times.

The post How to Issue a Stop Command in MagneMotion MagneMover Lite appeared first on DMC, Inc..

I like to think of it like the marketing emails you never manage to escape. A company hands its emails to a mailing service, the mailing service keeps the list of subscribers and delivers copies to everyone on it, and you signed up once for a 10% off coupon and have received every email since. The company doesn’t know who you are, and you never talk to the company directly. In this setup, Transmission is the company, Distributor is the mailing service, and Engine is your inbox, still subscribed.

Why Use MQTT?

MQTT is a publish-and-subscribe protocol, and that structure is the reason to use it. The central gateway maintains a single broker connection no matter how many edge sites feed into it, instead of polling every device directly. Data is also published by exception, so values only cross the network when they change, which is useful on cellular links and other constrained networks.

MQTT alone consolidates connections into a single stream, but it says nothing about what the data looks like. A plain MQTT message is just a value on a named topic (think a string or a JSON blob), and every publisher may format it differently.

Sparkplug adds a standard structure on top of MQTT: publishers announce everything they’re going to send when they first connect, and the broker notifies subscribers if a publisher drops offline. Ignition uses that first announcement, called a birth certificate, to build matching tags automatically instead of you mapping topics to tags by hand.

It’s like the welcome email of the subscription that lists everything you’re about to receive. And if the company quietly shuts down, the mailing service lets you know instead of leaving you to wonder why the emails with deals stopped.

MQTT Transmission

Transmission is the publisher. It’s installed on an edge or site-level gateway that already polls local PLCs or sensors over OPC UA or native drivers. Transmission watches the tag providers or folders you select and publishes them to the broker in Sparkplug format. In the email analogy, Transmission is the company’s sending tool. The PLCs write the content, and Transmission hands it to the mailing service.

You don’t need Transmission if a device already publishes Sparkplug natively, or if the gateway only consumes MQTT data.

MQTT Distributor

Distributor is the broker. It runs inside an Ignition gateway and accepts connections from publishers and subscribers. It’s the mailing service itself. It keeps the subscriber list and moves the mail but never writes any of it.

Since Distributor runs inside Ignition, the module works well for proofs of concept, development environments, and smaller production systems. Larger production systems will often use a standalone broker such as Chariot or HiveMQ, especially when applications outside Ignition share the broker or when security policies require the broker and SCADA system to be separate. Transmission and Engine can connect to compatible external MQTT brokers, so Distributor is not required.

MQTT Engine

Engine is the MQTT subscriber. When it’s installed on a central Ignition gateway, it connects to the broker, subscribes to Sparkplug data, and creates Ignition tags for every edge node, device, and metric it receives. Think of it like your email inbox. Everything a company sends to you shows up there, sorted and ready to read.

Once created, these tags act like any other Ignition tags. You can display them in Ignition Perspective, historize them, and use them for alarming and scripting. Because Sparkplug carries connection state, Engine also marks tags with bad quality when an edge node goes offline.

Engine is not the broker. It connects to the broker as a client in the same way Transmission does. If you want MQTT data to show up in Ignition, this is the module that does it.

Quick Guide for Setting Up a Basic Edge-to-Central Connection

For a basic two-gateway architecture, install the Transmission module at the edge and both Distributor and Engine modules on the central gateway. Then:

1. Configure MQTT Distributor on the central gateway: Confirm that MQTT Distributor is enabled and listening for TCP connections on port 1883. Under Users, create a broker user or confirm that one already exists. For a production connection across an untrusted network, use TLS instead of the non-secure listener.

2. Verify Engine connection on the same gateway. Under MQTT Engine > Servers, confirm that the default connection points to tcp:https://static.dmcinfo.com/ and shows Connected. If authentication is enabled in Distributor, confirm that the Engine connection uses the matching credentials.

3. Configure Transmission connection on the edge gateway. Under MQTT Transmission > Servers, point the broker connection to tcp://:1883 and confirm it shows 1 of 1 connected. Afterward, create a Transmitter with the tag provider, publish path, a Sparkplug Group ID, and a unique Edge Node ID. Transmission uses the next folder beneath that path as the Device ID.

4. Verify data in the Designer. Browse the MQTT Engine tag provider on the central gateway, find your Group ID and Edge Node, and confirm metrics appear and update when source values change.

For anything beyond a test setup, structure the edge tags as UDTs so every equipment instance publishes the same structure. New equipment can then appear in the namespace with the same layout as everything else.

When to Use MQTT

MQTT is a strong fit when you’re consolidating many edge sites or feeding the same data to several consumers. MQTT is also worth considering for bandwidth-constrained or congested networks because its publish-by-exception model reduces unnecessary traffic. On one of my recent projects, we chose MQTT because of the number of devices. Terminating hundreds of individual connections at the Ignition gateway wasn’t practical, so the devices published through a broker and Ignition held a single consolidated connection.

MQTT is not the best choice for every system. For a handful of devices on a single reliable plant network, with Ignition as the only consumer, a direct OPC UA connection is simpler. The Gateway Network also handles tag, alarm, and history sharing between a small number of Ignition gateways without extra infrastructure. And MQTT means another service to configure, secure, and monitor.

Once each module’s responsibility is clear, it becomes easier to place components, troubleshoot connections, and scale the architecture. The same pattern can also support a unified namespace, in which sites publish to a shared structure consumed by SCADA, MES, analytics, and cloud applications.

The post Which Ignition MQTT Modules Do You Need? Transmission, Engine, and Distributor Explained 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..

Our challenge was to build a world-class alarm analysis dashboard entirely in Ignition Perspective. This year’s primary round was unique in that we had eight consecutive hours to plan, develop, test, and submit the application.

The Alarm Intelligence Center

Our goal was to build more than a list of alarms. While Ignition’s standard alarm status and journal tables serve many applications well, we wanted our dashboard to help operators understand what the alarm data was telling them.

The result was the Alarm Intelligence Center, an operator-focused dashboard organized around three questions:

• How healthy is the facility?
• Which alarms or sources need attention?
• Is performance improving over time?

The Implementation

We focused on creating a slick, intuitive dashboard that made both real-time alarm data and historical performance easy to understand at a glance.

On the backend, we used named queries and custom scripting to analyze current and historical alarm events. Using EEMUA-informed alarm management metrics, we turned that analysis into information operators could act on, including:

• Alarm rate and time spent in flood.
• Average time to acknowledge.
• Standing and chattering alarms.
• Priority distribution and historical trends.
• A Pareto view identifying the sources responsible for most of the alarm load.

We also built custom alarm status and alarm history tables that fit seamlessly with the dashboard’s visual style. The tables provided simplified filtering and controls for viewing alarm details, acknowledging active alarms, and shelving them.

The result was a polished, standards-driven dashboard that helped operators quickly understand system health, identify problem areas, and decide where to focus their attention.

DMC is proud to share that our submission received the Best Error Handling award.

The experience demonstrated what DMC does best: bring the right people together, quickly turn ideas into action, and deliver a polished solution under a demanding deadline.

Check out the project on Ignition Exchange.

The post DMC Wins ‘Best Error Handling’ in Preliminary Round of the 2026 ICC Build-a-Thon appeared first on DMC, Inc..

At the same time, many organizations are expanding initiatives like predictive maintenance and real-time quality monitoring, which depend on reliable connectivity between industrial devices and the cloud.

This level of connectivity is a point where things can get complicated.

Unlike consumer IoT, industrial systems weren’t always designed to be connected to the cloud. Devices speak a wide range of protocols, networks can be slow or unstable, and shutting down operations to make fixes can be expensive. Connection to the cloud becomes an exercise in translation, normalization, and careful system design.

This blog focuses on one of the key components of that process: driver development.

Understanding Industrial IoT Connectivity

Historically, data produced by industrial equipment during manufacturing processes stayed local, stored on PLCs, SCADA systems, or proprietary vendor interfaces. This local storage provides a hurdle to implementing modern strategies for predictive maintenance, real-time quality monitoring, or the use of digital twins. There’s now a strong need to move machine data out of isolated systems and into centralized platforms where it can be analyzed and used to inform decisions or actions.

Centralizing data requires thinking about connectivity beyond simply networking machines together. To have an accessible, centralized system, one must ensure that each device can reliably and securely communicate with systems outside a traditional OT network.

Connectivity Challenges: From Plant Floor to the Cloud

On the plant floor, machines often communicate using standards like Modbus, OPC UA, or BACnet. These are well-suited for communicating with local devices but require translation when mapping onto cloud-native systems that rely on protocols like MQTT, HTTPS, or AMQP.

Take a legacy Modbus device, for example. It might provide a set of registers containing raw integer values. One number could represent motor speed; another might indicate tank level. But on their own, those values are just numbers; they don’t explain what they represent. A value of 4231 might mean 42.31°C, 423.1 psi, or something entirely different depending on scaling and encoding.

Cloud systems, on the other hand, are typically designed to expect structured, self-describing data. Timestamps, units, and data types may all be expected to come alongside the value for a datapoint.

This means there are two challenges to hooking industrial systems into cloud architectures. The first is extracting reliable data from industrial equipment by leveraging tools like serial connections, legacy backplanes, or proprietary APIs. The second is transforming that data into something the cloud can understand. Drivers act as a middle layer in the system to address these challenges.

Cloud-Focused Considerations in Industrial Connectivity

Once data is collected on the factory floor, the next step is sending it to the cloud safely, reliably, and with the ability to scale over time.

This adds a new layer of complexity at the edge. Practitioners now have to keep in mind things like communication, managing network interruptions, and efficiently moving large amounts of data without slowdowns. What previously worked for local devices and machines won’t always work when cloud platforms are involved.

From an edge perspective, this introduces a new set of design considerations.

Protocol Compatibility

Cloud systems typically rely on internet-friendly protocols. MQTT is often the default choice due to its publish/subscribe model and its efficiency, but HTTPS and AMQP are also common depending on the platform.

Drivers or gateways must translate industrial protocols into one of these formats, often while enriching and compressing the data.

Data Modeling and Normalization

Cloud platforms expect data to be consistent across devices and sites. That means:

• Clearly defined data types
• Standardized units
• Consistent naming conventions
• Structured metadata

Without normalization, every device can become a custom integration problem.

Security Requirements

Unlike a local OT network, cloud connectivity requires strong security controls:

• TLS encryption for all data in transit
• Certificate-based authentication for devices
• Managed identity and access control

In many cases, the gateway handles these responsibilities, but it’s essential that the driver integrates cleanly with that security model.

Reliability and Offline Operation

Industrial environments don’t always have the best connectivity. Networks fail, systems can be routinely interrupted for maintenance, and some locations have limited bandwidth.

Drivers and gateways need to buffer data locally, retry transmissions intelligently, and ensure that important data isn’t lost.

Edge Processing

Not all data needs to be sent to the cloud.

In many cases, it’s more efficient to process data at the edge by:

• Filtering noise
• Aggregating high-frequency signals
• Detecting simple events

This reduces bandwidth usage and keeps cloud systems focused on higher-value analysis.

Core Concepts in Building Industrial IoT Drivers

Developing a driver requires understanding both how devices represent data and how that data will ultimately be used.

Understanding Device Data Structures

Industrial devices commonly expose data through:

• Registers (e.g., Modbus)
• Tags or variables (PLCs)
• Objects (BACnet, OPC UA)
• Vendor-specific memory maps

Interpreting these correctly is critical. A single value can represent very different things depending on scaling, encoding, and byte order.

Drivers must apply the correct transformations to ensure accuracy.

Timing and Polling

Devices often expect communication at specific intervals. Poll too quickly and you risk overloading the device or network. Poll too slowly and you may miss important changes.

Drivers need to balance these constraints while also considering how frequently data should be sent to the cloud.

Event-Driven vs. Polled Data

Some systems support event-driven communication (such as OPC UA subscriptions), while others rely entirely on polling.

Supporting both approaches allows for more efficient and scalable designs.

Essential Components of an IoT Driver

A production-ready driver includes several key components beyond basic protocol handling:

Protocol Parsing: The process that translates raw bytes into structured values. It includes handling message formats, checksums, and protocol-specific logic.

Transport Layer Handling: Drivers often interact with multiple transport layers such as serial communication (RS-232, RS-485), TCP/UDP networking, and fieldbus interfaces. These layers must be resilient to noise, dropped packets, and physical issues.

Configuration Models: Scalability depends on structured configuration. Drivers typically support:

• External configuration files
• Dynamic updates via APIs
• Metadata definitions for signals

This avoids hardcoding logic for each deployment.

Error Handling and Recovery: Reliable operation requires robust handling of timeouts, invalid responses, and disconnections. Drivers should automatically retry and recover without manual intervention.

Logging and Diagnostics: Remote troubleshooting depends on visibility. Drivers should expose logs, communication traces, and status information that can be accessed remotely.

Best Practices for Cloud-Focused Driver Development

Several patterns consistently improve reliability and maintainability.

Use Abstraction Layers: Separating protocol logic from device-specific mappings makes drivers more reusable and easier to extend.

Support Simulation and Testing: Simulated devices allow for faster development and safer testing, especially when physical hardware is limited.

Control Data Volume: Sending too much data is a common mistake. Drivers should support filtering, aggregation, and event-based reporting.

Prioritize Security: Drivers should align with secure communication practices and integrate with certificate-based authentication and encrypted transport layers.

Choosing the Right Connectivity Approach

There is no one-size-fits-all architecture for industrial IoT. The right approach depends on a mix of technical and operational factors.

Data volume, update frequency, and real-time requirements all influence how much processing should happen at the edge versus the cloud.

Network reliability plays a major role—especially in environments where connectivity is intermittent.

Security requirements can further shape architecture, particularly in regulated industries.

When it comes to implementation, most teams choose between building custom solutions, buying commercial products, or combining both. Custom development offers flexibility but requires ongoing maintenance. Many commercial tools enable faster deployment but come with limited customization options. In practice, many organizations take a hybrid approach, using standard tools wherever possible and customization where necessary.

The key is to start with a reliable foundation and evolve the architecture as requirements become clearer.

Conclusion

Connecting industrial devices to the cloud is not a single step—it’s a layered process that starts with reliable data extraction and ends with meaningful insights.

Drivers play a very central role. They translate raw machine data into structured, usable information and ensure it can move reliably between systems that were never designed to work together.

By combining well-designed drivers, thoughtful edge architectures, and scalable cloud platforms, it becomes possible to unlock the full value of industrial data.

As technologies continue to evolve—through digital twins, edge computing, and next-generation networking—the importance of this foundation will only grow.

The post How Drivers Enable Industrial Cloud Connectivity appeared first on DMC, Inc..

A loading skeleton solves that by showing a placeholder version of the content before the real data loads. Instead of staring at an empty space, the user sees the shape of the card, chart, or widget that is about to appear.

In this post, I will show a straightforward way to build a shimmer loading skeleton in Ignition Perspective using a lightweight skeleton view, a loading Boolean, and a custom style class in the project stylesheet. No JavaScript or custom module is needed.

What We are Building

• Create a normal embedded view for the real content.
• Create a second embedded view that is structurally identical but uses placeholder components instead of real data.
• Apply the shimmer-style class to those placeholder components.
• Toggle between the real view and the skeleton view using a loading Boolean.

This works well for KPI cards, summary widgets, charts, tables, and other dashboard elements.

Step 1: Create a Skeleton Version of the View

Start with your normal view. For example, suppose you already have a card view called MetricCard. Create a second version of it called MetricCardSkeleton.

The skeleton version should keep the same overall layout as the real one: the same containers, spacing, padding, alignment, and approximate component sizes.

The goal is not to redesign the card. The goal is to make a lightweight placeholder that occupies roughly the same space as the real content.

For example, if the real card includes a title, a large OEE number, and a small subtitle, the skeleton version should include placeholders in the same locations.

Step 2: Use Static Placeholder Text for Sizing

For text-based placeholders, I used normal Label components and applied a custom style class to them.

The label text itself is just there to help with spacing and sizing. It does not need to be meaningful, and it should not be bound to live data.

For example, if the actual OEE typically shows 47.7%, the skeleton label might simply show 88.8%. That gives the label a realistic width and height while keeping the skeleton lightweight.

The same idea applies to titles. You might use a short static label value just to preserve the shape of the final layout.

Step 3: Add a Loading Boolean

This is the part that makes the whole pattern actually usable.

You need some Boolean value that tells Perspective whether the real content is ready yet. A simple example would be view.custom.isLoading.

Set that Boolean however it makes sense for your view. Common options include setting it true until a query returns, until required params are present, until a custom property is populated, or until a dataset or object has usable data.

For a simple setup, isLoading should be true while the data is not ready and false once the data is ready.

Then bind visibility like this:

• Real view visible when !view.custom.isLoading
• Skeleton view visible when view.custom.isLoading

This makes the skeleton show first, then disappear once the real content is ready.

Step 4: Add a CSS Shimmer Style Class in Perspective

In Perspective, style classes can be created in the project stylesheet. I used a single general-purpose class for shimmer text placeholders.

:root{
  --sk-base:   #FFFFFF1A;
  --sk-radius: 8px;
  --sk-clear:  #FFFFFF00;
}

@keyframes shimmer {
  from { background-position: 200% 0; }
  to   { background-position: -200% 0; }
}

.psc-skeletonTextShimmer {
  background:
    linear-gradient(
      90deg,
      var(--sk-clear) 0%,
      var(--sk-clear) 35%,
      var(--sk-base) 50%,
      var(--sk-clear) 65%,
      var(--sk-clear) 100%
    ),
    var(--sk-base);
  background-size: 200% 100%;
  background-repeat: no-repeat;
  border-radius: var(--sk-radius);
  min-height: 14px;
  animation: shimmer 1.4s ease-in-out infinite both;
  color: #FFFFFF00;
  user-select: none;
}

:root{
  --sk-base:   #FFFFFF1A;
  --sk-radius: 8px;
  --sk-clear:  #FFFFFF00;
}

@keyframes shimmer {
  from { background-position: 200% 0; }
  to   { background-position: -200% 0; }
}

.psc-skeletonTextShimmer {
  background:
    linear-gradient(
      90deg,
      var(--sk-clear) 0%,
      var(--sk-clear) 35%,
      var(--sk-base) 50%,
      var(--sk-clear) 65%,
      var(--sk-clear) 100%
    ),
    var(--sk-base);
  background-size: 200% 100%;
  background-repeat: no-repeat;
  border-radius: var(--sk-radius);
  min-height: 14px;
  animation: shimmer 1.4s ease-in-out infinite both;
  color: #FFFFFF00;
  user-select: none;
}

A quick Ignition-specific note: if your Perspective style class is named skeletonTextShimmer, the selector in the stylesheet needs the .psc- prefix: .psc-skeletonTextShimmer.

For a deeper dive into this code, see the section How the CSS Works.

Step 5: Apply the Style Class to Placeholder Labels

In the skeleton view, apply the style class to the labels you want to shimmer.

props.style.classes = skeletonTextShimmer

You can keep normal label styling for things like:

• font size
• font weight
• margin
• padding
• alignment

The text itself becomes transparent due to CSS, but the label retains its size and layout behavior. That is what makes this pattern so convenient: you are still working with ordinary Perspective components, just styled to look like placeholders.

Tip: If the shimmer does not appear right away in the Designer, try closing and reopening the view.

Step 6: Show the Skeleton While the Real View Loads

A simple and maintainable way to do this is to use two embedded views in a parent container: one embedded view for MetricCard and one embedded view for MetricCardSkeleton. Then bind each view’s visible property to your loading Boolean.

Skeleton embedded view:
visible = view.custom.isLoading

Real embedded view:
visible = !view.custom.isLoading

Skeleton embedded view:
visible = view.custom.isLoading

Real embedded view:
visible = !view.custom.isLoading

That gives you a very readable setup: when loading is true, show the skeleton; when loading is false, show the real widget. This is often easier to maintain than trying to make one view serve both purposes.

Why This Works Well

This pattern gives the user immediate visual structure instead of a blank area.

It also reduces layout shift because the skeleton uses the same approximate spacing as the real content.

Just as importantly, it stays simple. You are not adding much scripting or frontend complexity. You are duplicating the layout, replacing live content with static placeholders, toggling visibility with a Boolean, and using one reusable CSS class.

A Few Practical Tips

Keep the skeleton lightweight: Do not bind the placeholder labels to live data. Their job is just to hold space and show the shimmer effect.

Match the real layout closely: The closer the skeleton matches the final card, the smoother the transition feels.

Use realistic placeholder lengths: For percentages, use something like 88.8%. For short titles, use placeholder text of similar length. That helps preserve spacing.

Hide overflow if needed: If a placeholder label could get awkwardly sized, setting overflow-related text styling can help keep the skeleton clean.

How the CSS Works

If you mainly want the implementation, you can stop after applying the class and wiring up the loading Boolean. If you are curious about how the shimmer works, here is the breakdown.

Root Variables

:root{
  --sk-base:   #FFFFFF1A;
  --sk-radius: 8px;
  --sk-clear:  #FFFFFF00;
}

:root{
  --sk-base:   #FFFFFF1A;
  --sk-radius: 8px;
  --sk-clear:  #FFFFFF00;
}

These are reusable values for the skeleton effect.

• --sk-base is the main placeholder color
• --sk-radius keeps the skeleton corners rounded
• --sk-clear is a fully transparent color used inside the shimmer gradient

Using CSS variables makes it easier to tweak the look later without rewriting the whole class.

Keyframe Animation

@keyframes shimmer {
  from { background-position: 200% 0; }
  to   { background-position: -200% 0; }
}

@keyframes shimmer {
  from { background-position: 200% 0; }
  to   { background-position: -200% 0; }
}

This animation moves the background image from right to left.

The shimmer effect is not a separate moving object. It is just the background gradient sliding across the component over time.

The Background Layers

background:
  linear-gradient(
    90deg,
    var(--sk-clear) 0%,
    var(--sk-clear) 35%,
    var(--sk-base) 50%,
    var(--sk-clear) 65%,
    var(--sk-clear) 100%
  ),
  var(--sk-base);

background:
  linear-gradient(
    90deg,
    var(--sk-clear) 0%,
    var(--sk-clear) 35%,
    var(--sk-base) 50%,
    var(--sk-clear) 65%,
    var(--sk-clear) 100%
  ),
  var(--sk-base);

There are two background layers here:

1. A linear gradient (…) that creates the moving shimmer band
2. A solid var(--sk-base) layer underneath it

The gradient is mostly transparent, with a slightly visible band in the middle. As it moves, that band creates the shimmer effect.

Background Size and Repeat

background-size: 200% 100%;
background-repeat: no-repeat;

background-size: 200% 100%;
background-repeat: no-repeat;

background-size makes the animated gradient wider than the component itself, which gives the shimmer room to move across the element instead of appearing static.

background-repeat: no-repeat keeps the gradient from tiling in ways that look messy or unnatural.

border-radius keeps the skeleton shape visually aligned with the rest of the UI.

min-height helps prevent small labels from collapsing too much.

The animation line applies the shimmer keyframes and controls the speed, easing, and repetition.

Transparent Text and Text Selection

color: #FFFFFF00;
user-select: none;

color: #FFFFFF00;
user-select: none;

color hides the label text without removing the label itself.

That is important because the label is still doing layout work for us. It keeps its width, height, margins, padding, and font-based sizing, but the user sees only the animated background.

user-select: none prevents users from accidentally highlighting invisible text while the skeleton is visible.

Final Thoughts

This is a small UX improvement, but it makes a Perspective project feel much more polished.

Instead of showing a blank region while data loads, you can show a placeholder that matches the real layout and communicates that the screen is actively loading.

The main pieces are simple: a real view, a skeleton view, static placeholder components, a loading Boolean, and one shimmer style class. Once you set up the pattern, it becomes easy to reuse across the rest of the project.

The post Step-by-Step Guide: Building a CSS Skeleton in Ignition Perspective appeared first on DMC, Inc..

Exceptions are unexpected events that a program cannot take care of on its own, and stop the program from executing. Exceptions can be caused by a wide range of factors, leaving the user wondering why the system isn’t working when improperly managed.

When an exception occurs, the event details are laid out in an exception object, which can be used to better handle the event. By learning to use these details and handle exceptions, developers can write more robust functions, provide useful error messages when things go wrong, and flag conditions that could cause problems downstream.

How to Approach Exception Handling

When handling exceptions, DMC encourages engineers and programmers to stick by these three guidelines:

1. Let the code fail but rewrite the error message so that it is more helpful.
2. Use the DMC pop-up library to display exceptions as errors to the users.
3. Set up the code so that the system handles known and unknown errors consistently.

Handling Exceptions

Exceptions are handled by wrapping error-prone code in a try/except block. There are several types of except statements that can accomplish different things.

Because Ignition uses Jython, a Java implementation of Python, it is also important to handle Java exception types where applicable.

Understanding Python Syntax for Exception Handling

In Python, there are four main keywords for handling exceptions:

• Try: contains error-prone code
• Except: catches and handles errors if they occur
• Else: runs if the try block completes successfully
• Finally: always runs, regardless of what occurs earlier

The core of exception handling occurs in the try and except statements, so we will focus on those in the following examples.

Basic Exception

This example uses the most basic implementation of a try/except statement. You know that an error occurred, but you don’t know anything about the error. Not very useful.

try:
  output = dividend / divisor
  success = True
except:
  success = False
  errorMessage = 'An error occurred while dividing'

try:
  output = dividend / divisor
  success = True
except:
  success = False
  errorMessage = 'An error occurred while dividing'

Catch Python Exceptions

You can include the base exception type in the syntax to get the error message or filter for specific error types. It is best practice to look out for specific exception types. In the example below, we catch the ZeroDivisionError type and rewrite the error message so it is more human-readable. Notice how you can include multiple except statements! This way, you can filter for known exceptions and still catch others that may occur during execution of the code.

try:
  output = dividend / divisor
except ZeroDivisionError as e:
  errorMessage = 'Cannot divide by zero: {}'.format(e.message)
except Exception as e:
  errorMessage = 'Division error: {}'.format(e.message)

try:
  output = dividend / divisor
except ZeroDivisionError as e:
  errorMessage = 'Cannot divide by zero: {}'.format(e.message)
except Exception as e:
  errorMessage = 'Division error: {}'.format(e.message)

Catch Python and Java Exceptions

Because Ignition uses Jython, a Java implementation of Python, we should also handle Java exception types that might occur during queries, casting, or other scenarios.

import java.lang.Exception as JavaException

try:
  output = dividend / divisor
except (Exception, JavaException) as e:
  errorMessage = 'Division error: {}'.format(e.message)  

import java.lang.Exception as JavaException

try:
  output = dividend / divisor
except (Exception, JavaException) as e:
  errorMessage = 'Division error: {}'.format(e.message)  

Displaying and Logging Exceptions

Displaying

DMC’s pop-up library includes functions for automatically displaying exception message pop-ups in Perspective without requiring the declaration of a specific exception type. The pop-ups in this library can display simplified and detailed versions of the error, providing both user-friendly and developer-friendly messages.

import traceback
logger = system.util.getLogger('Test Function')

try:
  myFunction(inputA,inputB,inputC)
except Exception as e:
  logger.error(traceback.format_exc(e))

import traceback
logger = system.util.getLogger('Test Function')

try:
  myFunction(inputA,inputB,inputC)
except Exception as e:
  logger.error(traceback.format_exc(e))

Logging

In addition to displaying the exception to users, exceptions should also be logged to the gateway to maintain a record of such events. Without logging, a user can close the exception pop-up, and all information associated with the event will be lost.

Logging with traceback.format_exc(e) creates a well-formatted message with error type, message, and traceback, giving engineers the information they need to debug issues effectively.

from traceback import format_exc

try:
    1/0
except Exception as e:
    print type(e).__name__
    print ''
    print e.message
    print ''
    print format_exc(e)
    
>>> 
ZeroDivisionError

integer division or modulo by zero

Traceback (most recent call last):
  File "<input>", line 4, in <module>
ZeroDivisionError: integer division or modulo by zero

>>> 

from traceback import format_exc

try:
    1/0
except Exception as e:
    print type(e).__name__
    print ''
    print e.message
    print ''
    print format_exc(e)
    
>>> 
ZeroDivisionError

integer division or modulo by zero

Traceback (most recent call last):
  File "<input>", line 4, in <module>
ZeroDivisionError: integer division or modulo by zero

>>> 

Other Exceptions

You can raise your own Exceptions to catch errors that might not violate Python syntax by themselves. This is useful for sanitizing inputs or generally checking statuses before they cause errors later in program execution. You can also reraise within an Except block to add more context to an error message.

def divideNumbers(dividend, divisor):
  if divisor == 0:
    raise ValueError('Cannot divide by 0')
    
  try:
    output = dividend / divisor
  except Exception as e:
    raise Exception('Division error: {}'.format(e.message))
    
  return output

def divideNumbers(dividend, divisor):
  if divisor == 0:
    raise ValueError('Cannot divide by 0')
    
  try:
    output = dividend / divisor
  except Exception as e:
    raise Exception('Division error: {}'.format(e.message))
    
  return output

SQL Exceptions

When considering SQL exceptions, we first want to examine the query method. Where possible, we want to use named queries instead of prep queries because named queries provide much better error messages.

Custom Exception Classes

Creating custom exception classes is incredibly easy to accomplish in Python. You might want to create separate exception types for user input errors and system errors.

Conclusion

By moving beyond basic try/except usage and adopting a more structured approach, like catching specific exception types, handling both Python and Java errors in Ignition, and logging details, you can turn unexpected errors into actionable insights.

At DMC, we always apply these best practices across our automation and software projects to deliver systems that are robust, user-friendly, and scalable. Whether you’re building a new Ignition application or improving existing systems, stronger exception handling helps ensure greater dependability and performance.

The post Ignition Tricks: Improving Exception Handling and Error Logging appeared first on DMC, Inc..

Table of Contents

1. Installation
2. Configuration
3. Workloads and Packages
4. Conclusion

TwinCAT Package Manager is Beckhoff’s new innovative way of managing packages within the TwinCAT environment. Released with their latest build 4026, Package Manager allows for quick and easy downloads of TwinCAT versions and workloads (collections of one or more packages), as well as individual packages. Let’s get started with some of the key features of the TwinCAT Package Manager.

Installation

Download the latest version of the TwinCAT Package Manager from the Beckhoff website. This blog will use the full installation, which includes the UI. If you would prefer the command-line-only install, some common commands are available on Beckhoff Infosys.

Follow the installation procedure to install TwinCAT Package Manager.  

Configuration

Once TwinCAT Package Manager is installed successfully, open it. If this is your first time launching Package Manager, you should be greeted with the Introduction screen. If you have previously launched Package Manager, but want to follow along, you can access this screen with the Settings button (gear icon) in the bottom left.

Introduction

If you’re installing Package Manager on a system with a previous build of TwinCAT already installed, there will be a migration tab instead of a location tab. We will deal with that in a later section. Click Next.

Feeds

The next section is for configuring the feeds for Package Manager. Click the “Add new feed” button to add one of these feeds.

By default, Beckhoff provides three feeds: the stable feed, the outdated feed, and the testing feed. The stable feed contains officially released Beckhoff products and is typically the main feed for most workloads and packages. Select the URL that ends with “/stable” to add the stable feed. The feed name should auto-populate, but can be changed. Enter your valid myBeckhoff account credentials and click Save to add the feed. You can create your own myBeckhoff account if you don’t already one.

You’re also able to create your own feed, which you can access here. This would allow you to easily share custom libraries with other developers on your team. We won’t go in depth on how to do that in this blog, but the Beckhoff community GitHub repo has an example structure.

You should now see the feed added. You’re able to disable, edit, or delete the feed from this view if needed.

The outdated feed contains previous TwinCAT builds. If you used TwinCAT prior to build 4026, this is essentially the new version of Remote Manager. The testing feed contains test versions of workloads and packages. It’s most commonly used if you need access to an unreleased feature or are testing packages with Beckhoff engineers.

Follow the steps above for the stable feed to add the outdated and testing feeds, making sure to use their respective URLs.

Once you add the outdated and testing feeds, your Feeds tab should look like the one above. You can reorder the feed priorities using the up and down arrows on the right side. It’s recommended to keep the stable feed as priority 1 since it contains the officially released packages. If you reordered the feeds, click the save button in the top right. If you click next with unsaved changes, you will get this warning.

If you see this warning, click “Yes” to save changes. Click “Next.”

Integration

The next screen asks which versions of TwinCAT XAE to install. Since TwinCAT XAE is built on Visual Studio, it requires the same Visual Studio version (32-bit or 64-bit) to be installed. If you’re working on a project in build 4026 or newer, it’s recommended to use the 64-bit version when possible. If you’re working on a project in a build prior to 4026 or on a 32-bit computer system, the 32-bit version of TwinCAT XAE is the only option. You can always add or remove these XAE versions later, so for now, let’s install both. Click “Next.”

Migration

If you had a previous build of TwinCAT, you will be prompted to complete a Migration screen. If you did not have a previous build of TwinCAT, feel free to skip to the Location section.

The migration tool will attempt to capture existing user settings on previous versions of TwinCAT, uninstall previous versions, install the latest versions, and reapply the user settings. Let’s click “Start Migration” to get started.

When getting to step 2 of the preparation screen, you may see a notification that you need to install the MigrateCli package. Click “Yes” to continue.

Once the migration tool is installed, click “Start Simulation.”

Once the migration simulation runs, you should see a list of all existing products in the system and how TwinCAT Package Manager plans to upgrade them to packages and workloads.

Assuming all the products can be upgraded to packages and workloads, we are ready to start the migration. Click Start Migration.

Depending on the products you have installed, you may need to reboot your system. Press Ok and the TwinCAT Package Manager should automatically start up after rebooting and continue the migration.

Once the migration is complete, click Finish. You should see all the latest versions of the products you had previously installed on the system.

Location

If you did not have a previous version of TwinCAT installed, the final screen asks where to install TwinCAT. The default location is fine unless you have a reason to install it elsewhere. Click Finish.

Workloads and Packages

The workload view should be the default view when opening Package Manager for the first time. It can be navigated to by hovering over the package icon with a W in the bottom right and selecting workloads.

Workloads

Workloads are groupings of packages that closely align with Beckhoff’s licensing structure. For example, if you’re planning on using Beckhoff XTS in your solution, you can search for “XTS” to find the TF5850 | TwinCAT 3 XTS workload. This will install the necessary packages to work with XTS. If you are using XTS in your solution, check out our blog series on XTS to help get started!

The workloads in the general section are the ones we should install first. Let’s start by installing the latest version of TwinCAT Standard Engineering and the latest versions of TwinCAT XAE Shell 32-bit and 64-bit. If you’re installing the latest version, simply click on the blue download button associated with that workload.

You’ll see the planned installations added to the right side of Package Manager under selected products. Click Apply Modifications to start the installation.

Some workloads will require a restart. The TwinCAT Standard installation is one of them. Click Accept to continue.

If a pop-up appears asking you to allow the TwinCAT Package Manager to make changes to your device, click “Yes.”

The installation may take a few minutes, but Package Manager will give you a download and installation status.

Once the installation completes, Package Manager will show a check mark next to the workloads that were successfully installed.

We didn’t explicitly install TwinCAT Standard Remote Manager or TE9000 | TwinCAT 3 Safety Editor. Why are they showing as installed? TwinCAT Package Manager will install all dependencies needed to install the selected workloads! These workloads are dependencies for TwinCAT Standard and are automatically installed for us.

Workloads (Other Versions)

One of the nice things about TwinCAT Package Managers is the ability to access prior versions of all the workloads. Each workload has an ellipsis on the right side. Clicking on this provides the option to select other versions.

Click on the other versions option for TwinCAT Standard.

We can see that the latest version is currently installed and can be uninstalled here if needed. If we wanted to install a previous version, say 4026.21.2, we could click the icon next to that version. That icon is the downgrade icon. This would uninstall 4026.22.0 and downgrade TwinCAT Standard to 4026.21.2.  However, TwinCAT Standard Remote Manager can be used when working on multiple solutions across different versions.

Click the triple-dot icon next to TwinCAT Standard Remote Manager, then select other versions.

The icons here are install icons instead of downgrade icons, even though we already have the latest version installed. This is because the TwinCAT Standard Remote Manager supports multiple versions, as indicated by the AllowMultiple attribute in the top left. Installing from here will allow both versions to coexist on the same system. To illustrate this, I’ll install version 4026.21.2.

The Package Manager workload for TwinCAT Standard Remote Manager now shows a [ + 1 ] to indicate multiple builds are installed.

When opening TwinCAT XAE, we now have multiple builds to select from!

Installing Pre-4026 Builds

If you haven’t already, make sure you’re connected to the Beckhoff outdated feed. You can configure your feeds by clicking on the settings icon in the bottom left.

Once you have the outdated feed configured, hover over the package icon with the database in the bottom right. Select the “Beckhoff Outdated Feed.”

The only workload associated with the Beckhoff Outdated Feed is the TwinCAT Standard Remote Manager. From the outdated feed, we can install pre-4026 builds of TwinCAT.

I’ll install build 4024.75.4 to illustrate.

After installing build 4024.75.4 on TwinCAT Package Manager, it is now selectable in the build dropdown.

*NOTE: This is only available in the 32-bit XAE. The 64-bit version of XAE only supports builds 4026 and newer.

Packages

So far, we’ve been dealing with Workloads. Workloads are groupings of packages that TwinCAT organizes primarily according to Beckhoff’s licensing structure. TwinCAT projects reference packages directly. Let’s open a new TwinCAT XAE project to see this.

In the References folder of a brand new TwinCAT project, there are the Tc2_Standard, Tc2_System, and Tc3_Module packages.

Let’s switch back to the package manager. On the left, you should be able to go to the package view menu and select Packages.

This will show the individual packages that are available and installed on the system. Let’s search for Tc2_Standard.

We can see that Tc2_Standard is installed.

How To Deal with a Missing Package

If you have a missing package on a TwinCAT project, you will be greeted with a warning sign that looks something like this:

The package with the warning symbol next to it is missing from the project. Double-clicking on the package shows that the library is not available and does not have an effective version listed.

Right-click on the missing package and open the properties window. The resolution will show the version of the package that the TwinCAT PLC project is expecting.

If we go back to Package Manager and search for the Tc2_System package, we can see that although it is installed, it is not the same version the PLC project expects.

Click the ellipses next to the package, then select other versions.

Similar to Workloads, Packages have multiple versions that can be installed onto the same system. In this scenario, we have Tc2_System v3.10.1 installed already, but do not have v3.9.1. Tc2_System allows for multiple versions to be installed, indicated by the AllowMultiple tag. Let’s install v3.9.1 and see if that resolves our issue. Click the download button next to v3.9.1 and click “Apply modifications.”

If you see a message about “TwinCAT XAE / Visual Studio stop required,” be sure to close all open XAE windows before clicking Accept. Once the package is installed successfully, we can check the previously missing package.

The library is now available and has an effective version of v3.9.1. We have installed our missing package through Package Manager!

Conclusion

The TwinCAT Package Manager is a huge improvement in how engineers can manage the various Packages and Workloads that make up a TwinCAT solution. TwinCAT Package Manager is just the start of the improvements that TwinCAT build 4026 brings to development. A complete list of changes is offered on the Beckhoff website. If you’re starting a project in 4026 or upgrading an existing solution to 4026, reach out to DMC and see how we can help! We have extensive experience with upgrading and developing across all TwinCAT builds.

The post Getting Started with Beckhoff TwinCAT Package Manager appeared first on DMC, Inc..