1. 一次批量报废让我决定给车间上环境监控1.1 精密加工里温度和湿度到底动了什么去年夏天我们车间最忙的一周出了件让我印象极其深刻的事三批铝合金零件连续出现尺寸超差而且超差的方向完全一致全部往负偏差跑。这个零件是配合件孔径要求在0.02mm范围内结果批量报废了四十多件耽误了后端装配进度。排查了很久刀具没问题装夹没问题程序也对。后来查阅机床日志和空调运行记录才发现那几天气温连续超过38摄氏度车间的两台工业空调有一台在凌晨跳机之后没自动恢复车间温度从设定的23摄氏度一路飙到29摄氏度以上。铝件热胀冷缩几十毫米的孔径在几度温差下变化就能轻松超过0.02mm的加工公差。这就是根源。这件事让我彻底意识到一个事实精密加工车间里环境和刀具、程序同等重要。温度变化影响材料尺寸湿度变化则影响切削液浓度、工件表面锈蚀、夹具定位面的摩擦力、甚至静电放电导致传感器误动作。过去靠老师傅凭经验感觉闷热了就开空调这套做法在批量生产中已经完全不可靠了。1.2 改造前的痛点靠空调和经验管理车间环境我们车间原本有一套空调系统但完全是有人喊热才开下班就关的状态。问题很明显。第一没人知道环境的实时数值温度湿度都是体感估计第二空调在夜间和凌晨经常停机因为那个时段没有工人上班但机床还在跑自动加工第三没有记录数据一旦出了质量问题根本没法追溯当时的环境条件。那次报废事故之后我花了一周时间统计历史质量报表发现一个规律每年6到9月的高温高湿季节不良率明显比其他季节高出一截主要集中在尺寸超差和表面锈蚀两类问题。高温季节的持续加工中机床主轴热漂移本来就大环境温湿度再一叠加问题就被放大。所以那个年代很多老师傅总说夏天活不好干这句话背后其实是环境因素在起作用。当时我就在想能不能做一个结构简单、成本不高的车间环境监控系统把温度、湿度实时采集起来数据能看、能记录、能报警、最好还能联动空调和除湿机。我在网上搜了一圈工业级的温湿度监控方案很多价格从几千到几万都有但功能和我们的需求不匹配调度复杂而且很多是封闭系统没法自己改。考虑到车间实际条件我决定自己动手搭一套。1.3 立项时的核心诉求不是做个玩具而是能用的系统在决定自建系统之前我把需求写得很明确避免做着做着就变成一个电子爱好者的玩具。第一覆盖区域要够。车间面积大概一千二百平但真正需要精确监控的只有精密加工区大概四百平有三台CNC加工中心、一台精密磨床、一条检测台。我至少需要布置四个监控点分别在三台设备附近和检测区。第二数据要能连续记录。不能只是现场看一个数字我要的是能回溯的历史数据这样将来出现质量问题时可以快速判断环境是否符合工艺要求。第三要有报警能力。超温、超湿都要能提醒最好能联动现场声光报警器因为加工区的噪音比较大普通报警声很容易被忽略。第四成本和开发周期要可控。整套设备加上传感器预算不超过三千块从选型到上线不超过两周。这套诉求定下来之后方向就非常清晰了用STM32F1系列单片机做数据采集终端配DHT11温湿度传感器作为测量元件通过RS485或者Wi-Fi把数据汇聚到上位机最终形成一套带历史记录和报警功能的小型环境监控网络。2. DHT11 STM32F1为什么这套低成本方案撑得起车间监控2.1 DHT11的测量原理与数据格式很多人一听到DHT11就摇头觉得它精度太低、响应太慢、不适合工业现场。这个说法一半对一半不对。DHT11确实不是计量级传感器温度精度正负两摄氏度湿度精度正负百分之五相对湿度这个精度拿去校验实验室恒温恒湿箱肯定不行。但拿去做车间环境趋势监控它完全够用。我们要搞清楚一件事车间环境监控的关键不是绝对精度而是漂移趋势和相对变化。我关心的不是现在到底是23.0还是23.6摄氏度而是今天的加工环境跟昨天相比稳不稳定有没有异常走高。DHT11虽然绝对精度不高但它的重复性和一致性足够好放在同一个位置连续测量数据曲线的趋势是非常可信的。这个思路帮我绕开了很多人纠结的传感器精度不够的坑。DHT11的数据格式是40位一帧依次是八位湿度整数部分、八位湿度小数部分、八位温度整数部分、八位温度小数部分、八位校验和。校验和的算法是前四个字节相加取低八位如果和等于第五个字节就认为数据有效。单总线通信协议一条数据线既被主机拉低发送启动信号又被传感器拉低拉高返回数据位时序要求比较严谨。2.2 STM32F1 HAL库开发效率与稳定性的平衡单片机选择STM32F1的理由说穿了很简单便宜、资料多、稳定、我手头就有最小系统板。一片STM32F103C8T6价格十几块钱主频72MHz外设齐全足够同时接四个DHT11并跑一个串口协议栈。相比之下用Arduino当然能更快把原型跑起来但长期在车间运行STM32的稳定性和抗干扰能力更符合我的偏好。HAL库是我这次开发特别想重点说的。很多老工程师习惯用标准外设库觉得HAL库封装太多、性能损耗大、初始化代码冗长。这个观点放在几年前有一定道理但放到现在的开发环境里HAL库的优势非常明显它对GPIO、定时器、USART的抽象非常统一代码可读性强而且ST官方持续维护出现问题的概率远低于自己手撸寄存器。尤其对DHT11这种单总线器件HAL库的GPIO读写在配置正确的情况下完全够用不需要追求寄存器级操作。开发环境我用的是STM32CubeIDE配合STM32CubeMX做图形化初始化。用CubeMX的好处是能防止漏配时钟和外设特别是在配置定时器做微秒级延时的时候它会帮我把时基模块理清楚。我只需要关心应用逻辑而不是每次新建工程都去核对RCC配置。2.3 为什么不用现成工业级传感器这套方案定下来之后有同事问我市面上有四线制的温湿度变送器输出4-20mA电流信号抗干扰能力更强精度更高为什么不用那个我的回答是预算和部署周期不允许。一个进口的温湿度变送器几百到上千块四个点下来要几千块加上采集模块和组态软件整套系统直接破万。我们车间不是药厂也不是芯片厂对环境的要求还没有苛刻到那个程度。DHT11模块单个几块钱到十几块钱就算坏了随手换一个重新校准下就行。这也是工业现场的一个重要思维控制精度要匹配工艺需求不是越高越好。当然我留了一个升级接口。采样终端和传感器的连接用标准排针加杜邦线传感器的封装是通用的将来如果某台设备附近确实需要更高精度的监控我可以直接把DHT11换成DHT22或者SHT30只需要改一下驱动层的读取函数上层逻辑不用动。这就是把硬件接口和软件层解耦带来的好处。3. 从零搭建整条数据链路传感器接线、驱动开发到数据汇聚3.1 硬件清单与关键接线细节这套系统的东西不多清单如下STM32F103C8T6最小系统板四块分别部署在四个监控点附近DHT11温湿度传感器模块四个4.7kΩ上拉电阻四个如果买的是模块版板载已经带了不用另外加RS485转TTL模块若干用于长距离传输一个USB转RS485适配器接在上位机端工业声光报警器两个DC 5V/2A电源适配器四个最关键的接线细节是DHT11的数据引脚。传感器和STM32之间只有一根数据线这根线必须接一个上拉电阻到VCC阻值通常在4.7kΩ到10kΩ之间。如果省掉这个上拉电阻数据线在空闲状态下会处于不确定电平通信很容易出错。很多新手在这个地方栽跟头打开串口看到的全是乱码十有八九就是上拉电阻没接。安装位置也很重要。我一开始图省事直接把传感器贴在机床电控柜旁边结果读数比车间实际温度高了五六度。后来才意识到电控柜本身就是一个发热源把传感器装在冰柜旁边测环境温度测出来的当然不是真实车间环境。正确的做法是让传感器离设备主体至少两米离地大概一点五米高避免阳光直射和空调出风口直吹这样才能代表加工区域的真实环境水平。3.2 HAL库工程搭建与DHT11驱动移植我用CubeMX搭建工程时主要配置了这几样东西RCC时钟树、一个GPIO用于DHT11的数据通信、三个GPIO用于驱动报警灯和继电器控制、一个USART用于和上位机通信。其中通讯速率是115200波特率数据格式8N1。DHT11的驱动看起来不复杂但有几个坑值得说细一点。整个读取过程分四步第一步主机拉低数据线至少18毫秒然后释放这是给传感器一个启动信号。注意这个高电平持续时间至少要20到40微秒才能让传感器正确响应。第二步传感器收到启动信号后会先拉低80微秒表示响应然后再拉高80微秒准备发送数据。第三步传感器按顺序发送40位数据。每一位的传输方式是一样的拉低50微秒然后拉高拉高持续26到28微秒表示逻辑0拉高持续70微秒表示逻辑1。第四步主机读完40位数据后校验和验证通过才算完成一次有效读取。对应的HAL库代码逻辑大致是这样uint8_t DHT11_ReadByte(void) { uint8_t val 0; for (int i 0; i 8; i) { while (HAL_GPIO_ReadPin(DHT11_PORT, DHT11_PIN) GPIO_PIN_RESET); delay_us(40); if (HAL_GPIO_ReadPin(DHT11_PORT, DHT11_PIN) GPIO_PIN_SET) { val | (1 (7 - i)); while (HAL_GPIO_ReadPin(DHT11_PORT, DHT11_PIN) GPIO_PIN_SET); } } return val; }这段代码的核心逻辑是先等数据线被传感器拉低然后延时40微秒再判断电平。如果此时电平还是高说明这一位是逻辑1否则是逻辑0。判断完这一位之后要等数据线回到低电平才能进入下一位的读取。3.3 相位问题DHT11时序延时为什么要微秒级DHT11时序里对延时精度的要求是比较苛刻的启动信号要大于18毫秒但是读取每一位时判断逻辑1和逻辑0的延时窗口只有几十微秒。HAL库自带的HAL_Delay函数是基于SysTick的毫秒级延时做启动信号没问题但做微秒级延时根本不能用误差太大了。解决办法有两种。第一种是用定时器实现微秒延时函数比如配置TIM4为1微秒计数一次直接读计数寄存器来判断时间。第二种更简单用ST官方的核心库文件里面提供了一个基于DWT外设的delay_us函数初始化一次之后就可以精确微秒延时。我实际用的是第二种因为它不占用额外的定时器资源而且代码移植方便。要注意的是DWT延时的初始化必须在系统时钟配置完成之后调用否则它是不知道CPU主频的。初始化函数里要检查DWT的控制寄存器和周期计数寄存器确保它们被正确开启。这个细节我一开始忽略了导致传感器读数时好时坏排查了两天。另外一个容易踩的坑是读取频率。DHT11的采样周期至少是一秒也就是说你每秒最多读一次。如果你在主循环里疯狂地调用读取函数传感器会忙不过来返回的数据要么是校验失败要么是固定的错误值。我在程序里设置了一个一秒钟的调度标志每过一秒才发起一次读取这样既符合传感器能力也不会给单片机系统带来不必要的负载。3.4 多点部署与数据上传设计四个监控点各有一块STM32F103C8T6它们之间怎么把数据汇聚起来我采用的方案是RS485总线每个节点用一个RS485转TTL模块通过双绞线把四块板子串联到上位机旁边的USB转RS485适配器上。RS485的好处在于传输距离远、抗干扰能力强车间里电磁环境复杂有大功率电机和变频器如果直接用TTL串口拉长线数据误码率会非常高。RS485是差分信号能有效抑制共模干扰距离上百米没问题。通信协议我自定义了一个非常简单的帧格式帧头、地址、温度整数、温度小数、湿度整数、湿度小数、校验和。上位机软件通过地址区分是哪个监控点的数据。帧格式长这样typedef struct { uint8_t header; // 0xAA uint8_t addr; // 节点地址1~4 int8_t temp_int; // 温度整数部分 uint8_t temp_dec; // 温度小数部分 uint8_t humi_int; // 湿度整数部分 uint8_t humi_dec; // 湿度小数部分 uint8_t checksum; // 和校验 } EnvFrame;为了兼容将来可能增加节点帧格式里预留了地址字段四个节点地址对应1到4号传感器。上位机收到一帧数据后先做校验校验通过才更新界面和数据库校验失败就丢弃不影响系统稳定性。4. 报警联动与看板让监控数据真正参与车间管理4.1 阈值设置不要照抄手册要按工艺定传感器部署之后最棘手的问题是报警阈值怎么定。如果直接按照网上搜索到的车间温度推荐23度正负2度湿度45%到65%这类标准去设你会发现报警器天天响因为夏天车间里空调一旦波动湿度很容易跑到70%以上。但报警过于频繁的最终结果就是大家麻木真正异常出了也没人在意。我的做法是拉出一个月的历史质量报表找出质量稳定时段的环境数据区间以这个区间为基础设阈值。比如说我们测试下来铝合金精密加工段温度稳定在22到26摄氏度湿度在40%到60%不良率波动不大。那我就在23到27摄氏度、35%到65%湿度设报警带温度超过27度或者湿度超过65%才报警留出合理的余量。余量太大也不行温度只要超过28度配合连续加工两小时以上的主轴热漂移尺寸很危险所以我给温度报警设了两级第一级超过27度预警提醒工艺员关注第二级超过28.5度直接声光报警并联动空调加大制冷量。湿度方面超过70%要启动除湿机低于30%则要考虑加湿因为太干燥容易产生静电对电子元件和某些塑料件不适合。4.2 报警联动的具体实现报警联动分两路走。第一路是在STM32终端上做本地联动每个终端板卡上留了一个继电器输出引脚我把它接到一个中间继电器上再控制对应的空调外机控制器或者除湿机。当温度或湿度超过阈值时单片机会把继电器吸合强制启动除湿或制冷设备直到环境回落到正常区间后自动断开。第二路是远程报警。STM32终端通过RS485把数据传给上位机上位机会对数据进行实时判断一旦连续三次采样都超过报警阈值就触发声光报警器并发送消息到我的手机。连续三次采样这个条件是为了防止偶然的传感器尖峰数据造成误报。这个设计看似简单实际运行中帮我们挡掉了至少一半的无效报警。报警消息没有用复杂的云平台我用的是一个开放的物联网消息推送接口上位机通过HTTP请求把报警信息推送到手机App。整个集成过程大概一个下午就完成了稳不稳定看网络但大多数情况下挺可靠。如果你不想依赖云服务也可以在上位机本地发短信模块成本稍高但完全自主可控。4.3 数据和不良率的因果对照有了数据记录之后我做的第一件事就是把环境历史数据和质量报表做对照。以前我们只能靠那几天好像很热这种模糊记忆去分析质量波动现在可以把某批零件不良率高发的时间段调出来直接看到当时的温湿度曲线。第一批数据的价值就体现出来了。我在对照中发现有一个时间段的不良率明显偏高当时环境数据显示温度一直在25度附近但湿度从52%一路飙到68%。这个湿度变化之前完全没引起注意因为温度是稳的大家就觉得环境没问题。后来才发现湿度升高导致切削液浓度发生变化润滑效果下降表面粗糙度超标。这个发现让我们意识到环境监控不能只看温度湿度对特定工艺同样致命。数据积累两个月以后我们对车间环境的掌控能力和事故追溯能力完全不一样了。环境正常的时候我们可以大胆地认为工艺条件是稳定的一旦出现质量波动第一步就是查环境数据快速排除或确认环境因素节省了大量排查时间。5. 改造效果复盘不良率降30%是怎么实现的5.1 改造前后的数据对比系统运行四个月后我做了一次完整的复盘。以精密加工区为统计范围改造前的平均不良率大概在2.1%左右改造后四个月的平均不良率降到了1.4%到1.5%之间下降幅度接近30%。这个数字和标题里的结论是一致的但它不是奇迹而是几个因素叠加的结果。第一个因素是异常环境的及时发现。以前空调跳机可能要等到第二天早上工人上班才发现如今凌晨一点温度超限声光报警和手机推送同时触发值班人员通过远程控制系统把空调重新启动一晚上的批次就不会受影响。第二个因素是湿度的主动控制。除湿机接入监控系统后湿度超标时自动启动表面锈蚀和部分材质吸水导致的尺寸膨胀问题明显减少。这一类不良在夏季尤其突出改造前的那个夏天相关不良大概占了总不良的四分之一。第三个因素是质量追溯的准确性。以前遇到不良品只能靠猜现在可以直接查看当时的温湿度曲线。有一次一个批次轻微碰伤看不出是加工问题还是周转问题我查了环境数据当天的温湿度都非常平稳迅速排除环境因素把排查方向转到物流和装夹最后发现是周转箱缓冲垫老化。这种排除法带来的效率提升很难用数字量化但非常真实。5.2 传感器布局的实战经验与常见误报源运行一段时间后我发现传感器布局对数据可靠性影响极大比传感器本身的精度影响大得多。总结几条经验供参考。传感器别装在空调回风口附近。我最初有一个点装在车间立柱旁边正好在空调回风路径上读出来的温度始终比其他区域低两度害得我以为那台空调出了故障。后来移到远离回风口的墙面数据才正常。传感器别装在机床切屑液飞溅能喷到的地方。切削液粘在传感器外壳上会影响湿度测量尤其是油性切削液会在传感器透气膜上形成一层油膜导致湿度响应严重滞后。我给传感器加了一个简单的外壳外壳底部开小孔通风顶部做成倾斜面防止液体滞留。传感器读数的瞬时跳变不一定代表环境有问题。有几次凌晨数据显示温度突然从24度跳到31度我以为是空调坏了跑到现场一看原来是大货车停在车间外墙卸货车灯的热量透过窗户边缘晒到了传感器附近。这种偶发干扰不会影响整体判断但会导致误报。我在上位机程序里加了防抖逻辑连续三次越限才报警过滤了这类假数据。5.3 长期稳定运行的维护清单系统不是搭完就能一劳永逸我这几个月的运行经验整理成一份维护清单分享给打算复制这套系统的朋友。第一每三个月校准一次DHT11。校准方法不用很复杂把传感器和一只精度可靠的水银温度计放在同一个环境里等稳定后对比读数记录偏差。如果偏差超过传感器的指标范围直接换传感器反正成本很低。第二每半年检查一次传感器外壳和透气孔。车间里灰尘大传感器滤网被灰尘堵住以后湿度读数会明显偏低影响联动除湿机的启停判断。第三定期检查RS485总线的终端电阻。布线超过几十米后终端电阻的匹配对信号质量影响很大。我在总线的首尾两端各接了一个120Ω电阻但有一次检修时被同事拆掉没装回去结果上位机频繁丢包。重新装回后通信立即恢复稳定。第四上位机数据库要注意备份。历史数据是整个系统最有价值的部分我用的是轻量级数据库每天自动备份一次保留最近半年的数据。现在这套数据库里存了好几个完整季节的数据以后再做工艺分析那就是最真实的第一手资料。5.4 下一步的扩展方向这套车间环境监控系统做了一期工程之后我明显感觉到它带来的不只是不良率的下降更重要的是改变了整个团队对待车间环境的观念。以前大家觉得环境是辅助因素现在工艺员会主动看监控曲线排产时也会避开午后高温时段。这个观念转变的价值有时候比监控系统本身还大。后续我想做的扩展有三个方向。第一个是把刀补参数和环境数据做关联探索能否根据环境温度自动补偿刀具半径进一步压缩尺寸波动第二个是增加更多的环境参数比如粉尘浓度和风速因为部分设备对粉尘也很敏感第三个是把监控数据接入车间MES系统让每批零件在流转时都能附带加工时段的环境记录将来客户要追溯信息直接导出即可。其实这套系统的技术门槛并不高核心就是DHT11的驱动、STM32F1的稳定运行、加上一套合理的报警策略。真正的难点在于想清楚你要用数据解决什么问题以及怎么把数据和现场管理结合起来。对我个人来说最大的收获是学会了用系统思维看待车间里那些看似不可控的因素。环境不稳定不是因为车间条件差而是因为没有人去量化和干预它。用一个低成本的自制系统去解决一个看似高大上的质量问题这件事本身就很有成就感。
基于STM32与DHT11的车间环境监控系统搭建实践
1. 一次批量报废让我决定给车间上环境监控1.1 精密加工里温度和湿度到底动了什么去年夏天我们车间最忙的一周出了件让我印象极其深刻的事三批铝合金零件连续出现尺寸超差而且超差的方向完全一致全部往负偏差跑。这个零件是配合件孔径要求在0.02mm范围内结果批量报废了四十多件耽误了后端装配进度。排查了很久刀具没问题装夹没问题程序也对。后来查阅机床日志和空调运行记录才发现那几天气温连续超过38摄氏度车间的两台工业空调有一台在凌晨跳机之后没自动恢复车间温度从设定的23摄氏度一路飙到29摄氏度以上。铝件热胀冷缩几十毫米的孔径在几度温差下变化就能轻松超过0.02mm的加工公差。这就是根源。这件事让我彻底意识到一个事实精密加工车间里环境和刀具、程序同等重要。温度变化影响材料尺寸湿度变化则影响切削液浓度、工件表面锈蚀、夹具定位面的摩擦力、甚至静电放电导致传感器误动作。过去靠老师傅凭经验感觉闷热了就开空调这套做法在批量生产中已经完全不可靠了。1.2 改造前的痛点靠空调和经验管理车间环境我们车间原本有一套空调系统但完全是有人喊热才开下班就关的状态。问题很明显。第一没人知道环境的实时数值温度湿度都是体感估计第二空调在夜间和凌晨经常停机因为那个时段没有工人上班但机床还在跑自动加工第三没有记录数据一旦出了质量问题根本没法追溯当时的环境条件。那次报废事故之后我花了一周时间统计历史质量报表发现一个规律每年6到9月的高温高湿季节不良率明显比其他季节高出一截主要集中在尺寸超差和表面锈蚀两类问题。高温季节的持续加工中机床主轴热漂移本来就大环境温湿度再一叠加问题就被放大。所以那个年代很多老师傅总说夏天活不好干这句话背后其实是环境因素在起作用。当时我就在想能不能做一个结构简单、成本不高的车间环境监控系统把温度、湿度实时采集起来数据能看、能记录、能报警、最好还能联动空调和除湿机。我在网上搜了一圈工业级的温湿度监控方案很多价格从几千到几万都有但功能和我们的需求不匹配调度复杂而且很多是封闭系统没法自己改。考虑到车间实际条件我决定自己动手搭一套。1.3 立项时的核心诉求不是做个玩具而是能用的系统在决定自建系统之前我把需求写得很明确避免做着做着就变成一个电子爱好者的玩具。第一覆盖区域要够。车间面积大概一千二百平但真正需要精确监控的只有精密加工区大概四百平有三台CNC加工中心、一台精密磨床、一条检测台。我至少需要布置四个监控点分别在三台设备附近和检测区。第二数据要能连续记录。不能只是现场看一个数字我要的是能回溯的历史数据这样将来出现质量问题时可以快速判断环境是否符合工艺要求。第三要有报警能力。超温、超湿都要能提醒最好能联动现场声光报警器因为加工区的噪音比较大普通报警声很容易被忽略。第四成本和开发周期要可控。整套设备加上传感器预算不超过三千块从选型到上线不超过两周。这套诉求定下来之后方向就非常清晰了用STM32F1系列单片机做数据采集终端配DHT11温湿度传感器作为测量元件通过RS485或者Wi-Fi把数据汇聚到上位机最终形成一套带历史记录和报警功能的小型环境监控网络。2. DHT11 STM32F1为什么这套低成本方案撑得起车间监控2.1 DHT11的测量原理与数据格式很多人一听到DHT11就摇头觉得它精度太低、响应太慢、不适合工业现场。这个说法一半对一半不对。DHT11确实不是计量级传感器温度精度正负两摄氏度湿度精度正负百分之五相对湿度这个精度拿去校验实验室恒温恒湿箱肯定不行。但拿去做车间环境趋势监控它完全够用。我们要搞清楚一件事车间环境监控的关键不是绝对精度而是漂移趋势和相对变化。我关心的不是现在到底是23.0还是23.6摄氏度而是今天的加工环境跟昨天相比稳不稳定有没有异常走高。DHT11虽然绝对精度不高但它的重复性和一致性足够好放在同一个位置连续测量数据曲线的趋势是非常可信的。这个思路帮我绕开了很多人纠结的传感器精度不够的坑。DHT11的数据格式是40位一帧依次是八位湿度整数部分、八位湿度小数部分、八位温度整数部分、八位温度小数部分、八位校验和。校验和的算法是前四个字节相加取低八位如果和等于第五个字节就认为数据有效。单总线通信协议一条数据线既被主机拉低发送启动信号又被传感器拉低拉高返回数据位时序要求比较严谨。2.2 STM32F1 HAL库开发效率与稳定性的平衡单片机选择STM32F1的理由说穿了很简单便宜、资料多、稳定、我手头就有最小系统板。一片STM32F103C8T6价格十几块钱主频72MHz外设齐全足够同时接四个DHT11并跑一个串口协议栈。相比之下用Arduino当然能更快把原型跑起来但长期在车间运行STM32的稳定性和抗干扰能力更符合我的偏好。HAL库是我这次开发特别想重点说的。很多老工程师习惯用标准外设库觉得HAL库封装太多、性能损耗大、初始化代码冗长。这个观点放在几年前有一定道理但放到现在的开发环境里HAL库的优势非常明显它对GPIO、定时器、USART的抽象非常统一代码可读性强而且ST官方持续维护出现问题的概率远低于自己手撸寄存器。尤其对DHT11这种单总线器件HAL库的GPIO读写在配置正确的情况下完全够用不需要追求寄存器级操作。开发环境我用的是STM32CubeIDE配合STM32CubeMX做图形化初始化。用CubeMX的好处是能防止漏配时钟和外设特别是在配置定时器做微秒级延时的时候它会帮我把时基模块理清楚。我只需要关心应用逻辑而不是每次新建工程都去核对RCC配置。2.3 为什么不用现成工业级传感器这套方案定下来之后有同事问我市面上有四线制的温湿度变送器输出4-20mA电流信号抗干扰能力更强精度更高为什么不用那个我的回答是预算和部署周期不允许。一个进口的温湿度变送器几百到上千块四个点下来要几千块加上采集模块和组态软件整套系统直接破万。我们车间不是药厂也不是芯片厂对环境的要求还没有苛刻到那个程度。DHT11模块单个几块钱到十几块钱就算坏了随手换一个重新校准下就行。这也是工业现场的一个重要思维控制精度要匹配工艺需求不是越高越好。当然我留了一个升级接口。采样终端和传感器的连接用标准排针加杜邦线传感器的封装是通用的将来如果某台设备附近确实需要更高精度的监控我可以直接把DHT11换成DHT22或者SHT30只需要改一下驱动层的读取函数上层逻辑不用动。这就是把硬件接口和软件层解耦带来的好处。3. 从零搭建整条数据链路传感器接线、驱动开发到数据汇聚3.1 硬件清单与关键接线细节这套系统的东西不多清单如下STM32F103C8T6最小系统板四块分别部署在四个监控点附近DHT11温湿度传感器模块四个4.7kΩ上拉电阻四个如果买的是模块版板载已经带了不用另外加RS485转TTL模块若干用于长距离传输一个USB转RS485适配器接在上位机端工业声光报警器两个DC 5V/2A电源适配器四个最关键的接线细节是DHT11的数据引脚。传感器和STM32之间只有一根数据线这根线必须接一个上拉电阻到VCC阻值通常在4.7kΩ到10kΩ之间。如果省掉这个上拉电阻数据线在空闲状态下会处于不确定电平通信很容易出错。很多新手在这个地方栽跟头打开串口看到的全是乱码十有八九就是上拉电阻没接。安装位置也很重要。我一开始图省事直接把传感器贴在机床电控柜旁边结果读数比车间实际温度高了五六度。后来才意识到电控柜本身就是一个发热源把传感器装在冰柜旁边测环境温度测出来的当然不是真实车间环境。正确的做法是让传感器离设备主体至少两米离地大概一点五米高避免阳光直射和空调出风口直吹这样才能代表加工区域的真实环境水平。3.2 HAL库工程搭建与DHT11驱动移植我用CubeMX搭建工程时主要配置了这几样东西RCC时钟树、一个GPIO用于DHT11的数据通信、三个GPIO用于驱动报警灯和继电器控制、一个USART用于和上位机通信。其中通讯速率是115200波特率数据格式8N1。DHT11的驱动看起来不复杂但有几个坑值得说细一点。整个读取过程分四步第一步主机拉低数据线至少18毫秒然后释放这是给传感器一个启动信号。注意这个高电平持续时间至少要20到40微秒才能让传感器正确响应。第二步传感器收到启动信号后会先拉低80微秒表示响应然后再拉高80微秒准备发送数据。第三步传感器按顺序发送40位数据。每一位的传输方式是一样的拉低50微秒然后拉高拉高持续26到28微秒表示逻辑0拉高持续70微秒表示逻辑1。第四步主机读完40位数据后校验和验证通过才算完成一次有效读取。对应的HAL库代码逻辑大致是这样uint8_t DHT11_ReadByte(void) { uint8_t val 0; for (int i 0; i 8; i) { while (HAL_GPIO_ReadPin(DHT11_PORT, DHT11_PIN) GPIO_PIN_RESET); delay_us(40); if (HAL_GPIO_ReadPin(DHT11_PORT, DHT11_PIN) GPIO_PIN_SET) { val | (1 (7 - i)); while (HAL_GPIO_ReadPin(DHT11_PORT, DHT11_PIN) GPIO_PIN_SET); } } return val; }这段代码的核心逻辑是先等数据线被传感器拉低然后延时40微秒再判断电平。如果此时电平还是高说明这一位是逻辑1否则是逻辑0。判断完这一位之后要等数据线回到低电平才能进入下一位的读取。3.3 相位问题DHT11时序延时为什么要微秒级DHT11时序里对延时精度的要求是比较苛刻的启动信号要大于18毫秒但是读取每一位时判断逻辑1和逻辑0的延时窗口只有几十微秒。HAL库自带的HAL_Delay函数是基于SysTick的毫秒级延时做启动信号没问题但做微秒级延时根本不能用误差太大了。解决办法有两种。第一种是用定时器实现微秒延时函数比如配置TIM4为1微秒计数一次直接读计数寄存器来判断时间。第二种更简单用ST官方的核心库文件里面提供了一个基于DWT外设的delay_us函数初始化一次之后就可以精确微秒延时。我实际用的是第二种因为它不占用额外的定时器资源而且代码移植方便。要注意的是DWT延时的初始化必须在系统时钟配置完成之后调用否则它是不知道CPU主频的。初始化函数里要检查DWT的控制寄存器和周期计数寄存器确保它们被正确开启。这个细节我一开始忽略了导致传感器读数时好时坏排查了两天。另外一个容易踩的坑是读取频率。DHT11的采样周期至少是一秒也就是说你每秒最多读一次。如果你在主循环里疯狂地调用读取函数传感器会忙不过来返回的数据要么是校验失败要么是固定的错误值。我在程序里设置了一个一秒钟的调度标志每过一秒才发起一次读取这样既符合传感器能力也不会给单片机系统带来不必要的负载。3.4 多点部署与数据上传设计四个监控点各有一块STM32F103C8T6它们之间怎么把数据汇聚起来我采用的方案是RS485总线每个节点用一个RS485转TTL模块通过双绞线把四块板子串联到上位机旁边的USB转RS485适配器上。RS485的好处在于传输距离远、抗干扰能力强车间里电磁环境复杂有大功率电机和变频器如果直接用TTL串口拉长线数据误码率会非常高。RS485是差分信号能有效抑制共模干扰距离上百米没问题。通信协议我自定义了一个非常简单的帧格式帧头、地址、温度整数、温度小数、湿度整数、湿度小数、校验和。上位机软件通过地址区分是哪个监控点的数据。帧格式长这样typedef struct { uint8_t header; // 0xAA uint8_t addr; // 节点地址1~4 int8_t temp_int; // 温度整数部分 uint8_t temp_dec; // 温度小数部分 uint8_t humi_int; // 湿度整数部分 uint8_t humi_dec; // 湿度小数部分 uint8_t checksum; // 和校验 } EnvFrame;为了兼容将来可能增加节点帧格式里预留了地址字段四个节点地址对应1到4号传感器。上位机收到一帧数据后先做校验校验通过才更新界面和数据库校验失败就丢弃不影响系统稳定性。4. 报警联动与看板让监控数据真正参与车间管理4.1 阈值设置不要照抄手册要按工艺定传感器部署之后最棘手的问题是报警阈值怎么定。如果直接按照网上搜索到的车间温度推荐23度正负2度湿度45%到65%这类标准去设你会发现报警器天天响因为夏天车间里空调一旦波动湿度很容易跑到70%以上。但报警过于频繁的最终结果就是大家麻木真正异常出了也没人在意。我的做法是拉出一个月的历史质量报表找出质量稳定时段的环境数据区间以这个区间为基础设阈值。比如说我们测试下来铝合金精密加工段温度稳定在22到26摄氏度湿度在40%到60%不良率波动不大。那我就在23到27摄氏度、35%到65%湿度设报警带温度超过27度或者湿度超过65%才报警留出合理的余量。余量太大也不行温度只要超过28度配合连续加工两小时以上的主轴热漂移尺寸很危险所以我给温度报警设了两级第一级超过27度预警提醒工艺员关注第二级超过28.5度直接声光报警并联动空调加大制冷量。湿度方面超过70%要启动除湿机低于30%则要考虑加湿因为太干燥容易产生静电对电子元件和某些塑料件不适合。4.2 报警联动的具体实现报警联动分两路走。第一路是在STM32终端上做本地联动每个终端板卡上留了一个继电器输出引脚我把它接到一个中间继电器上再控制对应的空调外机控制器或者除湿机。当温度或湿度超过阈值时单片机会把继电器吸合强制启动除湿或制冷设备直到环境回落到正常区间后自动断开。第二路是远程报警。STM32终端通过RS485把数据传给上位机上位机会对数据进行实时判断一旦连续三次采样都超过报警阈值就触发声光报警器并发送消息到我的手机。连续三次采样这个条件是为了防止偶然的传感器尖峰数据造成误报。这个设计看似简单实际运行中帮我们挡掉了至少一半的无效报警。报警消息没有用复杂的云平台我用的是一个开放的物联网消息推送接口上位机通过HTTP请求把报警信息推送到手机App。整个集成过程大概一个下午就完成了稳不稳定看网络但大多数情况下挺可靠。如果你不想依赖云服务也可以在上位机本地发短信模块成本稍高但完全自主可控。4.3 数据和不良率的因果对照有了数据记录之后我做的第一件事就是把环境历史数据和质量报表做对照。以前我们只能靠那几天好像很热这种模糊记忆去分析质量波动现在可以把某批零件不良率高发的时间段调出来直接看到当时的温湿度曲线。第一批数据的价值就体现出来了。我在对照中发现有一个时间段的不良率明显偏高当时环境数据显示温度一直在25度附近但湿度从52%一路飙到68%。这个湿度变化之前完全没引起注意因为温度是稳的大家就觉得环境没问题。后来才发现湿度升高导致切削液浓度发生变化润滑效果下降表面粗糙度超标。这个发现让我们意识到环境监控不能只看温度湿度对特定工艺同样致命。数据积累两个月以后我们对车间环境的掌控能力和事故追溯能力完全不一样了。环境正常的时候我们可以大胆地认为工艺条件是稳定的一旦出现质量波动第一步就是查环境数据快速排除或确认环境因素节省了大量排查时间。5. 改造效果复盘不良率降30%是怎么实现的5.1 改造前后的数据对比系统运行四个月后我做了一次完整的复盘。以精密加工区为统计范围改造前的平均不良率大概在2.1%左右改造后四个月的平均不良率降到了1.4%到1.5%之间下降幅度接近30%。这个数字和标题里的结论是一致的但它不是奇迹而是几个因素叠加的结果。第一个因素是异常环境的及时发现。以前空调跳机可能要等到第二天早上工人上班才发现如今凌晨一点温度超限声光报警和手机推送同时触发值班人员通过远程控制系统把空调重新启动一晚上的批次就不会受影响。第二个因素是湿度的主动控制。除湿机接入监控系统后湿度超标时自动启动表面锈蚀和部分材质吸水导致的尺寸膨胀问题明显减少。这一类不良在夏季尤其突出改造前的那个夏天相关不良大概占了总不良的四分之一。第三个因素是质量追溯的准确性。以前遇到不良品只能靠猜现在可以直接查看当时的温湿度曲线。有一次一个批次轻微碰伤看不出是加工问题还是周转问题我查了环境数据当天的温湿度都非常平稳迅速排除环境因素把排查方向转到物流和装夹最后发现是周转箱缓冲垫老化。这种排除法带来的效率提升很难用数字量化但非常真实。5.2 传感器布局的实战经验与常见误报源运行一段时间后我发现传感器布局对数据可靠性影响极大比传感器本身的精度影响大得多。总结几条经验供参考。传感器别装在空调回风口附近。我最初有一个点装在车间立柱旁边正好在空调回风路径上读出来的温度始终比其他区域低两度害得我以为那台空调出了故障。后来移到远离回风口的墙面数据才正常。传感器别装在机床切屑液飞溅能喷到的地方。切削液粘在传感器外壳上会影响湿度测量尤其是油性切削液会在传感器透气膜上形成一层油膜导致湿度响应严重滞后。我给传感器加了一个简单的外壳外壳底部开小孔通风顶部做成倾斜面防止液体滞留。传感器读数的瞬时跳变不一定代表环境有问题。有几次凌晨数据显示温度突然从24度跳到31度我以为是空调坏了跑到现场一看原来是大货车停在车间外墙卸货车灯的热量透过窗户边缘晒到了传感器附近。这种偶发干扰不会影响整体判断但会导致误报。我在上位机程序里加了防抖逻辑连续三次越限才报警过滤了这类假数据。5.3 长期稳定运行的维护清单系统不是搭完就能一劳永逸我这几个月的运行经验整理成一份维护清单分享给打算复制这套系统的朋友。第一每三个月校准一次DHT11。校准方法不用很复杂把传感器和一只精度可靠的水银温度计放在同一个环境里等稳定后对比读数记录偏差。如果偏差超过传感器的指标范围直接换传感器反正成本很低。第二每半年检查一次传感器外壳和透气孔。车间里灰尘大传感器滤网被灰尘堵住以后湿度读数会明显偏低影响联动除湿机的启停判断。第三定期检查RS485总线的终端电阻。布线超过几十米后终端电阻的匹配对信号质量影响很大。我在总线的首尾两端各接了一个120Ω电阻但有一次检修时被同事拆掉没装回去结果上位机频繁丢包。重新装回后通信立即恢复稳定。第四上位机数据库要注意备份。历史数据是整个系统最有价值的部分我用的是轻量级数据库每天自动备份一次保留最近半年的数据。现在这套数据库里存了好几个完整季节的数据以后再做工艺分析那就是最真实的第一手资料。5.4 下一步的扩展方向这套车间环境监控系统做了一期工程之后我明显感觉到它带来的不只是不良率的下降更重要的是改变了整个团队对待车间环境的观念。以前大家觉得环境是辅助因素现在工艺员会主动看监控曲线排产时也会避开午后高温时段。这个观念转变的价值有时候比监控系统本身还大。后续我想做的扩展有三个方向。第一个是把刀补参数和环境数据做关联探索能否根据环境温度自动补偿刀具半径进一步压缩尺寸波动第二个是增加更多的环境参数比如粉尘浓度和风速因为部分设备对粉尘也很敏感第三个是把监控数据接入车间MES系统让每批零件在流转时都能附带加工时段的环境记录将来客户要追溯信息直接导出即可。其实这套系统的技术门槛并不高核心就是DHT11的驱动、STM32F1的稳定运行、加上一套合理的报警策略。真正的难点在于想清楚你要用数据解决什么问题以及怎么把数据和现场管理结合起来。对我个人来说最大的收获是学会了用系统思维看待车间里那些看似不可控的因素。环境不稳定不是因为车间条件差而是因为没有人去量化和干预它。用一个低成本的自制系统去解决一个看似高大上的质量问题这件事本身就很有成就感。