Build once. Reuse often. Simplify repeated ladder logic with custom instructions.

As projects grow, repeated ladder logic can make programs harder to read, troubleshoot, and maintain. User Defined Instructions, or UDIs, help solve that problem by letting you create a reusable custom instruction for logic that appears repeatedly in a project. In Productivity Suite, a UDI works much like a function block: you define the logic once, expose the parameters you want to use, and then instantiate that instruction wherever it is needed.

UDI’s are a good fit for repeated machine functions, device control, common calculations, or any logic block that you do not want to copy and maintain in multiple places. The main benefit is consistency. Instead of rebuilding the same sequence each time, you can standardize the logic, document it, and reuse it throughout the project or in future projects by exporting and importing the UDI definition.

Creating a UDI Definition

Before placing a UDI in ladder, you need to create a definition. Access the UDI Management Panel via Tools → UDI Management Panel (shortcut: Alt+T, then U), then click Create New UDI.

Fill in the Name (max 32 characters — letters, numbers, hyphens, underscores, and spaces only), an optional Comment describing its purpose, and Author initials. The Revision field is manually tracked — entering 1 in Major and revA in Suffix displays as 1.0revA.

Building the Ladder Logic

The Program tab is where you write the UDI's internal logic. Over 80 Boolean and Function Block style instructions are available — the same ones used in a main project Task.

A few important limits to know:

• Nesting of up to 4 UDI definitions is supported.
• Unsupported instructions include: communication instructions (AIN, AOUT, MRX, MWX, NETW, and others), PID, all High-Speed I/O functions, and program control instructions CALL, ACLR, and RFCT.
• Rungs can be copied and pasted from other tasks into the UDI editor. If a parameter name conflict exists, the pasted instruction is automatically appended with _1.

Use the Monitor dropdown in the Ladder tab toolbar to select a specific UDI instance to observe while running — contacts and coils highlight red or green, with a 1 or 0 displayed above each.

Configuring Parameters

The Parameters tab defines the data interface for the UDI. Click Add Parameters to define each one. The most important setting is Scope:

• Local — Internal to the UDI only. Used for temporary calculations. Local Parameter values persist between multiple executions of the UDI.
• In — Passed by value into the UDI. The source tag is not modified during execution.
• Out — Result data passed by value out of the UDI after execution.
• In/Out — Passed by reference. Changes inside the UDI directly affect the original tag. Best for bidirectional data exchange or modifying large arrays without duplicating memory.

Check Assignment Required on parameters where a tag or constant must be connected at instantiation — this prevents the UDI from compiling with uninitialized data. Check Visible to display a parameter on the UDI instruction block in ladder, which is useful for monitoring values during troubleshooting without requiring assignment.

Adding a Device to a UDI

Some instructions — such as MBUS (Modbus) or EMSG — require a hardware device reference. The Devices tab in the UDI Definition Editor lets you define a virtual hardware device the ladder logic can reference. Here's the setup using Modbus as an example:

1. In Hardware Configuration, create a Modbus Device in the project.
2. In the UDI Definition Editor, go to the Devices tab and click Add a Device. Assign a name and select Modbus Device from the dropdown.
3. In the Ladder tab, add the MBUS instruction and select the device just added.
4. In the Parameters tab, configure data types and scope for each parameter.

When the UDI is instantiated in ladder, the user selects which configured device from Hardware Configuration to associate — keeping the UDI portable across different hardware setups.

Note: A configured device must already exist in Hardware Configuration before it can be linked to a UDI Device.

Instantiating a UDI in Ladder

In the Task Management panel, navigate to the target task and either drag-and-drop the UDI instruction from Instruction Panel → Program Control → UDI, or type UDI directly on a rung.

From the UDI instruction window: select the UDI Definition, assign a unique Name (max 32 characters) to this instance, then assign tags or constant values to each parameter — or check Use Structure to map parameters to a named structure. If the UDI uses a device, select it under the Devices tab.

Reusing and Protecting UDIs

UDIs are built to travel. From the UDI Management Panel you can Export definitions as .udi files to share with other engineers or import into future projects, and Import definitions from other projects. Use Copy UDI to duplicate a definition within the same project.

Note: When exporting a UDI that contains nested definitions, all nested definitions must be selected together — otherwise an export error will occur.

To protect underlying logic, use Manage UDI Security to create a password-protected Security Key and assign it to one or more definitions. A secured UDI can still be instantiated and have parameters assigned, but the ladder logic cannot be viewed or edited without the correct password — ideal for distributing validated, proprietary modules to end users or integrators.

Example: Motor Start/Stop UDI

Here's a complete example — a standard 3-wire motor start/stop circuit with overload protection, built as a UDI named Motor_Control.

Parameter Table

Why Motor_Run is In/Out: The same tag serves as both the seal-in contact and the output coil on the same rung. In/Out passes it by reference so the seal-in reads the live coil state — a separate In and Out would break the latch.

Why Stop_PB , Start PB and Overload are In: These are read-only inputs from the main project. Passing by value is correct — the UDI has no reason to write back to either tag.

Program Logic

One rung: Start_PB (N.O.) in parallel with Motor_Run (seal-in, N.O.), feeding into Stop_PB (N.C.) and Overload (N.C.) in series, driving the Motor_Run output coil.

Once started, the seal-in latches the rung energized. Opening either Stop_PB or Overload breaks the path and stops the motor.

Instantiating

Assign project tags using the Use Structure check box then enter Pump 1 repeat for Pump 2:

Each additional motor is a new instance with new tags — the logic is already written and validated. Export as Motor_Control.udi to carry it into future projects without rewriting a single rung.

NOTE: Scan time increases associated with UDI usage are influenced by several factors, including the number of UDI instances, the depth of nested calls, and the number of parameters being assigned. The use of indirect addressing for communication instructions within UDIs may contribute to further scan time increases.