|
说实话, 我还从来没有见过另外一个行业的工程师,如本行业一样,动辄对同行的作品彻底否定。
见过了太多的plc编程工程师,公开声明自己的原则:不愿意读别人的程序, 不爱修改别人的程序,情愿另起炉灶自己从头编写程序。
理由就是:别人的程序, 烂。
至于原因么, 很简单, 别人的编程水平不行,就我的最好。
包括我自己。
我自己记忆最清晰的是两次现场救援,系统原本的程序烂掉了, 跑不起来,原来的程序员干不下去了, 撂挑子不管了, 我来接了烂摊子。 因为摊子本来就烂, 所以不得已,毁掉了原来的所有程序, 只保留了符号表, 所有程序从头做的。
除此之外, 只要系统原本是能运行的,无非有缺陷, 总出事情, 那也尽量在其原本基础上读懂, 修改。找到问题, 解决问题。 别人的程序再烂, 我想也总有一些可以参考学习的闪光点。
不过也确实有些程序烂到实在不像话。 读那种程序, 实在是要忍着恶心的。有那么几年, 我一边读这种程序, 心里一边暗暗排名,哪个是我见过的第一烂的程序, 哪个是第二烂。diangon.com 也曾经长时间的在硬盘上保留着,仅仅是为了作为比烂的样本。打算谁要发起比烂大赛, 拿出来参加的。
但我也实在明白得很,这种专业技术人员之间互相倾轧的心态是要不得的, 是自古以来的文人相轻的陋习的传承。 我还没有不要脸到只要别人的程序都烂, 只有我的程序最好, 最完美最合理最优雅最简洁。
所以, 这里面一定有一个客观衡量的标准。
这些年, 我一直在寻找, 在思考。
首先,要找到最合理, 最理想的程序范本。
最终我认为, 是PCS7 。 使用PCS7高级工具生成的程序, 最终落到S7-400的PLC中,其本质上还是PLC程序。 尽管其代码规模大,不够精简,运行效率低,但是从编程的规范来说, 它一定是最合理的。
其次, 是从中提炼出其可度量的好的标准。
好的程序, 一定是模块化的,面向对象的, 层次分明的。 PCS7显然是依循这一点做的。但还不足以作为考量程序好坏的标准。
我最终总结,认为,好的程序的标准是:不使用M中间量,不使用Timer。
我不希望有人给我耍滑头, 耍脑筋急转弯。说, 不让用M量,可以啊, 那我用全局数据块, 建立数据, 一样可以。 也用DB块自己脉冲计数, 也可以绕过不使用TIMER。
那性质是一样的, 特征都是:全局变量。
如果学过高级编程语言, 就会知道, 高级语言里面最基本的原则就是少用全局公用变量。 尤其禁止在函数块与函数块内部使用PUBLIC变量来交互数据。
放到PLC环境, 其实说的就是M和T。
我自己以前做程序, 程序块基本上靠M和T做出来的。为了清晰,便于传承, 给每个FC块严格分配了可以使用的M区和T区域。
现在看来, 都是属于落后的编程思想。也害了不少跟在我后面学习的徒弟。 惭愧。
那么如何避免使用M量和T呢?答案是大量使用FB, 每一个设备,单元类型,均提炼做成类库,需要的存储区使用FB块内部的静态变量,而定时器则使用SFB的定时器, 背景数据来自FB的多重静态数据。
那么是否可以完全做到呢?PCS7显然是可以做到。 而我自己做过的程序, 也有做到过没有使用1个M和1个T的。 CPU中指定的系统变量不算。
偶尔也有偷懒, 不够追求满分。 特别是调试到后期, 一些小的细节的功能, 顺便就用M量简单实现了。那怎么办呢?内心给自己的程序打个分扣上5分就可以了!
当你掌握了客观评价标准,都能给自己扣分了,那么就可以理直气壮地评价别人的程序了。 比如你如果见到我10年前的某个程序, 规定了多少M区不许使用,就可以尖锐地指出:烂!
本文转载自:西门子工业技术论坛 |
|