本文集中了倍福华南同事历年处理F415及18005故障的经验，在此整理发布，以期后来者引以为鉴
内容摘要
1.NC轴故障0x4655(18005)的触发机制2.伺服报警Sync Lost(0xF415)触发机制关键词
4655,18005,F415,Sync Lost,WcState, Data Invalid
适用范围
使用TwinCAT NC控制伺服驱动器时NC轴报警0x4655（18005），同时倍福的伺服驱动器AX5000报警0xF415，或者第三方驱动器报错“同步丢失”。18005和F415，可能是同一个硬件故障导致的分别在EtherCAT主站侧和从站侧触发的报警代码。本文阐述故障触发的机制，列举可能的原因，并提供故障排查的方法和顺序。本文也适用于普通IO从站WcState出现Data Invalid的异常处理。http://www.baclizzy.com.cn/20191022 解析NC轴18005错误及AX5000伺服F415故障/
ftp://baclizzy.com.cn:21/Lizzy的倍福园地/20191022 解析NC轴18005错误及AX5000伺服F415故障/
正文
1 NC轴故障0x4655（18005）的触发机制
1.1 报警信息和相关现象
(1) 故障信息：
Invalid IOdata for more than ‘n’ continuous NC cycles，意即连续若干个NC周期伺服驱动器的数据无效。
(2) 故障现象
NC报18005后CoE Online断掉显示Offline Data：NC报18005（Invalid Data）时，NC轴Online页面显示的当前位置为灰色，伺服的CoE Online就会断掉，只显示Offline Data。需要MC_Reset后，CoE Online才恢复正常。 (3) NC报警的依据
对于EtherCAT伺服，NC自动会通过从站的WcState状态位来检测数据是否有效。
(4) WcState与同步单元SyncUnit的关系
WcState的产生机制与同步单元（SyncUnit）相关。根据主站的配置，每个EtherCAT Frame中包括若干个SyncUnit，其中又包含若干个Slave。Frame经过一个Slave时如果IO刷新失败，该Slave所属SyncUnit下的所有模块WcState都会置为TRUE，即数据无效（Data Invalid）。按TwinCAT的默认设置，一个Frame下的所有Slave都在同一个Sync Unit，所以默认一条EtherCAT网络上的所有伺服都属于同一个Sync Unit，一损俱损。
1.2 什么情况下IO从站会刷新失败
在Frame经过Slave时为什么IO刷新会失败呢？有两个可能性：要么是Frame没来、来晚了，或者数据破坏了，要么是Frame正常但Slave自己出了问题，不能从Frame提取或者插入数据。1.2.1 什么情况下Frame没来？
对于从站来说Frame没来，在主站侧来说就是Frame Lost。这在EtherCAT Online界面可以监视到：
Frame Lost的原因，并不一定是主站没有发送Frame，只要发送了Frame就不会凭空丢失，更多的可能是数据破坏了，因此自破坏点之后的从站收到的都是“不合格”的Frame。根据破坏发生的位置、时间，分类统计在Lost Frames或者Tx/Rx Error的计数器中。对从站来说，都等于是没有收到Frame，这种错误往往是硬件引起的。
1.2.2 什么情况下Frame迟到？
所谓迟到，是指相对于“预定”的时间来说。只有工作在DC Sync Mode下的从站才需要设置Frame到达的“预定”时间。下图表示主站程序、EtherCAT传输、从站程序的时间关
图中的Master就是TwinCAT，Slave就是伺服驱动器。以2ms周期的任务为例，TwinCAT每2ms运算一次，然后发送数据包。伺服也是每2ms从数据包提取一次数据，所以必须确保Frame经过伺服后，伺服才提取数据。反言之，数据包必须在伺服周期开始之前到达。所以主站和从站的运算周期的点必须有所偏移，即上图中的Shift。TwinCAT会自动设置这个Shift值，如果Frame不能在这个Shift之前到达，就叫“迟到”。该从站在本周期就叫刷新失败，反映在WcState上就是 Invalid Data。1.2.3 为什么Slave刷新不了数据？
从站应用程序定期从它的EtherCAT缓存区中提取Frame送来的数据。如果EtherCAT缓存中的数据正常而从站应用程序却无法处理，那一定是从站自己的问题，比如电压不够、工作不稳定，内部芯片问题、干扰问题，诸如此类。
1.3 为什么PLC不报“Invalid IO data”？
为什么总是NC任务报“Invalid IO data”而PLC就不会报这个错呢？因为NC轴出于安全考虑，默认连续3个周期即6ms 时长WcState都无效的话，就禁止电机继续动作。这是由于WcState无效时，NC检测到的伺服状态字已经不能代表伺服的实际状态，继续动作可能有危险。根据实际的工艺要求，也可以禁止NC轴检测WcState，以扩大容错能力。
另一方面，PLC程序需要人为添加对WcState的检测，并编写相应的安全处理程序。因为如果IO模块的输入数据不能如实反应现场传感器的状态，那么PLC代码根据输入数据进行运算并控制输出机构的动作就可能潜藏危险。考虑到PLC程序的实时性要求本来就比NC低，连续无效触发报警的时间限制可以加长。
2 伺服报警Sync Lost（0xF415）的触发机制
说明1：本段文字来源于Beckhoff Infosystem中的AX5000手册。说明2：同样是Sync Lost报警，在倍福AX5000伺服的故障代码是0xF415，在OMRON伺服的故障代码是83，在其它品牌伺服的故障代码又是其它数字。下面的论述均以F415指代此类故障。说明3：从站报告Sync Lost，其实就是主站的Frame没有按时到达或者到达时数据破坏。2.1 EtherCAT 同步的机制
提示：此同步机制也适用于其它带分布时钟的EtherCAT从站，比如第三方伺服。EtherCAT主站发送EtherCAT报文至所有从站。每个从站都有一个专门的EtherCAT报文处理单元，称为EtherCAT从站控制器（ESC）。为了达到较高的定位精度和满足对同心度特性的严格要求，主机和所有连接的伺服驱动器的生成设定值应该保持同步。在EtherCAT系统中，这个同步任务通过分布式时钟（distributed clocks）实现。
2.1.1 EtherCAT Master
TwinCAT生成配置时，System Manager根据TwinCAT项目和ESI文件，对所连接的EtherCAT从站自动完成其分布时钟（DC）参数的基本设置。EtherCAT网络启动时发送Init初始化命令将这些参数传给从站，无须人工干预。应咨询AX5000技术支持才能修改默认设置。2.1.2 EtherCAT slave controller (ESC)
AX5000的EtherCAT 从站控制器 (ESC)根据主站（在TwinCAT）的配置产生两个同步信号(Sync0 和 Sync1)。AX5000的CPU分析这两个同步信号，并与内部控制算地进行同步。2.1.3 Sync0
Sync0信号默认每250us触发一次，如果Sync0触发失败（见F0）, CPU报F414错误。电机按急停减速曲线停止。Sync0 周期只能设置为62.5 μs、125 μs 或 250 μs，否则CPU报F409错误；如果ESC中的Sync0信号没有激活，CPU报F410错误。2.1.4 Sync1
Sync1信号的周期于NC周期决定，它总是Sync0的整数倍。如果Sync1信号不能触发（见F1），CPU也会报F414错误，电机按急停减速曲线停止。Sync1 周期必须是Sync0的整数倍，并且与参数S-0-0001 和 S-0-0002相同，否则CPU报F412错误。如果ESC中的Sync1信号没有激活，CPU报F413错误。2.1.5 End of telegram (EOT)
从站内部的EtherCAT 状态控制器 (ESC) 动态处理EtherCAT报文。ESC检测到报文末尾（EOT）标记后，如果报文是发到本站的，并且没有发生CRC错误，它就将报文内容传输到指定的同步管理器SyncMananger2，紧接着将SyncManager2的状态置为“SyncManagerwritten”。Sync 1触发时，如果SyncManager2状态为“SyncManagerwritten”，AX5000的CPU才会从SyncManager2复制数据到自己的内存区。CPU要求Sync1事件触发时SyncManager2中的数据已经刷新，所以必须在Sync1触发前检测到EOT标记，否则CPU就不会复制数据。如果连续两次Sync1事件触发时都没有复制数据，AX5000就会报F415错误，电机按急停减速曲线停止。由于“抖动”等原因，必须确保在规定时间内接收到新数据。EtherCAT主站必须确保数据及时到达SyncMan2（同步管理器2）。
在上图中，EtherCAT报文从左至后通行，最后一个BIT发送完毕就是EOT标记，左边是正常的情况：EOT标记之后一段时间（DT2）才检测到Sync1脉冲。右边是错误的情况，Sync1脉冲发生时，EOT标记还没到。
2.2 故障示例
AX5000驱动器在运行过程中持续监视设备的实时性，其中一个重要的监视目标就是数据传输链路中所有硬件和软件组件的同步性能。下面通过简单的插图举例说明这个数据传输过程，请重点关注“NC”驱动任务和“PLC”普通逻辑任务。2.2.1 Sample 1
(1) 基本条件
1. TwinCAT控制器的CPU定时器以固定时基发送中断信号 (default: base time = 1 ms)由于PLC计算量的增加或减少，任务占用时间相应增减，因此“I/O update”应设置为“At task begining”，这样就可以消除一个同步错误的隐患。不合理的任务优先级排序，则是另一个同步错误的隐患。 4. 在“I/O Update”之后，生成的数据被传输到TwinCAT IO系统，然后由EtherCAT电报发送到连接的设备。EtherCAT报文穿过每个物理连接的设备，并传递或接收该设备的数据。 5. 任务的优先级决定了它的执行顺序，首先执行高优先级的任务并向TwinCAT IO发送数据，然后TwinCAT IO就会发送EtherCAT报文。当系统里有多个不同周期的任务时，如果优先级排列不合理就容易出现问题，如图所示：
(2) 优先级设置
NC数据需要周期性地传输至驱动器，但在PLC占用计算时间时，就没有数据传输到驱动器。由于优先级较高，PLC任务总是在NC任务之前计算；这些任务在开始点时间“0 ms”相互影响，然后每“6 ms”重复一次，即2x Sync1。驱动器的ESC要求EtherCAT报文在每个Sync1信号（3ms）时都送来NC数据。但是这一点无法保证，因为更高优先级的PLC任务总是先于NC任务计算，所以同步映射（Sync Mapping）时报文发送延迟。这样每6毫秒就会发生一次NC报文延迟，可能导致AX5000中的F415错误。
2.2.2 Sample 2
(1) 基本情况
1. TwinCAT控制器的CPU定时器以固定时基发送中断信号 (default: base time = 1 ms)由于PLC计算量的增加或减少，任务占用时间相应增减，因此“I/O update”应设置为“At task begining”，这样就可以消除一个同步错误的隐患。不合理的任务优先级排序，则是另一个同步错误的隐患。 4. 在“I/O Update”之后，生成的数据被传输到TwinCAT IO系统，然后由EtherCAT电报发送到连接的设备。EtherCAT报文穿过每个物理连接的设备，并传递或接收该设备的数据。 5. 任务的优先级决定了它的执行顺序，首先执行高优先级的任务并向TwinCAT IO发送数据，然后TwinCAT IO就会发送EtherCAT报文。当系统里有多个不同周期的任务时，如果优先级排列不合理就容易出现问题，如图所示： 
(2) 优先级设置
- 假定（NC优先级比PLC高，皆为Sync Mapping并驱动DC从站）:NC任务只处理SyncUnit 1中的设备，同步映射（synchronous mapping）PLC任务只处理SyncUnit 2中的设备，同步映射（synchronous mapping）由于优先级较高，NC任务总是先于PLC执行，并先发送报文；这些任务在开始点时间“0 ms”相互影响，然后每“6 ms”重复一次，即2x Sync1。而驱动器的ESC要求在每次sync1（3ms）时都有一个EtherCAT报文。这在NC提供服务的SyncUnit 1中不是问题，因为高优先级的NC总是以相同周期发送报文，但PLC报文每6毫秒就会出现一次延迟，可能导致SyncUnit 2中的AX5000出现F415错误。
3 现场排故的基本方法和顺序
由于NC轴的故障0x4655（18005）和AX5000的故障0xF415，只是同一个问题在主站侧和从站侧分别引发的报警，以下处理方法适用于这两个报警，也可以用于PLC检测到WcState为Invalid Data的情况。基本内容为：3.1 使用诊断工具分析故障性质
使用TwinCAT集成的EtherCAT诊断界面，可以大致定位故障出于硬件原因或软件原因。 (1) EtherCATOnline
在EtherCAT主站的Online界面可以见到主站和从站硬件故障的计数： 
CRC校验可以看出从站硬件错误，普通模块只有两列，左边的表示入口的CRC错误次数，右边表示出口的CRC校验错误次数。对EL模块来说，左边的E-Bus触点为入口，右边的E-Bus触点为出口。对EtherCAT驱动来说，左进右出上进下出都有可能，需要看从站的说明书。从CRC错误次数的发生位置，可以定位最有可能发生干扰或者故障的地方。如果上图中红框以内的数值都是0，说明硬件没有问题，都是软件故障。 (2) 主站DC Diagnosis
另一个检测通讯质量的工具是主站Advanced Setting中的Distributed Clocks|Diagnosis，又称为Jitter检测： 
上图中，jitter大于500us的Frame突然增加，可以判断是硬件故障。而小于500的Frame各个计数都稳步增加，就是shift time或是PLC等软件设置引起的。 3.2 硬件故障导致EtherCAT Frame出错或丢失
严格说来，这里讲的Frame丢失，是指从站没有接收到“合法”的Frame，包括Frame Lost和Frame Error两种情况。Frame丢失通常是由硬件引起的，包括控制器、网线及接头、IO模块及伺服驱动器等从站，以及电源、屏蔽、外部干扰源。比如EtherCAT接头的4个触点时通时断、有通有断。这种故障常常使用生产状态有关，设备开着容易报错、高速运动容易报错、高温时（夏季白天）容易报错，在最终用户现场生产了几个月甚至一两年后报错。注意：完全拔掉网线，反而不会导致Frame Lost，因为前一个从站可以检测到后面的网线是否拔掉，如果发现走不通就会自动原路返回，持续检测不到Frame的从站会切回Init状态，而不是报同步丢失。3.2.1 硬件故障排查基本要求
(1) 电源
检查控制电源的电压、功率是否满足要求。电压或是功率不够时，有时会报通讯错误。比如AX5000要求的控制电压允许误差+-25%，考虑到开关电源的老化使用一段时间以后，实际输出电压会有所降低，以及从开关电源到驱动器如果线路较长的话，其压降也不可忽视，所以根据经验，调试之初会把开关电源的输出电压调到26.5V。此后每次检查开关电源时，都尽可能调到此值。
(2) 屏蔽和接地
屏蔽、接地不可靠时，容易有EMC干扰。检查驱动器接地是否良好。整个EtherCAT网络的应共用一个接地，否则不同接地之间的环流可以导致通讯数据破坏。 
另外，EtherCAT网线加磁环有助于提高抗干扰能力，第三方伺服的动力线加磁环有助于减少对外部设备的EMC干扰。 (3) 网线和接头
首先要使用专业的工业网线和接头，最好是倍福的预制EtherCAT电缆。如果客户购买倍福电缆和倍福接头自己压线时，要注意屏蔽层要和金属外壳接触牢固。切忌使用廉价网线加水晶头自己制作EtherCAT通讯电缆，如果在排故现场发现这种情况，要特别检查网线是否带屏蔽，屏蔽层是否和接头接触良好。如果条件允许，使用倍福预制网线挨个替换有疑点的网线。检查驱动器网口：是否损坏，接触弹片不够力，变形或是氧化的情况。晃动网线，检查插接是否松动，是否出现报警，更换网线等。3.2.2 软件基本配置检查
(1) Ebus电流是否足够
检查IO模块的EBus电流是否足够，如果模块和驱动都再同一个EtherCAT网络里，某些IO出问题导致EtherCAT数据不能返回主站，所有驱动都会报同步丢失。 (2) 配置文件与实际安装的硬件相符
最简单的方法是重新扫描IO，与项目文件中配置对比是否一致。其实TwinCAT还集成了一个工具“主站的Emergency Scan（紧急扫描）”。使用Emergency Scan可以验证离线配置和在线配置是否一致。方法如下：在TwinCAT Config Mode时，执行Emergency Scan可以发送预定数量的探测数据帧，用于快速测试物理连接的永久硬件问题（设备、电缆或者接头损坏），但是这个方法很难检测到随机干扰。 
如果实际IO模块和从站与配置一致，则上图中最后一列“Quality”总是100 of 100，表示发送100次，成功返回100次。如果为0 of 100，当然表示配置的模块或者从站不存在。如果小于100，表示部分数据包没有成功返回，这个从站多半有问题。3.2.3 软件配置的基本优化
(1) 每个伺服驱动器设置独立同步单元
这是为了排除个别驱动器自己的原因出错时影响其它驱动器也报Data Invalid，而EtherCAT对这些报Data Invalid的从站一视同仁，伤及无辜。 (2) 清除伺服的WcState与NC轴的变量映射
默认NC检测到连接3个SAF周期WcState为TRUE，就触发18005报警。而有的第三方从站，硬件设置的Sync Lost容错次数可能比NC还多，结果伺服还没报警NC就报了。从而NC不再发送新数据（此时NC轴的Online页面看到的当前位置为灰色，伺服的CoE Online页面也只显示Offline数据），引起伺服报警，需要用MC_Reset才能恢复。- Sync Unit的局限性
如果是Frame漏发、延迟或者数据破坏，无论Sync Unit怎样设置，所有从站或者后半部分从站都会IO刷新失败。如果Frame正常而是Slave自己出了问题，那么把每个伺服设置独立同步单元（最好再配合星形拓普和HotConnect设置）就有助于精确定位到故障从站。3.2.4 EtherCAT链路优化
(1) 伺服尽量放在EtherCAT链路靠前
越是靠前，驱动受到IO模块影响的可能性越小，有利无弊。 (2) 最优方案：IO和驱动分开两条EtherCAT网络
在电气设计之初，如果驱动器比较多，而且成本预算和安装空间都允许，推荐让伺服驱动和普通IO分开，各走一条EtherCAT网络。
CX50、CX51、CX20系列EPC除了右侧的内置EtherCAT之外左侧都有两个独立网卡，其中一个就可以用来走EtherCAT带伺服驱动。对于C60、C69等IPC，标配虽有两个独立网口，但是一条用于编程和外部Ethernet通讯，一条用于EtherCAT，如果IO和驱动要分开两条EtherCAT网络，就需要增加CU2508网络倍增器。 (3) 次优方案：尽可能用星形拓普
尽可能用星型（增加EK1122或是CU1128）拓普。3.2.5 其它说明
(1) 主站网卡的问题
控制器网卡或是驱动问题，如果是第三方工控机或是安装了较多其他驱动的控制器，也容易出现问题，不稳定。 (2) 重点检查第1个报Sync Lost的从站
3.3 软件原因导致的EtherCAT Frame迟到
一是EtherCAT主站和从站的Time Shift不够；软件引起的Frame迟到通常不会伴随丢包、TxRxError等累加，并且与设备的生产状态无关，并且越是链路上靠后的从站越容易报错。通常在厂内调试阶段就会发现，而不会在最终用户现场生产了一段时间才报错。 3.3.1 EtherCAT主站和从站的Time Shift优化
所谓Frame“迟到”，是指相对于“预定”的时间来说。只有工作在DC Sync Mode下的从站才需要设置Frame到达的“预定”时间。下图表示主站程序、EtherCAT传输、从站程序的时间关系：
图中的Master就是TwinCAT，Slave就是伺服驱动器。以2ms周期的任务为例，TwinCAT每2ms运算一次，然后发送数据包。伺服也是每2ms从数据包提取一次数据，所以必须确保Frame经过伺服后，伺服才提取数据。反言之，数据包必须在伺服周期开始之前到达。所以主站和从站的运算周期的点必须有所偏移，即上图中的Shift。
对于特定的从站来说，这个Shift由两部分组成：一是主站设置的适用于所有DC从站的偏移，二是个别从站单独设置的“额外”偏移量。二者迭加就是该从站的应用程序起始点相对于主站的偏移时间。在这个时间内，Frame必须出发并到达该DC从站，否则该从站就会报告Sync Lost。- EtherCAT主站的SYNC Shift Time设置EtherCAT主站Advanced Setting的Distributed Clock界面的右下方“SYNCShift Time”参数：
上图中的30%，就是表示所有DC从站的应用周期，必须在主站周期开始后600us才开始（以任务周期2ms为例）。由于NC任务默认是先刷新IO后进行运算，所以NC任务一开始就会发送EtherCAT Frame，只要600us内Frame可以到达最后一个DC从站，Frame就不算迟到。
从站的DC设置中，可以设置自己的“额外”偏移，与主站的Shift Time迭加，就是它相对于主站任务起始点的实际偏移时间。
3.3.2 优先级不合理的解决办法
如前所述，系统中存在多个带DC从站的任务时，Frame会以多个DC任务的最小公倍数周期性“延迟”，如果任务周期短，从站数量多，优先级低的任务发出的Frame就更容易迟到，因而与之同步映射的DC从站就容易报Sync Lost。优先级不合理导致的Sync Lost，从第一次联机调试就会出现，容易发现，也容易解决。方法是： (1) 确保周期短的任务优先级高
确保周期短的任务优先级高，勾选“Auto Priority”可以实现 (2) 多任务驱动从站的优化原则
对于不同周期的任务都要驱动DC从站的情况，延迟几乎无可避免，为此可以做3点优化：c) 或者把低优先级任务的从站单个设置Shift Time，保留足够的时间余量，以备它排在最后执行时其Frame仍能赶在从站要求的时间之前到达。3.3.3 程序计算量波动的解决办法
对于PLC程序，每个周期的计算量波动是正常的。克服计算量波动的影响，要从两个方面进行： (1) 启用I/O at task beginning
在TwinCAT 3中，PLC 任务和 C++ Modules 都不提供“IO at taskbegining”的标记。此时可以使用属性 TcCallAfterOutputUpdate 实现同样的功能：
(2) 确认PLC程序运算没有持续超时
从TwinCAT PLC提供系统变量lastExecTime和cycleTimeExceeded，可以观察PLC任务执行的波动情况。在TC2和TC3中查看这两个变量的方法如下：
TwinCAT3中的任务执行信息：
对于PLC任务，默认是先运算后发送Frame，如果有的周期运算量特别大，可能发送Frame的时间就比平时晚，以致Frame不能在设置的Shift Time之前到达每个DC从站。所以，对于有DC要求的Frame，在PLC任务中设置“IO at task begining”是很重要的，以此避免PLC计算量波动引起的Frame延迟。除了进PLC程序监视lastExecTime，从Task的Online里也能大致看出执行时间的波动情况： 
当cycleTimeExceeded置位1次，Frame就会少发1次，DC从站就有1个周期没有收到Frame。大多数普通模块偶尔少一个Frame是可以接受的，但对于某些敏感的DC从站，或者刚巧在这个周期需要输出的XFC通道，就会有不良后果。通常任务超时（cycleTimeExceeded）发生时，CPU利用率会达达甚至超过Realtime设置的限值，默认80%。所以直接观察CPU利用率，也可以估算是否出现任务超时： 
(3) 一个测试手段：新建Additional Task刷新IO
为了排查PLC运算量波动引起的Frame迟到或者漏发，可以新建一个高优先级、Auto Start的Additional Task来刷新IO，并把需要链接到DC从站的变量置于这个任务下。这样就可以完全排除PLC运算量波动的影响。提示1：如果验证并非PLC运算量波动引起Frame迟到或者丢失，最好恢复原样：删除临时添加的Task，恢复变量链接到PLC任务。提示2：如果不是对Task、Mapping和EtherCAT通讯机制深入了解的用户，请应尽量使用“常规”“默认”的配置。如果要修改，应充分了解这样做的理由，和可能产生的关联结果。 
3.3.4 DC主时钟（Reference Clock）紊乱
如果客户临时修改了硬件配置，比如禁用了作为参考时钟的EtherCAT从站，或者控制器正常运行中单独重启作为参考时钟的EtherCAT从站，就会引发DC时钟紊乱，以至于判断Frame是否准点或者迟到完全失去了依据。检查到是禁用了主时钟，则另外指定主时钟更新配置，重新激活。检查到是主时钟断电重启，则重启EtherCAT主站（掉电重启，或者切换状态OP-Init-OP）
遗留问题
鉴于现场情况千变万化，欢迎反馈您遇到的疑难杂症及处理办法，我将整理更新发布。
用IE浏览器可访问本文的PDF更新完整版：
http://www.baclizzy.com.cn/20191022 解析NC轴18005错误及AX5000伺服F415故障/
按日期查找即可；
示例程序和配套文档推荐用FTP工具下载：
ftp://baclizzy.com.cn:21/Lizzy的倍福园地/20191022 解析NC轴18005错误及AX5000伺服F415故障/
按日期查找即可
喜欢本文？识别二维码，可关注公众号
