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

OOP enables code to be divided into self-contained, reusable objects, resulting in code that is easier to understand, maintain, and update. Throughout this series, the reasons behind this advantage will hopefully become evident and clear.

Beckhoff has a set of examples that will occasionally be referenced throughout this series.

Object oriented programming exists of 4 pillars:

1. Encapsulation: Encapsulation refers to the grouping of data (variables, properties) and functions (methods, function blocks) into a single unit called an object. The single object allows for the internal code to be hidden from the application code.
2. Inheritance: Inheritance allows objects to inherit properties and functions from other objects. This allows for code to be reused even if the logic is not exactly the same.
3. Polymorphism: Polymorphism means the ability of objects to take on different forms or exhibit different behaviors based on the context. This is useful for devices that have very similar functions, but the processes for how they are completed are very different.
4. Abstraction: Abstraction involves simplifying complex systems by breaking them down into more manageable and understandable parts. It focuses on only the essential properties and behaviors of an object while hiding the unnecessary details.

Beckhoff provides several different tools that can be used to achieve these four pillars. Throughout this series, it will be pointed out how each tool correlates to the four pillars.

This first blog will touch on two basic principles of OOP, methods and properties.

Methods

Methods are actions that an object can perform, while encapsulating the details of how an object performs its tasks. Methods specify the behavior or actions that objects can perform, abstracting the implementation details and providing a clean interface for interacting with objects.

Methods can perform operations, manipulate data, and they may or may not return a value depending on their implementation. As for what a method should return, this depends largely on whether the method will be completed in one scan or not. For example, commanding a conveyor to move 10 feet will take more than one scan. However, determining the value of a sensor only takes one scan.

In addition, there are different access modifiers for methods, with the two main ones being PUBLIC and PRIVATE. Public versus private determines whether the method can be called outside of the program or function block. There are two additional modifiers: PROTECTED, which allows any function block that inherits the function block to access the method (more on that in future blogs) and INTERNAL, which restricts access to objects in the library.

In the example of commanding a conveyor to move 10 feet, the method may return a standard response that can be used in an application. This should be public because function blocks outside of the conveyor will need to call this.

TYPE ST_Response 
STRUCT
    bComplete : BOOL;
    bError : BOOL;
END_STRUCT
END_TYPE

TYPE ST_Response 
STRUCT
    bComplete : BOOL;
    bError : BOOL;
END_STRUCT
END_TYPE

METHOD PUBLIC MoveDistance : ST_Response
VAR_INPUT
    Distance : LREAL; // feet 
END_VAR

METHOD PUBLIC MoveDistance : ST_Response
VAR_INPUT
    Distance : LREAL; // feet 
END_VAR

When the method has completed, the state machine can then be moved to the next step. If it encounters an error during the process, the application can enter its error handling sequence.

E_State.MOVE_CONVEYOR:
    respone := fbConveyor.MoveDistance(10); // move 10 feet
    
    IF respone.bComplete THEN
        eState := E_State.RUN_MACHINE;
    ELSIF respone.bError THEN
        eState := E_State.ERROR;
    END_IF

E_State.MOVE_CONVEYOR:
    respone := fbConveyor.MoveDistance(10); // move 10 feet
    
    IF respone.bComplete THEN
        eState := E_State.RUN_MACHINE;
    ELSIF respone.bError THEN
        eState := E_State.ERROR;
    END_IF

An example of a method that takes one scan is calculating the torque of the conveyor. For calculating torque, it is often useful to implement a moving average or filter to smooth out any noise in the data. For example, a method can do all of the math inside and return the value in terms of foot-pounds. This would be an example of a private method because only the conveyor function block should be calling this. The torque could be accessed outside of the function block via a property, for example:

// foot-pounds
METHOD PRIVATE CalculateTorque : REAL
VAR_INPUT
    rActualTorque : REAL; //0.1% of max torque 
END_VAR
VAR_INST
    fbMovingAverage : FB_MovingAverage;
END_VAR

// foot-pounds
METHOD PRIVATE CalculateTorque : REAL
VAR_INPUT
    rActualTorque : REAL; //0.1% of max torque 
END_VAR
VAR_INST
    fbMovingAverage : FB_MovingAverage;
END_VAR

Another very common return type is simply a BOOL. Of course, a BOOL can mean many things (sensor state, method complete successfully, etc.), so be sure to comment on what the return value means if it is not obvious!

// true = enable successful, false = interlocks active 
METHOD PUBLIC Enable : BOOL

// true = enable successful, false = interlocks active 
METHOD PUBLIC Enable : BOOL

Methods can also serve as a way of organizing code and maintaining readability in application code. This is an example of when a return is not needed. The following excerpt is taken from the OOP Extended Sample. 

// Call of actions

    // Init
    General_Init();

    // Mode and state requests
    General_Requests();
    
    // Enable for power supply, compressed air control and buttons
    General_Enable();
    
    // Input variables of separating and sorting modules
    General_ModuleInputs();
    
    // Output variables
    General_SetOutput();
    ...

// Call of actions

    // Init
    General_Init();

    // Mode and state requests
    General_Requests();
    
    // Enable for power supply, compressed air control and buttons
    General_Enable();
    
    // Input variables of separating and sorting modules
    General_ModuleInputs();
    
    // Output variables
    General_SetOutput();
    ...

METHOD PRIVATE General_Init

METHOD PRIVATE General_Init

A really powerful feature of Beckhoff is the ability to call methods via ADS. This, in turn, makes methods able to be called via OPCUA. Head on over to our blog about setting up an OPCUA server if you have not already done so!

{attribute 'TcRpcEnable'}
METHOD PUBLIC MoveDistance : ST_Response

{attribute 'TcRpcEnable'}
METHOD PUBLIC MoveDistance : ST_Response

Here, I am using UaExpert to call the method. 

This can make testing extremely efficient. No need to add debug bits to test your code, just call the method that is being tested!

Another Beckhoff-specific implementation of a method is FB_init. This allows for initialization of the function block before it is called. A simple use case for this is when project variants are used (another plug for one of our blogs!). Different initialized values can be used depending on the variant selected. For example, in the Simulation variant, the default conveyor speed is set to the maximum value to speed up any testing that is needed. Another common use case is initializing pointers and references to be used during runtime.

METHOD FB_init : BOOL
VAR_INPUT
    bInitRetains : BOOL; 
    bInCopyCode : BOOL;  
END_VAR

METHOD FB_init : BOOL
VAR_INPUT
    bInitRetains : BOOL; 
    bInCopyCode : BOOL;  
END_VAR

{IF defined(Simulation)}
    lrSpeedSetpoint := MAX_SPEED;
{ELSE}    
    lrSpeedSetpoint := 100;
{END_IF}

{IF defined(Simulation)}
    lrSpeedSetpoint := MAX_SPEED;
{ELSE}    
    lrSpeedSetpoint := 100;
{END_IF}

Obviously, this is just scratching the surface of what methods can do. There are varying schools of thought on how much logic a method should contain. Some implementations of methods simply move state machines from one state to another; other implementations may contain an entire sequencer inside a state. This depends on the architecture of the project.

DMC is happy to discuss the implementation of your project and help decide which implementation of methods will work best for you! 

Properties

Moving onto properties, a property is an object attribute that encapsulates data and provides a controlled way to access or modify the data associated with it. Properties allow you to expose the internal state of an object while enforcing rules and logic for data access.

Properties are implemented using getter and setter methods. A getter is a method used to retrieve the value of a private attribute of an object. A setter is a method used to modify the value of a private attribute of an object.

Properties have the same access modifiers as the methods described above.

A simple example of this would be the speed setpoint of the previously mentioned conveyor.

// ft/min
PROPERTY PUBLIC lrSpeedSetpoint : LREAL

// ft/min
PROPERTY PUBLIC lrSpeedSetpoint : LREAL

The setter can have conditions to make sure the speed is set within the proper bounds. In this example, a negative number is rejected, and a speed greater than the maximum is set to the maximum speed. The getter simply returns the speed here; however, a getter could convert a raw signal into a useful value, for example:

// "Set"
IF lrSpeedSetpoint >= 0 THEN
    _lrSpeedSetpoint := SEL(lrSpeedSetpoint > MAX_SPEED, lrSpeedSetpoint, MAX_SPEED);
END_IF

// "Set"
IF lrSpeedSetpoint >= 0 THEN
    _lrSpeedSetpoint := SEL(lrSpeedSetpoint > MAX_SPEED, lrSpeedSetpoint, MAX_SPEED);
END_IF

// "Get" 
lrSpeedSetpoint := _lrSpeedSetpoint;

// "Get" 
lrSpeedSetpoint := _lrSpeedSetpoint;

To access properties, the following should be used: 

// Access "Set" 
fbConveyor.lrSpeedSetpoint := 100; // 100 ft/min

// Access "Set" 
fbConveyor.lrSpeedSetpoint := 100; // 100 ft/min

// Access "Get" 
lrConveyorSpeedSetpoint:= fbConveyor.lrSpeedSetpoint;

// Access "Get" 
lrConveyorSpeedSetpoint:= fbConveyor.lrSpeedSetpoint;

If a property does not need either the getter or the setter, it can simply be deleted.

From my personal experience, I have not seen properties used a ton. There are some specific situations where they are useful, but often there are several different ways to achieve the same functionality. Methods, on the other hand, are essential to building an OOP-based project.

Look out for part 2, interfaces, coming soon!

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

The post Beckhoff OOP: Part One – Methods and Properties appeared first on DMC, Inc..

This meeting began with Pizza and networking between DMCers and LabVIEW users from the Chicagoland area.

We kicked off the user group meeting by highlighting some of the most exciting features that were released at NI week this year.

NI Week 2019 Overview

DMC Presentations on LabVIEW Programming

Systems Engineer Ryan Yu presented an overview of NI Package Manager, with content initially developed by National Instruments and presented by Allen Hsu.  Yu showed LabVIEW users the workflow for installing, upgrading, and managing NI software.  He then highlighted the workflow of both NI Package Manager and SystemLink, when used in conjunction with LabVIEW. Users exchanged ideas with Yu and asked questions on use cases, versioning, and SystemLink feeds.

NI Package Manager

Systems Engineer Kyle Mitchell demonstrated JKI’s VI Package Manager, a reasonably popular tool among the user group. Mitchell gave a walkthrough on how to build and deploy packages within LabVIEW, and users shared their experiences and tips about VIPM.

VI package manager

Sharing LabVIEW Stories

This section of the meeting is devoted to short topics (max of 10 minutes) talking about a neat project, cool tool, or challenging problem users need help solving. 

Users shared stories about creating a custom VI to update UI elements through property nodes more effectively, warned about big arrays affecting the search feature, and one user shared a story about how to do LabVIEW translations effectively.

There was also a shoutout to the LabVIEW wiki that the community is currently constructing.

Thanks to our friends in the LabVIEW user group who made it to the event!

Learn more about DMC's partnership with National Instruments.

The post Chicago LabVIEW User Group Meeting at DMC appeared first on DMC, Inc..

Fortunately, the Siemens support website has a great article that explains these different ways to access I/O for Siemens S7-300 and 400 PLCs. Here are some summary thoughts and highlights that I’ve picked out.

Here are the basics:

• Process Image
  • The only way to access I/O bits
  • Values are “buffered” in between scans
  • Limited address space for some CPU models
  • Notation:
    • Bool “I 0.0”, “Q 0.0”
    • Byte “IB 10”, “QB 10”
    • Word “IW 16”, “QW 16”
    • Double Word “ID 24”, “QD 24”
• Peripheral Address
  • All addresses outside of the process image
  • Cannot access I/O bits this way
  • The actual values are immediately read and written to physical I/O from user program
  • Notation:
    • Byte “PIB 10”, “PQB 10”
    • Word “PIW 16”, “PQW 16”
    • Double Word “PID 24”, “PQD 24”

As a general rule, I use the process image for all my bit logic and the peripheral addresses for my analog values.

For more information, check out the article .

Learn more about DMC’s PLC Programming services and contact us to get started on your next PLC Programming project.

The post The Basics of Siemens S7 PLC I/O Addressing appeared first on DMC, Inc..