4、限位开关与边界保护：上限位/下限位逻辑、软件限位与硬件限位配合、边界条件测试用例设计、异常状态恢复测试

各位做窗帘电机的朋友，咱们今天聊一个非常关键的话题——限位保护。

说实话，我见过太多因为限位没做好导致的故障了。有一次在客户现场，电机直接冲过了机械限位，把窗帘导轨都顶弯了。嗯，从那以后，我对限位逻辑的设计就特别较真。

限位保护，说白了就是给电机画个安全区。上不能打顶，下不能撞底。这个安全区怎么画？怎么保证它牢不可破？咱们一步步拆开看。

4.1 上限位与下限位逻辑

先说说最基本的。限位逻辑分两种：硬件限位和软件限位。

硬件限位，就是物理开关。电机走到头，碰到微动开关或者霍尔传感器，直接切断动力。这个最可靠，但成本高，安装也麻烦。

软件限位，靠程序计数。电机转了多少圈，走了多少脉冲，程序心里有数。到了设定值就停。这个灵活，但怕丢步、怕干扰。

我个人习惯的做法是：硬件限位做最后一道防线，软件限位做日常保护。两者配合，才能万无一失。

来看一个典型的限位逻辑伪代码：

// 限位检测主循环
void LimitCheck(void)
{
    // 1. 硬件限位优先
    if (HARD_LIMIT_UP == ACTIVE) {
        MotorStop();
        SetErrorCode(ERR_HARD_LIMIT_UP);
        return;
    }
    if (HARD_LIMIT_DOWN == ACTIVE) {
        MotorStop();
        SetErrorCode(ERR_HARD_LIMIT_DOWN);
        return;
    }
    
    // 2. 软件限位二次检查
    if (g_softPosition >= g_softLimitUp) {
        MotorStop();
        SetErrorCode(ERR_SOFT_LIMIT_UP);
        return;
    }
    if (g_softPosition <= g_softLimitDown) {
        MotorStop();
        SetErrorCode(ERR_SOFT_LIMIT_DOWN);
        return;
    }
    
    // 3. 正常运转
    MotorRun(g_targetSpeed);
}

注意看顺序：硬件限位先判断，软件限位后判断。为什么？因为硬件限位是物理信号，反应最快，优先级最高。

4.2 软件限位与硬件限位配合

这两者怎么配合？我总结了一个原则：硬件限位是底线，软件限位是警戒线。

举个例子。窗帘导轨总长2米，硬件限位装在1.95米和0.05米的位置。软件限位设在1.90米和0.10米。这样软件限位先起作用，万一软件失效，还有硬件兜底。

你想想看，这个冗余设计是不是很合理？

具体配合策略：

• 正常运行时：软件限位负责日常保护，到达软件限位就减速停止
• 软件限位失效时：硬件限位作为最后一道屏障，直接切断电机电源
• 硬件限位触发后：程序必须记录错误状态，下次上电先检查，不确认安全不允许恢复运行

我曾经在一个项目中，把硬件限位的触发信号同时接到了MCU的中断引脚和电机驱动器的使能引脚。这样即使MCU死机，硬件限位也能直接切断驱动器，电机立刻停。这叫双重保险。

4.3 边界条件测试用例设计

好了，逻辑设计完了，怎么验证？边界测试是重中之重。

我做测试有个习惯：先测正常边界，再测异常边界，最后测极限破坏。一步步来，心里有底。

下面是我常用的测试用例表：

测试项	测试场景	预期结果	备注
TC-01	正常上行到达软件上限位	电机减速停止，位置记录正确	基础功能
TC-02	正常下行到达软件下限位	电机减速停止，位置记录正确	基础功能
TC-03	软件限位失效，触发硬件上限位	电机立即停止，报硬件限位错误	冗余保护
TC-04	软件限位失效，触发硬件下限位	电机立即停止，报硬件限位错误	冗余保护
TC-05	在软件限位附近反复启停	不误触发限位，位置不漂移	抗抖动
TC-06	断电后重新上电，位置丢失	自动寻找限位，重新校准	掉电恢复
TC-07	手动推动窗帘越过限位	检测到位置异常，进入保护	外力干扰
TC-08	连续100次极限位置启停	无累积误差，限位稳定	耐久测试

这里我要特别强调TC-05和TC-08。为什么？因为实际使用中，用户经常在窗帘快到顶的时候反复按开关。如果软件限位处理不好，就会出现「明明没到限位，却报限位错误」的假故障。我遇到过，排查了三天才发现是软件限位的滞回区间设得太小了。

4.4 异常状态恢复测试

最后说说异常恢复。这个很多人容易忽略，但恰恰是用户投诉的重灾区。

异常恢复测试，说白了就是：系统出错了，能不能自己好？怎么好？好了之后会不会留后遗症？

我一般会测这么几种场景：

1. 硬件限位触发后的恢复：电机撞到硬件限位停了，用户按反向按钮，应该能正常离开限位区。但如果用户继续按同向按钮呢？程序应该忽略这个指令，防止电机硬顶。
2. 软件限位触发后的恢复：软件限位触发后，允许用户反向运行。但要注意，反向运行一段距离后，软件限位标志才能清除。我习惯设一个「安全距离」，比如反向走5厘米才清除标志。
3. 掉电恢复：这是最头疼的。电机走到一半突然断电，位置信息丢了。重新上电后怎么办？我的做法是：强制让电机低速运行到硬件限位，重新校准位置。这个过程要告诉用户，比如让指示灯闪烁。
4. 通信中断恢复：如果是联网的窗帘电机，通信断了怎么办？我建议保持当前状态，等待通信恢复。不要自作主张乱动，万一用户正在操作呢？

来看一个异常恢复的代码片段：

// 硬件限位触发后的恢复逻辑
void HardLimitRecovery(void)
{
    // 检查当前错误状态
    if (g_errorCode == ERR_HARD_LIMIT_UP) {
        // 只允许反向（下行）操作
        if (g_userCommand == CMD_DOWN) {
            ClearError();
            MotorRun(SPEED_SLOW);
            // 反向走5cm后清除硬件限位标志
            while (g_softPosition > g_hardLimitUp - SAFE_DISTANCE) {
                Delay(10);
            }
            MotorStop();
            g_hardLimitFlag = FALSE;
        } else {
            // 同向指令忽略
            IgnoreCommand();
        }
    }
}

你看，这里有个细节：反向走的时候，我用了低速。为什么？因为用户可能就在旁边，突然高速启动容易吓到人，也容易造成机械冲击。嗯，这些都是实际项目中踩过的坑。

最后总结一下。限位保护这件事，说难不难，说简单也不简单。关键就三点：

• 硬件限位做底线，软件限位做警戒，两者配合，冗余设计
• 边界测试要全面，正常边界、异常边界、极限破坏，一个都不能少
• 异常恢复要谨慎，能自动恢复的自动恢复，不能自动恢复的要明确提示用户

记住一句话：限位保护做得好，用户投诉少一半。这话是我自己总结的，但确实是真理。

好，这一章就到这里。下一章咱们聊聊窗帘电机的堵转检测和过流保护，那也是个大话题。