简介《用与自动化机行业标准SMEMA协议》是一份面向SMT产线设备集成、现场调试与运维人员的PDF技术文档聚焦不同厂商自动化设备之间的通信对接问题帮助读者理解流水线前后主机及搬运设备如何按统一标准完成信号交换与板卡传递。文档围绕电气硬件接口、连接器与电缆接线规则展开说明Pin1至Pin4等信号用途并梳理上游有板可发、下游就绪接收的软件控制逻辑同时讲解出口、入口及中间传感器在T3、T4状态监测、板卡暂存与防碰撞中的作用。资源包仅含1个PDF文件大小约737KB便于随身查阅和现场对照。目前已有1219人学习。内容较适合用于设备联调、产线改造、培训讲义和故障排查时快速核对SMEMA接口定义与传感器配置要点。1. 停线故障八成不在程序里SMEMA 到底约定了什么一条自动化产线联调时最贵的故障常常不是控制程序写错而是两台设备之间四根线里有一根接反或者一端是源型输出、另一端按漏型输入去接。整线几十台设备来自不同厂商谁都不肯为对方的机箱改自己的接口板于是行业里沉淀出一套最低限度的公共约定——SMEMA 协议。它只干一件事约定板卡在设备之间交接时机械上怎么对齐、电气上用哪几路信号、按什么先后顺序放行。对运维来说这套约定最大的价值是把「接得上」变成一件不需要逐台谈判的事电缆两头一个规格接插件位置固定在机背信号语义写死。但反过来它对想搞懂产线为什么莫名停机的人也是最容易忽略的一层——撞板、叠板、板卡停在半路绝大多数不是上位机逻辑写错而是这四根线的握手条件没满足或者满足了但被误判。搞懂这四根线为什么这么排、传感器为什么这么装比背十本设备手册都管用。2. 电气接口层四芯线为什么只做两根半的握手2.1 母座固定在机背、电缆两头都是公头这套接口在机械上有个很值得琢磨的细节每台设备背面固定安装一个 female connector母座设备之间用一根两端都是 male connector公头的电缆连接。初看只是个接线习惯实际是一条关于「谁承担磨损」的明确分工。设备是资产电缆是耗材。插拔动作带来的针脚磨损、弯针、氧化如果发生在设备端维修就得拆机箱、换接口板停机按小时算发生在电缆端运维从备件柜里抽一根新的换上两分钟的事。所以标准把易损件做成线缆把耐久件固定在机器上。同一条产线几十台设备只要备一种两头公头的电缆就能覆盖任意两台之间的连接备件种类被压到最少——这是典型的运维友好型设计代价是每台设备都必须多一个固定母座。这条约定还隐含了一个排查动作当你怀疑两台设备之间的信号有问题最省事的验证不是去量设备内部而是换一根已知良好的电缆。因为线缆是唯一可快速替换的环节标准在设计时就把「可替换」这个属性留给了故障率最高的部件。2.2 四芯里真正承载语义的只有两路接口是四芯Pin1 到 Pin4 都用上了但真正构成握手的只有两路语义一路叫 Board Available我这有板可发由上游设备输出、下游设备接收另一路叫 Machine Ready我这能接板由下游设备输出、上游设备接收。第三路通常作为信号参考与回路第四路在很多实现里留给 Failed Board失败板语义。输入资料里那句「No need failed board available」说的正是第四路的一个常见取舍这条线只处理正常板流失败板不下线、不触发专门的旁路信号而是走人工挑拣或者由上层系统记录。这么做的直接后果是接口从「三态握手」退化成「两态握手」——上游只关心下游能不能接不再关心下游接的是好板还是坏板。对一条只做正常流的测试组装段来说这省掉了一整套失败板分流逻辑和对应的传感器接线、程序、排查三条线同时变简单。注意Pin 编号到具体信号的映射在不同厂商的设备手册里写法不完全一致有的把输入输出各占两芯做成回读。判断依据不要看针脚号看信号语义是「状态输出」还是「状态输入」。2.3 24V 与光耦隔离为什么值得多花一个器件信号电平最常见的实现是 24V DC输入侧经过光耦隔离。多加一个光耦成本不高但它解决的是自动化产线上最阴的一类问题地电位差。一条线跨几十米各台设备的开关电源各自接地两个「地」之间可能差几百毫伏甚至几伏。信号线一长这个差值就叠加在逻辑电平上轻则误触发重则把输入口打穿。光耦把信号域和地域隔开两边只通过光传递状态共模干扰被切断。这也是为什么排查时不能想当然地拿万用表一端搭在自己机箱地上量对方信号——量出来的值可能根本没有意义。隔离带来的另一个副作用是极性光耦输入侧要么共阳极、要么共阴极对应现场说的「源型」和「漏型」。两台设备如果一边按源型设计、一边按漏型设计线接对了信号也是反的甚至一直为高。这类问题在联调阶段最容易被误判成「下游程序没写对」实际是两边的电气约定没对齐。2.4 2910±10 与 450±10mm 是装配预算不是精度指标机械侧的两个关键尺寸是上下两层输送面的高度基准顶层输送带定位在 2910±10mm下层输送带在 450mm。±10mm 这个公差常被误读成「加工精度要求」其实它是留给装配和调平的预算。板卡在设备之间过渡时靠的是两条皮带对板边的连续支撑。如果两台设备的输送面高度差超过一定值板边会在接缝处被顶起或跌落薄板会翘、厚板会磕。这 10mm 要同时吸收机架焊接变形、地脚调平误差、皮带张紧后的厚度变化、以及设备搬迁后的重新就位偏差。把它理解成「误差的容器」而不是「精度的承诺」现场处理接缝落差时思路就完全不一样——不是去追求更高的加工精度而是把可调的环节地脚、皮带张紧、接驳过渡板调到位。上下两层同时存在的结构通常对应双轨或者上下回流的设计两层各自有独立的输送与传感逻辑。做接线和排查时必须先确认当前信号属于哪一层把上层的 Board Available 接到下层的 Machine Ready 上是联调期最常见的低级错误之一。3. 握手时序Board Available 与 Machine Ready 为什么要保持电平3.1 转移条件的与逻辑协议对「什么时候可以送板」只给了一个条件组合上游有板可发并且下游准备好接收。两个条件同时成立才放行这是纯粹的与逻辑。听起来简单到不值得写进标准但它的价值在于把责任边界划清楚了——上游不为下游的忙闲负责下游也不为上游有没有板负责各自只对外声明自己的状态。这个划分让设备可以独立开发。做测试机的厂商不需要知道下游组装机内部有几个工位、节拍多少秒它只需要在自己有板的时候把 Board Available 拉起来然后等对方的 Machine Ready。反过来组装机只要自己缓冲没满就把 Machine Ready 拉高。双方的接口实现可以完全不同只要这两个电平的语义一致线就能通。3.2 电平信号而不是脉冲掉电、复位、急停时的行为差异如果只从「通知对方」的角度看脉冲信号更省线——发一个上升沿表示「我要送板」收一个上升沿表示「我收到了」。但这套接口选的是电平保持原因藏在异常场景里。电平信号的语义是「我当前处于这个状态」状态持续可见。下游一旦因为急停、缺料、报警而把 Machine Ready 拉低上游立刻能看到这个变化正在等待的送板动作自然中止。脉冲信号则不然它表达的是「刚刚发生过一件事」如果接收方当时正在处理别的事情或者中途掉电重启这个沿就永久丢失了双方对状态的认知出现分叉只能靠超时机制补救。而电平信号在任意一方复位后重新上电读到的就是对方当前的真实状态不需要重放历史。这也是排查时一个很实用的判断依据如果一台设备重启后立刻出现误送板问题通常不在握手逻辑而在于某个输入被强制置位、或者上电瞬间输出默认电平不对。电平接口没有「历史包袱」它只会如实反映当下。3.3 T3/T4用两只传感器把「我以为发出去了」变成可验证握手信号只能证明双方「同意交接」证明不了「板真的过去了」。所以标准在输送路径上规定了两只传感器Outlet Sensor 装在出口侧Inlet Sensor 装在入口侧。板开始移出时出口传感器状态翻转板进入下游时入口传感器状态翻转两者配合用来检查 T3 与 T4 两个时间窗的状态。常见的实现思路是T3 衡量板从离开上游出口传感器、到触发下游入口传感器所花的时间T4 衡量板完全通过入口传感器的时间。这两个时间窗把「信号层面的握手」和「物理层面的移动」对上了账。如果 Board Available 和 Machine Ready 都正常但 T3 超时说明板卡在中途卡住、掉落或者皮带打滑如果 T4 异常说明板没有完全进入下游可能是下游皮带没启动或者板长与传感器位置不匹配。这两个时间窗是整条产线上最有价值的诊断数据可惜现场常常只把它们当作报警条件报完就复位不去看数值分布。真正常态化运维的做法是把 T3/T4 的实测值记下来看趋势某台设备的 T3 从 3.2 秒缓慢涨到 4.8 秒多半是皮带张紧度下降或者过渡板有异物而不是程序问题。3.4 一台设备端口的状态机长什么样把上面这些约束落到代码单台设备的接口端口大致是这样一个状态机。下面这段是示意实现用来把「与逻辑」「电平保持」「超时监控」三件事写清楚具体寄存器映射以设备手册为准。# 单台设备的 SMEMA 端口状态机示意非厂商实现 class SmemaPort: def __init__(self, t3_limit6.0, t4_limit1.5): # 输出侧本机对外声明的两个状态必须保持不能只发一个沿 self.board_available False # 我这有板可发输出 self.machine_ready False # 我这能接板输出 # 输入侧读到的对方状态 self.upstream_available False # 上游有板输入 self.downstream_ready False # 下游就绪输入 # 时间窗参数单位秒按设备手册设定 self.t3_limit t3_limit # 出口传感器到入口传感器的允许耗时 self.t4_limit t4_limit # 板完全通过入口传感器的允许耗时 self.t_out None # 板离开出口传感器的时刻 def can_send(self): # 送板放行条件本机有板 与 下游就绪二者缺一不可 return self.board_available and self.downstream_ready def tick(self, outlet_occluded, inlet_occluded): # 1) 板开始移出记录时刻用于后续 T3 判定 if outlet_occluded and self.t_out is None: self.t_out self.now() # 2) 板触发下游入口计算 T3超限即判定传输异常 if inlet_occluded and self.t_out is not None: t3 self.now() - self.t_out if t3 self.t3_limit: self.raise_fault(T3_TIMEOUT, t3) # 卡板 / 掉板 / 打滑 # 3) 板完全通过入口判定 T4同时清空本次传输记录 if not inlet_occluded and self.t_out is not None: self.t_out None # 4) 输出侧状态必须每周期重算并保持不能依赖上一周期的残留 self.machine_ready self.has_buffer_space() and not self.has_fault()三处关键点。board_available和machine_ready是持续输出而不是一次性置位所以每周期都要重算掉电恢复后读到的才是真状态。can_send()只做与运算不掺入任何节拍逻辑——节拍是设备内部的事接口层不该知道。t_out的置位与清零必须成对出现漏清零会导致下一块板的 T3 从上一块板开始算产生一个永远超时的假报警这种问题在现场非常典型报警只在下游连续进板时出现单块调试永远复现不了。4. 中间传感器一个缓存位如何吸收上下游的节拍差4.1 没有缓存位时产能被最慢工位锁死如果一条线只有出入口两只传感器板卡的行为是「无缝接驳」上游一放行板直接进入下游。此时整线的节拍等于最慢那台设备任何一台慢半拍上游就停在那里等 Machine Ready累积成整线停机。中间传感器的引入改变了这件事。它的位置在输送带中段作用是当下游没有发出就绪信号时把板停在这一段上暂存让上游的出口腾出来。上游把板交出去之后立刻可以做下一片下游什么时候空出来什么时候取。一个缓存位看起来微不足道但它把「两台设备必须同步动作」放松成「两台设备在一个缓存位的窗口内允许异步」节拍抖动被吸收掉了。这种效果在测试段特别明显。测试机的单板耗时本身就有波动不同产品测试项数量不同组装段则是固定节拍。没有缓存位时测试机慢的那一拍会直接传导成整线的等待有缓存位测试机可以连续出两片其中一片暂存在中间段组装段按自己的节奏取。4.2 为什么一条带只允许一个中间传感器标准里那句「Only 1 middle sensor is used in conveyor」是整套设计里最克制的一条。一个中间传感器意味着一个停止位一个停止位意味着一块板。为什么要卡死在「一条带只存一块板」而不是多加几个传感器做成多缓存物理原因是主因。皮带输送面上没有分区板与板之间只有很小的间距。如果允许两块板同时停在这一段上先停的那块会被后到的顶推着往前蹭板边相互挤压薄板会翘曲、板面会刮伤严重的会叠起来。而带面本身没有任何机械挡块能保证「第二块停在这里、第一块停在那里」只有传感器没有挡停机构位置控制就无从谈起。一个停止位是这套纯靠皮带摩擦与传感器定位的方案能做到的上限。第二个原因是排障成本。多缓存需要多套停止逻辑、多组位置判定参数还要处理「板长不一致时如何判断哪块板在哪」的问题。而现场运维最需要的恰恰是简单可预测一条带一块板看到板停在那里就知道是下游没就绪不用猜。提示中间传感器位置一旦调整停止距离参数必须同步重算否则板会停偏。板头越过停止位压到下游入口传感器的情形会被下游误判成「有板进入」而提前启动带子。4.3 停止距离与板长缓存位的物理上限板停在哪里、要提前多久开始减速取决于带速、板重和板长。传感器检测到板头的那一刻启动减速板还会继续滑行一段距离。这段滑行距离加上板长必须落在传感器和下游入口之间的可用空间里。这里有个容易被忽略的约束停止参数通常按最短板、最轻板标定因为小板滑行距离短、容易尽快停住。但长板、厚板、带载具的板惯性大同样的减速曲线下会多滑一段板头就越过了预期停止位。现场出现的「小批量产品跑得好好的换成长板就撞」根子往往在这里——不是逻辑错是物理参数没跟着产品换。合理的做法是把停止距离按最大板重、最长板长核算然后留出余量同时把中间传感器的检测位置尽量往上游侧挪给滑行留空间。如果空间实在不够只能降带速用节拍换稳定这是硬件布局决定的天花板。4.4 三种缓存策略的取舍策略缓存容量产能收益实现复杂度主要风险无中间传感器0无整线等于最慢工位最低只有出入口逻辑任一台慢即整线停抖动直接传导单中间传感器1 块吸收一个节拍周期内的抖动中需停止距离参数板长板重变化后停止位偏移易撞板多传感器多缓存2 块以上理论上可吸收更长抖动高需位置判定与间距控制板上滞留时间变长叠板与工艺暴露风险从表里能看出单缓存不是「折中方案」而是这套纯皮带加传感器架构下的最优点收益已经拿到大部分复杂度和风险还在可控范围。真正需要多缓存的场景通常要换掉整个输送结构加挡停机构或者改用载具那就不是调参数能解决的事了。5. 避坑与排查接线全对却仍然撞板的五种现场5.1 电气与接线类现象一换线后第一块板必撞第二块开始正常。原因多半是上下游方向接反——设备的 Upstream 端口接到了对方的 Upstream 端口两边都在等对方发信号第一块板在超时逻辑触发后被强行放行。解决方式是上电前做强制信号验证把下游的 Board Available 输入端短接到有效电平看上游是否动作30 秒就能分辨方向是否正确不要把这件事留到跑板的时候发现。现象二两台设备都显示 Machine Ready板停在中段不动。常见原因是两边的输出极性相反一端源型一端漏型光耦始终不导通软件读到的电平被上拉电阻维持在一个「看起来像就绪」的中间态。解决办法是断电后用万用表分段量通断、上电后量实际电平确认是 24V 有效还是 0V 有效再统一改跳线或加中间继电器。现象三白天正常夜班偶尔误动作。这类间歇性故障多半和地电位差、变频器干扰有关信号线与动力线捆在同一线槽里走长距离耦合进共模噪声。处理方式是分开走线、加屏蔽层单端接地必要时在输入端并一个小容量滤波电容但要注意滤波会让信号边沿变慢不能加得太大。5.2 时序与传感器类现象四偶尔叠板一天一两次怎么都复现不了。最常见的原因是板上的开孔或者镂空刚好从传感器下方经过对射式光电被穿透检测不到板在。换成漫反射式、或者把传感器位置调整到板面实心区域能解决大部分如果板型太多无法统一就得在停止逻辑里加延时确认让信号必须持续一段时间才被认可。现象五长板产品上线后撞板短板产品一切正常。这是停止距离按小板标定导致的——长板惯性大同样减速曲线下滑行更远板头越过停止位顶到下游。处理办法是把停止距离按最大板长、最大板重重新核算把中间传感器的检测位置往上游侧调整或者在换型工单里把带速作为一个必须同步修改的参数。这五类问题有个共同点都不是「逻辑写错了」而是物理参数、电气约定、产品换型三者没有同步。排查的时候先问一句「最近改了什么」比盯着程序看半天有效得多。6. 标准化的边界SMEMA 为什么故意不规定数据协议把接口翻完会发现一件有意思的事这套约定管了机械高度、管了连接器位置、管了四芯信号的语义和先后顺序却完全没有规定两台设备之间怎么交换数据——没有报文格式没有地址没有校验。它是一套纯硬线握手连一颗处理器都不需要几个继电器就能实现。这不是疏漏是刻意的边界。标准要能被最便宜的设备实现要能让一台二十年前的老设备和今年新买的机器接在一起。一旦规定了数据层标准就绑死了实现方式任何一方升级都要拉着对方一起改兼容性反而崩塌。只规定到「电气语义」这一层各家内部怎么做都行只要对外的两个电平含义一致线就能通。这个取舍的代价也很清楚能保证「接得上」保证不了「跑得快」。产能、节拍、缓存深度、换型切换全在标准之外需要产线集成方自己去算。所以遇到整线产能不达标去翻接口文档是没用的得回到第 4 章那张表看缓存策略和停止参数是不是匹配当前产品。要验证这套接口到底有没有按标准实现我的做法是三步。第一步用强制信号盒其实就是几个开关加 24V模拟下游把 Machine Ready 手动拉高拉低看上游的 Board Available 和送板动作是否跟随这一步验证方向与极性。第二步用逻辑分析仪长时间抓四根线的电平看有没有窄脉冲、掉电复位后的默认电平是否正确这一步能抓到软件看不出来的毛刺。第三步把 T3/T4 的实测值按产品型号记一周看分布和趋势这一步能提前发现皮带老化、传感器偏移这类慢性问题。从那以后我每次上线新设备或者换型都强制先走一遍第一步——一根短接线把下游就绪强制拉高看上游会不会提前送板。这个动作只要半分钟却能一次性暴露方向接反、极性不匹配、上电默认电平错误这三类最常见的翻车。那份接口资料的原始版式里连接器位置、传感器安装点、上下层高度基准都标在图上配合这里讲的时序和状态机一起看现场对着实物找位置会快很多。希望帮到你。本文还有配套的精品资源点击获取
企业数字化 ERP 产品动态
相关推荐
SMEMA协议解析:四芯线握手与产线设备对接避坑 简介:围绕自动化设备行业常用的SMEMA协议,这份PDF文档面向SMT产线设备集成、电气接口调试与运维人员,帮助理解前后主机及外部搬运设备之间的通信规范。内容涉及硬件接口与连接器布置、设备间电缆接线规则、板卡转移的软件控制条件,… · 2026/11/4 13:59:09
Qwen3-TTS-1.7B-Base在昇腾与寒武纪的部署适配与性能实测 语音合成模型从“能跑起来”到“能在国产算力上稳定跑起来”,中间隔着的坑比大多数人预想的要多得多。Qwen3-TTS-1.7B-Base 这个体量的模型,参数量不算夸张,单卡显存占用在合理优化下可以压到比较舒服的区间,但它对算子支持、精度… · 2026/11/4 13:59:09
3 分钟把 Win11 任务栏调回 Win10 样式:ExplorerPatcher 完整配置指南 3 分钟把 Win11 任务栏调回 Win10 样式:ExplorerPatcher 完整配置指南 【免费下载链接】ExplorerPatcher This project aims to enhance the working environment on Windows 项目地址: https://gitcode.com/GitHub_Trending/ex/ExplorerPatcher
升级到 Wind… · 2026/11/4 19:08:31
免安装的免费开源 CAD:SolidCraft,浏览器里画参数化 3D 零件 免安装的免费开源 CAD:SolidCraft,浏览器里画参数化 3D 零件 【免费下载链接】solidcraft SolidCraft: an open-source parametric 3D CAD application built in pure Rust. Desktop, web, and automation through MCP. 项目地址: https://gitcode.com… · 2026/11/4 19:08:31
Whisky 教程:Mac 免费运行 Windows 应用 Whisky 教程:Mac 免费运行 Windows 应用 【免费下载链接】Whisky A modern Wine wrapper for macOS built with SwiftUI 项目地址: https://gitcode.com/gh_mirrors/wh/Whisky
把一个 Windows 的 .exe 安装器拖进 Mac,只会弹一句"无法打开&q… · 2026/11/4 19:08:31
小爱音箱自定义固件刷机实践:从机型核对到智能家居中枢 小爱音箱自定义固件刷机实践:从机型核对到智能家居中枢 【免费下载链接】xiaoai-patch Patching for XiaoAi Speakers (小爱音箱), add custom binaries and open source software. Tested on LX06, LX01, LX05, L09A 项目地址: https://gitcode.com/GitHub_Trend… · 2026/11/4 19:08:31
NapCatQQ 错误处理与容灾机制:3 个参数,让机器人故障后自己好起来 NapCatQQ 错误处理与容灾机制:3 个参数,让机器人故障后自己好起来 【免费下载链接】NapCatQQ Modern protocol-side framework based on NTQQ 项目地址: https://gitcode.com/gh_mirrors/na/NapCatQQ
本文用一次"机器人假死"的故障&… · 2026/11/4 19:08:31
防抖 Debouncing 完整指南:从一次真实卡顿到手写实现 防抖 Debouncing 完整指南:从一次真实卡顿到手写实现 【免费下载链接】30-seconds-of-interviews A curated collection of common interview questions to help you prepare for your next interview. 项目地址: https://gitcode.com/gh_mirrors/30/30-seconds-o… · 2026/11/4 19:07:30
双极步进电机控制实战:DRV8818PWPR与PIC18F86K22驱动调试 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/4 3:16:49
STM32F207ZG + DRV8818PWPR 步进电机驱动实战解析 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/4 6:59:29
DRV8818PWPR+dsPIC30F4013工业级双极步进电机控制方案 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/4 7:02:38
AI辅助技术栈评估:提升研发决策效率60% 1. 项目背景与核心价值技术决策一直是研发团队面临的重大挑战。随着技术生态的快速演进,技术栈的选择、维护和迭代变得愈发复杂。我们团队在过去两年里,先后经历了三次重大技术栈迁移,每次都需要投入大量人力进行技术评估和风险分析。直到去年… · 2026/11/4 0:00:17
从生成Token到直接决策:Jev如何重塑AI Agent工程实践 1. 从"生成文字"到"拍板决策":Jev 到底在解决什么问题大多数人第一次接触大模型,脑子里建立的模型是"输入问题、输出文字"。你问它今天天气怎么样,它给你一段描述;你让它写个周报,它给你… · 2026/11/4 0:00:17
32G统一内存跑大模型:内存账、TPS实测与端云分流 想在一台 32G 统一内存的小主机上把大模型跑成"日常可用",这件事我前后折腾了小半年。标题里说的这台 Mac mini M6,是我们这次讨论的目标平台,具体到手规格以实物为准;但下面这套推算方法和实测思路,对任何统… · 2026/11/4 0:00:17
双极步进电机控制实战:DRV8818PWPR与PIC18F86K22驱动调试 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/4 3:16:49
STM32F207ZG + DRV8818PWPR 步进电机驱动实战解析 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/4 6:59:29
DRV8818PWPR+dsPIC30F4013工业级双极步进电机控制方案 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/4 7:02:38