这次我们来看 BnlAiCtrl 系列文章的第 7 篇AI 助手集成。前面六篇把机器视觉、运动控制、上位机这三个模块拆开讲过这一篇的重点是把 AI 助手真正接进非标自动化无代码平台里让它能参与视觉参数配置、运动控制点位计算、上位机报错诊断这些日常工作。先说结论BnlAiCtrl 这类非标自动化无代码平台核心价值是把视觉算法、运动控制逻辑、上位机界面通过拖拽节点的方式串起来降低工程师上手门槛。而 AI 助手集成要做的事情是把自然语言、知识库检索、报错解析、参数换算这些能力注入到节点编排流程中让不熟悉底层算法的调试人员也可以用大白话完成配置。这篇文章会讲清楚几个问题AI 助手到底能帮视觉、运动控制、上位机做什么本地大模型和云端大模型怎么选怎么把 AI 助手接到无代码流程节点里怎么验证效果接口调用和批量任务怎么设计以及最常见的坑有哪些。适合正在搞非标设备、自动化产线、机器视觉项目同时想用 AI 减负的工程师阅读。1. 核心能力速览能力项说明平台类型非标自动化无代码平台覆盖机器视觉、运动控制、上位机系列定位第 7 篇重点在 AI 助手集成AI 助手主要能力自然语言生成视觉配置、报错诊断、点位换算、PLC/上位机通讯辅助、知识库问答集成方式云端大模型 API 或本地大模型Ollama 等均可按数据保密要求选择是否支持批量任务支持AI 节点可嵌入批量处理流程如批量视觉检测参数生成、批量日志解析是否有 API无代码平台一般会暴露 HTTP APIAI 助手以接口服务方式接入具体路径以实际版本为准推荐硬件本地大模型需要 8GB 以上显存或 32GB 内存跑 CPU 推理云端 API 只需能访问外网支持平台Windows 为主工业上位机常用系统Linux 部署本地大模型更稳定适用场景非标自动化设备调试、视觉定位、运动控制联动、产线数据监控、报错快速排查使用边界涉及设备控制、产线参数、图纸数据时需确认数据是否可以出内网优先本地部署从表格可以看出AI 助手集成不是把 GPT 塞进平台那么简单核心价值是让 AI 能调用平台内部的能力比如读取当前视觉检测的坐标、查询设备的报警寄存器、生成一段 PLC 通讯配置。这才是无代码平台加 AI 的正确定位。2. 非标自动化平台的现状视觉、运动控制、上位机为什么需要 AI 助手非标自动化设备有个特点每个项目都不一样。A 项目是手机中框的视觉定位加四轴 SCARA 取放B 项目是锂电池表面的缺陷检测加伺服脉冲控制C 项目可能只是做一个数据采集上位机加 SCADA 监控。传统的实现方式每个项目都要重新写视觉脚本、重新调运动控制参数、重新做上位机界面周期长且依赖经验丰富的工程师。机器视觉这侧最常见的工作是定位和检测。定位时要处理旋转中心、取料基准点、手眼标定这些概念。比如热词里提到的场景“已经知道旋转中心且已经知道取料基准点如果物料与基准点发生旋转怎么换算新的取料位置”。这类问题在无代码平台里通常需要配置一个坐标转换节点输入旋转中心坐标、旋转角度、原始基准点输出旋转后的目标点。很多工程师第一次接触时对旋转矩阵、坐标系变换不熟调试半天也不对。运动控制这侧涉及脉冲输出、轴插补、伺服参数、PLC 通讯。热词里有一条是“通过双 DMA 实现脉冲输出 8 个轴插补能达到 500K3 轴可达 1M 的输出”这是嵌入式或板卡级运动控制的做法。在无代码平台里用户不需要写底层 DMA 驱动但需要理解轴参数怎么设、插补速度怎么配、回原点方式怎么选。这些参数的取值范围和调试顺序经验性极强。上位机这侧则是 C#、WPF、Qt、LabVIEW 这些技术栈的选择问题。热词里“C# 上位机 WPF 例程”“S7-1200 G2 的 S7 协议通讯与 PC 上位机如何搭建”“拿来就能用C# 上位机 PLC 实战项目”都在反映同一个需求上位机开发大量时间花在通讯对接、界面布局、报警处理上。这些痛点叠加在一起导致一个非标项目从进场到稳定生产很多时间都耗在参数调试和问题排查上。AI 助手切入的价值就是把这部分高重复、强经验的工作自动化一部分用自然语言描述目标平台生成配置把报错日志丢给 AI直接给出可能原因把旋转中心计算这类固定逻辑抽成工具让 AI 调用而不是让工程师手工推算。3. 机器视觉关键处理流程旋转中心、取料基准点、手眼标定的工程化落地AI 助手集成要能真正帮到机器视觉就要先把视觉处理里的高频逻辑固化下来。无代码平台的做法通常是把视觉节点封装成图像采集、标定、定位、检测、坐标转换、结果输出。3.1 旋转中心与取料基准点换算这是视觉定位里最容易出问题的地方。场景很明确物料在吸嘴或夹爪上绕着某个旋转中心转动一个角度后原来的取料基准点位置变了。如果平台已经通过标定得到旋转中心坐标也知道初始取料基准点那么任意旋转角度下新取料点的计算公式是固定的。核心数学逻辑是绕点旋转。已知旋转中心初始基准点旋转角度目标点的计算方式为import math def rotate_point(center_x, center_y, base_x, base_y, angle_deg): # 将角度转为弧度 angle_rad math.radians(angle_deg) cos_a math.cos(angle_rad) sin_a math.sin(angle_rad) # 将基准点平移到旋转中心为原点的坐标系 dx base_x - center_x dy base_y - center_y # 旋转 new_dx dx * cos_a - dy * sin_a new_dy dx * sin_a dy * cos_a # 平移回原坐标系 new_x center_x new_dx new_y center_y new_dy return new_x, new_y # 示例旋转中心 (100, 100)取料基准点 (120, 130)旋转 90 度 x, y rotate_point(100.0, 100.0, 120.0, 130.0, 90.0) print(f旋转后的取料位置: ({x:.2f}, {y:.2f}))在无代码平台里这个计算逻辑通常会被封装成一个“坐标旋转”节点。用户只需要填四个参数旋转中心 X、旋转中心 Y、基准点 X、基准点 Y、旋转角度输出就是新的取料点。AI 助手在这里的作用是当用户不记得角度正负方向、或者不确定旋转中心怎么标定时直接问 AI“我的物料逆时针旋转了 30 度旋转中心是 (520, 430)基准点是 (560, 460)取料点应该怎么填” AI 助手调用坐标旋转工具返回结果并解释计算过程。3.2 手眼标定与九点标定热词里多次出现“机器视觉手眼标定原理”。在实际项目中手眼标定要解决的核心问题是相机像素坐标怎么映射到机器人或运动平台的物理坐标。常见做法是九点标定在相机视野内均匀分布九个点记录像素坐标和实际机械坐标然后计算仿射变换矩阵。无代码平台一般会提供标定流程节点用户不需要手动解矩阵。AI 助手在这里可以做的是根据标定板布局、相机安装方式、运动平台行程推荐标定路径和点位数量。例如用户描述“相机固定安装在机台上方视野范围大约 100mm x 80mm”AI 可以给出标定路径建议按 3x3 网格移动每个位置拍照并记录坐标不要超出行程边界标定完成后用剩余点做验证计算重复精度。这个能力的前提是平台把标定流程和坐标结果暴露给 AI 工具。否则 AI 只能给建议不能直接干预流程。3.3 视觉检测参数生成视觉检测里最费时间的是调参数。圆检测要设最小半径、最大半径、边缘阈值、投票数。blob 分析要设灰度阈值范围、面积范围、圆度。模板匹配要设金字塔层数、匹配分数、旋转范围。无代码平台把算法封装成节点后参数数量还是很多。AI 助手集成后可以这样工作用户输入文字“在 ROI 区域 C 检测外径 8mm 到 10mm 的圆形零件要求 0.02mm 精度”平台先根据相机分辨率和视野比例把毫米换算成像素再给出一组初始参数写回到视觉节点的配置里。工程师确认后直接运行验证。这套流程不是把 AI 吹成无所不能而是把经验型参数配置变成可对话、可解释的过程降低首轮调试时间。4. 运动控制与上位机联动无代码编排如何支撑产线逻辑机器视觉和运动控制是紧密配合的。视觉算出目标位置运动控制就要执行到位。热词里“S7-200 SMART 运动控制实例”“S7-1200 G2 的 S7 协议通讯与 PC 上位机如何搭建”“grbl 上位机”“伺服运动控制仿真软件”都指向同一个问题工程师需要快速把逻辑跑通。BnlAiCtrl 这类无代码平台通常会把运动控制抽象成轴节点、点位节点、插补节点、IO 节点。用户在界面上拖拽连线就能实现“相机拍照 - 视觉定位 - 坐标转换 - 轴运动 - IO 触发”的完整流程。不需要写底层驱动也不需要直接操作 DMA 或脉冲输出寄存器。热词里那条“通过双 DMA 实现脉冲输出 8 个轴插补能达到 500K 3 轴可达 1M 的输出”说明在高阶应用里脉冲输出频率和轴数是硬指标。无代码平台如果走中间层必须保证不发指令延时、不丢指令。这里 AI 助手能帮忙的地方是根据轴数和速度要求推荐合适的脉冲频率、加减速时间。例如用户问“3 轴插补目标速度 800KHz应该怎么配加减速” AI 可以给出梯形加减速的加速度、减速度计算逻辑并提醒检查驱动器细分和最大输入脉冲频率限制。上位机层面C# WPF、Qt、LabVIEW 这些技术栈在传统开发里要写大量代码。无代码平台把这些封装成页面组件和变量绑定后用户拖拽就能出基础监控界面。但遇到定制逻辑时仍需要脚本节点。热词里“AI 写上位机软件有哪些”很能说明问题很多工程师希望 AI 直接生成上位机代码。在 BnlAiCtrl 里AI 助手的合理做法是生成“节点脚本”而不是整个上位机工程。例如用户说“设备启动时把所有轴回原点回完后弹窗提示”AI 生成对应的脚本片段用户粘贴到脚本节点中即可。这种联动方式的好处是AI 不替代无代码平台而是做平台和工程师之间的翻译层。工程师用自然语言描述需求AI 生成配置或脚本平台负责可靠执行。5. AI 助手集成的三种方案云端 API、本地大模型、RAG 知识库AI 助手要落地到非标自动化平台首先要想清楚模型放哪里。这里有三条路线按数据保密要求和硬件条件选择。方案 A云端大模型 API适合测试阶段、数据不敏感的场景。通过 HTTP 调用云厂商的大模型接口把用户问题和上下文发送过去。优点是效果强不需要本地显卡缺点是数据出内网产线信息、设备参数、图纸数据都暴露给第三方而且断网时功能失效。工业场景里如果只是调试帮助、参数问答问题不大。但一旦涉及工艺文档、客户产品尺寸、未发布设备设计图纸就要谨慎。一个通用的云端 API 调用模板如下import requests # 以 OpenAI 兼容接口为例实际使用需替换为自己的 API 地址和密钥 api_url https://your-api-endpoint/v1/chat/completions api_key your-api-key payload { model: your-model-name, messages: [ {role: system, content: 你是非标自动化设备调试助手擅长机器视觉、运动控制、上位机问题排查。}, {role: user, content: 九点标定完成后验证精度时发现最大误差 0.3mm可能是什么原因} ], temperature: 0.2 } headers { Authorization: fBearer {api_key}, Content-Type: application/json } response requests.post(api_url, jsonpayload, headersheaders, timeout60) print(response.json()[choices][0][message][content])方案 B本地大模型适合产线内网、数据不能出厂的场景。常见的部署方式是 Ollama 配合开源模型比如 Qwen2.5 7B 或 14B。设备方面7B 模型量化后大约需要 6GB 显存能流畅跑如果只用 CPU建议 32GB 内存起步速度会慢一些。对非标自动化平台的 AI 助手来说7B 级别的模型做报错分类、参数解释、简单计算已经够用。Ollama 启动服务后无代码平台通过本地接口访问# 启动本地大模型服务模型名按实际拉取为准 ollama pull qwen2.5:7b ollama run qwen2.5:7bimport requests # 本地 Ollama 默认端口 11434 url http://127.0.0.1:11434/api/generate payload { model: qwen2.5:7b, prompt: S7-1200 的 S7 协议通讯不上常见原因有哪些, stream: False } response requests.post(url, jsonpayload, timeout120) print(response.json().get(response, ))方案 CRAG 知识库RAG检索增强生成是把设备手册、视觉算法说明、PLC 寄存器表、历史报错记录、操作规范做成向量知识库。AI 回答问题前先从知识库里检索相关资料再组织回答。这样回答更准确也更贴合自家设备的实际情况。无代码平台集成 RAG通常需要三个环节文档导入、文本切分和向量化、检索回答。典型流程是把视觉标定手册、伺服驱动器手册、PLC 寄存器表等内容整理成 PDF 或 Markdown导入平台的 AI 知识库模块。之后用户问“驱动器报警代码 A.510 是什么问题”时AI 从知识库检索到对应解释再结合现场参数给出排查建议。这种方式对非标自动化项目的价值非常大因为设备厂家和集成商积累的调试知识可以沉淀下来新工程师也能直接使用。实际项目中建议内部测试先用云端 API 快速验证流程后续再切到本地大模型加 RAG 组合。验证的重点是AI 助手能否正确理解设备描述能否调用平台工具回答是否稳定。6. AI 助手在无代码流程中的位置节点、工具、知识库三件事要让 AI 助手真正跟无代码平台打通不能只是做一个聊天框。工程化方案是拆成三个部分AI 节点、平台工具集、知识库。6.1 AI 节点AI 节点是无代码流程中的一个普通节点和其他视觉节点、运动控制节点一样可以被拖拽和连线。AI 节点的输入是文本或变量输出也是变量。例如输入变量产品型号、相机分辨率、检测区域坐标、当前报警代码输出变量推荐参数、排查建议、生成的脚本AI 节点可以在线调试直接运行当前流程把 AI 的输出显示在界面上。这样 AI 就不只是独立聊天工具而是流程的一部分。比如在自动检测流程里当视觉定位结果精度异常时AI 节点可以自动接收检测数据输出异常原因猜测并记录到日志文件。6.2 平台工具集Function CallingAI 要真正干活需要能调用平台内部能力。比如获取当前视觉检测的坐标、读取 PLC 寄存器值、查询历史报警、执行点位换算。这一步通常通过函数调用Function Calling实现。平台把工具函数暴露给 AIAI 根据用户问题选择调用哪个函数。示例函数定义如下{ functions: [ { name: calc_roi_points, description: 计算 ROI 区域坐标输入中心点、宽度、高度输出矩形四个角点, parameters: { type: object, properties: { center_x: {type: number}, center_y: {type: number}, width: {type: number}, height: {type: number} }, required: [center_x, center_y, width, height] } }, { name: get_plc_alarm, description: 获取 PLC 当前报警代码, parameters: { type: object, properties: { plc_ip: {type: string} }, required: [plc_ip] } } ] }平台收到 AI 返回的函数调用请求后自动执行对应函数把结果回传给 AI由 AI 组织成可读的答案。这个设计是 AI 助手能否落地的关键没有工具调用AI 只能聊天有了工具调用AI 才能帮助调试。6.3 知识库知识库是 AI 回答质量问题的重要保证。非标自动化调试最怕 AI 一本正经讲错参数。知识库可以把以下内容预先导入相机和镜头的选型手册光源型号及打光案例视觉算法节点参数说明伺服驱动器报警代码表PLC 寄存器地址表现场历史调试记录和解决方案知识库导入后需要在 AI 节点里启用“知识库增强”选项。用户提问时先检索相关片段再拼接到 Prompt 中。这样回答不会空泛而是能引用具体的设备型号和参数。7. 环境准备与部署方式从无代码平台到本地模型服务AI 助手集成后的部署涉及两个部分无代码平台本身的运行环境以及 AI 服务端。平台侧BnlAiCtrl 这类无代码平台通常在 Windows 上运行因为工业上位机大多是 Windows。需要保证系统满足 .NET 或 Java 运行环境要求具体以平台安装文档为准。同时要确认相机驱动、PLC 通讯库、运动控制卡的驱动已经安装。如果视觉检测用到 GPU 加速的深度学习模型还要安装 CUDA 和对应版本的推理依赖。AI 服务端如果选云端 API只需要在平台里配置 API 地址和密钥。如果选本地大模型需要准备一台单独的服务器或工作站。推荐配置因模型参数而异以 7B 模型为例GPU 方案NVIDIA 显卡 8GB 以上显存建议 12GBCPU 方案32GB 以上内存模型加载后推理速度较慢磁盘模型文件约 4GB 到 8GB操作系统LinuxUbuntu比 Windows 更省资源Windows 也能跑部署时建议先验证本地大模型能不能正常响应再接入无代码平台。这样排查问题时能分清是平台配置问题还是模型服务问题。启动检测常用命令包括# 查看本地模型服务是否在监听端口 curl http://127.0.0.1:11434/api/tags # Windows 下查看端口占用 netstat -ano | findstr 11434 # Linux 下查看 GPU 显存占用 nvidia-smi平台侧的启动方式以通用无代码平台为例一般是双击启动脚本或执行 start 命令。启动后浏览器打开本地 WebUI端口可能是 8080、7860 或自定义端口实际以平台版本为准。AI 助手的配置页面一般在系统设置或插件管理里需要填写模型服务地址、模型名、API Key如果有的话。8. 功能测试与效果验证AI 助手能跑通哪些任务AI 助手集成完成后建议按以下顺序做功能验证。不要一上来就测复杂任务先跑通最简单的对话再逐步加工具、加知识库。8.1 基础对话测试测试目的确认 AI 服务连通、平台能接收和返回文本。操作步骤启动无代码平台和 AI 服务。在 AI 助手页面输入“你好介绍一下你现在能帮我做什么”。点击发送。预期结果AI 返回一段可读的介绍且响应时间在可接受范围内。若是本地小显存模型几秒到几十秒都正常若是云端 API应在一两秒内响应。8.2 视觉参数配置测试测试目的确认 AI 能理解视觉场景并生成参数建议。输入示例相机分辨率 2448x2048视野 120mm x 100mm需要检测直径 10mm 的圆形零件定位精度要求 0.05mm。操作步骤把这段文字发给 AI 助手要求输出检测节点的 ROI、圆检测参数、像素当量。判断成功的标准AI 先计算像素当量2448 / 120 ≈ 20.4 像素每毫米再换算出 10mm 零件约为 204 像素直径给出最小半径 90、最大半径 110 之类的建议。同时提醒 ROI 应留出余量、光源和曝光会影响边缘提取。常见失败原因AI 没有做像素换算直接给出无意义的参数。此时应调整 Prompt要求“先计算像素当量再配置检测参数”。8.3 坐标转换工具测试测试目的确认 AI 能调用平台换算工具而不是自己硬算。输入示例旋转中心是 (500, 400)取料基准点是 (530, 420)物料旋转了 30 度求旋转后的取料点。操作步骤发送问题等待 AI 返回结果。预期结果AI 返回新的坐标值并显示计算过程。这里要特别检查 AI 是否真的调用了平台工具。如果 AI 直接让用户自己算说明工具调用配置有问题。如果 AI 算出的结果和手动计算一致则说明工具调用链路是通的。8.4 报错日志诊断测试测试目的确认 AI 能结合知识库解释报错。输入示例粘贴一段视觉节点报错日志“OpenCV Error: Insufficient memory (Failed to allocate bytes) in cv::OutOfMemoryError”。操作步骤发送日志并要求给出可能原因和排查顺序。预期结果AI 指出是内存不足可能原因包括图像分辨率过大、一次载入图像数量太多、系统可用内存不足给出排查顺序先查看单张图像大小再检查批量处理数量最后检查系统内存占用。8.5 批量任务测试测试目的确认 AI 节点能处理批量输入。操作步骤准备一个包含多行文本的输入文件每一行描述一个视觉检测任务例如检测区域A内的圆直径约8mm 检测区域B内的矩形边长约15mm 检测区域C内的圆和矩形混合数量各2个平台批量调用 AI 节点输出每一行的检测参数建议并保存为 CSV 文件。预期结果所有任务依次被执行遇到超时或失败时能自动重试输出结果和原始输入对应。批量任务设计时要考虑 AI 服务并发限制。本地大模型通常只能串行或低并发处理云端 API 并发上限更高但要注意限流和费用。平台侧要有失败重试和日志记录避免批量跑到一半全断掉。9. 接口 API 与二次开发把 AI 助手接到自己的工具链里无代码平台的一个优势是开放 API方便和其他系统对接。AI 助手集成之后也应能通过 API 调用。9.1 通用 AI 助手接口调用示例以下是一个通用的 HTTP 接口调用模板用于向 AI 助手发送问题并获取回答。实际路径和参数需要根据平台版本调整。import requests # 平台 AI 助手接口地址按实际版本替换 url http://127.0.0.1:8080/api/ai/chat payload { session_id: debug-001, message: 相机标定完成后重复性精度 0.1mm但绝对精度 0.5mm是什么原因, use_knowledge_base: True, enable_tools: True } response requests.post(url, jsonpayload, timeout120) if response.status_code 200: data response.json() print(AI 回答:, data.get(reply, )) print(调用到的工具:, data.get(used_tools, [])) else: print(调用失败:, response.status_code, response.text)9.2 批量流程接口设计批量视觉检测参数生成、批量报警日志分析这类任务建议用异步接口。先提交任务再轮询结果避免大任务堵住主流程。import requests import time # 1. 提交批量任务 submit_url http://127.0.0.1:8080/api/ai/batch submit_payload { task_type: vision_param_generate, items: [ {region: A, description: 检测直径 8mm 的圆}, {region: B, description: 检测边长 15mm 的矩形} ] } resp requests.post(submit_url, jsonsubmit_payload, timeout30) task_id resp.json().get(task_id) print(任务 ID:, task_id) # 2. 轮询任务状态 while True: status_url fhttp://127.0.0.1:8080/api/ai/batch/{task_id} status_resp requests.get(status_url, timeout30) result status_resp.json() print(当前状态:, result.get(status)) if result.get(status) completed: for item in result.get(results, []): print(item) break elif result.get(status) failed: print(任务失败:, result.get(error)) break time.sleep(5)9.3 批量任务的失败重试建议批量调用 AI 时由于网络波动、本地模型推理超时、云端 API 限流失败是常态。工程化方案需要做到每条任务独立记录状态失败不影响其他任务。设置单次超时时间超过 120 秒自动标记失败。失败任务最多重试 3 次重试间隔递增。所有请求和响应保存到日志目录方便排查。输入输出以文件方式组织例如input/放原始描述output/放结果log/放请求响应记录。10. 资源占用与性能观察本地模型和云端 API 怎么选AI 助手集成后的性能观察通常分三块模型服务资源、平台资源、网络延迟。如果是本地大模型显存占用是第一个指标。7B 量化模型运行时会占 6GB 左右显存14B 模型需要 10GB 以上。用nvidia-smi可以实时看显存使用情况。如果显存不足系统会开始用内存交换推理速度明显下降。更稳妥的做法是选择更小的模型或者增加 batch 处理间隔避免多个请求同时压到模型上。CPU 推理的情况要更耐心。以 32GB 内存的工控机跑 7B 模型为例生成 200 字回答可能需要几十秒到几分钟。这种速度不适合实时交互但用于离线批量日志分析、交接班报告生成仍然可行。云端 API 的性能瓶颈主要在网络和限流。每次请求都有一来一回的网络延迟通常在 1 秒到 3 秒之间。批量任务并发太高会触发限流这时需要加退避重试。在无代码平台上AI 节点对流程本身的开销不大。真正的开销是 AI 服务端。建议在正式使用前做一轮压力测试同时提交 5 个、10 个、20 个请求观察响应时间和失败率据此调整 AI 节点的并发数。11. 常见问题与排查方法问题现象可能原因排查方式解决方案AI 助手页面打不开平台服务未启动或端口被占用查看启动日志检查端口监听重启服务或更换端口AI 回复很慢本地模型显存不足或模型太大nvidia-smi 查看显存占用换小模型或增加显存AI 回复内容与设备无关知识库未启用或文档未导入检查知识库配置测试检索结果重新导入文档启用知识库增强AI 说“我没有这个工具”工具集未注册或函数调用异常查看平台日志中工具调用记录重新注册工具检查函数参数格式云端 API 返回 401API Key 错误或过期检查请求返回状态更换 API Key本地模型服务连不上Ollama 未启动或端口被改curl 访问 /api/tags启动模型服务确认端口批量任务部分失败网络波动或限流查看任务日志和重试记录增加超时时间和重试次数视觉参数建议不准Prompt 缺少相机和视野信息补充分辨率、视野、精度要求使用标准 Prompt 模板AI 生成的点位换算结果错误AI 未调用坐标工具而是自己推算检查函数调用日志强制指定调用工具并做验证报错诊断时 AI 只给通用建议知识库缺少设备手册检查知识库是否包含对应文档导入设备手册和报警代码表排查 AI 相关问题时要养成看日志的习惯。平台侧日志、模型服务日志、API 请求日志分别查看能快速定位问题在哪一层。不要一上来就怀疑 AI 模型能力更多时候是配置、网络或知识库的问题。12. 最佳实践与使用建议基于前面几篇系列文章和常用工程经验在非标自动化无代码平台里集成 AI 助手建议按以下顺序做。第一先做最小场景验证。不要一开始就想让 AI 接管整个调试流程。先选择一个高频、低风险的场景比如“根据报警代码给出排查步骤”跑通后再扩展到视觉参数配置、坐标转换、批量日志分析。第二把知识库当成长期资产来建设。每一次现场调试、每一次问题解决都记录下来并导入知识库。积少成多后AI 助手对新人的价值会越来越大。知识库文档建议按设备类型、模块类型、问题类型三个维度组织同时在文档开头写明适用的设备型号和软件版本。第三涉及工艺参数、客户产品数据、设备图纸时优先使用本地大模型。如果必须使用云端 API要做数据脱敏处理把产品名称、客户名称替换成代号。不要因为省事把核心数据直接提交到外部模型服务。第四AI 助手回答的视觉参数、运动控制参数必须经过实际验证才能用于生产。AI 给出的参数只能作为初始值或建议值最终要以设备实际运行效果为准。建议在无代码流程中为 AI 节点增加“验证确认识别”的现场操作步骤。第五批量任务要设计成可中断、可重试、可追溯。实际产线上批量任务可能跑数小时中途断电、断网、模型卡死都可能发生。任务状态要持久化重启后能恢复未完成任务。第六注意工具权限控制。AI 助手能调用工具后要限制其可调用的范围。例如只允许读取视觉检测结果和报警信息不允许直接修改 PLC 寄存器或运动控制参数。工具执行前增加人工确认环节防止 AI 误触发设备动作。13. 总结与下一步BnlAiCtrl 系列讲到这里视觉、运动控制、上位机、AI 助手四个模块就串起来了。这一篇的 AI 助手集成核心不是让聊天机器人回答几个问题而是让 AI 能调用视觉坐标换算、PLC 报警读取、参数推荐这些实际工具把自然语言变成可执行的配置和建议。这样做之后非标自动化的调试门槛会明显降低新人也能在知识库辅助下处理常见问题。如果你想在自己的项目里快速验证这套思路第一步建议先搭一套本地大模型服务接上无代码平台做一个“报警代码查询”场景。把 PLC 报警代码表导进知识库在 AI 助手页面输入一个真实报警代码看它能不能结合平台数据给出排查建议。跑通这个场景后再逐步增加坐标换算、视觉参数生成、批量日志分析等能力。最容易踩的坑是知识库没建好就期望 AI 给出准确答案。AI 模型本身不了解你的设备、你的相机、你的 PLC只有把设备手册和调试经验沉淀成文档AI 助手才能真正有生产力。建议收藏备用接下来照着最小场景一步一步做比一次性追求大而全更稳。 
长河君 · 2026/8/26 6:51:32 · 阅读 1.2k AI助手集成到非标自动化无代码平台：机器视觉与运动控制协同
这次我们来看 BnlAiCtrl 系列文章的第 7 篇AI 助手集成。前面六篇把机器视觉、运动控制、上位机这三个模块拆开讲过这一篇的重点是把 AI 助手真正接进非标自动化无代码平台里让它能参与视觉参数配置、运动控制点位计算、上位机报错诊断这些日常工作。先说结论BnlAiCtrl 这类非标自动化无代码平台核心价值是把视觉算法、运动控制逻辑、上位机界面通过拖拽节点的方式串起来降低工程师上手门槛。而 AI 助手集成要做的事情是把自然语言、知识库检索、报错解析、参数换算这些能力注入到节点编排流程中让不熟悉底层算法的调试人员也可以用大白话完成配置。这篇文章会讲清楚几个问题AI 助手到底能帮视觉、运动控制、上位机做什么本地大模型和云端大模型怎么选怎么把 AI 助手接到无代码流程节点里怎么验证效果接口调用和批量任务怎么设计以及最常见的坑有哪些。适合正在搞非标设备、自动化产线、机器视觉项目同时想用 AI 减负的工程师阅读。1. 核心能力速览能力项说明平台类型非标自动化无代码平台覆盖机器视觉、运动控制、上位机系列定位第 7 篇重点在 AI 助手集成AI 助手主要能力自然语言生成视觉配置、报错诊断、点位换算、PLC/上位机通讯辅助、知识库问答集成方式云端大模型 API 或本地大模型Ollama 等均可按数据保密要求选择是否支持批量任务支持AI 节点可嵌入批量处理流程如批量视觉检测参数生成、批量日志解析是否有 API无代码平台一般会暴露 HTTP APIAI 助手以接口服务方式接入具体路径以实际版本为准推荐硬件本地大模型需要 8GB 以上显存或 32GB 内存跑 CPU 推理云端 API 只需能访问外网支持平台Windows 为主工业上位机常用系统Linux 部署本地大模型更稳定适用场景非标自动化设备调试、视觉定位、运动控制联动、产线数据监控、报错快速排查使用边界涉及设备控制、产线参数、图纸数据时需确认数据是否可以出内网优先本地部署从表格可以看出AI 助手集成不是把 GPT 塞进平台那么简单核心价值是让 AI 能调用平台内部的能力比如读取当前视觉检测的坐标、查询设备的报警寄存器、生成一段 PLC 通讯配置。这才是无代码平台加 AI 的正确定位。2. 非标自动化平台的现状视觉、运动控制、上位机为什么需要 AI 助手非标自动化设备有个特点每个项目都不一样。A 项目是手机中框的视觉定位加四轴 SCARA 取放B 项目是锂电池表面的缺陷检测加伺服脉冲控制C 项目可能只是做一个数据采集上位机加 SCADA 监控。传统的实现方式每个项目都要重新写视觉脚本、重新调运动控制参数、重新做上位机界面周期长且依赖经验丰富的工程师。机器视觉这侧最常见的工作是定位和检测。定位时要处理旋转中心、取料基准点、手眼标定这些概念。比如热词里提到的场景“已经知道旋转中心且已经知道取料基准点如果物料与基准点发生旋转怎么换算新的取料位置”。这类问题在无代码平台里通常需要配置一个坐标转换节点输入旋转中心坐标、旋转角度、原始基准点输出旋转后的目标点。很多工程师第一次接触时对旋转矩阵、坐标系变换不熟调试半天也不对。运动控制这侧涉及脉冲输出、轴插补、伺服参数、PLC 通讯。热词里有一条是“通过双 DMA 实现脉冲输出 8 个轴插补能达到 500K3 轴可达 1M 的输出”这是嵌入式或板卡级运动控制的做法。在无代码平台里用户不需要写底层 DMA 驱动但需要理解轴参数怎么设、插补速度怎么配、回原点方式怎么选。这些参数的取值范围和调试顺序经验性极强。上位机这侧则是 C#、WPF、Qt、LabVIEW 这些技术栈的选择问题。热词里“C# 上位机 WPF 例程”“S7-1200 G2 的 S7 协议通讯与 PC 上位机如何搭建”“拿来就能用C# 上位机 PLC 实战项目”都在反映同一个需求上位机开发大量时间花在通讯对接、界面布局、报警处理上。这些痛点叠加在一起导致一个非标项目从进场到稳定生产很多时间都耗在参数调试和问题排查上。AI 助手切入的价值就是把这部分高重复、强经验的工作自动化一部分用自然语言描述目标平台生成配置把报错日志丢给 AI直接给出可能原因把旋转中心计算这类固定逻辑抽成工具让 AI 调用而不是让工程师手工推算。3. 机器视觉关键处理流程旋转中心、取料基准点、手眼标定的工程化落地AI 助手集成要能真正帮到机器视觉就要先把视觉处理里的高频逻辑固化下来。无代码平台的做法通常是把视觉节点封装成图像采集、标定、定位、检测、坐标转换、结果输出。3.1 旋转中心与取料基准点换算这是视觉定位里最容易出问题的地方。场景很明确物料在吸嘴或夹爪上绕着某个旋转中心转动一个角度后原来的取料基准点位置变了。如果平台已经通过标定得到旋转中心坐标也知道初始取料基准点那么任意旋转角度下新取料点的计算公式是固定的。核心数学逻辑是绕点旋转。已知旋转中心初始基准点旋转角度目标点的计算方式为import math def rotate_point(center_x, center_y, base_x, base_y, angle_deg): # 将角度转为弧度 angle_rad math.radians(angle_deg) cos_a math.cos(angle_rad) sin_a math.sin(angle_rad) # 将基准点平移到旋转中心为原点的坐标系 dx base_x - center_x dy base_y - center_y # 旋转 new_dx dx * cos_a - dy * sin_a new_dy dx * sin_a dy * cos_a # 平移回原坐标系 new_x center_x new_dx new_y center_y new_dy return new_x, new_y # 示例旋转中心 (100, 100)取料基准点 (120, 130)旋转 90 度 x, y rotate_point(100.0, 100.0, 120.0, 130.0, 90.0) print(f旋转后的取料位置: ({x:.2f}, {y:.2f}))在无代码平台里这个计算逻辑通常会被封装成一个“坐标旋转”节点。用户只需要填四个参数旋转中心 X、旋转中心 Y、基准点 X、基准点 Y、旋转角度输出就是新的取料点。AI 助手在这里的作用是当用户不记得角度正负方向、或者不确定旋转中心怎么标定时直接问 AI“我的物料逆时针旋转了 30 度旋转中心是 (520, 430)基准点是 (560, 460)取料点应该怎么填” AI 助手调用坐标旋转工具返回结果并解释计算过程。3.2 手眼标定与九点标定热词里多次出现“机器视觉手眼标定原理”。在实际项目中手眼标定要解决的核心问题是相机像素坐标怎么映射到机器人或运动平台的物理坐标。常见做法是九点标定在相机视野内均匀分布九个点记录像素坐标和实际机械坐标然后计算仿射变换矩阵。无代码平台一般会提供标定流程节点用户不需要手动解矩阵。AI 助手在这里可以做的是根据标定板布局、相机安装方式、运动平台行程推荐标定路径和点位数量。例如用户描述“相机固定安装在机台上方视野范围大约 100mm x 80mm”AI 可以给出标定路径建议按 3x3 网格移动每个位置拍照并记录坐标不要超出行程边界标定完成后用剩余点做验证计算重复精度。这个能力的前提是平台把标定流程和坐标结果暴露给 AI 工具。否则 AI 只能给建议不能直接干预流程。3.3 视觉检测参数生成视觉检测里最费时间的是调参数。圆检测要设最小半径、最大半径、边缘阈值、投票数。blob 分析要设灰度阈值范围、面积范围、圆度。模板匹配要设金字塔层数、匹配分数、旋转范围。无代码平台把算法封装成节点后参数数量还是很多。AI 助手集成后可以这样工作用户输入文字“在 ROI 区域 C 检测外径 8mm 到 10mm 的圆形零件要求 0.02mm 精度”平台先根据相机分辨率和视野比例把毫米换算成像素再给出一组初始参数写回到视觉节点的配置里。工程师确认后直接运行验证。这套流程不是把 AI 吹成无所不能而是把经验型参数配置变成可对话、可解释的过程降低首轮调试时间。4. 运动控制与上位机联动无代码编排如何支撑产线逻辑机器视觉和运动控制是紧密配合的。视觉算出目标位置运动控制就要执行到位。热词里“S7-200 SMART 运动控制实例”“S7-1200 G2 的 S7 协议通讯与 PC 上位机如何搭建”“grbl 上位机”“伺服运动控制仿真软件”都指向同一个问题工程师需要快速把逻辑跑通。BnlAiCtrl 这类无代码平台通常会把运动控制抽象成轴节点、点位节点、插补节点、IO 节点。用户在界面上拖拽连线就能实现“相机拍照 - 视觉定位 - 坐标转换 - 轴运动 - IO 触发”的完整流程。不需要写底层驱动也不需要直接操作 DMA 或脉冲输出寄存器。热词里那条“通过双 DMA 实现脉冲输出 8 个轴插补能达到 500K 3 轴可达 1M 的输出”说明在高阶应用里脉冲输出频率和轴数是硬指标。无代码平台如果走中间层必须保证不发指令延时、不丢指令。这里 AI 助手能帮忙的地方是根据轴数和速度要求推荐合适的脉冲频率、加减速时间。例如用户问“3 轴插补目标速度 800KHz应该怎么配加减速” AI 可以给出梯形加减速的加速度、减速度计算逻辑并提醒检查驱动器细分和最大输入脉冲频率限制。上位机层面C# WPF、Qt、LabVIEW 这些技术栈在传统开发里要写大量代码。无代码平台把这些封装成页面组件和变量绑定后用户拖拽就能出基础监控界面。但遇到定制逻辑时仍需要脚本节点。热词里“AI 写上位机软件有哪些”很能说明问题很多工程师希望 AI 直接生成上位机代码。在 BnlAiCtrl 里AI 助手的合理做法是生成“节点脚本”而不是整个上位机工程。例如用户说“设备启动时把所有轴回原点回完后弹窗提示”AI 生成对应的脚本片段用户粘贴到脚本节点中即可。这种联动方式的好处是AI 不替代无代码平台而是做平台和工程师之间的翻译层。工程师用自然语言描述需求AI 生成配置或脚本平台负责可靠执行。5. AI 助手集成的三种方案云端 API、本地大模型、RAG 知识库AI 助手要落地到非标自动化平台首先要想清楚模型放哪里。这里有三条路线按数据保密要求和硬件条件选择。方案 A云端大模型 API适合测试阶段、数据不敏感的场景。通过 HTTP 调用云厂商的大模型接口把用户问题和上下文发送过去。优点是效果强不需要本地显卡缺点是数据出内网产线信息、设备参数、图纸数据都暴露给第三方而且断网时功能失效。工业场景里如果只是调试帮助、参数问答问题不大。但一旦涉及工艺文档、客户产品尺寸、未发布设备设计图纸就要谨慎。一个通用的云端 API 调用模板如下import requests # 以 OpenAI 兼容接口为例实际使用需替换为自己的 API 地址和密钥 api_url https://your-api-endpoint/v1/chat/completions api_key your-api-key payload { model: your-model-name, messages: [ {role: system, content: 你是非标自动化设备调试助手擅长机器视觉、运动控制、上位机问题排查。}, {role: user, content: 九点标定完成后验证精度时发现最大误差 0.3mm可能是什么原因} ], temperature: 0.2 } headers { Authorization: fBearer {api_key}, Content-Type: application/json } response requests.post(api_url, jsonpayload, headersheaders, timeout60) print(response.json()[choices][0][message][content])方案 B本地大模型适合产线内网、数据不能出厂的场景。常见的部署方式是 Ollama 配合开源模型比如 Qwen2.5 7B 或 14B。设备方面7B 模型量化后大约需要 6GB 显存能流畅跑如果只用 CPU建议 32GB 内存起步速度会慢一些。对非标自动化平台的 AI 助手来说7B 级别的模型做报错分类、参数解释、简单计算已经够用。Ollama 启动服务后无代码平台通过本地接口访问# 启动本地大模型服务模型名按实际拉取为准 ollama pull qwen2.5:7b ollama run qwen2.5:7bimport requests # 本地 Ollama 默认端口 11434 url http://127.0.0.1:11434/api/generate payload { model: qwen2.5:7b, prompt: S7-1200 的 S7 协议通讯不上常见原因有哪些, stream: False } response requests.post(url, jsonpayload, timeout120) print(response.json().get(response, ))方案 CRAG 知识库RAG检索增强生成是把设备手册、视觉算法说明、PLC 寄存器表、历史报错记录、操作规范做成向量知识库。AI 回答问题前先从知识库里检索相关资料再组织回答。这样回答更准确也更贴合自家设备的实际情况。无代码平台集成 RAG通常需要三个环节文档导入、文本切分和向量化、检索回答。典型流程是把视觉标定手册、伺服驱动器手册、PLC 寄存器表等内容整理成 PDF 或 Markdown导入平台的 AI 知识库模块。之后用户问“驱动器报警代码 A.510 是什么问题”时AI 从知识库检索到对应解释再结合现场参数给出排查建议。这种方式对非标自动化项目的价值非常大因为设备厂家和集成商积累的调试知识可以沉淀下来新工程师也能直接使用。实际项目中建议内部测试先用云端 API 快速验证流程后续再切到本地大模型加 RAG 组合。验证的重点是AI 助手能否正确理解设备描述能否调用平台工具回答是否稳定。6. AI 助手在无代码流程中的位置节点、工具、知识库三件事要让 AI 助手真正跟无代码平台打通不能只是做一个聊天框。工程化方案是拆成三个部分AI 节点、平台工具集、知识库。6.1 AI 节点AI 节点是无代码流程中的一个普通节点和其他视觉节点、运动控制节点一样可以被拖拽和连线。AI 节点的输入是文本或变量输出也是变量。例如输入变量产品型号、相机分辨率、检测区域坐标、当前报警代码输出变量推荐参数、排查建议、生成的脚本AI 节点可以在线调试直接运行当前流程把 AI 的输出显示在界面上。这样 AI 就不只是独立聊天工具而是流程的一部分。比如在自动检测流程里当视觉定位结果精度异常时AI 节点可以自动接收检测数据输出异常原因猜测并记录到日志文件。6.2 平台工具集Function CallingAI 要真正干活需要能调用平台内部能力。比如获取当前视觉检测的坐标、读取 PLC 寄存器值、查询历史报警、执行点位换算。这一步通常通过函数调用Function Calling实现。平台把工具函数暴露给 AIAI 根据用户问题选择调用哪个函数。示例函数定义如下{ functions: [ { name: calc_roi_points, description: 计算 ROI 区域坐标输入中心点、宽度、高度输出矩形四个角点, parameters: { type: object, properties: { center_x: {type: number}, center_y: {type: number}, width: {type: number}, height: {type: number} }, required: [center_x, center_y, width, height] } }, { name: get_plc_alarm, description: 获取 PLC 当前报警代码, parameters: { type: object, properties: { plc_ip: {type: string} }, required: [plc_ip] } } ] }平台收到 AI 返回的函数调用请求后自动执行对应函数把结果回传给 AI由 AI 组织成可读的答案。这个设计是 AI 助手能否落地的关键没有工具调用AI 只能聊天有了工具调用AI 才能帮助调试。6.3 知识库知识库是 AI 回答质量问题的重要保证。非标自动化调试最怕 AI 一本正经讲错参数。知识库可以把以下内容预先导入相机和镜头的选型手册光源型号及打光案例视觉算法节点参数说明伺服驱动器报警代码表PLC 寄存器地址表现场历史调试记录和解决方案知识库导入后需要在 AI 节点里启用“知识库增强”选项。用户提问时先检索相关片段再拼接到 Prompt 中。这样回答不会空泛而是能引用具体的设备型号和参数。7. 环境准备与部署方式从无代码平台到本地模型服务AI 助手集成后的部署涉及两个部分无代码平台本身的运行环境以及 AI 服务端。平台侧BnlAiCtrl 这类无代码平台通常在 Windows 上运行因为工业上位机大多是 Windows。需要保证系统满足 .NET 或 Java 运行环境要求具体以平台安装文档为准。同时要确认相机驱动、PLC 通讯库、运动控制卡的驱动已经安装。如果视觉检测用到 GPU 加速的深度学习模型还要安装 CUDA 和对应版本的推理依赖。AI 服务端如果选云端 API只需要在平台里配置 API 地址和密钥。如果选本地大模型需要准备一台单独的服务器或工作站。推荐配置因模型参数而异以 7B 模型为例GPU 方案NVIDIA 显卡 8GB 以上显存建议 12GBCPU 方案32GB 以上内存模型加载后推理速度较慢磁盘模型文件约 4GB 到 8GB操作系统LinuxUbuntu比 Windows 更省资源Windows 也能跑部署时建议先验证本地大模型能不能正常响应再接入无代码平台。这样排查问题时能分清是平台配置问题还是模型服务问题。启动检测常用命令包括# 查看本地模型服务是否在监听端口 curl http://127.0.0.1:11434/api/tags # Windows 下查看端口占用 netstat -ano | findstr 11434 # Linux 下查看 GPU 显存占用 nvidia-smi平台侧的启动方式以通用无代码平台为例一般是双击启动脚本或执行 start 命令。启动后浏览器打开本地 WebUI端口可能是 8080、7860 或自定义端口实际以平台版本为准。AI 助手的配置页面一般在系统设置或插件管理里需要填写模型服务地址、模型名、API Key如果有的话。8. 功能测试与效果验证AI 助手能跑通哪些任务AI 助手集成完成后建议按以下顺序做功能验证。不要一上来就测复杂任务先跑通最简单的对话再逐步加工具、加知识库。8.1 基础对话测试测试目的确认 AI 服务连通、平台能接收和返回文本。操作步骤启动无代码平台和 AI 服务。在 AI 助手页面输入“你好介绍一下你现在能帮我做什么”。点击发送。预期结果AI 返回一段可读的介绍且响应时间在可接受范围内。若是本地小显存模型几秒到几十秒都正常若是云端 API应在一两秒内响应。8.2 视觉参数配置测试测试目的确认 AI 能理解视觉场景并生成参数建议。输入示例相机分辨率 2448x2048视野 120mm x 100mm需要检测直径 10mm 的圆形零件定位精度要求 0.05mm。操作步骤把这段文字发给 AI 助手要求输出检测节点的 ROI、圆检测参数、像素当量。判断成功的标准AI 先计算像素当量2448 / 120 ≈ 20.4 像素每毫米再换算出 10mm 零件约为 204 像素直径给出最小半径 90、最大半径 110 之类的建议。同时提醒 ROI 应留出余量、光源和曝光会影响边缘提取。常见失败原因AI 没有做像素换算直接给出无意义的参数。此时应调整 Prompt要求“先计算像素当量再配置检测参数”。8.3 坐标转换工具测试测试目的确认 AI 能调用平台换算工具而不是自己硬算。输入示例旋转中心是 (500, 400)取料基准点是 (530, 420)物料旋转了 30 度求旋转后的取料点。操作步骤发送问题等待 AI 返回结果。预期结果AI 返回新的坐标值并显示计算过程。这里要特别检查 AI 是否真的调用了平台工具。如果 AI 直接让用户自己算说明工具调用配置有问题。如果 AI 算出的结果和手动计算一致则说明工具调用链路是通的。8.4 报错日志诊断测试测试目的确认 AI 能结合知识库解释报错。输入示例粘贴一段视觉节点报错日志“OpenCV Error: Insufficient memory (Failed to allocate bytes) in cv::OutOfMemoryError”。操作步骤发送日志并要求给出可能原因和排查顺序。预期结果AI 指出是内存不足可能原因包括图像分辨率过大、一次载入图像数量太多、系统可用内存不足给出排查顺序先查看单张图像大小再检查批量处理数量最后检查系统内存占用。8.5 批量任务测试测试目的确认 AI 节点能处理批量输入。操作步骤准备一个包含多行文本的输入文件每一行描述一个视觉检测任务例如检测区域A内的圆直径约8mm 检测区域B内的矩形边长约15mm 检测区域C内的圆和矩形混合数量各2个平台批量调用 AI 节点输出每一行的检测参数建议并保存为 CSV 文件。预期结果所有任务依次被执行遇到超时或失败时能自动重试输出结果和原始输入对应。批量任务设计时要考虑 AI 服务并发限制。本地大模型通常只能串行或低并发处理云端 API 并发上限更高但要注意限流和费用。平台侧要有失败重试和日志记录避免批量跑到一半全断掉。9. 接口 API 与二次开发把 AI 助手接到自己的工具链里无代码平台的一个优势是开放 API方便和其他系统对接。AI 助手集成之后也应能通过 API 调用。9.1 通用 AI 助手接口调用示例以下是一个通用的 HTTP 接口调用模板用于向 AI 助手发送问题并获取回答。实际路径和参数需要根据平台版本调整。import requests # 平台 AI 助手接口地址按实际版本替换 url http://127.0.0.1:8080/api/ai/chat payload { session_id: debug-001, message: 相机标定完成后重复性精度 0.1mm但绝对精度 0.5mm是什么原因, use_knowledge_base: True, enable_tools: True } response requests.post(url, jsonpayload, timeout120) if response.status_code 200: data response.json() print(AI 回答:, data.get(reply, )) print(调用到的工具:, data.get(used_tools, [])) else: print(调用失败:, response.status_code, response.text)9.2 批量流程接口设计批量视觉检测参数生成、批量报警日志分析这类任务建议用异步接口。先提交任务再轮询结果避免大任务堵住主流程。import requests import time # 1. 提交批量任务 submit_url http://127.0.0.1:8080/api/ai/batch submit_payload { task_type: vision_param_generate, items: [ {region: A, description: 检测直径 8mm 的圆}, {region: B, description: 检测边长 15mm 的矩形} ] } resp requests.post(submit_url, jsonsubmit_payload, timeout30) task_id resp.json().get(task_id) print(任务 ID:, task_id) # 2. 轮询任务状态 while True: status_url fhttp://127.0.0.1:8080/api/ai/batch/{task_id} status_resp requests.get(status_url, timeout30) result status_resp.json() print(当前状态:, result.get(status)) if result.get(status) completed: for item in result.get(results, []): print(item) break elif result.get(status) failed: print(任务失败:, result.get(error)) break time.sleep(5)9.3 批量任务的失败重试建议批量调用 AI 时由于网络波动、本地模型推理超时、云端 API 限流失败是常态。工程化方案需要做到每条任务独立记录状态失败不影响其他任务。设置单次超时时间超过 120 秒自动标记失败。失败任务最多重试 3 次重试间隔递增。所有请求和响应保存到日志目录方便排查。输入输出以文件方式组织例如input/放原始描述output/放结果log/放请求响应记录。10. 资源占用与性能观察本地模型和云端 API 怎么选AI 助手集成后的性能观察通常分三块模型服务资源、平台资源、网络延迟。如果是本地大模型显存占用是第一个指标。7B 量化模型运行时会占 6GB 左右显存14B 模型需要 10GB 以上。用nvidia-smi可以实时看显存使用情况。如果显存不足系统会开始用内存交换推理速度明显下降。更稳妥的做法是选择更小的模型或者增加 batch 处理间隔避免多个请求同时压到模型上。CPU 推理的情况要更耐心。以 32GB 内存的工控机跑 7B 模型为例生成 200 字回答可能需要几十秒到几分钟。这种速度不适合实时交互但用于离线批量日志分析、交接班报告生成仍然可行。云端 API 的性能瓶颈主要在网络和限流。每次请求都有一来一回的网络延迟通常在 1 秒到 3 秒之间。批量任务并发太高会触发限流这时需要加退避重试。在无代码平台上AI 节点对流程本身的开销不大。真正的开销是 AI 服务端。建议在正式使用前做一轮压力测试同时提交 5 个、10 个、20 个请求观察响应时间和失败率据此调整 AI 节点的并发数。11. 常见问题与排查方法问题现象可能原因排查方式解决方案AI 助手页面打不开平台服务未启动或端口被占用查看启动日志检查端口监听重启服务或更换端口AI 回复很慢本地模型显存不足或模型太大nvidia-smi 查看显存占用换小模型或增加显存AI 回复内容与设备无关知识库未启用或文档未导入检查知识库配置测试检索结果重新导入文档启用知识库增强AI 说“我没有这个工具”工具集未注册或函数调用异常查看平台日志中工具调用记录重新注册工具检查函数参数格式云端 API 返回 401API Key 错误或过期检查请求返回状态更换 API Key本地模型服务连不上Ollama 未启动或端口被改curl 访问 /api/tags启动模型服务确认端口批量任务部分失败网络波动或限流查看任务日志和重试记录增加超时时间和重试次数视觉参数建议不准Prompt 缺少相机和视野信息补充分辨率、视野、精度要求使用标准 Prompt 模板AI 生成的点位换算结果错误AI 未调用坐标工具而是自己推算检查函数调用日志强制指定调用工具并做验证报错诊断时 AI 只给通用建议知识库缺少设备手册检查知识库是否包含对应文档导入设备手册和报警代码表排查 AI 相关问题时要养成看日志的习惯。平台侧日志、模型服务日志、API 请求日志分别查看能快速定位问题在哪一层。不要一上来就怀疑 AI 模型能力更多时候是配置、网络或知识库的问题。12. 最佳实践与使用建议基于前面几篇系列文章和常用工程经验在非标自动化无代码平台里集成 AI 助手建议按以下顺序做。第一先做最小场景验证。不要一开始就想让 AI 接管整个调试流程。先选择一个高频、低风险的场景比如“根据报警代码给出排查步骤”跑通后再扩展到视觉参数配置、坐标转换、批量日志分析。第二把知识库当成长期资产来建设。每一次现场调试、每一次问题解决都记录下来并导入知识库。积少成多后AI 助手对新人的价值会越来越大。知识库文档建议按设备类型、模块类型、问题类型三个维度组织同时在文档开头写明适用的设备型号和软件版本。第三涉及工艺参数、客户产品数据、设备图纸时优先使用本地大模型。如果必须使用云端 API要做数据脱敏处理把产品名称、客户名称替换成代号。不要因为省事把核心数据直接提交到外部模型服务。第四AI 助手回答的视觉参数、运动控制参数必须经过实际验证才能用于生产。AI 给出的参数只能作为初始值或建议值最终要以设备实际运行效果为准。建议在无代码流程中为 AI 节点增加“验证确认识别”的现场操作步骤。第五批量任务要设计成可中断、可重试、可追溯。实际产线上批量任务可能跑数小时中途断电、断网、模型卡死都可能发生。任务状态要持久化重启后能恢复未完成任务。第六注意工具权限控制。AI 助手能调用工具后要限制其可调用的范围。例如只允许读取视觉检测结果和报警信息不允许直接修改 PLC 寄存器或运动控制参数。工具执行前增加人工确认环节防止 AI 误触发设备动作。13. 总结与下一步BnlAiCtrl 系列讲到这里视觉、运动控制、上位机、AI 助手四个模块就串起来了。这一篇的 AI 助手集成核心不是让聊天机器人回答几个问题而是让 AI 能调用视觉坐标换算、PLC 报警读取、参数推荐这些实际工具把自然语言变成可执行的配置和建议。这样做之后非标自动化的调试门槛会明显降低新人也能在知识库辅助下处理常见问题。如果你想在自己的项目里快速验证这套思路第一步建议先搭一套本地大模型服务接上无代码平台做一个“报警代码查询”场景。把 PLC 报警代码表导进知识库在 AI 助手页面输入一个真实报警代码看它能不能结合平台数据给出排查建议。跑通这个场景后再逐步增加坐标换算、视觉参数生成、批量日志分析等能力。最容易踩的坑是知识库没建好就期望 AI 给出准确答案。AI 模型本身不了解你的设备、你的相机、你的 PLC只有把设备手册和调试经验沉淀成文档AI 助手才能真正有生产力。建议收藏备用接下来照着最小场景一步一步做比一次性追求大而全更稳。