请教懂上位机软件的专家们一个问题

只看该作者 · 2011-8-4 16:29

顶顶

2万 · 2011-8-4 16:32

LS的头像是哪位韩剧明星？

只看该作者 · 2011-8-4 16:44

21# yewuyi ascii模式下数据报文里本来就不会出现帧头帧尾
如果出现，就是传输错误

只看该作者 · 2011-8-4 16:46

pc上弄3ms或者更短的时间，好像不太容易
其实，可以自己定义为300ms或者500ms之类
是否符合标准不好说，但是实际应该应该没什么问题

只看该作者 · 2011-8-4 17:00

:dizzy: ，晕倒，俺用MODBUS很多年了，还要你发一份协议学习？:L ，俺自己的电脑里面中英文的MODBUS协议都有。

俺虽然没有用过ASCII模式，但仔细想想，如果用所谓的0x3A做开始接受判断，以0X0d0a做结束接受判断的 ...
yewuyi 发表于 2011-8-4 16:26

:dizzy: :dizzy: :dizzy: :dizzy: :dizzy::dizzy: :dizzy: :dizzy: :dizzy: :dizzy: :dizzy: :dizzy: :dizzy: :dizzy: :dizzy:
用ASCII模式，除了头和尾就不可能出现那两三个标志了，楼上的也有说到。你仔细想想，这样就不再用时间去判断开始结束了。之所以叫做ASCII模式就是所有数据都用ASCII传输了，在PDU段的所有十六进制数用ASCII传输了，还会在出现那两个标志吗？

不好好看书:dizzy:

只看该作者 · 2011-8-4 17:02

pc上弄3ms或者更短的时间，好像不太容易
其实，可以自己定义为300ms或者500ms之类
是否符合标准不好说，但是实际应该应该没什么问题
zjswuyunbo 发表于 2011-8-4 16:46

我正在看的代码用GetTickCount，也不知道那个得到的是什么精度的时间。

2万 · 2011-8-4 17:04

pc上弄3ms或者更短的时间，好像不太容易
其实，可以自己定义为300ms或者500ms之类
是否符合标准不好说，但是实际应该应该没什么问题
zjswuyunbo 发表于 2011-8-4 16:46

MODBUS只是规定不小于3.5个字符，并没有规定上限，所以俺个人认为：符合。

2万 · 2011-8-4 17:09

:dizzy: :dizzy: :dizzy: :dizzy: :dizzy::dizzy: :dizzy: :dizzy: :dizzy: :dizzy: :dizzy: :dizzy: :dizzy: :dizzy: :dizzy:
用ASCII模式，除了头和尾就不可能出现那两三个标志了，楼上的也有说到。你仔细想想， ...
wzf3151 发表于 2011-8-4 17:00

;P ，你把ASCII阉割了一下可能不会出现，但对于一个协议来说，传输的数据段中完全可以出现':'这个字符，例如我有两个设备，A设备控制B设备显示的内容，当A设备用MODBUS将显示内容发给B时，可能会出现如下的显示内容“x:1,Y=2”，此时数据包中的:将会带来歧义。

2万 · 2011-8-4 17:10

从俺个人使用MODBUS的体会来说，用时间判断是非常好、非常简洁的一种方式，:lol，一目了然、一清二楚，多好啊！

只看该作者 · 2011-8-4 17:15

;P ，你把ASCII阉割了一下可能不会出现，但对于一个协议来说，传输的数据段中完全可以出现':'这个字符，例如我有两个设备，A设备控制B设备显示的内容，当A设备用MODBUS将显示内容发给B时，可能会出现如下的显示内 ...
yewuyi 发表于 2011-8-4 17:09

看来必须要和大侠说道说道了，我根本没有阉割ASCII,modbus也没有阉割。如果要发送ASCII的“：”，这个冒号用二进制表示是什么,一个字节，然后用十六进制表示就是两个ASCII字符，所以发送一个冒号，要用两个字节去发送，在发送端编码，在接受端解码，你仔细看看协议怎么说的，难道是我理解错了？

只看该作者 · 2011-8-4 17:18

显示内容并不是直接去发，而是要编码，对方要解码，只要知道是ASCII模式，双方互能理解，我想用了那么久的协议不会出现这种问题的。而且协议本身说的很清楚，如果用ASCII模式，传输数据量要翻番。就是这么翻出来的。

2万 · 2011-8-4 17:43

看来必须要和大侠说道说道了，我根本没有阉割ASCII,modbus也没有阉割。如果要发送ASCII的“：”，这个冒号用二进制表示是什么,一个字节，然后用十六进制表示就是两个ASCII字符，所以发送一个冒号，要用两个字节去发 ...
wzf3151 发表于 2011-8-4 17:15

俺只是举个例子，大概的意思就是在数据段无法避免不出现引导和结束符的数值，如果出现这个数值，要么是通过转义躲开，要么是强行规定数据段永远不准出现这几个数值，如果这样，则就是阉割拉。

协议要具备严谨和通用，MODBUS并没有定死应用层，所以不能强行规定用户在应用层怎么怎么，

2万 · 2011-8-4 17:51

呵呵，强烈呼唤chunyang把本贴加酷，呼唤真正用过MOSBUS ASCII方式的人上来露露脸，帮助LZ解决问题的同时，也权当帮俺释疑一下。:D

只看该作者 · 2011-8-4 18:09

呵呵，强烈呼唤chunyang把本贴加酷，呼唤真正用过MOSBUS ASCII方式的人上来露露脸，帮助LZ解决问题的同时，也权当帮俺释疑一下。:D
yewuyi 发表于 2011-8-4 17:51

搞技术的人就是执著，感动了，继续和叶大侠说道，如果是二进制编码，还要引入某个固定的标识符来标识起始结束，结果就像叶大侠所说，无法避免不出现。

但是modbus的ASCII模式就通过编码解决叶大侠担心的问题，但是付出的代价就是使数据传输量加倍。
其实转意字符也是在编码啊！

看来叶大侠只用RTU模式，没有用ASCII模式。我个人感觉叶大侠对modbus的ASCII模式理解有误。

只看该作者 · 2011-8-4 21:54

我正在看的代码用GetTickCount，也不知道那个得到的是什么精度的时间。
wzf3151 发表于 2011-8-4 17:02

ms级精度的时间可以得到，一直纠结的是，不好保证底层在收到一个字符后一定会在X ms内通知上层应用程序去处理，也不好保证上层应用程序调用发送数据的API后，底层一定会保证在X ms内真正发出去。这个问题不解决，应用层参考再精准的时钟也没用。调高进程线程优先级，调整CreateFile,ReadFile以及串口参数可以很大程度上解决这个问题，但无法保证一定不出问题。我没实际试过，不确定是否真如此。

只看该作者 · 2011-8-4 21:54

若上位机只是做Modbus-RTU的主站，则编程时可不用考虑间隙时间，发送完等待接收即可，但要做超时无响应判断，间隙时间从站自会处理。

只看该作者 · 2011-8-4 21:58

MODBUS只是规定不小于3.5个字符，并没有规定上限，所以俺个人认为：符合。
yewuyi 发表于 2011-8-4 17:04

既然是这样，那定个长时间的不就没问题了。

2万 · 2011-8-5 08:30

搞技术的人就是执著，感动了，继续和叶大侠说道，如果是二进制编码，还要引入某个固定的标识符来标识起始结束，结果就像叶大侠所说，无法避免不出现。

但是modbus的ASCII模式就通过编码解决叶大侠担心的问题，但是 ...
wzf3151 发表于 2011-8-4 18:09

你所言用ASCII实现转义？
转义的一个最基本要求就是要确保数据段的数值不出现那几个特定数值，如果出现了则需要用别的数值‘组合’规避，因为这个组合的出现，数据段长度将被改变，而且在校验计算时需要，仍然需要按照未组合前的数值计算。

MODBUS的ASCII模式没有看出有以上特征。

只看该作者 · 2011-8-5 09:01

你所言用ASCII实现转义？
转义的一个最基本要求就是要确保数据段的数值不出现那几个特定数值，如果出现了则需要用别的数值‘组合’规避，因为这个组合的出现，数据段长度将被改变，而且在校验计算时需要，仍然需要 ...
yewuyi 发表于 2011-8-5 08:30

用ASCII实现转义，本身就没有你说的如果，你注意看看采用ASCII传输模式时所采用的校验方法也变了。而且如果说用ASCII实现转义已经是广义的转义了，转义直接确保了不再出现标识符，不再是你一直理解的狭义的转义。这块更应该理解为一种编码，这种编码保证了传输时不会出现某些标识符（在16进制的意义上），所以。。。。。

你可以说说你ASCII模式的理解。你可以按照你对ASCII模式的理解去尝试读取一些支持ASCII模式的设备的数据，你看看是什么，不要看被modbus软件解释过的数据，直接看总线的原始数据。

帖子跑偏了！

只看该作者 · 2011-8-5 11:24

研究了一个老外写的MODBUS的例程，他在WIN32系统里对串口的读取采用查询，然后再利用1ms的定时，来实现MODbus对超时的管理，但是他的程序只管理了T3.5,对T1.5是不理会的，开了一个线程运行协议。
感觉那个软件模块化程度很高，协议栈不变，运行平台随便换，管你是有无操作系统，也不管是单片机还是PC，移植时只需要改动少量的代码即可。
我现在才知道什么叫做协议栈了，以前听说，但是不理解。
而且注意MODBUS协议的一个细节约定，
“RTU 接收驱动程序的实现，由于t1.5 和 t3.5 的定时，隐含着大量的对中断的管理。在高通信速率下，这导致CPU 负担加重。因此，在通信速率等于或低于19200 Bps 时，这两个定时必须严格遵
守；对于波特率大于19200 Bps 的情形，应该使用2 个定时的固定值：建议的字符间超时时间(t1.5)
为750μs，帧间的超时时间(t3.5) 为1.750ms。”
协议都建议了超时时间可以增大，而不是必须都按照波特率算。而且为什么这么做也说得很清楚，对于单片机负担太重，对于PC基于WINAPI编程，太短的时间管理都没法实现。

请教懂上位机软件的专家们一个问题

社区建设奖章

欢快之小溪

伴坛终老

技术高手奖章

终身成就奖章

坚毅之洋流

十世金身

技术领袖奖章

突出贡献奖章

沉静之湖泊

技术奇才奖章

精华达人奖章

湍急之河流

缘定三生

技术导师奖章

常驻人口