Parameter Code

The 2-minute path

These four steps produce an L5X ready for Studio 5000 import. The full guide below covers every option in detail.

1 Input · Upload, load a saved configuration, or add rows manually.
2 Define · Parameter name, value, min, max, optional UDT and units.
3 Generate · Routine L5X, tag CSV, plus UDT_Setpoint and AOI_Setpoint.
4 Import · Into Studio 5000 and verify your new logic.

Overview

Parameter Code generates the structures and logic for runtime-tunable setpoints. Each parameter ends up as a UDT instance with three core members (the current value, a minimum bound, and a maximum bound) plus an AOI call that writes the current value and enforces the bounds on every write. The output is a single self-contained Studio 5000 routine plus the supplementary UDT and AOI definitions.

Common uses: generating 20+ tunable setpoints with consistent bounds-checking, protecting an operator HMI’s setpoint writes from out-of-range entries, or producing PID tuning constants, recipe values, or threshold parameters from a spreadsheet instead of typing them rung-by-rung.

Before you start. You need a list of parameters with their initial value and min/max bounds. Either as a spreadsheet (.xlsx, .xls, or .csv), in your Tag Database under the PARAMETER category, or you can type them directly into the editor. Parameter Code uses UDT_Setpoint by default; if your company or project has a custom parameter UDT it must exist in the UDT Library under the PARAMETER category before you reference it.

Step 1. Get parameters into the editor

Open Parameter Code from the dashboard. The empty page offers three ways in.

File Upload. Drop a .xlsx, .xls, or .csv into the dropzone. The Download Template link below the dropzone produces a canonical workbook with the right columns and a few example rows.
Load Saved. Pick a previously saved configuration from the picker, or select the Default Set under Load Saved on the right side of the shell to load a sample set of parameters into the editor.
Add Row. Type parameters directly into the table. Each click adds one row with defaults (UDT_Setpoint, value=0, min_value=0, max_value=1).

Once at least one row exists, Import from DB appears in the toolbar. It pulls existing PARAMETER-category tags from your Tag Database into the editor; the mapper reads each tag’s SP, Min, and Max attributes and fills the parameter, value, min, max columns automatically.

Input columns

Column	Required	Notes
`parameter`	yes	Parameter name. Becomes the tag name
`value`	yes	Initial setpoint value. Written to the `.SP` member at startup
`min_value`	yes	Minimum allowed value. Bounds-check enforced on every write
`max_value`	yes	Maximum allowed value
`udt`	optional	UDT name. Defaults to `UDT_Setpoint`. Only PARAMETER-category UDTs from your library are valid
`description`	optional	Description text. Surfaces in tag browsers and generated comments
`unit`	optional	Engineering unit (`degC`, `PSI`, `GPM`, etc.)

Save your configuration as you go. Once you have entries in the editor, the Save button on the table toolbar stores the current state as a named saved configuration. The configuration shows up in the Load Saved panel next time you visit. Useful for projects you come back to, an ever-changing project parameter list, or for sharing a configured run with a teammate by name.

Step 2. Define the parameters

The entry table shows one row per parameter with the columns from the input file or template. Each cell is editable. Validation runs continuously and flags rows in red if a required field is empty or a value is out of range.

Toolbar actions:

Button	Action
Validate	Re-run validation on every row. Errors surface inline in red
Add Row	Add a blank row
Import from DB	Pull PARAMETER tags from Tag Database
Save to DB	Write the current entries back to Tag Database (as PARAMETER tags)
Save	Save the current configuration under a name
Load	Open the saved-configuration picker
Clear	Drop all entries (with confirmation)

The UDT column is a dropdown showing any PARAMETER-category UDTs in your library, plus the built-in UDT_Setpoint. If your custom UDT has members named differently from the default (sp_value, min_value, max_value), Parameter Code reads the UDT definition to resolve the correct member names at generation time.

Step 3. Generate

Click Generate Code at the bottom of the table. The page disables the button, shows “Generating code…” with a spinner, and streams progress to the console panel below.

The console shows timestamped log entries: parameters processed, tags allocated, MOV instructions emitted for the bounds checks, AOI calls written. Typical generations under 50 parameters complete in a few seconds.

What’s generated

When the run completes, three panels appear:

File Preview opens with a left-list / right-content layout. You can click any file to read its contents inline, and the Copy button in the corner copies the full file text to your clipboard. The L5X file is hidden from this preview (it is XML, not useful to read by eye); the .txt and .csv outputs are visible.

Generated Files lists all four output files as clickable cards. Click any card to download that one file. The Download ZIP button at the top right downloads everything in one archive.

File	What it contains
`parameter_routine.L5X`	Self-contained Studio 5000 routine bundling tags, UDT_Setpoint, AOI_Setpoint, and ladder logic into one importable file
`parameter_tags.csv`	CSV-format tag definitions for direct import or paste into Studio 5000. Includes UDT_Setpoint and AOI_Setpoint instances
`parameter_logic.txt`	MOV instructions writing the initial value to `.SP`, plus min/max bounds enforcement on a `Global_Parameters` array
`parameter_aoi.txt`	One rung per parameter calling the `AOI_Setpoint` Add-On Instruction

Required Components is the third panel. It contains the two supporting L5X files in standalone form:

UDT_Setpoint.L5X is the User-Defined Type definition for setpoint parameters
AOI_Setpoint.L5X is the Add-On Instruction that handles bounds enforcement and operator writes

Both files are already bundled inside the routine L5X, so the routine imports cleanly on its own. The standalone files are here if you want to import the UDT and AOI independently, for example, to reference them from routines you author outside PLCflow.

Step 4. Import into Studio 5000

Import the routine L5X directly. The bundled UDT_Setpoint and AOI_Setpoint definitions resolve automatically. The standalone UDT and AOI files are optional.

Right-click the program you want the routine in, then Import then Import Routine.
Select parameter_routine.L5X.
Set the routine name in the import dialog if Studio 5000 prompts.
Click OK.
Review your code before deployment. Read and review the imported rungs before deployment.

Once the routine is imported, the generated logic compiles and your parameters are tunable from any HMI tag binding that writes to the .SP member.

This is draft control logic. Bounds-checking enforced in PLC logic is operator-error protection, not safety logic. If a parameter controls a safety-critical setpoint (overspeed, overpressure, overtemperature), the safety bound belongs in independently certified safety-rated hardware with SIL/PL verification, not in a generated MOV instruction.

Common pitfalls

Custom UDT with mismatched member names. Parameter Code reads the UDT structure from your library to resolve the right member names for SP, Min, Max. If your UDT calls them something exotic (SetPoint_Curr, Lo_Limit, Hi_Limit), the generation still works, but only if every member is mappable to one of the three roles. If the UDT has missing required members, generation fails with a validation error.
Operator writes from the HMI bypass the bounds check. The AOI_Setpoint enforces bounds when a write goes through the AOI. If the HMI writes directly to the .SP member without going through the AOI’s Write parameter, the bounds are not enforced. Configure the HMI binding to go through AOI_Setpoint_Inst.Write, not .SP directly.
Min value greater than max value. Caught by validation if you click Validate before generating, but if you generate without validating, the L5X is produced with the inverted bounds and the runtime parameter accepts no valid value. Always validate first.
Re-generating overwrites your tuned values. Each generation writes the initial values from your spreadsheet to .SP at startup. If operators have tuned the setpoints since the last download, those tuned values will be overwritten on the next download (because startup runs the MOV). Either capture the tuned values back to your spreadsheet before re-generating, or remove the initial MOV after the first commissioning.

FAQ

How many parameters can one generation handle?

The per-generation entry cap is tier-dependent. The button tooltip names the exact cap for your plan when it greys out. For projects that exceed the cap, split by area or function and generate multiple routines.

Can I round-trip parameters through the Tag Database?

Yes. Import from DB pulls existing PARAMETER tags into the editor. Save to DB writes the current entries back. This is the cleanest way to keep one canonical source of truth for parameter values across multiple generations and projects.

What's the UDT_Setpoint structure?

By default it has three required members: sp_value (the runtime value, REAL), min_value (the bound, REAL), and max_value (the bound, REAL). Your custom UDTs can have any extra members (description, scaling, alarm hooks) as long as the three required ones exist.

Does Parameter Code work with INTEGER setpoints, or only REAL?

Both, as long as your UDT defines sp_value, min_value, and max_value with the same numeric type. Generation reads the UDT’s member types and emits compatible MOV instructions.

Can I set a separate engineering unit per parameter for HMI display?

Yes. The unit column in the input is stored as a tag attribute and surfaces in HMI tag browsers. The generated PLC logic does not consume the unit string; it is metadata for downstream tools.

The Generate button is greyed out. Why?

Usually because the entry count exceeds your tier’s max_entries_per_generation cap, or because no entries are loaded yet, or because a generation is already in progress. The label and tooltip on the button explain the specific reason.

Tag Database. Round-trip parameters via Import from DB / Save to DB. Keeps naming consistent across modules.
UDT Library. Stores custom PARAMETER-category UDTs you can pick from the UDT column.
I/O Code. Generates the I/O wrapper logic that often references parameters as setpoints (e.g. a VFD speed reference parameter).

What's next

Related modules

Was this helpful?

Honest feedback. We read all of it.

Email support Talk to an engineer