学生第一次做，全卡在「连得上，传不出」
上周带大三做智能制造方向的课程设计，选题是小型物料分拣台的状态监测。大家画结构选传感器都快，一周就出了方案，到数据上传这一步，一半人卡到 deadline 前一周都动不了。
我原来以为是学生不会写代码，蹲下来挨个看才发现，根本不是代码的问题。很多人连设备端上传的触发逻辑都搞反了。他们总觉得云端等着收，设备把数据推过去就行，哪想到工业现场很多低带宽场景，设备得先等平台轮询，乱推直接把网关堵死。
我翻了学生参考的旧讲义，上面写设备数据上传就是把采集到的数据打包发送到服务器，一句话带过，根本没说工业实机和实验室单片机demo有啥不一样。
有个戴黑框眼镜的男生找我吐槽了三回，说他买的模块是全新的，串口调试助手能打出完整数据，为什么上传到免费平台就全是丢包？我盯了他的代码十分钟，发现他把采集周期设成了100ms，免费平台给学生的带宽，1秒最多收5个包，可不全丢嘛。
他瞪着眼睛说，我看文献里的工业设备都是百毫秒级采样，所以就这么设了。我问他，你这个分拣台一分钟最多走10个料，你一秒采十次有啥用？他愣了半天说不出话。
原来我们都把教学顺序教反了
实话讲，之前我讲这块也是按教材来：先讲数据结构，再讲传输协议，再讲上传步骤，学生都是从代码往回倒推，根本不理解自己的设备到底需要什么样的上传方式。
做机械设计的学生，大部分不会去做专门的后端开发，你跟他背MQTT的QoS三个等级，他记下来转头就忘。他需要知道的只有三件事：我的数据要不要实时传？选什么方式不费钱不卡？出了问题先调哪里。
这次我干脆把整个顺序倒过来，先讲场景，再选方案，最后写代码。我把机械设计常见的上传需求分成了三类，让学生先对号入座：
- 第一类：事后导出，设备离线运行，实验结束再导数据，根本不需要实时上传，很多学生为了凑「智能化」硬要做联网，纯属给自己找麻烦。
- 第二类：定时批量上传，普通状态监测用，几分钟传一次平均数据就行，对带宽要求低，调试简单很少出错。
- 第三类：事件触发实时上传，只有设备出异常、触发动作的时候才传，平时待机，省带宽省额度。
不过话说回来，改了顺序还是有学生卡点。卡在哪里？边界感。
有个组做异常振动监测，选了事件触发上传，把阈值设得特别宽，实验室开个门震一下都触发，不到三天免费平台的存储额度就用光了，直接被停服，连原来存的数据都调不出来，急得团团转。最后还是改成了异常触发后连续传10组数据然后自动休眠，才解决问题。
能跑通实机的，才是该教的设计
我最大的反思是，这几年机械设计讲智能化，总喜欢往高大上了靠，要云平台要实时分析要数字孪生，结果学生连最基础的设备数据上传都搞不定，最后课程设计毕设，全靠演示视频凑数，根本没跑通过实机。
我三年前带过一个学生，为了做远程数据上传，花了一个多月折腾内网穿透、公网IP，最后结构部分的强度校核都没做完，答辩的时候结构变形量超了一倍，可惜不可惜？
很多教材里讲这块，上来就讲OSI七层模型，罗列十几个协议的区别，跟我们做机械设计的学生有多大关系？我们学数据上传，是为了给设备功能服务，不是去做通信工程师。能把需要的数据稳定传上去，不堵不掉，不额外花冤枉钱，这就够了。
这次改完教学逻辑，我给学生提了三个硬要求：
第一，先定你的数据要不要上传、要不要实时传，再选模块买配件，不许先买回来硬件再想怎么传。
第二，实机接线完最少跑24小时测试，丢包率超过10%就回去调上传周期，不许拿十分钟的测试结果交差。
第三，能省则省，不需要公网的就别弄穿透，不需要实时的就别选高成本协议，离线导出数据不丢人，凑出来的智能化才丢人。
上周收最终作业，八成的组都跑通了实机稳定上传，放在之前，能有三成跑通就不错了。还有个组本来要做实时上传，听完课改成了定时批量上传，省出来的预算加了一块防护钢板，结构刚性提了不少，评分的时候我直接给了A。
说到底，我们是教机械设计的，核心永远是设备本身，数据上传只是个工具。别把工具当目标，为了上传而上传，最后丢了自己的本行。对吧。
