1200PLC与爱普生机器人modbus_TCP通讯

1200PLC与爱普生机器人modbus_TCP通讯

1.前言

首先申明一下我的硬件信息

机器人:C4-A601S

控制器:RC700

PLC:西门子S7-1200(CPU:1217C/DC/DC/DC)

2.控制器IP地址查看及修改

在配置控制器相关信息时需要先用网线连接PC与机器人控制器连接,爱普生机器人出厂设定网址为192.168.0.1(我这里是之前修改过了)

若默认没有显示以太网连接,点击右侧的增加,选择“通过以太网连接到控制器”后点击确定

如果控制器网址被修改过了,不知道是多少,可以用一根PC线,一头接在控制器的“开发用PC连接专用USB端口”另一头接在电脑USB口

这时候再在通讯处选择USB连接就可以通上了

现在就可以在“系统配置”处看到控制器的IP地址以及相关信息了,如果有需要也可以直接在这修改IP地址。

3.机器人控制器配置

网线连接好后开始配置通讯相关信息

1.控制设备

控制设备修改为远程I/O

2.现场总线

现场总线类型修改为“Modbus TCP”

端口号记住PLC配置时要用到,也可以视情况进行修改

3.修改线圈地址

在远程控制➡输入/输出处,对应信号的线圈进行修改,修改为512~2559的任意一个值

修改信号线圈是因为爱普生机器人的MODBUS地址分布,保持性寄存器对应的线圈是从512开始的

如果还是使用原线圈,就无法通过Modbus通讯进行这些信号控制

不用全部信号都修改,根据实际情况修改即可,若是只需要机器人运行,停止(不需要暂停、继续、复位),那么就只需要修改Start、Stop的对应线圈即可。

4.控制器重启

参数都修改好后点击“应用”并关闭“设备控制器”,控制器会进行重启

重启好后再点开“设备控制器”看看参数是否都修改成功

4.PLC配置

1.MB_CLIENT

因为是由PLC作为主站,所以选用MB_CLIENT指令

2.TCON_IP_V4

建立一个TCON_IP_V4数据用于设置连接所需要的地址参数

3.读写数据

还需要新建word用于存储数据或是写入数据(指针指向的地址),根据实际情况增加或减少word个数

5.通讯测试

PLC与机器人都配置好后就可以进行通讯测试了

随便写一个程序写入,方便观察机器人运行状态

打开爱普生的“I/O监视器”,将监视的信号类型修改为现场总线从站输入/输出,方便实时观察信号线圈的通断情况

打开“运行控制台”并激活远程I/O

修改word值后写入,由于之前将start的线圈修改为512,stop线圈修改为513

所以写入1时,机器人512线圈得电,机器人启动

写入2时,机器人513线圈得电,机器人停止

能在I/O监视器看到写入的信号状态,就通讯成功了

6.注意事项

不要用错通讯指令了,爱普生默认不支持作为 Modbus TCP 主站,仅支持作为Modbus TCP 从站(Server)与外部设备(如 PLC、上位机)通讯。

若业务需要机器人主动读取外部设备数据(主站功能),可通过以下方式实现:

  • 方案 1:使用 TCP Socket 编程:通过 RC + 的SetNet/OpenNet/Input/Print等指令,自定义 TCP 通讯逻辑,让机器人主动建立连接并读取外部设备数据(需外部设备支持 TCP Server 模式);
  • 方案 2:借助中间设备:通过 PLC 作为中转(PLC 同时作为 Modbus TCP 主站 + TCP Client),机器人与 PLC 通过 TCP 通讯获取数据。

Read more

VSCode Github Copilot使用OpenAI兼容的自定义模型方法

VSCode Github Copilot使用OpenAI兼容的自定义模型方法

背景 VSCode 1.105.0发布了,但是用户最期待的Copilot功能却没更新!!! (Github Copilot Chat 中使用OpenAI兼容的自定义模型。) 🔥官方也关闭了Issue,并且做了回复,并表示未来也不会更新这个功能: “实际上,这个功能在可预见的未来只面向内部人员开放,作为一种“高级”实验功能。是否实现特定模型提供者的功能,我们交由扩展作者自行决定。仅限内部人员使用可以让我们快速推进,并提供一种可能并非始终百分之百完善,但能够持续改进并快速修复 bug 的体验。如果这个功能对你很重要,我建议切换到内部版本 insider。” 🤗 官方解决方案:安装VSCode扩展支持 你们完全不用担心只需要在 VS Code 中安装扩展:OAI Compatible Provider for Copilot 通过任何兼容 OpenAI 的提供商驱动的 GitHub Copilot Chat,使用前沿开源大模型,如 Kimi K2、DeepSeek

Copilot助力AI原生应用:提升开发效率的5种方法

Copilot助力AI原生应用:提升开发效率的5种方法 关键词:GitHub Copilot、AI原生应用、开发效率、代码生成、智能补全、上下文感知、开发协作 摘要:在AI原生应用(AI-Native Apps)的开发浪潮中,开发者面临着代码复杂度高、迭代速度快、跨模态能力需求强等挑战。作为GitHub与OpenAI联合推出的AI代码助手,GitHub Copilot通过“代码即自然语言”的交互方式,正在重塑开发者的工作流。本文将结合真实开发场景,拆解Copilot提升效率的5种核心方法,并通过实战案例演示如何在AI原生应用中最大化发挥其价值。 背景介绍 目的和范围 本文旨在帮助开发者(尤其是AI原生应用开发者)掌握GitHub Copilot的核心能力,通过具体方法和实战案例,解决“如何用AI工具提升开发效率”的实际问题。内容覆盖从基础功能到高阶技巧,适用于前端、后端、全栈开发场景。 预期读者 * 正在开发AI原生应用(如智能客服、推荐系统、AIGC工具)的开发者 * 希望优化现有开发流程的技术团队 * 对AI辅助开发工具感兴趣的技术管理者

Ollama下载模型太慢?试试国内HuggingFace镜像+LLama-Factory组合

Ollama下载模型太慢?试试国内HuggingFace镜像+LLama-Factory组合 在本地跑一个大模型,第一步不是写代码、调参数,而是——等它下载完。 这听起来有点荒诞,却是许多中国开发者的真实日常。当你兴致勃勃地打开终端,输入 ollama run llama3:8b,满心期待地准备开启微调之旅时,现实却给你泼了一盆冷水:进度条纹丝不动,网络连接频繁中断,几个小时过去连基础权重都没拉下来。 问题出在哪?根源就在于——Ollama 默认从 HuggingFace 官方仓库拉取模型,而这个服务器远在海外。对于国内用户来说,这无异于“越洋取经”,不仅速度慢如龟爬,还常因网络波动导致失败重试,白白浪费时间和算力资源。 但其实,我们完全不必硬扛这条路。真正聪明的做法是:绕开公网瓶颈,借助国内镜像高速获取模型 + 使用 LLama-Factory 实现低门槛、高效率的本地微调。这套组合拳不仅能让你把“等待下载”的时间省下来喝杯咖啡,还能让7B甚至13B级别的模型在一张消费级显卡上顺利训练起来。 镜像加速:别再用裸连 HuggingFace

农业机器人如何自主导航?:5大核心路径规划算法深度解析

第一章:农业机器人自主导航与路径规划概述 农业机器人在现代精准农业中扮演着日益重要的角色,其核心能力之一是能够在复杂多变的农田环境中实现自主导航与高效路径规划。这一过程不仅依赖于高精度的环境感知系统,还需融合多种算法模型以应对非结构化地形、动态障碍物及作业任务的多样性。 自主导航的基本构成 农业机器人的自主导航通常由三个关键模块组成: * 定位:通过GPS、IMU与SLAM技术确定机器人在田间的实时位置 * 地图构建:利用激光雷达或视觉传感器生成环境的二维或三维表示 * 运动控制:将规划路径转化为电机指令,驱动机器人沿预定轨迹行驶 典型路径规划算法对比 算法优点缺点A*全局最优路径,适用于静态环境计算开销大,难以应对动态障碍Dijkstra保证最短路径搜索范围广,效率较低RRT适用于高维空间和非完整约束路径不平滑,随机性较强 基于ROS的路径规划代码示例 以下是在ROS(Robot Operating System)中使用A*算法进行栅格地图路径搜索的核心片段: // A* 路径搜索核心逻辑 std::vector<Node> astar_path(c