如图 以上图片是一个淘宝模板，程序架构是将报警，复位，初始化，手动，轴控，自动等全部分开写的，好处就是好修改都集中在一个地方，不用到处找，坏处就是我没有感觉到。。。各位大佬是怎么用的程序架构？最关建的是，这个架构用步进梯形图能写嘛？我感觉这个架构和步进梯形图的结构很矛盾。步进梯形图是按工序顺序写的，逻辑性强，这个架构是按功能性写的。。。。反正我有点晕。。

不用到处找？
可能吗？比如报警（可能用三色灯之一或二）是哪个触发？如果屏幕没有提示，只查程序，是谁触发不需要到查找？
那种架构编程在自己熟悉的方式，换种方式不是不可以，看你的能力

这里是将报警功能集中到一个程序里，用的是其他程序段里的触点触发。这样一来，报警是不用到处找啊，比如电机报警，我去电机程序找，气缸报警我去气缸程序找，这样就很麻烦。

我的框架也差不多这样。

还是那句话，工艺决定程序架构。
但是听群里的大佬说，有个架构可以满足大部分控制需求。
反正我大部分程序都是这样的
初始化，异常（分停机和不停机），主程序，手动，自动。

看自己习惯，自己好调试的就是好框架

嗯，因为一些有经验的工程师，在写程序时，有自己的模板和架构，这样写法很熟练，很清楚，也能最大程序上避免BUG，主要是我编程少，经验不够，所以才想搞一套通用的程序结构。你这些FB块里关于结构体数据是杂用的？

就是自己没有框架，我编程少，为了少走弯路，所以就想借鉴一些别人的框架，框架一出来，程序的大概思路就出来了。这样就能避免很多新手踩的坑。

先尝试着把程序按照功能分段，每段处理特定的功能。后面写多了再慢慢整合。比如手动、自动、参数设置、轴控、气缸、报警处理、触摸屏显示等...，都可以尝试着分成一个个的程序段。我觉得框架不是问题，关键是程序写好后，后续要好扩展，好调试，很快定位问题点。

这些模板是用来快速开发程序的，不是用来方便维修的。维修的时候肯定要用搜索功能