初入PLC领域我还依稀的记得当时西门子、三菱、欧姆龙争夺市场的情形。三家各自推出性价比比较高的产品，都提供比较优质的服务。西门子这一块我是深有感触。当时作为小白对PLC不是很了解，一遇到项目或者项目实施的过程中遇到困难就拨打400电话。当时西门子的服务工程师不仅能够解答你的问题还会给你一些启发，更有甚者还帮你检查程序。回想当年真的是PLC的好时代。
回到现在你要是遇到些问题拨打400服务电话先要预约最快一小时最慢估计要到明天了，关于问题能回答很溜的就不错了。也不要指望他能够帮你分析或者给你些启发。
总而言之现在要学习PLC系统要么自学、要么报课程学、要么跟随公司老师傅学习。学习环境没有以前那么乐观。更别提教你如何构思PLC程序，如何思考PLC程序。教会你如何使用已经是阿弥陀佛了。接下来用我身边的实际发生的事情谈谈程序结构的重要性。
我身边也有个把同事从技术支持转到PLC自控这个岗位，他们以前也多多少少看了不少PLC程序。照常理来说应该有一些程序的概念，事实上呢没有而且是完全没有。我发现他们在拿到别人的程序从来不去思考别人为什么要这么写这段程序，而只是下载后看看运行的正不正常。如果哪里有问题到程序里查看下，搞不定问下写程序的人。最后也是勉强把设备调试完成了。完成后也会研究下程序，但是只是研究程序逻辑，不会在程序结构上思考。久而久之习惯了拿来主义，让他独立开发一套程序就很困难了，就算能够完成后期问题也是五花八门。接下来我展示下一个同事写的程序段，程序已经正常运行但是总是有稀奇古怪的问题。
查看了他的程序满屏都是启保停程序段，都在OB1块里写的。询问了他以前是不是使用欧姆龙的PLC的，他说没有用过。那具体都不知道他为什么会这样写。逻辑思路都是对的，报错停机什么的也是正确的，关键就是会出现问题而且是事故性的。光从逻辑角度查问题是查不出来的，很费解。
但是另一套程序与他一样的逻辑不一样的程序思路的程序硬是没有出现问题，弄的他自己也很无语。有很多人认为用最简单的程序去表达，对于后期维护会很容易，其实这理论上是成立的。因为你的程序每一段都能被现场维护人员看懂且方便以后查找问题。但是我们的程序都是环环相扣的如果单纯的使用启保停电路反而会加重后期程序维护的成本。因为程序太碎了，七零八落。一旦动态了就不知道哪里出现问题了。
经过上述的一些经历，我们在编写程序前就要慎重再慎重。一定要好好去思考如何写，以什么样的一个形式去写。不能草草下笔，然后就是在不停地修补修补，弄得最后可能自己都觉得这程序有点陌生。
在这里我们在试想下如果每一次我们在编写程序都进行有效的构思，充分的思考程序的可扩展性。那么久而久之我们的思维就被锻炼了。不会在为如何下手而苦恼了。也不会因为这家使用西门子、哪家使用三菱而担忧了。因为对应一个成熟的PLC程序员来说PLC基本都是一样的，略微有点差别。稍稍适应下就可以上手了。
