4. 符号表与变量管理迁移

旧产线程序迁移到TIA Portal时，最容易被低估的工作不是逻辑转换，而是变量管理。S7-300/400时代的符号表、共享数据块和位内存地址，在TIA Portal中分别对应PLC变量表、全局DB和M/I/Q存储区。三者不是简单复制粘贴的关系，而是需要重新建立“符号名—绝对地址—数据类型—作用域”四者之间的映射。如果这一步做错，后续即使逻辑块移植正确，程序也会因为地址重叠、类型不匹配或符号名冲突而无法编译或运行异常。

一、先理清旧项目的变量来源

旧STEP 7项目中，变量通常来自四个位置：一是符号表（Symbol Table），包含I、Q、M、T、C等区域的符号定义；二是共享数据块（Shared DB），例如DB1、DB2中按偏移量排列的变量；三是位内存地址（M区），包括M0.0、MW10、MD20等；四是功能块背景数据块（Instance DB），这类DB通常随FB迁移，不建议手工重建。迁移前应先导出旧符号表为ASC或Excel格式，并逐条记录符号名、绝对地址、数据类型和注释。对于共享DB，需要导出其变量声明表，记录每个变量的偏移量、类型和初始值。

这里有一个关键判断：旧符号表中大量使用德语缩写或拼音首字母，例如“MOTOR_EIN”“ZYL_VOR”“STOER_01”。这些名称在TIA Portal中虽然允许使用，但不利于维护。迁移时建议同步做一次命名规范化，例如改为“Motor_Start”“Cylinder_Forward”“Fault_01”，并保留旧名到新名的对照表。对照表不是装饰，而是后续交叉引用和排障的依据。

二、命名冲突与地址重叠的处理顺序

迁移中最常见的三类问题，处理顺序不能颠倒。第一步先解决命名冲突：TIA Portal的PLC变量表中，符号名在同一作用域内必须唯一，且不区分大小写。旧项目中可能存在“Motor”和“MOTOR”两个符号，迁移后会冲突。处理方法是合并为同一符号，或加前缀区分，例如“Motor_Conveyor”和“Motor_Pump”。第二步解决地址重叠：旧程序中可能存在M10.0被定义为“Start”，同时MW10又被定义为“Speed”的情况。M10.0属于MW10的低字节，两者物理重叠。TIA Portal不会自动阻止这种定义，但会在编译时给出警告或导致逻辑错误。处理方法是重新分配地址，或改用DB存储，避免M区重叠。第三步解决数据类型不匹配：旧符号表中MW10定义为INT，但实际程序中按WORD使用，迁移后如果直接定义为INT，比较指令可能出错。需要根据实际用法重新选择数据类型。

三、共享DB迁移到TIA Portal的具体做法

旧共享DB通常采用绝对地址寻址，例如DB1.DBW0、DB1.DBD4。TIA Portal支持两种DB：优化DB和非优化DB。优化DB不支持绝对地址访问，但支持符号名访问，且访问速度更快、类型检查更严格。迁移时建议优先转为优化DB，但前提是旧程序中所有对DB的访问都能改为符号名。如果旧程序中存在大量间接寻址或指针操作，例如使用DB1.DBW[AR1,P#0.0]，则必须保留非优化DB，否则程序无法运行。

具体操作时，先在TIA Portal中新建一个全局DB，命名为“DB_ProcessData”或类似名称。然后按照旧DB的变量声明表逐条添加变量。对于旧DB中偏移量为0的INT变量，在优化DB中直接定义为“Start_Status : Int”；对于偏移量为2的WORD变量，定义为“Speed_Word : Word”。注意，优化DB中变量的顺序由声明顺序决定，不再由偏移量决定。如果旧程序中有代码依赖偏移量顺序，例如通过DBD4访问第三个变量，迁移后必须改为符号名访问，否则会访问到错误变量。

对于旧DB中未使用的预留字节，例如“Reserve : Array[0..9] of Byte”，在优化DB中可以保留为数组，也可以删除。如果删除，需要确认旧程序中没有通过绝对地址访问这些预留区。建议保留并加注释，避免后续排障时找不到对应关系。

四、位内存地址迁移的注意事项

M区迁移到TIA Portal时，PLC变量表中可以直接定义M0.0、MW10等。但需要注意两点：第一，TIA Portal中M区的默认保持范围与旧PLC可能不同。旧S7-300中M0.0到M15.7通常设置为保持，而TIA Portal中需要在PLC属性中手动设置保持范围。如果旧程序依赖M区的保持特性，例如M10.0作为设备运行状态记忆，迁移后必须检查保持设置，否则断电重启后状态丢失。第二，M区地址重叠问题在TIA Portal中不会自动报错，但会导致逻辑错误。例如M10.0定义为“Start”，MW10定义为“Speed”，两者物理重叠。如果程序中同时使用这两个符号，写入MW10会改变M10.0的值。处理方法是使用PLC变量表的“地址重叠检查”功能，或手动逐条核对地址范围。

五、数据类型不匹配的典型场景与处理

数据类型不匹配是迁移后编译错误的主要来源。常见场景包括：旧符号表中MW10定义为INT，但程序中用“==”比较时与WORD常量比较，TIA Portal会报类型不匹配；旧DB中DBW0定义为WORD，但程序中按INT进行算术运算，迁移后需要改为INT；旧程序中TIMER类型在TIA Portal中对应IEC_TIMER，不能直接复制。处理方法是逐条检查旧符号表和DB声明，根据实际用法重新选择数据类型。对于不确定的变量，可以先定义为WORD，编译后根据错误提示再调整。

下面给出一份迁移检查表的示例，用于逐条核对变量迁移结果。该表为示例模板，实际使用时根据项目变量数量扩展行数。

六、迁移后的验证方法

变量迁移完成后，不能只看编译是否通过。建议做三项验证：第一，在PLC变量表中使用“交叉引用”功能，检查每个符号是否被程序块正确引用，是否存在未使用的符号或未定义的符号。第二，在监控表中强制写入关键变量，例如将“Motor_Start”置为TRUE，观察对应输出Q0.0是否动作，验证地址映射正确。第三，对于共享DB，打开DB在线视图，对比旧DB的初始值和当前值，确认数据类型和偏移量对应关系无误。如果发现某个变量值异常，优先检查该变量是否与其他变量地址重叠。

最后需要强调：变量迁移不是一次性动作，而是贯穿整个迁移工程的基础工作。建议在TIA Portal中建立独立的“变量迁移”工作区，保留旧符号表导出文件、新旧对照表和迁移检查表。这样在后续逻辑调试阶段，一旦发现变量问题，可以快速回溯到旧项目定义，避免反复猜测。