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

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

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

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

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

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

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

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

---

2020年2月22日