本文针对自动抄表系统结构,通过一系列方法来提高上位机软件的可靠性,从而协调和下位机(硬件)数据及命令的交互。上位机采用Visual Basic 6.0编程工具,采用MSComm控件实现与通讯控制器的通讯。
1帧格式的设计
要保证数据的正确性和可靠性,必须设计一种尽可能避免错误出现的帧格式,我们以01H作为帧起始码(SOH),以04H作为帧结束码(EOT)。在帧内的数据中也有可能出现01H和04H,必须加以替换以区别帧头和帧尾。文中以DLE+‘x’来代替SOH(01H),以DLE+‘y’来代替EOT(04H)。此时会出现一个问题,即如何区分数据区中的DLE与替换后出现的DL E;这就必须对数据DLE(10H)再进行替换,以DEL+‘z’来替换DLE,此时所有情况的替换结束。这既能很容易识别出一帧数据,又避免了因数据区中出现特殊字符而导致错误数据的出现,再结合奇偶校验,从而进一步保证了传输数据的可靠性。
对上位机发送的数据,要先替换后校验;而对于下位机传上来的数据,要先校验再反替换,这是为了保证上位机和下位机在通讯线路中都不出现特殊字符SOH、EOT和DLE而设计的规定。反替换流程相当于替换流程的逆,在此就不再累述了。
2串口问题
因为本系统的上位机是通过RS232转RS485与下位机进行通讯的。所以,串口通讯的可靠性直接关系到整个系统的可靠性。而串口的使用借助于Visual Basic 6.0中的MSComm控件。MSComm控件是通过OnComm事件来触发的,触发的时机由CommEvent的属性Rthreshold决定。当设定Rthreshold=1时,即缓冲区每接受到1个字符就引发一次OnComm事件;当设定Rthreshold=10时,即缓冲区每接收到10个字符就引发一次OnComm事件。因考虑到前面的替换问题,每一帧的长度是无法预测的,但根据通讯规程可以知道最短帧的长度。我们采用最少数据长度(没有任何替换)作为Rthreshold的值。这虽然可以保证对上传数据的及时响应但无法保证获得一个完整的帧。当使用此语句读串口时若接收的数据没经过任何替换则可接收到完整一帧,否则数据帧不全。解决的方法是在读串口前加延时以保证读入数据完全,至于延时的处理不建议用循环语句来实现,这将增加调试的难度,最好的方法是调用API函数Sleep:
Sleep()中时间以毫秒作为最小时间单位,a值的选取必须通过多次调试才能获得最佳效果。另外,为了防止MSComm控件串行通讯问题,在发送读串口命令时通过启用定时器处理程序来捕获串口通讯异常。这些方法可以最大程度的减少因通讯方面的问题而引发的错误。
3整体抄表问题
自动抄表系统的优点在于它既可以对单一用户又可以对所有用户的水、电、气三表进行读数而不需人工干预。单一抄表比较简单;但在整体抄表过程中会出现因连续、快速的读数导致硬件的采集速度与上位机的读数速度不匹配,或因串口事件处理函数未结束而又有事件触发,或线路干扰等一系列问题,这些因素都会影响到整体抄表的稳定性和正确率。由于整体读数的复杂性,仅通过增加错误处理程序往往无法达到预期效果。对于本系统,笔者通过不断实践发现,在整体读数程序中引入第二个延时和重复读数功能可以大大提高整体读数的正确率。
在发出读数命令并正确读到数据后,必须进行短暂的延时,然后再读下一户,再延时,以此类推直到全部读完。当对一户读数出错时,要重复对其读数几次,若正确再读下一户,否则先调错误处理函数,再读下一户。注意:错误数据不能写入数据库,以防结算时产生问题。延时的引入尽管会对整体抄表的速度造成一定影响,但考虑到系统的整体性能,以损失一定速度来换取准确性这在绝大多数自动抄表系统中是可以接受的。在整体抄表过程中,“延时”具有关键的作用,它不但协调了软件和硬件之间的问题,也协调了软件自身的问题。
通过上述方法,使得整个系统从细节到整体上都加强了抄表系统的可靠性和对 大多数错误情况的避免和处理,从而保证了自动抄表系统高性能和高可靠性的要求,这种方 法在实际应用中收到了良好的效果。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)