Configuring PAC Control Tag Names: Naming Conventions

Overview

Tag names are the only part of a PAC Control strategy that follows the data everywhere it goes: the strategy tree, OptoScript, the debugger, PAC Display, and mobile clients. Everything else — scaling text entered in the I/O configuration, the type column in the strategy tree, the variable description field — is context-dependent and may not travel with the tag. That asymmetry drives every decision below.

There is exactly one hard rule: variable names are limited to 50 characters. Everything else is convention. The engineering task is picking a convention your team can hold consistently for the life of the strategy, then documenting it so the next person maintaining the code does not invent a second scheme alongside yours.

The Three Competing Schemes

Practitioners split into three camps. None is wrong; mixing them inside one strategy is.

Case for type prefixes

A leading one- or two-letter prefix identifies the type at a glance in OptoScript, where the strategy tree is not on screen:

ntProductTypeTable          // integer table
utElapsedTimeInSeconds      // up timer
aiDuckProductionRate        // analog input point
MAX_TIME_TO_WAIT_IN_SECONDS // all caps = used as a constant

Case against type prefixes

PAC Control already reports the type of every variable in the strategy tree and in the variable-selection dialogs when you write instructions. If the tool tells you the type, the prefix is redundant and it forces alphabetical sorting by type rather than by equipment — which is almost never how a maintenance engineer searches. Scrolling the tree hunting for a lost tag is the cost.

The hybrid

Put the equipment function first, engineering units second (when required), and the type indicator last. You keep type information without letting it dictate sort order:

DRYER02_ExhaustTemp_DegF_f
FILLER01_CycleCount_n
HEATER01_CTL_PV

Encoding Units in the Name

Scaling entered in the I/O unit configuration — the "Scaled" units text — is configuration-only. It is not visible while debugging the strategy, and it is not visible on a mobile client viewing tag values. A unit suffix baked into the tag name is stored in the I/O unit's memory and travels with the value:

aiDuckProductionRate_in_Ducks_per_Second
utElapsedTimeInSeconds
DRYER02_ExhaustTemp_DegF

Weigh this against the 50-character budget. A verbose unit phrase such as _In_Degrees_C consumes 13 characters that could carry equipment identity. Practical compromise: short unit tokens (_DegC, _PSI, _GPM, _Sec) rather than sentences.

The 50-character budget

Compare two treatments of the same point:

Process_Variable_Heater_Controller_01_In_Degrees_C  // 50 chars, at the ceiling
HEATER01_CTL_PV_DegC                                // 20 chars, sorts with the loop

Long descriptive names are self-documenting but consume the entire budget and scatter related tags across the alphabetical list. Short object_parameter names group every tag for HEATER01 together. Push the prose into the variable description field, which has no such constraint and is the correct place for scaling notes, alarm limits, and cross-references.

Grouping Prefixes That Earn Their Characters

Type prefixes are optional; grouping prefixes solve a real navigation problem in a long variable list. Common patterns:

Preventing Cross-Chart Variable Collisions

PAC Control variables are global. Two charts running concurrently that both use a loop counter named iLoop share the same memory. One chart's FOR loop can be corrupted by the other chart's increment, producing intermittent, load-dependent faults that are extremely hard to reproduce.

Assign each concurrently running chart a number and prefix every temporary variable with it:

// Chart 5 temporaries
i5_Loop
i5_Index
n5_Temp

// Chart 2 temporaries
i2_Loop
n2_Temp

1. Enumerate every chart that can run concurrently and assign it a unique integer.
2. Prefix all loop counters, indexes, and scratch variables in that chart with the chart number.
3. Reuse the same numbered temporaries freely within that chart — that is the point.
4. Never let a numbered temporary appear in a chart other than its own.
5. Grep the strategy (or use the OptoScript search) to confirm no unnumbered scratch names remain.

Renaming Safely

Modern PAC Control versions propagate a variable rename into OptoScript automatically — change the name in the strategy tree and the references in your code follow. This is the practical justification for the single tag database: if you change your mind about a convention, the cost of correcting it is low.

Verify this behavior before committing to a mass rename:

1. Create a throwaway variable and reference it in one OptoScript block.
2. Rename the variable in the strategy tree.
3. Reopen the OptoScript block and confirm the reference updated.
4. If the reference did not update, your version does not propagate renames — version 8.2 does not. Upgrade before renaming anything referenced in OptoScript, or plan a manual search-and-replace pass.
5. Compile the strategy and resolve any unresolved-name errors before download.

Renames also break external references. Anything outside the strategy that binds to the tag by name — PAC Display projects, Modbus register maps, OPC clients, mobile app configurations — must be updated separately. This is why the HMI_ prefix is worth its characters: it flags exactly which tags carry an external contract.

Adopting a Convention

1. Pick one scheme (type-prefix, function-first, or object_parameter) and write it into a one-page project standard.
2. Decide the unit policy: unit token in the name, or units in the description field only. Do not do both inconsistently.
3. Reserve grouping prefixes: HMI_, P_, and chart-number prefixes for temporaries.
4. Reserve ALL_CAPS for values used as constants.
5. Budget name length — target well under 50 characters so future qualifiers fit.
6. Use the strategy's Initialization file to establish known startup values for grouped tags, particularly in Modbus projects where register mapping depends on stable ordering.
7. Review the convention at each strategy revision; consistency across the team matters more than which scheme you chose.