已屏蔽 原因:{{ notice.reason }}已屏蔽
{{notice.noticeContent}}
~~空空如也

今天考虑了RS485上的通讯协议 大致确定以下各点 (只是草案 但是已经感觉复杂了 可能我只会实现部分) .... 今晚又补充了那么多细节 暂时先按这个实现吧 我感觉主机都要交出总线 自我禁用了 ... 就一个一维的位置信息指定 搞出那么多花样 我自己也有点服了

  1. 最小信息传递单位是1byte 比特率缺省1Mbps(这里有个参数) 使用双绞线 

  2. 兼容RS485一主多从的通信协议 最高位为1 表明是地址码

  3. 普通从机地址码从1开始递增 虚拟组地址从126开始往下降 0和127保留 (可能分别给主机和外部系统)

  4. 主机进行总线控制 通过协议明式把控制权交给从机 从机应通过协议明式交换回主机或给其他从机 没有控制权的设备不允许发声 从机失去响应 超时没有发声(这里有个超时参数) 如果总线是1状态 主机可以主动发起新地址上的通信 抢夺回控制权 并且作废产生超时的通信中 部分已收到的回复

  5. 主机应该在发送时候同时监听总线 如果发送与监听的不一致  说明总线上产生了冲突 主机可以在延时一个随机短时间后 多次发送地址码夺回总线 如果一直失败 根据情况可以向上位机发送报告 发送紧急告警等

  6. 从机如果回复主机 进行一次简单问答 无须地址码 但是如果得到总线授权 也可以采用类似的主机的地址码加命令的方式 对其他从机进行控制

  7. 虚拟组地址不进行未在协议中声明的通信 保留所有未使用的信息位和地址 其他私有协议可以通过普通从机地址进行

  8. 设备编号ID:1-127 当出现ID0时候 表明对所有设备群发 此时主机不应该发送任何需要回应的命令 除非能够有新机制避免总线冲突

  9. 所有参数均高字节先发 高位先发 未知长度的参数 包括字符串和二进制串 采用先送 2字节长度 再送内容 字符串同时应该有0结尾 因为最高位不能用 所以一字节只能表示7位二进制 两字节表示14位数 如此类推 有符号数 最高位为符号标志

  10. 除了运动控制命令是流 没有长度限制 其他管理和非持续性控制类命令 再次进行时候 都需要重新发送地址位 每次通信只进行一次命令 每组命令应该尽量定长 或者可以在已经收到的定长的内容 推断出之后的信息长度 并且有方法判断整个命令已经传递完成 如果剩下不能定长的内容 通常应该是解释性 可选性和文字性的

  11. 从机出现严重错误 会影响整个系统 产生损失性危害时 可以在总线为1的时候 强行发布急停命令 可以定期重复发送 (但应考虑冲突 不能发送太快 不能占用超过1/100的总线时间 在这短时间内的总线冲突不会损害总线通信设备) 发送地址为126 

  12. 地址126 必须实施  是紧急告警通道 无论主机或者从机均可以短时间强行发送 可以只发送一个地址 也可以后跟一个字符串二进制串 所有设备应该在遇到这个地址时候立即采用能最大减少损失的措施 比如停止运行 释放压力 而相关安全设备可能反而需要紧急启动 提供压力

  13. 地址125 必须实施  是设备管理通道 

    1. 第一个字节是要通信的设备ID

    2. 如果ID为0群发  则任何命令 即使是原本需要回复的命令 无须回答 主机也默认已被成功执行

    3. 如果需要回复 从机先发一个字节的回复码 然后再跟具体内容(如果有的话) 回复码含义:

      1. 0: 成功 可能有回复内容也可能没有 但是这次通信已经完成

      2. 1: 成功 并跟回复内容 但是这次通信并未完成 后续还有其他内容 直到最后一个回复码为0 或者其他失败 如果最终失败 主机应该忽略已经收到的部分内容 保证事务性

      3. 2: 需要等待 并不跟后续内容 这个回复码会定期重复发送 防止主机认为软超时 (但是主机应该有硬超时设置 再等不到回答 会强行中断抢夺总线) 

      4. 3: 操作失败

      5. 4: 不支持

      6. 5. 协议理解失败 比如不支持其中的子协议

      7. 6: 协议内容理解 比如虽然支持 但是内容并未正确识别 或者校验码等错误

    4. 第二个字节是命令

      1. 0: 空操作 后续无它 无须回答 主机可以用此进行总线争夺之类的命令(需要检测总线冲突) 或者使用这个终止前面未传达完的命令 已传达完的命令 在等待回复期间 主机无法用这个来撤销前面的命令

      2. 1:禁用和复位设备 后续无它 设备应该回复 (如果不是群发) 设备之后将不再响应原本该响应的信号 并进行复位 清除所有历史信息和状态 直到重新被启用 如果是运动设备 应释放所有出力  不需要保持任何之前的运动状态 (也是运动设备缺省状态 而其他设备可以直接上线就运行) 

      3. 2:暂停设备 后续无它 设备应该回复 (如果不是群发) 设备之后将不再响应原本该响应的信号 并将状态转变为就绪 直到重新被启用 但是应该保存状态性信息 如果是运动设备 应释放所有出力 但需要保持任何之前的运动状态

      4. 3:屏蔽设备 后续无它 设备应该回复 (如果不是群发) 设备之后将不再响应原本该响应的信号 但是仅仅是等效于未收到指令 其他保持不变 直到重新被启用 如果是运动设备 将不再接受之后的运动指令 但是当前出力状态应该保持

      5. 4:启用设备 后续无它 设备应该回复 (如果不是群发)

      6. 5:设备ID赋予 后面跟随二进制串的字符串 具有该字符串内部码的设备(一般是由设备公布 并且固定 比如MAC码 MCU独特码等) 将获得协议中第一个字节的ID 并发送回复码. 而原有该ID的设备不需回应 但应该放弃原有编码 其编码丢失 并写入自身配置持续化下来  等同被屏蔽 除非再次获得ID 

      7. 6:同步标志 后面跟随4字节的时间码 一般群发 设备无须回复 时间码没有具体的时长标准 根据主机的定时计数决定 强名其单位为"刻" 

        时间码有循环时间 4字节只能提供实际无符号28位的信息 主机应该保证发送间隔不超过其一半的循环时间 如果一刻是1微秒 主机需要在130秒内再次发送 如果超过这个时间 前面的定时同步均失效 如果同步间隔太短 从机会太忙 而且同步精度会降低 建议0.1-1秒内同步一次 至少两次成功同步 从机才能建立基本的时间系统 后面需要时间参数的运动命令才能被执行 但是从机可以考虑通过更多的同步数据 获取更精密的时间标准 包括与主机的差距 比例 和抖动的程度等

      8.  7 同步失效 后面跟随4字节的时间码 一般群发 设备无须回复 后面跟随4字节的时间码 立即废止前面的时间参考 同时提供新参考的第一个同步时戳

      9. 8 同步时刻  后面跟随4字节的时间码 一般群发 设备无须回复 后面跟随4字节的时间码 在不改变时间比例的同时 立即宣布一个新时刻

      10. 9 精密同步(可选 该方案待定 不应实施) 不进行群发 设备必须回复 后跟随4字节的时间码 设备应立即回复回复码 跟4字节它之前收到的最后一个回复码 然后主机收到后再次发送一次4字节的更新的时间码 结束通信

      11. 10 总线授予/交回 不能群发 后续无须字节 如果ID不为0  是主机将总线授予对应ID的设备 然后主机保持沉默 等待总线交回 或者超时时间到 未收到总线任何信号 则可以发命令0收回总线 如果ID为0 是从机主动交回总线 主机可以立即使用总线

      12. 11 设备状态查询 不能群发 后续无它 设备返回一个字节回复码 再是一个字节的状态码

        1. 0 表明设备正常工作

        2. 1 设备出现控制性的致命性异常 无法正常控制

        3. 2 设备出现可恢复性的控制上的错误 

        4. 3 设备出现告警

        5. 4 设备正在初始化 

        6. 5 设备已经可接受部分指令 但是精度尚未到位 比如同步时基尚未建立或者发现较大抖动

        7. 6. 设备基本达标 但是未完全稳定 尚未到最佳 建议不要进行大应力操作

        8. 7. 设备环境出现不好的预期 比如冷却水温过高等

        9. 8 设备环境出现影响性问题

        10. 9 设备环境出现致命性问题

        11. 10 设备发生轻微堵转等细微的 可恢复的机械性问题

        12.  11 设备发生碰撞等影响有 但是不算大的机械故障

        13. 12 设备发生严重机械性损坏 比方说撞车了 轴歪了

        14. 127 设备触发预订信号1 比如位置检测 HOME 人为按下按钮等

        15. 126 设备触发预定信号2

        16. 125 .....


      13. 12 设备属性查询 不能群发 后跟查询地址2个字节 (有效14位) 从机先回复回复码 然后回复长度打头的二进制串 主机应该理解从机回复数据其含义 比如可能是1位的状态 16位的PWM设置 等等 不在本协议的范围内

      14. 13 设备属性设置 不应群发 除非主机已知设置地址的共通性 后跟设置地址2个字节 这个地址与查询地址应该有相通性 再跟主机理解的长度打头的二进制串 具体含义也不在本协议范围内

      15. 127 文本协议转发 后跟长度打头(0-16383不包括长度本身 )的二进制串 等待设备回复或者超时 设备回复位1字节的回复码 然后跟长度打头的二进制串 数据均为0-127的ASCII码 无须包装 注意一次收发结束后 需要再次进行 要重新从地址码开始

      16. 126 文本协议转发 后跟长度打头(0-16383不包括长度本身 )的二进制串 等待设备回复或者超时 设备回复位1字节的回复码 然后跟长度打头的二进制串 数据均为utf-8编码 然后进行8位转7位的串流包装 用8个字节包装7个字节 注意一次收发结束后 需要再次进行 要重新从地址码开始

      17. 125 MODBUS协议转发 同前面 数据流也是8位转7位的串流包装 

  14. 地址124-121 保留给使用者自定制的运动控制协议 以及以其他方为主的协议 比如klipper的MCU命令 系统如果使用该地址 必须自己了解该地址上的协议 之后的地址均为可选支持

  15. 地址120 字节流方式 是模拟传统DIR-PUL协议简单实现的虚拟地址 支持4轴系统的同步运动 和共16轴系统的异步运动 运动型设备支持的话 应该监听这个地址 要么全部忽略这个地址上的通信 通信的长度没有限制 直到下一个地址出现 重新进入这个地址将持续之前的状态 其通信字从0-127有以下含义

    1. 0-80 为4轴系统的同步步进和方向控制 以3进制编码 共4位对应运动设备(从低位往上对应ID为1..4的设备) 0表示不动 1表示前进一步 2表示后退一步

    2. 81 -104 为4轴外其他轴的异步步进和方向控制 81表明ID为5的运动设备前进一步 其他设备不动 82表明 ID为5的运动设备后退一步 83表明ID为6的运动设备前进一步 ... 如此类推 可以支持ID为5-16运动设备的异步运行

    3. 105-120 为运动设备的状态查询 同时这条命令之后 该地址上的字节流将暂停 设备返回查询结果后 105查询ID为1的设备  106查询ID为2的设备  .. 120查询ID为16的设备 设备收到命令 立即返回一个不带地址等数据的字节即可 主机收到回应 立即可以恢复字节流 如果超时 主机需要重新发送地址 夺回总线控制权 从机返回的内容不应该有运动的歧义 以免让其他运动设备误判 其含义如下:

      1. 121 表明设备正常

      2. 122 设备致命性异常

      3. 123 设备出现可恢复性错误 或者在初始化中 需要等待

      4. 124 设备触发预订信号 比如位置检测 HOME 人为按下按钮等

      5. 125 设备运动遇到下限

      6. 125 设备运动遇到上限

      7. 127 设备遇到更复杂情况 需要更复杂的通信协议 主机应该使用其他地址获得进一步信息

  16. 地址119 - 保留

  17. 地址118 多轴同步带纠错纯运动控制 字节流 

    1. 每个运动设备使用3个位 1个字节中 2个运动设备 分别使用bit0-2 bit3-5 ID小的使用低的位

    2. bit5为延续标准 如果该字节后还有其他轴的字节 则为1 这样1-2号运动设备使用字节1 2-4号用字节2 以此类推 直到最后一个字节 此时bit5应该为0 表明一组运动传输完毕

    3. 运动设备收到自己的控制码 并不立即进行运动 直到收到最后一个控制码 bit5为0  才同步进行运动

    4. 设备查询 本协议没有足够空间 可用采用地址120和125上的功能

    5. 每个设备的3位 采用3位格雷码进编码 比如从其中3变成4 是前进一步  7变成5是后退两步 7变成1却是前进两步 可用表示位置变化可用从-3到+3 编码利用率达到7/8 比2位法要高 即使轴数为奇数 少用了几乎半个字节 因此也相差不大 而轴数为偶数时 更是超过传统编码的速度 其纠错有两种

      1. 采用格雷码 即使错了一位 误差也仅一步

      2. 当需要更多纠错的时候 无须双方设置 只需要主机保证只使用-2到2或-1到1的位置位移 可用达到用带宽换可靠的效果 即使丢失整个字节 从机可以根据"采用位置变化绝对值最小的可能" 进行纠错 比如从3缺了4到5 从机显然会认是从3到5走两步 而不是反方向3210765走6步

  18. 地址117 本想采用Sigma-Delta等新式调制方法 利用其自纠错 可重采的特点 但是仿真看来不容易实现 而且也有许多性能问题 即使4阶亦不如人意 而且特别复杂 先打住 保留 以后留给更好的算法 

  19. 地址116是学习模式 主机控制运动设备返回位置变化信息 采用轮询方式获取信息 (目前还没投心思 仅作为想法保留)

    1. 第一个字节是要通信的运动设备ID 

    2. 第2个字节是命令字

      1. 0: 结束采样

      2. 1: 开始采样

      3. 2:要求运动设备返回采样结果 可以是多个采样结果 采样结果的编码根据采样设置而定

        1. 从机返回成功/失败码 采样结果数量 采样结果(包括采样时间) CRC32校验码

      4. 3: 采样设置协议未定 应包含采样策略 缓冲策略

        1. 采样策略包括定时采集 位置变化和其导数大时候采集 编码溢出采集

        2. 缓冲策略包括采集深度 绝对编码和相对编码选择等

  20. 从1开始为常规设备 与运动设备的编号并不需要一致 但是运动设备也可以使用这里的地址 兼容普通设备 进行私有协议的通信

文号 / 926706

千古风流
名片发私信
学术分 1
总主题 54 帖总回复 905 楼拥有证书:进士 学者 机友
注册于 2020-01-22 18:44最后登录 2024-12-19 14:41
主体类型:个人
所属领域:无
认证方式:手机号
IP归属地:上海

个人简介

个人开源项目: m24h.github.io

文件下载
加载中...
{{errorInfo}}
{{downloadWarning}}
你在 {{downloadTime}} 下载过当前文件。
文件名称:{{resource.defaultFile.name}}
下载次数:{{resource.hits}}
上传用户:{{uploader.username}}
所需积分:{{costScores}},{{holdScores}}下载当前附件免费{{description}}
积分不足,去充值
文件已丢失

当前账号的附件下载数量限制如下:
时段 个数
{{f.startingTime}}点 - {{f.endTime}}点 {{f.fileCount}}
视频暂不能访问,请登录试试
仅供内部学术交流或培训使用,请先保存到本地。本内容不代表科创观点,未经原作者同意,请勿转载。
音频暂不能访问,请登录试试
投诉或举报
加载中...
{{tip}}
请选择违规类型:
{{reason.type}}

空空如也

插入资源
全部
图片
视频
音频
附件
全部
未使用
已使用
正在上传
空空如也~
上传中..{{f.progress}}%
处理中..
上传失败,点击重试
等待中...
{{f.name}}
空空如也~
(视频){{r.oname}}
{{selectedResourcesId.indexOf(r.rid) + 1}}
处理中..
处理失败
插入表情
我的表情
共享表情
Emoji
上传
注意事项
最大尺寸100px,超过会被压缩。为保证效果,建议上传前自行处理。
建议上传自己DIY的表情,严禁上传侵权内容。
点击重试等待上传{{s.progress}}%处理中...已上传,正在处理中
空空如也~
处理中...
处理失败
加载中...
草稿箱
加载中...
此处只插入正文,如果要使用草稿中的其余内容,请点击继续创作。
{{fromNow(d.toc)}}
{{getDraftInfo(d)}}
标题:{{d.t}}
内容:{{d.c}}
继续创作
删除插入插入
插入公式
评论控制
加载中...
文号:{{pid}}
加载中...
详情
详情
推送到专栏从专栏移除
设为匿名取消匿名
查看作者
回复
只看作者
加入收藏取消收藏
收藏
取消收藏
折叠回复
置顶取消置顶
评学术分
鼓励
设为精选取消精选
管理提醒
编辑
通过审核
评论控制
退修或删除
历史版本
违规记录
投诉或举报
加入黑名单移除黑名单
查看IP
{{format('YYYY/MM/DD HH:mm:ss', toc)}}
ID: {{user.uid}}