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

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

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