每次批改学生的PLC大作业，我都有一件头疼的事：程序下载下来，打开一看，OB1里密密麻麻堆了几百行代码，没有注释、没有分层、没有模块。想找一个电机的启动逻辑，得从头翻到尾。我管这种程序叫“面条式代码”——看着能吃，但理不清、改不动、维护起来要命。

今天，我就用一个“红绿灯”案例，讲讲怎么把一盘“意大利面”改造成一座“模块化建筑”。

反面教材：一段真实的“面条代码”

这是我上学期一个学生交上来的红绿灯程序。功能很简单：东西向和南北向轮流放行，红灯、绿灯、黄灯依次切换，带人行道按钮请求。

学生花了很大力气写出来了，运行时也能亮，但问题出在哪儿呢？

第一，整个程序全写在OB1里，没有FC、没有FB，所有逻辑搅在一起。东西向的绿灯时间、南北向的黄灯时间，这些参数散落在程序各处，想改一个时间，得全局搜索，还得小心别改错了地方。

第二，没有注释。我逐行翻看，试图理解某个计时器的用途，但变量名叫T1、T2、M0.0、M0.1……说实话，我自己看着都费劲。我问这个学生：“这个T37是干什么的？”他想了半天，自己也记不清了。

第三，扩展性为零。如果我想加入一个“紧急情况全红”模式，或者“夜间黄灯闪烁”模式，他不知道从哪下手，因为所有状态都耦合在一起。

我在批改意见上写了八个字：“功能实现，工程不及格。”

进阶示范：把“面条”变成“积木”

同样的红绿灯需求，我带着学生一起重构。我们用结构化编程的思路，把程序拆成四块积木。

第一块，数据定义。在DB块里，我们把所有的时间参数定义成符号变量，比如EastWest_GreenTime、NorthSouth_YellowTime。这些变量有名字、有类型、还有注释，以后想改时间，只需要进DB块改一个数值，不用动任何逻辑。

第二块，状态机封装。我们用FB写了一个“单方向交通灯控制器”。这个FB的输入是当前状态的剩余时间，输出是红灯、绿灯、黄灯的控制信号。这样一来，东西向和南北向可以复用同一个FB，只需要分别调用、传入不同的参数就行。代码量直接减少了一半。

第三块，主逻辑编排。OB1里面干净了，只做三件事：调用东西向的灯控FB、调用南北向的灯控FB、处理人行道按钮的中断逻辑。整个OB1不到30行代码，读起来像一份说明书。

第四块，紧急处理。我们单独写了一个FC叫“EmergencyHandler”。当急停信号触发时，不管当前是什么状态，所有方向出红灯，并且锁死所有输出。这个FC和主逻辑完全独立，互不干扰。

重构完成后，学生自己都惊讶了：“老师，同样的功能，现在看起来顺眼多了。”

方法论：结构化编程三步走

通过这个案例，我总结了一套适合教给学生的方法论，每次上PLC课我都会反复强调。

第一步，分析工艺流程，画出时序图。不要一上来就拖梯形图，先在纸上画清楚：系统有哪些状态？状态之间怎么切换？每个状态的触发条件是什么？红绿灯的时序图画出来，程序其实就完成了一半。

第二步，划分功能模块，定义接口。把大问题拆成小问题，每个小问题对应一个FC或FB。关键是定义好模块的“接口”——输入是什么，输出是什么，内部变量有哪些。模块之间尽量解耦，互不依赖。

第三步，编写代码，自上而下。先搭框架，再填细节。主程序负责调用，子程序负责干活。变量命名要规范，注释要写到“别人三天后还能看懂”的程度。

我还编了一个顺口溜，每次课结束前让学生一起念：“输入输出先映射，中间逻辑用功能，复杂状态上SCL，变量命名要人命。”最后一句是玩笑，但也是实话。

写在最后

从“写代码”到“做工程”，这个转变不是一朝一夕的事，但值得每一位老师和学生认真对待。在我看来，一个程序的好坏，不在于它能不能跑通，而在于三个月后、三年后，别人拿到你的程序，能不能看懂、能不能维护。

那个交“面条代码”的学生，后来重修了我的课。期末的时候，他交了一个车间物料分拣的程序，用上了模块化、用上了DB块、注释写得比我要求还详细。我在作业上回复：“这才是工程师该有的样子。”

所有的学生都能做到，只要我们从第一行代码开始，就教给他们正确的思维方式。