1. 为什么CPU资源查看是博途项目里最容易被忽视的环节做西门子PLC项目的人尤其是刚接触TIA博途的朋友往往把绝大部分精力花在写逻辑、调通讯、做HMI画面上很少有人会主动去关注CPU的资源占用情况。我刚开始做项目那几年也是这样程序能跑通、设备能动起来就觉得万事大吉了。直到有一次一个S7-1200的项目在客户现场运行了三个月之后突然报错CPU直接进入停止模式产线停了两个小时。排查了半天才发现是程序里不断累积的通讯数据把CPU的通信资源耗尽了。那次之后我才真正意识到CPU资源查看和设置这件事不是可做可不做的“锦上添花”而是项目稳定运行的“保命底线”。所谓CPU资源在TIA博途的语境下主要涵盖几个维度程序存储器Work Memory的占用、装载存储器Load Memory的占用、保持性存储器Retentive Memory的使用、通信连接资源的消耗、以及CPU的扫描周期和实时负载。这些东西在项目开发阶段如果不加关注到了现场调试或者长期运行阶段就会以各种意想不到的方式暴露出来——轻则扫描周期变长导致响应迟钝重则CPU停机、数据丢失。这篇文章主要面向已经上手TIA博途、能独立完成基本组态和编程的工程师尤其是使用S7-1200和S7-1500系列的朋友。我会把CPU资源查看的入口、各项参数的含义、设置的方法、以及我在实际项目中踩过的坑尽可能完整地讲清楚。不管你是刚入门的新手还是做了几年项目的老手相信都能从中找到一些之前没注意到的细节。2. 博途里CPU资源到底藏在哪几个界面很多人在博途里找CPU资源信息的时候第一反应是在“在线诊断”里翻但实际上博途把资源相关的信息分散在了好几个不同的位置。如果你不知道每个位置对应的是什么很容易看了半天也抓不住重点。我下面按使用频率从高到低把几个核心入口逐一拆开讲。2.1 设备视图中的CPU属性面板这是最基础也是最常用的入口。在项目树里双击“设备与网络”进入设备视图点击CPU模块下方就会出现该CPU的属性面板。在属性面板的左侧导航栏里有几个跟资源直接相关的分组“存储器”分组这里显示的是CPU的装载存储器和程序存储器的容量信息。对于S7-1200来说不同型号的CPU内置的装载存储器容量差异很大比如1211C只有1MB而1215C有4MB。程序存储器也就是工作存储器则决定了你写的程序代码和块能占多少空间。“保持性存储器”分组这里可以设置保持性存储区的字节数。默认情况下S7-1200的保持性存储器是10KBS7-1500则更大。如果你在程序里用了大量的保持性变量比如配方数据、累计产量等这个值需要根据实际需求调整。“通信接口”分组这里可以看到CPU集成的以太网接口和PROFINET接口的配置信息包括IP地址、子网掩码等。通信资源的消耗跟这里的配置以及你建立的连接数量直接相关。注意在设备视图的属性面板里看到的存储器容量是CPU的硬件规格是固定的。你实际用了多少需要在线之后才能看到。2.2 在线与诊断中的存储器使用情况当你把程序下载到CPU并在线连接之后在项目树里选中CPU右键选择“在线与诊断”会弹出一个诊断窗口。这个窗口里的“存储器”选项卡才是真正能看到实际占用情况的地方。这里会显示几个关键数据参数名称含义关注要点装载存储器整个项目文件在CPU上的占用包括程序块、数据块、硬件组态、HMI组态等工作存储器代码程序指令占用的空间跟程序复杂度直接相关工作存储器数据数据块和变量占用的空间跟DB块数量和大小相关保持性存储器已使用的保持性字节数不能超过CPU规格上限我一般会在项目下载完成后第一时间打开这个界面看一眼确认装载存储器的占用率不超过70%。如果超过80%就要考虑优化程序结构或者换更大容量的CPU了。2.3 扫描周期与实时负载的查看扫描周期是CPU资源消耗最直观的体现。在“在线与诊断”窗口的“循环时间”选项卡里可以看到当前扫描周期、最小扫描周期和最大扫描周期。S7-1200的典型扫描周期在1-10ms之间S7-1500则更快通常在1ms以下。如果你发现最大扫描周期比最小扫描周期大很多比如最小2ms、最大15ms那就说明程序里存在某些条件触发的耗时操作比如大量的循环计算、频繁的通讯读写、或者某些FB块在特定条件下执行了复杂的逻辑。这时候就需要去定位这些“尖峰”产生的原因。另外在“诊断缓冲区”里也能看到一些跟资源相关的条目比如“存储器空间不足”、“通信连接数达到上限”等报警信息。养成定期查看诊断缓冲区的习惯能帮你提前发现很多潜在问题。2.4 通信连接资源的查看通信连接资源是很多人容易忽略的一块。S7-1200和S7-1500的CPU对同时建立的通信连接数是有上限的。比如S7-1200最多支持16个S7通信连接、8个开放式用户通信连接具体数值跟固件版本有关。如果你用了多个HMI、多个上位机、再加上PLC之间的通信连接数很容易接近上限。在“在线与诊断”窗口的“通信”选项卡里可以看到当前已建立的连接数和连接类型。如果发现连接数接近上限就需要考虑优化通信架构比如把一些不必要的心跳连接去掉或者把多个HMI的数据请求合并到一个连接里。3. 存储器资源的分配逻辑与设置方法存储器的设置是CPU资源管理里最核心的部分也是最容易出问题的地方。很多人对装载存储器、工作存储器、保持性存储器这几个概念的理解是模糊的设置的时候凭感觉填个数结果要么浪费了资源要么不够用导致停机。3.1 装载存储器与工作存储器的区别我用一个比较通俗的类比来解释装载存储器就像你电脑的硬盘工作存储器就像内存。你写的程序、组态的数据块、硬件配置信息全都存在装载存储器里相当于“存起来”。而CPU运行时需要把程序代码和相关的数据块加载到工作存储器里相当于“跑起来”。S7-1200的装载存储器是集成在CPU内部的不可扩展。S7-1500则可以通过插入SIMATIC存储卡来扩展装载存储器容量。工作存储器的容量则是固定的由CPU型号决定无法扩展。在博途里你可以在CPU属性的“存储器”分组里看到这两个存储器的规格值。但实际用了多少需要在线之后在“在线与诊断”里查看。我一般的做法是在项目开发阶段定期下载程序后查看工作存储器的占用率确保代码占用不超过50%、数据占用不超过60%。留出足够的余量是为了后续增加功能或者修改程序时不会捉襟见肘。3.2 保持性存储器的设置策略保持性存储器的设置需要根据实际需求来定。在CPU属性的“保持性存储器”分组里你可以设置保持性存储区的字节数。这个设置决定了断电后哪些数据会被保留。我见过很多项目工程师把所有DB块都设成了保持性结果保持性存储器很快就不够用了。正确的做法是只把真正需要断电保持的数据设为保持性比如累计产量、配方参数、设备运行时间等。而那些中间变量、临时计算结果完全不需要保持。在博途里设置保持性的方式有两种一种是在DB块的属性里勾选“保持性”另一种是在PLC变量表里对单个变量设置保持性。对于S7-1200来说保持性存储器的上限是10KB可调整范围0-10KBS7-1500则根据型号不同通常在100KB以上。提示如果你发现保持性存储器不够用但又确实有很多数据需要保持可以考虑把数据写到SIMATIC存储卡里或者通过HMI的配方功能来管理。不过这些方案会增加程序的复杂度需要权衡。3.3 存储卡在资源扩展中的角色对于S7-1500来说SIMATIC存储卡是扩展装载存储器的唯一方式。存储卡有两种模式程序卡和传输卡。程序卡是插在CPU上长期使用的相当于CPU的“硬盘”传输卡则是用来在多个CPU之间传递程序的。我建议在项目初期就根据程序规模选择合适的存储卡容量。如果程序里用了大量的HMI组态、配方数据、或者历史记录功能装载存储器的占用会比较大。一般来说S7-1500的项目我至少会配一张4MB以上的存储卡复杂项目会用到12MB甚至更大。另外要注意的是存储卡上的程序在下载时会覆盖CPU内部装载存储器里的内容。如果你换了一张存储卡原来的程序就不在了。所以存储卡一定要做好备份最好在电脑上保留一份完整的项目归档文件。4. 通信资源与连接数的实际管理经验通信资源的消耗是很多现场问题的根源但因为它不像存储器那样有一个直观的“占用率”百分比所以往往被忽视。我在实际项目中遇到过好几次因为通信连接数超限导致的故障下面把经验整理一下。4.1 S7-1200与S7-1500的连接资源上限不同型号的CPU通信连接资源的上限是不同的。以常见的型号为例CPU型号S7通信连接开放式用户通信连接PROFINET IO设备数S7-1200 CPU 1211C8816S7-1200 CPU 1215C16816S7-1500 CPU 1511-1 PN3232128S7-1500 CPU 1516-3 PN/DP6464256这些数值在博途的CPU属性里也能查到在“通信接口”分组下的“连接资源”里。我建议在项目规划阶段就把所有需要跟CPU通信的设备列出来算一下总共需要多少个连接。如果接近上限就要考虑用网关或者交换机来分担通信压力。4.2 HMI与上位机连接对CPU资源的影响一个HMI触摸屏通常会占用1-2个S7通信连接。如果你有多个HMI再加上上位机SCADA系统连接数消耗得很快。我见过一个项目用了3个HMI加1个WinCC上位机再加上PLC之间的通信总共占了12个连接而用的CPU是1215C上限是16个余量已经很小了。这种情况下可以考虑把HMI的连接方式从S7通信改成开放式用户通信比如TCP因为开放式用户通信的连接资源是独立计算的。或者把多个HMI的数据请求合并到一个连接里通过一个中间变量表来交换数据。4.3 通信负载对扫描周期的影响通信负载不仅占用连接资源还会影响CPU的扫描周期。每次通信读写都会消耗CPU的处理时间。如果通信频率太高、数据量太大扫描周期就会明显变长。我一般的做法是对于非关键数据把通信周期设长一点比如500ms或者1s对于关键数据才用100ms或者更短的周期。在博途里可以通过“循环中断”来组织通信任务把不同优先级的通信分配到不同的循环中断OB里避免通信任务阻塞主程序。另外S7-1500支持“通信负载”的设置在CPU属性的“循环”分组里可以设置通信占用的CPU时间百分比。默认是20%如果你的通信任务比较重可以适当调高但不要超过50%否则会影响程序执行的实时性。5. 扫描周期优化与程序结构的关联扫描周期是CPU资源消耗的最终体现。一个优化良好的程序扫描周期应该是稳定且可预测的而一个结构混乱的程序扫描周期会忽长忽短给系统带来不确定性。5.1 扫描周期变长的常见原因根据我的经验扫描周期异常变长通常有以下几个原因循环体里有大量的FOR/NEXT循环尤其是在循环次数不确定的情况下比如遍历一个很大的数组。这种操作会一次性占用大量CPU时间。频繁的通信读写每个通信读写指令都需要CPU去处理数据打包和解包如果在一个扫描周期里执行了多个通信指令扫描周期会明显拉长。复杂的数学运算浮点数运算、三角函数、PID控制等都会消耗较多的CPU时间。如果这些运算在每次扫描都执行累积起来就很可观。大量的DB块访问尤其是跨DB块的数据访问CPU需要做地址转换和边界检查比访问本地变量要慢。5.2 用循环中断OB来分摊负载博途里的循环中断OB比如OB30、OB31等是分摊CPU负载的好工具。你可以把一些不需要每个扫描周期都执行的任务放到循环中断里比如PID控制运算放到OB30设置100ms的循环周期通信数据打包放到OB32设置500ms的循环周期数据记录和统计放到OB33设置1s的循环周期这样主程序OB1的扫描周期就能保持稳定不会被这些周期性任务拖慢。而且循环中断OB有固定的执行周期对于需要精确时间控制的任务来说比在主程序里用定时器更可靠。5.3 程序块的分割与复用程序块的分割也是优化CPU资源的重要手段。我见过一些项目所有的逻辑都写在一个OB1里几千行代码从头到尾。这种结构不仅难以维护而且CPU在执行时无法有效利用优化编译器带来的优势。正确的做法是把功能相关的逻辑封装到FC或FB里然后在OB1里按需调用。对于需要保持状态的逻辑用FB对于纯计算或纯逻辑判断用FC。这样不仅程序结构清晰而且CPU在执行时可以更好地利用块调用的优化机制。另外对于S7-1500来说还可以利用“优化访问”的DB块。优化访问的DB块在存储器中的布局是编译器自动安排的访问速度比标准访问的DB块更快而且不会因为地址对齐问题浪费存储空间。在新建DB块时默认就是优化访问除非你有特殊需求比如需要通过绝对地址访问否则不要改成标准访问。6. 几个我实际踩过的坑和排查过程理论讲了不少下面分享几个我在实际项目中遇到的跟CPU资源相关的故障案例。这些坑有些是我自己踩的有些是帮别人排查时发现的希望能给你一些参考。6.1 保持性存储器溢出导致的CPU停机有一次一个S7-1200的项目在运行了半年之后突然停机诊断缓冲区里报的是“保持性存储器溢出”。我到现场之后在线查看了一下保持性存储器的使用情况发现已经用了9.8KB接近10KB的上限。排查后发现程序里有一个FB块每次调用时都会在背景DB里增加一个保持性变量用来记录该设备的运行次数。而这个FB块被调用了200多次每个背景DB都占用了保持性存储器。累积下来就把10KB用完了。解决办法是把运行次数的记录方式改了一下不再用保持性变量而是写到一个非保持性的DB块里然后通过HMI定期把数据保存到配方或者CSV文件里。这样既保留了数据又不占用保持性存储器。经验保持性存储器是稀缺资源一定要省着用。每增加一个保持性变量之前先问自己这个数据真的需要断电保持吗有没有其他方式可以实现6.2 通信连接数超限引发的间歇性通讯失败另一个项目用的是S7-1200 CPU 1215C带了两个HMI、一个上位机、还有一个远程IO站。调试的时候一切正常但运行了几天之后HMI上偶尔会出现数据不刷新的情况过几秒又恢复了。我在线查看了一下通信连接数发现已经用到了15个而1215C的上限是16个。也就是说只要再有一个连接请求就会超限。后来查了一下发现是上位机软件在后台建立了一些额外的连接用于诊断和数据采集。这些连接平时不用但偶尔会激活一激活就把连接数占满了。解决办法是把上位机的诊断连接关掉只保留必要的数据采集连接。同时把两个HMI中的一个改成了开放式用户通信释放了一个S7连接资源。调整之后连接数降到了12个再也没有出现过通讯失败的情况。6.3 扫描周期尖峰导致的定位偏差还有一个案例比较有意思。一个S7-1500的项目控制一台伺服电机做定位。客户反映偶尔会出现定位偏差偏差不大但很频繁。我查了伺服参数、机械结构、编码器信号都没发现问题。后来在线监控扫描周期发现最大扫描周期偶尔会跳到20ms以上而正常情况只有2ms左右。每次扫描周期出现尖峰的时候定位就会出现偏差。进一步排查发现程序里有一个数据记录的功能每次触发时会把一批数据写入DB块然后再通过通信发送到上位机。这个操作在OB1里执行一次性占用了大量CPU时间。解决办法是把数据记录和通信发送的功能移到循环中断OB里设置200ms的周期。这样即使这个任务执行时间较长也不会影响主程序的扫描周期。调整之后扫描周期稳定在2-3ms定位偏差的问题也解决了。7. 日常维护中值得养成的几个习惯CPU资源管理不是一次性的工作而是贯穿项目全生命周期的。下面几个习惯是我做了这么多年项目之后觉得最有价值的分享给你。第一个习惯下载程序后必看存储器占用。每次下载完程序花30秒打开“在线与诊断”看一眼存储器占用率。如果发现某个指标超过70%就要警惕了。这个习惯能帮你提前发现很多问题而不是等到现场出故障了才去查。第二个习惯定期查看诊断缓冲区。诊断缓冲区里记录了CPU运行过程中的所有重要事件包括资源相关的报警。我一般会在每次现场巡检的时候把诊断缓冲区清空然后过一周再看。如果一周内出现了资源相关的报警就说明需要优化了。第三个习惯给程序留出足够的资源余量。不要等到资源用满了才去优化。我一般会在项目规划阶段就预留30%以上的资源余量用于后续的功能扩展和程序修改。这个余量看起来浪费但实际上能帮你省下很多麻烦。第四个习惯做好项目归档和版本管理。每次修改程序之前先归档一个版本。这样如果修改之后出现了资源问题可以快速回退到之前的版本。博途的“项目归档”功能可以把整个项目打包成一个ZIP文件非常方便。第五个习惯记录每次资源调整的原因和效果。我在项目文档里会专门留一页记录每次调整CPU资源设置的原因、调整前后的数值、以及调整后的效果。这样下次遇到类似问题的时候可以直接参考之前的经验不用从头排查。8. 关于CPU资源查看与设置的个人体会做了这么多年西门子PLC的项目我越来越觉得CPU资源管理这件事技术难度其实不高难的是“意识”。很多人不是不会看、不会设而是根本没想到要去看、要去设。等到出了问题才回过头来查这时候往往已经造成了停机或者数据丢失。我现在的做法是把CPU资源检查作为项目调试的标准流程之一。每次下载程序之后必看存储器占用和扫描周期每次现场巡检必看诊断缓冲区和通信连接数。这些动作花不了几分钟但能帮你避免很多大麻烦。另外不同型号的CPU在资源规格上差异很大不要用同一个标准去套所有项目。S7-1200的资源相对紧张需要精打细算S7-1500的资源充裕一些但也不能随意挥霍。了解你用的CPU的规格上限根据项目需求合理分配这才是最靠谱的做法。最后说一个我最近发现的细节博途的“在线与诊断”里有一个“资源”选项卡可以同时看到存储器、通信、扫描周期的汇总信息。这个界面比一个个选项卡去翻要方便得多建议你下次在线的时候找找看。