开机前先把“采样周期”这两个数算了后面能少加一个月的班。上个月在客户现场处理一台 200kN 伺服压机的力控震荡折腾了一下午。PID 参数从 P0.5 试到 P20积分从 0.1 调到 0.01该震荡还是震荡客户都开始怀疑是传感器坏了换了两颗新的还是一样。最后把控制任务的实际执行时间录出来一看——1ms 的采样周期里控制算法加通讯加日志要跑 800μsCPU 直接顶到 80%。这哪是参数问题这是采样周期根本没有余量的问题。伺服压机控制系统实时性这件事不是玄学开工之前算两个数就能避免九成的现场拉扯第一个数被控对象最晚多久必须采一次样它由控制带宽、运动速度和精度要求决定第二个数控制任务跑完一圈实际要多久它由 CPU 的执行时间、最坏路径决定。采样周期必须落在两者之间。这篇文章就把这两个数怎么算、怎么测、怎么用讲透适合做伺服压机集成、运动控制系统开发或者正在被压装力控震荡折磨的工程师。1. 先把问题翻译成两个数需求端的“最晚周期”和供给端的“最快周期”1.1 伺服压机的控制回路为什么比液压机更“抠”实时性液压机靠泵和阀系统响应带宽撑死十几赫兹控制回路几毫秒的采样延迟影响不大。伺服压机完全不同伺服电机的电流环带宽就有几百上千赫兹整个机械传动链丝杠、肘杆、曲柄刚性高、惯量小动作的物理过程比液压系统快一个数量级。你在控制器里设的采样周期直接决定位置误差、力超调、下死点重复精度这些客户天天盯着的指标。伺服压机的典型控制架构分三层电流/力矩环在伺服驱动器内部采样周期通常 62.5μs-125μs8kHz-16kHz这部分一般不需要你操心速度环多数驱动器也集成了250μs-1ms位置环和力环这两个在主控制器里500μs-5ms是系统集成商自己写程序设定的。这里有个关键认知位置环和力环的采样周期是你写代码的时候定出来的不是驱动器自带的。所以“采样周期够不够”这个问题问的就是这几个外环周期。而外环周期定不对内环再快也救不回来——外环慢整个闭环带宽就被外环卡死了电机再敏捷也体现不出来。1.2 两个数分别是什么我把标题里的“两个数”明确成下面两件事。第一个数是需求端约束被控对象允许的最长采样间隔记为 T_max。比这个值还慢系统的相位滞后和响应延迟就会大到控制不住——轻则超调超标重则闭环震荡。第二个数是供给端约束控制任务真正跑完一圈的最坏执行时间记为 WCET。比这个值还快意味着 CPU 在采样周期内跑不完下一拍采样来了、上一拍计算还没结束轻则丢拍重则控制输出错位、节拍混乱。所以合理的采样周期 T_s 必须满足WCET 安全余量 ≤ T_s ≤ T_max这个不等式是全文的核心。T_s 比 T_max 大是“响应跟不上”的问题T_s 比 WCET 小是“任务跑不完”的问题。现场绝大多数伺服压机实时性故障都能归到这条不等式被打破。调试时你调 PID、换传感器、改机械都只是在处理表象等式恢复才是根上的事。1.3 为什么不能靠“默认值”和“经验值”我见过不少设备采样周期直接从别的项目复制过来位置环 2ms、力环 5ms。问为什么答“以前都这么干”。在伺服压机上这种做法很危险因为压装工艺千差万别有的要压不锈钢销子接触瞬间力突变以毫秒计有的要压软性材料力上升极慢。同样的 5ms 采样周期前者可能已经过冲 10%后者却绰绰有余。还有个隐藏的坑主控制器的采样周期、驱动器内部周期、总线通讯周期比如 EtherCAT 的同步周期是三条独立的节拍。三条节拍如果没有整数倍关系或者同步抖动大系统就会周期性出现“看着没问题、实际误差忽大忽小”的怪现象。这也是为什么不能只看设计值必须实测节拍是否干净。2. 第一个数这么算从带宽、速度和精度反推最晚采样周期2.1 硬规则一采样频率与闭环带宽的 10-20 倍关系这是数字控制系统流传最广的工程准则f_s ≥ (10~20) × f_BWf_BW 是你期望的闭环带宽。为什么不是奈奎斯特说的 2 倍奈奎斯特定理只保证“采样后信号不混叠”它不保证“数字控制能控稳”。数字采样保持本身会引入约半个采样周期的纯延迟这个延迟折算到带宽频率处的相位滞后大约是Δφ ≈ 180° × f_BW / f_s即 π × f_BW / f_s 弧度f_s 2×f_BW 时滞后 90°加上被控对象本身的相位特性系统几乎没有稳定裕量必振f_s 10×f_BW 时滞后约 18°常规 PID 还能压住f_s 20×f_BW 时滞后约 9°基本可忽略但 CPU 压力翻倍。所以第一个判断很简单先把你要的闭环带宽定下来乘以 10-20就是采样频率下限。想要省 CPU取 10想要更好的相位裕量取 20再高没意义只会白白增加运算负担。2.2 硬规则二采样周期必须“看得清”关键物理过程带宽规则是频域视角工程上我更建议先做一道“时域题”——关键过程持续多久、允许多少误差。伺服压机最典型的三个关键过程直接查下表关键过程典型参数允许延迟/误差对应采样周期上限接触检测快下→加压切换快下速度 300mm/s允许延迟 0.5mm0.5mm ÷ 300mm/s≤ 1.67ms下死点定位接近速度 30mm/s重复精度 ±0.02mm0.02mm ÷ 30mm/s≤ 0.67ms吨位限制保护力上升速率 50kN/ms允许超调 5kN5kN ÷ 50kN/ms≤ 0.1ms最后一行 0.1ms 看着吓人但这是力保护回路的物理极限需求。实际工程里我们不会让主控制器的力环去扛这个事而是在驱动器端做力矩限幅的硬件级保护微秒级响应控制器里的力环只负责工艺力控。这就是多层保护的思路硬实时的事交给硬件软实时的节拍交给控制器的采样周期。上表是数量级估算具体数值要以实际机械特性和工艺要求为准。2.3 完整算例从位置精度和压装速度反推 T_max拿一台 200kN 伺服压机、金属零件压装工艺来算加压阶段压装速度20mm/s位置重复精度要求±0.02mm位置环采样周期上限 0.02mm ÷ 20mm/s 1ms。再考虑位置环闭环带宽。压装定位一般希望位置环带宽做到 10Hz 以上按 10 倍规则采样频率 ≥100Hz即周期 ≤10ms。两个约束取更严的T_max 取 1ms。但 1ms 只是“看得清”的最低要求。算全链路延迟位置环 1ms 驱动器电流环 0.125ms 通讯延迟 0.1ms总计约 1.2ms。在 20mm/s 的速度下这个延迟对应的位置误差约 0.024mm再叠加机械间隙、热漂移已经顶到 ±0.02mm 的指标边缘。所以想要余量就得把位置环提到 500μs或者把接近速度降到 15mm/s 以下。这就是第一个数算完之后的工程取舍你的采样周期选择不是在纸面上选是在为整条链路延迟买单。2.4 别忘了机械谐振频率带宽规则之外还有一个容易漏的因素机械谐振。伺服压机的丝杠、肘杆、机身、模具都有固有谐振频率典型的在 50-200Hz 区间。如果谐振落在闭环带宽附近甚至以内采样周期再合适也会激励出振荡。判据采样频率必须高于“你希望看到并抑制”的最高机械谐振频率的 5 倍以上。比如机身一阶谐振 80Hz没有陷波滤波器的情况下采样频率至少要 400HzT_s ≤ 2.5ms如果有陷波器把谐振压住采样频率可以放宽到带宽的 10 倍。这一点在力控压装中尤其重要。力传感器安装位置、模具刚度都会改变谐振频率换一套模具后原来稳定的参数可能开始抖——很多工程师以为是传感器坏了其实是机械谐振点变了采样或滤波策略没跟着变。3. 第二个数这么算把控制任务放表上跑一遍测出最坏执行时间3.1 什么叫“最坏执行时间WCET”为什么要最坏WCET 是 Worst-Case Execution Time 的缩写指一段代码在“最不利情况”下从头跑到尾需要的最长时间。为什么必须取最坏而不是平均因为采样周期是硬性节拍每一拍都必须跑完任何一拍超时都会造成数据错位或控制输出延迟。平均值好看没用某一次超时就足以让压机在关键时刻抖一下——而“关键时刻”恰恰是快下切换加压、下死点到底的那几个毫秒。哪些因素会造成“非平均”的执行时间中断嵌套通讯中断、编码器中断、DMA 中断同时挤进来缓存 miss控制代码路径跳到冷数据区执行时间瞬间翻几倍浮点异常路径除零保护、饱和处理等分支比正常路径慢得多日志/诊断代码往 SD 卡或上位机发数据时耗时可能增加几十微秒状态机切换不同工艺阶段快下、加压、保压、回程跑的代码路径长度不同。3.2 测量方法GPIO 翻转加示波器是最靠谱的组合我测量 WCET 的习惯做法两步走。第一步在控制任务定时中断的入口把某个空闲 GPIO 拉高出口拉低void ControlISR(void) { GPIO_SetHigh(DBG_PIN); // 入口打点开始计时 // ... 控制算法本体读反馈、算PID、算前馈、写输出 ... GPIO_SetLow(DBG_PIN); // 出口打点结束计时 }第二步用示波器看这个 GPIO 的波形两个相邻上升沿之间的间隔是实际采样周期上升沿到下降沿的宽度是单次执行时间。示波器开余晖模式persistence看脉冲宽度的最大值最方便尖峰不会一闪而过。然后让设备开足马力跑覆盖各种工艺阶段快下、加压、保压、回程、待机观察脉冲宽度的最大值和分布。正常工况下脉冲宽度应该非常稳定抖动在 1-2μs 以内如果看到明显变宽的尖峰那个尖峰的宽度就是 WCET 正在“现身”。也可以用代码方式做统计任务开头读一个自由运行定时器结尾再读一次差值存到环形缓冲区上位机拉出来分析。这个方法能统计长时间运行的最坏值不用一直盯着示波器我更喜欢这个。项目上我通常会在控制器里保留一个“最大执行时间”变量跑一个班次后读出来比示波器记录更客观。下面是一组来自某实际项目的测量数据控制器为 600MHz 工业处理器任务项平均耗时最坏耗时编码器读取SPI4μs12μs力传感器采集 滑动滤波18μs45μs位置环 速度环运算22μs60μs力环 模式切换逻辑15μs50μs通讯刷新EtherCAT 从站28μs80μs日志/监控上送8μs120μs合计95μs367μsWCET 取 367μs。如果采样周期设 1msCPU 占用率 36.7%看起来安全但如果后续加了工况、日志往闪存写最坏时间可能涨到 500μs 以上占用率就过了 50%必须重新评估。3.3 CPU 预算的三条红线工程上我给控制任务划三条线执行时间 采样周期的 30%健康区余量充足可以安心调参30%-50%可用区但必须确认 WCET 测准了、没有隐藏的慢路径超过 50%危险区不管参数多漂亮都建议先处理执行时间的问题。为什么 50% 就危险因为控制任务不是 CPU 唯一的工作。通讯、HMI、上位机数据交互、故障处理都要时间而且这些任务和采样中断存在优先级抢占。如果采样中断自己就占了 50% CPU一个突发总线中断进来轻则丢拍重则整个节拍崩溃。需要强调这里说的 50%指的是“控制相关总负载”采样中断 通讯 数据记录占 CPU 的比例不是单纯某个 ISR 的占用率。很多工程师只看中断本身把数据记录和通讯的开销漏了最后被现场数据打脸。3.4 最容易低估的三处耗时第一处滤波算法。压机的力传感器原始信号往往噪音不小滑动平均、FIR、Butterworth 一层套一层每个采样周期都要重新算。我见过客户把 64 阶 FIR 放在 1ms 中断里光这一个就吃掉 300μsWCET 直接爆表。第二处通讯同步。EtherCAT 这类总线要求控制器在同步信号到来时尽量集中做刷新。如果你的采样中断恰好和总线同步中断撞在一起触发优先级反转执行时间瞬间翻倍。解决思路是错开中断相位或者把两个中断合并成一个统一节拍。第三处日志和 trace。很多人把监测数据上送直接放在控制中断里做字符串格式化printf 系列函数在嵌入式环境里耗时可到几十上百微秒。正确做法中断里只塞环形缓冲区上送交给低优先级任务慢慢发。4. 两个数对不上怎么办多周期拆解、任务分级、该放就放4.1 多周期控制不要所有环都塞在一个中断里如果算完发现矛盾比如 T_max 500μs 但 WCET 400μs怎么都抠不出余量第一个思路是拆周期而不是硬压执行时间。伺服压机的控制天然是多速率的电流环驱动器内部固定 125μs别动速度环驱动器内部250μs-500μs多数驱动器已集成不必进主控制器位置环主控制器1ms 或 500μs力环主控制器1ms 或 2ms。关键技巧力传感器的原始采样用独立的高频任务比如 4-8kHz做只做采集和滤波滤波结果按力环周期更新。这样既保住“看得清”的高频数据又不让高频任务拖累控制运算。你可以理解为高频任务负责“看”低频任务负责“算”两者各司其职。实测下来这个拆分往往能把力环的执行时间砍掉一半以上因为重滤波不再跟控制运算抢同一拍。4.2 任务分级实时任务与非实时任务彻底分开主控制器里的任务按实时性分四档优先级任务周期/触发最高定时中断位置/力控制核心设定的采样周期高总线同步刷新、高速 IO 处理总线周期中数据记录、工艺状态机1-10ms低HMI 通讯、文件、诊断事件/轮询分级之后做两件事。第一中低优先级任务严禁在采样中断里做任何事只能通过队列或双缓冲交付数据。第二给采样中断绑死优先级和总线中断的优先级关系必须实测确认。我自己吃过亏总线中断优先级设得比采样中断高结果总线一忙采样就丢拍位置环出现周期性抖动查了一个星期才定位到是优先级设置问题。4.3 采样周期不是越短越好三个副作用要认账我把这条放在这里是因为往往要等“跑得过快”的坑踩了才明白。采样周期过短会带来三个副作用噪声放大。位置反馈里的量化噪声、力传感器的电噪声采样越快微分项速度估计放得越厉害系统高频发抖数值问题。采样周期太短积分项每拍增量极小浮点舍入误差开始占主导微分项更是放大噪声的重灾区激励未建模动态。采样频率高到一定程度你会“看到”机械谐振、线缆串扰、电源纹波控制环会去响应这些本来不该管的东西。所以在两个数之间的区间里我的习惯是取“能满足需求的最长周期”而不是“CPU 能扛住的最短周期”。给系统留出一点慢反而稳。5. 现场验证不靠感觉靠三个测试确认采样周期合格5.1 测试一实际周期和抖动实测不管设计文档写的是 1ms 还是 500μs先测实际波形。方法还是 GPIO 翻转加示波器这次看上升沿之间的间隔间隔稳定在设计值 ±5μs 以内定时基准健康间隔偶尔突然变大存在高优先级任务长时间占据 CPU常见是总线或 DMA间隔整体漂移定时器基准来自不稳定的时钟源需要换定时器或做锁相。同时把任务执行时间的脉冲宽度和 WCET 对照确认没有超出预算的路径。这一步花半小时能避免后面几天的返工。5.2 测试二阶跃响应和扰动测试采样周期够不够最终要看闭环表现。在压机上做两个测试位置阶跃给一个 5mm 的阶跃指令观察超调量、调节时间、有没有高频抖动力阶跃压装模拟用弹簧负载模拟压装给力指令阶跃记录力的超调和稳定时间。判断标准超调量在工艺允许范围、无持续振荡、恢复时间符合节拍要求。如果出现超调偏大且无论怎么调 PID 都压不住回头检查采样周期是否落在 T_max 附近——相位裕量不足的症状往往不是发散而是“压不住的超调”。5.3 测试三边界工况压测最后把最恶劣的工况跑一遍连续高速冲击比如每分钟 30 次短行程压装、满载吨位保压、同时开着上位机数据记录。期间监控 GPIO 抖动和执行时间确认 WCET 没爆、没有丢拍记录。我一般在项目验收前都会做这个压测并且把“最大执行时间”变量读出存档。客户后续改工艺、换模具如果发现力控变差先对比这个存档值能快速判断是不是采样节拍被新代码污染了。5.4 实战排查力控震荡孕育于采样、暴露于参数最后分享一个印象很深的案例。某客户 300kN 压机做轴承压装力控在 20kN 附近持续振荡振幅 3kNP 参数从 0.3 一路调到 0.05 都压不下去。客户怀疑传感器损坏换了两颗新的还是一样。我到现场先把采样中断的执行时间录出来结果一目了然力环采样周期标称 1ms实际每隔 3-4 拍就出现一次 900μs 的宽脉冲整体节拍被拉得乱七八糟。根因是力环任务里有一段“峰值保持”逻辑每次进入某个工艺分支会触发一次浮点异常处理对零做除法这一下就耗掉 600μs。修复方式很简单把峰值保持逻辑改成整数运算、加保护判断、避开异常分支执行时间从平均 300μs 回到 150μs 以内。再去调 PIDP 参数回到 0.5系统轻松稳定。这个案例我想强调的教训是不要一震荡就调 PID。先确认采样节拍干净、执行时间可控再动手动参数。节拍都不齐参数调得再漂亮也是白搭。伺服压机的实时性从来不是参数问题优先而是采样周期两头夹逼的计算问题优先——这两个数算清楚、测明白至少能让你的排查路径少走一半弯路。 
长河君 · 2026/11/5 6:26:13 · 阅读 1.2k 伺服压机采样周期怎么定？两个数算好避免力控震荡
开机前先把“采样周期”这两个数算了后面能少加一个月的班。上个月在客户现场处理一台 200kN 伺服压机的力控震荡折腾了一下午。PID 参数从 P0.5 试到 P20积分从 0.1 调到 0.01该震荡还是震荡客户都开始怀疑是传感器坏了换了两颗新的还是一样。最后把控制任务的实际执行时间录出来一看——1ms 的采样周期里控制算法加通讯加日志要跑 800μsCPU 直接顶到 80%。这哪是参数问题这是采样周期根本没有余量的问题。伺服压机控制系统实时性这件事不是玄学开工之前算两个数就能避免九成的现场拉扯第一个数被控对象最晚多久必须采一次样它由控制带宽、运动速度和精度要求决定第二个数控制任务跑完一圈实际要多久它由 CPU 的执行时间、最坏路径决定。采样周期必须落在两者之间。这篇文章就把这两个数怎么算、怎么测、怎么用讲透适合做伺服压机集成、运动控制系统开发或者正在被压装力控震荡折磨的工程师。1. 先把问题翻译成两个数需求端的“最晚周期”和供给端的“最快周期”1.1 伺服压机的控制回路为什么比液压机更“抠”实时性液压机靠泵和阀系统响应带宽撑死十几赫兹控制回路几毫秒的采样延迟影响不大。伺服压机完全不同伺服电机的电流环带宽就有几百上千赫兹整个机械传动链丝杠、肘杆、曲柄刚性高、惯量小动作的物理过程比液压系统快一个数量级。你在控制器里设的采样周期直接决定位置误差、力超调、下死点重复精度这些客户天天盯着的指标。伺服压机的典型控制架构分三层电流/力矩环在伺服驱动器内部采样周期通常 62.5μs-125μs8kHz-16kHz这部分一般不需要你操心速度环多数驱动器也集成了250μs-1ms位置环和力环这两个在主控制器里500μs-5ms是系统集成商自己写程序设定的。这里有个关键认知位置环和力环的采样周期是你写代码的时候定出来的不是驱动器自带的。所以“采样周期够不够”这个问题问的就是这几个外环周期。而外环周期定不对内环再快也救不回来——外环慢整个闭环带宽就被外环卡死了电机再敏捷也体现不出来。1.2 两个数分别是什么我把标题里的“两个数”明确成下面两件事。第一个数是需求端约束被控对象允许的最长采样间隔记为 T_max。比这个值还慢系统的相位滞后和响应延迟就会大到控制不住——轻则超调超标重则闭环震荡。第二个数是供给端约束控制任务真正跑完一圈的最坏执行时间记为 WCET。比这个值还快意味着 CPU 在采样周期内跑不完下一拍采样来了、上一拍计算还没结束轻则丢拍重则控制输出错位、节拍混乱。所以合理的采样周期 T_s 必须满足WCET 安全余量 ≤ T_s ≤ T_max这个不等式是全文的核心。T_s 比 T_max 大是“响应跟不上”的问题T_s 比 WCET 小是“任务跑不完”的问题。现场绝大多数伺服压机实时性故障都能归到这条不等式被打破。调试时你调 PID、换传感器、改机械都只是在处理表象等式恢复才是根上的事。1.3 为什么不能靠“默认值”和“经验值”我见过不少设备采样周期直接从别的项目复制过来位置环 2ms、力环 5ms。问为什么答“以前都这么干”。在伺服压机上这种做法很危险因为压装工艺千差万别有的要压不锈钢销子接触瞬间力突变以毫秒计有的要压软性材料力上升极慢。同样的 5ms 采样周期前者可能已经过冲 10%后者却绰绰有余。还有个隐藏的坑主控制器的采样周期、驱动器内部周期、总线通讯周期比如 EtherCAT 的同步周期是三条独立的节拍。三条节拍如果没有整数倍关系或者同步抖动大系统就会周期性出现“看着没问题、实际误差忽大忽小”的怪现象。这也是为什么不能只看设计值必须实测节拍是否干净。2. 第一个数这么算从带宽、速度和精度反推最晚采样周期2.1 硬规则一采样频率与闭环带宽的 10-20 倍关系这是数字控制系统流传最广的工程准则f_s ≥ (10~20) × f_BWf_BW 是你期望的闭环带宽。为什么不是奈奎斯特说的 2 倍奈奎斯特定理只保证“采样后信号不混叠”它不保证“数字控制能控稳”。数字采样保持本身会引入约半个采样周期的纯延迟这个延迟折算到带宽频率处的相位滞后大约是Δφ ≈ 180° × f_BW / f_s即 π × f_BW / f_s 弧度f_s 2×f_BW 时滞后 90°加上被控对象本身的相位特性系统几乎没有稳定裕量必振f_s 10×f_BW 时滞后约 18°常规 PID 还能压住f_s 20×f_BW 时滞后约 9°基本可忽略但 CPU 压力翻倍。所以第一个判断很简单先把你要的闭环带宽定下来乘以 10-20就是采样频率下限。想要省 CPU取 10想要更好的相位裕量取 20再高没意义只会白白增加运算负担。2.2 硬规则二采样周期必须“看得清”关键物理过程带宽规则是频域视角工程上我更建议先做一道“时域题”——关键过程持续多久、允许多少误差。伺服压机最典型的三个关键过程直接查下表关键过程典型参数允许延迟/误差对应采样周期上限接触检测快下→加压切换快下速度 300mm/s允许延迟 0.5mm0.5mm ÷ 300mm/s≤ 1.67ms下死点定位接近速度 30mm/s重复精度 ±0.02mm0.02mm ÷ 30mm/s≤ 0.67ms吨位限制保护力上升速率 50kN/ms允许超调 5kN5kN ÷ 50kN/ms≤ 0.1ms最后一行 0.1ms 看着吓人但这是力保护回路的物理极限需求。实际工程里我们不会让主控制器的力环去扛这个事而是在驱动器端做力矩限幅的硬件级保护微秒级响应控制器里的力环只负责工艺力控。这就是多层保护的思路硬实时的事交给硬件软实时的节拍交给控制器的采样周期。上表是数量级估算具体数值要以实际机械特性和工艺要求为准。2.3 完整算例从位置精度和压装速度反推 T_max拿一台 200kN 伺服压机、金属零件压装工艺来算加压阶段压装速度20mm/s位置重复精度要求±0.02mm位置环采样周期上限 0.02mm ÷ 20mm/s 1ms。再考虑位置环闭环带宽。压装定位一般希望位置环带宽做到 10Hz 以上按 10 倍规则采样频率 ≥100Hz即周期 ≤10ms。两个约束取更严的T_max 取 1ms。但 1ms 只是“看得清”的最低要求。算全链路延迟位置环 1ms 驱动器电流环 0.125ms 通讯延迟 0.1ms总计约 1.2ms。在 20mm/s 的速度下这个延迟对应的位置误差约 0.024mm再叠加机械间隙、热漂移已经顶到 ±0.02mm 的指标边缘。所以想要余量就得把位置环提到 500μs或者把接近速度降到 15mm/s 以下。这就是第一个数算完之后的工程取舍你的采样周期选择不是在纸面上选是在为整条链路延迟买单。2.4 别忘了机械谐振频率带宽规则之外还有一个容易漏的因素机械谐振。伺服压机的丝杠、肘杆、机身、模具都有固有谐振频率典型的在 50-200Hz 区间。如果谐振落在闭环带宽附近甚至以内采样周期再合适也会激励出振荡。判据采样频率必须高于“你希望看到并抑制”的最高机械谐振频率的 5 倍以上。比如机身一阶谐振 80Hz没有陷波滤波器的情况下采样频率至少要 400HzT_s ≤ 2.5ms如果有陷波器把谐振压住采样频率可以放宽到带宽的 10 倍。这一点在力控压装中尤其重要。力传感器安装位置、模具刚度都会改变谐振频率换一套模具后原来稳定的参数可能开始抖——很多工程师以为是传感器坏了其实是机械谐振点变了采样或滤波策略没跟着变。3. 第二个数这么算把控制任务放表上跑一遍测出最坏执行时间3.1 什么叫“最坏执行时间WCET”为什么要最坏WCET 是 Worst-Case Execution Time 的缩写指一段代码在“最不利情况”下从头跑到尾需要的最长时间。为什么必须取最坏而不是平均因为采样周期是硬性节拍每一拍都必须跑完任何一拍超时都会造成数据错位或控制输出延迟。平均值好看没用某一次超时就足以让压机在关键时刻抖一下——而“关键时刻”恰恰是快下切换加压、下死点到底的那几个毫秒。哪些因素会造成“非平均”的执行时间中断嵌套通讯中断、编码器中断、DMA 中断同时挤进来缓存 miss控制代码路径跳到冷数据区执行时间瞬间翻几倍浮点异常路径除零保护、饱和处理等分支比正常路径慢得多日志/诊断代码往 SD 卡或上位机发数据时耗时可能增加几十微秒状态机切换不同工艺阶段快下、加压、保压、回程跑的代码路径长度不同。3.2 测量方法GPIO 翻转加示波器是最靠谱的组合我测量 WCET 的习惯做法两步走。第一步在控制任务定时中断的入口把某个空闲 GPIO 拉高出口拉低void ControlISR(void) { GPIO_SetHigh(DBG_PIN); // 入口打点开始计时 // ... 控制算法本体读反馈、算PID、算前馈、写输出 ... GPIO_SetLow(DBG_PIN); // 出口打点结束计时 }第二步用示波器看这个 GPIO 的波形两个相邻上升沿之间的间隔是实际采样周期上升沿到下降沿的宽度是单次执行时间。示波器开余晖模式persistence看脉冲宽度的最大值最方便尖峰不会一闪而过。然后让设备开足马力跑覆盖各种工艺阶段快下、加压、保压、回程、待机观察脉冲宽度的最大值和分布。正常工况下脉冲宽度应该非常稳定抖动在 1-2μs 以内如果看到明显变宽的尖峰那个尖峰的宽度就是 WCET 正在“现身”。也可以用代码方式做统计任务开头读一个自由运行定时器结尾再读一次差值存到环形缓冲区上位机拉出来分析。这个方法能统计长时间运行的最坏值不用一直盯着示波器我更喜欢这个。项目上我通常会在控制器里保留一个“最大执行时间”变量跑一个班次后读出来比示波器记录更客观。下面是一组来自某实际项目的测量数据控制器为 600MHz 工业处理器任务项平均耗时最坏耗时编码器读取SPI4μs12μs力传感器采集 滑动滤波18μs45μs位置环 速度环运算22μs60μs力环 模式切换逻辑15μs50μs通讯刷新EtherCAT 从站28μs80μs日志/监控上送8μs120μs合计95μs367μsWCET 取 367μs。如果采样周期设 1msCPU 占用率 36.7%看起来安全但如果后续加了工况、日志往闪存写最坏时间可能涨到 500μs 以上占用率就过了 50%必须重新评估。3.3 CPU 预算的三条红线工程上我给控制任务划三条线执行时间 采样周期的 30%健康区余量充足可以安心调参30%-50%可用区但必须确认 WCET 测准了、没有隐藏的慢路径超过 50%危险区不管参数多漂亮都建议先处理执行时间的问题。为什么 50% 就危险因为控制任务不是 CPU 唯一的工作。通讯、HMI、上位机数据交互、故障处理都要时间而且这些任务和采样中断存在优先级抢占。如果采样中断自己就占了 50% CPU一个突发总线中断进来轻则丢拍重则整个节拍崩溃。需要强调这里说的 50%指的是“控制相关总负载”采样中断 通讯 数据记录占 CPU 的比例不是单纯某个 ISR 的占用率。很多工程师只看中断本身把数据记录和通讯的开销漏了最后被现场数据打脸。3.4 最容易低估的三处耗时第一处滤波算法。压机的力传感器原始信号往往噪音不小滑动平均、FIR、Butterworth 一层套一层每个采样周期都要重新算。我见过客户把 64 阶 FIR 放在 1ms 中断里光这一个就吃掉 300μsWCET 直接爆表。第二处通讯同步。EtherCAT 这类总线要求控制器在同步信号到来时尽量集中做刷新。如果你的采样中断恰好和总线同步中断撞在一起触发优先级反转执行时间瞬间翻倍。解决思路是错开中断相位或者把两个中断合并成一个统一节拍。第三处日志和 trace。很多人把监测数据上送直接放在控制中断里做字符串格式化printf 系列函数在嵌入式环境里耗时可到几十上百微秒。正确做法中断里只塞环形缓冲区上送交给低优先级任务慢慢发。4. 两个数对不上怎么办多周期拆解、任务分级、该放就放4.1 多周期控制不要所有环都塞在一个中断里如果算完发现矛盾比如 T_max 500μs 但 WCET 400μs怎么都抠不出余量第一个思路是拆周期而不是硬压执行时间。伺服压机的控制天然是多速率的电流环驱动器内部固定 125μs别动速度环驱动器内部250μs-500μs多数驱动器已集成不必进主控制器位置环主控制器1ms 或 500μs力环主控制器1ms 或 2ms。关键技巧力传感器的原始采样用独立的高频任务比如 4-8kHz做只做采集和滤波滤波结果按力环周期更新。这样既保住“看得清”的高频数据又不让高频任务拖累控制运算。你可以理解为高频任务负责“看”低频任务负责“算”两者各司其职。实测下来这个拆分往往能把力环的执行时间砍掉一半以上因为重滤波不再跟控制运算抢同一拍。4.2 任务分级实时任务与非实时任务彻底分开主控制器里的任务按实时性分四档优先级任务周期/触发最高定时中断位置/力控制核心设定的采样周期高总线同步刷新、高速 IO 处理总线周期中数据记录、工艺状态机1-10ms低HMI 通讯、文件、诊断事件/轮询分级之后做两件事。第一中低优先级任务严禁在采样中断里做任何事只能通过队列或双缓冲交付数据。第二给采样中断绑死优先级和总线中断的优先级关系必须实测确认。我自己吃过亏总线中断优先级设得比采样中断高结果总线一忙采样就丢拍位置环出现周期性抖动查了一个星期才定位到是优先级设置问题。4.3 采样周期不是越短越好三个副作用要认账我把这条放在这里是因为往往要等“跑得过快”的坑踩了才明白。采样周期过短会带来三个副作用噪声放大。位置反馈里的量化噪声、力传感器的电噪声采样越快微分项速度估计放得越厉害系统高频发抖数值问题。采样周期太短积分项每拍增量极小浮点舍入误差开始占主导微分项更是放大噪声的重灾区激励未建模动态。采样频率高到一定程度你会“看到”机械谐振、线缆串扰、电源纹波控制环会去响应这些本来不该管的东西。所以在两个数之间的区间里我的习惯是取“能满足需求的最长周期”而不是“CPU 能扛住的最短周期”。给系统留出一点慢反而稳。5. 现场验证不靠感觉靠三个测试确认采样周期合格5.1 测试一实际周期和抖动实测不管设计文档写的是 1ms 还是 500μs先测实际波形。方法还是 GPIO 翻转加示波器这次看上升沿之间的间隔间隔稳定在设计值 ±5μs 以内定时基准健康间隔偶尔突然变大存在高优先级任务长时间占据 CPU常见是总线或 DMA间隔整体漂移定时器基准来自不稳定的时钟源需要换定时器或做锁相。同时把任务执行时间的脉冲宽度和 WCET 对照确认没有超出预算的路径。这一步花半小时能避免后面几天的返工。5.2 测试二阶跃响应和扰动测试采样周期够不够最终要看闭环表现。在压机上做两个测试位置阶跃给一个 5mm 的阶跃指令观察超调量、调节时间、有没有高频抖动力阶跃压装模拟用弹簧负载模拟压装给力指令阶跃记录力的超调和稳定时间。判断标准超调量在工艺允许范围、无持续振荡、恢复时间符合节拍要求。如果出现超调偏大且无论怎么调 PID 都压不住回头检查采样周期是否落在 T_max 附近——相位裕量不足的症状往往不是发散而是“压不住的超调”。5.3 测试三边界工况压测最后把最恶劣的工况跑一遍连续高速冲击比如每分钟 30 次短行程压装、满载吨位保压、同时开着上位机数据记录。期间监控 GPIO 抖动和执行时间确认 WCET 没爆、没有丢拍记录。我一般在项目验收前都会做这个压测并且把“最大执行时间”变量读出存档。客户后续改工艺、换模具如果发现力控变差先对比这个存档值能快速判断是不是采样节拍被新代码污染了。5.4 实战排查力控震荡孕育于采样、暴露于参数最后分享一个印象很深的案例。某客户 300kN 压机做轴承压装力控在 20kN 附近持续振荡振幅 3kNP 参数从 0.3 一路调到 0.05 都压不下去。客户怀疑传感器损坏换了两颗新的还是一样。我到现场先把采样中断的执行时间录出来结果一目了然力环采样周期标称 1ms实际每隔 3-4 拍就出现一次 900μs 的宽脉冲整体节拍被拉得乱七八糟。根因是力环任务里有一段“峰值保持”逻辑每次进入某个工艺分支会触发一次浮点异常处理对零做除法这一下就耗掉 600μs。修复方式很简单把峰值保持逻辑改成整数运算、加保护判断、避开异常分支执行时间从平均 300μs 回到 150μs 以内。再去调 PIDP 参数回到 0.5系统轻松稳定。这个案例我想强调的教训是不要一震荡就调 PID。先确认采样节拍干净、执行时间可控再动手动参数。节拍都不齐参数调得再漂亮也是白搭。伺服压机的实时性从来不是参数问题优先而是采样周期两头夹逼的计算问题优先——这两个数算清楚、测明白至少能让你的排查路径少走一半弯路。