AEC systems, photometric data, and the quiet automation behind production lighting.

IES-to-Revit family automation via Autodesk Platform Services

An end-to-end pipeline that ingests IES photometric files and generates parametric Revit families (.rfa) on demand. Triggered by product configuration in the manufacturer's catalog system; output flows back into a downloadable specification package for specifiers and electrical contractors.

The interesting design question was type catalogs versus per-variant families. A naive approach generates one .rfa per optic/driver combination — straightforward but produces thousands of nearly-identical files. The alternative — one shared RFA per optic group plus a .txt type catalog enumerating photometric variants — is dramatically leaner but requires careful MEP shared-parameter design so downstream Revit users still see the right electrical and identity data.

Adjacent research: standardizing MEP shared parameters across the manufacturer's full catalog so that families behave consistently when loaded into specifier projects regardless of which optic, lumen package, or driver was selected.

Photometric data pipeline — parsing, scaling, validating IES files at catalog scale

Custom tooling that parses, validates, and transforms IES files across the manufacturer's catalog. Handles the differences between LM-63-2002 and LM-63-2019 (header conventions, tilt data, keyword extensions), extracts power factor and input watts where present, and integrates candela distributions to derive luminous flux for downstream catalog and submittal data.

The non-obvious part is scaling between fixture lengths. A 4ft linear fixture is often two parallel 2ft LED boards splitting the driver current — so its candela distribution isn't simply the 2ft distribution doubled. The pipeline encodes the manufacturer's optical assumptions explicitly rather than letting them live in a spreadsheet somewhere.

Output formats feed downstream consumers: JSON for the web catalog, CSV for ERP item master sync, and structured data for the Revit family generator above.

Production NFC programming bridge across three vendor SDKs

A unified production tool that programs LED drivers on the factory floor by combining three otherwise-incompatible vendor toolchains: Signify MultiOne, Tridonic deviceCONFIGURATOR (which exposes itself only through Windows Named Pipes), and eldoLED/Optotronic. The operator scans a job ticket, the system verifies it against the ERP, generates the correct device configuration files (DCF and .trgf), and writes them to drivers via a FEIG CPR30 NFC reader.

Architecturally: cloud APIs generate config files, a local bridge service handles the NFC writes (since NFC hardware can't live in a browser), and the entire flow is gated on ERP job-ticket verification before any programming happens. Successful programming triggers Zebra label output for build traceability.

CAD/ERP integration — SOLIDWORKS PDM and Epicor Kinetic

Bidirectional integration between the engineering CAD vault and the manufacturing ERP. Read-only SQL access for cross-system reporting, BPM-driven automation for nonconformance reporting and DMR (Defective Material Report) workflows including vendor RMA return-to-supplier with correct GL transaction mapping, and React-based internal apps surfacing Epicor REST data to operators on the floor.

A working principle on this stack: verify empirically with SQL before trusting the UI. Documentation and the form layer often disagree about how a given transaction type or UOM conversion actually behaves; the database is the ground truth.