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

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

While the Paintable Canvas’s heavy reliance on scripting might be intimidating for a new Ignition developer, this short tutorial will put you on track to create complex dynamic displays in no time!

Paintable Canvas Overview

The Paintable canvas makes use of the Java2D graphics library, which allows you to create complex shapes, load and edit images, add text, and more.

To add a paintable canvas to your Vision project, simply drag the Paintable Canvas component anywhere on your window. You’ll notice that this component comes with an example script that renders a simple pump graphic. Turn on preview mode to see your paintable canvas area filled with the pump image below. Notice that you can resize the canvas window to any shape or size and the pump will automatically stretch to fill the new area. This is because Java2D is a vector drawing library, allowing components to scale with ease.

Now, let’s take a look into how this graphic is being created. Open up the script editor by right-clicking on your paintable canvas component in the project browser.

Here you will see that the repaint script is prepopulated with the script that creates our static pump icon. You’ll notice that this script is split up into two sections. The first part defines the Java2D shapes that make up our pump, based on a 100×100 pixel area. Then, the second half scales the shapes to the size of the canvas and renders them using Java graphics.

Notice that the order in which the objects are painted is significant. I recommend you take some time to play around with this script, editing some values to see how the pump graphic changes. See if you can change the shape of the pump from a circle to a square or rotate it upside down.

Updating the Canvas from a Dynamic Property

Now, let’s see how we can dynamically update the pump at runtime. First, let’s add a custom property to our Paintable Canvas by right-clicking on the Paintable Canvas component in the Project Browser and selecting “Customizers > Custom Properties.” 

Then, we will add a toggle button to our window and bind its value to this property. Now we can test pressing our toggle button and verify that our new paintable canvas property changes.

Now it’s time to bring this property into our paintable canvas by editing the “repaint” script below, adding a simple if statement to change the color and text of the status icon based on our new dynamic property.

Now you should be able to change your pump mode at runtime by pressing the toggle button. This works because the repaint script for a Paintable Canvas runs any time a property of the canvas changes, including our custom bAuto property.

Updating Dynamic Properties from the Canvas

Now that we know how to update graphics in the paintable canvas from dynamic properties, let’s take a look at writing to properties from within the paintable canvas tool. To do this, we will open back up the component scripting tool and navigate to the mouseClicked event. Let’s say we want to change our mode only when the mode indicator circle is clicked. We can do this very easily by using the x and y properties of our mouseClicked event object.

Here, we create a Point2D object with the coordinates of our mouseClicked point (event.x and event.y) and scale it to match the 0-100 scaling of our initial ellipse definition. We can then use the ‘contains’ method of Ellipse2D to determine whether our point lies within the Ellipse. In this case, if the user clicks within the ellipse, we update our mode property.

Now you can click the status ellipse on the pump icon to update the mode, rather than needing a separate toggle button.

Dynamically Resize and Reorient Objects

Now, let’s return to our original pump display and let’s try updating our canvas to display a dynamic number of pumps. We will again start by adding a custom property to our Paintable Canvas and connect it to a numeric text field on our main window. This will be our user input for number of pumps. Then we will make a few small edits to our repaint script below.

Define a new variable numPumps and link it to your new custom property.

Scale your pump graphic in the X-direction so that each pump takes up 1/numPumps of the screen. The vector-oriented nature of Java2D makes it so easy to resize an entire object all at once, rather than adding a scale factor to each shape within the pump.

Next, add a for loop around the ‘Paint Shapes’ portion of the script to paint each pump one at a time. At the end of the for loop, we will need to ensure any relevant properties (in my case the font size) are reset to the values they are at the start of the loop and then translate our origin to the right by one pump width.

Now try changing your new user input at runtime and see your Paintable Canvas update!

Now you have the tools you need to create simple dynamic objects using the Paintable Canvas tool. With the powerful Java graphics library at your disposal, your creativity is your only limit with what objects you can create!

The post Getting Started with the Paintable Canvas in Ignition Vision appeared first on DMC, Inc..

Ignition offers native support for Mitsubishi devices through its new Mitsubishi TCP Driver, allowing direct communication between the PLC and the SCADA system. Ignition has a published guide for setting up connection from the Ignition side. 

In this blog we will focus on the configuration of a Mitsubishi PLC project in Gx Works3 to connect to an Ignition server as well as some basic troubleshooting tips. Additionally, we will go over the concept of a useful tool DMC developed DMC to quickly convert assigned labels within global label lists to Ignition addresses in a .csv file and that can be directly imported into the Ignition Gateway. 

Configuring a Mitsubishi PLC for Connecting With Ignition:

After you’ve added your PLC to a Gx Works3 project, navigate to the Module Parameter of your PLC. 

In the “Own Node Settings,” first make sure your PLC is on the same network as your Ignition Gateway, and then make the following changes:

1. Enable/Disable Online Change > Enable All (SLMP)
2. Communication Data Code > Binary

Then press “Apply” at the bottom right corner. 

Next, double click on the “<Detailed Settings>.”

A new window will pop-up labeled “Ethernet Configuration.” Navigate to the right of the window and click on “Ethernet Device (General).” Next, click and drag a “SLMP Connection Module” to the table portion of the window. A new SLMP Connection Module will be added. 

Set the Protocol to “TCP” and then set the Port Number to the same port number that was chosen in the Ignition Mitsubishi Driver. 

Press “Close with Reflecting the Setting” at tool bar located at the top of the window. Finally, write the new configuration changes to the PLC and do a power cycle.

Troubleshooting Connection Issues: 

In the tool bar at the top, navigate to “Diagnostics” > “Ethernet Diagnostics” to troubleshoot any connection issues. Here you can see any error codes or statuses. You need to be connected to the PLC to use this. 

Converting Gx Works3 Global Label Lists to Ignition Addresses: 

Quick reminder that, for your tags to be seen by your Ignition project, they need to have device assignments. Here is an example where the labels are assigned to D devices: 

For the Ignition side, you can find the formatting for these addresses in the “Determining Addresses” section in the Ignition document linked at the top of this blog.

If your project has a lot of tags, it can be worthwhile to create an automated script/program to convert the label list exports from Gx Works3 to Ignition addresses and compile them into one .csv file to import into the Mitsubishi driver on the Ignition gateway. This will be much faster than manually adding in one tag at a time. 

You can choose to use one .csv file to keep track of all your PLC tags or append new .csv files each time you add new tags. 

On a recent DMC project, we designed a Python tool to help us automate this task. Our Python tool would read the exported .xml files from Gx Works3, pull out the tag names, data types, and assigned device numbers, and then use that information to construct the Ignition addresses. 

Our tool was custom made for a particular project, but here is the overall workflow for our tool for guidance if you are looking to create your own:

1. Right click on HMI tag lists from Gx Works3 project and export as XML.

2 . Move them into the designated folder where our Python script is accessing unprocessed tag lists.

3. Run Python script.

4. Grab converted .csv file and import (without appending) into Mitsubishi Driver in Ignition gateway.

5. Repeat process if new tags/lists were added to the unprocessed tag folder.

In this project, we changed the mapping for our tags often during development due to changing scope/issues we were encountering. It was beneficial for us to re-run our Python conversion script on all the .xml HMI tag list files and import a new converted .csv file each time instead of appending an additional file. It was easier to keep track of changes and to update any tag mappings that might have changed as we just needed to export and overwrite the same tag list in the unprocessed tag list folder. 

The post Integrating Mitsubishi GX Works3 with Ignition Using the Ignition Mitsubishi TCP Driver appeared first on DMC, Inc..

This past week, I took on the challenge of turning one of our IO demo kits connected to a Siemens PLC into a working game system. I chose to program the classic games Bop It and Simon Says as they would be easy to understand while still presenting their own challenges in both programming and playing.

I first created a simple infrastructure that would allow users to select which game they would like to play using one of the two colored push buttons on the IO kit. I associated each game with a different LED flash sequence to indicate which game had been selected.

The first game I decided to tackle was Bop It. In place of the original game’s “Twist it,” “Pull it,” etc., I used the IO kit’s toggle switches and push buttons.  I wrote a simple logic sequence that would randomly illuminate one of the four colored LEDs and wait for the user to press/toggle the corresponding button/switch. Like the original game, if the user waited too long or selected the wrong button or switch, they would lose the game and the program would play a failure LED sequence and return to the game selection sequence. After enough correct button pushing and switch flipping, the program would display a winning LED sequence and return to game selection.

Simon Says used similar code but with a few differences. These changes were needed due to the game’s sequence, stored using an array, which would be flashed by the LEDs then input by the user. The LED flash was accomplished using a counter up to the current length of the sequence, reading the index of the array at the current count and flashing the corresponding LED. The user input used similar logic, comparing the user’s selection to the array after each button push or switch flip. After successfully repeating a sequence of 10 LED flashes the program displays the winning sequence and returns to the game selection.

User Interface

I created a project in Ignition to graphically display the state of the game and monitor some key statistics. This endeavor added some useful functionality to the PLC code through the powerful tools provided by Ignition Perspective.

The perspective session has three main views: an overview screen and two screens for the games. It is set up so that additional games can be added easily. The overview screen offers navigation to both games, as well as a leaderboard and a popup that explains the games. Each game screen displays a brief description of the game, the status of each digital output, and the player’s current progress. Additionally, a timer shows the player how much time is remaining to make a move, a feature that is not available on the physical kit. Each game screen displays the current high score for that game. This data is pulled from a PostgreSQL database of player initials, scores, and dates. This database is also used to populate the leaderboard.

This project utilizes several of Ignition’s powerful features. Perspective can pull data from the PLC with OPC tags. These tags are then used with both built-in and custom graphics, in combination with Ignition scripting to display the status of the game. Ignition also connects to the database to create the leaderboard and high score features, through additional scripting and SQL queries. Additionally, popups are used in combination with scripts and event handlers to provide a seamless navigation experience for the user. This project uses one PLC, one database, and six windows, but these features can easily be applied to much larger automation applications.

Currently, the Perspective session only reads data from the PLC. An interesting next step could be to use Ignition to write to the plc, maybe with inputs more realistic to Bop It (i.e. twisting and pulling). This project takes advantage of some of the functionality of Ignition, but there are numerous other features that could be utilized for additional functionality.

The post Programming a PLC to be a Game Console appeared first on DMC, Inc..

Despite the great capabilities of the Tag Historian, the format in which data is stored can complicate the process of directly querying these tables. As a result, migrating tag history from one tag to another after say, renaming or moving a tag, may prove challenging. These types of migrations may need to be performed after reorganizing the tag structure of a project or replacing a sensor while maintaining continuous tag history data.

The Example

For simplicity's sake, we will go over an example in which a new tag is added to a project under these conditions:

1. The old and new tags are standalone tags not found in any UDTs.
2. The tag group of the tags did not change.
3. Neither the gateway nor the gateway name changed.
4. Only one gateway is used.

It's worth noting that tag history can still be migrated when some or none of the above conditions apply! There are several nuances each of the conditions requires that one must consider when performing migration. Knowledge of all Ignition built-in historian tables is key to ensuring a successful migration for more complex conditions. Due to the simplicity of the example used, we will only focus on two tables.

Let's start off with a single tag called "TagX". We want to transfer the history of this tag to a new tag, "TagY", that we'll introduce later. According to this Power Chart image, TagX has been active since at least 12:40PM and has been holding at a steady value of 2.

Tag Historian Tables

We can find this tag in one of Ignition's historian tables, sqlth_te. This contains all of the non-data information about a tag. The information in this table is a great starting point to understanding the other tables created by the historian. The most important columns are:

• id: A unique identifier for a tag
• tagpath: The tag path (without the provider), all lowercase
• scid: id of the tag group that tag is in
• created: An epoch timestamp of when the tag began storing tag history
• retired: An epoch timestamp of when the tag stopped storing tag history or was deleted

We also have the tables in which the history is actually stored. If monthly partitioning is set up, the name of the table will look something like sqlt_data_A_B_C where A is the driver id or gateway identifier, B is the year, and C is the month. In this example, our data table is sqlt_data_1_2022_11, so we know that this data was taken in November of 2022. The columns here log the actual values of the tags storing history. The columns in this table are:

• tagid: The id from the sqlth_te table
• ___value: The value recorded for the tag
• dataintegrity: The quality code of the value recorded
• t_stamp: The epoch timestamp at which the value was recorded

We can also see TagX, which has a tagid of 5, started at a value of 0, and then transitioned to a value of 2 at 12:40PM.

Adding TagY

Next, we introduce a new tag called "TagY", assigned a tagid of 6 by Ignition, that begins collecting information at 12:52.

From 12:52 to about 12:53, both tags are reading a value of 2. The sensor for TagX goes offline just before 12:53, leaving only TagY online. At about 12:58, TagY then drops down to 1.

Performing the History Migration

To transfer the history of TagX to TagY, all we have to do is run a simple update query to replace the tagpath of TagX with the tagpath of TagY. The following script examples use Ignition's script console to query the database. Because these scripts are only querying the database, one may use whatever query tool they prefer.

The sqlth_te table now looks like this.

While sql_data_1_2022_11 will still look the same, the tag history of TagX has transferred over to TagY. The history for TagY now goes beyond 12:52PM, its start time and TagX is no longer in the tag browser for the Power Chart component. We can also see that Ignition continues to collect and store history for TagY when the value rises to 3 at 1:11PM.

Learn more about DMC's Ignition expertise, and contact us to get started on your next HMI, SCADA, or MES project!

The post Migrating Tag History in Ignition’s Tag Historian appeared first on DMC, Inc..

In the following example, we will create a window in Ignition that can dynamically create station groups as well as set up device UDT tag instances for those stations. It is important to note that, to effectively streamline the tag instantiation process, you must create all device UDTs with that goal in mind.

One way of doing this is by creating your UDTs to utilize the same parameters. As an example, I’ve created some simple example device UDTs that all have the string parameters: PLC, PLCTagPath, and Path. All the device tags have the same structure in this example, but, in real use cases, they can be different as long as they all have the same parameters.

We will be using several datasets to hold information about the other tags we want to create. The first dataset tag we must create is for storing our station information. Set up dsAvailableStations as a Memory tag and Dataset data type and add two columns: Value and Label. Value will be the index of the station, and Label will be the station folder’s name.

With this done, we can begin setting up a window that the user can interact with to create stations and add device tags. Start by creating a new window and adding a power table at the top, along with two buttons that will be used to add and delete rows from the table.

Link the Data property of the power table to the dsAvailableStations dataset tag. In this example, this tag has been placed in a configuration folder, which has been put in a system folder for organizational purposes. Next, add a script to the Add Row button’s actionPerformed event handler that will add a row to the dsAvailableStations tag.

We can use Ignition’s built-in system.dataset.addRow function for the Add Row button. In the example code below, the path to our dsAvailableStations is input at the top. A try/except block is used to first make sure that a dataset tag exists that we can add to.

Add a script to the delete row button that can delete the currently selected row from the power table. The example script for this step will be slightly more complicated because we will also set up this button to delete the station folder tags that were created from the data contained in the row that is being deleted. We can use Ignition’s system.dataset.deleteRow() and system.tag.deleteTags() functions to do this.

Before we set up scripting on the power table itself, we will need to write scripts to create the station folders and the tags contained within. The example script for this purpose is shown below.

The section outlined in green uses system.dataset.toPyDataSet() to change the Ignition dataset (which is not easily able to be iterated through) into a Python dataset. We can iterate through the dataset and create a list of the stations listed in the table.

The blue section goes through the tags in the default browser and checks if the stations in the station list have already had tags created for them. If they have, they are removed from the list. Finally, the red section moves through the station list and sets up the configurations for the tags you would like to create for each station.

The configurations in this section can be changed to fit the tags you will need in your specific project. For the purposes of this example, we will create a folder for the station itself and add an IO and a Devices folder to go inside. To the IO folder, we will add a DigitalInputs and DigitalOutputs folder.

Finally, we will configure a dataset tag that will have a column for DeviceID and the UDT of each device. We will add to this dataset later. This will be critical to actually instantiating our device tags.

Next, we simply need to add a call to the createStations() script we just created whenever a cell of the power table is edited. This will create new station folders with all appropriate tags when they are added to the table. With that, the portion of our window that deals with creating our stations is complete.

We then move on to setting up device UDT instantiation on the window. We will add a dropdown component to select which station we want to add device tags to.

Add an Indirect Tag property binding to the data property of the dropdown and link it to the dsAvailableStations tag. This will list the stations that were created with the station table.

Next, add another power table and a copy of the Add Row and Delete Row buttons.

Modify the Add Row button script to use the station dropdown to modify the dsDevices dataset at the selected station.

Modify the Delete Row button script to use the selected station to delete the selected row/device tag from the dsDevices dataset. Also, use system.tag.browse() to search through the tags and delete the device instance.

We now move on to adding the table that will instantiate device tags in the station folders by adding a dropdown component to select which station we want to add device tags to. Add an Indirect Tag property binding to the data property of the dropdown and link it to the dsAvailableStations tag. This will list the stations that were created with the station table.

Before we work on the power table, we need to set up a script to create a list of all of the devices UDTs to select from in the power table. This will make setting up the device tags faster because each UDT will not need to be typed in; they can simply be selected from a dropdown in the table.

This script will once again use system.tag.browse() to search through the tags (specifically for this example, the UDTs within the _types_/devices folder). It then takes the names of those UDTs and adds them to a list that we can connect to a cell in the device power table.

Next, we will make the script that instantiates the device tags. This script goes through the dsDevices dataset for the selected station and uses the deviceID and UDT columns to set up the device tag configuration. System.tag.configure() is then used to create the tag at the station input into the function.

To make sure that the device tag configuration is updated if a tag of the same deviceID has already been made, we need to delete the old version of the tag before recreating it.

Back on the device creation window, use an indirect tag binding on the device power table’s Data property to connect it the dsDevices tag for the station selected from the dropdown.

Add a configureEditor script on to the device creation power table and use the deviceUDTlookup() script to setup the UDT column of our power table to use a dropdown list of the device UDTs.

Finally, add an onCellEdited script that calls the createDevices() script to instantiate our device UDTs whenever the power table is changed.

Now our window is completely set up to quickly add station folders and instantiate device UDT tags. This window makes tag creation in Ignition much simpler and faster. In this screenshot, we can see Station1 was created and a few devices with the correct parameter configuration were added.

If this project were connected to a matching tag source, we would expect these tags to show good quality and be working as intended. This window and all associated scripts can be copied between multiple projects and, as long as the UDTs were set up in a similar fashion to each other, allow you to begin dynamically creating tags in a snap.

Learn more about DMC’s Ignition expertise and contact us for your next HMI or SCADA project.

The post Dynamically Creating Stations and Tags in Ignition appeared first on DMC, Inc..

No matter what I tried, I could not get the Vision Designer or the Client to connect to the gateway, even though the gateway showed up when adding through the ‘Add Designer’ button and displayed as a valid connection. 

After a considerable amount of time, I resolved this issue. In this article, my goal is to help others avoid my frustrations by walking through my solution.

The Problem

The error that came up was “Error launching application: ConnectException: Connection refused: connect.”

I noticed a setting called “Force Secure Redirect” was automatically commanding the designer to use SSL. This setting is located in Config>Networking>Web Server>HTTPS Settings (see image below). In this instance, SSL was set up on the client environment, but it not my local one. 

The HTTPS settings are not accessible if SSL is not set up, so there was no way for me to uncheck the Force Secure Redirect from within the gateway UI.

The Solution

To get this box unchecked, I went into the ‘gateway.xml’ file (located at C:\Program Files\Inductive Automation\Ignition\data on my computer) and manually changed the value (see image below). I also deleted the backup file titled ‘gateway.xml.bak,’ which was automatically created. 

Once this was complete, I restarted the gateway by navigating to the ‘gwcmd.bat’ file location within a command window (located at C:\Program Files\Inductive Automation\Ignition on my computer) and used command: gwcmd -r to restart the gateway. 

After these steps were completed, I was able to access the gateway and open the project within the Ignition Designer.  

Helpful Tips

Here are some helpful clues and additional steps that helped me resolve this issue:

• I verified firewall permissions.
• I verified that my current version of Java was up to date.
• I verified that the project version matched the version I had installed on my computer.
• I increased the logging from INFO to DEBUG.
• I found the launch error logs on my computer at C:\Users\oliverr\.ignition
  • This was the biggest help.
  • I saw the following lines in the log and understood that the system was trying to connect to the https address instead of the http address:  

Downloading "https://static.dmcinfo.com/system/jar/m/active-query-builder-8.1.15.jar" (timeout=60000)…
Download attempt #0 for file active-query-builder-8.1.15.jar failed.
java.net.ConnectException: Connection refused: connect

DMC is an Ignition Premier Integrator. Learn more about our Ignition programming expertise and contact us for your next project. 

The post Resolving “Connection Refused SSL” Error in Ignition appeared first on DMC, Inc..

Although most Ignition functions work the same across Perspective or Vision, there are some necessary adjustments to work better in a web-friendly environment. This multi-part blog will serve as a guide to setting up dynamic Perspective screens that take full advantage of the powerful new features.

In part 3, we created a template view that controls an enable property and shows a numeric tag. In this part, we will go over how to add parameters to your embedded view, then use those parameters to drive indirect tag bindings. We can then use our parametrized template in a flex repeater to maximize our layout efficiency.

Adding View Parameters

First, we will cover how to add a parameter to a view and change the tag binding based on that parameter. My example project has the following tag structure, where each TemperatureZone folder has an Enable tag and OutputTemp tag. We want the parameter to change which temperature zone the view displays.

First, open the flex container template view we created in part 3. Select the view in the project browser, which will open the view properties in the property editor. Press the blue "Add View Parameter" button to create a new param. Change the param name to "TempZone" and set the value to 1.

Next, we are going to adjust the button text to display the name of the current zone. Select the button and add an expression binding to the "text" property. Add the following expression, which will display the parameter value with the Zone prefix:

Indirect Tag Bindings

Next, we will change our temperature tag binding to an indirect tag binding. If you are creating an indirect binding from scratch the method is the same. Select the temperature label and change the tag binding type from Direct to Indirect. Next, delete the "1" index from the tag path (or whatever index distinguishes your tag folders or UDTs).

Place your cursor where you wish to add the indirect reference (where the 1 used to be), then press the property reference button to the right of the tag path entry box. Find the TempZone parameter in the tree and press Ok to insert the TempZone param. The reference is now shown in both the tag path and the reference list. You will know that you've configured the binding correctly when the Binding Preview shows the tag value, not an error.

(Note: Previous guides did not explicitly cover binding the "enable" custom property to the enable tag. This can be accomplished with an indirect tag binding on the custom property. Don't forget to set the bidirectional checkbox so the property can write back to the tag!)

Configuring Embedded View Parameters and Flex Repeaters

Once you have added a parameter to a view, you can add a value to that parameter on any embedded view instances. Select the embedded view, then find "params" in the property editor. Click "Add Object Member", then find TempZone (input) in the parameters list. Once you add that parameter, it will appear in the parameters list and you can edit the value. Try changing the TempZone param to different values to see how the template reacts.

One of the most common ways to embed templates is the flex repeater. This object works like a flex container, but it creates multiple instances of a single specified view. Drag a flex repeater from the toolbox to the main view.

Next, select the flex repeater and change its path property to the path of the template view. Under instances, click "Add Array Element" and add three instances of the template.

The three instances will appear as array objects under the instances property. Each instance has an instanceStyle and instancePosition, but you will need to add the TempZone parameter. Click the grey plus button by the instance number and add TempZone (input) as a parameter.

Change each TempZone parameter to a different index. The objects inside the template will use that parameter value for display (Zone 1, Zone 2, Zone 3) and for their indirect tag bindings (note the different temperature values).

In this guide, we've learned how to create view parameters, use them to drive indirect bindings, and how to use flex repeaters to efficiently copy embedded views. In the next guide, we'll cover a more advanced flex repeater technique to allow for a variable number of instances.

Learn more about DMC's Ignition expertise.  Contact us to get started on your next HMI, SCADA, or MES project.

See other blogs in this series: Creating Dynamic Ignition Perspective Projects
Part 1: Bindings and Transforms
Part 2: Button Event Actions
Part 3: Embedded Views and Flex Containers
Part 4: View Parameters, Indirect Bindings, and Flex Repeaters
Part 5: Flex Repeaters with Variable Number of Instances (coming soon)
Part 6: Changing Colors and Other Properties (coming soon)

The post Creating Dynamic Ignition Perspective Projects, Part 4: Parameters, Indirect Bindings, and Flex Repeaters appeared first on DMC, Inc..

Although most Ignition functions work the same across Perspective or Vision, there are some adjustments to work better in a web-friendly environment. This multi-part blog will serve as a guide to setting up dynamic Perspective screens that take full advantage of the powerful new features.

In the last two blogs, we created a status display to toggle an enable bit and display a numeric value. In this blog, we will combine those objects into an embedded view and use a flex repeater to create a dynamic layout.

Creating a New Flex View

To create a new view, right click "Views" in the Project Browser then click "New View" In the popup. Be sure to change the root container type to "Flex Container". The root container type cannot be changed once the view is created.

Next, select the view in the project browser and resize it using the width and height properties in the property editor. Change the dimensions to 400x100px.

Next, return to the main view and copy the toggle button, enable display, and numeric value display. Paste these three components into the new view's root container.

The three views line up on top of each other in the flex container, which is not what we want. We need to configure the flex container and object position properties to best display our data.

Configuring the Flex Container

The flex container has many different properties that determine how objects are displayed, the first is the direction. Switch this to "row" to change the orientation of the three objects.

Now our objects are in a row, but they are not the correct size. We want the button, enable, and numeric display to take up different amounts of space. Luckily, there are position properties on each object that can achieve this exact behavior.

Select the button object and find the position properties in the property editor. The basis determines how much space the object "wants" to take up. It can be in percent (%) or pixels (px). Set the button basis to 20%, the enable label basis to 30%, and the numeric label to 50%.

The other parameters are shrink, which decides if the object should shrink if there isn't enough space, and grow, which decides if the object should grow to take up unallocated space. We do not need to adjust these.

After adjusting the basis, each object takes up the allotted percentage of space. There is one final tweak: adding a margin to the button so it is spaced away from the edges and other components. 

Select the button and find the "style" property in the property editor. Press the plus button to add a new style entry. Name it "margin" and set the value to 5px. Alternatively, you can click the style card icon button to graphically view and edit style definitions. 

With a margin on the button, our flex container view looks ready to go! All that's left to do is to add it to our main view.

Embedding in Another View

Embedding views within other views is easy. Just find your desired view in the project browser, then drag it into your current view. Alternatively, you can grab an "Embedded View" object from the toolbox, then set the path parameter to your view's path. The embedded view now acts as a singular object.

In this blog, we learned how to create an embedded view template and add it to another view. In the next blog, we will add parameters to this template so we can create multiple instances to get data from different sources!

Learn more about DMC's Ignition expertise.  Contact us to get started on your next HMI, SCADA, or MES project.

See other blogs in this series: Creating Dynamic Ignition Perspective Projects
Part 1: Bindings and Transforms
Part 2: Button Event Actions
Part 3: Embedded Views and Flex Containers
Part 4: View Parameters, Indirect Bindings, and Flex Repeaters
Part 5: Flex Repeaters with Variable Number of Instances (coming soon)
Part 6: Changing Colors and Other Properties (coming soon)

The post Creating Dynamic Ignition Perspective Projects, Part 3: Embedded Views and Flex Containers appeared first on DMC, Inc..