您的位置:首页 > 其它

项目总结新技术在项目中的应用风险和机遇

2015-12-11 23:08 225 查看
新技术应用到项目中,尤其是面临上线压力的项目中,风险总是很大。因为新技术中有很多不确定的东西,稍有考虑不周之处,就会带来巨大的项目风险和项目灾难。

但新技术又带来新的机遇,因为老的技术体系或技术思路,可能已经不适合一些处理场合了。

本次项目应用场景中的新技术,原来在项目中上位机软件对传感器信号或设备IO信号的监测,靠时间对信号进行处理,包括信号滤波检测等,当在一个过程控制中,涉及到产品在产线上经过多个传感器和设备,实现多个功能时,需要在系统中对信号和数据进行模拟排队,在传统的过程控制中这是常见的解决思路,但是如果涉及到数据的交互关联情况,很容易因为排队时,某个信号的误动作或不准确,造成整体的错位,并且这个错位是不可修复和还原的,会造成持续性的累积误差。

因为运动的不确定性,完全靠时间量,很难彻底的摒弃复杂运动过程中的误差信号,因为时间信号是个线性的,如果把线性的时间信号转化成位移量,再对位移量进行分解,微分的过程,那就转化成了很小的计数脉冲,通过脉冲数的累加来确定信号的状态,这样可以有效的解决信号的误动作问题,引入位移脉冲计数后,同时能对产品的运动过程进行定量分析,从而达到对产线产品的实时监控过程,这样在入口点触发一个信号后,后续信号的触发将不再依赖,不缺定性的外部信号输入,而是完全的内部信号标定和控制了。

比如一个产品经过传感器触发后,需要触发工业采集器,并将编码送入激光机进行喷印,这个在原来的处理过程中,是一个线性的多输入点信号,复杂且难以控制,现在可以把信号的控制切割到位移脉冲上,反向转化为内部闭合信号处理。通过输入信号订阅产生确定性的信号触发点,此信号触发点位于系统内部。

既然要用到以上的技术,就面临的问题是,做计数采样,可以利用高速编码器,由于上位机采用通用操作系统,没法实现高速编码器的采样,因此要实现上位机的实时监控,就需要中间有一个过渡的桥接设备,利用实时处理系统,来解决高速编码采样的问题,实时系统再与上位机的通用系统,做数据通信,以达到实时交互的目的,为了达到指令执行的高效不失真,则需要实时系统能对上位机的指令能实时解析处理,并反馈,等于是上位机系统,做了延长和扩展到下位机,由此达到了扩展控制的目的。

因为先前没有实时下位机系统,作为新技术的引入(以前没用过),需要做很多功课来学习,包括从实时系统的学习、编译、开发、通信协议的制定,其中通信协议部分,在开发过程中,就有五版的大的变更,才确定下来。因为项目启动之前,只有一个月的周期,预留了一周左右,开发项目系统(包括老机制的兼容系统),三周时间做这款实时系统的应用,在两个周左右写出了第一版和Demo,但是测试中发现一直有不可靠的地方,包括Flash读写、串口数据的读写,其中Flash的读写花费了大概有一周左右的工作量,晚上基本有白天的工作时间,最后找到原因是因为存储边界对齐和地址查找失败引起的,串口读写是第二个令人纠结的地方,项目中一度要放弃这种机制了,因为在项目进客户现场的第二周了,还是没法解决串口的数据丢包问题,此处的数据包是指完整的指令包,思路一度陷入,是因为串口中断排队问题,中断故意丢弃引起,后来加入串口缓冲队列机制,问题还是有,又后来分析是主程序周期与中断冲突,会产生对队列的竞态调用问题,改成了一个带锁机制的队列(STM32中是无锁和线程这一说的,是模拟的竞态锁机制),发现还是会在软件初始化时,有指令没正常反馈,(软件初始化时,会做大概有20条左右的命令初始化,会连续发送到串口,如果串口发送间隔大于50毫秒,都有反馈应答,小于50毫秒,会出现没有反馈应答的情况),这让人很郁闷,因为考虑到在上位机做一些发送延时间隔,会对实时性带来很大的问题,偶然的测试中发现,在连续发送其他执行命令时,所有执行命令都有反馈,这证明底层的串口接收缓存队列机制是起效的,进一步分析,原来在初始化时,还需要把配置写入Flash做硬存储,应该是Flash的写入时间耗时比较长,并且Flash的写入靠的是中断写入,当大量的中断申请时,脆弱的flash写入遇到了问题,直接导致主程序的回馈出现了问题,分析到此知道整个系统是没问题的,初始化注意一下就可以了。

,机遇也就是好处,也是巨大的,最大的改进是设备的误动作信号基本全部屏蔽,时序控制简单清晰,响应高速可靠,无法实现的一些处理机制,也可以全部实现了,比如数据库数据实时校验等。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: