|
1 梯形图编程经验 优秀的工程师，一定是有强迫症的工程师！项目代码一定是优雅， “秀色可餐”的！！大家共勉！下面给大家分享一下梯形图编程经验。 1.1 使用状态机，慎用M元件
图1.1一堆M元件接手的第一个项目，一堆M元件，各种状态的判断使用的都是M元件，导致最终查bug的时候，异常困难，一会SET,一会RST的。这么写就说明程序作者，没有一个好的编程思想。咱们再看看下面这个图，更牛逼…… 图1.2客户的牛逼程序 某客户，写梯形图程序。。一行不够，还连写了好几行。也是服写这个程序的人，能写出这样的程序，也是很牛逼的。。。但是这么写梯形图程序，不但坑死自己而且还会坑死交接程序的负责人，这程序写的太差劲了……一堆M元件串在一起，找bug是非常困难的。如果这个项目过去很长时间了，如果有人想在这个项目中添加功能的话，估计也会无从下手的。这样写程序，会导致程序无法维护！！！ 我做的梯形图程序，一般这么处理： 图1.3采用状态机编程
在程序中考虑使用D元件，进行分步，分状态进行处理相关程序。写梯形图的时候，慎用M元件（HMI上开关量正常使用） 图1.4为状态字赋值
在项目程序中引入状态字状态机编程思想，每一个状态只做当前状态的任务。要思考如何进行状态解耦，要根据各个状态或者开关来给状态字进行赋值。 1.2 元件注释
《计算机程序结构与说明》一书在开篇写到：程序写出来是给人看的，附带能在机器上运行。就像男生喜欢美女，女生喜欢帅锅一样一样滴。编写的程序也能做到优雅漂亮，让别人在看的时候赏心悦目。 对于类似于C语言或者ST这样的高级编程语言，变量函数的命名也是讲究技术的，在变量命名上可以做文章。但是在小型PLC中梯形图元件并没有太多特殊性，好在我们的H3U小型PLC挺好用，每个元件都可以添加元件注释。这里元件注释，我给大家提供一种比较好的梯形图注释经验。 以下“v”开头代表变量，“c”开头代表常量，“h”开头代表HMI数据。“s”16位整形数据，“i”32位整形数据，“f”代表浮点型数据，“b”代表bool布尔型数据（开关量） 以下是我常用的注释前缀： vb_布尔变量 vs_16位整形变量 vi_32位整形变量 vf_浮点变量 cb_布尔变量 cs_16位整形常量 ci_32位整形常量 cf_浮点常量 hb_布尔变量 hs_16位HMI整形 hi_ hf_ 加上前缀之后，只要看到前缀就能很容易知道这个元件是变量还是HMI中的数据，是整形还是浮点型，是32位还是16位。这样一来注释就额外增加了很多重要提示信息。加上前缀可能会让注释变长，所以大家一定要精练一下注释，如果太长，不适合看。 图1.5元件注释举例
1.3 网络注释
图1.6元件注释举例
汇川编程软件，有网络注释功能，很好用。大家一定要善于利用，网络注释是对整个网络内容的注释，好的网络注释便于程序接手人快速入手。 图1.7元件注释举例
1.4 功能解耦
大家来对比一下下面俩个图，第一个图是钢板制袋机我接手的项目程序，第二个图是我完全推倒重写的程序。 1.8接手的坑爹程序
1.9完全推倒重写的程序
图1.8是我之前接手，客户想让我修改添加功能的程序。图1.9是我完全推倒重新写的这个项目程序。我接手这个程序的时候，真是一堆乱麻各种bug，客户还要求添加新功能，程序我看了2,3天愣是不知道该怎么把新功能加进去…… 受不了，于是完全推倒重写。也就有了现在这个项目总结。对比一下两幅图的子程序，大家应该可以看到了，我写的项目子程序很多，比1.8完善很多很多了。这是同一个项目啊，差别就这么大……图1.8明显是功能没有完全解耦嘛，一个子程序里可能做着好几个轴的不同任务，程序写的乱七八糟！！ 更有甚者，整个项目就1个main函数……然后程序再用一堆M元件，这样的程序能坑死很多接手项目的人……
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ | 
