1. 为什么CPU资源查看这件事值得单独拿出来讲
干工控这行的，尤其是天天跟西门子TIA博途打交道的兄弟，估计都遇到过类似场景：程序编译没问题，下载也顺利，但设备一跑起来就感觉哪里不对劲——扫描周期忽高忽低，HMI画面上数据刷新明显变慢，有时候甚至直接报出“循环时间超出”的报警。这时候大多数人第一反应是查程序逻辑，翻来覆去看OB1里是不是有死循环，或者怀疑通讯负载太高。但真正的问题，往往出在CPU自身的资源占用上。
TIA博途这个平台，功能确实强大，从S7-1200到S7-1500，从基础逻辑控制到运动控制、PID、通讯，几乎什么都能干。但正因为能干的事情太多，CPU内部的资源分配就变得非常关键。程序块占多少工作内存、通讯占多少连接资源、Web服务器开没开、诊断缓冲区记录了多少条、运动控制资源有没有被占满——这些东西平时不显山不露水，一旦逼近上限，设备就开始出各种“玄学”故障。
我见过太多现场，工程师把程序写得漂漂亮亮，但CPU负载常年挂在70%以上，扫描周期波动大得吓人，最后查来查去发现是某个FB块里开了大量背景DB，或者通讯连接数配得太多，把CPU的通讯资源吃干净了。所以，学会在TIA博途中查看和设置CPU资源，不是锦上添花的技能，而是保证设备稳定运行的基本功。
这篇文章主要面向已经有一定TIA博途使用基础、但还没系统梳理过CPU资源管理的朋友。我会从资源分类、查看方法、设置策略、常见坑点几个维度，把S7-1200和S7-1500这两大主流系列的相关操作讲透。不管你是刚入行一两年的新手，还是干了七八年的老手，相信都能从中找到一些之前忽略的细节。
2. CPU资源到底包含哪些东西
2.1 工作内存与装载内存的区别
很多人第一次在TIA博途里看CPU资源，会被“装载内存”和“工作内存”这两个概念搞晕。简单来说，装载内存相当于你电脑的硬盘，程序下载进去之后就存在那里，断电也不会丢；工作内存相当于内存条，CPU运行时真正执行代码用的是这部分空间。S7-1500的装载内存和工作内存是分开显示的，而S7-1200在某些固件版本里显示方式略有不同。
在博途里查看路径是：在线访问 → 选中CPU → 右键“在线和诊断” → “诊断状态” → “存储”选项卡。这里能看到装载内存的总量、已用、剩余，以及工作内存的代码区和数据区分别占了多少。我个人的经验是，工作内存的数据区往往比代码区更容易成为瓶颈，因为每个FB的背景DB、每个全局DB、每个工艺对象都要占数据区空间。
注意：S7-1200的工作内存是固定的，不能扩展。S7-1500部分型号支持通过存储卡扩展装载内存，但工作内存同样固定。选型时一定要根据程序规模留足余量，别等到下载时报“工作内存不足”才后悔。
2.2 通讯连接资源
通讯资源是另一个容易被忽视的大头。S7-1200最多支持多少个连接？S7-1500又能支持多少？这些数字在选型手册里都有，但实际项目中，HMI连接、编程设备连接、S7通讯、开放式用户通讯、Web服务器连接、OPC UA连接，每一项都要占用连接资源。而且不同协议占用的资源数量不一样，比如一个S7连接可能占1个资源，一个开放式用户通讯可能占多个。
在博途的“在线和诊断” → “诊断状态” → “通讯”选项卡里，可以看到当前已建立的连接数和最大连接数。如果发现连接数接近上限，就要考虑优化通讯架构，比如把多个HMI合并到一个连接里，或者用路由功能减少直接连接数。
2.3 运动控制与工艺对象资源
只要项目里用了运动控制功能，比如控制V90伺服、步进电机或者做凸轮同步，就会涉及到工艺对象。每个工艺对象都要占用CPU的运动控制资源。S7-1200最多支持多少个轴？S7-1500又能支持多少？这些在选型时就要确认清楚。而且运动控制资源不仅跟轴数量有关，还跟每个轴的更新周期、编码器类型、是否启用同步功能有关。
在博途里查看路径是：“在线和诊断” → “诊断状态” → “运动控制”选项卡。这里能看到已配置的轴数量、当前使用的资源百分比。如果资源占用超过80%，就要警惕了，因为运动控制对实时性要求极高，资源不足会导致轴定位精度下降甚至报故障。
2.4 Web服务器与诊断缓冲区资源
Web服务器功能在S7-1500上很常用，方便远程查看CPU状态。但开启Web服务器会占用额外的CPU资源，包括内存和通讯连接。而且Web服务器的刷新频率、同时访问的客户端数量都会影响CPU负载。诊断缓冲区也是类似，虽然它不直接占用大量资源，但如果记录条数设得太多，或者频繁触发诊断事件，也会增加CPU的处理负担。
在“在线和诊断” → “诊断状态” → “Web服务器”选项卡里，可以看到Web服务器的状态和当前访问情况。诊断缓冲区的设置则在“属性” → “诊断缓冲区”里调整。
3. 在TIA博途中查看CPU资源的完整操作流程
3.1 在线连接与诊断入口
首先确保你的编程电脑和CPU在同一个网络中，或者通过USB编程电缆连接。在博途项目树中选中CPU，点击“在线”按钮，等待连接建立。连接成功后，CPU图标上会出现一个绿色的小三角。
然后右键点击CPU，选择“在线和诊断”。这个界面是查看CPU资源的核心入口，里面包含了诊断状态、诊断缓冲区、功能、维护等多个选项卡。我习惯先看“诊断状态”里的“存储”和“通讯”，这两个是最直观反映资源占用的地方。
实操心得：如果你用的是S7-1200固件V4.0以上版本，在线和诊断界面会比老版本丰富很多。建议把博途升级到V15或更高版本，资源查看的粒度更细，显示也更准确。
3.2 存储资源查看与解读
进入“诊断状态” → “存储”选项卡后，你会看到几个关键数据：装载内存的总量、已用、剩余；工作内存代码区的总量、已用、剩余；工作内存数据区的总量、已用、剩余。单位通常是KB或MB。
这里有个细节要注意：博途显示的工作内存已用量，是编译后的实际占用量，不是源代码大小。有时候你删了几个FB，但编译后已用量没怎么变，那是因为编译器做了优化，或者背景DB仍然占着数据区。真正要关注的是“剩余”那一栏，如果剩余量低于总量的20%，就说明程序规模已经接近CPU上限了。
我一般会在项目初期就估算一下程序规模。比如一个中等复杂度的S7-1200项目，OB1加十几个FB、几十个DB，工作内存数据区大概占200-400KB。如果选的是CPU 1214C，工作内存数据区总共才100KB，那肯定不够用。所以选型时一定要留足余量，至少按预估量的1.5倍来选。
3.3 通讯资源查看与连接数管理
“诊断状态” → “通讯”选项卡里，会列出当前所有已建立的通讯连接，包括连接类型、本地端点、远程端点、状态等。同时会显示“已使用的连接资源”和“最大连接资源”的对比。
S7-1200的最大连接资源通常是8个（具体型号有差异），S7-1500则从16个到64个不等。这里要特别注意：编程设备连接（也就是你的博途）也占一个资源。所以如果你一边在线监控，一边HMI在通讯，一边还有S7通讯在跑，资源消耗是叠加的。
如果发现连接资源紧张，可以考虑以下优化措施：把多个HMI连接合并到一个S7连接里；用PUT/GET通讯代替多个独立的开放式用户通讯；关闭不必要的Web服务器连接；减少编程设备的在线时间。
3.4 运动控制资源查看
“诊断状态” → “运动控制”选项卡里，会显示已配置的工艺对象数量和资源占用百分比。S7-1200最多支持4个轴（具体取决于型号），S7-1500从8个到几十个不等。
这里有个坑：即使你没有实际启用某个轴，只要在项目中配置了工艺对象，它就会占用资源。所以如果某个轴暂时不用，最好把它从项目中删除，而不是仅仅禁用。另外，每个轴的更新周期也会影响资源占用，更新周期越短，占用的CPU时间片越多。
3.5 Web服务器与诊断缓冲区查看
“诊断状态” → “Web服务器”选项卡里，可以看到Web服务器是否启用、当前访问的客户端数量、使用的语言等。如果Web服务器不是必须的，建议在“属性” → “Web服务器”里把它关掉，能省下不少资源。
诊断缓冲区的查看在“诊断缓冲区”选项卡里，这里会列出所有诊断事件，包括错误、警告、信息。虽然诊断缓冲区本身不直接占用大量CPU资源，但如果记录条数设得太多（比如1000条以上），在频繁触发诊断事件时，CPU处理这些记录也会消耗时间。我一般建议把诊断缓冲区设为200-500条，既能满足排查需求，又不会给CPU增加太多负担。
4. CPU资源设置与优化策略
4.1 工作内存优化：从代码层面减负
工作内存不够用，最根本的解决办法是优化代码。几个实用的技巧：第一，尽量用FC代替FB，因为FC不需要背景DB，能省下数据区空间；第二，多个FB如果功能相似，可以考虑合并成一个FB，用不同的输入参数来区分；第三，全局DB里的变量如果不需要保持，可以设为“非保持”区域，这样编译器可以更灵活地分配空间；第四，删除未使用的变量和块，博途虽然会自动清理，但手动检查一遍更放心。
还有一个容易被忽视的点：S7-1200的优化块访问功能。在DB属性里勾选“优化的块访问”后，编译器可以更高效地分配内存，而且访问速度更快。但要注意，优化块不能用于某些老式通讯方式，比如绝对地址访问。所以如果项目里有第三方设备通过绝对地址读写DB，就不能用优化块。
4.2 通讯资源优化：连接数与协议选择
通讯资源的优化，核心思路是“能合并就合并，能不用就不用”。具体来说：HMI连接尽量用S7连接而不是开放式用户通讯，因为S7连接占用的资源更少；多个HMI如果访问同一台CPU，可以考虑用HMI的“多路复用”功能，减少连接数；PUT/GET通讯虽然方便，但每个连接都要占资源，如果数据量不大，可以考虑用S7通讯代替。
另外，S7-1500支持OPC UA服务器功能，这个功能很强大，但也会占用额外的通讯资源。如果项目里不需要OPC UA，建议在“属性” → “OPC UA”里把它关掉。
4.3 运动控制资源优化：轴数量与更新周期
运动控制资源的优化，主要从两个方面入手：一是减少轴数量，二是调整更新周期。如果某个轴只是做简单的点位控制，不需要高精度同步，可以把更新周期设长一些，比如从1ms调到4ms，这样能显著降低CPU负载。
另外，S7-1500的“运动控制”功能支持“动态资源分配”，也就是说，不是所有轴都必须一直占用资源。如果某个轴在特定时间段内不动作，可以通过程序控制暂时释放资源。但这个功能需要较新的固件版本，而且编程复杂度较高，建议在充分测试后再用到实际项目中。
4.4 Web服务器与诊断缓冲区设置
Web服务器如果确实需要，建议把刷新频率调低，比如从1秒调到5秒，同时限制同时访问的客户端数量。诊断缓冲区则建议设为200-500条，并且定期清理。如果CPU经常报诊断事件，要先排查根本原因，而不是简单地把缓冲区设大。
注意：S7-1200的Web服务器功能相对有限，资源占用也比S7-1500高。如果项目对成本敏感，建议用HMI代替Web服务器来实现远程监控。
5. 常见问题与排查技巧实录
5.1 下载时报“工作内存不足”怎么办
这是最常见的问题之一。首先在“在线和诊断”里确认当前工作内存的已用量和剩余量。如果剩余量确实很小，说明程序规模已经接近CPU上限。解决办法：一是优化代码，删除不必要的块和变量；二是检查是否有大量背景DB占用了数据区；三是考虑换更高型号的CPU。
如果剩余量看起来还够，但下载仍然报错，可能是编译缓存的问题。可以尝试“编译 → 软件（全部重建）”，然后重新下载。有时候博途的编译缓存会保留一些已删除块的空间，全部重建能释放这些空间。
5.2 扫描周期波动大，如何定位原因
扫描周期波动大，通常跟CPU资源占用有关。首先在“在线和诊断” → “循环时间”里查看当前扫描周期和最大扫描周期。如果最大扫描周期远大于当前扫描周期，说明有偶发的资源抢占。
常见原因包括：通讯负载突然增大、运动控制轴同时动作、Web服务器被访问、诊断事件频繁触发。排查方法是逐个关闭这些功能，观察扫描周期变化。我一般会先关Web服务器，再关运动控制，最后检查通讯连接。
5.3 通讯连接数达到上限，如何快速释放
如果发现连接数已满，无法建立新连接，可以先在“在线和诊断” → “通讯”里查看哪些连接是活动的。如果是编程设备连接占用了资源，可以断开博途的在线连接，释放资源。如果是HMI连接，可以重启HMI或者断开HMI的网络。
长期解决方案是优化通讯架构，减少不必要的连接。比如把多个HMI合并到一个连接里，或者用路由功能让HMI通过PLC中转通讯。
5.4 运动控制资源不足，轴无法使能
运动控制资源不足时，轴可能无法使能，或者使能后报故障。首先在“在线和诊断” → “运动控制”里查看资源占用百分比。如果超过90%，说明资源已经接近极限。解决办法：减少轴数量、调整更新周期、或者换更高型号的CPU。
另外，S7-1200的运动控制资源是固定的，不能扩展。如果项目需要控制多个轴，建议直接选S7-1500，资源更充裕，扩展性也更好。
5.5 诊断缓冲区频繁报错，如何排查
诊断缓冲区频繁报错，说明系统中有持续存在的异常。常见的诊断事件包括：模块故障、通讯超时、电池电量低、循环时间超出等。排查方法是先看诊断缓冲区的详细描述，确定错误类型和发生频率，然后针对性地检查硬件和程序。
如果错误是“循环时间超出”，说明CPU负载过高，需要优化程序或减少通讯负载。如果错误是“通讯超时”，说明某个连接不稳定，需要检查网络和通讯伙伴的状态。
6. 几个容易被忽略的细节与个人经验
6.1 固件版本对资源查看的影响
不同固件版本的CPU，在资源查看和设置上差异很大。比如S7-1200固件V4.0之前，在线和诊断界面比较简单，很多资源信息看不到。V4.0之后，界面丰富了很多，但也有一些功能需要V4.2以上才支持。所以建议在项目开始前，先确认CPU的固件版本，必要时升级到较新版本。
升级固件有风险，操作前一定要备份程序和参数。而且升级后，某些老程序可能需要重新编译才能正常运行。
6.2 存储卡对资源的影响
S7-1500支持用存储卡扩展装载内存，但工作内存不能扩展。所以如果程序规模大，装载内存不够，可以换更大的存储卡。但工作内存不够，只能换CPU。这一点在选型时就要考虑清楚。
另外，存储卡还用于存储配方、数据记录等。如果项目里用了这些功能，也要预留足够的存储卡空间。
6.3 在线修改对资源的影响
在设备运行过程中，如果通过博途在线修改程序，会临时占用额外的CPU资源。频繁的在线修改可能导致扫描周期波动，甚至触发循环时间超出报警。所以建议在设备停机时进行程序修改，或者至少避开生产高峰期。
如果必须在线修改，尽量只改逻辑，不要改硬件配置和通讯设置。改完后及时下载并观察扫描周期变化。
6.4 个人踩坑记录
我曾经遇到过一个项目，S7-1200的CPU，程序编译下载都正常，但设备运行一段时间后就会报“循环时间超出”。查了半天程序逻辑，没发现死循环。后来在在线和诊断里看资源占用，发现工作内存数据区已经用了95%，通讯连接数也接近上限。原来是一个FB的背景DB里定义了一个很大的数组，占用了大量数据区空间。把数组改小之后，问题就解决了。
还有一次，S7-1500的项目，运动控制轴总是使能失败。查了资源占用，发现运动控制资源已经用了92%。原来是有几个轴配置了但实际没用，占着资源不放。把不用的轴删除后，问题解决。
这些经历告诉我，CPU资源查看不是可有可无的操作，而是设备调试和运维的必备技能。养成定期查看资源占用的习惯，能提前发现很多潜在问题。
6.5 资源查看的时机建议
我一般会在以下几个时间点查看CPU资源：项目初期选型时，估算程序规模，确认CPU型号是否够用；程序下载后首次运行时，查看实际资源占用，确认是否在安全范围内；设备运行一段时间后，定期查看资源变化，及时发现异常；设备出现故障时，第一时间查看资源占用，排除资源不足的可能性。
这几个时间点覆盖了项目的全生命周期，能最大程度避免因资源问题导致的设备故障。
7. 资源设置中的几个关键参数详解
7.1 循环时间监控设置
在CPU属性里，有一个“循环时间”设置项，可以设置最小循环时间和最大循环时间。最小循环时间用于保证扫描周期的稳定性，最大循环时间用于触发报警。我一般会把最大循环时间设为实际扫描周期的3-5倍，这样既能及时发现异常，又不会因为偶发的负载波动误报警。
如果最大循环时间设得太小，比如只比实际扫描周期大20%，那稍微有点通讯负载就会触发报警，反而影响生产。如果设得太大，又起不到监控作用。所以这个参数要根据实际负载情况来调整。
7.2 通讯负载设置
在CPU属性里，有一个“通讯负载”设置项，可以设置通讯占CPU时间的百分比。默认值通常是20%，也就是说，通讯最多占用20%的CPU时间，剩下的80%留给程序执行。如果项目里通讯量很大，可以适当提高这个比例，但不要超过50%，否则会影响程序执行的实时性。
这个参数在S7-1500上尤其重要，因为S7-1500的通讯功能更丰富，OPC UA、Web服务器、S7通讯、开放式用户通讯都可能同时运行。合理设置通讯负载，能保证程序执行不受通讯影响。
7.3 诊断缓冲区设置
诊断缓冲区的设置包括记录条数和记录类型。记录条数建议设为200-500条，记录类型建议只记录错误和警告，不记录信息。这样可以减少CPU处理诊断事件的开销，同时保留足够的排查信息。
如果项目对诊断要求很高，比如需要记录所有通讯事件，那可以适当增加记录条数，但要密切观察CPU负载变化。
7.4 Web服务器设置
Web服务器的设置包括启用/禁用、刷新频率、访问权限、语言等。如果不需要远程监控，建议直接禁用。如果需要，建议把刷新频率设为5秒以上，访问权限设为只读，语言只保留中文和英文。
另外，Web服务器的访问会占用通讯连接资源，所以如果连接资源紧张，要优先保证HMI和编程设备的连接。
8. 从资源查看延伸到系统性能优化
8.1 程序结构对资源的影响
程序结构对CPU资源的影响很大。好的程序结构应该是模块化的，每个FB只负责一个功能，背景DB尽量小，全局DB按功能分区。这样的结构不仅便于维护，也能让编译器更高效地分配内存。
相反，如果所有逻辑都堆在OB1里，或者一个FB里塞了几百个变量，那工作内存的利用率就会很低，而且扫描周期也会变长。我见过一个项目，OB1里有上千行代码，扫描周期一直在20ms以上，后来把逻辑拆分成多个FB，扫描周期降到了5ms以内。
8.2 数据类型对资源的影响
数据类型的选择也会影响资源占用。比如，能用BOOL就不用INT，能用INT就不用DINT，能用DINT就不用REAL。虽然单个变量差别不大，但积少成多，几百个变量下来，差距就很明显了。
另外，数组和结构体的使用也要注意。大数组会占用大量数据区空间，如果数组元素不是全部使用，可以考虑用动态数组或者分段存储。
8.3 通讯协议对资源的影响
不同通讯协议对CPU资源的占用差异很大。一般来说，S7通讯的资源效率最高，开放式用户通讯次之，OPC UA和Web服务器占用资源较多。所以如果项目对资源敏感，优先选择S7通讯。
另外，通讯的刷新频率也会影响资源占用。比如HMI的刷新频率从1秒调到2秒，通讯负载就能降低不少。如果HMI只是显示一些不常变化的数据，刷新频率完全可以设长一些。
8.4 运动控制对资源的影响
运动控制是CPU资源消耗的大户。每个轴都要占用CPU时间片来处理位置环、速度环、编码器反馈等。如果轴数量多，或者更新周期短，CPU负载就会很高。
优化运动控制资源的方法包括：减少轴数量、调整更新周期、使用动态资源分配、选择更高性能的CPU。另外，如果某些轴只是做简单的点位控制，可以考虑用普通IO控制代替运动控制，这样能省下不少资源。
9. 实际项目中的资源管理案例
9.1 案例一：S7-1200包装机项目
这是一个典型的S7-1200项目，控制一台包装机，有3个伺服轴、1个HMI、1个编程设备连接。程序规模中等，大概有20个FB、50个DB。选型时用的是CPU 1215C，工作内存数据区125KB。
程序下载后，查看资源占用：工作内存数据区用了85KB，剩余40KB；通讯连接数用了4个，剩余4个；运动控制资源用了60%。整体来看，资源还有余量，但不算宽裕。
运行一段时间后，发现扫描周期偶尔会波动到15ms以上。查看诊断缓冲区，发现有“循环时间超出”的警告。进一步排查，发现是HMI的刷新频率设得太快（500ms），导致通讯负载偏高。把HMI刷新频率调到1秒后，扫描周期稳定在8ms左右，问题解决。
这个案例说明，即使资源占用看起来还有余量，但通讯负载过高也会影响扫描周期。合理设置HMI刷新频率，是优化CPU负载的重要手段。
9.2 案例二：S7-1500多轴同步项目
这是一个S7-1500项目，控制一条生产线，有8个伺服轴需要同步运行，还有2个HMI、1个SCADA系统通过OPC UA连接。选型时用的是CPU 1516-3 PN/DP，工作内存数据区1MB，运动控制资源支持16个轴。
程序下载后，查看资源占用：工作内存数据区用了400KB，剩余600KB；通讯连接数用了12个，剩余20个；运动控制资源用了75%。整体来看，资源比较充裕。
但运行一段时间后，发现某些轴的同步精度下降，偶尔报“跟随误差过大”。查看运动控制资源，发现占用已经升到90%以上。排查后发现，是OPC UA服务器的刷新频率设得太快（100ms），占用了大量CPU时间，导致运动控制的时间片被压缩。把OPC UA刷新频率调到500ms后，运动控制资源降到80%以下，同步精度恢复正常。
这个案例说明，运动控制资源不仅跟轴数量有关，还跟其他功能的资源占用有关。在高精度运动控制项目中，要优先保证运动控制的资源需求，其他功能要适当让步。
9.3 案例三：S7-1200小型设备改造项目
这是一个改造项目，原来的设备用的是S7-200，现在要换成S7-1200。程序逻辑不复杂，但有一些老式的通讯协议，比如自由口通讯。选型时用的是CPU 1214C，工作内存数据区100KB。
程序移植后，发现工作内存数据区用了90KB，剩余只有10KB。而且自由口通讯占用了大量通讯资源，导致HMI连接不稳定。后来把自由口通讯改成S7通讯，工作内存数据区降到70KB，通讯资源也释放了不少，HMI连接稳定了。
这个案例说明，老设备改造时，要注意新CPU的资源限制。S7-1200虽然功能强大，但资源比S7-200紧张，移植程序时要做好优化。
10. 资源查看与设置的长期维护建议
10.1 建立资源基线
在项目首次调试完成后，记录下CPU的各项资源占用数据，作为基线。以后每次修改程序或增加功能后，对比基线数据，就能快速发现资源异常。我一般会把这些数据记在项目文档里，包括工作内存已用量、通讯连接数、运动控制资源占用率等。
10.2 定期巡检
对于长期运行的设备，建议每季度或每半年做一次资源巡检。查看资源占用是否有明显变化，诊断缓冲区是否有新的错误记录。如果发现资源占用持续上升，要及时排查原因，可能是程序里有内存泄漏，或者通讯连接没有正常释放。
10.3 程序版本管理
每次修改程序后，保留一个版本备份。如果新版本导致资源占用异常，可以快速回退到旧版本。博途的版本管理功能虽然不如专业的版本控制软件，但基本的备份和对比功能还是有的。
10.4 文档记录
把资源查看的结果、优化措施、参数设置都记录下来，形成项目文档。这样即使换了人维护，也能快速了解CPU的资源状况。我见过很多项目，因为缺乏文档，后来的人根本不知道CPU资源已经接近上限，结果一加功能就出问题。
10.5 培训与传承
如果是团队协作，建议把CPU资源查看和设置的方法教给团队里的每个人。这不是什么高深技术，但需要有人提醒和指导。我一般会在项目启动会上专门讲一下资源管理的要点，让大家都养成查看资源的习惯。
11. 写在最后的一些个人体会
CPU资源查看这件事，说大不大，说小不小。它不像写程序逻辑那样有成就感，也不像调试运动控制那样有技术含量，但它却是保证设备稳定运行的基础。我干了这么多年工控，见过太多因为资源不足导致的“玄学”故障，最后查来查去都是资源问题。
我的建议是，把资源查看当成和程序下载一样常规的操作。每次下载完程序，顺手看一眼资源占用；每次设备出故障，先查一下资源状态。养成这个习惯，能帮你省下大量排查时间。
另外，选型时一定要留足资源余量。别为了省几百块钱选了个资源紧张的CPU，后期加功能时捉襟见肘，反而更麻烦。S7-1200和S7-1500的选型手册里都有详细的资源参数，选型时仔细看看，按预估量的1.5倍到2倍来选，基本不会出问题。
最后再分享一个小技巧：如果你不确定某个功能会占用多少资源，可以先在测试CPU上试一下，查看资源占用后再决定是否用到实际项目中。这个方法虽然笨，但很有效，尤其是对于运动控制、OPC UA这些资源消耗大的功能。
