1. 迁移工程认知

在工业自动化现场，一台运行了十年以上的设备往往仍在稳定生产，但它的控制系统可能已经进入“技术孤岛”状态：PLC程序基于TwinCAT 2编写，HMI使用旧版可视化组件，驱动参数通过早期总线配置，备件采购周期越来越长，工程师对原代码的熟悉程度逐年下降。当设备需要扩产、改造、接入MES或更换工控机时，一个现实问题就摆在面前——不是简单地把程序“复制”到新平台，而是要把整套控制逻辑、通信关系、参数体系和工艺知识，完整、可验证地迁移到TwinCAT 3环境中。这就是本课程所定义的TwinCAT旧设备控制程序迁移工程。

它的核心不是“换软件”，而是在保持设备功能与工艺行为一致的前提下，完成控制平台、工程结构和运行环境的系统性转换。迁移的对象通常包括PLC逻辑、运动控制配置、I/O映射、HMI画面、通信接口、配方与参数数据，以及隐藏在代码中的工艺时序和联锁条件。迁移的成果必须能够在新平台上编译、下载、运行，并通过现场或半实物测试验证其行为与旧系统一致。

典型场景：什么时候必须做迁移

迁移需求通常来自以下几类场景。第一类是硬件生命周期终止：原工控机或CX控制器停产，无法采购备件，只能更换为支持TwinCAT 3的新硬件。第二类是软件版本升级：TwinCAT 2已停止功能更新，新功能如EtherCAT分布式时钟、OPC UA、Tc3 PLC库无法使用，必须升级到TwinCAT 3。第三类是产线改造与扩展：增加伺服轴、视觉工位或机器人接口，旧架构的CPU性能和工程结构已无法承载。第四类是标准化与知识管理：企业希望统一到TwinCAT 3工程模板，便于多人协作、版本管理和后续维护。第五类是合规与安全要求：需要接入审计、远程维护或信息安全机制，旧平台无法满足。

这些场景的共同点是：设备仍在生产，停机窗口有限，迁移不能“推倒重来”，而要在可控风险下完成。因此，迁移工程必须像一次精密手术，而不是一次重建。

工程边界：迁移什么、不迁移什么

明确边界是迁移工程的第一道防线。迁移的核心范围包括：PLC程序逻辑与功能块、任务配置与循环周期、I/O变量与过程映像、运动控制轴参数与耦合关系、HMI画面与变量连接、通信协议与数据映射、配方与关键工艺参数。迁移的非目标范围通常包括：机械结构、电气柜布线、传感器与执行器本身、现场总线物理层、安全回路硬件。这些部分除非同步改造，否则应保持原状，迁移工程只保证控制程序对它们的接口行为不变。

边界不清会带来典型风险：把机械问题误判为程序问题，或在迁移中顺手修改工艺参数，导致行为漂移。因此，在项目启动阶段应形成一份迁移边界清单，明确哪些变量、哪些功能块、哪些通信报文必须逐位一致，哪些允许优化。这份清单是后续测试和验收的依据。

课程任务全景：从认知到交付

本课程围绕迁移工程的全生命周期展开，共30章，可划分为五个阶段。第一阶段是认知与准备，包括本章的迁移定义、场景与边界，以及旧工程资产盘点、TwinCAT 2与TwinCAT 3的架构差异、迁移风险评估。第二阶段是程序分析与映射，重点讲解如何阅读旧PLC代码、识别功能块依赖、处理全局变量与符号映射、替换Tc2库为Tc3库。第三阶段是工程重建与配置，涵盖新建Tc3工程、任务与周期配置、I/O重新扫描与映射、运动控制轴参数迁移、HMI画面重建与变量连接。第四阶段是通信与数据迁移，包括EtherCAT从站配置、OPC UA接口、配方与参数数据转换、第三方设备通信适配。第五阶段是测试、验证与交付，涉及离线仿真、在线调试、行为对比测试、停机切换方案、回退策略与文档交付。

每个阶段都对应可检查的交付物：资产清单、映射表、Tc3工程文件、I/O配置表、轴参数表、HMI变量表、通信测试记录、验证报告和切换预案。这些交付物不是形式文档，而是迁移过程中控制风险、保证可追溯的实际工具。

一个教学示例：迁移边界如何影响决策

假设某包装设备使用TwinCAT 2控制，包含3个伺服轴、1套EtherCAT远程I/O、1个旧版HMI和1条RS-232通信链路。迁移边界清单中明确：PLC逻辑、轴参数、HMI变量连接、RS-232报文格式必须保持一致；电气柜、机械凸轮、安全继电器不纳入迁移范围。在分析阶段发现，旧程序使用了一个Tc2专用的凸轮耦合功能块，Tc3中对应库已变更。此时不能直接删除该功能块，而应找到Tc3中的等效功能块，逐参数对比耦合曲线和相位偏移，并在离线仿真中验证轴间跟随误差。若误差超出允许范围，则需要调整参数或修改逻辑，而不是修改机械。这个例子说明：迁移工程的核心判断依据始终是行为一致性，而不是代码是否“看起来一样”。