我的观点来源于我对实践的总结,当然这可能是很片面的,对于编程,我总是很苦恼,也许是我智商不够,或者是技巧不够,也或许是工程经验还不够丰富,但今年我找到了解决这些问题的办法,或许是我自认为找到了办法,而办法来之于从事计算机软件行业的弟弟给我上的一课。
先说一下我编程的苦恼:
1.难以下笔。拿到项目,硬件设计通常都能迅速搞定,除了选型比较花时间外。但要开始写程序的时候往往不知道从何下手,对于画流程图,我觉得难以运用这个工具。也许一整天,甚至两天都还找不到头绪。当然只要灵感一来,什么图都不用画,就如滔滔江水决堤,不管是小系统还是大系统的功能模块都能很快完成。总之我就觉得西门子的那种编程思想就是比三菱的好用,至于要让我说出为什么,我啥也说不出来。
2.漏洞百出。程序是很快就写完了。接下来就是测试,不用说,这样像写小说一样写出来的程序,可想而知,到处是问题,不管小系统还是大系统,从未有一次通过的快感出现过。开始找错误,补漏洞,非常苦恼。补了大洞,来了小洞。这里通过了,哪里又完蛋了。总之,我的程序我总结是建立在BUG的基础之上的。我从来不害怕我的程序被别人<此处内容被屏蔽>,因为难得我自己都看不懂,根本不用害怕别人能看懂了去。
3.过于技巧,几个月后自己都看不懂。项目不是一个,做了这个项目做哪个项目,测试通过后都交给客户了。 不管是自己的程序还是解的别人的程序,完工后统统变成RAR压缩文档。几个月之后,也许某个客户这里要改下那里要改下,或系统出了故障需要知道究竟是怎么回事。RAR压缩文档一解开,完蛋,绝对死翘翘,自己都看不懂。越是技巧的程序,越是搞不明白。几个小时过去了,一片空白,和看天书区别不大。苦恼无比。该死,这时才想到当时还是就不应该这么写,可是不这么写又该怎么写呢?
4.程序复用性差。不习惯于功能块封装,或者说是不懂得该怎样封装。反正下次能用得上的程序很少,最多就是实现功能的思想下次能用下,还经常性的一个主程序一直到底。这样的搞法既费马达又费电,重复写呀写,写得四肢无力,腰酸背疼,两眼放光!
我很想改变,可我真不知道该如何是好。我相信也有不少的同行和我有一样的苦恼,但方法我总算找到了。通讯网在30楼其实已经部分提到。
那就是 软件工程思想,虽然我还不是太理解。在计算机软件行业早就有了软件工程的思想。对,PLC编程也需要引入软件工程的思想。在从事计算机软件工程的人看来,我们这些数千上万行的PLC代码简直就是简单得可怜,毫无复杂概念所言。对于那些人来说,一年不知道要经历多少个封闭开发项目,一个项目数百M,几个G常见得多了去了,单是那些代码和那些表格,数据处理和那些数百上千页的开发文档,我一看才发现,PLC编程真的太小儿科。人家同样是干项目,几个人的小组,一周,半过月就搞定。相反我们的系统,几个眼镜码了一个月,还在调过去调过来。晕!
其实不是我们笨,而是我们没有掌握最好的方法,片面的追求编程技巧,在注重细节的同时丢掉了更重要的东西,正如33楼所说-------系统架构。记得坛子上多次提高到需要在系统架构的高度来考虑整个系统,甚至包含硬件系统。
如果我们这些面对PLC的人掌握了这些方法,我认为一样的能够又快又好的完成项目任务。
当然,行业的不同,也导致了我们写程序比那些搞计算机软件的面对和考虑的问题不一样,更复杂一些。但我相信,编程的思想是一样的。
其实,细细的看每一个回复,和每一个观点,才发现,我们都是盲人摸象,把大家的观点综合起来,其实就是软件工程的核心思想呀!
看来是不是可以这样定义:按软件工程思想编写的程序就是在现阶段下最好的程序。
引用 第五纪冰川 的回复内容: 我的观点来源于我对实践的总结,当然这可能是很片面的,对...
有过这样的经历,一样也在探索如何将高级语言的编程思想融入到plc的编程之中,但总觉的缺点什么,还望赐教
对于工程之中靠性排第一,在运行许可的情况下不一定要精简到极致,不然那么大ROM闲着也是闲着
对于第一次做工程的经历还是记忆犹新啊,
一次大工程,还是用小程序的思路去编,完蛋了,流程图画的好了,写到最后都不知道自己写的是啥,调试的时候更悲剧很难看懂,最后借鉴C语言的编程模块化思路,然后调用,虽然写的有点长,但是混乱度而言好多了
程序感觉只要将每个指令用到恰到好去就是高手,感觉没必要完全追求程序的精妙
菜鸟路过,随便说两句,望各位前辈不吝赐教
大家去看一下我这个帖子吧:http://bbs.e10000.cn/a/a.asp?B=302&ID=1027466,引出过很多技术同行有关程序的探讨。
还有一个有关模块化的帖子:http://bbs.e10000.cn/a/a.asp?B=302&ID=1226527
我也是苦苦求索过若干年,后来还是从德国的一些程序里面学到了一些感觉至今还没有被超越的编程思想。
我觉得有相当一部分朋友都走入了一个误区。。。
只要程序够简短就一定运行效率高么?
比方说同样一个功能,A君用了10个位指令,涉及3个位地址。B君用了5个字节控制指令,涉及2个位地址和两个字节地址。你说哪个程序运行更快?哪个更有效率??
我记得在官网论坛里,有高手提到过,少用转换功能。能不用尽量不用,用复位指令清空数据空余地址,然后直接调用数据就好了。因为转换指令是对该格式的整个地址进行操作,执行过程远比复位指令要复杂。
类似这样的小技巧,其实就是为了提升代码执行效率,减少冗余。别以为汇编语言就不会有冗余。冗余本来就是个相对的概念,一毛钱能搞定的事情,你非要花一块钱,那就叫冗余。
至于编程时无从下手的情况,个人表示不大会遇到。因为这与每个人的编程习惯有关,我就习惯先统计IO点,IO出来了,外部就确定了。然后考虑哪些功能放在外部更划算,最后就是需要PLC完成的部分。然后按照功能或者流程步骤来分块。分块了之后,再就开始写了。所谓的复用性,对于一部分人来说其实是很简单的东西。但如果你对设备工艺不够了解,那么你可能很难做出复用性出色的小模块。见的少了,自然就不好总结。见的多了,发现各种功能当中的共通之处则并不是很困难。
最后,强调一点!程序员的前途,其实是在程序之外的。。。当你能够横扫一个行业的时候,想编出不具备复用性的程序都难,因为那是你的习惯,办类似的事情你都是一样的办法。
每一个行业的设备不一样,程序风格即不一,德国人的生产线程序架构做的好,模块化,特别有个叫ALFINE的公司的程序。七楼芳兄的意见不错,“
未用心做过一个程序的都想楼上这么说的。什么自动化公司帮做的程序,一般都是随便做完,能动就算了。完全没有在客户方面想过这样做才能做好。常常发生一些客户无法理解而且又必须的操作才能继续工作的事。
我一般的同意楼主意见。
程序本身就是要达到功能。好,谁评呢?用户。
好的程序要好操作。自动。纠错。顺理成章。
如何好操作呢?比如:什么状态就自动弹出什么界面。不需要你操心去翻。
如何自动呢?比如:一个行走机械前方有若干个可以停靠的站,程序应该可以根据当前位置意料到操作者需要把机械停在应该去的位置,而不是由操作者看着机械去停机。
如何纠错呢?无论是操作错还是电眼断线……大家都懂的了。只是不做而已。
如何顺理成章?手工操作做到哪个步骤,随时切换到自动,都要可以无缝切换。
我觉得纠错能力最重要。”
我在上海做项目时遇到一个客户,那个客户的设备电气主管就是这么要求的。
在广东一个地级市看到一个三菱的FX2N的程序,当时是用户要改一个动作顺序,找遍整个市里的同行都看不懂,程序做的很好,用地址指针做的,我想可能是电镀行业的通用程序吧,但原创可能是老外,