搞控制的人最舒服的状态是什么模型在 Simulink 里建好仿真曲线跑通然后一键把代码生成到 PLC 里现场设备的实际数据和仿真几乎重合。但真实情况往往是模型只能留在电脑里算法要靠手工翻译成 SCL 或者结构化文本翻译完了还得处理数据类型、时序、初始化一堆问题调试到天亮都未必对得上。近两年我在几个部署项目里反复做 Simulink 转博图TIA Portal的工作踩了不少坑也慢慢摸出了一套能稳定落地的流程。这篇就把最重要的核心要点梳理一遍适合手头已经有 Simulink 模型、准备部署到 S7 系列 PLC 的人也适合第一次接这种任务、连从哪下手都不知道的新手。我不去讲那些细枝末节只聊能直接拿来用的东西模型侧要做什么、代码生成怎么配、博图里怎么导、现场运行怎么调。1. 整体思路与方案取舍先分清要不要自动生成1.1 这个事到底是什么Simulink 转 PLC本质上解决一件事把在 MATLAB 环境里建模、仿真、验证过的控制算法变成可以在 PLC 上周期执行的代码。PLC 的执行模型和 Simulink 完全不一样。Simulink 里时间可以自由推进有连续求解器、变步长、事件触发而 PLC 只有一个固定的循环节拍物理上只能每隔一定时间扫描一次程序在这个节拍内把所有任务执行完。所以“转换”这个动作不只是语法翻译而是把一种以“模块图 时间连续”为核心的计算方式映射到“周期扫描 函数调用”的工业执行环境里。这个过程绕不开的中间层是代码生成器。Simulink PLC Coder 是官方提供的工具能生成结构化文本ST/SCL代码也可以生成 C 代码。博图TIA Portal这边对 ST 代码的支持靠的就是 SCL 语言TIA Portal 可以直接导入外部源文件把 ST 代码编译成可执行对象。整条链路就是Simulink 模型 → PLC Coder 生成 ST 代码 → TIA Portal 导入 → 外层封装成功能块 → 由 PLC 周期调用。注意这里谈的“适配博图”指的就是 SCL 这一环的兼容性而不是说 PLC 里能直接跑 Simulink 的二进制模型这种概念上的区分很多人一开始没意识到后面就会瞎折腾。还有一点值得先说清楚为什么不是直接转成梯形图梯形图擅长开关逻辑、互锁、电气回路但你让它去表达一个卡尔曼滤波的状态更新方程写出来会非常痛苦而且可读性极差。SCL 是文本语言能写复杂的数学表达式、数组运算、循环本质上接近通用编程语言。这也是为什么自动生成路径几乎都会选 ST/SCL 作为输出语言而不是梯形图。认清这一点你才不会在工具配置里找半天“梯形图生成选项”。1.2 自动生成和手写移植怎么选这是最应该想清楚的问题也是最容易被忽略的问题。很多人一上来就想着把整个模型全部生成到 PLC结果生成的代码量巨大、运行周期撑不住最后又退回手写。我个人的判断标准很简单。如果算法涉及大量矩阵运算、状态空间求解、观测器、滤波器、预测控制这类数值密集型计算自动生成几乎是最好的选择。因为手写这类数学逻辑非常容易出错而且很难保证和仿真结果一致。Simulink 模型本身就是经过验证的算法描述自动生成相当于把这份描述直接翻译成目标代码一致性远高于人工转译。如果控制逻辑就是简单的开关逻辑、顺序控制、布尔判断那自动生成不仅不划算还会因为生成的代码结构复杂而拖慢扫描周期。比如一个电机起保停电路手写 SCL 十行以内生成出来可能几百行完全没必要。而且生成的代码内部包含了大量临时变量和辅助函数资源占用高纯逻辑控制场景根本吃不消。还有一个折中方案我在这几个项目里用得最多把模型里最核心的算法部分做自动生成外围的 IO 处理、使能逻辑、故障诊断仍然手写。这样做的好处是复杂计算交给可靠的生成器外围逻辑保持人的灵活控制既保证核心算法不出错也把代码规模控制在合理范围。选自动生成之前要做一次可行性审查模型是否离散化、采样时间是否合理、数据类型是否已收敛、生成代码有没有用到 PLC 不支持的动态内存、指针、递归调用。这些检查最好在动手前完成否则配置做到一半才发现模型根本不适合生成前面功夫全白费。2. 模型侧准备与代码生成配置决定成败的第一步2.1 模型离散化与采样时间的设定PLC 是周期执行模型必须工作在离散状态。这一点怎么强调都不过分。如果在模型里用了连续积分环节或者连续求解器生成的代码即便编译通过运行起来也会因为缺少真实积分环境而出现各种怪异现象。比如明明是个稳定的闭环一到 PLC 里就震荡或者某个状态变量不断累积漂移几分钟后直接饱和。所以第一步就是检查模型里的所有积分环节全部改成离散版本。常用的做法是用零阶保持器离散化或者在 Simulink 里把求解器设置为固定步长离散求解器先仿真确认行为不偏差太大再进入代码生成流程。采样时间的设定是另一个关键。理论上采样时间要满足控制带宽的需求至少比被控对象中最高频的动态过程快 5 到 10 倍。比如你的对象动态响应最快是 100ms 级别采样步长保守起见就取 10ms 到 20ms。PLC 侧还要考虑扫描周期。如果 PLC 的循环中断周期是 10ms模型采样周期最好不要设成 25ms 这种非整数倍关系否则会产生相位抖动。工程上常见做法是采样步长取 PLC 扫描周期的整数倍比如 1 倍、2 倍、5 倍这样每次调用时机都是确定的不会累积偏移。还有一个细节固定步长求解器的类型选择。离散模型最稳妥的是选“单任务离散”SingleTasking模式或者把求解器类型直接选为离散。如果在配置里还保留连续求解器代码生成时会自动插入一些连续求解器的支持代码这些代码在 PLC 里根本用不上只会白白增加体积和计算开销。我见过有人生成的代码里带了完整的 ODE 求解器辅助函数原因就是模型里残留了连续模块。2.2 PLC 代码生成的几项关键配置配置这一步不同人用的工具版本不一样界面可能略有差异但逻辑基本一致。我一般会走这么几个步骤。第一步在模型的 Configuration Parameters 里选择 PLC Coder 作为代码生成目标目标平台选择和你实际部署的 PLC 类型匹配这里就是选 S7 系列相关支持。第二步语言选择结构化文本 ST。这里要确认一下生成模式有些版本会默认生成 C 代码而不是 ST需要手动切过去。切过去以后代码生成报告里的输出文件后缀就会变成 .scl 或 .st。第三步函数封装方式。通常选生成一个 step 函数和一个 initialize 函数。推荐关闭“生成单独文件”的选项让代码整体打包方便导入 TIA Portal。因为如果拆成多个小文件导入博图时要逐个处理文件之间如果有相互引用编译顺序稍不对就报错。第四步代码优化级别。优化要打开可以减少代码体积和局部变量但不要开到最高级。最高级可能会改变某些内部计算的顺序在数值敏感算法里会产生微小偏差比如一个矩阵连乘展开以后浮点累加顺序变了结果就差几个单位。对控制算法来说这种差随迭代会累积非常不好排查。第五步注释和文档选项。生成的代码里默认带一堆注释不影响执行但导入博图后代码体积会明显变大。建议把注释量降到最低尤其是那些“Generated by Simulink”之类的头部注释。真正运行的时候没人看这些PLc 内存才是硬约束。2.3 数据类型和接口的预处理代码生成之前模型里所有和外部交互的信号都应该明确数据类型和维度。我见到最多的问题就是 double 类型。Simulink 里默认数据类型是 double也就是双精度浮点64 位。S7 系列 PLC 里的浮点数是 REAL单精度32 位。这个映射关一旦处理不好仿真结果和现场数值对不上是必然的不是差一点而是能差出一个数量级。我的做法是建模阶段就把关键信号的数据类型显式设置成 single然后在仿真时也用 single 跑。这样仿真时看到的精度表现就是将来 PLC 里实际运行的精度表现没有任何意外。Code Generation 本身的自动映射也有但我从来只把它当作兜底而不是依赖。还有一个容易被忽略的地方是模拟量输入输出的范围。Simulink 里你随便定义一个 0 到 100 的百分比信号PLC 侧对应的可能是 0 到 27648 的整数编码。这类缩放关系必须在模型侧用 Gain 模块提前处理而不是部署到 PLC 以后再手动换算。为什么坚持在模型侧处理因为模型侧处理完之后仿真结果和现场实际值可以直接对得上排查问题少绕一大圈。如果你让 PLC 侧做线性转换仿真输出和现场实际之间永远隔着一层换算每次调试都要同时看两边效率极低。3. 工具链与目标平台适配搞清楚你手上的“博图”是什么3.1 博图版本与 SCL 支持差异同一个“博图”名称下面不同版本的 SCL 编译能力差别不小。较新版本对复杂数组、结构体、字符串处理的支持明显更好编译速度和诊断信息也完善得多。早期版本有时会出现对某个 ST 语法报“不支持的表达式”但同样一段代码换到新版上就能正常编译。所以做这类项目我强烈建议先把博图版本确认清楚再决定模型里怎么组织代码。如果手头的博图版本比较旧那模型侧就要尽量避免生成过于前沿的语法结构比如避免在内部代码里使用复杂的嵌套 FOR 循环或动态数组访问。这里有个教训有一次我把目标平台配置成了某个比较新的 PLC 型号生成的 ST 代码里嵌了一段针对长数组的初始化指令。导入到现场那台版本偏旧的 TIA Portal 里编译直接挂掉。后来只能回到 Simulink 里把数组拆成标量接口重新生成一遍才勉强通过。所以版本适配不是到了博图侧才想的模型生成配置阶段就要把现场环境一起考虑进去。3.2 S7-1200 与 S7-1500 的资源边界S7 系列里最常见的是 1200 和 1500 两个子系列它们的资源边界差异很大。S7-1500 的浮点运算能力强内存也大适合跑带有大量矩阵运算或状态观测器的模型。S7-1200 是小中型 PLCCPU 主频有限内存也小跑比较大的生成代码会非常吃力。我有一个测算习惯先把生成的 ST 代码行数拿到再估算里面需要多少字节的静态变量区。一般来说超过几千行带浮点运算的代码就不太建议往 S7-1200 里塞了硬塞进去要么扫描周期暴涨要么编译时报内存不足。如果项目还没定 PLC 型号我的建议是只要模型里有超过几十个状态变量的算法优先选 1500 系列留足余量。不要为了省几百块硬件成本让后面的算法优化和代码瘦身占用大量调试时间。硬件选型省下来的钱远远不够覆盖现场调试的人工成本。3.3 ST 代码与 C 代码的选择除了 ST 代码PLC Coder 也能生成 C 代码。很多人会在这一步纠结。我直接给结论在 S7 系列 PLC 上标准路径就是 ST/SCL不用考虑 C 代码。原因很简单常规 S7 CPU 没有开放 C 运行时环境C 代码不能直接作为 PLC 程序运行除非设备本身是带操作系统的工业 PC 或者软 PLC 方案那就不是传统意义上的博图项目了。ST 代码则是 TIA Portal 原生支持的语言之一导入、编译、下载都是顺畅的。所以路径选择其实是平台决定的而不是个人偏好。如果你确认将来要部署到基于 PC 的软 PLC 或带实时系统的控制器上再考虑 C 代码的路径也不迟。但在普通的 S7 项目里谈 C 代码只会绕远路。工具链的适配就到此为止明白这些边界之后再进博图做集成会顺很多。4. 博图适配与集成落地代码只是开始4.1 生成的代码长什么样用 PLC Coder 生成的 ST 代码结构上一般包含两个核心函数一个是初始化函数负责把内部状态变量设置成初始值另一个是 step 函数也就是周期执行的主计算函数。step 函数的输入参数对应模型中的输入端输出参数对应模型中的输出端。函数内部通常会有很多临时变量代码结构看起来像一个比较大的 SCL 程序块。下面是个简化的结构示意// 示意结构实际代码会比这个多很多 FUNCTION_BLOCK FB_ModelWrapper VAR_INPUT u : REAL; // 模型输入 END_VAR VAR_OUTPUT y : REAL; // 模型输出 END_VAR VAR x : ARRAY[0..9] OF REAL; // 模型内部状态 tmp : REAL; // 临时变量 END_VAR BEGIN // --- 这里粘贴 Step 生成代码 --- // y : ...; // tmp : ...; // 状态更新逻辑 END_FUNCTION_BLOCK在 TIA Portal 里你不会直接把这段代码当成主程序运行而是先建一个 FB功能块在 FB 的声明区里定义好输入、输出和静态变量然后把生成的 step 函数代码整体复制到 FB 的代码区。这个 FB 就是模型的外壳上层 OB 只需要周期调用这个 FB 就行。初始化函数可以在 FB 的初始化部分调用一次或者用 FB 静态变量的默认值来实现。这样外层结构非常清晰输入输出全部暴露在 FB 的接口上想监控哪个变量都方便查问题的时候不用去翻一大堆内部局部变量。4.2 TIA Portal 导入与外层功能块封装在博图里导入 ST 代码有两条路。第一条是用“外部源文件”功能在项目树里右键添加新源文件选 .scl 后缀把生成的代码贴进去编译完成后可以生成一个功能块。这个方式适合代码量大、结构完整的工程。第二条是手动处理新建一个 FB把变量声明区先按代码里的输入输出补齐再把代码粘贴到实现区然后编译。如果代码规模不大我更喜欢第二种因为变量声明和注释都掌握在自己手里排查问题顺手。无论走哪条路有三件事必须注意。变量命名冲突是高频问题。生成的代码内部变量名可能带有特殊前缀博图不保证完全兼容遇到报错就改变量名但建议在生成前就在 Simulink 侧做一个全局命名前缀设置统一加个短前缀比如 mdl_能避免大多数冲突。数组下标习惯也要统一。博图数组可以自定义上下界我一般统一用 LOWER_BOUND 0 来对齐 C/ST 习惯这样从代码里复制过来的数组访问逻辑不用改。如果 Simulink 侧的数组默认是 1 基索引生成的代码里可能会差一个下标这种错误编译能通过但运行结果完全不对非常隐蔽。FB 的调用方式同样要注意。封装好的 FB 不能直接往 OB1 里一放就完事还要确定调用位置。建议单独建一个技术功能块专门负责周期调用便于运行监控。直接把算法 FB 散落在 OB1 的各个角落后面想测量这段代码的执行时间都很难操作。4.3 轮询调用与周期设计PLC 运行模型算法绝对不能直接挂在 OB1 上。OB1 的扫描周期和程序复杂度强相关同一段代码在不同扫描周期里执行到的位置可能完全不同时序不稳定对算法来说是灾难。我的做法是建一个循环中断 OB设置固定中断周期比如 10ms再在中断里调用封装好的 FB。这样模型的计算频率是精确可控的不受主程序其他逻辑影响。循环中断的周期要和模型采样步长保持一致性。如果模型采样时间是 20ms而 PLC 循环中断是 10ms那 step 函数每执行一次需要等待两个中断周期逻辑上也能跑但复杂状态下容易出现状态滞后和时序抖动。更好的做法是循环中断周期等于模型采样步长或者采样步长是中断周期的整数倍。如果是整数倍关系step 函数外层要加一个计数逻辑只有计数满时才真正执行 step。这个执行标志位可以作为 FB 的输出暴露出来方便监控。实际部署时还要留一个性能余量参数step 函数的平均执行时间占循环中断周期最好控制在 50% 以内。如果占太高后续模型迭代加功能或者现场负载增加时很容易超时触发 PLC 的循环超时报警。这个参数建议在上线前就测好别等到现场出了问题再抓瞎。5. 部署中的常见问题与排查技巧实录5.1 导入编译阶段的经典报错我把实际过程中碰到的问题整理成一个速查表方便对照现象原因处理办法导入时提示语法不支持生成了特定平台扩展语法或源文件编码不符合预期检查生成选项把平台相关选项全部取消确认编码为 UTF-8函数名重复step 函数名与博图已有对象重名生成前在代码接口里配置函数命名前缀数组越界多维数组拍平后下标错位统一数组定义上下界用 LOWER_BOUND 0数据类型不匹配double 被映射为 REAL 后某些接口还要和 DINT 对接在模型侧显式把接口转换成需要的类型表格里每一条都可以展开。就拿第一类来说我遇到过生成的 ST 文件里带了一些由代码生成工具额外加上的平台宏定义博图转译的时候直接报“未知标识符”最后只能把代码里无关的部分删掉再编译。所以导入之前先打开源文件扫一眼是很有必要的习惯。不要指望一键导入永远顺利多留出十分钟做检查能省出一个晚上的排查时间。数组越界这类问题最典型的场景是 Simulink 侧用了一个二维矩阵接口生成到 ST 里变成二维数组。如果模型里对矩阵的索引方式用的是 C 语言习惯从 0 开始而你在博图里不小心把数组下限定义为了 1那每一个访问都会错位运行结果完全不可理喻。排查时可以先把所有数组下限改成 0如果现象立刻消失那就是索引约定不一致。5.2 运行阶段的偏差、时序与资源问题编译通过不代表运行就对。最典型的问题是仿真曲线和现场曲线对不上不是差一星半点而是趋势都对不上。这时候先不要怀疑代码生成有 bug90% 的概率是采样时间不一致或者模型侧和 PLC 侧的数据类型精度不一致。我的排查顺序是先确认循环中断周期和采样步长再检查所有接口数据的类型和缩放最后再对比关键中间变量的数值。中间变量对比这一招最有用它能帮你在模型内部定位到第一个产生偏差的位置而不是在输出端猜原因。第二个高频问题是 CPU 占用过高。生成代码虽然看起来是一堆文本但里面常常有大量嵌套循环和矩阵计算。S7-1200 这类小型 PLC 跑起来尤其吃力。建议在上线前做一个性能估算把 step 函数平均执行时间控制在循环中断周期的 50% 以内。如果超了优先优化模型里的矩阵运算比如用直接公式替代复杂的矩阵求逆而不是去优化代码结构本身。第三个问题是状态初始化。生成的初始化函数只在 FB 首次调用时执行一次如果中途修改过模型并重新下载 PLC 程序老的状态可能残留导致输出跳变。解决办法是在 FB 里加一个“模型复位”输入或者用启动 OB 里的触发逻辑把初始化函数强制调用一次。这个细节很多文档不会写但现场基本都会遇到提前设计好能少很多麻烦。5.3 一套我实测好用的推进流程最后分享一个自己反复用的推进顺序。拿到模型后我不会先去做代码生成而是先把模型里所有可能引起部署问题的地方标记出来包括连续积分环节、int 型接口、上升沿检测模块、维度不明确的信号。然后把任务分成两类一类需要在模型侧修改另一类可以在 PLC 侧通过外层封装解决。这样就不会在工具配置里反复返工。具体流程大概是模型离散化检查 → 采样周期确定 → 接口数据类型规范化 → 代码生成 → 导入博图 → FB 封装 → 循环中断部署 → 空载仿真对比 → 连接 IO 实机验证。每一步都有对应的输出物比如采样周期确定后就写进项目文档这样后续迭代时有据可查。尤其是代码生成那一步建议先生成一个最简单的测试模型比如一个增益模块加一个积分器把整个链路从生成到博图运行完整跑通再换成真实模型。很多人一上来直接拿完整模型去生成到最后一步出问题定位范围会非常大。我个人习惯在每一步切换前都做一次“目标环境对照”问自己这段逻辑在 PLC 里会以什么频率执行、有什么资源限制、和模型里的仿真假设是否一致。把这个问题想清楚比记住任何具体配置项都重要。工具只是执行者真正决定成败的是对两个平台差异的理解。我自己在这几轮项目里最深的体会是Simulink 转 PLC 这件事最磨人的不是工具链而是心态。总觉得自动生成就应该是一键完成却忘了 PLC 和 Simulink 是两种执行模型一个时间自由一个严格周期。把模型离散化、把数据类型显式收敛、把采样时间对齐这三件事做到位后面基本是水到渠成。顺便分享一个最后的小技巧在上线前把生成代码里的所有常量调出来和 Simulink 模型里的参数逐个核对一遍经常会有意外收获。我至少碰到过两次模型中某处还是默认的 0.5、1.0而实际工程参数应该是 0.05、10 的情况。这类问题不会报错但会让现场的曲线非常难看多留这一步能帮你省掉大量排查时间。