企业官网建设流程全解析

做了一段时间CODESYS项目，尤其是涉及运动控制和多轴联动的场景，我越来越觉得ST语言写得好不好，直接决定了你三天后还能不能看懂自己的代码，以及同事接手时是想请你吃饭还是想骂你。上一篇part 1聊了命名规范、文件组织和基础的POU结构，这篇part 2往里走一层，专攻数据类型规划、任务分配、状态机设计、功能块封装、错误诊断这些真正影响程序质量和调试效率的东西。

内容会结合我实际调试汇川PLC、用SoftMotion跑六轴机器人时踩过的坑来展开，不会只讲标准条款，尽量都落在具体能抄作业的例子上。

1. 数据类型规划：把小变量攒成工程结构

ST语言最容易被低估的环节就是数据类型设计。很多人写程序就是BOOL、INT、REAL一把梭，程序简单时没什么问题，一旦涉及多轴插补、位姿换算、工艺参数切换，变量满天飞的状态下，根本分不清哪个REAL是X坐标、哪个REAL是目标速度。数据类型的核心价值不是“规范”两个字，而是让代码自解释、让错误在编译期现形。

1.1 基础数据类型的使用边界

CODESYS里的基础类型和IEC 61131-3标准一致，但实际使用中有几个地方要特别注意：

• BOOL：只用来表示“是/否”，不要参与算术运算。很多人为了省变量，用BOOL累加计数器，这种代码维护起来很痛苦。
• INT/DINT：CODESYS里INT是16位，范围-32768到32767。轴速度、位置误差这些量级稍大的数值，直接上DINT，别给自己埋雷。我见过不止一次因为INT溢出导致坐标跳变的事故，排查的时候完全看不出来。
• REAL/LREAL：涉及长度、位置、速度这些需要精度和量程的变量，优先用LREAL做运算，只在发送给驱动器或写入HMI显示时才做必要转换。REAL在累计运算时会飘，这是浮点本身的性质，不是你代码的bug，但规范的做法是从源头减少这类隐患。
• TIME/TOD/DT：定时用TON、TOF，但状态停留时间、节拍统计这类需要长时间累计的场景，建议直接用LREAL秒数，否则后期做数据分析时还要到处转，很麻烦。

基础类型规范的核心原则是：变量声明的类型要让别人一眼看出它的量纲和使用场景。凡是带工程单位的变量，直接裸用REAL、INT都不够，要在命名上带单位后缀，或者在注释里写清楚，两者最好都做。

1.2 枚举与别名是状态可读性的地基

ST里最容易被忽视但回报率最高的语法是TYPE定义。尤其是枚举类型，它能把一堆魔法数字变成有业务含义的名字。我在做六轴机器人的夹具控制时，最初定义抓取状态用的是1、2、3、4，两个月后自己看都不知道1代表的是“夹紧完成”还是“松开完成”。后来改成枚举，这个低级错误就彻底消失了。

TYPE E_GripperState : ( eGripper_Idle := 0, eGripper_Opening := 1, eGripper_Open := 2, eGripper_Closing := 3, eGripper_Closed := 4, eGripper_Fault := 16 ) INT; END_TYPE

注意我故意把错误状态从取值上和其他状态拉开，保留跳变余量，这样在总线监视表里看到状态值等于16时，不用查代码就知道是故障态。

另一个值得养成习惯的是别名类型，特别是与IO地址、驱动器参数相关的变量。用别名把底层实物和逻辑含义解耦：

TYPE Axis_Ref_ActualPos : LREAL; (* 单位:mm *) END_TYPE

1.3 结构体：把轴参数、位姿、报警信息做成一张表

结构体是ST工程数据组织的核心工具。没有结构体的ST程序，变量表就像菜市场；有了结构体，就像给每个物料筐贴上了标签。

我在机器人项目里常用这样几个结构体：

TYPE ST_Pose : STRUCT dX : LREAL; (* 笛卡尔X, mm *) dY : LREAL; dZ : LREAL; dA : LREAL; (* 欧拉角A, deg *) dB : LREAL; dC : LREAL; END_STRUCT END_TYPE TYPE ST_AxisParam : STRUCT stRefAxis : AXIS_REF; (* SoftMotion轴引用 *) rVelMax : LREAL; (* 最大速度 mm/s *) rAccMax : LREAL; (* 最大加速度 mm/s2 *) rJerkMax : LREAL; (* 加加速度 mm/s3 *) eDirection : E_Direction; (* 正转/反转/双向 *) bEnable : BOOL; END_STRUCT END_TYPE

这里有个非常实用的细节：AXIS_REF是SoftMotion轴的引用句柄，强烈建议把轴引用和轴的工艺参数一起封装在同一个结构体里。否则你会在程序里看到轴命令FB的Axis输入参数处反复拖变量，拖错一个轴就出大事。

把报警信息也做成结构体，这个习惯能直接改善后期HMI对接的效率：

TYPE ST_AlarmRecord : STRUCT usiAlarmID : WORD; tTriggerTime : LREAL; (* 设备上电累计秒 *) eLevel : E_AlarmLevel; sMessage : STRING(80); END_STRUCT END_TYPE

2. 变量声明与作用域：VAR不是随便写的

ST代码里变量声明位置不同，生命周期和可见范围完全不同。很多新手甚至部分老手都搞混了VAR、VAR_INPUT、VAR_OUTPUT、VAR_IN_OUT、VAR_GLOBAL、VAR_TEMP、VAR_STAT的区别，这直接影响程序的严谨程度和可测试性。

2.1 六类变量区的适用场景

这里重点讲两个容易翻车的点。

VAR_IN_OUT不是VAR_INPUT。它们在变量区的位置不一样，语义也完全不同。VAR_INPUT是传值，FB内部怎么改都不影响外部变量；VAR_IN_OUT是传引用，FB内部改了就直接改外部变量。运动控制里的主命令结构体，如果你不希望被某个FB改坏，就用VAR_INPUT；如果你希望FB直接操作外部轴结构体，那就用VAR_IN_OUT。但要注意VAR_IN_OUT在实参传递时，不能用字面量或常量，必须传变量本身。

VAR_TEMP必须显式初始化。很多人栽在VAR_TEMP默认值为0的假设上，但CODESYS的VAR_TEMP在特定任务配置下可能不是干净的。规范做法是声明后就赋值，别省这一行。

VAR_TEMP rTempAcc : LREAL := 0.0; bCalcDone : BOOL := FALSE; END_VAR

2.2 输入输出参数规范

功能块的输入输出参数，有三个建议：

1. 输入参数只做格式转换和判断，不要在里面做复杂的工艺计算。工艺计算应该放在FB内部VAR里，或调用专门的私有方法。
2. 输出参数要带有效标志。比如一个计算位置的FB，输出除了X/Y/Z之外，用一个BOOL表示“本次计算结果有效”，否则外部拿到上一周期的残留值，排查起来特别妖。
3. 所有FB的输入输出参数都按结构体分组。超过3个参数就不要平铺了，做成参数结构体，避免调用界面密密麻麻。这在后面封装功能块的实操里我会再展示。

2.3 全局变量与IO映射的隔离

VAR_GLOBAL这个区域很容易变成垃圾场。规范的做法是只做两层事情：

• 第一层：把物理IO映射进去，比如g_bInput_StartBtn AT %IX0.0 : BOOL;这类地址映射变量，只允许在设备配置层赋值。
• 第二层：把跨程序的共享状态变量放进去，例如g_eSystemState : E_SystemState;、g_bEmergencyStop : BOOL;、g_diMachineRunningSec : LREAL;。

其他所有中间运算的临时状态、工艺数据、局部参数，一律不放进全局区。我在汇川PLC项目里见过几百个全局变量从Main直接到处引用的代码，程序一旦出故障，你不知道改动哪个全局变量会影响哪条逻辑，调试起来就是灾难。

注意一点，网络上的“codesys的PLC网口MAC地址”相关问题，本质上也是IO映射和底层配置问题。CODESYS Runtime的网口、MAC地址、IP设置，属于设备配置层面的内容，变量层不需要管；真正需要做的是在全局区建一个结构体来承载通讯运行状态，比如：

TYPE ST_NetStatus : STRUCT bLinkUp : BOOL; sIP : STRING(15); dwRxBytes : DWORD; dwTxBytes : DWORD; bModbusTCP_Master_OK : BOOL; END_STRUCT END_TYPE VAR_GLOBAL g_stNet : ST_NetStatus; END_VAR

3. 任务配置与周期分配：运动控制项目的命门

ST语言规范不能只看代码文本，还得看这些代码是在哪个任务周期里跑、以什么优先级跑。CODESYS里任务配置对程序行为的影响，比重远比很多人以为的大。同一段ST代码，放在1ms周期任务里和放在50ms周期任务里，控制效果和资源占用完全是两个世界。

3.1 任务优先级与周期的分配思路

CODESYS的任务类型有“触发周期任务”和“自由运行任务”两种，一般都用固定周期触发的周期任务。任务优先级的数字越小优先级越高，CODESYS里0是最高优先级，通常留给运动控制或通讯协议栈。

以一台六轴机器人设备的典型任务分配为例：

这条分配逻辑是：越快越重要、越快越短的逻辑放高频优先级高的任务里；人机交互和参数类数据放慢任务里。把工艺逻辑状态机放在10ms周期很合理，因为人的操作和大部分传感器变化不需要2ms级的响应；如果状态机放2ms任务里跑，反而会频繁触发抖动、误判。

3.2 运动控制任务与SoftMotion配置

CODESYS里做六轴控制时，SoftMotion是核心运动控制库。它分为标准SoftMotion和SoftMotion Light等不同授权版本，提供的轴类型有AXIS_REF等。运行时，轴的插补计算必须在同一个固定周期的快速任务里完成。

这里回答一个热词“codesys添加softmotionlight和softmotion”的问题。在CODESYS里添加SoftMotion库的流程大致是：

1. 在库管理器（Library Manager）中点击“添加库”。
2. 在搜索框中输入SoftMotion，过滤出SoftMotion Light或完整版SoftMotion。
3. 选中需要添加的库并确认，库管理器会带出它依赖的基础库（如Util库、Motion库）。
4. 添加后在设备树中出现SoftMotion的配置节点，这时才能使用MC_Power、MC_MoveAbsolute这些功能块。

关键点在于：SoftMotion Light和完整版SoftMotion对轴数和功能块的授权限制不一样，Light版通常轴数和功能范围有限，比如不支持CNC或某些高级插补。添加什么库取决于你的授权文件，而不是代码里想用多少功能块。如果发现编译报错说缺少库授权或者功能块不可用，先检查授权和库版本的匹配关系。

在任务分配上，运动控制相关功能块的调用必须在周期<=5ms且优先级最高的任务里。MC_Power、MC_MoveAbsolute、MC_GroupXYZ这些运动功能块，以及轴参数的更新逻辑，全部放在这个任务里。有些工程师把所有程序堆在默认的MainTask里，周期还是默认的100ms，结果轴跑起来一顿一顿的，不是算法不对，是任务周期根本喂不饱插补器。

3.3 用任务计数器做健康监控

任务配置到位后，还需要一个东西来证明任务真的按预期跑了——任务计数器。这是很多工程师忽略的。

在每个任务里对各自的全局计数器加1，然后在慢速任务里比较这些计数器的增量是否在合理范围内。比如FastIO_Motion任务里每周期加1，1秒内应该增加的次数约为1000/2=500次；如果实际只增加了300次，说明任务被高优先级任务阻塞了，出现了任务超时或丢帧。这个隐患在长时间运行、负载增加时特别容易暴露，而且不会直接导致报错，只会让运动精度劣化。

(* 在FastIO_Motion任务末尾 *) g_diCnt_MotionTask := g_diCnt_MotionTask + 1; (* 在WatchDog_Task里 *) IF (g_diCnt_MotionTask - g_diCnt_MotionTaskLast) < 400 THEN bMotionHealthy := FALSE; ELSE bMotionHealthy := TRUE; END_IF g_diCnt_MotionTaskLast := g_diCnt_MotionTask;

这个比单纯看CPU占用率要准得多，因为它直接反映任务调度层面的健康状况，而不是资源使用率那种间接指标。

4. 状态机设计：六轴机器人的逻辑骨架

机器人和运动控制程序的逻辑骨架，几乎必然是状态机。没有状态机的代码，用一堆互相嵌套的IF-ELSE来管理轴的启停、回零、到位、报警、急停，最后一定会出现逻辑漏洞：可能在某个组合条件下，两个互斥的动作同时被执行，或者卡在某个状态里出不来。

4.1 为什么状态机比散碎的IF-ELSE可靠

状态机本质上是用一个约束条件管理流程：同一时刻只有一个状态生效，状态迁移有明确的触发条件、执行动作、结果状态。这能让所有读代码的人，包括三个月后的你自己，把整个控制流程画成一张清楚的表格。

我见过最典型的反面案例是：用BOOL变量表示“回零完成”“夹紧完成”“门已关闭”等条件，然后直接在Main里用IF判断这些条件“层层套娃”，再加一堆互锁。结果是，任何两个条件的组合逻辑遗漏都会形成安全漏洞，而且排查的时候根本无迹可寻。

状态机代码的核心不是写完状态就完事，而是每个状态都要有明确的进入条件、停留逻辑、离开条件。以六轴机器人的一个简化工作流为例：

CASE eMainState OF eSt_Init: (* 初始化 *) bInitDone := FALSE; eMainState := eSt_Home; eSt_Home: (* 回零 *) bIsHomed := FALSE; // 调用MC_Home或自研回零功能块 IF bHomeFinished THEN eMainState := eSt_Ready; END_IF eSt_Ready: (* 待机 *) IF bStartCycle THEN eMainState := eSt_Running; END_IF eSt_Running: (* 运行 *) // 调用路径规划 IF bCycleDone THEN eMainState := eSt_Ready; ELSIF bStopRequest THEN eMainState := eSt_Stopping; END_IF eSt_Stopping: (* 停机 *) // 执行减速停止 IF bStopped THEN eMainState := eSt_Ready; END_IF eSt_Fault: (* 故障 *) // 故障锁定，需人工复位 IF bFaultReset AND bFaultCleared THEN eMainState := eSt_Init; END_IF END_CASE

注意，这个状态机里Fault状态是最高优先级，无论从哪个状态进入Fault，都要有统一出口。同时，我在每个状态里都用了独立的FUNCTION_BLOCK或方法封装该状态的具体逻辑，CASE本身只负责迁移，这样每个FB可以单独调试。

4.2 状态定义与迁移规范

状态机相关的命名和定义，有几个能落地的规范：

状态枚举命名统一用E_SystemState，带e前缀，按流程顺序赋值。状态值从0开始顺排，保留一定间隔，以便后期插入新状态。

状态迁移有三个原则：

• 原则一：每个状态里必须明确本状态停留时持续执行的动作，不能只在进入时执行一次就完事。比如Stopping状态要持续输出减速指令，直到速度归零。
• 原则二：状态迁移的判定条件统一放在状态段的末尾，按优先级写：故障 > 急停 > 请求停机 > 正常流程结束 > 启动新步骤。
• 原则三：跨状态的共享变量，在进入状态的第一行做统一赋值初始化，避免上个状态残留值污染本状态逻辑。

4.3 状态超时与异常复位

状态机里最容易出现的问题是“卡死”。比如轴回零指令发出后，因为某根轴的限位没到位，回零FB不返回完成标志，整个状态机就停在Home状态不动了。设备不报警也不执行，就是不动，现场调试的人最难排查的就是这种“不死不活”的状态。

对策很粗暴也很有效：每个状态都要配上超时看门狗。用一个共同的时间基准变量，每个状态设置允许停留的最长时间，超时后直接进Fault状态并产生报警码。

CASE eMainState OF eSt_Home: // 进入状态时启动计时 IF bFirstEntry THEN tStateTimer := TIME(); bFirstEntry := FALSE; END_IF // 回零动作 // 状态迁移条件 IF bHomeFinished THEN eMainState := eSt_Ready; bFirstEntry := TRUE; ELSIF (TIME() - tStateTimer) > tHomeTimeout THEN eMainState := eSt_Fault; usiAlarmCode := 1001; (* 回零超时 *) bFirstEntry := TRUE; END_IF END_CASE

这里有一个细节值得多说一句：bFirstEntry这个“进入状态只执行一次”的标志，是状态机代码里最常见的隐藏bug来源。很多人忘了在迁移时把它重置，导致下次进入同一状态时不会重新初始化。我的规范是“每个状态的第一行就处理这个标志，把该状态的进入动作和周期动作显式分开”。

5. 功能块封装：从复制粘贴到库工程

ST编程规范如果只停留在“代码写得整齐”这个层面，那就太浅了。真正拉开差距的是功能块设计的水平。功能块写得好，项目越做越轻松；功能块写得差，就是给后续每个项目埋雷。

5.1 SMC/运动控制功能块调用规范

在CODESYS里用SoftMotion运动库时，你会发现所有运动控制功能块几乎都是一个套路：有输入参数、有执行位Execute、有输出状态位Busy/Done/Error/CommandAborted。调用它们有一套统一的规范：

• 每次执行指令都要先给Execute一个下降沿/上升沿。CODESYS的MC功能块通常用R_TRIG触发Execute位，连续置TRUE是无效的。
• Done信号只在功能块完成的一个周期内为TRUE，必须立刻被逻辑捕获并记录下来，否则下个周期就丢了。
• Error后必须检查ErrorID并做明确处理，不要只把报警信息发给HMI，程序内部也要有一个对应的异常流程。

fbRTrig_Start(CLK := bStartMoveCmd); fbMoveAbs_01( Axis := stAxis1.stRefAxis, Execute := fbRTrig_Start.Q, Position := rMoveTarget, Velocity := stAxis1.rVelMax, Acceleration := stAxis1.rAccMax, Jerk := stAxis1.rJerkMax, Done => bMoveDone, Busy => bMoveBusy, Error => bMoveError, ErrorID => wMoveErrorID );

5.2 封装自己的功能块

有了运动库兜底还不够。工艺中大量重复出现的功能——比如“轴运动到指定位置”、“检测到料到位后夹紧”、“暂停时保持当前位置”——都应该封装成自己的功能块。封装的好处有三个：一是调用界面简洁；二是统一修改工艺参数时只改FB内部；三是可以在内部统一加日志和监控。

我自己封装一个“位置到达检测”功能块的思路供你参考：

FUNCTION_BLOCK FB_PositionCheck VAR_INPUT rActualPos : LREAL; rTargetPos : LREAL; rWithinRange : LREAL; (* 允许误差, mm *) END_VAR VAR_OUTPUT bInPosition : BOOL; bRangeCheckOK : BOOL; END_VAR

内部实现就是绝对值比较，但在输出上做了“范围判定”和“有效标志”分层，外部调用者不会误用一个超出有效范围的“到位”信号。

5.3 接口设计：参数该传结构体还是平铺变量

功能块接口设计是最影响可维护性的决策。我现在的原则很明确：输入参数超过3个就打包成参数结构体；运动控制类和硬件相关的用引用；参数有数量差异的用ARRAY结构。

FUNCTION_BLOCK FB_MultiAxisMove VAR_INPUT stGroup : ST_AxisGroup; (* 轴组描述, 含轴引用 *) rPoseSetpoint : ST_Pose; (* 目标位姿 *) rSpeedRatio : LREAL; (* 倍率 0.0~1.0 *) bStart : BOOL; END_VAR

这样调用的时候，一眼能看到一个功能块需要哪些核心输入，而不是一堆散落的参数拖来拖去。

5.4 库工程化：把自己常用的轮子沉淀下来

项目做多了以后，会发现大量功能块是跨项目复用的。位置检测、软限位、管脚滤波、HMI数据交换、报警解析，这些都属于通用功能。把它们放进独立的Library工程里，打包成.library文件，然后在不同项目里引用，是ST编程规范最进阶的一步。

这个操作有几个细节：

• 库工程里只放通用的、与具体设备无关的代码。
• 库工程内部分层：基础通用功能层、行业工艺层、设备适配层。三层之间依赖方向必须单向。
• 每次改动库之后都要更新版本号，并且写清变更记录，否则引用方不知道新库改了什么，很容易出兼容问题。
• 库变更后，引用方要重新生成一遍主工程，确认没有编译错误。注意CODESYS项目文件多以XML格式保存，用代码对比工具做差异分析时要小心，很多格式差异是无意义的自动格式化，真正要关注的是逻辑变更。

6. 错误码与诊断：设备坏了也别乱猜

项目交到现场后，维护人员面对的永远是“设备不动了，报警也不弹”这种场景。程序里有没有一套完善的错误码和诊断体系，直接决定了故障恢复时间是10分钟还是3小时。

6.1 错误码统一建模

我建议每个项目里都建立一个统一的错误码枚举表，用全局常量或枚举类型统一管理。错误码分三段式结构：

• 第1位：错误等级（1=提示，2=警告，3=故障，4=安全）
• 第2-3位：子系统编号（01=轴系统，02=夹具，03=通讯，04=气路，05=安全）
• 最后两位：子系统内具体序号

例如F_301表示“轴系统故障—某轴软限位触发”，W_207表示“夹具警告—夹爪开到位延时”。这套编号的规则一旦定下来，整个程序里所有报警都用它，HMI的报警文本表也按这个编号建立，调试时扫一眼编号就知道该往哪查。

6.2 日志数据落盘的实现思路

错误码只是给人看的，要排查问题还得靠数据。ST代码里写日志通常有几种实现途径：

• 简单方案：用RECIPE或配方数据块记录最近的几百条事件，每条包括时间戳、事件类型、错误码、附加参数。
• 持续记录：通过Modbus/TCP把报警推给上位机，用上位机写文件或数据库。
• 现场排查：直接在CODESYS的Trace工具上在线观测变量波形，定位卡在某状态前的关键信号。

我在六轴机器人调试时最常用的是第一种，定义一个报警记录数组：

VAR_GLOBAL arAlarmHistory : ARRAY[0..99] OF ST_AlarmRecord; iAlarmWriteIdx : INT := 0; END_VAR

每次触发报警时写入一条记录，写满后回到0位置覆盖最老的一条。现场出问题时，拉开报警历史就能看到“回零超时前0.5秒时哪个轴速度异常”之类的时间线索，比盲猜效率高一个量级。

6.3 软复位与现场调试规范

最后说一个很容易被忽略但又极其实用的经验：故障复位必须严格分两级。

• 软复位：只清除“可恢复故障”的标志位，比如通讯瞬时断开后重连成功，或者夹爪开到位超时但人工确认无碍。软复位不能清除安全类故障。
• 硬复位：只有安全条件满足（急停释放、门关闭、手自动切换回安全状态）后，在HMI上执行复位，然后设备才允许重新进入Init状态。

用代码实现时，硬复位条件至少要包含：急停回路信号正常、安全门信号正常、轴软限位未激活、伺服使能已断开。这些条件缺一不可，否则就存在安全隐患。

实际做下来，我有一个很深的体会：ST语言编程规范不是给“别人”看的约束，而是给自己和未来的接手人留的活路。数据类型规划、任务周期分配、状态机设计、功能块封装，任何一步偷懒，最后都会在调试现场以更难看的方式还回来。尤其是运动控制项目，程序跑得稳不稳，七分在硬件选型与机械结构，三分在代码与任务的协同——而这三分的差距，往往就是规范与随意之间的差距。

最后再分享一个小技巧：CODESYS项目里如果你用汇川等国产PLC的CODESYS平台，要注意库版本和Runtime版本的匹配，很多诡异的编译错误和运行崩溃都源于版本错位。比如SoftMotion库升了一版，轴参数的默认值就可能变了，以前的程序重新编译后运动表现会和原来不同，这种问题最难查。建议每次升级SDK或库文件后，都拿旧版本代码做一个回归验证，别图省事直接怼到现场设备上。