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

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

One issue that arises with this workflow is that Ignition does not always immediately detect file changes made outside the Designer. After checking out a branch, merging changes, or pulling updates, the gateway will still need a manual file scan from the Gateway before the latest project or configuration files are reflected.

To make development workflows smoother for our projects at DMC, we created a script that uses the Ignition 8.3 Gateway API endpoints to trigger project and configuration file scans. By integrating this script into Git hooks, file scans can run automatically after branch checkouts or merges, eliminating the need to manually navigate to the Gateway webpage and trigger them each time (fig1 and fig2). Additionally, developers can manually run the script from Bash or the command line to trigger file scans on demand.

In this blog, we have provided a sample script and .env file, and we will walk you through the steps to set this up.

Why This Step Matters

There are a variety of reasons why automating this step is both important and beneficial. This automation reduces friction in the development workflow, reducing some of the common sources of errors and delays while improving team-wide consistency and clarity. By using Git hooks to automate file syncing in Ignition, developers avoid repeated trips to the Gateway UI and reduce mental load.

By adding automated file scans into the development workflow, teams can make Ignition 8.3 development feel more like regular software development, where Git-based practices like branching, merging, and pull requests fit naturally into SCADA projects.

Set Up Gateway API Key

In order to access the API endpoint, we need to set up an API key in the Gateway. Follow Ignition’s manual for this.

By default, Ignition requires API keys to be used over secure HTTPS connections. Since this script commonly runs against local development Gateways using standard HTTP, the Require secure connections for API Keys setting must be disabled for the requests to succeed.

Make sure to copy the ENTIRE api key. We will add it to the .env file in the next section.

Repo and Environment Variables Set Up

Copy the example script (included in the section below) into your desired location in your repo. For example, in this repo, we have put it at the following location and called it gateway_scan.py.

Path: ignition-docker-8-3\scripts\gateway_scan

Next, add the following variables to your .env file:

GATEWAY_IP= (your gateway’s IP address)
HTTP_PORT = (your gateway’s port)
GATEWAY_API_TOKEN=(your generated API token for the gateway)

The example script looks for these variables; if they are already in your .env and are named differently, open the example script and do a find-and-replace to update the variable names.

Git Hook Set Up

Git hooks let us automatically run scripts when certain Git actions occur. For this workflow, we typically set up Git hooks to run the gateway_scan.py script after branch checkouts and merges.

This means that when a developer switches branches, pulls changes, or merges updates, the Gateway file scan can run automatically without having to open the Gateway webpage and manually trigger it.

To set this up, create two files in the .git/hooks folder:

.git/hooks/post-checkout
.git/hooks/post-merge

Paste the following code into both files:

#!/bin/sh

# Move to the root of the git repository
cd "$(git rev-parse --show-toplevel)" || exit 1

# Run file scan script
py scripts/gateway_scan/gateway_scan.py

#!/bin/sh

# Move to the root of the git repository
cd "$(git rev-parse --show-toplevel)" || exit 1

# Run file scan script
py scripts/gateway_scan/gateway_scan.py

The post-checkout hook runs after switching branches. The post-merge hook runs after a merge, which also commonly happens when pulling new changes from the remote repository.

The first command moves the terminal to the root of the Git repository. This helps ensure the script runs from the correct location, even if Git triggers the hook from within the repository.

The second command runs the Gateway scan script:

py scripts/gateway_scan/gateway_scan.py

Developers can also run this command manually from Bash or the command line whenever they want to trigger a Gateway file scan on demand.

If the repository contains multiple gateways you want to automatically file scan for, add a separate set of environment variables for each gateway in the .env file, create an API key for each gateway, and then update the gateway_scan.py script following the comments, so the script knows which gateways to scan.

Example Script & env. File

#------------------Gateway Scan Trigger Script Example------------------
"""
Run script to trigger file scans for gateways.
"""
import os
from pathlib import Path
from urllib import error, request

REQUEST_TIMEOUT_SECONDS = 5

print("Syncing Ignition Gateway...", flush=True)


def load_env_file(env_path):
	"""
	Load simple KEY=value pairs from a .env file without third-party dependencies.
	"""
	if not env_path.exists():
		return

	for line in env_path.read_text(encoding="utf-8").splitlines():
		line = line.strip()

		if not line or line.startswith("#") or "=" not in line:
			continue

		key, value = line.split("=", 1)
		os.environ.setdefault(key.strip(), value.strip().strip("\"'"))


# Read in .env file
load_env_file(Path(__file__).resolve().parents[2] / ".env")

# Grab environment variables
# TODO: VERIFY YOUR .ENV FILE HAS THESE VARIABLES SET CORRECTLY
# CREATE ADDITIONAL ENVIRONMENT VARIABLES FOR ADDITIONAL GATEWAYS IF NEEDED
# BY COPYING THE FOLLOWING FORMAT
GATEWAY_PORT = os.getenv("HTTP_PORT_IGN")
GATEWAY_IP = os.getenv("GATEWAY_IP")
GATEWAY_API_TOKEN = os.getenv("GATEWAY_API_TOKEN")

# TODO: ADD ADDITIONAL GATEWAYS HERE IF NEEDED!
gateways = {
	"Ignition": {"ip": GATEWAY_IP, "port": GATEWAY_PORT, "token": GATEWAY_API_TOKEN}
	# Additional gateways can be added here in the same format
}

actions = ["projects", "config"]

def post_scan_request(url, headers):
	"""
	Post a gateway scan request and return the HTTP status code.
	"""
	req = request.Request(url, headers=headers, method="POST")

	with request.urlopen(req, timeout=REQUEST_TIMEOUT_SECONDS) as response:
		return response.status


def trigger_scans():
	"""
	Trigger scans on the specified gateways.
	"""
	for name, config in gateways.items():
		ip = config["ip"]
		token = config["token"]
		port = config["port"]

		if not ip or not token or not port:
			var_name = "ip address" if not ip else "API token" if not token else "Port"
			print(f"Skipping {name}: Missing environment variable '{var_name}'.")
			continue

		headers = {
			"X-Ignition-API-Token": f"{token}"
		}

		for action in actions:
			# Ignition uses the final path segment to choose the scan type
			url = f""

			try:
				status_code = post_scan_request(url, headers)

				if status_code == 200:
					print(f"Success: File Scan {name} {action}")
				else:
					print(f"Failed: File Scan {name} {action} (Status: {status_code})")
			except TimeoutError:
				print(f"Timeout: {name} took too long to respond.")
			except error.HTTPError as err:
				print(f"Failed: File Scan {name} {action} (Status: {err.code})")
			except error.URLError as err:
				print(f"Connection Error: Could not reach {name} at {ip}. ({err.reason})")


if __name__ == "__main__":
	trigger_scans()

# ---------------------.env file example for one gateway--------------------
# HTTP_PORT_IGN= "your gateway's port"
# GATEWAY_IP= "your gateway's IP address"
# GATEWAY_API_TOKEN= "your gateway's API token"

#------------------Gateway Scan Trigger Script Example------------------
"""
Run script to trigger file scans for gateways.
"""
import os
from pathlib import Path
from urllib import error, request

REQUEST_TIMEOUT_SECONDS = 5

print("Syncing Ignition Gateway...", flush=True)


def load_env_file(env_path):
	"""
	Load simple KEY=value pairs from a .env file without third-party dependencies.
	"""
	if not env_path.exists():
		return

	for line in env_path.read_text(encoding="utf-8").splitlines():
		line = line.strip()

		if not line or line.startswith("#") or "=" not in line:
			continue

		key, value = line.split("=", 1)
		os.environ.setdefault(key.strip(), value.strip().strip("\"'"))


# Read in .env file
load_env_file(Path(__file__).resolve().parents[2] / ".env")

# Grab environment variables
# TODO: VERIFY YOUR .ENV FILE HAS THESE VARIABLES SET CORRECTLY
# CREATE ADDITIONAL ENVIRONMENT VARIABLES FOR ADDITIONAL GATEWAYS IF NEEDED
# BY COPYING THE FOLLOWING FORMAT
GATEWAY_PORT = os.getenv("HTTP_PORT_IGN")
GATEWAY_IP = os.getenv("GATEWAY_IP")
GATEWAY_API_TOKEN = os.getenv("GATEWAY_API_TOKEN")

# TODO: ADD ADDITIONAL GATEWAYS HERE IF NEEDED!
gateways = {
	"Ignition": {"ip": GATEWAY_IP, "port": GATEWAY_PORT, "token": GATEWAY_API_TOKEN}
	# Additional gateways can be added here in the same format
}

actions = ["projects", "config"]

def post_scan_request(url, headers):
	"""
	Post a gateway scan request and return the HTTP status code.
	"""
	req = request.Request(url, headers=headers, method="POST")

	with request.urlopen(req, timeout=REQUEST_TIMEOUT_SECONDS) as response:
		return response.status


def trigger_scans():
	"""
	Trigger scans on the specified gateways.
	"""
	for name, config in gateways.items():
		ip = config["ip"]
		token = config["token"]
		port = config["port"]

		if not ip or not token or not port:
			var_name = "ip address" if not ip else "API token" if not token else "Port"
			print(f"Skipping {name}: Missing environment variable '{var_name}'.")
			continue

		headers = {
			"X-Ignition-API-Token": f"{token}"
		}

		for action in actions:
			# Ignition uses the final path segment to choose the scan type
			url = f"http://{ip}:{port}/data/api/v1/scan/{action}"

			try:
				status_code = post_scan_request(url, headers)

				if status_code == 200:
					print(f"Success: File Scan {name} {action}")
				else:
					print(f"Failed: File Scan {name} {action} (Status: {status_code})")
			except TimeoutError:
				print(f"Timeout: {name} took too long to respond.")
			except error.HTTPError as err:
				print(f"Failed: File Scan {name} {action} (Status: {err.code})")
			except error.URLError as err:
				print(f"Connection Error: Could not reach {name} at {ip}. ({err.reason})")


if __name__ == "__main__":
	trigger_scans()

# ---------------------.env file example for one gateway--------------------
# HTTP_PORT_IGN= "your gateway's port"
# GATEWAY_IP= "your gateway's IP address"
# GATEWAY_API_TOKEN= "your gateway's API token"

Conclusion

Automating file syncs in Ignition 8.3 is a simple configuration change that can deliver meaningful improvements to your development workflow. By reducing manual steps and ensuring the Gateway always reflects the latest project state, teams can work more efficiently and with greater confidence. For engineers using Git to manage their Ignition projects, this approach unlocks the full benefits of modern version control while keeping SCADA development reliable and consistent.

The post Triggering Gateway File Syncs for Ignition 8.3 Using Git Hooks appeared first on DMC, Inc..

In this guide, we walk through the essential steps for downloading, configuring, and commissioning a WinCC Unified Comfort Panel using Siemens TIA Portal. You will learn how to set network parameters, configure users and security, enable encrypted transfers, and successfully load your project to the device. As Siemens Solutions Partners, we also provide tips for common commissioning tasks to save time and prevent headaches in the field.

All example screenshots were captured using TIA Portal V20 and an MTP700 Unified Comfort Panel (6AV2 128-3GB06-0AX1), but the same concepts apply across the WinCC Unified Comfort Panel family.

Pre-requisites

Before you begin commissioning, your system must meet certain prerequisites. For instance, your TIA Portal project must be set up with the appropriate hardware, network connections, and screens developed, and your WinCC Unified Comfort Panel must be powered on. Here is how you download your project and commission your WinCC Unified Comfort Panel.

Change IP Address

On the WinCC Unified Comfort Panel, go to Network and Internet, then Network settings. Here, select the port you wish to set the IP address for, then select Specify an IP address. Enter your desired IP address and subnet mask and click the Set IP address button.

Configure Users

To configure users, go to “Security settings” > “Users and roles” in the TIA Portal project tree. From there, create an administrator user, set a password, and assign it all roles. Feel free to learn more about Users and roles, by seeing a previous guide about setting up basic user profiles for WinCC Unified Runtime.

Configure Encrypted Transfer

An encrypted transfer ensures secure download of project files to your WinCC Unified Comfort Panel. On the panel, navigate to Service and commissioning > Transfer. Enable the Enable transfer checkbox and create a password.

In TIA Portal, go to Runtime settings under your HMI. In the General section, enable the Activate encrypted transfer checkbox and enter the same password that you created on your WinCC Unified Comfort Panel.

Download to the Unified Comfort Panel

Finally, it is time to download your developed screens and configured TIA Portal project to the WinCC Unified Comfort Panel. To do so, click on your HMI in the Project tree, then click the Download button in the toolbar. This opens the Extended download to device window.

From here, set the Type of PG/PC Interface to PN/IE, and the PG/PC Interface to your network adapter, and click Start search. If you do not see your device, you can see all compatible devices by selecting the drop-down menu above the table of possible target devices and choosing Show all compatible devices. When you see your HMI appear in the table, select it and click Load.

In the Load preview window, select Full download and click Load. Check to ensure that the option to download all users and authentication settings is selected. If successful, you should then see your TIA Portal screens loaded onto the WinCC Unified Comfort Panel!

Trusting the PLC Communication Certificate

By default, the Only allow secure PG/PC and HMI communication setting in your TIA Portal project for your PLC is enabled. Enabling this means that during the download of your TIA Portal Project to the PLC and HMI, a PLC communication certificate will be automatically generated and transferred to your WinCC Unified Comfort Panel. But this PLC communication certificate needs to be trusted by completing the following steps.

Go to Security>Certificates on the WinCC Unified Comfort Panel. In the Certificate store dropdown menu, select Other Certificates. Here you should see your certificate, and press Trust. Then, restart the HMI runtime software.

Additional Settings to Apply to Your HMI Panel

Beyond core commissioning steps, there are a handful of additional settings that can be helpful for further improving system reliability and maintainability. While they aren’t required for every project, these settings are commonly used to help reduce downtime, manage system access, and recover information and settings in the event of outages or reboots. Consider the settings below as they apply to your unique project requirements. Storage Device Set Up

Storage Device Set Up

When commissioning a WinCC Unified Comfort Panel, it is often recommended to activate the Automatic Backup option. This will ensure that the HMI device’s data is backed up to the storage device. If the WinCC Unified Comfort Panel becomes inoperable, you can simply purchase a replacement and insert it into the new HMI to resume operation.

To do this, slot in a SIMATIC HMI Memory (SD) Card into the X50 SYSTEM slot of the Unified Comfort Panel. Note, the system memory card of the comfort panel must be a SIMATIC HMI Memory Card.

Slotting in the storage device will cause a System memory card plugged dialog window to pop up. Click OK. This takes you to the settings Service and Commissioning/ Automatic Backup screen.

Here, click the Start button, and OK in the Start automatic backup dialog window to activate Automatic Backups. Once preparation is complete, the Status box will display automatic backup active.

Restrict Control Panel Access

To limit access to certain system settings, go to Security and Control panel access on the WinCC Unified Comfort Panel and click the checkbox to Enable password protection for control panel. This option requires a user with proper access to log in to use the WinCC Control panel, reducing the risk of accidental or unauthorized changes.

Automatic Runtime Start

To set a delay time before the automatic start of a project, click the icon with a wrench and a play button. This will open the Runtime Properties page. Locate the Automatic runtime start section and select a time from the “Waiting time(s)” dropdown menu. This is a very helpful setting to allow for some time before the automatic start to access the control panel.

Enable Smart Server Access

Enabling Smart Server Access allows VNC access to the WinCC Unified Comfort Panel.

To enable this setting in TIA Portal, go to Runtime settings, > Remote Access, >  Smart Server. Click the Enable Smart Server checkbox. You must then configure unique passwords for each User1 and User2.

If you wish to allow a user with that password to access the WinCC Unified Comfort Panel, click the Authorize User# for remote access to the panel checkbox. Upon your next download, the Smart Server will be enabled on the WinCC Unified Comfort Panel.

Firmware updates

Depending on the panel and the version of TIA Portal you are using, you may need to update the device firmware prior to commissioning. If this is the case, follow these steps:

1. It can be helpful to connect to the maintenance port on the HMI (PN-X2).
2. Right-click the HMI in the Project Tree while the device is offline. Go to HMI device maintenance and select Update operating system.
3. TIA Portal will now prompt you to connect to the HMI via ethernet. Enter the IP address of the PN-X2 port. A pop-up with a progress bar should appear on the HMI, and a pop-up will appear on TIA Portal stating the firmware is being transferred.

Date and time

Operators can also set a date and time on their panel by clicking the world icon in the sidebar menu. This will open the Language, Region and Formats/Date and time UI, allowing you to set your local date and time.

Synchronizing Time

If the clocks between the HMI and PLC are not synchronized, HMI communication may be limited or blocked. If the HMI still cannot read tags from the PLC after following the steps above, first ensure the correct time zone is selected for the PLC. Then check the clock on the PLC through Online and Diagnostics. Under Functions > Set Time, select Take from PG/PC Interface to synchronize the PLC with your PC.

Conclusion

Commissioning a WinCC Unified Comfort Panel is about more than getting screens to load. Proper network configuration, security settings, and runtime behavior all play a critical role in building a reliable, maintainable HMI system. By taking the time to configure encrypted transfers, user access, certificates, and startup behavior correctly, you set your system up for long-term success in the field.

Whether you are bringing a new HMI online, modernizing an existing system, or troubleshooting communication and security challenges, we can support you at any stage of the project. Partner with DMC to streamline your Siemens automation efforts and commission your systems with confidence.

The post How to Commission a WinCC Unified Comfort Panel appeared first on DMC, Inc..

From cutting-edge visualization capabilities to streamlined development workflows, this release is packed with upgrades that make it easier than ever to build scalable, efficient, and future-proof systems. In this blog, we’ll dive into the most exciting features of Ignition 8.3 and explore why upgrading to this latest version is a smart move for any organization looking to stay ahead in the world of industrial automation.

Technical Improvements and New Features

The new improvements of Ignition 8.3 can be classified into three broad categories: Applications, Power Historian, and Infrastructure. Each category contains improvements in current features and new features that will be valuable to users. Some features that we are particularly excited about are the event streams, power historian, new Siemens driver, and improved GIT integration. Read on for a detailed look at these exciting features in version 8.3. 

Applications 

The application improvements encompass changes to the Designer and the Gateway that will make the day-to-day development of Ignition a breeze.

Perspective Drawing Tools

The highly anticipated Perspective Drawing Tools have arrived in Ignition 8.3! This release introduces powerful new Drawing Tools alongside a native Drawing Editor, providing a seamless way to create and manage graphics within Perspective. Featuring a robust vector drawing package, these tools make it easier than ever to integrate Scalable Vector Graphics (SVGs) into your projects. Plus, with native binding integration, animating elements has never been more intuitive—enabling developers to craft dynamic, interactive visualizations with ease. 

Perspective Forms

The new Perspective Forms component brings a powerful and flexible way to capture and manage user input. This component allows users to configure the fields in the form, including its layout and validation process to suit the user’s needs. Forms being a popular way of capturing data makes this component an exciting one. Not only will it make the visuals look more consistent, but will also make it easy to handle submissions and validations for the data. 

Perspective Offline Mode

Offline Mode enables users to collect data even without an active network connection. Once the system reconnects, the data is seamlessly synchronized with the Gateway. This feature is particularly useful for entering data in remote locations where network service is unavailable. 

Event Streams

This new feature in Ignition 8.3 is a way to trigger data flow through the system and can function as a method of communication within and outside of Ignition. Event streams get triggered from a source which can be a message handler, API endpoint, Kafka, etc. The event source then goes into the Data Filter & Transform where you can add scripts or filters to your data to massage and transform the data between the source and the handler. Finally, the data goes to the Data Buffer and then the handler sends the data to its destination.  

Event Streams are a big shift in the way data is handled in Ignition. This powerful new architecture unifies multiple data sources into a seamless, event-driven framework. By consolidating these elements, Event Streams provides a more efficient and dynamic way to handle data throughout your system. Additionally, with robust error handling methods and a built-in test mode, it makes it easier for developers to build robust data pipelines.

New Gateway UI

With the intent to make Gateway UI work better at scale, Ignition 8.3 is going to have a new Gateway UI designed from scratch. It will have improved search functionality and bulk editing capabilities to make finding and changing gateway configurations a lot easier. 

Power Historian 

Ignition 8.3 introduces a new Historian, streamlining the implementation of the Ignition Historian. The Power Historian enhances integration with platforms like Snowflake and Influx while removing the need for a history splitter between local and remote historians. Good news for the Power Historian is that it is included in the existing Historian Module, so existing users with a support contract will get it when they upgrade to 8.3! 

Features 

• Supports ~2M tags ingested as compared to ~500k in the existing historian
• Easy configuration 
• Richer data modeling capabilities 
• Open source and cross-platform integration 
• Ability to change the path of a tag without losing history

Probably one of the most exciting features of Ignition 8.3, the Power Historian will add a lot of value to projects due to its greatly improved capacity and performance.  

Infrastructure 

With Ignition 8.3, IA also promises to bring about “the new SCADA” which include a lot of improvements that we as developers are very excited about. It includes the following new infrastructure features.

Source Control Compatibility and Secret Provider

Source control compatibility is another much-awaited feature added to Ignition 8.3. Along with making collaboration and deployments easier, this feature will also make projects more secure with its secrets management functionality. This feature includes:  

• New file structure and configuration will enable source control compatibility (easy integration into Git and other platforms). 

• Source control will also have a Secret Provider capability to keep confidential information such as passwords, keys, and bearer tokens safe. 

• Secrets management also makes it easier to change passwords since every password usage can be linked to a location in the Secret Provider.

Gateway Settings Configuration via REST API

Gateway settings can be configured via scripting and Ignition will autogenerate a REST API schema document based on the modules installed on the Gateway. 

Deployment Modes

The deployment modes promise to be a huge improvement for the developers and process owners alike. This will give the system the ability to run a Gateway in different modes with alternate settings will make developing, testing and deploying a smoother process. 

• Users can now define any number of modes on the Gateway to enable ease of deployment across modes. 

• In each mode (for instance Development, Staging and Production), users can define alternative settings for any configuration. 

  • For instance, Development mode could be set up to use a Simulator while Production mode interacts with an actual device. 

• All production modes are stored in a single gateway backup. This means one Gateway backup can be used across all Gateways and eliminates the need for tracking differences between Gateways. 

Updates to OPC-UA

With the new Ignition version, users can specify which tags to share with specific OPC UA clients. OPC events will also be added to event streams and will be logged on to the Gateway. 

Other New Features

• New Siemens S7+ driver will have the capability to browse PLCs for tags with symbolic addressing capability
• Twilio voice notification and Whatsapp integration 
• Improved Alarm Aggregation and Security 
• Improved searching and filtering across Gateway and Designer 
• Kafka integration 
• Kubernetes integration with Helm Charts 

Ignition 8.3 promises to be a significant step up in the SCADA platform’s capabilities! 

Why Should You Upgrade 

Still on the fence about upgrading to Ignition 8.3? Beyond the exciting new features, we talked about above, here are some key details to help you decide if an upgrade is right for you. 

First, the upgrade process will be seamless from 8.1 Gateways. If you’re running an older version, it’s best to upgrade to 8.1 first before making the jump to 8.3. 

Additionally, 8.3 is expected to have long-term version support and regular updates. With the release of 8.3, it is expected that releases for 8.1 will slow down and be mainly focused on bug fixes and security updates. While 8.1 is expected to be supported through 2028, active support for 8.1 will end in 2026–meaning now is the time to start planning your transition. 

The post Ignition 8.3–What’s New and Reasons to Upgrade Your Project appeared first on DMC, Inc..

1. Ctrl+m Hot Key for Runtime

Quickly entering and exiting runtime is the most effective method for testing the screen’s functionality. The fastest way to do this is to simply hit Ctrl + M from inside GraphWorx. Once inside the runtime, the only way to exit the runtime is to hit Ctrl + M once again.  

2. Find and Replace Through All Screens at Once with Ctrl+F and Ctrl+H

Need to search through all your screens at once? Simply hit CTRL + F while NOT inside the scripting window to display the popup shown below. Select what “Type” you want to find from the “Find Type” section. Next, choose if you want to search the current open section, the current display, or multiple files. If searching through multiple files, either add your files individually or the folder containing the relevant files. Add in your keyword and search. Note, other screens will open, so be sure to save the current screen before leaving it. 

If you are trying to replace an item instead of finding it, hit CTRL+H instead. All the steps will be the same, except there will be an extra text entry section for what you want to replace the text with. 

3. Calling Script or Event an Opening a Screen

Calling an event on a screen opening can be quite useful. Often, there are values or connections that need to be initialized when a screen is called. To set this up, add a button to the screen and set the initial click to true.

From here, you can add your event or script that should be called at the screen opening. Next, turn off the button’s visibility in the project explorer on the left side. Now the button won’t be interactable from the user, but will still call the startup action or script when the screen is opened.  

4. Can’t Add a Script to a Button?

Are you unable to find a function you wrote from the “RunScript” drop-down? 

That is because the function needs the following parameters to be passed in:  

sender : System.Object, cmdArgs : Ico.Gwx.CommandExecutionEventArgs 

Now, the script should be able to be linked to the “RunScript” drop-down. 

5. C# Syntax to Get Close

If you are new to coding in JavaScript. net and unsure of how to get started, C# is a similar language, as they are both .NET languages. Be warned, the two languages do have some differences, and some fine-tuning and error fixing will be required. Luckily, Iconics has built-in error checking! 

6. Check for Errors in Script

In the top ribbon of the code view window, there is an error checking button.  

This button will scan through the script and check for any syntax errors. If there are any errors within the script, the first error will be displayed at the bottom of the window. 

Please note that this only checks for syntax, and bugs and invalid function calls will not be flagged. 

7. Adding Variables into Workbench SQL

When querying from SQL, it is often useful to insert variables so that the query can be dynamically modified. To implement this, within the workbench, add the ‘@’ to declare that the following is a variable that will be defined later.

This can be utilized within the script by adding a string to the SQL call.  

This line sets the variable “@Second” to “World”, modifying the query to “SELECT [first] FROM dbo.Table_2 where second = World.”  

8. Inserting Variables into SQL Calls

This can be further dynamized by turning the string that is being passed in, in this case “World”, into a variable.  

This is a simple use case, but the ability to pass variables into SQL queries from a script enables more complex usage, such as passing in user data and retrieving the relevant information. 

9. How to Find Workbench SQL Path

Trying to find the correct path for SQL data sources or modifiers in the workbench can be challenging, and typos can be difficult to identify. An easy way to copy this path is to add a process point and click the ellipse next to “data source.” 

From here, navigate to the data source or modifier from the drop-down menu. 

Now, the process point’s data source will have the appropriate path to the selected data source or modifier. 

This can be copy and pasted into a script and will then point to relevant spot in workbench.  

10. Locked out of a Local Instance of Iconics Genesis 64?

This trick only works if you are working on a local instance. If you exceed the number of login attempts, you will be locked out of the account you are using.  

If the Iconics configuration SQL database is local, you can access it through Microsoft SQL Server Management Studio. Once you connect to your local server, two databases should appear, “IcoSetup” and “IcoUnifiedConfig.” We care about the latter. Open IcoUnifiedConfig and then open the Tables subsection. Scroll through until you find dbo.SEC_Users, right click and hit “Edit Top 200 Rows.” If there are more than 200 users on your server, this will not work, and you will have to use a SQL query to modify the value. Once the page is open, scroll until you find the relevant username, move over to the “AccountLocked” column, and change this value from True to False. You may need to restart Iconics, but your account should no longer be locked! 

Learn more about DMC’s Iconics programming expertise and contact us for your next project.

The post Ten Tips and Tricks for Iconics Genesis 64 appeared first on DMC, Inc..

Congratulations to our team members Brandon Tanner, Sheila Kennedy-Moore, and Nicoli Liedtke for representing DMC and bringing home the win! 

The Competition 

DMC and BIJC Ltd competed live on stage in an industrial automation challenge for the ICC Build-a-thon’s grand finale. To challenge our Ignition programming skills, we had two days to program an Ignition application to control a convenience store. The store had a car wash, gas pump, and food market. 

Opto 22 provided the PLCs and a miniature convenience store that we could control. The goal provided by Inductive Automation was to make it easy to expand our brand of convenience stores and take over the world with our stores. We decided to include a Minion theme in our project, saying that we were hired by Gru to take over the world with our convenience stores. Our tagline was, “This is a first for DMC, being hired by a villain.” 

To accomplish this goal, DMC made a high-level map screen displaying the location and the status of each store. Users could click on a store location on the screen to see more details. In order to verify that each store was profitable for our business expansion, we used simulation logic to simulate transactions. We also tracked the store’s transactions and profitability with custom dashboards. Our solution streamlined configuring new stores by prompting the user to fill out its name and select the location on a map once the project detected new MQTT tags. 

One highlight of our solution was our slick user interface (UI). We implemented custom CSS in our project to give the UI a polished look. This is a complex aspect of Ignition that not everyone has experience with, and we spent extra time on the UI to make our project stand out. 

Other fun aspects of the project included creating a car wash button with an animated car and bubbles. We also created a custom SVG to control the store’s lights. Every time the car wash ran, we brought out bubble guns. 

Each member of DMC’s team presented on part of the project. Sheila handled the introduction and the project overview.  Nicoli did the technical project review and Brandon took on the project curveball which was adding a new store to the application. The audience voted on the winner, and we were proud to take home the honors and wear the orange winner’s blazers! 

If you are interested in digging into the code that we made during the Build-a-Thon, we’ve uploaded our project to the Ignition Exchange.  

Ignition Community Conference 

The Ignition Community Conference’s mission is to see new technology, share ideas, and find inspiration. In addition to competing in the Build-a-Thon, DMC led a presentation on Optimizing Load Time in Ignition Perspective by Elizabeth Reed and Casimir Smith. 

DMC and Ignition 

DMC is an Ignition Premier Integrator. We are Ignition 8.1 Gold certified, illustrating our commitment to delivering Ignition expertise. Our partnership allows DMC access to exclusive technical resources which enables us to deliver top-notch customer service to our clients. 

The post DMC Wins the 2024 ICC Build-a-Thon appeared first on DMC, Inc..