企业官网建设流程全解析

在自动化现场调了这么多年设备，我到现在还记得第一次给几十台伺服驱动器挨个刷固件的场景：拆盖板、找调试线、一台一台连电脑、刷完还要核对版本号，一天下来腰都直不起来。后来换了个思路，直接用 EtherCAT 的 FOE 功能，从主站通过网络把固件推送下去，省掉了大量往返和拆装时间。

FOE 的全称是 File over EtherCAT，说白了就是一个跑在 EtherCAT 邮箱通信上的文件传输协议。它最常见也最实用的场景就是给从站设备升级固件，比如伺服驱动器、IO 端子、阀岛、编码器，只要从站固件支持 FOE，就能用这根现成的 EtherCAT 网线把固件刷进去，不需要额外拉线、不需要专用下载器，更不用停机拆设备。

这篇文章不只讲概念，我会把从协议原理、环境准备、TwinCAT 3 界面操作，到 PLC 里用 FB_EcFOEWrite 写远程升级功能块的完整代码，一步一步拆开来讲。适合正在做设备调试、产线维护、或者准备做设备远程运维的工程师参考。

1. 为什么我劝你直接走 EtherCAT FOE，而不是手动刷固件

1.1 手动刷固件的三个痛点

搞自动化和设备维护的，最怕的不是故障本身，而是设备明明没坏，却要为一次版本升级付出大量时间成本。

第一是设备位置和时间成本。产线设备分布在车间各个角落，驱动器装在电柜里，IO 端子排成一排，升级时要把设备停下来，打开电柜，找出调试口，把电脑搬过去，运气不好还得爬到设备底下跪着操作。一次两次没关系，设备一多，时间全花在拆装上。

第二是操作过程容易出低级错误。USB 线接触不良、驱动装错、固件选错版本、刷到一半电脑休眠，这些我都踩过。特别是老旧设备，调试口和版本号五花八门，手一抖刷错版本，轻则多花几个小时回退，重则可能把引导程序弄坏，直接返厂处理。

第三是记录和追溯困难。每次刷完固件，版本号、时间、操作人、设备序列号，要是有记录习惯还好，没有记录习惯，等到设备出了问题，排查了半天才发现是现场固件版本没有统一。这种事最憋屈。后来我换了 FOE 升级方式之后，这些问题得到了很大改善。

1.2 FOE 到底能省什么

EtherCAT 本身是主站和从站之间最正常不过的实时通信网络，但 FOE 的出现让这条网线多了一个“传文件”的能力。它的作用相当于在 EtherCAT 网线上内建了一个迷你 FTP 服务，只不过传输的文件通常是固件、配置或日志。

用 FOE 升级固件，最直接的好处是不需要额外动线、动设备。只要从站还在 EtherCAT 网络上、还能正常通信，就可以通过网络把固件文件直接写到从站的存储区域里。对于分布式 IO、伺服驱动器这种布置在危险或者不方便接触位置的设备，尤其实用。

第二点是可以把升级动作编进 PLC 程序。设备上电后先读一次从站固件版本，版本不对就自动触发 FOE，更新完成再继续运行，整个过程不需要人工干预。如果配合上位机、云平台或者远程运维网关，还能做到远程批量升级，这也符合目前 OTA 远程升级在工业设备领域不断普及的趋势。

第三点是 FOE 不只是从主站向从站“写文件”，还可以反向把从站里的日志、配置、固件备份读出来。碰到设备异常现场又拿不出数据的情况，通过 FOE 直接拉日志，能让排查问题省下非常多的时间。

当然，FOE 本身不是万能的，它适合传输中等大小的文件，比如几百 KB 到几十 MB 的固件镜像。如果动辄数百 MB 甚至 GB 级的大文件，就要考虑换通道了，这个后面我会详细说。

2. FOE 升级前要确认的 4 个条件

2.1 从站支不支持 FOE，怎么确认

不是所有 EtherCAT 从站都支持 FOE，这一点必须放在最前面。

最简单的确认方式是查设备手册。一般的伺服驱动器、功能安全的 IO 模块、阀岛，厂商会在手册里单独写一章“固件更新”或者“Bootloader”，里面明确说明是否支持 FOE。第二个方式是从站 ESI 文件里看，从站的 XML 描述文件中会声明邮箱协议的通讯能力，如果支持 FOE，通常能看到 FOE 相关的标识或者对应邮箱初始化参数。第三个方式更直接，在 TwinCAT 里扫描到设备以后，把从站信息窗口打开，看 Mailbox 一栏是否显示支持 FOE DownLoad/UpLoad。

需要提醒的是，有些从站虽然有邮箱功能，但只支持 CoE（CanOpen over EtherCAT），不支持 FOE。这类设备仍然可以通过对象字典做配置读写，但没法直接传固件文件，想远程升级就要看厂商是否提供了专门的 OEM 升级命令。

2.2 固件文件不是随便拿一个就能用

固件文件表面上看就是一个二进制文件，但实际讲究很多。

首先是格式。不同厂商习惯不同，常见的有 .bin、.hex、.s19、.efw、.mot 等等。.bin 是纯二进制，.hex 和 .s19 往往是带地址信息的文本格式。FOE 传输时一般要求的是二进制的固件镜像，.hex 和 .s19 需要先用厂家的转换工具或者专门的 SRecord 工具转换成 .bin 再传，否则从站收到文件后可能无法识别。

其次是内容。有些从站的固件文件同时包含了 Bootloader 和 Application，有些则只是 Application。如果只刷 Application，一般要求 Bootloader 版本要匹配。刷之前最好对照厂商的版本兼容表，别看到文件名字像就往上刷。

第三是校验。好的固件文件自带 CRC 或者 SHA 校验，从站写入后会自己验证，验证失败会反馈错误。但也有一些老设备不做校验，这时候刷错固件可能直接变砖。所以刷之前做好归档，把固件文件按照设备型号、版本、日期命名，放到专门目录，不要直接丢在桌面。

2.3 TwinCAT 3 主站这边要把环境装对

TwinCAT 3 本身不带现成的 FOE 界面，也不代表装了 TwinCAT 就能直接用，你还需要确认三件事。

第一，Twincat 3 运行时版本和库版本要匹配。虽然本文章里的示例主要基于常见版本，但不同小版本之间的功能块参数会有细微差异。建议在 Package Manager 里检查已安装的 Tc2_EtherCAT、Tc3_EtherCAT 等库。

第二，EtherCAT 主站设备和网卡驱动要安装正确。TwinCAT 安装时会把兼容网卡驱动替换成 TwinCAT 专用驱动，如果你不是在目标机上直接开发，而是在工程机编程，需要先通过 TwinCAT 的“目标浏览器”把程序放到目标机上，并且保证目标机能扫描到 EtherCAT 从站。

第三，AMS NetID 要搞清楚。FB_EcFOEWrite 里有一个 sNetId 参数，填的是 EtherCAT 主站的 AMS NetID，一般就是目标机的 AMS NetID，不是从站的 ID。很多新手在配置远程升级时，会误把从站地址填到 sNetId 里，结果一直超时。

2.4 升级窗口：从站停在什么状态才安全

EtherCAT 从站有明确的状态机：INIT、PREOP、SAFEOP、OP，部分从站还有 BOOTSTRAP 状态。FOE 属于邮箱通信服务，邮箱通信一般从 PREOP 阶段开始就可用，所以理论上在 PREOP 状态下就能刷固件。

但这里有一个关键点：你刷固件的时候，从站最好不要处于 OP 状态。OP 状态下从站正在实时交换过程数据，如果此时数据区被改写或者从站被强制重启，轻则通信断一下，重则轴上直接掉使能，造成安全风险。所以稳妥的做法是先在 PLC 程序里把设备切到安全状态，比如伺服先解除使能、阀门先回到安全位、不需要的过程数据全部停止输出，再把从站的状态切到 PREOP，然后执行 FOE 写入。

还有一类从站更特殊，它要求先通过 CoE 写一个特殊命令，让从站进入“固件下载模式”或者“Bootloader 模式”，之后才能接受 FOE 文件。这个动作一般在手册里有明确说明，常见的是写某个厂商自定义对象，比如 0x2A00 之类的，写完后从站自动断开过程数据，进入引导模式，这时再执行 FOE 写入，完成后再重启从站。

总之，FOE 升级不是一个随随便便就能按下去的按钮，它是一个有明确时序要求的过程。处理不好，轻则升级失败，重则影响产线安全。

3. 先走通不写代码的方式：TwinCAT 3 界面里直接刷固件

3.1 三个步骤在界面中完成升级

如果你现在手里只有一个从站、一个固件文件，想快速验证 FOE 能不能通，最快的办法是用 TwinCAT 3 自带的界面功能，不需要写一行 PLC 代码。

第一步，在 Solution Explorer 中打开你的 EtherCAT 设备，把从站扫描出来，确保它处于在线状态。扫描完成后，设备树里能看到这台从站，状态一般是 PREOP、SAFEOP 或 OP。

第二步，右键点击目标从站节点，选择“Firmware Update”或者“更新固件”。不同版本 TwinCAT 的菜单名称略有差异，有的版本叫“Firmware Update”，有的版本叫“Update Firmware”，功能一样。

第三步，在弹出的对话框里选择固件文件，点击确定。TwinCAT 会自动将你的从站状态切到合适的位置，开始通过 FOE 传输文件，界面会显示进度条。传输完成后，它会提示你重新启动从站。重启后可以重新扫描，右键查看从站的固件版本号，确认是否升级成功。

整个过程大概几分钟，具体时间取决于固件文件大小和网络负载。通常几百 KB 的固件，在标准 EtherCAT 网线上也就是几十秒的事。

3.2 界面升级需要留意的几个细节

界面操作虽然方便，但有几个坑必须提前知道。

一个坑是界面升级只能针对单个从站一个一个点，如果现场有几十台设备，你就要一台一台右键、选择文件、确认，操作还是繁琐。当然，后面我会讲怎么用代码批量跑。

另一个坑是界面升级过程中，TwinCAT 会短暂地把从站状态切走，如果此时你的 PLC 程序还在正常运行，并且程序里还有对这个从站的 IO 操作，就会出现瞬时错误。所以升级前最好把程序停下，或者至少在程序里做一个互锁，确保升级过程中不访问这个从站。

第三个坑是界面升级不一定会校验固件文件是否匹配。TwinCAT 只管通过 FOE 把文件送过去，至于从站能不能识别、能不能写入，是由从站固件决定的。刷完以后如果版本号没变化，大概率是文件格式或者写入地址不对，这时候要从厂商手册里找答案。

界面方式的最大价值不在生产使用，而在验证。我先在公司测试台上用界面方式刷了一次，确认了从站 FOE 功能正常、固件文件没有问题，之后才有信心去写代码。

4. 手写远程升级功能块：FB_EcFOEWrite 完整代码解析

4.1 库的选择与功能块清单

当界面方式验证通过以后，下一步就是把升级逻辑写进 PLC 程序，这样才可以做到自动判断、批量执行、集中管理。

首先要把库引用加上。TwinCAT 3 里和 EtherCAT 操作相关的功能块主要在 Tc2_EtherCAT 库中。如果你在工程中看不到这个库，可以在 Package Manager 里添加 TwinCAT 3 EtherCAT 相关的库。添加完成后，在 PLC 中直接声明 FB_EcFOEWrite、FB_EcFOERead、FB_EcCoESdoWrite 这几个功能块，就可以调用。

这几个功能块分工不太一样：

• FB_EcFOEWrite：把主站侧的数据通过 FOE 写给从站，这是固件升级的核心。
• FB_EcFOERead：从从站读取文件，可以用于读取日志、备份固件。
• FB_EcCoESdoWrite：用来向从站对象字典写入命令，常用于先让从站进入固件下载模式。

我之前第一次写的时候，以为只要用一个 FB_EcFOEWrite 就能搞定一切，实际上不少设备在 FOE 之前都需要一个 CoE 命令“预热”，否则从站根本不会进入等待文件的状态。所以安全起见，把 FB_EcCoESdoWrite 也准备好，根据实际从站手册决定要不要用。

4.2 FB_EcFOEWrite 参数逐个拆解

FB_EcFOEWrite 是 FOE 写入功能块，如果想灵活使用它，必须把它的参数含义彻底搞清楚。我根据常用版本整理了一份参数清单：

sNetId 填的是主站地址，不是从站地址，这一点特别容易搞混。nSlaveAddr 填的是从站在 TwinCAT 设备树里的 EtherCAT 地址，一般可以在从站属性的 EtherCAT 页面里看到。第一台从站通常是 0x1000，第二台是 0x1001，或者按实际显示值来填。

sFile 参数比较有意思，它只是“文件名”，不包含路径。因为 FOE 是从站侧的存储系统，文件名最终由从站固件来解释。也就是说，从站收到文件名后，是按照它自己的规则去找存储位置。所以你传过去的文件名必须和厂商规定的名字一致，比如有的厂家要求固定叫 “firmware.bin”，有的要求带版本号后缀，不能随便起。

cbLen 和 pDataBuf 共同描述待传输的数据来源。实际工程里，固件内容一般有两个来源：一是由上位机或 HMI 从本地读取固件文件，通过接口传给 PLC；二是 PLC 直接读取本地存储介质的文件，写入缓冲区后再触发 FOE。无论哪种方式，要保证在整个 FOE 传输期间，这个缓冲区内容不能被其他任务修改，否则会出现数据不一致，从站校验失败。

4.3 一个可复用的 FB_FirmwareUpgrade 功能块

既然要做远程升级，就别把操作逻辑写在主程序里，强烈建议封装成一个独立的功能块。这一个功能块可以反复调用，每次传入不同的从站地址和文件名，就能批量处理多台设备。

我习惯先定义一个枚举类型，用来表示升级状态：

TYPE E_FW_STATE : ( FW_IDLE := 0, // 空闲 FW_WRITE := 1, // FOE 写入中 FW_DONE := 2, // 升级完成 FW_ERROR := 3 // 升级出错 ); END_TYPE

然后定义功能块：

FUNCTION_BLOCK FB_FirmwareUpgrade VAR_INPUT sNetId : T_AmsNetID; // 主站 AMS NetID nSlaveAddr : DWORD; // 从站地址，如 16#1000 sFileName : STRING(255); // 固件文件名 pFwData : POINTER TO BYTE; // 固件数据缓冲区 cbFwLen : UDINT; // 固件数据长度 bStart : BOOL; // 启动命令 tTimeout : TIME := T#30S; // 超时时间 END_VAR VAR_OUTPUT bBusy : BOOL; // 忙 bDone : BOOL; // 成功完成一次 bError : BOOL; // 错误 hrError : HRESULT; // 错误码 eState : E_FW_STATE; // 当前状态 END_VAR VAR fbFoeWrite : FB_EcFOEWrite; bExecute : BOOL; bWriteDone : BOOL; bWriteError : BOOL; bWriteBusy : BOOL; hrWriteError : HRESULT; bStartPrev : BOOL; END_VAR

功能块的内部状态机如下：

CASE eState OF FW_IDLE: bBusy := FALSE; bDone := FALSE; bError := FALSE; hrError := 0; bExecute := FALSE; // 检测启动上升沿 IF bStart AND NOT bStartPrev THEN bExecute := TRUE; eState := FW_WRITE; END_IF FW_WRITE: bBusy := TRUE; fbFoeWrite( sNetId := sNetId, nSlaveAddr := nSlaveAddr, sFile := sFileName, cbLen := cbFwLen, pDataBuf := pFwData, bExecute := bExecute, tTimeout := tTimeout, bBusy => bWriteBusy, bDone => bWriteDone, bError => bWriteError, hrError => hrWriteError ); // 保持 bExecute 为 TRUE，直到 FOE 执行完成或报错 bExecute := TRUE; IF bWriteDone THEN bExecute := FALSE; bBusy := FALSE; bDone := TRUE; eState := FW_DONE; ELSIF bWriteError THEN bExecute := FALSE; bBusy := FALSE; bError := TRUE; hrError := hrWriteError; eState := FW_ERROR; END_IF FW_DONE: // 等待用户复位 bStart IF NOT bStart THEN eState := FW_IDLE; END_IF FW_ERROR: // 等待用户复位 bStart IF NOT bStart THEN eState := FW_IDLE; END_IF END_CASE // 记录上一周期启动信号 bStartPrev := bStart;

这个功能块把所有和 FOE 交互的细节都封装起来了，上层调用者只需要关注 bStart、bBusy、bDone、bError 这四个信号，非常直观。

4.4 完整调用流程：从版本校验到重启验证

单纯把固件文件“写”进从站，只是升级过程的一半。真正工程化的升级流程，至少包含下面几个步骤：

第一步，读取当前版本。一般在从站对象字典里会有厂商版本号，比如 0x1009、0x1018 或者厂商自定义对象，协议不同对象不同。通过 FB_EcCoESdoRead 先读出来，和期望版本比对，如果版本已经是最新，就跳过升级，避免重复写入。

第二步，切换从站状态。通过 CoE 或状态控制，把从站从 OP 切到 PREOP。如果是特殊设备，再额外发送一个进入 Bootloader 模式的命令。

第三步，调用 FB_FirmwareUpgrade 执行 FOE 写入。

第四步，等待完成后，让从站重新启动。有的从站需要远程掉电重启，有的从站只需要把状态切到 INIT 再回到 OP。TwinCAT 自身也提供了状态切换功能块，可以根据实际设备选择。

第五步，重新读取版本号，校验升级结果。这一步非常重要，不能只看 FOE 报 Done 就认为升级成功，因为有些从站 FOE 写入成功但应用层校验失败，版本号还是旧的。

调用示例可以这样写：

PROGRAM MAIN VAR fbUpgrade : FB_FirmwareUpgrade; stSdoRead : FB_EcCoESdoRead; fwData : ARRAY [1..1024] OF BYTE; // 这个示例只放前 1K 数据 fwLength : UDINT; bCmdStart : BOOL; sCurrentVersion : STRING; END_VAR

具体到某台从站，固件文件内容怎么进入 fwData，取决于你的应用环境。你可以用 TwinCAT 自身的文件读取功能，从本地磁盘读入；也可以从上位机通过 ADS 接口把固件文件下发到 PLC 缓冲区。总体原则是，缓冲区要在调用期间保持一致，不能被中途修改。

4.5 错误处理：别让功能块卡死在现场

远程升级最怕的就是功能块卡在一个中间状态，既没有完成也没有报错，现场人员只能干瞪眼。

我总结了几条经验。

第一，超时时间一定要给够。固件传输不光是网线速度的问题，还包含从站内部 Flash 擦写的时间。有些从站只有在 FOE 数据发送完之后才开始擦写 Flash，这个过程可能持续几十秒，如果超时时间设成 5 秒，基本必超时。我一般会设成 30 秒到 2 分钟，具体看固件大小。

第二，出错之后必须能复位。功能块要允许现场人员按复位按钮或者重新触发 bStart 来回到 IDLE 状态，否则一旦出错，整个流程就僵死了。

第三，错误码要能解析。FB_EcFOEWrite 报错后，hrError 里包含的是 FOE 错误码，比如错误命令、文件不存在、Flash 写入失败等等。拿到错误码后，要记录下来，和厂商错误码表对应，再决定下一步动作。现场最忌讳的是看到 bError 亮了就直接断电重启，这样往往找不到真正的根因。

第四，升级流程和设备运行逻辑要做互锁。功能块内部只管刷固件，但刷之前必须由外层逻辑确认设备已经安全停机。这个互锁做在程序的最外面，千万不要省。

5. 现场踩坑排查：从报错到断电恢复的实操记录

5.1 高频报错与排查思路

我整理了一份高频报错排查表，都是这几年实际用 FOE 升级时遇到的，虽然具体错误码因设备而异，但排查思路是通用的。

这里特别想说一下网线问题。很多现场设备 FOE 升级失败，不是程序问题，而是网线或者接线端子老化，导致链路误码率偏高。升级前如果批量操作，先确认物理层没有问题，否则你会被各种莫名的超时折磨到崩溃。

5.2 升级中断或掉电怎么救

FOE 升级过程中如果突然断电或者拔了网线，从站固件损坏的概率比较大，但也不是无药可救。

多数正规厂商设计的从站有 Bootloader 保护机制，也就是说从站内部有两个区域：Bootloader 区域和 Application 区域。即使 Application 区域被写坏，Bootloader 仍然会正常工作，从站上电后会进入一个“固件下载等待状态”，这时候你只要再次用 FOE 把正确的固件刷进去，就能恢复。

但也要注意，不是所有从站都这么设计。有些低成本设备没有独立 Bootloader，升级断电后可能真的变砖，只能返厂用编程器恢复。所以升级前，先确认从站的 Bootloader 机制，然后在操作流程上做好防断电措施。最稳妥的方法是给从站和 PLC 都接到 UPS 上，或者选择产线计划性停电的时间窗口做升级。

如果刷了一半发现中断了，第一步不是重复刷，而是先扫描从站，看它还能不能出现在 EtherCAT 设备树里，状态是什么。如果还能扫描到，说明 Bootloader 还在，直接重新执行完整升级即可。如果扫描不到，检查 EtherCAT 网线、从站供电，再尝试给从站重新上电。还是不行，就要参考厂商手册的强制恢复流程了。

5.3 批量升级的实用技巧

当你需要升级几十台甚至上百台从站时，单纯在界面里一台一台点已经不够高效，也不是简单的循环调用就行。我提供几个批量升级的经验。

先把设备列表整理成表格，包括从站地址、设备型号、当前版本、目标版本、升级结果。然后按照设备位置或者从站地址的顺序，一个一个执行升级。千万注意，不要同时给两台从站同时发 FOE 写命令，这会让 EtherCAT 主站负载瞬间升高，也可能引起从站状态错乱。

批量升级建议用一个“扫描+比对+升级+校验”的流水线式状态机。先依次扫描所有从站的当前版本，自动生成需要升级的设备清单。然后逐个执行升级，每台设备升级完都验证版本号并记录日志，失败的重试两次，仍失败则标记为异常，等全部跑完再人工处理异常设备。

另外，升级程序的触发权限也要做好。远程升级虽然方便，但一旦误触发，后果比手动刷固件更严重。我的习惯是做一个双重确认：第一步在 HMI 或者上位机上输入目标批次号，第二步必须有一个工程密码或确认按钮，确认后程序才开始执行。这样能避免误碰按钮就把全产线设备给刷了。

写日志也特别重要。每次升级，无论成功还是失败，都要把时间、从站地址、固件版本、错误码写进一个可以查询的表单或者数据块里。后面有人问“这台设备什么时候刷的、刷的什么版本”，你不用翻聊天记录，直接把日志导出来就行。

6. 最后分享几条我的实操习惯

做固件远程升级这件事，本质上不是“会调用一个功能块”就够了，它是一个系统工程。从我自己的经验来说，有几点特别值得坚持。

一是先在测试台上把完整流程跑通。至少验证三件事：从站能通过 FOE 正常写入、固件文件本身没问题、升级后从站能恢复 OP 状态。这三件事有一件没验证，就不要上现场。

二是把固件文件管理好。我现在的习惯是所有固件按“厂商_设备型号_版本号_日期”命名，存放在统一的网络目录里，每次升级前由上位机程序读取目录列表，PLC 只负责接收指定文件。版本管理做好了，远程升级才有底。

三是保持对从站状态的敬畏。FOE 写入操作虽然看起来只是传文件，但它对从站来说是一次“深度干预”。任何时候都不要在设备还在正常运行、轴上还带负载的情况下触发升级。安全停机这个步骤，永远放在升级逻辑的最前面。

四是不要把所有内容都放在一个功能块里硬写。我吃过亏：一开始把所有逻辑写在一个 FB 里，结果后来想增加“版本比对”和“日志记录”，改起来非常痛苦。现在我会拆成几个模块：版本读取模块、状态切换模块、FOE 写入模块、日志记录模块。每个模块只做一件事，组合起来就是一个完整的远程升级流程。

最后再分享一个小技巧：调试 FOE 功能时，先用 1 个字节或者几个字节的小文件模拟传输，确认通讯链路通，再去刷真实固件。这样能把“网络问题”和“固件问题”分开定位，省下大量排错时间。

希望这篇文章能把 FOE 远程升级这条路径讲透。只要把协议原理、从站状态、功能块参数和批量流程这四块连起来，你完全可以做出一个稳定、可追溯、还带保护机制的固件升级系统。