汽车产线PLC编程：SCL算法、顺控与梯形图如何协同分工

在汽车焊装、总装车间摸爬滚打多年，如果你要问我西门子PLC项目调试最怕什么，我的答案不是某个高深的指令不会用，而是接手一个毫无结构的程序。一条整线几十个工作站，如果每个人的SCL、梯形图、顺控逻辑都天马行空，那调试周期会直接失控。这篇文章想和你聊聊，在汽车行业真实的项目里，SCL算法、顺控和梯形图这三者到底各自扮演什么角色，为什么在成熟的项目经理眼中，程序结构的分量远超指令本身。

我会结合自己做过的产线项目，把这三类经典程序结构的使用场景、逻辑细节、以及它们之间如何配合讲清楚。内容不会停留在指令手册层面，而是聚焦于工程落地时真正会踩到的坑、真正需要的代码骨架和真正能让你少加班的经验。

1. 汽车项目的特殊“体质”：为什么结构先行比代码本身更重要

1.1 节拍、联锁与安全等级倒逼程序规范化

汽车制造区别于普通机械加工，最明显的三个词是：节拍、联锁、安全。

节拍意味着设备必须在30秒甚至更短的时间内完成一个循环，PLC的程序扫描周期要稳定，功能块不能有冗长的阻塞式等待。联锁意味着一个动作必须在前一个信号到位、后一个条件满足的前提下才允许执行，这就要求程序里必须有一种“状态矩阵”的概念，而不是散落一地的M点。安全等级意味着急停回路、安全光栅、安全门锁，大多由TÜV认证的安全PLC（如S7-1500F）处理，标准PLC需要通过Profinet与安全PLC进行状态字交换，这个交换逻辑必须放在固定的扫描周期里。

基于这三点，汽车行业逐渐形成了一套“约定俗成”的程序框架：输入统一映射、算法集中封装、顺控独立成块、输出统一驱动。我见过很多从通用设备转做汽车产线的工程师，第一反应是:“我梯形图写得挺溜的，继电器逻辑信手拈来。”但真正接手汽车项目后才发现，梯形图在联锁上确实好使，可一旦涉及几十组模拟量曲线的处理、拧紧扭矩的角度判定、视觉拍照位置补偿，直接用梯形图堆出来的程序简直没法维护。

1.2 程序是给团队看的，不是给PLC看的

这是我认为最关键的一句心得。PLC执行的效率差距并不体现在你用SCL还是梯形图，而在于这套程序有没有人能读懂、能修改、能交接。

汽车厂的项目周期通常很紧凑，电气调试阶段往往是“三班倒”的。一个程序今天是你写，下个礼拜可能是别人在维护，三个月后甚至要移交到厂方的设备科。如果程序结构不清晰，哪怕代码写得再漂亮，都是一堆数字垃圾。

我见过最典型的正面案例是：一个工作站有抓取机器人、压机、变位机、输送滚床、安全光栅、扫码枪。程序框架清晰到新接手的人能看着OB1的调用顺序，就把整台设备的运行逻辑在脑子里跑通。反面案例则是全部逻辑堆在OB1里，动用一个M点都要满屏搜索。所以在这篇文章里，我会把一个比较标准的三层结构拆开讲：用梯形图做底层信号与联锁，用SCL做中层算法与状态判断，用顺控（状态机）做顶层流程调度。

2. 梯形图是“肌肉”不是“大脑”：输出与互锁的正确打法

2.1 梯形图的本质究竟适合解决什么问题

梯形图源自继电器控制电路，它的优势是直观、符合电气操作工的思维习惯，特别适合表达“按钮按下去、继电器吸合、输出动作”这种即时逻辑。在汽车行业里，梯形图最适合干三件事：

• 标准IO信号处理：急停、门锁、光栅、双手启动等安全及操作信号，从安全PLC接收并转换成标准PLC内的联锁条件。
• 输出控制：直接驱动气缸阀岛、电机接触器、指示灯的各条支路。
• 简单互锁：两台电机不能同时启动、阀岛动作顺序保护等。

但你千万不要指望用梯形图去做复杂的模拟量计算。比如拧紧机实时发送的扭矩值要做均值、极差、斜率判断，这些需要用SCL；又比如视觉系统给过来一组XY坐标补偿值，需要做坐标系旋转映射，这更不是梯形图的长项。把算法硬塞进梯形图，最终的结果往往是密密麻麻的网络，没人敢动。

2.2 汽车产线里写梯形图的三个“土规矩”

第一，输入信号必须集中处理。不要在OB1里到处读光电传感器。我们通常会把整车工件检测、到位检测、安全门信号通过一个FC_InputMapping，把所有物理IO和Profinet GSD映射到DB块里的结构化变量，例如#Sensor.WorkpieceDetect、#Sensor.ClampEnd。这样后续所有程序块都只访问DB，不直接访问IO地址。

第二，使用“启保停”电路固定范式。汽车行业对电机、风扇、泵控制极其“保守”。下面这段文字描述的就是一个典型的LAD结构：

// 电机启保停电路（带自动/手动切换与安全反馈） Network 1: 控制字使能 #AutoCmd --| |--------/ /-------------------( #MtrRun ) #RunFeedback --| | #SafetyOK Network 2: 手动强制 #ManualCmd --| |------------------( #MtrRun ) Network 3: 输出映射 #MtrRun --| |-------------------( Q200.0 )

这个结构老套但稳定可靠。注意我把#SafetyOK串在了公共通路上，这是汽车行业的标准做法：任何标准PLC输出都必须以安全PLC给出的“允许运行”状态字为前置条件。

第三，不要在梯形图里改动报警文本或配方值。报警和配方统一走SCL或者HMI脚本，梯形图只干“通断”的事。

2.3 安全光栅与安全门信号的交接处理

汽车现场的安全光栅通常接入安全PLC（F-CPU），标准CPU只通过PN/PN Coupler或通过安全PLC的输出字获得“安全许可”信号。遇到很多跨度来的项目，工程师直接在标准PLC里读安全光栅的常开触点，这种我劝你别试，汽车厂安全评审直接不通过。

标准做法是：安全PLC维护一个16位状态字，比如：

标准PLC在FC_InputMapping里把这个状态字读出来，通过一个#SafetyWord变量供全程序使用。只有在#SafetyWord = 0xFFFF时，自动循环才被允许。梯形图的联锁网络就把#SafetyWord当作一个总闸。

3. SCL算法是“大脑”：处理曲线、数据和复杂判定

3.1 汽车行业里，哪些应用非SCL不可？

SCL（结构化控制语言）在博途里本质上是一个高级文本语言，类似于Pascal或VB。它对数学运算、数组、结构体、循环和条件分支的支持，是梯形图完全无法企及的。汽车行业里非要SCL不可的场景大概有这几类：

• 拧紧数据判定：比如电池包极柱拧紧，要求拧紧扭矩在某几个角度区间内保持在公差带内，同时实时计算峰值扭矩、终切扭矩、斜率。
• 压装曲线的监控：例如压机在压入轴承的整个行程中，位移和压力的对应关系必须呈现特定的包络趋势。如果出现过早的压力上升或压力骤降，要靠SCL对实时数组做特性判断。
• 视觉定位补偿：机器人抓件前，由视觉系统给出工件在X、Y、R方向上的偏差，PLC需要把偏差换算到机器人的基础坐标偏移，这块计算也靠SCL。
• 数据统计与追溯：比如统计生产节拍、焊接点数、报警频次，需要用到定时器数组、平均值计算等。

3.2 一个真实的拧紧结果判定FB拆解

我举一个我在电池模组产线里写过的功能块FB_TightenResultCheck。它的作用是接收拧紧机通过Profinet发送过来的10个扭矩采样点，判定拧紧质量是否合格。

先看代码块的核心逻辑：

FUNCTION_BLOCK FB_TightenResultCheck VAR_INPUT bExec : BOOL; arrTorque : ARRAY[0..9] OF REAL; // 从拧紧控制器读取的区间扭矩 rTorqueUpper : REAL; // 扭矩上限 rTorqueLower : REAL; // 扭矩下限 iOffsetAngle : INT; // 触发角度偏移 END_VAR VAR_OUTPUT xScrewOK : BOOL; xAlarmLow : BOOL; xAlarmHigh : BOOL; rMeanTorque : REAL; rStDev : REAL; END_VAR VAR i : INT; rSum : REAL; rDevSq : REAL; END_VAR // 标准启动方式：边缘触发 IF bExec AND NOT #iLockEdge THEN #iLockEdge := TRUE; #xScrewOK := FALSE; #rSum := 0.0; #rDevSq := 0.0; // 第1步：求均值 FOR #i := 0 TO 9 DO #rSum := #rSum + #arrTorque[#i]; END_FOR; #rMeanTorque := #rSum / 10.0; // 第2步：求样本标准差，判断离散度 FOR #i := 0 TO 9 DO #rDevSq := #rDevSq + (#arrTorque[#i] - #rMeanTorque) * (#arrTorque[#i] - #rMeanTorque); END_FOR; #rStDev := SQRT(#rDevSq / 9.0); // 第3步：判定是否在上下限内 IF #rMeanTorque < #rTorqueLower THEN #xAlarmLow := TRUE; ELSIF #rMeanTorque > #rTorqueUpper THEN #xAlarmHigh := TRUE; ELSE #xScrewOK := TRUE; END_IF; END_IF; // 输入信号复位 IF NOT #bExec THEN #iLockEdge := FALSE; #xScrewOK := FALSE; #xAlarmLow := FALSE; #xAlarmHigh := FALSE; END_IF;

这段代码里有几个容易踩坑的地方。

一个是边缘检测变量#iLockEdge。SCL不像梯形图天然有上升沿指令，这里用全局静态变量手动锁存。如果忘记写边缘锁定，程序会在执行位有效的每个扫描周期都重复计算一次标准差，虽然结果一样，但在工业现场若中间插入了新采样的数组值，数据的时序就会被搅乱。

另一个是数组下标边界。汽车程序最大的“崩溃源”其实是SCL里的越界访问。一旦arrTorque[10]，诊断缓冲区直接报编程错误，场上设备停线。所以我有一个习惯：所有传入SCL的数组，都先用UPPER_BOUND或者直接通过FOR循环配合SIZE()来限制范围。

最后是报警处理。你会发现我没有把ALARM直接发出去，而是输出布尔量交给上级FB统一处理。这是汽车行业的结构习惯：算法块保持“算干净”，报警文本和CLEAR逻辑集中在报警管理FC里。

3.3 SCL编写时的“高内聚、低耦合”心得

很多刚接触SCL的工程师，写着写着就把一串巨型计算往FC里塞，结果一个功能块动辄几百行，输入输出几十个。一旦调试的时候发现结果不对，根本没法定位。

我自己的习惯是：一个FB只做一件判一件。拧紧扭矩判定一个块，压装曲线斜率判定一个块，视觉坐标换算一个块，节拍统计一个块。每个块控制在50到80行之内，输入输出变量控制在10个以内。这样虽然调用了一堆FB，但每个FB都可以单独通过监控表给输入的仿真数据，验证输出逻辑。更有价值的是，这套FB可以被COPY到同类型的下一个项目里复用。

4. 顺控是“脊椎”：状态机设计决定设备节拍与稳定性

4.1 为什么老的“步进梯形图”在汽车行业不吃香了

提到顺控，很多人第一反应是三菱的SFC（顺序功能图）或者西门子的GRAPH。但在汽车行业，尤其博途环境下，我们更常用的是SCL手写状态机，或者直接在GRAPH里做。为什么不用老式步进梯形图呢？

因为汽车设备的状态不是一条直线走到底的。典型工位有手动、自动、复位、维护四种模式，自动循环会随时因为门打开、光栅触发、工件不到位、机器人故障而中断。老式的步进梯形图（用移位寄存器做步进）一旦状态乱了，找问题找到怀疑人生。

而SCL状态机的逻辑清晰到一眼能看懂“当前在哪一步，前一步的完成条件是什么，这一步的触发条件是什么”。而且状态机天然支持暂停、跳步、故障保持、复位重来。

4.2 用一个夹紧举升工位演示状态机骨架

假设一个工位：输送线把滑橇送到位后，举升器上升，然后侧向夹紧机构夹紧，机器人再焊接，完成后松开，举升器下降，滑橇放行。

在博途里我会把状态变量定义为一个INT，专门放在FB的静态区。下面是一个典型的SCL状态机核心代码：

// 状态定义 #state := 0; // 空 #state := 10; // 等待启动条件 #state := 20; // 输送滚床进料 #state := 30; // 定位请求 #state := 40; // 举升前进 #state := 50; // 侧向夹紧 #state := 60; // 机器人交互焊接完成 #state := 70; // 松开 #state := 80; // 举升返回 #state := 90; // 滚床出料完成

主跳转逻辑示例：

CASE #state OF 10: // 等待自动循环使能 IF #AutoMode AND #SafetyWord = 16#FFFF AND #Handshake_OK THEN #state := 20; END_IF; 20: // 启动滚床电机正转，并等待工件到位信号 #Roller_FWD := TRUE; IF #SensorPos THEN #state := 30; END_IF; 30: // 停滚床，触发定位阻挡器 #Roller_FWD := FALSE; #Stopper := TRUE; IF #StopperEnd THEN #state := 40; END_IF; 40: // 举升器上升 #Lift_UP := TRUE; IF #LiftUpEnd THEN #state := 50; END_IF; 50: // 侧向夹紧 #Clamp := TRUE; IF #ClampEnd THEN #state := 60; END_IF; 60: // 给机器人发自动焊接请求，等待机器人回焊接完成信号 #Robot_Start := TRUE; IF #Robot_Done THEN #state := 70; END_IF; // ... 后续省略 END_CASE;

这个骨架的威力在于，每一个#state都对应一组输出动作和一个完成反馈。如果设备卡住了，工程师打开监控表，直接看#state停在哪一步，然后看这一步的前端条件和后端反馈缺失了什么，通常几分钟就能定位故障。

4.3 自动/手动/安全复位三大模式的正确摆放

顺序控制必须处理好三个模式的切换逻辑。我在项目里的做法是：

• 自动模式：状态机从初始位运行，严格按照CASE状态顺序执行，过程中任何安全信号断开，状态机会立即跳到一个“暂停等待”分支，安全信号恢复后，无论当前在哪个状态，都要恢复到暂停前的状态继续。
• 手动模式：状态机不运行。所有输出都由HMI按钮强制控制，但每个输出仍然受安全PLC总字控制。这个模式下的所有动作指令直接映射到梯形图网络里，相当于把状态机“旁路”掉。
• 安全复位模式：急停恢复后，PLC不是立刻回到自动运行，而是先进入一个专门的“复位步”。比如要求操作员双手按下复位按钮，才能把状态机的#state强制跳回10，然后再触发启动条件进入自动循环。这个逻辑在汽车行业是硬性要求，能有效防止急停恢复后设备意外动作。

有一种错误做法是急停复位后在梯形图里用一个SET指令把所有输出直接复位。这样虽然表面安全，但操作员不知道系统处于什么状态。而状态机方式的好处是：设备究竟该退半程还是推半程，是按照你在SCL里写好的复位分支执行的，过程可预测、可追溯。

5. 一台设备的总装：SCL、顺控和梯形图的协同架构实例

5.1 程序调用层次Idea：OB1里的“三层结构”

把前面的内容综合起来，在一台汽车工位PLC里，我的程序调用结构通常长这样：

• OB1（主循环）：
  • 调用FC_SafetyGuard（梯形图）：将安全PLC状态字映射到DB，并输出总安全许可。
  • 调用FC_InputMapping（梯形图）：将远端IO和阀岛反馈刷新到公共DB。
  • 调用FB_SequenceController（SCL）：顶层状态机，对节拍、顺序流程进行调度。
  • 调用FB_QualityCheck（SCL）：拧紧、压装、视觉等核心数据算法块。
  • 调用FC_OutputMapping（梯形图/SCL）：将计算结果和安全条件统一映射到物理输出模块。
  • 调用FC_AlarmHandling（SCL）：集中处理报警、历史记录、故障快照。

这样分下来，梯形图主要负责“手脚”，SCL主要负责“大脑”，顺控负责“神经”，三者各司其职。调试时哪个环节出了问题，看调用链一眼就能锁死在某个FB里，不用满屏找触点。

5.2 ABB变频器与安川机器人Profinet通讯地址对应法

在搜索词里我注意到很多人问“ABB变频器和西门子PLC怎么通讯”“西门子PLC与安川机器人Profinet通讯地址怎么对应”。这块确实是汽车集成商项目里的重头戏。

先说标准步骤。第一步，先把ABB变频器和安川机器人的GSDML文件安装到博途的硬件目录里。第二步，在设备视图里分配设备名称和IP地址。第三步，在“设备视图”的IO表里配置通讯报文结构。

ABB变频器通常我们用PPO类型1（4个字控制字/状态字 + 2个字速度设定/反馈），比如控制字地址是I/Q地址，状态字从I/Q地址偏移2个字开始，速度设定在偏移4个字。在PLC侧，不会直接去读I/Q的物理地址，而是把这些I/Q地址映射到DB结构体里：

// DB_ABB1 // ControlWord (IW100) // StatusWord (IW102) // SpeedSet (QW100) // SpeedAct (IW104)

注意博途里无法直接在DB里新建符号地址去覆盖物理IO，但可以通过POKE指令或者直接访问I/Q地址来刷新。不过我现在更推荐在程序里做一个映射块，用标准的MOVE指令或直接#DB_ABB1.ControlWord := "IW100"这种写法。这样维护的人不需要对着硬件组态表找一个地址，直接看DB变量名就能懂。

安川机器人大同小异，同样是Profinet从站。安川的标准报文中一般有交互信号，通常包含：

这里有一个关键点：地址对应的不是任意的，而是严格按机器人侧“IO分配表”来的。在安川的示教器上进行IO定义时，会看到类似“Input signal 1001 - 1016”对应到Profinet的输入模块位置。你需要确保PLC侧组态的Profinet模块的输入起始地址，和机器人侧发送数据的位置一致。要确认这个对应关系，最稳妥的办法是先在PLC侧给某一个输出字强制一个数值，然后在机器人示教器上查看对应的IO字节有没有变化，以此验证映射关系。

5.3 自动循环和机器人交互的“心跳”机制

在汽车产线上，PLC和机器人之间除了常规的状态和控制信号，往往还需要一个“握手心跳”机制。这不是可选的，而是防止通讯卡死的重要手段。

具体做法是：PLC侧建立一个2Hz脉冲，把值写入机器人的某个输入点，同时机器人侧也把它的循环计数写到PLC的输入映射里。PLC判断如果超过500ms没有收到机器人侧的新计数，就判定通讯异常，强制状态机跳转至故障暂停分支。这个功能用SCL写很简单：

// FB_HeartbeatCheck IF #iCounter <> #iRobotHeartbeat THEN #xComAlive := TRUE; #iCounter := #iRobotHeartbeat; ELSE #xComAlive := FALSE; END_IF;

如果你在现场调试时遇到机器人报异常但PLC状态机没反应，十有八九就是没有心跳保护，机器人程序死循环了PLC还不知道。加入心跳之后，设备会立刻停机并弹出“机器人通讯中断”的报警，不会等操作员发现。

5.4 我一般在联调前先跑这几类“模拟验证”

实践中的经验是，程序写完不能直接上线，至少要过三遍模拟。

• 第一遍，强制IO模拟：把传感器信号用PLC变量强制，手动跑一遍完整的状态机，看看各步骤之间有没有卡住的节点。
• 第二遍，虚拟Profinet站模拟：在没有实际机器人和变频器的情况下，可以建一个虚拟的PLC或仿真模块，把Profinet从站的数据在仿真里喂给主站功能块，验证通讯映射没有断链。
• 第三遍，故障注入：人为断开一个安全光栅信号、取消一个气缸到位反馈，看PLC是否能按预期进入故障状态，并产生正确的报警文本。

这三遍走完，现场上电联调的时间至少能砍掉一半。

回到最初的话题。汽车行业对PLC工程师的要求，从来不是把某个指令用得特别花哨，而是能不能把一套逻辑用清晰、安全、可复用的结构组织起来。SCL负责复杂计算与数据判定，梯形图负责输入输出与安全联锁，顺控负责节拍与流程调度，三者协同，设备才能跑得稳，出了问题才能查得准。最后分享一个个人的习惯：我会在自己的博途库文件夹里建立一个“标准结构库”，里面存着常用的FB_MotorControl、FB_ValveControl、FB_Sequencer_Template、FB_TightenCheck等通用块。新项目来了，优先从库里调用框架，而不是从零堆逻辑。这套方法让我在转换项目时始终心里有底。希望这篇关于SCL算法、顺控和梯形图的程序结构分享，能让你在下一个汽车项目里少走点弯路。