I/O Code

Overview

The I/O Code module generates a Studio 5000 routine from a list of physical devices (digital and analog I/O, motors, valves, VFDs). The output is a single importable L5X containing tags, UDTs, AOIs, and ladder logic.

Use it when starting a greenfield project that needs a consistent code baseline from rung 1, when adding a new line or zone with familiar device types, or any time the I/O list is the input and a structured routine is the desired output.

Not suitable for safety logic, complex sequencing, or anything that needs hand-tuned logic per device. The module covers the templated portion of repetitive I/O work; per-device engineering judgment still belongs in Studio 5000.

Step 1. Add your devices

Open I/O Code from the dashboard. On the empty page you have three ways in:

• File Upload. Drop in a .xlsx, .xls, or .csv. The template (download from the upload panel) is a multi-sheet Excel with one sheet per device type. Single-sheet CSVs with a Type column also work.
• Load Saved. Pick a previously saved session, or select the Default Set under Load Saved on the right side of the shell to load a sample set of devices into the editor. Loaded sessions come back with every row, every UDT pick, and every parameter you set.
• Add Row. Type devices directly into the table. Good for small lists, quick edits, or starting from a blank slate.

A fourth option, Import from DB, appears once any row is on the table. It allows you to pull existing I/O devices from your Tag Database into the current run.

Columns on each row

Column	Required	Notes
Name	Yes	The PLC tag base name
Type	Yes	One of DI, DO, VALVE, AI, AO, MOTOR, VFD_MOTOR
IO Address	Yes	Physical address (e.g.Local:1:I.Data.0)
UDT	No	UDT for this device. Empty falls back to the built-in default. Disabled for DI and DO
Description	No	Used in tag descriptions and generated comments
AOI	No	Override AOI name. Used for analog outputs (AO)
IO Speed Ref	No	Speed reference tag for VFD_MOTOR only

Beyond the columns above, each device type exposes a set of UDT-specific configurable parameters via a per-row Details button (motors, valves, analog devices, and VFDs). The dialog reads the device’s UDT structure and surfaces the configurable members for that type: feedback tags and run-mode flags for motors and valves, raw-to-engineering scaling and per-channel alarm setpoints for analog devices, speed-reference and acceleration parameters for VFDs, and interlock references for every type. These values map directly into the corresponding UDT members on the generated tag and into the AOI call on the generated rung. If you pick a custom UDT in the row, the Details dialog surfaces whatever configurable members your UDT defines instead of the defaults.

Step 2. Pick device types

The type column drives everything else. The seven types and their default library components:

Type	What it is	Default UDT	Default AOI
DI	Digital input (limit switch, push button, prox sensor)	none	none
DO	Digital output (solenoid, indicator)	none	none
VALVE	On/off valve with optional position feedback	UDT_ValveDiscrete	AOI_ValveDiscrete
MOTOR	Fixed-speed motor controlled by a digital output	UDT_MotorSimple	AOI_MotorSimple
VFD_MOTOR	Variable-speed motor controlled via a VFD	UDT_MotorVFD	AOI_MotorVFD
AI	Analog input (pressure, temperature, level, flow)	UDT_SensorAnalog	AOI_SensorAnalog
AO	Analog output (control valve, drive reference)	UDT_ValveAnalog	AOI_ValveAnalog

The UDT and AOI files for each type in use are offered as separate downloads after generation, so you can import them once into your project and reuse them across runs. These are system components, available on every tier.

Bringing your own UDTs

If you already maintain custom UDTs for these device classes, upload them into the UDT Library and they appear in the UDT column dropdown automatically. The generator emits AOI calls and tag members keyed off whichever UDT you pick.

Saving and reloading your configurations

Above the table, Save stores the current rows under a name and version. Load pulls any saved configuration back in. Saved Configs include every row’s parameters from the Details dialog. Use this for projects you come back to, an ever-changing project I/O list, or for sharing a configured run with a teammate by name.

Save to DB is the other side of the import path: it pushes the rows you’ve built up into the Tag Database, so the next module (Alarm Code, Parameter Code) can reference them by name.

Step 3. Generate

Click Generate Code. The output console streams progress, and once the run finishes you get three panels:

File Preview. A two-column pane on the left lists every generated text file; the right side shows its contents with a per-file Copy button. Good for grabbing one routine’s logic without downloading anything.

Generated Files. Card with one row per file. Click any row to download that file. The Download ZIP button bundles everything into one archive.

Required Components. A separate card listing the UDT and AOI L5X files for whichever device types are in your run. These are already bundled inside the routine L5X and resolved on routine import, so you don’t need to import them separately. They’re surfaced here as standalone downloads if you want to import the UDTs or AOIs independently for reuse in other routines, or inspect them in isolation.

What’s in the bundle

File	Purpose
io_routine.L5X	The main deliverable. Self-contained routine: tags, UDT instances, AOI references, and ladder logic in one importable file
device_tag.csv	Tag definitions for every device. Useful for HMI tag imports
device_input.txt	Input logic mapping physical inputs to controller tags
device_output.txt	Output logic mapping controller tags to physical outputs
device_cfg.txt	Device initialization and parameter setup
device_aoi.txt	AOI calls for the analog and motor/valve devices
device_reset.txt	Reset and fault-clearing logic
device_simulation.txt	Simulation logic for bench testing without physical I/O

For most projects the L5X is what you import. The .txt files are there if you want to paste a single section into an existing routine, or read the generated logic in plain text before committing.

Step 4. Import into Studio 5000

In your Studio 5000 project:

1. Right-click the program you want the routine in, then Import then Import Routine.
2. Select io_routine.L5X.
3. Set the routine name in the import dialog. Confirm any tag-collision behavior (usually merge for repeat imports).
4. Click OK.
5. Review the imported routine before deployment. Walk the rungs, confirm tag references, and check that the AOI calls match your equipment’s signal map.

Common pitfalls

FAQ

Does I/O Code support GuardLogix safety I/O?

Not currently. Safety I/O involves SIL-rated logic patterns and hardware that PLCflow is not certified to generate. Standard I/O on a GuardLogix processor works fine; safety-rated I/O does not.

Can I bring my own UDTs and AOIs?

Yes. Upload them into the UDT Library and they appear in the UDT column dropdown automatically. Defaults only fire when nothing matches.

What happens if I re-import the same routine into Studio 5000?

Studio 5000’s import dialog asks how to handle name collisions (merge, rename, or skip per element). PLCflow does not touch your project until you confirm inside Studio 5000.

Does it handle multi-sheet Excel?

Yes. The downloaded template is multi-sheet, one sheet per device type. PLCflow infers the device type from the sheet name and applies the right column schema per sheet. Single-sheet CSVs with a Type column also work.

Can I save my work and come back to it later?

Use Save at the top of the table. Saved sessions appear under Load Saved on the empty page and behind the Load button once you have rows. Saves include every row’s parameter values from the Details dialog.

Related

• Tag Database. Foundation for naming consistency. Set this up first and every I/O Code run can pull devices straight from it.
• Alarm Code. Richer alarm configurations than what the device-level Details dialog produces. Delays, enable conditions, multiple trigger types.
• Code Analyzer. Run the generated routine through this before commissioning. Catches unconditional outputs, naming inconsistencies, and structural issues.