科技以人为本,人身安全第一,设备安全第二,达到要求第三,稳定第四,效率第五,易操作易用性第六......从来不迁就客户为图方便不考虑安全因素的要求,有的是客户自己没意识到,需要沟通好,最后会同意其他办法的。
至于程序,我一直认为就是翻译的译文,属于技巧问题,有的人翻译的篇幅大,有的人篇幅小,无伤大雅,有良好的规范和习惯最好,做多了自然就有总结和归纳了。程序我一般是多做功能块和库,可以重复利用,也方便;先做标签,符号表,规划分配好不同功能的地址范围;列好触摸屏大概的交换数据;归纳简化逻辑,做好流程图;最后再编程。这样做编程的时间也许会长些,但是换来的是清晰规划的技术归档和技术积累,大大缩短现场调试时间,减少客户的试机成本,也减少自己公司的费用。
PLC从编程软件来说,我最不喜欢三菱和松下,一页纸从头写到尾,太累。喜欢西门子S7200和OMRON,最喜欢的是基于CoDeSys平台的软件,那个太好用了。
工程师甲和工程师乙同时接到一个工程命题。二者同时就这一命题开始PLC程序编写。
一周之后,甲乙二人均已完工,于是开始评估谁的程序更好。
两个程序分别运行了一下,甲程序平均扫描周期为60mS,乙程序平均扫描周期为15mS。
甲不服曰:玛丽隔壁的,老子的程序有通信,你有么?
乙曰:必须的啊。
甲继续不服曰:老子用的是官方的Modbus通信模块!
乙曰:我在保证功能实现的前提下,有限支持Modbus。
甲仍然不服曰:我的程序中有专门针对错误操作的容错模块,你有么?
乙曰:必须的!不信你试试错误操作会不会有影响?
甲死鸭子嘴硬曰:老子的程序都是用的各种流行功能库,可复用性好,可读性好!
乙曰:我保证我的程序中没有火星文,如果你还是看不懂,我真的不知道该说啥了。。。
甲:。。。
乙:我要求涨工资。。。
最终Boss拍板了,决定直接解雇工程师乙,并采用工程师甲的程序。
理由有三:
1、甲程序门槛低,好理解好抄袭好维护好更改!
2、甲程序员水平差,好平衡好控制好剥削!
3、甲程序该有的功能全有,尽管效率一般,但目前的市场并不是那么苛刻,客户啥也不懂。二十一世纪什么最重要?成本!成本控制最重要!!
类似这样的故事在中国并不鲜见,并不仅仅是在工控行业,各行各业中这样的Boss比比皆是。但要想摆脱山寨国的状况,必须让各位老板从内心接受一些有追求的技术员。。。
看这个帖子在工控网首页挂了很久了,今天也来冒几句。
好的程序,首先要发掘客户的真实需求,往往客户提出的要求总是比较简单,按他们说的编程也很简单,但是在使用中总会不断出现问题。
在着手设计前,最好将工艺熟悉到比任何人都熟悉,和操作工、维修工、班组领导、车间领导等积极沟通,反复沟通。
其实编程大部份时间都用于考虑对不正常情况的处理,比如误操作,比如物料超标,比如电机停转,这些问题都需要考虑,尽量缩小影响面,尽量减小经济损失,不出安全事故。
关于功能---必须实现。
关于操作---操作工的文化水平不会太高,界面尽量简单清析易懂,要尽量减少操作,尽量用颜色文字将不同功能的分开。
关于易读---就算程序不对客户开放,但是必须要让自己能看懂,让接手这个工作的同事能看懂。客户要求不大可能一直不变,硬件设备也会增增减减升级换代,设备运行中也不可能一直不维护。工作太多,隔几个月哪还记得这是怎么回事,后续的工作也不可能自己一路到底。所以我在写程序前总是要写一篇文档,写上总的控制逻辑,地址分配,然后写程序时不断对照完善。程序的注释中也有详细的说明。
关于成本---每个品牌都有各价位的PLC,选型时注意一下功能和成本,总有适合自己的。
关于模块化---做系统集成的,一项目基本不会出现第二次。这些年都没做过重复的东西,所我写的程序基本没做成模块,只需要在当时可以快速实现就行了。
关于安全性---尽量多花时间在这上面
偶然间看到这个道场里一个个平时难得一聚的大咖们,忽然间在这汪水里都冒了头,随即产生了拿起搅屎棍在这里翻腾几下的冲动,如翻腾起点味儿出来,欢迎列位大咖们拍砖哈!
本是个讨论编程手段何为“好”还是“不好”的老套话题,最后却都汇聚到了“简单好”还是“可读性好”的这个犄角旮旯里,多少还是让我感到有些意外。
这个争论之所以能够出现,其实反映的是这样一个最根本的问题:造小渔船的那些绝活,用到造现代超级油轮的生产过程中,还管不管用?即便管用,还能不能用?
如果两个分别造上述两种“船舶”的老板面对面,对上述问题的答案当然是冲突的地方多,相容的地方少。
如果跳出“船厂老板”的眼光,用“船舶技术协会”的高度,其实这个问题根本就不是个什么问题!
怎么解决?
采用模块化制造技术,把你能够应用到大型船舶制造过程的“局部小技术”封装打包使用不就完了么?
应用到PLC程序编制过程当中,如果你以前有一种用起来非常顺手,速度又快,代码又简单的一个个独立小技术,你干啥非得明睁眼露地把它塞进程序中?将其分别制作成可独立应用的DFB模块,然后程序编制过程中每每遇到它你再单独调用,问题不就解决了么?
不仅如此,更大、更复杂、更具独立性的单独的一项任务,你全都给他做成DFB,你看看你的程序在“既简洁、又具备非常好的可读性”方面,会好到何种程度?
上述做法,用个形象化的比喻,那就叫“用预制件盖大楼”,用句时髦点的话讲,那就叫“面向对象的程序编制”;而各位大咖们争论的导火索,恰是你们所采用的这种“砖头水泥盖到顶”的、“面向过程”的“盖大楼”的“工艺”!
我在程序编制过程中,几十个被我用的熟熟的DFB,我是随手就用,在我的PLC程序画面里,绝看不到直接的数据处理程序,能看到的,就是一个个独立的、围绕受控设备专用DFB所展开的程序画面,几个关键的条件变量、输出变量鲜明地摆在那里,整个逻辑流程清晰、明了,各个DFB的调用一目了然。
我自己的程序库中的那几十个DFB,不仅包含各种自编的时间脉冲发生器、标准时钟脉冲,还有专用于控制各类受控设备的,其中不仅有专讲究“高效”的,更有专门搞复杂逻辑或复杂控制的,但这其中的奥秘我是不是愿意白白透露给用户,那就得看我是啥态度了。不愿意给你看,我就将其加密。而主程序,你想怎么看就怎么看,反正就简单到仅仅那么几页,刚学编程的人都一眼就能看明白,我凭啥不公开?
怎么样,我的做法“开放”不?“简单”不?“高效”不?
依我这种编程序的方式,一个由数台大泵组成的、可实现恒压、恒流运行的大型泵站的全部控制程序,我在家里几乎就能完成98%的程序编制工作,到现场将硬件安装及电路连接完成后,通常一个上午就把现场调试工作完成。
不知道我这根“搅屎棍”搅到现在,能不能翻起几个泡泡出来?有没有点味儿?各位大咖伸出水面的那两只小鼻孔能不能闻得到?
哈哈!