Guide
What data is in PipeEX PCF Export output?
This guide explains the kinds of line, component, topology, and mapped engineering data that typically appear in a PCF file generated by PipeEX PCF Export.
It also points readers back to validation habits, because exact downstream requirements depend on the target deliverable and template.
Line data
Line data identifies the piping system being handed off. Typical fields include line number, service, system name, nominal size, spec or class, and project-specific identifiers that appear on isometrics or analysis deliverables.
PipeEX PCF Export can only export line data that is present and mapped from the Revit model. Before rollout, decide whether the authoritative value lives on a system, pipe segment, fitting, shared parameter, or project standard table.
Component data
Component data describes the physical items on the route: pipe, elbows, tees, reducers, flanges, valves, instruments, and special items.
Useful PCF output should let the downstream tool distinguish component type, size, orientation where needed, and any required tag or catalog/spec reference. Families with incomplete connector or parameter data are common sources of poor PCF results.
Coordinates and connectivity
PCF is valuable because it carries more than a drawing. It describes the connected piping route so downstream tools can rebuild the line graph and place components in the correct sequence.
Coordinates, endpoints, branches, and component order should be checked after import. A visually acceptable Revit model can still contain disconnected elements that create split or incomplete PCF output.
Size, spec, and material fields
Size, spec, material, pressure class, insulation, and rating fields are usually project-specific. Some teams store them directly in Revit; others rely on shared parameters or mapped project conventions.
For search and buyer clarity, the important claim is not that every field is universal. The important claim is that PipeEX PCF Export provides a repeatable mapping path, and the team validates which fields are required by Plant 3D, CAESAR II, AutoPIPE, or another consumer.
SKEY and component representation
Many PCF-consuming workflows use symbolic component representation, often discussed as SKEY or component code behavior. The exact representation depends on the component, family mapping, and target tool expectations.
If an elbow, tee, valve, or reducer imports with the wrong symbol or catalog behavior, review the family-to-PCF mapping and the downstream import rules instead of only editing the PCF text by hand.
Example redacted PCF snippet
A redacted PCF review might include records for a pipeline header, a pipe segment, an elbow, a valve, and endpoint coordinates. Sensitive project names and client line IDs should be replaced before sharing externally.
Example review text: PIPELINE-REFERENCE LINE-XXX, COMPONENT PIPE 100, COMPONENT ELBOW 90, COMPONENT VALVE TAG-V-001, END-POINT X/Y/Z redacted. The exact token names vary by toolchain, but the validation idea is stable: line identity, component type, tag, size, and coordinates must survive the handoff.
What must be validated downstream
Validate the PCF in the receiving application, not only by opening the text file. Check line continuity, component count, branch locations, dimensions, tag fields, size/spec/material fields, and any deliverable-specific attributes.
Document fields that are intentionally completed in the downstream tool. PCF should reduce re-entry, but stress loads, support assumptions, analysis cases, and some deliverable formatting may still belong outside Revit.