1、学习PLC编程需要坚强的毅力和足够的耐心
人各有所长。有些人把编程看作一项冗长而枯燥的工作;有些人把编程看作一项趣味的智力游戏。如果你是前者,强烈建议你远离这份工作。毕竟编程工作是对人的毅力和耐心的挑战。我所在实验室中,很多学生看到我编程序就会惊讶于我面对这一堆堆符号所表现出的专注。其实,这是兴趣使然。兴趣使我具备了足够的毅力和耐心。经过无数次失败后,当看到一个个符号按我的思路整齐的排列,PLC按我的要求有条不紊的运行时,兴趣得到了极大的满足,如同打通了一个游戏的关口。所以,我告诉这些学生:你们看到的是一堆枯燥怪异的符号,我看到的却是一群热情奔放的舞者,而我则是她们的导演。
2、学习PLC编程需要敢于实践的信心
我曾经教过一个学生学AutoCAD,我对她的唯一要求就是实践。我告诉她:你随便怎么操作,大不了一张图重画;最坏的结果是系统崩溃,没关系,系统重做,再来;只要电脑没被砸了,怎么都行。两年后,我再看到她做的CAD图纸,也自叹不如。
同样道理,只有不断地在PLC上运行这些指令,观察运行的结果,才能弄清PLC指令的作用。很多初学者对PLC一脸的迷茫,往往是出于一种畏惧,担心损坏设备。而这些畏惧是没有任何道理的。仔细的阅读手册是非常重要的,但是仅靠读书是成不了一个工程师的。更何况手册上的内容并非面面俱到。我在接触到那些不熟悉的指令时,喜欢单独编一个小程序,让PLC运行。然后逐个修改条件,观察运行的结果(MicroWin为用户提供了非常好的监控手段),反过来再重新理解手册的描述,这样就可以非常直观的理解这些指令的作用和使用方法。不必担心自己写的程序会有什么问题,会影响PLC的正常工作。程序有没有问题,只有让PLC运行了才能发现。而发现问题并解决问题就是对自己能力的提高。撇开硬件操作不谈,单就软件来说,我还真没有遇到过由于软件问题而损坏PLC的事。在这里不必担心继电器电路接错线可能造成的后果。所以,大胆的实践是PLC编程的必由之路。
当然,大胆实践并不是野蛮操作,而是必须遵循必要的规范。还有一个要注意的,在程序未经可靠性证实之前,千万不要挂接负载,以免造成不必要的损失。数字量的输出有LED显示;而模拟量处理可以采用一些硬件或软件模拟手段来解决。
3、学习PLC编程需要有缜密的逻辑思维
编程本身就是一种逻辑思维过程。在高级语言中,使用最多的是if then else、select这些条件判别语句,这就是逻辑中的因果关系。PLC程序就是由这些因果关系组成的:判别条件是否成立,进而决定执行相应的指令。最初的PLC是用来替代继电器逻辑电路的,所以继承了继电器电路以触点作为触发条件的描述方式。在PLC中,以虚拟触点代替了继电器的金属触点,而继电器电路所表达的逻辑关系还是被完整的保留下来。即使引入了继电器电路难以胜任的数值处理过程,PLC从根本上还是在执行一个个因果关系。所以,理顺对象的各个事件之间的逻辑关系,是编程之前必须精心做好的准备工作。我在接到一项任务后,第一件事就是整理出一份逻辑关系图,与用户反复商讨,取得用户的认可,然后才真正进入程序的编写过程。
4、学习PLC不可或缺的相关知识
PLC的程序是直接作用于对象的具体工艺过程,那么对对象具体工艺过程的理解是非常重要的的。我在与用户的交流过程中,会用我所掌握的Unit Operation的知识分析用户的工艺过程,协助用户整理过程控制中的各个逻辑关系,甚至包括各种仪表、硬件的配置。这得益于我原本所学的专业。当然,不能要求所有搞PLC程序的工程师都有我这样的经历。但是有两门知识却是不可或缺的:一是过程仪表的硬件知识,包括传感器、变送器(二次仪表)和PLC本身,这是构建控制系统的基础;二是过程控制理论,包括各种控制模型的原理和应用,其中最重要的是二位调节和PID调节模型。PID调节是目前用得最广泛的过程控制手段,且变化多端。学习PID最好的方法就是读书。几乎所有讲解过程控制的书籍都有关于PID的内容,多读基本相关的书籍对理解PID是很有益处的。我发现不少网友在进入PLC领域时,缺乏这些相关知识。这并不可怕;可怕的是当事者不能静下心来弥补知识的缺陷。我们不要怪罪学校没有教授这些内容,而是要注重自己如何去学习这些知识。工作中遇到的许多问题是学校里没讲过的,这不能成为我们拒绝工作的理由,而应该以积极的态度去应对这些问题。我的体会是,为了解决工作中的问题而学习的知识,比课堂上学的东西更容易记住。
5、学习PLC需养成良好的编程习惯
每个人编程都会有不同的习惯和特点,不能强求一致。但是一些好的习惯还是应该为大多数人所遵循。一是理顺逻辑关系、时序关系,编制程序框图;二是合理分配主程序、子程序和中断程序;三是合理分配寄存器,编制寄存器符号表。
PLC编程更接近于单片机,或者说PLC就是模块化的单片机。因此PLC的很多操作都是直接针对寄存器的,如果在程序中出现不合理的寄存器地址重叠,一定会出现不可预想的后果。编制寄存器符号表不仅可以避免上述问题(MicroWin会有问题提示),而且可以使程序具备更好的可读性。这和VB中定义变量有异曲同工之处。
VB编程中关注的是事件,不强调主程序和子程序的观念,因为VB主程序的工作是由PC的操作系统完成的。PLC则不然。PLC程序是以主程序为主干的,CPU不断的循环执行主程序,只有触发条件成立时才会调用子程序或中断程序。即子程序和中断程序所执行的任务不是全时需要的。如果把这些任务都放在主程序中会无端增加主程序的工作量,降低程序的效率。这点和单片机的编程思路是一致的。子程序的使用可以使整个程序的逻辑更清晰。而且子程序可以分开编写、调试,最后“安装”到主程序上。这样你可以一个一个解决问题。
PLC编程,无论是LAD,抑或STL,都不如VB那么直观、有趣,更不如CAD那么形象。但比单片机的汇编语言的可视性强多了。对于初学者,LAD(梯形图)的编程相对直观,更容易上手。
最后,PLC提供了丰富的指令、模块,比单片机方便了很多。但是初学者编程时应尽量先使用简单的指令达到目的。尽管看上去有点土,却不失为一个入门的好途径,且对你理解那些较为复杂的指令会有帮助。具备了一定经验后,应该考虑掌握复杂指令的应用,以及程序的优化。
楼主最近还看过
LD不如VB直观?
我不这样看。
如果一个程序所描述的进程是一个单一、简单的进程,这时用VB来描述当然简单、明了。
但如果是多进程或多个复杂逻辑关系的判断过程,我认为“一眼所能看到”的,梯形图的信息量要比VB大得多。
为什么呢?
因为VB是一种一维信息表述手段,而梯形图表述是一种二维表述手段,用个形象的描述,即在梯形图内你可以看到“几个人在那里同时讲话”;相反,如果用VB来描述,你是不是得“把几个人讲的话从前到后顺次写出来”?而这种“一段一段写出每段讲话内容”的过程,是否至少得不停地上下卷动屏幕,你才看的过来?
梯形图就像学生站操场,而VB则像学生排长队,十个学生当然排一队最好,一千个学生如果不是横竖排列站满操场,而是从头排到尾,你当校长的就是长一双鹰眼,也一眼望不到头。
至于“梯形图不如CAD形象”,这简直就是闻所未闻的奇谈怪论了。一个是编程语言,一个是绘图工具,虽然外表看起来都是“图形”,但其实二者间风马牛不相及。莫非LZ每次编制PLC程序之前,都用CAD先绘制一遍梯形图的“图形”,然后再着手编程?