企业官网建设流程全解析

简介：面向自动化技术与PLC开发人员的TwinCAT 3版本管理指南，聚焦3.1.4024起集成的AdsGitServer功能，说明如何把控制器作为Git Server，在不依赖外部Git软件的情况下完成PLC程序的提交、获取、差异查看与版本回退。文档从软硬件版本确认、软件安装、控制器路由配置和TwinCAT环境设置讲起，逐步落到Multiuser启用、Git Server初始化及日常操作界面，并覆盖历史版本浏览、版本比较、用历史版本修改当前程序、恢复到某一历史版本，以及第二台PC从控制器装载不同版本PLC程序等协作场景。对于Init创建失败、连续提交两个版本等典型问题，也给出原因分析与处理思路。资源包内含1个PDF文件，大小1.77MB，篇幅精炼、按主题分节，内容偏重实操与问题定位，便于在项目现场快速查阅。已有373人学习下载，适合需要建立PLC协同开发规范、补齐版本控制操作细节的工程师参考。

1. 初始化卡在第一步：Init local and Remote 点下去没有任何反应

TwinCAT 3 AdsGitServer 最坑人的地方是它不报错。你按手册把 PLC 程序属性里的 Multiuser 勾上，打开 Multiuser Explorer，选好 ADS Route，填了仓库名，点下 Init local and Remote——然后什么都没有：不弹 Update Message 输入框，不抛异常，按钮就那么灰着，控制器上也没多出仓库目录。第一次上手的人多半会去怀疑网络、怀疑路由，甚至重装一遍开发环境，一个下午就这么没了。

这种「静默失败」在集成式版本管理里出现频率极高，因为它把三件事压在了一个按钮后面：Windows 服务有没有起来、ADS 通道通不通且两端版本匹配、本地和控制器上有没有上一轮的 Git 残留。任何一环不对，表现都是同一个「没反应」。下面按我实际踩过的顺序拆开讲，从服务、路由、残留清理一路走到版本分叉和比较工具打不开，最后给一套能三分钟定位的确认流程。

2. Init 失败的四种成因：服务、路由、残留、仓库名

2.1 先看两个 Windows 服务，别急着怀疑路由

AdsGitServer 不是独立安装的软件，它是随 TwinCAT 3.1.4024 安装包一起落地的组件。开发机上装完整版安装包，控制器上装运行时安装包，装完重启，服务列表里就应该能看到两条记录：TwinCAT 3 System Service 和 TwinCAT3 AdsGitServer。很多人只确认了前者在跑，后者是停止状态，于是 Init 按钮点下去毫无反馈——因为请求根本没有接收方。

在开发机和控制器上各跑一遍下面这段，两边结果要一致：

# 列出所有 TwinCAT 相关服务，确认关键两项的状态与启动类型 Get-Service -Name "TwinCAT3*" | Format-Table Name, Status, StartType -AutoSize # 如果 AdsGitServer 是 Stopped，手动拉起来再看 Start-Service -Name "TwinCAT3 AdsGitServer" Get-Service -Name "TwinCAT3 AdsGitServer"

Status必须是Running，StartType建议是Automatic，否则每次重启控制器都要人工去点一次，迟早忘。如果Start-Service直接报「找不到服务」，说明安装包根本没装对——常见情况是把完整版安装包装到了控制器上，或者控制器上装的是低于 4024.15 的旧运行时。这时候不要试图单独补一个 Git 组件，重装对应版本的运行时安装包比什么都快。

还有一种更隐蔽的情况：服务在跑，但登录账户权限不对。AdsGitServer 要在控制器的仓库根目录下建文件夹、写对象文件，如果服务账户对C:\ProgramData下的厂商目录没有写权限，Init 同样会静默失败。判断方法是看控制器事件查看器里有没有对应时间点的写入拒绝记录，或者干脆用管理员账户跑一次对照实验。

2.2 路由通不代表版本对得上：ADS Route 变灰的三层排查

路由列表里能看到控制器，不代表 Multiuser Explorer 里就能选中它。这里有三层，逐层往下排：

第一层是路由本身。控制器操作系统要求 Windows 7 或 Windows 10，TwinCAT 版本要求 3.1.4024.15 及以上。添加路由时如果控制器是 WES7 这类嵌入式系统，路由能加上，但某些安全策略下 ADS 通讯会被拦。先在开发机上用系统托盘里的路由工具确认控制器状态是绿色，再往下走。

第二层是两端版本。实测下来，XAE（开发环境）和 XAR（控制器运行时）最好完全同版本，Build 号越高越稳。开发机是 4024.15、控制器是 4024.10 这种组合，路由看着是通的，Init 就是不动。检查方法很简单，两边分别打开关于对话框对一下 Build 号。

第三层是硬件。手册没有明确规定，但实测结论很直接：控制器用厂商自家的 IPC/EPC 系列最稳，换到第三方 PC 上跑 XAR，会出现各种说不清的问题——路由时通时断、Init 偶尔成功一次、仓库目录建了一半。如果你的场景是「第三方工控机 + 厂商运行时」，遇到 Init 失败先别怀疑配置，换台原厂硬件对照一次，能省掉大量时间。

版本要求整理成一张表，排查时对着看：

2.3 Init 创建失败之后：清 Local、清 Boot、再重启的顺序

如果前面都对，Init 还是失败，八成是残留。AdsGitServer 的状态是「控制器上的仓库目录 + 本地项目目录下的 Git 元数据 + 控制器 Boot 目录里的运行镜像」三份数据共同决定的，只清一份，下次 Init 依旧会撞上旧状态。

正确顺序是先清远程、再清本地，最后重启控制器让状态彻底归零。控制器侧的操作：

# 控制器上执行：先停掉 TwinCAT 服务，避免文件被占用 Stop-Service -Name "TwinCAT3*" -Force # 清空 Boot 目录（路径以实际安装为准） Remove-Item "C:\TwinCAT\3.1\Boot\*" -Recurse -Force -ErrorAction SilentlyContinue # 重新拉起服务，Boot 目录会在下次激活配置时重新生成 Start-Service -Name "TwinCAT3*"

-Force是为了连带停掉依赖服务，-ErrorAction SilentlyContinue是为了跳过已被删除的临时文件。Boot 目录里放的是控制器当前运行的镜像，清空之后控制器处于「没有活动程序」的状态，这时再重新激活配置，得到的才是干净的起点。要注意：控制器上的版本仓库根目录（安装后位于系统 ProgramData 下的厂商目录，实测为...\MultiuserRepository）里的内容不必清空，那是历史仓库，将来还能从下拉菜单里重新选回来。

本地侧要手动删掉项目目录下的 Git 文件：

# 开发 PC 上，进入 PLC 项目所在目录，先看清楚有什么 ls -a # 确认后再删，主要是 .git 目录和项目根下的几个 Git 配置文件 rm -rf .git .gitignore .gitattributes

初始化成功后，项目目录下会多出三个文件和—个文件夹，.git是本地仓库本体，另外几个是忽略规则和属性配置。删除时一定要确认当前目录是 PLC 项目根目录而不是整个解决方案目录，否则会把上层别的仓库一起干掉。清完之后重新打开项目，重新走一遍 Init。

2.4 仓库名留空、url 不自动生成时的绕过办法

这是个看着像 bug、其实只是界面刷新问题的小坑。选完 ADS Route 之后，对于全新的 PLC 项目，在 Multiuser Repository 一栏填名称，下面的 url 应该自动补全。但实际经常出现填完了名称、url 还是空白，于是 Init 按钮点不动。

处理方法很土但有效：把仓库名最后一个字符删掉，再重新敲回去，光标离开输入框，url 就会刷新出来。本质是这个输入框的变更事件没被触发，人为制造一次内容变化即可。

这里有个概念要钉死：你填的这个名称，就是将来控制器仓库根目录下那个文件夹的名字。填DemoLine，控制器上就多一个...\MultiuserRepository\DemoLine。所以名字一旦定下来就不要随手改，改了等于换了一个仓库，之前的历史在旧文件夹里躺着，新版界面里根本看不到。

对于已有的 PLC 项目，如果你知道控制器上的仓库名，直接从 Multiuser Repository 的下拉菜单里选，不用重新输入。还有一个时序问题：初始化 Git Server 要在激活配置下载之前做。先下载再初始化，控制器 Boot 目录里已经有程序了，第一次提交的内容就会和预期不一致。如果非要在现有控制器上跑另一个完全不同的 PLC 项目，最稳妥的做法还是提前清空 Boot 并重启，把上一轮版本控制对新项目的影响彻底断干净。

3. 两台 PC 版本打架：LocalsBehindRemote 与 Conflict 的处理顺序

3.1 第二台 PC 接入：先拿到同名项目，再谈同步

单机开发时这套流程很顺，一旦第二台笔记本要接进来，问题就集中爆发。根本原因是 AdsGitServer 追踪的粒度是「项目」，而不是「文件夹」，第二台 PC 上必须存在一个与控制器上运行程序同名的项目，才能把仓库拉下来对齐。

标准动作是：先在第二台 PC 上加好到控制器的路由，然后从控制器上传源程序，目的不是拿到完整源码（第一台 PC 可能压根没下载源码），而是拿到和 PLC 里正在跑的那个程序同名的项目骨架。接着打开 Multiuser Explorer，从 ADS Routes 里选控制器，从 Multiuser Repository 下拉菜单里选目标仓库名，点 Init Local and Remote。这时系统会提示远程已存在数据仓库、是否读取，回答「是」，控制器上的仓库就会同步到这台笔记本上。

同步完之后不要急着改代码，先去 History 里把当前版本装载下来，让本地项目和控制器上运行的那份对齐。跳过这一步直接改，后面必然撞上「本地落后于远程」的状态。

3.2 LocalsBehindRemote 是状态描述，不是错误

第一台 PC 重新打开项目，进 History 会看到 Local 和 Remote 不一致：红色的是远程新增的版本，绿色的是本机保存的最新版本。切到 Status 页，提示LocalsBehindRemote——意思是本地程序版本比控制器上的旧。

这个提示很容易被当成故障，其实它只是告诉你「有人在你之后提交过」。真正的风险点在 Conflict 页：它会明确列出本地丢失了远程的哪几次修改。看到这一页才需要动手，否则只是信息展示。

判断分叉点的办法是把 History 列表按时间顺序读一遍，红色条目是远程独有的提交，绿色是本地独有的。两边都有、内容不同的那一次提交，就是分叉点。把分叉点和当前版本各选一次，右键 Compare，看差异落在哪几个 POU 上，心里有数再决定是拉取还是覆盖。

3.3 Get Latest 和 Get This Version 的区别，Accept 提示怎么读

这两个菜单项长得像，作用完全不同，用错一次就够疼。

Get Latest拉取远程最新版本，会直接改动当前打开的项目文件，所以系统一定会弹「程序从外部改动了」的提示，并列出与当前代码的差异，让你逐条 Accept 或拒绝。它的语义是「以远程为准往前追」。如果你本地有一堆还没提交的修改，点它等于把远程内容盖上来，本地改动就悬了。

Get This Version是针对 History 里选中的某一个具体版本，右键选择后同样会提示代码从外部改变、是否装载。确认之后当前 PLC 项目就回退到那个版本。恢复历史版本走的就是这条路，比手工复制粘贴可靠得多。

Accept 那一步有个细节：提示框里列出的差异是可以逐条接受的，也可以整体关闭不予理会。关掉不等于放弃，只是这次不合并。真正的坑在于——很多人看到提示框直接点关闭，以为「什么都没发生」，其实文件在弹出提示之前就已经被 Compare 工具改写了。

3.4 Reload 提示：File has been changed outside the environment

装载历史版本或者执行 Get Latest 之后，TwinCAT 会弹一句File has been changed outside the enviroment. Reload the new file?。这里的 outside 指的就是比较工具从 Git Server 取了旧版本代码、改写了项目的 POU 文件。

关键结论只有一句：Reload 只是把文件重新读进编辑器看看，无论你选是还是否，代码都已经改了。选「否」不会撤销修改，只是编辑器里显示的还是内存里的旧内容，下次保存时反而可能把回退结果又覆盖回去。所以看到这个提示，正确做法是选「是」，让编辑器状态和磁盘保持一致，然后再去编译验证。

回退到某个版本之后，建议立刻 Login 一次控制器并填一条明确的 Update 信息，比如「Rollback to V1.0.1」。不填的话，控制器侧会产生一条内容为空或者自动生成的记录，过两周再回来看历史，根本分不清哪次是人为回退、哪次是误操作。

4. 比较打不开：Compare 空白、双击红色 POU 没反应

4.1 源代码管理插件没切到 Git，比较功能直接失效

新建项目、写完第一个 POU、Login 提交，History 里能看到两条记录，但右键 Compare 之后弹出的窗口一片空白，或者干脆什么都没发生。这类问题的第一嫌疑人是环境设置里的源代码管理插件没选对。

从主菜单进入工具-选项，找到源代码管理（Source Code Control）设置页，把插件选成 Git。这一步的作用不是「启用 Git 功能」——功能本来就在——而是告诉 TwinCAT：做版本比较时去 Git Server 上取源代码，并用集成的项目比较工具渲染。插件停在别的选项上，比较动作会走另一条分支，结果就是窗口打开但没内容。

改完这个设置建议重启一次开发环境。这类全局配置在部分 Build 上不会热生效，改完不重启，行为还是旧的，很容易误判成「设置没用」。

4.2 Project Compare 的 Git 配置没导出启用

插件选对了还不够。项目比较工具自己还有一份用户工具配置，没启用 Git 插件的话，它不知道该怎么解析仓库里的版本。

操作路径是：从开发环境的启动图标点开工具菜单，进入项目比较工具，在主菜单里找 Configure User Tools，点 Export Configuration，选中 Git 插件，启用默认的全局 git 配置。这一串动作做完，比较工具才真正具备「从 Git 仓库读源码并渲染差异」的能力。

顺序上有个经验：先配比较工具，再做第一次提交。反过来的话，前面几次提交产生的版本在比较时可能读不出源码，得重新提交一遍才有完整信息。这不是 bug，是配置生效时机的问题。

4.3 双击红色 POU 弹出的是 XML 而不是代码

History 里选两个版本 Compare，差异图里能看到红色的 POU，双击进去却发现是一堆 XML 结构，找不到一行 ST 代码。原因通常不在工具，而在源程序本身没被下载到控制器。

TwinCAT 的 PLC 项目可以选择是否把源程序一起下载到控制器。如果第一台 PC 编译下载时没勾选源程序下载，控制器仓库里存的就是编译产物和工程描述，比较工具只能按 XML 结构渲染，自然看不到梯形图或 ST 代码。第二台 PC 上来拉仓库，拉到的也是这份不含源码的版本。

解决办法是在下载配置里把源程序下载打开，重新 Login 一次产生一个新版本。这个新版本开始才有可读的代码差异，之前的历史版本补不回来——Git 存的是当时提交的快照，事后改不了。这也是为什么建议在项目一开始就把这个选项定下来，中途改会留下一段「看得见版本、看不见内容」的历史。

4.4 三种差异怎么读，Accept Single 与 Accept All 的取舍

差异图里只有三种标记：新增、删除、逻辑修改，全部用红色标出。新增和删除看块的边界就行，逻辑修改要看具体行。双击红色 POU 进入代码视图，左右两栏分别是两个版本，改动行高亮。

如果只是想从历史版本里搬一小段逻辑回来，用 Accept Single；整块搬用 Accept Block；确定这个 POU 整体回到旧版本用 Accept All。这三个按钮的作用是「把差异应用到当前版本」，操作完回到当前 PLC 程序的源代码，会发现代码已经改过来了，不需要手动复制。

要提醒的是，Accept 是单向的、即时的。点完之后当前项目的文件就被改写了，没有二次确认。所以在点 Accept All 之前，先确认当前版本里没有别人刚提交、你还没拉下来的改动，否则一 Accept 就把远程的新内容盖掉了。多人协作时这一步最容易出事，一个人回退版本，另一个人刚提交的修改直接消失，而且从 History 上看不出是谁干的。

5. 避坑记录：五条踩过一次就忘不掉的坑

5.1 同一个文件夹既 Enable Multiuser 又 git init

现象：项目做了一段时间，想用标准 Git 工具备份文档，顺手在 PLC 项目根目录执行了git init，之后 Multiuser Explorer 里的状态开始乱跳，History 时有时无，Login 时提示提交失败。

原因：AdsGitServer 和标准 Git 不能同时追踪同一个文件夹。PLC 项目目录一旦启用 Multiuser，里面的.git就归 AdsGitServer 管，再手动初始化一个仓库，两套元数据互相覆盖，谁都读不准状态。

解决：一个目录只归一套工具管。PLC 代码走 AdsGitServer，文档类内容另建一个独立目录，用标准 Git 或者可视化客户端管理，两个目录不要有包含关系。

5.2 在现有控制器上换项目，没清 Boot 就初始化

现象：控制器上原来跑着 A 项目，现在要换成 B 项目并做版本控制。直接改项目、激活配置、Init，结果第一个版本里混进了 A 项目的残留对象，History 里出现一条内容莫名其妙的初始提交。

原因：Boot 目录里还是 A 项目的镜像，激活配置时新旧内容混在一起被提交进了仓库。

解决：换项目前先停服务、清空 Boot、重启控制器，再激活新项目、再 Init。顺序不能颠倒，先 Init 后下载同样会出问题——初始提交抓到的是一份还没对齐的快照。

5.3 在可视化客户端里点了「解决方案」视图

现象：用开发环境自带的团队资源管理器管理非代码文件，手滑点了「解决方案」，当前打开的 TwinCAT 项目被关掉了，资源管理器跳到了项目文件夹。

原因：这个入口的语义是「以解决方案方式打开」，对 TwinCAT 项目来说等价于关闭当前工程。

解决：管理非 TwinCAT 文件时只用「文件夹视图」和存储库配置页，别碰解决方案相关入口。迷路了就点左上角的「管理连接」回到主界面，这是最快的复位方式。

5.4 以为在开发环境里能看非 TwinCAT 文件的历史

现象：把 Word 文档放进一个受 Git 管理的文件夹，提交了两个版本，想在开发环境里回退到上一版，翻遍界面找不到入口。

原因：开发环境里只能看到 PLC 代码的历史版本，非 TwinCAT 文件的历史查看和回退必须走标准 Git。

解决：在那个文件夹里右键打开命令行，用git log看版本，用git reset --hard HEAD^回退：

# 进入受 Git 管理的文档目录 cd /d/技术文档/项目归档 # 查看提交历史，确认要回退到哪一版 git log --oneline # 回退到上一个版本，注意 --hard 会丢弃工作区未提交的改动 git reset --hard HEAD^

HEAD^表示当前提交的父提交，回退两级用HEAD^^，也可以直接写提交哈希。--hard会同时重置暂存区和工作区，执行前确保没有还没提交的内容。回退完再打开那个 Word 文档，内容确实回到了上一版。要清楚的是，非代码类文件在标准 Git 里同样没法像 PLC 代码那样做结构化比较和合并，回退是「整文件替换」，不是「逐行合并」。

5.5 多人同时改一个 PLC 程序，还指望工具兜底

现象：两个人各改一部分逻辑，各自 Login 提交，History 里很快出现一堆交错的提交，Conflict 页长期飘红，最后谁也说不清当前跑的到底是哪个组合。

原因：这套机制本质是线性历史加版本快照，它不解决并发编辑的语义冲突。两个人改同一个 POU 的不同段落，工具只能告诉你「这个文件两边都变了」，没法替你判断保留哪边。

解决：多人协作前先把分工、编辑范围、上传下载时机约定清楚，尽量按 POU 或按功能块切分。真要并行改同一个文件，宁可最后人工合并一次，也好过让工具去猜。另外 ADS 通道本身支持 CA、PSK、用户名密码等安全方式，测试阶段可以图省事不加密，正式多人环境该配的授权还是要配，否则谁都能往仓库里提交。

6. 快速定位：我现在固定走的三步确认法

踩了这么多坑之后，我形成了一个很土的检查顺序，基本能在几分钟内把「没反应」拆成「具体哪一环坏了」。核心思路是从下往上：先确认执行者活着，再确认通道通，最后才怀疑内容。

第一步永远是看服务。开发机和控制器两头都跑一次服务状态查询，两个关键服务不在 Running，后面所有排查都是浪费。第二步看版本，路由通了只是物理层通了，XAE 和 XAR 的 Build 号差一个数字，Init 就是不动，这个我吃过不止一次亏。第三步才去看残留和仓库名，前两步都干净的情况下，九成问题出在本地.git和控制器 Boot 目录上，按「先远程后本地、最后重启」的顺序清一遍基本就恢复了。

还有一个验证习惯值得养成：每次 Login 提交时把 Update 信息写清楚，比如「V1.0.1 修改递增步长」而不是「update」。这行字是 History 里唯一的语义线索，出问题回溯时，一条「V2.0.1 第二台 PC 新增 y 变量」能让你三秒钟定位到那次提交，而一条「update」只会让你把整个列表从头翻到尾。回退操作之后更要补一条说明，标明是人为回退而不是新功能。

从那以后我每次接手一台新控制器做版本管理，都强制先走一遍「服务状态 → 两端版本 → Boot 清空」这三步，哪怕看上去一切正常。省下的那五分钟，往往要用一个下午来找回来。

希望帮到你。

本文还有配套的精品资源，点击获取