程序隐患点.txt

本人s12的一部分机器人巡线程序

1、在TaskStart中的通信程序中可能存在的隐患:由于频率相差太多，主从机之间如果通信失误比较多的话，
就可能导致主机频繁中断从机，要求与从机通信，直至通信完成。但是这样的好处就是假如通信出错能
得到如此及时的重发，可以在一定程度上减少从机长时间无法得到主机给定速度而不能快速反应的问题。

也可以使用出现错误通信的时候限定补发次数，要是补发到达一定的次数还没有成功就取消本次发送数
据，直到下次循线、位置判断、速度查表完成后发送新的数据。这样编程相对来说就要麻烦一点。

不过不建议通信出错了就立即跳出通信(放弃本次通信，直至下次通信是给定新的速度)，这样可能导致
在通信出错率比较高的情况下长时间无法给定下位机速度值，最终导致循线失败。

注意:通信的时候一定要进入临界段,在通讯完成之后再退出临界段,防止程序在通信的过程中到达时钟节拍
      时刻进入任务调度而导致通讯超时失败,
      在现场的测试通讯和实验室测试有很大的差别,实验室里面一般没有现场测试那么多不可预测的干扰
      ,如现场测试时候的机械振动和电路电磁干扰等因素在实验室一般是没有那么大的强度的,所以通信的
      实验室速度一定要和现场使用的通讯速度区分好,一般的情况是实验室测试的通讯速度降频作为现场
      通讯的速度，因为在现场干扰源和不可测因素增加的状况下，首先要保证的是通讯的高可靠性运行，
      不比在实验室测试的时候都是短时间测试，现场一般都是要求长时间正常运行的。
      
      所以，在实验室里面先测试好通讯的极限速度(在这个速度下能正常运行至少数小时或者数天)，然后
      移植到现场设备的时候，在此极限速度的一个降频系数后的速度作为现场速度(个人认为在极限速度的
      1/2.5以上缩减比)。
      
      
通讯中要是在应答位置采用死等的形式探测从机(或者从机探测主机)返回信号的时候极有可能出现等不到信号
而死机的状态，这是不希望在系统运行的时候出现的，所以最好将通讯程序改写成定时限查询方式，这种通讯
方式只是在探测从机(或者从机探测主机)的同时设定一个变量，设定变量的限度，让变量自加，如果出现探测
成功或者变量自加超过限度的时候都继续向下执行其他程序，并在通讯最后的地方返回一个布尔(BOOLEAN)变
量，比如说，在超时限的时候返回FALSE，在正常通讯完成时候返回TRUE，这样主程序中再设定针对这个布尔值
的处理程序。处理程序一般大概有2种:1、返回的是TRUE，继续向下执行程序；2、返回的是FALSE:1)立即补发
通讯信号给从机,直至通讯成功为止，这样可能有一定的风险：如果立即通讯的时候从机还没有从上次的通讯中
断中退出则无法响应通讯请求，导致多次的通讯失败;2)、延时一段时间再做补发信号事件；3)、忽略通讯失败
在下次检测完成后直接发送新的数据,这样可能导致下位机很久都得不到通讯信号(假如通讯失败比较多的情况)