我前面手懒了,再"详细"解释一遍
|
首先感谢各位的回帖.<br /> 回chunyang:讲话直是好事,搞技术的最烦拐弯抹角!我非常赞同你的这段话:"一个行业里的“大牛”换个“山头”一问三不知也属正常".我在意的是在看清楚问题以前上来就批!<br /> 回到技术问题.我的问题要是在DOS实模式下根本不是问题,因为所有程序都可以很简单的用汇编直接控制.犹如探囊取物.问题的起因就来自于方便易用的Windows+VB.(其它的方法我不会,不敢臆测)<br /> 我做通讯试验时是架着双踪示波器进行的.在VB下时间的分辨率无法优于20mS(大约).而每次正常发送间隔不能小于50mS(大约).这样对于已经不快的9600pbs来讲,通讯线上2/3的时间在等待.而对于38400bps来说88%的时间在等待.(以上计算基于ModBus协议最常用的双向报文长度8字节+4字节间隔).这个问题在子站数量少的情况下不易被注意到,而子站多了就不能忽视了.如果采用简单的232转485方案,只要VB的50mS无法去掉这个问题就只能如此!这就我前面提到的第一个方案即单串口的方案.<br /> 我说得第二个方案就是要彻底解决这个问题--采用双串口设计.这里MCU已经不是简单的仅控制485芯片的收/发线,而是负责更复杂的协议转换.即把VB直接控制下效率低的ModBus协议转换为更适合Vb控制的效率更高的其它协议.<br />例如,既然间隔不能在缩小就加大报文长度,把需要上百个短报文完成的巡检命令变成批巡检命令.由MCU翻译成高效的ModBus命令.<br /> 我想肯定有第三种方案;修改Windows,加入实时内核,把它变得即有Windows的易用又有DOS下的准确.网上看到过由于不常用担心比第二种方案的成本还要高(这的确是臆测的).感叹,技术进步了我却低能了,我已经没有能力像当年把CP/M修改成实时多任务那样驾驭Windows了.<br /> 突然想起一个故事:说一个小孩子上学去,第1天学了一个字"一",第2天又学了一个字"二",第3天也学了一个字"三".第4天他就不来了,说: ......!<br /><br /> 回21ele:千万不要打标准协议的歪主意,修改标准就是向众多专家的经验提出挑战!眼前站点便宜以后会有很多麻烦.(传出去,名声也不好呀!).遵守协议就是为了交流,自成体系就是自我封闭!<br />好心人,你那个非常好用Modbus Poll调试软件是否可以共享!我早已是垂涎三尺啦.<br />
|
|
楼主
