# Historian tag model for LPBF copper cold-plate validation runs

**URL:** <https://forum.inductiveautomation.com/t/historian-tag-model-for-lpbf-copper-cold-plate-validation-runs/116669>\
**Category:** Ignition\
**Created:** [August 5, 2026, 2:08pm UTC](https://forum.inductiveautomation.com/t/historian-tag-model-for-lpbf-copper-cold-plate-validation-runs/116669 "2026-08-05T14:08:55Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![WalterChenComo](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/walterchencomo/32/86471_2.png) [@WalterChenComo](https://forum.inductiveautomation.com/u/WalterChenComo)\
**Post date:** [August 5, 2026, 2:08pm UTC](https://forum.inductiveautomation.com/t/historian-tag-model-for-lpbf-copper-cold-plate-validation-runs/116669/1 "2026-08-05T14:08:55Z")

</div>

I am mapping how Ignition could be structured for validation runs on LPBF copper/CuCrZr cold plates. Each run would have inlet/outlet temperature, flow, pressure drop, pump command, ambient, part serial, fixture ID, and a steady-state acceptance window.

The manufacturing and verification context is here: [Thermal Design & Validation for Copper AM | COPPER 3DP](https://copper3dp.com/thermal-design-validation/)

Would you model this as:

1. continuous equipment tags plus a run table that stores start/end and part metadata, or
2. a UDT instance per test fixture/run?

The main issue is keeping higher-rate transient data available while making run-to-run acceptance reports easy to query. I am also interested in how others mark sensor replacement or calibration changes so historical comparisons are not misleading.

This is not a request for vendor recommendations; I am looking for historian and tag architecture patterns that have worked in production test cells.