modbus 串口通信,怎么区分2次返回的数据!

女神打Boss 2016-03-22 10:30:38
我用的是SerialPort串口通信类,读函数每次读取1个字节
比如 发送命令 01 10 00 50 00 14 c0 17 返回 01 10 00 50 00 14 c0 17

发送2次命令就返回01 10 00 50 00 14 c0 17 01 10 00 50 00 14 c0 17这样一个字符串,我该怎么把2次返回的数据分开。

判断 某字符是 01 然后xx长度之后进行crc校验,这样是否可以保证成功。

如果不行,有没有其他好办法,或者有更简单的办法
...全文
918 16 打赏 收藏 转发到动态 举报
写回复
用AI写文章
16 条回复
切换为时间正序
请发表友善的回复…
发表回复
女神打Boss 2016-05-04
  • 打赏
  • 举报
回复
每条命令返回的数据长度是固定的。发命令的时候就知道返回数据的长度了。
schlafenhamster 2016-03-24
  • 打赏
  • 举报
回复
schlafenhamster 2016-03-23
  • 打赏
  • 举报
回复
是“ModBusPcMaster.rar”,找不到我给你发
女神打Boss 2016-03-23
  • 打赏
  • 举报
回复
引用 7 楼 schlafenhamster 的回复:
搜索 “ModBusPcMaster”
大神你好,这个ModBusPcMaster 资源搜不到有用的啊,能推荐个网站不
schlafenhamster 2016-03-23
  • 打赏
  • 举报
回复
搜索 “ModBusPcMaster”
女神打Boss 2016-03-23
  • 打赏
  • 举报
回复
引用 4 楼 schlafenhamster 的回复:
"发送2次命令就返回01 10 00 50 00 14 c0 17 01 10 00 50 00 14 c0 17这样一个字符串," 发送1次命令时 ;接受应该清除,怎么 上次的 还在 ?
引用 5 楼 worldy 的回复:
一般和单片机通信都使用应答式通信,发出命令或数据,等待响应,响应后再下一个命令 因此,上位机软件应该避免在发出命令后,下位机没有返回数据之前,发出第二个命令,特别是485通信的时候,是通信成功的保证 lz应该在发出命令,并接收完成相应数据后,再发送下个命令,这才是正确的做法,而不是去区分哪些数据是属于第一条而另外数据属于第二条
接收函数是触发某消息调用,不是人为调用,所以我不知道该怎么区分上一条数据和下一条数据
worldy 2016-03-23
  • 打赏
  • 举报
回复
引用 6 楼 CKRGD 的回复:
[quote=引用 4 楼 schlafenhamster 的回复:] "发送2次命令就返回01 10 00 50 00 14 c0 17 01 10 00 50 00 14 c0 17这样一个字符串," 发送1次命令时 ;接受应该清除,怎么 上次的 还在 ?
引用 5 楼 worldy 的回复:
一般和单片机通信都使用应答式通信,发出命令或数据,等待响应,响应后再下一个命令 因此,上位机软件应该避免在发出命令后,下位机没有返回数据之前,发出第二个命令,特别是485通信的时候,是通信成功的保证 lz应该在发出命令,并接收完成相应数据后,再发送下个命令,这才是正确的做法,而不是去区分哪些数据是属于第一条而另外数据属于第二条
接收函数是触发某消息调用,不是人为调用,所以我不知道该怎么区分上一条数据和下一条数据[/quote] 需要有发送-完成----再发送的---。。。的控制机制,有两种编程模式可以选择,1使用事件触发,2使用“发送----等待---接收”方式, 前者在modbus-RTU模式,不容易使用,因为,没法判断接收结束,无法触发接收完成处理,方式2比较容易控制,并且数据收发也很可靠,只是等待期间会浪费进程的时间,但如果使用多线程,可以得到比较理想的结果
女神打Boss 2016-03-23
  • 打赏
  • 举报
回复
引用 11 楼 schlafenhamster 的回复:
已发到 ak_33344@163.com
谢谢,已收到
向立天 2016-03-23
  • 打赏
  • 举报
回复
粘包的问题要自己制定协议来区分包头包尾
schlafenhamster 2016-03-23
  • 打赏
  • 举报
回复
已发到 ak_33344@163.com
女神打Boss 2016-03-23
  • 打赏
  • 举报
回复
引用 9 楼 schlafenhamster 的回复:
是“ModBusPcMaster.rar”,找不到我给你发
真是没有,百度不到啊,麻烦你发给我好吗! 我邮箱 ak_33344@163.com
张三oO 2016-03-22
  • 打赏
  • 举报
回复
做过一点51的串口 串口是串行的,硬件保证,应该不会存在组包的问题 你这个应该有套机制,比如有个结束符,分隔成一条指令,在收到的一个完整的数据中去识别指令。
赵4老师 2016-03-22
  • 打赏
  • 举报
回复
仅供参考: 不知道有多少前人掉在TCP Socket send(人多)send(病少)send(财富) recv(人多病)recv(少财富) 陷阱里面啊! http://bbs.csdn.net/topics/380167545
worldy 2016-03-22
  • 打赏
  • 举报
回复
一般和单片机通信都使用应答式通信,发出命令或数据,等待响应,响应后再下一个命令 因此,上位机软件应该避免在发出命令后,下位机没有返回数据之前,发出第二个命令,特别是485通信的时候,是通信成功的保证 lz应该在发出命令,并接收完成相应数据后,再发送下个命令,这才是正确的做法,而不是去区分哪些数据是属于第一条而另外数据属于第二条
schlafenhamster 2016-03-22
  • 打赏
  • 举报
回复
"发送2次命令就返回01 10 00 50 00 14 c0 17 01 10 00 50 00 14 c0 17这样一个字符串," 发送1次命令时 ;接受应该清除,怎么 上次的 还在 ?
lang14 2016-03-22
  • 打赏
  • 举报
回复
在头加一个长度,最后加个检验字节

16,548

社区成员

发帖
与我相关
我的任务
社区描述
VC/MFC相关问题讨论
社区管理员
  • 基础类社区
  • AIGC Browser
  • encoderlee
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

        VC/MFC社区版块或许是CSDN最“古老”的版块了,记忆之中,与CSDN的年龄几乎差不多。随着时间的推移,MFC技术渐渐的偏离了开发主流,若干年之后的今天,当我们面对着微软的这个经典之笔,内心充满着敬意,那些曾经的记忆,可以说代表着二十年前曾经的辉煌……
        向经典致敬,或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天,我们期待着MFC技术能够恢复其曾经的辉煌,或许这个期待会永远成为一种“梦想”,或许一切皆有可能……
        我们希望这个版块可以很好的适配Web时代,期待更好的互联网技术能够使得MFC技术框架得以重现活力,……

试试用AI创作助手写篇文章吧