1. 为什么要把 InoProShop、Claude Code 和 MCP 串在一起如果你同时接触过工业自动化和 AI 编程工具这两个圈子大概率会有一种割裂感一边是 InoProShop 这类 PLC 编程环境讲究的是确定性、实时性和现场调试另一边是 Claude Code 这类终端里的 AI 编程助手讲究的是自然语言驱动、上下文理解和自动化执行。这两样东西看起来八竿子打不着但 MCPModel Context Protocol的出现让它们有了真正打通的可能。先说清楚这三个东西各自是什么。InoProShop是国内工控场景里常见的 PLC 编程平台底层基于 CODESYS 3.5 内核支持梯形图、ST、FBD 等 IEC 61131-3 标准语言常用于中小型自动化项目的逻辑开发、Modbus TCP/RTU 通讯组态、SoftMotion 运动控制配置等。Claude Code是运行在终端里的 AI 编程代理能读写本地文件、执行命令、理解整个项目结构适合做代码生成、重构、脚本编写这类工作。MCP则是一套开放协议它定义了 AI 模型如何以标准化方式连接外部工具和数据源——你可以把它理解成AI 世界的 USB-C 接口只要工具实现了 MCP ServerClaude Code 就能直接调用它。那把它们串起来到底解决什么问题我举个自己踩过的真实场景。之前做一个汇川 PLC 的项目需要在 InoProShop 里组态 Modbus TCP 通讯从站设备有十几台每台的寄存器地址、数据类型、字节序都不一样。手动一个个填变量表填到第八台的时候眼睛都花了还填错了两个地址现场调试时排查了半天。当时我就在想如果能让 AI 读取设备手册自动生成 InoProShop 能导入的变量表文件再通过某种协议直接写进工程里这事能省多少时间。MCP 就是干这个的。你可以写一个 MCP Server把 InoProShop 工程文件的读写能力、CODESYS 的 API 调用能力、甚至设备手册的解析能力都封装成工具然后 Claude Code 通过 MCP 协议调用这些工具实现用自然语言描述需求AI 自动操作工程文件的效果。这不是科幻是现在就能落地的东西。这篇文章适合谁看如果你是有一定 PLC 编程基础、同时对 AI 工具感兴趣的工控工程师这篇内容能帮你打开一个新思路。如果你是从软件转过来做工业自动化的开发者里面关于 CODESYS 工程结构和 MCP 协议对接的部分会对你有直接帮助。如果你只是想了解 MCP 到底能干什么我也会用尽量通俗的方式把原理讲清楚。需要提前说明的是下面涉及的具体配置和代码一部分来自我自己的实践一部分是基于 MCP 协议规范和 CODESYS 公开文档的合理推演。工业现场环境差异很大你在实际部署时一定要先在测试环境验证不要直接上生产设备。2. 部署前的环境盘点别急着装先把这几件事想清楚2.1 三个组件的版本匹配关系很多人一上来就急着装 Claude Code结果装完发现连不上 MCP Server或者 InoProShop 工程文件根本读不了。问题往往出在版本不匹配上。这三个组件之间有明确的依赖关系我整理了一张表你可以对照自己的环境检查。组件推荐版本关键依赖常见坑InoProShopV1.5.x 及以上CODESYS 3.5 SP16 以上内核低版本不支持工程文件的外部读写接口Claude Code最新稳定版Node.js 18Node 版本过低会导致 MCP 连接超时MCP Server按需选择Python 3.10 或 Node.js 18协议版本要与 Claude Code 匹配这里重点说 InoProShop 的版本。InoProShop 本质上是 CODESYS 的定制发行版它的工程文件.project 格式底层是 CODESYS 的 XML 结构。如果你想让外部程序读写工程文件需要确认你的版本支持 CODESYS 的 Scripting 接口或者 Project Export 功能。我实测下来V1.5 以上的版本对这块支持比较完整低版本可能只能通过导出 XML 再解析的方式间接操作。Claude Code 这边Node.js 版本是硬门槛。我一开始在旧笔记本上用的是 Node 16装完 Claude Code 后 MCP 连接一直报协议不兼容换成 Node 20 之后一次就通了。这个坑很隐蔽因为 Claude Code 本身能跑起来只是 MCP 功能不正常容易误以为是 MCP Server 的问题。2.2 网络与权限的隐性约束工业现场的网络环境通常比较封闭很多工程师的编程电脑是不连外网的。但 Claude Code 和 MCP 的工作模式需要你提前想清楚Claude Code 的核心推理是在云端完成的本地只是一个客户端而 MCP Server 是跑在本地的负责桥接本地工具和云端模型。这意味着两件事。第一你的编程电脑需要能访问 Claude Code 的服务端点如果现场完全断网这套方案就跑不通你得考虑用本地模型替代的方案。第二MCP Server 访问本地文件系统、调用 InoProShop 相关接口时需要相应的文件读写权限和进程调用权限。在 Windows 环境下建议把 Claude Code 和 MCP Server 都放在同一个用户权限上下文里运行避免出现Claude Code 能读文件但 MCP Server 读不了的诡异情况。还有一个容易被忽略的点InoProShop 在运行时会锁定工程文件。如果你在 InoProShop 打开着工程的同时让 MCP Server 去读写同一个文件大概率会失败或者读到脏数据。我的做法是涉及工程文件操作的 MCP 工具都加上一个检查逻辑——先检测目标文件是否被占用如果被占用就提示用户先关闭 InoProShop 或者切换到离线模式。2.3 目录结构规划一开始就分清楚我见过太多人把所有东西堆在一个目录里最后自己都找不到哪个文件是干嘛的。建议在开始部署前就规划好目录结构我自己的习惯是这样的workspace/ ├── mcp-servers/ │ ├── inoproshop-bridge/ # InoProShop 工程操作相关的 MCP Server │ │ ├── server.py │ │ ├── config.json │ │ └── tools/ │ ├── codesys-api/ # CODESYS API 封装 │ └── device-manual-parser/ # 设备手册解析工具 ├── projects/ │ └── my-plc-project/ # 实际的 InoProShop 工程目录 ├── claude-config/ │ └── mcp-settings.json # Claude Code 的 MCP 配置 └── logs/ └── mcp-server.log这样分的好处是每个 MCP Server 独立管理配置文件和日志分开存放出问题的时候排查范围很清晰。特别是当你有多个 MCP Server 的时候这种结构能避免端口冲突和配置覆盖。3. MCP Server 的搭建从零写一个能操作 InoProShop 工程的桥接工具3.1 MCP 协议到底怎么工作的在动手写代码之前有必要把 MCP 的工作机制讲清楚。很多人觉得 MCP 很神秘其实它的核心逻辑非常简单MCP Server 暴露一组工具Tools每个工具就是一个函数有明确的输入参数和输出格式Claude Code 在需要的时候根据用户的自然语言描述决定调用哪个工具、传什么参数然后把工具返回的结果纳入自己的推理上下文。打个比方MCP Server 就像是一个工具箱里面放着各种工具螺丝刀、扳手、电钻。Claude Code 是一个聪明的助手你告诉它把那个螺丝拧紧它会自己判断需要用螺丝刀然后从工具箱里拿出来用。MCP 协议规定的就是工具箱的标签怎么写工具怎么摆放助手怎么取用这些标准。具体到技术层面MCP 支持两种传输方式stdio标准输入输出和 SSEServer-Sent Events。对于本地工具类 Serverstdio 是最常用的方式Claude Code 启动 MCP Server 进程后通过标准输入输出进行 JSON-RPC 格式的消息交换。这种方式的好处是不需要网络端口安全性好适合本地文件操作类的工具。一个最简的 MCP Server 需要实现三个核心能力列出可用工具tools/list、执行工具调用tools/call、以及处理初始化握手initialize。下面我用 Python 写一个最小可用的示例展示如何封装一个读取 InoProShop 工程变量表的工具。import json import sys from pathlib import Path class InoProShopBridge: def __init__(self): self.tools [ { name: read_project_variables, description: 读取 InoProShop 工程文件中的变量表返回变量名、数据类型和地址, inputSchema: { type: object, properties: { project_path: { type: string, description: InoProShop 工程文件的绝对路径 } }, required: [project_path] } } ] def handle_request(self, request): method request.get(method) if method initialize: return { protocolVersion: 2024-11-05, capabilities: {tools: {}}, serverInfo: {name: inoproshop-bridge, version: 0.1.0} } elif method tools/list: return {tools: self.tools} elif method tools/call: return self.call_tool(request.get(params, {})) return {error: unknown method} def call_tool(self, params): tool_name params.get(name) arguments params.get(arguments, {}) if tool_name read_project_variables: return self.read_variables(arguments.get(project_path)) return {error: funknown tool: {tool_name}} def read_variables(self, project_path): # 实际实现需要解析 CODESYS 工程文件的 XML 结构 # 这里用占位逻辑说明调用链路 path Path(project_path) if not path.exists(): return {content: [{type: text, text: f文件不存在: {project_path}}]} return {content: [{type: text, text: 变量表读取成功共 0 个变量}]} def main(): bridge InoProShopBridge() for line in sys.stdin: line line.strip() if not line: continue try: request json.loads(line) response bridge.handle_request(request) print(json.dumps(response), flushTrue) except json.JSONDecodeError: print(json.dumps({error: invalid json}), flushTrue) if __name__ __main__: main()这段代码跑起来之后Claude Code 就能通过 MCP 协议调用read_project_variables这个工具了。当然真正的工程文件解析逻辑要复杂得多下面我会展开讲。3.2 解析 InoProShop 工程文件的关键细节InoProShop 的工程文件本质上是 CODESYS 的工程结构它可能是一个压缩包也可能是一个目录结构里面包含 XML 格式的设备描述、变量声明、POU程序组织单元代码等。要从中提取变量表你需要理解 CODESYS 的工程组织方式。我实测下来比较稳妥的做法是走导出这条路而不是直接解析原始工程文件。InoProShop 支持把工程导出为 PLCopen XML 格式这是一种标准化的交换格式结构清晰解析起来比原始工程文件容易得多。你可以在 InoProShop 里手动导出也可以通过 CODESYS 的 Scripting 接口自动触发导出。导出后的 PLCopen XML 里变量表通常在interface节点下的variables子节点中每个变量有name、type等属性。地址信息可能在addData或者自定义的扩展节点里。这里有个坑不同版本的 InoProShop 导出的 XML 结构可能有细微差异你的解析代码要做好容错不要硬编码节点路径。另一个关键点是字节序和数据类型映射。Modbus TCP 通讯里寄存器是 16 位的但你的变量可能是 32 位浮点数、32 位整数、甚至 64 位双精度。这就涉及到字节序和字序的问题。InoProShop 里组态 Modbus 通讯时需要指定这些映射关系。如果你的 MCP 工具要自动生成变量表就必须把这些映射规则也编码进去。我一般会在 MCP Server 里维护一个设备模板库每种常见设备比如某品牌的温控器、某品牌的变频器对应一套寄存器映射规则。当 Claude Code 需要为某台设备生成变量表时它先调用工具查询设备模板再根据模板和实际地址偏移生成完整的变量定义。这样比每次从零推导要可靠得多。3.3 把工具注册到 Claude CodeMCP Server 写好了接下来要告诉 Claude Code 去哪里找它。Claude Code 的 MCP 配置通常放在用户目录下的配置文件中格式是 JSON。你需要指定 Server 的启动命令、参数和环境变量。{ mcpServers: { inoproshop-bridge: { command: python, args: [/path/to/mcp-servers/inoproshop-bridge/server.py], env: { INOPROSHOP_WORKSPACE: /path/to/projects } } } }配置好之后重启 Claude Code它会在启动时自动拉起 MCP Server 进程。你可以在 Claude Code 里输入类似列出当前可用的 MCP 工具的指令来验证连接是否成功。如果连接失败先检查 Python 路径是否正确、脚本是否有执行权限、以及 JSON 格式是否合法。这里有个经验MCP Server 的启动日志一定要重定向到文件。因为 stdio 模式下Server 的标准输出被 Claude Code 占用了你没法直接在终端看到它的打印信息。把日志写到文件里出问题的时候才有得查。我一般会在 Server 代码里加一个日志初始化逻辑把关键操作都记录下来。4. 实战场景用自然语言驱动 InoProShop 完成 Modbus TCP 组态4.1 场景描述与工具设计假设你手头有一台汇川 PLC需要通过 Modbus TCP 读取三台设备的运行数据一台温控器读取当前温度、设定温度、一台变频器读取输出频率、电流、一台电表读取电压、电流、功率。传统做法是打开 InoProShop手动添加 Modbus TCP 主站设备然后一个个添加变量、填写寄存器地址、选择数据类型。整个过程大概需要半小时到一小时而且容易出错。用 MCP 方案你可以这样操作在 Claude Code 里输入帮我为这三台设备生成 InoProShop 的 Modbus TCP 变量表温控器地址是 40001 和 40002变频器是 40100 和 40101电表是 40200 到 40202都是保持寄存器温度是 16 位整数除以 10频率和电流是 32 位浮点数。Claude Code 会调用 MCP 工具生成符合 InoProShop 导入格式的变量表文件。为了实现这个场景MCP Server 需要暴露至少三个工具查询设备模板、生成变量定义、导出为 InoProShop 可导入格式。下面我重点讲生成变量定义这个工具的实现逻辑。4.2 寄存器映射的自动化处理寄存器映射是 Modbus 通讯里最容易出错的地方。我总结了几条规则这些规则可以直接编码到 MCP 工具里。第一地址偏移。Modbus 协议里的地址有几种表示方式协议地址从 0 开始、PLC 地址从 1 开始、以及带功能码前缀的地址如 40001 表示保持寄存器。InoProShop 里通常用的是带前缀的表示法但底层通讯用的是协议地址。你的工具需要做这个转换。比如 40001 对应协议地址 040100 对应协议地址 99。第二数据类型与寄存器数量的对应关系。16 位整数占 1 个寄存器32 位浮点数占 2 个寄存器64 位双精度占 4 个寄存器。当多个变量连续排列时要确保地址不重叠。我见过有人把两个 32 位浮点数放在相邻的 2 个寄存器上结果数据全乱了。第三字节序和字序。这是最坑的地方。同样是 32 位浮点数不同设备可能用不同的字节序大端/小端和字序高低字交换。Modbus 标准本身没有规定全靠设备手册说明。你的工具应该支持为每个变量单独指定字节序配置而不是全局统一。下面是一个生成变量定义的代码片段展示了如何处理这些规则def generate_variable_definitions(device_configs): variables [] for device in device_configs: base_addr device[base_address] for var in device[variables]: reg_count get_register_count(var[data_type]) variables.append({ name: f{device[name]}_{var[name]}, address: f4{base_addr var[offset]:04d}, data_type: var[data_type], register_count: reg_count, byte_order: var.get(byte_order, big_endian), word_order: var.get(word_order, high_low), scale: var.get(scale, 1.0) }) return variables def get_register_count(data_type): mapping { INT16: 1, UINT16: 1, INT32: 2, UINT32: 2, FLOAT32: 2, FLOAT64: 4 } return mapping.get(data_type, 1)这段逻辑看起来简单但实际部署时你会发现设备手册里的地址描述五花八门有的写 40001有的写 0x0000有的写 1。你的工具需要能处理这些不同的表示方式并且在遇到歧义时主动向用户确认而不是自己猜。4.3 从生成到导入的完整链路变量定义生成之后还需要转换成 InoProShop 能识别的导入格式。InoProShop 支持多种导入方式比较常用的是 CSV 格式的变量表和 PLCopen XML。CSV 格式简单直接适合批量导入变量PLCopen XML 则能保留更多结构信息适合完整的工程交换。我一般优先用 CSV因为格式简单出错容易排查。CSV 的列通常包括变量名、数据类型、地址、注释等。不同版本的 InoProShop 对列名和顺序可能有要求你需要先在 InoProShop 里手动导出一个模板照着模板的格式生成。导入的时候有个细节要注意InoProShop 在导入变量表时如果遇到已存在的变量名可能会覆盖或者报错。我的做法是生成的变量名加上设备前缀比如TEMP_CTRL_CurrentTemp这样既能避免冲突又能一眼看出变量属于哪台设备。整个链路跑通之后你可以在 Claude Code 里用一句话完成原本需要半小时的手工操作。当然第一次配置 MCP Server 和调试工具链可能需要几个小时但这是一次性投入后续每个项目都能受益。5. 调试与排错那些文档里不会写的坑5.1 MCP 连接失败的排查顺序MCP 连接失败是最常见的问题表现是 Claude Code 里看不到工具或者调用工具时报错。我总结了一个排查顺序按这个顺序走基本能定位到问题。先确认 Claude Code 是否真的启动了 MCP Server 进程。在 Windows 上打开任务管理器看有没有对应的 Python 或 Node 进程。如果没有说明配置文件的路径或者命令有问题。检查 JSON 配置里的command和args是否指向了正确的可执行文件和脚本路径路径里尽量不要有空格和中文。如果进程启动了但连接不上检查 MCP Server 的日志。前面说过stdio 模式下标准输出被占用所以日志要写到文件。看日志里有没有收到initialize请求有没有正常返回。如果连initialize都没收到说明 Claude Code 和 Server 之间的管道没建立起来可能是协议版本不匹配。如果initialize成功但tools/list失败检查工具定义的 JSON Schema 是否合法。MCP 对工具定义的格式有严格要求inputSchema必须是一个合法的 JSON Schema 对象。我遇到过因为required字段写成了字符串而不是数组导致工具列表加载失败的情况这种错误很隐蔽日志里可能只报一个笼统的解析错误。5.2 工程文件读写的权限与锁定问题InoProShop 工程文件的读写是另一个高频出问题的环节。前面提到过文件锁定的问题这里展开说几个具体的表现和应对方式。第一种情况是文件被 InoProShop 占用。当你打开 InoProShop 并加载了工程时工程文件会被锁定。此时 MCP Server 尝试读取可能会读到不完整的数据或者直接抛出权限异常。我的应对方式是在 MCP 工具里加一个前置检查尝试以独占方式打开文件如果失败就返回明确的提示信息告诉用户先关闭 InoProShop。第二种情况是路径问题。InoProShop 工程可能引用了一些外部文件或者库这些引用路径可能是相对路径。当 MCP Server 在不同的工作目录下运行时相对路径解析会出错。解决办法是在工具里统一把路径转换为绝对路径并且在配置里明确指定工程根目录。第三种情况是编码问题。CODESYS 工程文件里可能包含中文注释如果编码处理不当读取时会乱码。Python 里打开文件时明确指定encodingutf-8如果遇到 BOM 头用utf-8-sig。这个问题在中文环境下特别常见但很容易被忽略。5.3 工具调用结果不符合预期时的调试技巧有时候 MCP 连接正常工具也能调用但返回的结果不是你想要的那样。这时候需要分两步排查先确认工具本身的逻辑是否正确再确认 Claude Code 是否正确理解了工具的返回结果。确认工具逻辑最直接的方式是脱离 Claude Code单独测试 MCP Server。你可以写一个简单的测试脚本模拟发送 JSON-RPC 请求看 Server 的返回是否符合预期。这样能把问题范围缩小到 Server 本身排除 Claude Code 的干扰。确认 Claude Code 的理解可以在对话里让它解释它为什么选择调用某个工具、传了哪些参数。Claude Code 通常会展示它的推理过程你可以从中看出它是怎么理解你的需求的。如果它理解偏了说明你的工具描述description字段写得不够清晰需要调整。我踩过的一个坑是工具描述里写的是读取变量表但 Claude Code 理解成了读取所有变量包括系统变量结果返回了一大堆不相关的数据。后来我把描述改成读取用户定义的变量表不包括系统变量和库变量问题就解决了。工具描述要尽可能精确把边界条件说清楚这是用好 MCP 的关键。6. 进阶玩法把 CODESYS 生态的其他能力也接进来6.1 SoftMotion 配置的自动化生成CODESYS 的 SoftMotion 是做运动控制的核心组件配置起来相当繁琐需要设置轴参数、凸轮曲线、齿轮比等。如果你经常做类似的项目可以把这些配置也封装成 MCP 工具。思路是这样的维护一个运动控制模板库每种常见的运动模式点位运动、往复运动、凸轮同步对应一套参数模板。当用户描述需求时Claude Code 调用工具查询模板再根据实际参数如行程距离、速度、加速度生成具体的配置。生成的配置可以导出为 CODESYS 能识别的格式或者通过 Scripting 接口直接写入工程。这里的关键是参数校验。运动控制的参数之间有物理约束比如加速度不能超过电机的最大扭矩对应的值速度不能超过机械结构的极限。你的工具应该内置这些校验规则在生成配置时就发现不合理的地方而不是等到现场调试时才发现。6.2 设备手册解析与寄存器映射自动推导前面提到过设备模板库的思路更进一步的做法是让 AI 直接解析设备手册。很多设备手册是 PDF 格式里面有寄存器映射表。你可以写一个 MCP 工具用 PDF 解析库提取表格内容然后让 Claude Code 理解表格结构自动生成变量定义。这个玩法的难点在于 PDF 表格的解析准确率。不同厂商的手册格式差异很大有的表格跨页有的合并单元格有的用图片展示。我的经验是不要追求 100% 自动化而是做成AI 解析 人工确认的模式。工具先给出一个初步的解析结果让用户在 Claude Code 里确认或修正然后再生成最终的变量表。这样既提高了效率又保证了准确性。6.3 多 MCP Server 协同工作的配置要点当你有了多个 MCP Server比如一个管 InoProShop 工程一个管设备手册解析一个管代码生成它们之间的协同就变得重要了。Claude Code 支持同时连接多个 MCP Server它会根据任务需要自动选择合适的工具。配置多个 Server 时要注意工具名称不要冲突。每个 Server 的工具名在 Claude Code 看来是全局的如果两个 Server 都有叫read_file的工具会让人困惑。我的做法是给工具名加上 Server 前缀比如inoproshop_read_variables、manual_parse_table这样一眼就能看出工具属于哪个 Server。另外多个 Server 之间的数据传递也需要注意。比如设备手册解析 Server 提取出的寄存器信息需要传给 InoProShop Server 来生成变量表。这种跨 Server 的数据传递目前 MCP 协议本身没有直接支持需要通过 Claude Code 的上下文来中转。也就是说Claude Code 先调用手册解析工具拿到数据再把这些数据作为参数传给 InoProShop 工具。这种方式可行但要注意数据量不要太大否则会超出上下文窗口。7. 我在这套方案上踩过的几个真实坑第一个坑是过度自动化。一开始我想让 AI 全自动完成从需求描述到工程文件生成的全过程结果发现中间环节太多任何一步出错都会导致最终结果不可用而且排查起来非常困难。后来我调整了策略把流程拆成几个独立的步骤每个步骤都有明确的输入输出用户可以逐步确认。这样虽然多几次交互但可靠性高得多。第二个坑是忽略了 InoProShop 的版本差异。我在自己电脑上调试好的工具拿到同事的电脑上就跑不通原因是他的 InoProShop 版本低了一个小版本导出的 XML 结构有细微差异。后来我在工具里加了版本检测逻辑对不同版本走不同的解析路径。如果你要团队协作这一点一定要提前考虑。第三个坑是没有做好错误处理。MCP 工具调用失败时如果返回的错误信息太笼统Claude Code 很难判断该怎么处理。我后来养成了一个习惯每个工具的错误返回都尽量具体比如文件不存在、文件被占用、XML 解析失败第 15 行格式错误这样 Claude Code 能给出更有针对性的建议用户也更容易定位问题。第四个坑是日志记录不完整。早期我没有在 MCP Server 里加详细的日志出问题的时候只能靠猜。后来我在每个工具调用的入口和出口都加了日志记录输入参数、执行时间、返回结果摘要。这样即使出了问题翻日志也能快速定位。日志文件建议按天分割避免单个文件过大。这套方案目前还在持续迭代中每次做新项目都会发现可以优化的地方。但核心思路已经验证可行用 MCP 把工业编程环境和 AI 工具连接起来让重复性的配置工作自动化把工程师的时间留给真正需要判断力的部分。如果你也在做类似的事情欢迎交流踩坑经验。