PLCCreator Device I/O List Format Explained.

PLCCreator's Device IO List CSV is one of those formats that grew up in industry rather than being designed top-down. It started as a panel-shop convention, became the input format for a code-generation tool, and is now common as an interchange format between controls engineering and PLC programming on small and mid-size projects. The format is precise about columns and values in a way that surprises people coming from looser I/O list traditions.

Why the format is structured the way it is

A code generator needs deterministic input. If the signal class column sometimes says AI and sometimes says Analog Input and sometimes says 4-20mA, the generator has to either guess or fail. The PLCCreator format pins down the vocabulary so the generator does neither.

The cost is that hand-edited spreadsheets sometimes drift from the vocabulary. The benefit is that a clean Device IO List produces working code on first import.

Column overview

The format has roughly twenty columns organized into a few groups.

• Identification. Tag number, description, equipment reference.
• Signal characterization. Signal class, range, units, scale.
• Hardware location. Rack, slot, channel, terminal block.
• Architecture. Vendor, controller family, network.
• Alarm and interlock. Alarm class, setpoints, interlock references.
• HMI metadata. Display group, faceplate, navigation hint.

Different versions of the format have slightly different column counts. The 14-column variant published as a reference template covers the core fields without the hardware-location detail.

Identification columns

Tag. The instrument or device tag number. Has to be unique within the I/O list. Most projects use the ISA 5.1 or NORSOK or KKS identifier from the P&ID directly.

Description. Free-text service description. PLCCreator uses this as the default HMI faceplate label, so terse text is preferred over full sentences.

Equipment. The equipment tag the device is associated with. Used for grouping in the generated HMI and for traceability back to the P&ID.

Signal class column

This is the column that drives the most downstream behavior. Accepted values usually include.

The vocabulary varies a little between PLCCreator releases and between integrators who have customized it. The principle is the same. One column drives the entire I/O card selection, terminal wiring assumption, and HMI faceplate.

Range and units

For analog points, range and units are mandatory.

• Range Low. Engineering units value at 4 mA.
• Range High. Engineering units value at 20 mA.
• Units. Engineering unit string. Must come from the project's unit dictionary so the generator can apply consistent unit conversions.

Discrete points leave these blank. Pulse points use them to encode the count rate at full scale. HART points carry a secondary range pair for the second variable.

Hardware location

For projects where the Device IO List drives the panel layout.

• Rack. Chassis or rack identifier.
• Slot. Module slot within the rack.
• Channel. Channel number within the module.
• Terminal Block. Optional, used when the marshalling cabinet has separate terminal blocks from the I/O modules.

These columns are typically populated late in design. Early-stage I/O lists leave them blank and rely on the architecture column to drive automatic assignment.

Architecture column

The architecture column tells PLCCreator what the target controller is. Accepted values typically include.

• Siemens-S7-1500
• Siemens-S7-1200
• Rockwell-CompactLogix
• Rockwell-ControlLogix
• Generic
• Project-specific extensions for Schneider, Beckhoff, or other targets

The architecture drives.

• The data type, Siemens uses Real and Bool. Rockwell uses REAL and BOOL
• The tag naming convention, Siemens accepts dots and dollar signs. Rockwell does not
• The card type assumption, Siemens HART cards versus Rockwell HART cards
• The output file format, TIA Portal XML versus Studio 5000 L5X versus generic CSV

The same Device IO List can be re-targeted by changing this one column, which is a substantial part of why the format is useful as an interchange.

Alarm columns

For points that participate in the alarm philosophy.

• Alarm Class. Critical, High, Medium, Low, Informational.
• HiHi Setpoint. High-high alarm threshold.
• Hi Setpoint. High alarm threshold.
• Lo Setpoint. Low alarm threshold.
• LoLo Setpoint. Low-low alarm threshold.

Alarm class is the most operationally important. It drives HMI color, audible behavior, and the alarm summary navigation. Projects aligned with ISA 18.2 use the matching priority vocabulary.

Interlock columns

Some Device IO List variants include interlock references.

• Interlock Tag. Tag of the interlock function the device participates in.
• Interlock Direction. Cause or effect.
• Interlock Setpoint. If the interlock triggers on a process condition.

These are simpler than a full cause-and-effect matrix but adequate for projects where the C&E lives elsewhere.

A worked example row

A pressure transmitter on a feed line might appear as.

PT-2105,Feed pressure to V-201,V-201,AI-HART,0,1000,kPa,Siemens-S7-1500,High,950,800,,,...

Reading left to right. Tag PT-2105, description Feed pressure to V-201, equipment V-201, analog HART input, range 0 to 1000 kPa, target Siemens S7-1500, alarm class High, hi-hi setpoint 950, hi setpoint 800, no low setpoints.

PLCCreator turns that into a Siemens TIA Portal tag with the correct data type, a HART-capable AI card assignment, an alarm block with the configured setpoints, and an HMI faceplate at the High priority.

Common errors when authoring the CSV

A few patterns repeat across projects.

• Mixing signal class vocabularies. Half the file says AI, the other half says Analog Input. The generator rejects one form. Standardize on the documented vocabulary in the very first pass.
• Range as a single string. Writing 0-1000 kPa in one column instead of splitting into Range Low, Range High, Units. Splitting at edit time is cheap. Splitting at import time is unreliable.
• Tag duplication. Two rows with the same tag, often because the same physical instrument is wired to two destinations. Fix by adding a destination column or by splitting into clearly named A and B variants.
• Architecture inconsistency. Mixing Siemens and Rockwell rows in the same file. PLCCreator can usually handle this, but the resulting code split is rarely what the engineer intended. Pick one architecture per file or use clearly partitioned sections.
• Missing alarm class on alarmed points. A setpoint without an alarm class generates a tag without an alarm. Always pair them.

Conversion from a P&ID-derived I/O list

A P&ID extraction yields tag, description, signal class, equipment reference, and, when available range. Converting to the PLCCreator format means.

• Mapping signal class to the PLCCreator vocabulary
• Splitting range into Low, High, Units
• Adding architecture, often a project-wide default
• Filling alarm class from the alarm philosophy or project default
• Leaving hardware location blank for late-design completion

The mechanical part of the conversion is straightforward. The judgment part is signal class normalization for points that the P&ID does not unambiguously classify, HART versus plain analog, for example.

Hardware-location auto-assignment

PLCCreator can auto-assign hardware locations given the architecture and the I/O count. The rules vary by target.

• Siemens S7-1500 fills modules in the order encountered, respecting card type
• Rockwell ControlLogix fills slots in the rack with the chosen card mix
• Generic spreads I/O evenly across configured racks

Manual assignment overrides take precedence. Most projects use auto-assignment for the first pass and refine specific points by hand.

How tag-extraction tooling produces the format

A P&ID extraction system that targets PLCCreator output has to.

• Recognize signal class beyond just AI, AO, DI, DO, HART, RTD, TC variants matter
• Capture range and units when shown on the P&ID
• Carry equipment reference for grouping
• Allow project-level architecture override at export time

Tagsight produces PLCCreator CSV as one of its eight export formats. The vocabulary maps to the documented PLCCreator values, and the architecture column accepts the standard Siemens, Rockwell, and Generic targets at export.

The Device IO List is the contract between controls engineering and PLC programming. When the format is clean, the programmer imports it and writes logic. When the format is messy, the programmer spends a week cleaning it before any logic gets written. That week is pure rework. Authoring discipline at the I/O list level pays back tenfold at programming time. The upstream column-building and signal-class conventions that produce a clean Device IO List are covered in the I/O list creation guide.

Further reading

• PLCCreator user documentation
• ISA 18.2 Management of Alarm Systems for the Process Industries
• ISA TR84.00.04 Guidelines for the implementation of safety instrumented systems
• Project-specific I/O list templates and naming conventions