上周四下午的机电系统综合设计实训，第三组的俩男生蹲在数控铣实训台边，满头汗。
他们做的柔性送料装置，刚跑12分钟就卡料了。俩人为了等这个故障点，蹲在边上盯了快40分钟，连水都不敢喝——怕一转身的功夫，故障点就过去了。
我靠在边上看了十分钟，突然想起这学期改了三次的课程设计题目，本来就是要解决这种“无意义蹲守”的问题。
最先被学生忽略的成本账
好多学生刚接触设备远程状态查看这个功能，第一反应就是往方案里堆配置。
买最贵的工业网关。接全链路的传感器。振动、温度、电机电流、传动带张紧力，恨不得把装置上每个零件的状态都传到云端。我上次翻他们的方案，差点把教案本捏皱。算下来单台装置的监测成本，快赶上装置本身的造价了。
真的没必要。
我们课堂上做的都是小型实训装置，既没有连续24小时运行的生产要求，也没有极端工况的环境考验，根本不需要照搬工业现场那套冗余的监测体系。去年有个组的作品，就用了个几十块的ESP32开发板，只接了三个核心信号：电机运行电流、送料到位的光电触发信号、气缸伸缩的位置反馈，把这三个数据传到微信小程序上，就实现了最基础的远程状态查看。
他们甚至上次在宿舍煮面的时候，看到小程序上显示装置到了预设的自动停机时间，才慢悠悠晃回实验室关机，省了整整一个小时的蹲守。
这里的设计取舍其实很简单：核心数据的选择，永远跟着你最不想蹲在现场盯的节点走。
比如之前碰到的卡料故障，本质上就是光电传感器被遮挡的信号，根本不需要额外测什么主轴振动的复杂参数。学生之前的误区，就是把这个功能做成了大而全的监测系统，完全脱离了自己做小实训装置的实际需求。有个学生之前跟我吐槽，他为了凑功能点，给装置加了个环境温湿度监测模块，结果上次实验室开空调，温度变了两度，他在宿舍的手机上弹了三条告警，他以为装置出故障了，跑回实验室发现就是空调吹的。白跑一趟，累得够呛。
卡了三届学生的那个逻辑bug
好多学生做远程状态查看，从一开始的逻辑就错了。
他们总想着“设备要把所有数据实时推送到我的手机上”。结果呢？实验室的WiFi稍微波动一下，数据链路就断了。手机上显示的状态，和现场实际状态对不上。
上次有个学生看到手机上显示装置正常运行，结果跑到现场发现，电机因为堵转过载，已经停了20分钟了。手机上因为网络断了，还停留在之前的正常状态页面。
错了。
我们后来在课堂上统一引导学生换个思路，别做单向的高频推送，就做轻量的请求-响应逻辑：你想知道设备状态的时候，主动发个请求给设备，设备把当前的实时状态回传给你。哪怕网络断个十分钟，你下次点进去看的时候，拿到的一定是当下的真实状态，根本不会出现“手机显示正常，现场已经停转”的乌龙。
我第一次把这个逻辑讲给学生的时候，有个男生突然拍了下脑门。他之前卡了两周的bug，就是因为网络断了的时候，设备还在往云端发缓存的旧数据，导致他的小程序状态永远比现场慢半拍。他之前改了快十版的网络重连逻辑，都没解决。结果换了个交互思路，一下就通了。
你说有意思不？
好多时候我们总觉得，做机械设计就是要把机械结构做的多精密，把传感器接的多全，却忘了最基础的逻辑通顺，比堆多少硬件都重要。
别把这个功能做成课堂上的“花架子”
之前几届的学生，做完设备远程状态查看的功能，就把它当成答辩PPT上的一个亮点页面。演示的时候连个实验室的WiFi，点一下小程序，显示个“运行中”，就完事了。真到后续做迭代的时候，根本没人用。
去年有个组的分拣装置，他们做了远程查看之后，整整一个学期，从来没在实验室以外的地方点开过那个小程序。那这个功能做了有啥意义？对吧。
我们现在的教学调整很简单，要求学生做完这个功能之后，必须真的在非实验室场景下用满三次。
比如小组轮值做实验的时候，轮值的学生不在学校，要确认装置是不是正常跑完了一整个循环，就靠这个远程查看的功能确认，不需要专门跑回实验室。比如装置跑自动循环的时候，学生可以在边上的办公室改图纸，看到状态不对了再过去处理，不用全程守在边上。
上个月有个组的学生，在去食堂买饭的路上，看到小程序上显示送料机构的到位信号连续三次没触发，就顺道拐回实验室，发现是物料偏了，调整了一下，前后花了三分钟。要是按照之前守在现场的模式，那得在实训台边上站一个多小时等这个故障。
说到底，我们教学生做设备远程状态查看，从来不是为了让他们在答辩的时候多一个可以吹的亮点。
就是为了帮他们省点无意义的等待时间。
没必要一上来就堆一堆昂贵的模块，搞一套复杂的云平台，最后做出来的东西自己都不愿意用。
