我开发PLC数据采集、录波软件PLC-Recorder的心路历程

PLC-Recorder是个什么软件?请参考这篇文章,也可以参考网站里的介绍

当一个软件出现在大家目前时,很多人看一眼,发现赶不上国外的,就觉得开发者很土。那些崇洋媚外者甚至开始恶语相向:你敢挑战老外的东西?太不自量力了吧!有的人还是能发现可取之处“起码大部分功能已经不错啦!”,然后对开发者进行一些鼓励。

看似简单的小录波软件,简单吗?如果需求能够写的足够清晰,边界条件都设定好,我想,很多计算机专业的人员可以快速实现。但我是一位老工控人员,这是我第一次用C#开发项目,花了快一年半的业余时间去摸索,去完善。时间都去哪儿了呢?

  1. 我要熟悉语言,寻找实现自己想法的方法(好在我有点开发其他软件的思路):用户操作习惯怎么保存和恢复?怎么进行硬件信息的读取?怎么处理多个设备的并发工作?怎么使用某个控件?好在百度很强大、CSDN很丰富,大部分都能找到答案,搬过来,测试一下就心里有数了。感觉非常有价值的,就记入自己的学习笔记,回头再找的时候,就非常快了。
  2. 当然,也遇到一些很难办的问题:比如极值处理。画图时的Y轴,外面显示是double,我的数据是double型,在某些情况下,画面就变成了大叉叉,只能关闭软件,重新打开(这在工业上是不允许的,必须要事先处理)。控件的Y轴是什么数据类型?其内部应该不是double。帮助上没有,然后,就要去国外的论坛,通过蛛丝马迹去确认,然后再自己验证,设定自己送画面显示时的限幅值。再比如,当Y轴的最大和最小值相差非常小时,理论上,是没有问题,画面显示也正常。但是,软件放到某些系统下跑一下,就发现CPU资源占用非常大,这些问题,也很难找到答案,只能自己去摸索。
  3. 要花很多时间和PLC进行结合,将开发好的软件与PLC连起来进行测试,测试极限性能(最快、最慢、最大)、每个设备特殊点的处理,通讯协议的优化(不是底层协议),找到一些折衷的采集策略。为什么国外的软件好?他们已经发展了很多年,已经完成了这些摸索和积累,可能已经找到了边界。当我们不知道准确边界时,就只能尽量靠近边界,牺牲一些性能,这就是折衷。
  4. 如何管理变量?如何与数据文件关联?如何方便使用数据文件?用户后期对于波形的修改,如何进行保存和应用?这些都没有人指导,只能参考外方软件的功能,自己设计一套规则,发现不完整时,再进行扩充,完善,甚至全部推倒重来。架构推倒重来的事情,发生过一次:开始设计时,这个软件只用于单设备录波。后来,要能对多个设备进行录波。这次就将文件结构、变量结构,初始化等等全部重新重写,大量使用了集合、线程的概念,并要进行多线程之间的同步控制。软件的复杂程度一下上了一个数量级。

我的优势是什么?我懂这个软件的需求,我用过老外的不同软件,知道他们的特点,知道哪些功能是必须的,希望怎么操作。在开发的过程中,我可以随时放在多个工业系统上去测试(测试稳定性、是否能满足自己的要求等),从某种意义上说,这是个为自己开发的软件。经过一年多的埋头苦干,我自己已经比较满意了(针对于当前阶段的功能),而我是比较严格的人,我相信大部分工控人员应该也能接受了。

目前的软件只能说是实现了对外方软件部分功能的追赶。我还有很多新的想法要在未来版本里去实现,这些功能里,就有要超越的部分了。

不积跬步,无以至千里!只要我们上路了,目标就不远了!


2020年2月22日

猜你喜欢

转载自blog.csdn.net/chengjl8/article/details/104443701