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

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

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

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 a recent Ignition 8.3 project, we had two gateways in a single Git repository that needed to share library elements. While 8.3 enables a more Git-centric workflow, it does not provide a built-in mechanism to keep shared resources synchronized across multiple gateways. Without an automatic way to manage this, shared libraries can quickly drift and become difficult to maintain.

We addressed this by creating symbolic links from each gateway’s library folders to a shared “source of truth” directory. A symbolic link (symlink) is a special file that points to another file or folder—like a shortcut at the filesystem level. When you access it, the system transparently redirects you to the target location. This approach allows both gateways to reference the same underlying files while still fitting cleanly into a Git-based workflow, making it a simple, low-friction way to keep shared resources consistent.

This blog walks through how to set up shared libraries between two Ignition gateways in a single Git repository using symlinks on Windows, helping you avoid duplication and keep shared code synchronized in one place.

With this setup, any time a symlinked file is modified in a Designer and saved, it’s immediately overwritten in the shared “source of truth” location. After changes are made and tested in one gateway project’s Designer, the files can be committed and pushed to the repo as usual.

We’ll walk through setting up a shared script library folder as an example. You can use the same pattern to share views, styles, and additional files as needed for your project.

What are Symbolic Links?

A symbolic link, often referred to as a symlink, is a reference point in a filesystem that points one file or folder to another location. Instead of duplicating the files, a symlink acts as a pointer. When an application accesses the symlinked path, the operating system (OS) redirects it to the target destination.

In Ignition 8.3, a symlinked folder behaves exactly like a project directory. Associated scripts, views, and resources load as one would expect; however, the actual files live somewhere else in the filesystem.

Sample Repository Structure

Here is a visual representation of what the structure would look like after the symlinks are set up. The file structure for gateway1 and gateway2 down to script-python is default to ignition. You will have to create the “shared” folder location and structure manually in your repo, and you can organize it anyway you want.

repo/
└── gateways/
   ├── shared/
   │   └── script-python/
   │       └── library/ (real files live here for this example)
   │
   ├── gateway1/
   │   └── projects/
   │       └── project1/
   │           └── ignition/
   │               └── script-python/
   │                   └── library/ -> symlink to ../../../../../shared/script-python/library
   │
   └── gateway2/
       └── projects/
           └── project2/
               └── ignition/
                   └── script-python/
                       └── library/ -> symlink to ../../../../../shared/script-python/library

Setup Steps for Windows

Before creating any symbolic links, complete the following one-time setup steps. Every developer working with this repository must perform these steps on their local machine. Skipping them can result in broken links when the repo is cloned or checked out.

Prerequisites

1. Enable Git symlink support

By default, Git on Windows may treat symlinks as plain text files. This setting ensures symlinks are created and checked out correctly.

Run the following command in Git Bash:

git config --global core.symlinks true

git config --global core.symlinks true

2. Enable Windows Developer Mode

Developer Mode allows non-admin users to create symbolic links without permission-related issues.

Settings > Privacy & Security > For Developers > Developer Mode

Turn Developer Mode on.

3. Restart your computer

Restarting your computer ensures Developer Mode is fully applied before creating symlinks.

Initial Creation of Symbolic Links

Follow the steps below to set up the initial symlinks for the script-python library folder in our example. The same approach can be used for other shared resources.

Gateway 1:

1. Open Command Prompt as an Administrator

2. Navigate to the target directory for your symbolic links

Move to the directory where the symlink will live in Gateway 1: cd gateways\gateway1\projects\project1\ignition\script-python

3. Move any existing library files:

If you already have files in the library folder and/or the library folder exists, move the entire library folder to the shared directory at gateways/shared/script-python. If not, skip this step.

If you leave the library folder here: \gateways\gateway1\projects\project1\ignition\script-python. The following error will occur because Windows cannot create a link where a directory already exists:

4. Create the symbolic link

Run the command below to create the symlink linked to the actual files in the shared location:

mklink /D library ……….\shared\script-python\library

5. Verify the symlink was created successfully

Verify the link has been created by running the command dir at the symlink location in the command prompt. If the symlink was created correctly, then you should see it in your output.

In addition, you can visually verify that the folder was created correctly in File Explorer by looking for the arrow icon in the bottom left. When you double-click into this symlinked folder, it will take you to the location it is linked to.

Gateway 2

Repeat the same steps for Gateway 2, adjusting the path as needed:

cd gateways\gateway2\projects\project2\ignition\script-python

Create the symlink pointing to the same library location.

Once both gateways are linked, the shared library folder is ready for use. Any changes made through one gateway’s Ignition Designer will be written directly to the shared directory and can be committed to Git as usual.

Ignition Designer/Gateway Refresh and Test

After creating the symbolic links, the final step is to confirm that Ignition detects and uses the shared files properly. Because Ignition doesn’t automatically reload filesystem changes, users must manually initiate file and project scans to update each gateway.

1. Close all open Ignition Designer sessions

Closing active sessions of Designer resolves any potential validation interference caused by cached projects.

2. Trigger file and project scans on both Gateways

On each gateway, run the following:

• Platform → Overview → Scan File System
• Platform → System → Projects → Scan Projects

3. Open Ignition Designer for Gateway 1

• Create a new script or modify an existing script in the share library.
• Save the changes.

4. Refresh Gateway 2

• From the Gateway 2 web UI, trigger both the file system scan and project scan again.

5. Open Ignition Developer for Gateway 2

• Open Ignition Developer for the second Gateway and verify that the adjustments are present.

Now the library symlinks are set up and ready for use. If the changes appear as expected, the symbolic link configuration is working correctly, and both gateways are pulling from the same shared source of truth. Once validated, follow your project’s specific git workflow to push these changes to your repository.

Final Thoughts and Best Practices

It’s important to keep in mind that whenever a file in the gateway filesystem is changed, the gateway doesn’t automatically update to reflect those changes. You will need to perform two file scans for the latest changes to be reflected. The screenshots below show where to trigger these scans.

At some point during testing, you may need to view/test a library file in both gateways. In this scenario, it is important to regularly perform the above file and project scans, as changes are being made and saved. Below is an example of a possible order of operations:

1. Make changes to library file in Gateway 1 project designer.
2. Save changes to library file in Gateway 1 project designer.
3. Open Gateway 2 webpage UI.
4. Press Scan File System on both Platform > Overview page and Platform > System > Projects page for Gateway 2.
5. Open a fresh designer session of Gateway 2’s project to view latest changes.

Keep in mind that if changes are made in both gateways to the same library object, the last place it was saved will be the effective, latest state of the file. In the above example, if a change is made in Gateway 2’s project designer session and saved there, Gateway 1 would have stale library files internally, requiring file scans to refresh them.

To avoid accidentally overwriting changes, the best practice is to separate work into separate commits and modify a given shared file from only one gateway at a time.

Finally, make sure the other developers run through the setup steps on their machines to avoid accidentally breaking any symbolic links during initial setup.

The post Setting Up Symbolic Links for Shared Project Libraries Across Ignition 8.3 Gateways appeared first on DMC, Inc..

The Example

For this example, let us imagine there are simple weather stations across the country reporting the communication status, the type of weather (represented by an integer), and temperature. Each city is set up with User Defined Types (UDT) containing this information [Figure 1]. We will then use this information to build an interface to allow users to individually enable and disable weather stations and view their statuses.

Setting Up the Table

First, we will add a table to a Perspective screen and bind the table’s data property to the tags. To do this, we look through the Cities folder and parse the tag values into a JSON format [Figure 2].

This method is preferred for its scalability, as new cities added to the tags will automatically appear on the screen. This results in a table with the raw tag data.

Column Configuration

But how do we make the data easier for users to quickly understand? We can do that by enhancing the table by configuring the five columns to have the following display:

1. City: the name of the city
2. Enabled: a toggle switch controlling if a weather station is enabled or disabled
3. CommsStatus: an icon indicating if a weather station is communicating properly
4. Temperature (F): the last reported temperature
5. Weather: an icon based on an enumeration

The end goal is to have a table that looks like this.

Background Knowledge: Passing Data into an Embedded View in a Table

Before discussing the detailed process for configuring each column, let’s first explain how to transfer data into embedded views in tables, as this understanding is crucial for our example. To start, the Perspective table component has a set of properties per cell. The full list is:

• :column : the current column name
• columnIndex: index of the current column
• row: index of the current row
• rowData: table data for the current row in a JSON format
• rowIndex: the displayed index of the current row (if only a select number of rows are displayed at a given time)
• value: the value being passed into the cell

The table component also has a columns property, where for each column you can set the viewPath to be a path to another Perspective View. This is how you configure a view to be embedded in a table. Now the problem is, how do you pass information from your table into this embedded view?

The answer is to set the embedded view’s parameters to match the names of the table properties. For example, if you want to pass in the name of the current column into your embedded view, you would add a parameter called column to your embedded view.

You can also add custom properties under columns.viewParams to pass into the embedded view. Similar to the built-in Ignition cell properties above, once an input parameter with the same name as the new custom property is set up on the embedded view, that value will be passed in from the parent.

Column: Enabled

Now that we have the background knowledge of how to pass information into an embedded View, let’s use that to configure the Enabled column. The first step will be to create a view called EnabledView that contains a toggle switch component and link the view path to the Enabled column’s viewPath property [Figure 5]. By adding an input param called value to EnabledView [Figure 6], the enabled status will be passed automatically into EnabledView.

But how do you make sure the tag value is updated when the user presses the toggle button? There are a few different possible solutions for this:

Option 1: Create a Message Handler to write to tags and refresh the table data. This is DMC’s recommended approach because it centralizes all tag reads in one place, which is more performant, especially for large datasets. It also ensures that the table data is always synchronous, which is necessary if the table has columns that rely on multiple tag values. For instance, in our example, the CommsStatus column relies on the Enabled column data. So when you update the Enabled column, you also want the CommsStatus column to update.

Option 2: Pass in the tag path into the embedded view and do a bidirectional binding within the embedded view. While this approach may be more straightforward for smaller tables, it can negatively impact performance because tag reads occur in each cell rather than in a single table-level read. This method also does not automatically refresh the table data, which, in our example, would mean the CommsStatus column would not update to reflect the change in the Enabled column.

And you might be thinking–why not just have value property in the EnabledView set to an in/out param? Despite being an in/out param, this will not actually write back to the desired tag. This is because the table cell is linked to the manually parsed dataset and is not bidirectionally linked to the original tag.

For this example, we will implement a Message Handler. The first step in implementing this is to add another input, called row, to the EnabledView. This will inform the Message Handler what index of the data array to use. Notice that row, not rowIndex, is used since rowIndex only uses the rows that are displayed. If there were more cities, this number would differ from row as it would change depending on which page is being viewed.

Then, on the toggle switch’s component event, we will add a script to trigger the Message Handler being sent [Figure 7]. Finally, on the main table, we will add a Message Handler that takes in the payload and uses that to both write to the tag and refresh the entire table [Figure 8]. After making those changes, toggling the switches writes to the respective tag!

Column: CommsStatus

This column will use an icon to indicate the communication status based on both the rowData.CommsStatus and rowData.Enabled properties. To pass that information into the embedded view, we will add rowData as a param to the View [Figure 10].

The bindings on the icon property are set up such that:

1. A gray material/wifi_off icon indicates the station is disabled.
2. A gray material/wifi icon indicates comms are good and the station is enabled.
3. A red material/wifi_off icon indicates that comms bad and station is enabled.

Then the color property has the following binding, where the color codes are hardcoded. If you would like to do more advanced CSS handling of the color animations, check out DMC’s blog on CSS styles.

Column: Weather

The Weather column will be set up similarly to CommsStatus, but we’ll add an additional input param called color, which is bound to the icon’s color property [Figure 13]. In the table, in the Weather column, add a viewParam.color and bind it to a new field where users can specify the color of the weather icons [Figure 14].

Conclusion

With the customization now finalized, the table provides users with a straightforward method for enabling/disabling each city, alongside clear graphical representations for efficient data interpretation. This enhancement streamlines user interactions and helps increase the functionality of the Ignition system.

At DMC, we know how important it is to our clients to have easy-to-understand data visualization. Using embedded views in tables is just one of the many ways engineers at DMC leverage Ignition’s tools to build intuitive screens that provide value to our customers. For more tips and tricks, check out our other blogs where engineers explore more ways to use Ignition’s powerful features.

The post Ignition Perspective Tricks: Embedded Views in Tables Cells appeared first on DMC, Inc..

Kanoa is a next-generation Manufacturing Execution System built on Ignition that helps manufacturers improve production visibility, support better decision-making, and advance digital transformation on the plant floor. Through this partnership, DMC can offer clients an additional, flexible MES option that complements our existing Ignition-based and custom manufacturing solutions.

We’re excited to collaborate with the Kanoa team and see this as a strong fit for many of the manufacturers we work with.

The post DMC Joins Partnership with Kanoa appeared first on DMC, Inc..

Integrating SharePoint into Ignition can reduce friction between organizational teams without compromising system reliability. The core draw is bringing enterprise information closer to operations and reducing manual work like exporting reports, emailing files, hunting for the latest SOP, or duplicating data across systems.

In some organizations, SharePoint may already be the system of record. As part of the Microsoft suite of tools, it is depended on for document management and collaboration. In this case, integrating SharePoint into Ignition can expand system capabilities to leverage the strengths of each tool and reduce separation or duplication between operation/production and other teams.

Other organizations may be looking to move away from paper-driven or manual processes. In these cases, the combination of Ignition and SharePoint can allow the concerns of both manual production or record keeping and old-fashioned document storage and sharing to be addressed in a way that sets teams up for lower overhead.

What Ignition and SharePoint Each Do Best

As a SCADA platform, Ignition excels at real-time and near-real-time operations. It connects to control system components, surfacing information to users in a way that is conducive to effective and efficient decision-making during operation. Additionally, it’s built around SQL database connectivity rather than proprietary data storage formats. It natively integrates with databases such as PostgreSQL, Microsoft SQL Server, and MySQL, enabling robust historical data logging, reporting, and analytics. This makes it well-suited for data-driven applications and integration with other data analytics tools. Ignition also supports Python scripting throughout the platform, allowing engineers and developers to build custom logic, automation routines, and integrations. Its API-driven design and flexible UI development tools enable deep customization, making it adaptable.

SharePoint, on the other hand, is designed for document handling and collaboration. At its core, SharePoint provides a centralized and structured environment for storing, organizing, and managing digital content across an organization. Unlike traditional file servers, it layers document management capabilities such as version control, metadata, and permissions directly onto cloud-based storage, making information both more accessible and more governable. Its built-in search engine further strengthens this by allowing users to retrieve relevant documents and data across sites, libraries, and even connected Microsoft 365 services. Procedures, manuals, reports, and audit artifacts all fit naturally into SharePoint’s structure and methodology. Beyond document storage, SharePoint serves as a flexible platform for building internal portals and collaborative workspaces, with sites acting as hubs for departments or projects and Power Automate integration providing options for automating workflows like approvals, document routing, and notifications.

The value in integration between these two systems comes from exposing information between them, while allowing each to preside over the scope of work it was designed for. When humans are in the loop doing document management, approvals, or reviewing reports, integrating SharePoint into Ignition provides benefits in terms of transparency between teams and the reduction of duplicated data.

Common Integration Use Cases

Publishing Reports

One common pattern for integration is publishing content out of Ignition. Scheduled reports, batch summaries, or downtime logs can be automatically uploaded to a SharePoint document library where supervisors and engineers already expect to find them.

From a technical standpoint, this typically involves formatting data into a document and then using Ignition’s scripting capabilities and SharePoint’s APIs (such as Microsoft Graph or SharePoint REST endpoints) to programmatically upload the files to the appropriate SharePoint site, folder, or document library. Metadata — such as production line, batch ID, timestamp, shift, or product type — can be attached to each file on upload, making the content easier to search, filter, and organize.

This allows other organizational teams or team members – such as engineers or managers – to access the latest production summaries, downtime logs, or performance reports directly from SharePoint, alongside other operational and business documents. This creates a more unified information flow between OT (operational technology) and IT systems, which reduces separation or duplication between plant-floor data and enterprise documentation.

Additionally, storing Ignition-generated content in SharePoint enables downstream workflows. For example, the arrival of a new batch summary could automatically trigger a review or approval process via Power Automate, notify stakeholders in Microsoft Teams, or be archived according to corporate retention policies. Over time, this turns SharePoint into not just a storage location, but an active collaboration and governance layer for industrial data.

Document Display in Ignition

Another high-value use case for integrating SharePoint with Ignition is using SharePoint as the authoritative source of documentation and then surfacing that information directly within Ignition’s operator interface. In many facilities, critical operational information — such as standard operating procedures (SOPs), wiring diagrams, and manuals — requires formal version control, approvals, and periodic reviews, making SharePoint a natural system of record. However, operators and technicians typically spend most of their time inside Ignition HMIs rather than browsing SharePoint sites. If they must leave the HMI to search for documents, it can cause frustration and increase the likelihood that outdated or unofficial copies will be used.

Through integration, Ignition screens can dynamically link to or embed documents that reside in SharePoint. Technically, this can be accomplished by storing document URLs or metadata in Ignition and using web views or API calls to retrieve the correct file from SharePoint in real time. The system can also be designed to filter documents, so users see only the most relevant information. For example, when an operator selects a specific piece of equipment in Ignition, the screen could automatically display the latest approved maintenance checklist associated with that asset.

Because the documents remain managed in SharePoint, this approach preserves strong governance without sacrificing usability. SharePoint’s built-in versioning ensures that only the most current, approved documents are presented, while historical versions remain available for auditing or reference. Approval workflows, document review cycles, and change tracking can all continue to operate in SharePoint, independent of Ignition. From the operator’s perspective, however, they simply see the right document in the right place at the right time, embedded seamlessly within their normal workflow.

This integration also improves consistency and reduces risk. Instead of multiple copies of procedures floating around on local drives or printed binders, there is a single, controlled source of truth in SharePoint that is directly connected to the HMI. If a procedure is updated due to a safety change or process improvement, the new version becomes instantly available to all operators through Ignition without requiring manual redistribution.

Exception Log Tracking

Some teams leverage SharePoint lists as a lightweight mechanism to capture operational information that is important from a business, quality, or compliance perspective but not critical to real-time control. Instead of pushing everything into an industrial database or embedding every data-capture requirement directly into Ignition, teams use SharePoint as a parallel system for structured tracking of contextual or administrative records that surround plant activity.

In practice, this often includes exception logs, operator notes, minor deviations, near-miss reports, shift comments, maintenance observations, or non-critical audit records. These are pieces of information that benefit from being organized, searchable, and reviewable across departments, but do not require the speed, determinism, or reliability guarantees of a control system database. SharePoint lists are well-suited for this because they allow teams to define custom fields, validation rules, and views without requiring a dedicated application.

Integration with Ignition in this scenario usually takes the form of one-way or loosely coupled data exchange. For example, Ignition might provide an operator interface that allows users to submit an exception entry or add contextual notes about a process event. Behind the scenes, Ignition scripts or API calls then create or update corresponding entries in a SharePoint list via Microsoft Graph or SharePoint’s REST endpoints. Alternatively, Ignition could automatically log certain classes of events — such as repeated minor alarms or operator overrides — into SharePoint for later review by supervisors or quality teams.

The critical design principle in this pattern is that SharePoint remains outside of the control loop. Ignition continues to handle all real-time monitoring, interlocking, alarming, and automation logic, while SharePoint serves as a complementary system with improved visibility for team collaboration. Operations teams retain a responsive, high-performance control environment in Ignition, while IT and quality teams gain structured, shareable records in SharePoint that can be integrated with broader business processes. Over time, this creates a balanced ecosystem where industrial data and human-centered documentation coexist without overloading the control system with non-operational responsibilities.

Integration Approaches and Architecture

Most SharePoint integrations with Ignition are built around API access using either the SharePoint REST API or Microsoft Graph API, which are invoked directly from Ignition scripting. SharePoint’s APIs expose a robust integration surface that allows external systems to programmatically interact with SharePoint as a structured content and data platform. Through standard web-based endpoints, external applications can create, read, update, and delete sites, document libraries, files, and list items, and manage metadata, permissions, and versioning. All interactions are secured through Entra ID authentication and role-based access controls, ensuring that integrations follow the same security policies as human users.

Within Ignition, this connectivity is implemented through its Python-based scripting environment, which can issue HTTP requests to these APIs. Using built-in networking functions or third-party libraries, Ignition scripts can transmit data and handle responses in real time. This enables Ignition to reliably read from and write to SharePoint while staying tightly aligned with Ignition events, tags, and transaction logic.

Generally, a middleware layer that handles authentication and API complexity is also required. This can take the form of a simple web service, server-less compute function, or gateway-hosted service and helps to manage authentication tokens and segregate concerns. As an example, this might take the form of a Python application that runs on the ignition gateway, with the following flow:

Integration Considerations

Governance and Ownership

As is common when tools are bridging the gaps between organizational teams, it is worthwhile to consider who is responsible for maintaining each part of the solution long-term. In the case of this integration, it is likely that the controls or operations team will own the Ignition side of the system, including screens, control logic, and scripts, while IT will own the SharePoint side, including permissions/authentication and structure. Defining the boundary and interface between these two sides to the integration explicitly can reduce friction and maintenance overhead down the line. Things to consider:

• Folder structures and naming conventions
• Retention and archiving rules
• The change management process

Authentication and Security

Ignition authenticates to SharePoint as an application (rather than receiving delegated permissions from a user log-in) using a dedicated service account. This requires setting up an app registration in Azure Entra ID, with the following basic steps:

1. Create a New App Registration in Entra ID via the Azure Portal
   • At this point, Entra ID creates the application identity with an Application (client) ID and Directory (tenant) ID. These values are important for later configuration.
2. Add a Certificate
   • You must prove the app’s identity when requesting tokens. Go to “Certificates & secrets” and upload a certificate; the thumbprint and private key for this certificate will later be used to authenticate.
3. Assign API Permissions (Scopes)
   • This defines what the app is allowed to do. Common examples include: Sites.ReadWrite.All (to create/update files and lists) or User.Read.All  (to read user profiles).
4. Grant Admin Consent
   • Most SharePoint/Graph permissions require tenant-wide approval. Without this, your app will not be able to access SharePoint in most enterprise tenants.
5. Use These Values in Your Integration
   • You will typically need the following to acquire access tokens from Entra ID:
     • Tenant ID
     • Client (Application) IDCertificate (thumbprint + private key)
     • Certificate (thumbprint + private key)
     • API Scopes (e.g., Graph’s User.Read or SharePoint’s Sites.ReadWrite.All)

In addition to setting up an app registration for Ignition, general security guidance, such as not hardcoding credentials and using the lowest permissions required are important for implementing the integration as securely as possible.

Expectations and Error Handling

Ensuring the usefulness of the integration depends on keeping expectations aligned with what each tool is good at and implementing robust error handling to account for connectivity issues. For instance, it is reasonable to expect SharePoint to handle files and metadata in a batched or event-driven way. SharePoint excels at handling files and list-formatted data, and API based access aligns well with low-frequency updates. However, it would not be reasonable to use SharePoint to store high-frequency operational data or to act as a data historian; it is not set up to handle streams of data, and it is not optimized for time-series information. Similarly, it is likely reasonable to expect that the normal operational state of the system would be Ignition and SharePoint communicating with relatively low response times, but likely not reasonable to assume perfect connectivity or 100% uptime.

To this end, it is valuable to implement handling to account for cases that would differ from the reasonable expectations for the system. This could include:

• Including timeouts to prevent calls from blocking indefinitely,
• Clear logging for failures,
• Retry logic; likely with limits on the total number of retries,
• Caching of queried data (like SOP’s or manuals) when practical

Considering these cases allows the overall system to continue functioning as smoothly as possible when something goes wrong, and forethought into failure handling allows for a simpler debugging process.

Building Your SharePoint and Ignition Integration

Integrating Ignition with SharePoint in a secure, scalable, and maintainable way is technically feasible for many organizations, but doing it well often requires a blend of OT, IT, and cloud expertise that rarely exists fully within a single team. For this reason, working with an experienced consulting partner like DMC can be highly valuable when undertaking this type of integration.

A knowledgeable partner brings deep, practical experience with both Ignition and the Microsoft ecosystem. This helps avoid common pitfalls around integration interfaces and authentication. Rather than learning through trial and error, organizations benefit from proven design patterns and best practices that have been refined across multiple projects and industries. DMC maintains Ignition Premier Integrator status and Microsoft Solutions Partner status and has extensive experience developing solutions in both Ignition and SharePoint. Additionally, DMC’s diverse experience across both manufacturing/OT and business-centric/IT projects enables us to facilitate conversations between organizational teams and stakeholders, ensuring the solution is designed in a way that works for all users. This cross-functional perspective is often just as important as the code itself.

Finally, working with a partner accelerates delivery. Instead of dedicating internal resources to building and troubleshooting unfamiliar components, teams can focus on their core responsibilities while the consultant handles the complexity of the integration. The result is a more robust solution delivered faster, with a clearer path for future enhancements.

The post Integrating SharePoint into Ignition: A Practical Guide appeared first on DMC, Inc..

The Ignition Community Conference (ICC) was a blast this year. Hosted at Sacramento’s SAFE Credit Union Convention Center, Inductive Automation definitely leveled up this year. From technical deep dives to forward-looking industry discussions, ICC 2025 delivered plenty of insight and inspiration. DMC has condensed our key takeaways that we believe will have the biggest impact on our customers.

8.3 is Here

8.3 made a big splash on the first day of the conference with the official release. And it was everything that we had been waiting for. Earlier this year, we did a deep dive in this Ignition 8.3 – What’s New and Reasons to Upgrade Your Project blog on what we were most excited about in Ignition 8.3, and the initial release did not disappoint. DMC is excited to continue working with our clients on their upgrade strategy, enabling them to maximize the benefits of these new features and get the most out of it.

Modern Deployment Methods

One of the most anticipated aspects of 8.3 is its support for modern deployment workflows. From the new Gateway setting for deployment modes, to text-based project files – 8.3 is made for a DevOps workflow. DMC is eager to take advantage of this to make deploying changes to production more reliable.

MES is on the Rise

More and more Discovery Gallery projects and technical sessions were focused on core Manufacturing Execution System (MES) functions such as Overall Equipment Effectiveness (OEE), product traceability, batch control, inventory management, ERP system integration, and production scheduling. Ignition is clearly evolving beyond traditional HMI and SCADA into complex, plant-wide operational systems. Since many Ignition installations already collect valuable production data, DMC is excited to continue helping customers harness that data for greater visibility, optimization, and continuous improvement through MES functionality.

Inductive is Revolutionizing SCADA Licensing Models Again

Inductive Automation is once again transforming how SCADA systems are licensed. The new Ignition Solution Suites simplify the buying process by grouping modules around specific functionality goals. Even more impactful, these suites are future-proof—if new modules are added to a suite, existing Solution Suite license purchasers automatically gain access. This model will make it easier and more cost-effective for customers to adopt new capabilities as they’re released.

AI is Coming

The big buzzword nowadays is, of course, AI. With the steady adoption of AI, the importance of factory floor data is even greater. Inductive introduced an upcoming Model Context Protocol (MCP) module, which is designed to bridge Ignition with AI systems. This integration could unlock powerful new ways to use real-time data for predictive insights and process optimization.

See You at ICC 2026

DMC is continuously exploring new ways to push the boundaries of Ignition, and ICC 2025 gave us a lot of new features and ideas that we are excited to bring back to our clients. Less than a year until the next ICC!

The post Top Takeaways from ICC 2025: What DMC Learned and What It Means for You appeared first on DMC, Inc..