1. 为什么CPU资源查看这件事值得单独拿出来讲做西门子PLC项目的人尤其是用TIA博途做S7-1200/1500的几乎都遇到过类似场景程序下载进去跑起来设备动作偶尔卡顿扫描周期忽高忽低通讯间歇性丢包但打开程序监控又看不出明显逻辑问题。折腾半天最后发现是CPU的存储区快满了或者通讯负载率太高或者某个循环中断组织块占用了过多扫描时间。这些问题的共同点是——它们都不在梯形图或SCL代码的逻辑层面而是藏在CPU的运行资源里。TIA博途提供了一套相当完整的CPU资源查看与设置机制但很多刚入行的朋友要么不知道在哪看要么看到了也不清楚每个数值意味着什么、该调到多少合适。这篇内容就把CPU资源查看和设置这件事从头到尾拆开讲清楚包括在线诊断怎么看、存储区怎么分配、扫描周期怎么监控、通讯负载怎么设置以及实际调试中踩过的坑。适合阅读的人群正在用TIA博途做S7-1200/1500项目的电气工程师、自动化调试人员、PLC编程初学者以及需要排查PLC运行性能问题的现场技术人员。不需要你有多深的博途使用经验但至少要能完成基本的硬件组态和程序下载。提示本文所有操作基于TIA博途V16及以上版本S7-1200和S7-1500系列CPU。不同固件版本的界面可能略有差异但核心逻辑一致。2. CPU资源到底包含哪些东西2.1 存储区资源工作内存、装载内存、保持内存很多人第一次打开CPU属性里的存储区页面看到一堆数字是懵的。我先把这三个概念用大白话解释一遍。装载内存Load memory相当于你电脑的硬盘。你的项目程序、硬件组态、注释、符号表这些东西编译完之后全部存在装载内存里。它可以是CPU内置的也可以插一张SIMATIC存储卡来扩展。装载内存不够的典型表现是编译没问题但下载的时候报错说存储卡空间不足或者内部装载内存溢出。工作内存Work memory相当于电脑的内存条。CPU运行时真正参与执行的代码和数据放在工作内存里。工作内存又分为代码工作内存和数据工作内存。代码工作内存放的是编译后的机器指令数据工作内存放的是DB块、M区、定时器/计数器等运行数据。工作内存是CPU出厂就固定的不能扩展所以选型的时候就要算清楚。保持内存Retentive memory是专门用来掉电保持的那部分区域。M区、DB块、定时器、计数器都可以设置保持属性但保持的数据总量不能超过CPU规定的上限。这三个东西的关系可以这样理解装载内存是仓库工作内存是操作台保持内存是保险柜。仓库可以加货架存储卡操作台大小固定保险柜容量也固定。2.2 扫描周期与循环时间CPU的扫描周期是PLC最核心的运行指标之一。它指的是CPU完成一次“读取输入→执行程序→刷新输出”这个完整循环所花的时间。TIA博途里可以在CPU属性的“循环”页面设置最小循环时间和最大循环时间。最小循环时间的作用是当你的程序特别短扫描周期可能只有几百微秒但某些通讯或过程控制需要稳定的时间基准这时候可以设一个最小循环时间让CPU至少等这么久再进入下一轮扫描。最大循环时间则是监控用的如果实际扫描周期超过了这个值CPU会报错或者进入STOP。实际项目中我一般会把最大循环时间设为实际平均扫描周期的2到3倍作为预警阈值。比如实测平均扫描周期是3ms最大循环时间设8到10ms这样一旦程序里有某个条件导致扫描时间异常拉长能第一时间发现。2.3 通讯负载与连接资源S7-1200/1500的CPU同时要处理多种通讯任务PROFINET IO通讯、HMI连接、编程设备连接、Web服务器、OPC UA等等。每种通讯都会占用CPU的通讯资源。TIA博途在CPU属性的“通讯负载”页面可以设置通讯负载百分比默认是20%。这个参数的含义是CPU把最多20%的处理时间分配给通讯任务剩下80%留给循环程序和中断程序。如果你的项目里HMI刷新频率很高、PROFINET从站很多、还有OPC UA在上传数据20%可能不够用通讯会变慢甚至丢包。但如果你把这个值调得太高比如50%那循环程序的执行时间就会被压缩扫描周期变长。我的经验是一般项目保持默认20%就行。如果HMI画面刷新明显卡顿、或者上位机读数据经常超时可以试着调到30%到40%同时观察扫描周期的变化。超过50%就要慎重了除非你的程序逻辑本身很简单。2.4 中断组织块与资源占用S7-1200/1500支持多种中断组织块循环中断OB、硬件中断OB、时间错误OB、诊断错误OB等。每个中断OB都会在特定条件下打断主循环程序的执行。如果中断触发太频繁或者中断程序本身执行时间太长就会严重挤占主程序的执行时间。在CPU属性的“循环中断”页面可以设置各个循环中断OB的执行间隔。比如OB30设为100msOB31设为50msOB32设为200ms。这里有个容易忽略的点多个循环中断如果设置成相同的优先级它们会按顺序执行不会互相打断。但如果优先级不同高优先级的中断可以打断低优先级的中断。我见过一个项目工程师把OB30设成1ms的循环中断里面又写了不少浮点运算结果CPU有将近40%的时间都在跑这个中断主程序的扫描周期被拉得很长。后来把间隔改成10ms问题立刻解决。3. 在TIA博途中查看CPU资源的几种方式3.1 在线诊断最直接的资源查看入口把CPU连上之后在项目树里选中PLC右键选择“在线和诊断”或者直接点工具栏上的在线按钮。进入在线视图后左侧有一列诊断选项其中“诊断缓冲区”是最常用的但很多人忽略了下面还有“存储区”和“循环时间”这两个页面。诊断缓冲区记录的是CPU运行过程中发生的所有事件模式切换、错误、警告、模块插拔等等。看诊断缓冲区的时候重点关心里面的错误条目尤其是“区域长度错误”、“写访问错误”、“循环时间超出”这几类它们直接指向资源问题。存储区页面会显示当前工作内存和装载内存的使用情况包括已用字节数和剩余字节数。这个页面是实时的程序运行过程中也能看。我习惯在程序下载完之后先看一眼这里确认工作内存的余量。如果余量低于20%就要考虑优化程序结构或者换更大内存的CPU了。循环时间页面显示的是当前扫描周期、最小扫描周期、最大扫描周期和平均扫描周期。这个页面对于排查扫描周期异常非常有用。如果最大扫描周期远大于平均扫描周期说明程序中有偶发的耗时操作比如某个条件触发后执行了大量循环运算。3.2 程序监控与扫描周期测量除了在线诊断还可以在程序里直接测量扫描周期。S7-1200/1500提供了几个系统函数可以读取CPU的运行信息。比如用RD_SYS_T读取系统时间在OB1的开头和结尾各调一次相减就得到本次扫描的时间。不过这种方法会额外增加扫描负担一般只在调试阶段用。更优雅的方式是用OB1_PREV_CYCLE这个系统变量它直接返回上一次OB1的扫描周期单位是毫秒。你可以在OB1里把这个值传送到一个DB块里然后在HMI上显示出来实时监控扫描周期的变化趋势。// 在OB1中读取上一次扫描周期 ScanCycleDB.PrevCycle : OB1_PREV_CYCLE; ScanCycleDB.MinCycle : MIN(ScanCycleDB.MinCycle, OB1_PREV_CYCLE); ScanCycleDB.MaxCycle : MAX(ScanCycleDB.MaxCycle, OB1_PREV_CYCLE);这段代码把每次扫描的周期值记录下来同时维护最小值和最大值。HMI上可以做一个趋势图观察扫描周期是否稳定。如果发现最大值经常跳到平均值的几倍以上就要去查是哪个程序段或哪个中断导致的。3.3 Web服务器远程查看S7-1500的CPU内置了Web服务器功能在CPU属性的“Web服务器”页面启用之后用浏览器输入CPU的IP地址就能访问。Web服务器里有一个“诊断”页面可以看到CPU的存储区使用情况、扫描周期、通讯负载等关键指标。这个功能在现场调试时特别实用。比如你在控制柜前面用手机连上现场WiFi直接打开浏览器就能看CPU状态不用抱着电脑插网线。不过要注意Web服务器的刷新频率有限不能替代在线诊断的实时性适合做趋势观察而不是精确测量。注意启用Web服务器会占用额外的通讯资源如果项目本身通讯负载已经很高建议只在调试阶段启用正式运行后关闭。4. CPU资源相关参数的设置方法与计算逻辑4.1 存储区分配的实际计算方法选型阶段就要算清楚存储区需求不能等程序写完再发现不够。我一般按以下步骤估算第一步统计所有DB块的数据量。每个DB块的大小等于所有变量字节数之和再加上块头开销一般几十字节。把OB、FB、FC的代码量也估算进去代码工作内存大约是源文件编译后的机器码大小SCL和LAD编译后的差异不大。第二步估算M区、定时器、计数器的使用量。M区按实际使用的字节数算定时器和计数器每个占用一定的工作内存。第三步留出30%到50%的余量。因为程序在调试过程中会不断增加而且CPU固件本身也要占用一部分工作内存。举个例子一个中等规模的S7-1200项目有15个DB块平均每个200字节OB/FB/FC总共约50个块M区用了128字节定时器20个。那么数据工作内存大约需要15×20012820×16≈3500字节代码工作内存大约需要50×500≈25000字节。加起来约28.5KB。S7-1200 CPU 1214C的工作内存是100KB看起来够用但如果程序继续扩展就要留意了。4.2 循环时间设置的计算与调整最小循环时间的设置要看你的应用需求。如果项目里有PID控制PID的采样周期通常要求稳定这时候最小循环时间可以设为PID采样周期的整数分之一。比如PID采样周期是100ms最小循环时间可以设为10ms或20ms保证每个采样周期内至少执行了5到10次PID运算。最大循环时间的设置前面说过了设为平均扫描周期的2到3倍。但要注意如果项目里有循环中断OB最大循环时间的监控只针对主循环OB1不包括中断OB的执行时间。所以如果中断OB执行时间很长即使OB1的扫描周期正常CPU的整体负载也可能很高。4.3 通讯负载百分比的调整策略通讯负载百分比的调整需要配合实际测试。我的做法是先把通讯负载设为默认的20%然后让系统满负荷运行所有HMI连接、所有PROFINET从站、所有上位机通讯都打开观察在线诊断里的扫描周期和通讯状态。如果HMI刷新正常、上位机读写不超时、PROFINET没有丢站那就保持20%不动。如果出现通讯延迟先把通讯负载调到30%再观察。如果调到40%还不够那说明问题可能不在通讯负载比例上而是通讯任务本身设计有问题比如HMI刷新频率设得太高、上位机轮询周期太短。这里有个经验数据S7-1500的CPU在通讯负载20%的情况下典型扫描周期增加约0.5到1ms。调到40%时扫描周期可能增加2到3ms。这个代价是否值得取决于你的应用对扫描周期的敏感程度。4.4 中断OB的优先级与执行时间控制循环中断OB的优先级设置很关键。S7-1500的优先级范围是1到26数值越大优先级越高。默认情况下OB30的优先级是11OB31是12依次递增。这意味着OB31可以打断OB30。如果两个中断OB都需要精确的时间基准建议把它们设为相同的优先级这样它们会顺序执行不会互相干扰。如果某个中断OB的执行时间特别长可以把它设为较低的优先级让它被其他更紧急的中断打断。中断OB的执行时间要严格控制。一般来说单个中断OB的执行时间不应超过其触发间隔的20%。比如OB30的间隔是10ms那OB30里的程序执行时间最好控制在2ms以内。超过这个比例中断就会开始挤占主循环的时间导致扫描周期不稳定。5. 实操从零开始查看和调整CPU资源5.1 新建项目并组态CPU打开TIA博途新建项目添加一个新设备。以S7-1500 CPU 1511-1 PN为例在硬件目录里找到对应型号拖到网络视图里。然后在设备视图里双击CPU打开属性面板。属性面板里和资源相关的页面主要有这几个循环设置最小循环时间和最大循环时间通讯负载设置通讯负载百分比循环中断设置各循环中断OB的参数存储区查看工作内存和装载内存的分配情况Web服务器启用或禁用Web服务器系统和时钟存储器启用系统存储器和时钟存储器字节先把这些页面都过一遍了解每个参数的默认值。S7-1500的默认最小循环时间是0ms最大循环时间是150ms通讯负载是20%。这些默认值对大多数项目是合适的。5.2 编写测试程序并下载为了演示资源查看写一个简单的测试程序。在OB1里写一段循环累加的代码故意让它消耗一定的扫描时间。// OB1中的测试代码 FOR #i : 1 TO 1000 DO #temp : #temp #i * 0.001; END_FOR; TestDB.Result : #temp;这段代码执行1000次浮点乘加大概会消耗几百微秒的扫描时间。下载到CPU后打开在线诊断观察循环时间页面的数据。5.3 在线诊断查看实时资源下载完成后点击“在线”按钮然后打开“在线和诊断”。在诊断缓冲区里应该能看到CPU从STOP切换到RUN的记录。然后点开“循环时间”页面可以看到当前扫描周期、最小扫描周期、最大扫描周期和平均扫描周期。我实测的数据是空程序时平均扫描周期约0.3ms加上上面那段测试代码后平均扫描周期约1.2ms。这个增量就是测试代码的执行时间。再点开“存储区”页面可以看到工作内存的使用情况。S7-1500 CPU 1511-1 PN的工作内存是175KB代码加175KB数据装载内存是1MB。一个简单的测试程序占用的工作内存很少大概几KB。5.4 调整参数并观察效果现在把通讯负载从20%调到40%重新下载硬件组态。然后再次观察扫描周期。你会发现平均扫描周期可能增加了0.5到1ms。这就是通讯负载调整的代价。再把OB30的循环中断间隔从默认的100ms改成10ms在OB30里也放一段测试代码。下载后观察扫描周期你会发现扫描周期的波动明显变大因为OB30每10ms就打断一次主循环。这些实验可以帮助你建立对CPU资源参数的直观感受。实际项目中参数调整要基于实测数据不能凭感觉。5.5 用HMI或上位机做长期监控调试阶段用在线诊断看数据就够了但正式运行后不可能一直开着博途。这时候可以在HMI上做一个资源监控画面把扫描周期、存储区使用率、通讯状态这些关键指标显示出来。具体做法是在DB块里定义几个变量在OB1里用系统函数读取CPU资源数据然后在HMI上绑定这些变量。S7-1200/1500提供了RD_SYS_T、OB1_PREV_CYCLE等系统变量可以直接读取。// 在OB1中读取CPU资源信息 MonitorDB.ScanCycle : OB1_PREV_CYCLE; MonitorDB.MinScanCycle : MIN(MonitorDB.MinScanCycle, OB1_PREV_CYCLE); MonitorDB.MaxScanCycle : MAX(MonitorDB.MaxScanCycle, OB1_PREV_CYCLE);HMI上可以用趋势图显示扫描周期的变化用数值显示存储区的剩余量。这样操作员或维护人员可以随时了解CPU的运行状态提前发现潜在问题。6. 常见问题与排查技巧实录6.1 扫描周期突然变大的排查思路扫描周期突然变大是最常见的资源问题。排查思路如下首先打开在线诊断的循环时间页面看最大扫描周期是多少。如果最大扫描周期是平均扫描周期的5倍以上说明有偶发的耗时操作。然后检查所有中断OB。把每个中断OB的执行时间单独测量一下。方法是在中断OB的开头和结尾各读一次系统时间相减得到执行时间。如果某个中断OB的执行时间接近或超过其触发间隔那就是它的问题。接着检查程序里有没有大循环。FOR循环、WHILE循环如果循环次数太多或者循环体里有复杂的浮点运算、字符串操作都会导致扫描时间骤增。我见过一个项目工程师在OB1里用FOR循环遍历一个1000个元素的数组做排序每次扫描都执行一遍扫描周期直接飙到50ms。最后检查通讯任务。如果PROFINET从站很多或者有大量的HMI连接通讯负载会占用CPU时间。可以试着临时禁用部分通讯任务观察扫描周期是否改善。6.2 存储区不足的典型表现与处理存储区不足的表现分几种情况装载内存不足编译时报错提示“装载内存不足”或“存储卡空间不足”。处理方法是优化程序删除不必要的注释和符号信息或者换更大的存储卡。工作内存不足下载时报错提示“工作内存不足”。处理方法是精简DB块把不常用的数据移到装载内存通过“仅存储在装载内存中”属性或者换更大工作内存的CPU。保持内存不足下载时报错提示“保持内存不足”。处理方法是减少保持变量的数量或者把部分保持数据改为非保持通过程序在启动时初始化。注意S7-1200的保持内存是固定分配的不能像S7-1500那样灵活设置。S7-1200的M区保持范围、DB块保持属性都有总量限制选型时要特别注意。6.3 通讯负载过高导致的问题通讯负载过高的典型表现是HMI画面刷新慢、上位机读数据超时、PROFINET从站偶尔掉站。但在线诊断里看扫描周期可能正常因为通讯任务是在循环程序的间隙执行的。排查方法是在在线诊断的通讯页面查看通讯负载的实际情况。如果实际通讯负载接近或超过设定的百分比说明通讯任务太多需要优化。优化方向包括降低HMI刷新频率、减少上位机轮询频率、合并PROFINET从站、关闭不必要的通讯服务如Web服务器、OPC UA。如果这些都不够再考虑提高通讯负载百分比。6.4 中断OB冲突与优先级问题中断OB冲突的表现是程序逻辑偶尔出错或者某些中断OB的执行次数不对。这通常是因为多个中断OB的优先级设置不当导致高优先级中断频繁打断低优先级中断。排查方法是在在线诊断里查看各中断OB的执行次数和执行时间。如果某个中断OB的执行次数远大于预期说明它被频繁触发。如果某个中断OB的执行时间远大于预期说明它被其他中断打断了。处理方法是调整中断OB的优先级让关键中断有更高的优先级非关键中断设为相同优先级顺序执行。同时检查中断触发条件避免不必要的触发。6.5 常见问题速查表问题现象可能原因排查方法处理措施扫描周期波动大中断OB执行时间过长在线诊断查看循环时间优化中断程序或增大触发间隔下载时报存储不足工作内存或装载内存不够在线诊断查看存储区精简程序或换更大内存CPUHMI刷新卡顿通讯负载过高在线诊断查看通讯负载降低刷新频率或提高通讯负载百分比CPU频繁报错最大循环时间设置过小查看诊断缓冲区增大最大循环时间保持数据丢失保持内存不足查看存储区保持内存使用减少保持变量或改用启动初始化中断OB不执行优先级设置错误查看中断OB执行次数调整优先级或检查触发条件7. 几个容易被忽略的细节和我的实操心得7.1 系统存储器和时钟存储器字节的妙用在CPU属性的“系统和时钟存储器”页面可以启用系统存储器字节和时钟存储器字节。系统存储器字节的第一个位是“首次扫描”标志可以用来初始化变量。时钟存储器字节提供不同频率的方波信号可以用来做闪烁报警或定时触发。这两个字节虽然不直接属于“资源查看”范畴但它们能帮你减少程序中的定时器和计数器使用量间接节省工作内存。我习惯在每个项目里都启用这两个字节用时钟存储器字节的1Hz信号做闪烁用0.5Hz信号做慢闪省去了自己写闪烁程序。7.2 优化DB块访问方式降低扫描负担S7-1200/1500的DB块有两种访问方式优化访问和标准访问。优化访问的DB块在CPU内部按变量名索引访问速度更快而且支持符号寻址。标准访问的DB块按绝对地址访问兼容S7-300/400的程序。在DB块属性里可以设置访问方式。对于新项目建议全部使用优化访问。优化访问的DB块不仅访问速度快而且不会因为变量顺序调整而导致地址错乱。只有在需要与老程序兼容或者需要绝对地址访问时才用标准访问。7.3 用轨迹功能记录资源变化趋势TIA博途的轨迹功能Trace可以记录变量随时间的变化曲线。你可以把扫描周期、存储区使用量这些变量添加到轨迹里让CPU运行一段时间后把轨迹数据上传上来分析。轨迹功能对于排查偶发的资源问题特别有用。比如扫描周期偶尔跳变但在线诊断只能看到最大值看不到跳变的时刻和规律。用轨迹功能可以精确记录跳变发生的时间点和前后的变量状态帮助定位问题。7.4 固件版本对资源参数的影响不同固件版本的CPU资源参数的默认值和可设置范围可能不同。比如S7-1500早期固件版本的通讯负载默认是20%后期版本可能调整了默认值或增加了新的通讯服务选项。在项目开始前建议先确认CPU的固件版本然后查阅对应的技术手册了解该版本支持的所有资源参数。如果项目中途升级了固件要重新检查资源参数是否需要调整。7.5 实际项目中我的参数配置习惯经过多个项目的积累我形成了自己的一套参数配置习惯最小循环时间一般不设保持0ms。除非有PID控制或需要稳定时间基准的场景才设为采样周期的1/5到1/10。最大循环时间设为实测平均扫描周期的3倍。比如平均扫描周期2ms最大循环时间设6ms。这样既能及时发现异常又不会因为偶尔的波动误报。通讯负载默认20%。如果项目有多个HMI和上位机调到30%。超过40%的情况很少见除非是专门的数据采集项目。循环中断OB30设100msOB31设50msOB32设200ms。优先级按默认递增。中断程序执行时间控制在触发间隔的20%以内。这些参数不是固定的每个项目都要根据实际情况调整。但有了这套基准调整的时候心里有底不会盲目乱改。7.6 资源查看的时机选择什么时候该查看CPU资源我的建议是程序下载后第一次运行时查看存储区使用情况确认余量充足。系统联调时查看扫描周期和通讯负载确认在正常范围内。正式运行后定期比如每周查看一次诊断缓冲区看有没有资源相关的警告。每次修改程序后重新查看存储区和扫描周期确认修改没有导致资源超限。这些时机看起来简单但实际项目中很多人只在出问题的时候才去看结果小问题拖成大问题。养成定期查看的习惯能避免很多现场故障。8. 从资源查看延伸到程序优化CPU资源查看的最终目的不是看数据而是通过数据发现问题并优化程序。当你发现工作内存余量不足时自然会去精简DB块、删除无用变量。当你发现扫描周期过长时自然会去优化循环结构、减少浮点运算。当你发现通讯负载过高时自然会去调整HMI刷新频率、合并通讯任务。我在一个实际项目里遇到过这样的情况S7-1200 CPU 1215C的工作内存是125KB程序下载后余量只剩15%。在线诊断一看发现有一个DB块占了将近40KB里面存的全是历史报警记录而且用了标准访问方式。后来把这个DB块改成优化访问并且把历史记录改为循环覆盖模式只保留最近100条DB块大小降到8KB工作内存余量恢复到40%以上。另一个项目里扫描周期平均8ms最大扫描周期偶尔跳到25ms。用轨迹功能记录后发现每次跳变都发生在某个HMI画面切换的时候。原因是那个画面绑定了大量变量画面切换时CPU要一次性刷新所有变量导致扫描周期骤增。后来把画面变量分组刷新问题解决。这些经验说明CPU资源查看不是孤立的操作而是程序优化的起点。看懂数据背后的含义才能做出正确的优化决策。提示如果你在项目中遇到CPU资源相关的问题建议先在线诊断看数据再用轨迹功能记录趋势最后结合程序逻辑分析原因。不要一上来就改参数那样可能掩盖真正的问题。 TIA博途S7-1200/1500 CPU资源查看与设置详解
1. 为什么CPU资源查看这件事值得单独拿出来讲做西门子PLC项目的人尤其是用TIA博途做S7-1200/1500的几乎都遇到过类似场景程序下载进去跑起来设备动作偶尔卡顿扫描周期忽高忽低通讯间歇性丢包但打开程序监控又看不出明显逻辑问题。折腾半天最后发现是CPU的存储区快满了或者通讯负载率太高或者某个循环中断组织块占用了过多扫描时间。这些问题的共同点是——它们都不在梯形图或SCL代码的逻辑层面而是藏在CPU的运行资源里。TIA博途提供了一套相当完整的CPU资源查看与设置机制但很多刚入行的朋友要么不知道在哪看要么看到了也不清楚每个数值意味着什么、该调到多少合适。这篇内容就把CPU资源查看和设置这件事从头到尾拆开讲清楚包括在线诊断怎么看、存储区怎么分配、扫描周期怎么监控、通讯负载怎么设置以及实际调试中踩过的坑。适合阅读的人群正在用TIA博途做S7-1200/1500项目的电气工程师、自动化调试人员、PLC编程初学者以及需要排查PLC运行性能问题的现场技术人员。不需要你有多深的博途使用经验但至少要能完成基本的硬件组态和程序下载。提示本文所有操作基于TIA博途V16及以上版本S7-1200和S7-1500系列CPU。不同固件版本的界面可能略有差异但核心逻辑一致。2. CPU资源到底包含哪些东西2.1 存储区资源工作内存、装载内存、保持内存很多人第一次打开CPU属性里的存储区页面看到一堆数字是懵的。我先把这三个概念用大白话解释一遍。装载内存Load memory相当于你电脑的硬盘。你的项目程序、硬件组态、注释、符号表这些东西编译完之后全部存在装载内存里。它可以是CPU内置的也可以插一张SIMATIC存储卡来扩展。装载内存不够的典型表现是编译没问题但下载的时候报错说存储卡空间不足或者内部装载内存溢出。工作内存Work memory相当于电脑的内存条。CPU运行时真正参与执行的代码和数据放在工作内存里。工作内存又分为代码工作内存和数据工作内存。代码工作内存放的是编译后的机器指令数据工作内存放的是DB块、M区、定时器/计数器等运行数据。工作内存是CPU出厂就固定的不能扩展所以选型的时候就要算清楚。保持内存Retentive memory是专门用来掉电保持的那部分区域。M区、DB块、定时器、计数器都可以设置保持属性但保持的数据总量不能超过CPU规定的上限。这三个东西的关系可以这样理解装载内存是仓库工作内存是操作台保持内存是保险柜。仓库可以加货架存储卡操作台大小固定保险柜容量也固定。2.2 扫描周期与循环时间CPU的扫描周期是PLC最核心的运行指标之一。它指的是CPU完成一次“读取输入→执行程序→刷新输出”这个完整循环所花的时间。TIA博途里可以在CPU属性的“循环”页面设置最小循环时间和最大循环时间。最小循环时间的作用是当你的程序特别短扫描周期可能只有几百微秒但某些通讯或过程控制需要稳定的时间基准这时候可以设一个最小循环时间让CPU至少等这么久再进入下一轮扫描。最大循环时间则是监控用的如果实际扫描周期超过了这个值CPU会报错或者进入STOP。实际项目中我一般会把最大循环时间设为实际平均扫描周期的2到3倍作为预警阈值。比如实测平均扫描周期是3ms最大循环时间设8到10ms这样一旦程序里有某个条件导致扫描时间异常拉长能第一时间发现。2.3 通讯负载与连接资源S7-1200/1500的CPU同时要处理多种通讯任务PROFINET IO通讯、HMI连接、编程设备连接、Web服务器、OPC UA等等。每种通讯都会占用CPU的通讯资源。TIA博途在CPU属性的“通讯负载”页面可以设置通讯负载百分比默认是20%。这个参数的含义是CPU把最多20%的处理时间分配给通讯任务剩下80%留给循环程序和中断程序。如果你的项目里HMI刷新频率很高、PROFINET从站很多、还有OPC UA在上传数据20%可能不够用通讯会变慢甚至丢包。但如果你把这个值调得太高比如50%那循环程序的执行时间就会被压缩扫描周期变长。我的经验是一般项目保持默认20%就行。如果HMI画面刷新明显卡顿、或者上位机读数据经常超时可以试着调到30%到40%同时观察扫描周期的变化。超过50%就要慎重了除非你的程序逻辑本身很简单。2.4 中断组织块与资源占用S7-1200/1500支持多种中断组织块循环中断OB、硬件中断OB、时间错误OB、诊断错误OB等。每个中断OB都会在特定条件下打断主循环程序的执行。如果中断触发太频繁或者中断程序本身执行时间太长就会严重挤占主程序的执行时间。在CPU属性的“循环中断”页面可以设置各个循环中断OB的执行间隔。比如OB30设为100msOB31设为50msOB32设为200ms。这里有个容易忽略的点多个循环中断如果设置成相同的优先级它们会按顺序执行不会互相打断。但如果优先级不同高优先级的中断可以打断低优先级的中断。我见过一个项目工程师把OB30设成1ms的循环中断里面又写了不少浮点运算结果CPU有将近40%的时间都在跑这个中断主程序的扫描周期被拉得很长。后来把间隔改成10ms问题立刻解决。3. 在TIA博途中查看CPU资源的几种方式3.1 在线诊断最直接的资源查看入口把CPU连上之后在项目树里选中PLC右键选择“在线和诊断”或者直接点工具栏上的在线按钮。进入在线视图后左侧有一列诊断选项其中“诊断缓冲区”是最常用的但很多人忽略了下面还有“存储区”和“循环时间”这两个页面。诊断缓冲区记录的是CPU运行过程中发生的所有事件模式切换、错误、警告、模块插拔等等。看诊断缓冲区的时候重点关心里面的错误条目尤其是“区域长度错误”、“写访问错误”、“循环时间超出”这几类它们直接指向资源问题。存储区页面会显示当前工作内存和装载内存的使用情况包括已用字节数和剩余字节数。这个页面是实时的程序运行过程中也能看。我习惯在程序下载完之后先看一眼这里确认工作内存的余量。如果余量低于20%就要考虑优化程序结构或者换更大内存的CPU了。循环时间页面显示的是当前扫描周期、最小扫描周期、最大扫描周期和平均扫描周期。这个页面对于排查扫描周期异常非常有用。如果最大扫描周期远大于平均扫描周期说明程序中有偶发的耗时操作比如某个条件触发后执行了大量循环运算。3.2 程序监控与扫描周期测量除了在线诊断还可以在程序里直接测量扫描周期。S7-1200/1500提供了几个系统函数可以读取CPU的运行信息。比如用RD_SYS_T读取系统时间在OB1的开头和结尾各调一次相减就得到本次扫描的时间。不过这种方法会额外增加扫描负担一般只在调试阶段用。更优雅的方式是用OB1_PREV_CYCLE这个系统变量它直接返回上一次OB1的扫描周期单位是毫秒。你可以在OB1里把这个值传送到一个DB块里然后在HMI上显示出来实时监控扫描周期的变化趋势。// 在OB1中读取上一次扫描周期 ScanCycleDB.PrevCycle : OB1_PREV_CYCLE; ScanCycleDB.MinCycle : MIN(ScanCycleDB.MinCycle, OB1_PREV_CYCLE); ScanCycleDB.MaxCycle : MAX(ScanCycleDB.MaxCycle, OB1_PREV_CYCLE);这段代码把每次扫描的周期值记录下来同时维护最小值和最大值。HMI上可以做一个趋势图观察扫描周期是否稳定。如果发现最大值经常跳到平均值的几倍以上就要去查是哪个程序段或哪个中断导致的。3.3 Web服务器远程查看S7-1500的CPU内置了Web服务器功能在CPU属性的“Web服务器”页面启用之后用浏览器输入CPU的IP地址就能访问。Web服务器里有一个“诊断”页面可以看到CPU的存储区使用情况、扫描周期、通讯负载等关键指标。这个功能在现场调试时特别实用。比如你在控制柜前面用手机连上现场WiFi直接打开浏览器就能看CPU状态不用抱着电脑插网线。不过要注意Web服务器的刷新频率有限不能替代在线诊断的实时性适合做趋势观察而不是精确测量。注意启用Web服务器会占用额外的通讯资源如果项目本身通讯负载已经很高建议只在调试阶段启用正式运行后关闭。4. CPU资源相关参数的设置方法与计算逻辑4.1 存储区分配的实际计算方法选型阶段就要算清楚存储区需求不能等程序写完再发现不够。我一般按以下步骤估算第一步统计所有DB块的数据量。每个DB块的大小等于所有变量字节数之和再加上块头开销一般几十字节。把OB、FB、FC的代码量也估算进去代码工作内存大约是源文件编译后的机器码大小SCL和LAD编译后的差异不大。第二步估算M区、定时器、计数器的使用量。M区按实际使用的字节数算定时器和计数器每个占用一定的工作内存。第三步留出30%到50%的余量。因为程序在调试过程中会不断增加而且CPU固件本身也要占用一部分工作内存。举个例子一个中等规模的S7-1200项目有15个DB块平均每个200字节OB/FB/FC总共约50个块M区用了128字节定时器20个。那么数据工作内存大约需要15×20012820×16≈3500字节代码工作内存大约需要50×500≈25000字节。加起来约28.5KB。S7-1200 CPU 1214C的工作内存是100KB看起来够用但如果程序继续扩展就要留意了。4.2 循环时间设置的计算与调整最小循环时间的设置要看你的应用需求。如果项目里有PID控制PID的采样周期通常要求稳定这时候最小循环时间可以设为PID采样周期的整数分之一。比如PID采样周期是100ms最小循环时间可以设为10ms或20ms保证每个采样周期内至少执行了5到10次PID运算。最大循环时间的设置前面说过了设为平均扫描周期的2到3倍。但要注意如果项目里有循环中断OB最大循环时间的监控只针对主循环OB1不包括中断OB的执行时间。所以如果中断OB执行时间很长即使OB1的扫描周期正常CPU的整体负载也可能很高。4.3 通讯负载百分比的调整策略通讯负载百分比的调整需要配合实际测试。我的做法是先把通讯负载设为默认的20%然后让系统满负荷运行所有HMI连接、所有PROFINET从站、所有上位机通讯都打开观察在线诊断里的扫描周期和通讯状态。如果HMI刷新正常、上位机读写不超时、PROFINET没有丢站那就保持20%不动。如果出现通讯延迟先把通讯负载调到30%再观察。如果调到40%还不够那说明问题可能不在通讯负载比例上而是通讯任务本身设计有问题比如HMI刷新频率设得太高、上位机轮询周期太短。这里有个经验数据S7-1500的CPU在通讯负载20%的情况下典型扫描周期增加约0.5到1ms。调到40%时扫描周期可能增加2到3ms。这个代价是否值得取决于你的应用对扫描周期的敏感程度。4.4 中断OB的优先级与执行时间控制循环中断OB的优先级设置很关键。S7-1500的优先级范围是1到26数值越大优先级越高。默认情况下OB30的优先级是11OB31是12依次递增。这意味着OB31可以打断OB30。如果两个中断OB都需要精确的时间基准建议把它们设为相同的优先级这样它们会顺序执行不会互相干扰。如果某个中断OB的执行时间特别长可以把它设为较低的优先级让它被其他更紧急的中断打断。中断OB的执行时间要严格控制。一般来说单个中断OB的执行时间不应超过其触发间隔的20%。比如OB30的间隔是10ms那OB30里的程序执行时间最好控制在2ms以内。超过这个比例中断就会开始挤占主循环的时间导致扫描周期不稳定。5. 实操从零开始查看和调整CPU资源5.1 新建项目并组态CPU打开TIA博途新建项目添加一个新设备。以S7-1500 CPU 1511-1 PN为例在硬件目录里找到对应型号拖到网络视图里。然后在设备视图里双击CPU打开属性面板。属性面板里和资源相关的页面主要有这几个循环设置最小循环时间和最大循环时间通讯负载设置通讯负载百分比循环中断设置各循环中断OB的参数存储区查看工作内存和装载内存的分配情况Web服务器启用或禁用Web服务器系统和时钟存储器启用系统存储器和时钟存储器字节先把这些页面都过一遍了解每个参数的默认值。S7-1500的默认最小循环时间是0ms最大循环时间是150ms通讯负载是20%。这些默认值对大多数项目是合适的。5.2 编写测试程序并下载为了演示资源查看写一个简单的测试程序。在OB1里写一段循环累加的代码故意让它消耗一定的扫描时间。// OB1中的测试代码 FOR #i : 1 TO 1000 DO #temp : #temp #i * 0.001; END_FOR; TestDB.Result : #temp;这段代码执行1000次浮点乘加大概会消耗几百微秒的扫描时间。下载到CPU后打开在线诊断观察循环时间页面的数据。5.3 在线诊断查看实时资源下载完成后点击“在线”按钮然后打开“在线和诊断”。在诊断缓冲区里应该能看到CPU从STOP切换到RUN的记录。然后点开“循环时间”页面可以看到当前扫描周期、最小扫描周期、最大扫描周期和平均扫描周期。我实测的数据是空程序时平均扫描周期约0.3ms加上上面那段测试代码后平均扫描周期约1.2ms。这个增量就是测试代码的执行时间。再点开“存储区”页面可以看到工作内存的使用情况。S7-1500 CPU 1511-1 PN的工作内存是175KB代码加175KB数据装载内存是1MB。一个简单的测试程序占用的工作内存很少大概几KB。5.4 调整参数并观察效果现在把通讯负载从20%调到40%重新下载硬件组态。然后再次观察扫描周期。你会发现平均扫描周期可能增加了0.5到1ms。这就是通讯负载调整的代价。再把OB30的循环中断间隔从默认的100ms改成10ms在OB30里也放一段测试代码。下载后观察扫描周期你会发现扫描周期的波动明显变大因为OB30每10ms就打断一次主循环。这些实验可以帮助你建立对CPU资源参数的直观感受。实际项目中参数调整要基于实测数据不能凭感觉。5.5 用HMI或上位机做长期监控调试阶段用在线诊断看数据就够了但正式运行后不可能一直开着博途。这时候可以在HMI上做一个资源监控画面把扫描周期、存储区使用率、通讯状态这些关键指标显示出来。具体做法是在DB块里定义几个变量在OB1里用系统函数读取CPU资源数据然后在HMI上绑定这些变量。S7-1200/1500提供了RD_SYS_T、OB1_PREV_CYCLE等系统变量可以直接读取。// 在OB1中读取CPU资源信息 MonitorDB.ScanCycle : OB1_PREV_CYCLE; MonitorDB.MinScanCycle : MIN(MonitorDB.MinScanCycle, OB1_PREV_CYCLE); MonitorDB.MaxScanCycle : MAX(MonitorDB.MaxScanCycle, OB1_PREV_CYCLE);HMI上可以用趋势图显示扫描周期的变化用数值显示存储区的剩余量。这样操作员或维护人员可以随时了解CPU的运行状态提前发现潜在问题。6. 常见问题与排查技巧实录6.1 扫描周期突然变大的排查思路扫描周期突然变大是最常见的资源问题。排查思路如下首先打开在线诊断的循环时间页面看最大扫描周期是多少。如果最大扫描周期是平均扫描周期的5倍以上说明有偶发的耗时操作。然后检查所有中断OB。把每个中断OB的执行时间单独测量一下。方法是在中断OB的开头和结尾各读一次系统时间相减得到执行时间。如果某个中断OB的执行时间接近或超过其触发间隔那就是它的问题。接着检查程序里有没有大循环。FOR循环、WHILE循环如果循环次数太多或者循环体里有复杂的浮点运算、字符串操作都会导致扫描时间骤增。我见过一个项目工程师在OB1里用FOR循环遍历一个1000个元素的数组做排序每次扫描都执行一遍扫描周期直接飙到50ms。最后检查通讯任务。如果PROFINET从站很多或者有大量的HMI连接通讯负载会占用CPU时间。可以试着临时禁用部分通讯任务观察扫描周期是否改善。6.2 存储区不足的典型表现与处理存储区不足的表现分几种情况装载内存不足编译时报错提示“装载内存不足”或“存储卡空间不足”。处理方法是优化程序删除不必要的注释和符号信息或者换更大的存储卡。工作内存不足下载时报错提示“工作内存不足”。处理方法是精简DB块把不常用的数据移到装载内存通过“仅存储在装载内存中”属性或者换更大工作内存的CPU。保持内存不足下载时报错提示“保持内存不足”。处理方法是减少保持变量的数量或者把部分保持数据改为非保持通过程序在启动时初始化。注意S7-1200的保持内存是固定分配的不能像S7-1500那样灵活设置。S7-1200的M区保持范围、DB块保持属性都有总量限制选型时要特别注意。6.3 通讯负载过高导致的问题通讯负载过高的典型表现是HMI画面刷新慢、上位机读数据超时、PROFINET从站偶尔掉站。但在线诊断里看扫描周期可能正常因为通讯任务是在循环程序的间隙执行的。排查方法是在在线诊断的通讯页面查看通讯负载的实际情况。如果实际通讯负载接近或超过设定的百分比说明通讯任务太多需要优化。优化方向包括降低HMI刷新频率、减少上位机轮询频率、合并PROFINET从站、关闭不必要的通讯服务如Web服务器、OPC UA。如果这些都不够再考虑提高通讯负载百分比。6.4 中断OB冲突与优先级问题中断OB冲突的表现是程序逻辑偶尔出错或者某些中断OB的执行次数不对。这通常是因为多个中断OB的优先级设置不当导致高优先级中断频繁打断低优先级中断。排查方法是在在线诊断里查看各中断OB的执行次数和执行时间。如果某个中断OB的执行次数远大于预期说明它被频繁触发。如果某个中断OB的执行时间远大于预期说明它被其他中断打断了。处理方法是调整中断OB的优先级让关键中断有更高的优先级非关键中断设为相同优先级顺序执行。同时检查中断触发条件避免不必要的触发。6.5 常见问题速查表问题现象可能原因排查方法处理措施扫描周期波动大中断OB执行时间过长在线诊断查看循环时间优化中断程序或增大触发间隔下载时报存储不足工作内存或装载内存不够在线诊断查看存储区精简程序或换更大内存CPUHMI刷新卡顿通讯负载过高在线诊断查看通讯负载降低刷新频率或提高通讯负载百分比CPU频繁报错最大循环时间设置过小查看诊断缓冲区增大最大循环时间保持数据丢失保持内存不足查看存储区保持内存使用减少保持变量或改用启动初始化中断OB不执行优先级设置错误查看中断OB执行次数调整优先级或检查触发条件7. 几个容易被忽略的细节和我的实操心得7.1 系统存储器和时钟存储器字节的妙用在CPU属性的“系统和时钟存储器”页面可以启用系统存储器字节和时钟存储器字节。系统存储器字节的第一个位是“首次扫描”标志可以用来初始化变量。时钟存储器字节提供不同频率的方波信号可以用来做闪烁报警或定时触发。这两个字节虽然不直接属于“资源查看”范畴但它们能帮你减少程序中的定时器和计数器使用量间接节省工作内存。我习惯在每个项目里都启用这两个字节用时钟存储器字节的1Hz信号做闪烁用0.5Hz信号做慢闪省去了自己写闪烁程序。7.2 优化DB块访问方式降低扫描负担S7-1200/1500的DB块有两种访问方式优化访问和标准访问。优化访问的DB块在CPU内部按变量名索引访问速度更快而且支持符号寻址。标准访问的DB块按绝对地址访问兼容S7-300/400的程序。在DB块属性里可以设置访问方式。对于新项目建议全部使用优化访问。优化访问的DB块不仅访问速度快而且不会因为变量顺序调整而导致地址错乱。只有在需要与老程序兼容或者需要绝对地址访问时才用标准访问。7.3 用轨迹功能记录资源变化趋势TIA博途的轨迹功能Trace可以记录变量随时间的变化曲线。你可以把扫描周期、存储区使用量这些变量添加到轨迹里让CPU运行一段时间后把轨迹数据上传上来分析。轨迹功能对于排查偶发的资源问题特别有用。比如扫描周期偶尔跳变但在线诊断只能看到最大值看不到跳变的时刻和规律。用轨迹功能可以精确记录跳变发生的时间点和前后的变量状态帮助定位问题。7.4 固件版本对资源参数的影响不同固件版本的CPU资源参数的默认值和可设置范围可能不同。比如S7-1500早期固件版本的通讯负载默认是20%后期版本可能调整了默认值或增加了新的通讯服务选项。在项目开始前建议先确认CPU的固件版本然后查阅对应的技术手册了解该版本支持的所有资源参数。如果项目中途升级了固件要重新检查资源参数是否需要调整。7.5 实际项目中我的参数配置习惯经过多个项目的积累我形成了自己的一套参数配置习惯最小循环时间一般不设保持0ms。除非有PID控制或需要稳定时间基准的场景才设为采样周期的1/5到1/10。最大循环时间设为实测平均扫描周期的3倍。比如平均扫描周期2ms最大循环时间设6ms。这样既能及时发现异常又不会因为偶尔的波动误报。通讯负载默认20%。如果项目有多个HMI和上位机调到30%。超过40%的情况很少见除非是专门的数据采集项目。循环中断OB30设100msOB31设50msOB32设200ms。优先级按默认递增。中断程序执行时间控制在触发间隔的20%以内。这些参数不是固定的每个项目都要根据实际情况调整。但有了这套基准调整的时候心里有底不会盲目乱改。7.6 资源查看的时机选择什么时候该查看CPU资源我的建议是程序下载后第一次运行时查看存储区使用情况确认余量充足。系统联调时查看扫描周期和通讯负载确认在正常范围内。正式运行后定期比如每周查看一次诊断缓冲区看有没有资源相关的警告。每次修改程序后重新查看存储区和扫描周期确认修改没有导致资源超限。这些时机看起来简单但实际项目中很多人只在出问题的时候才去看结果小问题拖成大问题。养成定期查看的习惯能避免很多现场故障。8. 从资源查看延伸到程序优化CPU资源查看的最终目的不是看数据而是通过数据发现问题并优化程序。当你发现工作内存余量不足时自然会去精简DB块、删除无用变量。当你发现扫描周期过长时自然会去优化循环结构、减少浮点运算。当你发现通讯负载过高时自然会去调整HMI刷新频率、合并通讯任务。我在一个实际项目里遇到过这样的情况S7-1200 CPU 1215C的工作内存是125KB程序下载后余量只剩15%。在线诊断一看发现有一个DB块占了将近40KB里面存的全是历史报警记录而且用了标准访问方式。后来把这个DB块改成优化访问并且把历史记录改为循环覆盖模式只保留最近100条DB块大小降到8KB工作内存余量恢复到40%以上。另一个项目里扫描周期平均8ms最大扫描周期偶尔跳到25ms。用轨迹功能记录后发现每次跳变都发生在某个HMI画面切换的时候。原因是那个画面绑定了大量变量画面切换时CPU要一次性刷新所有变量导致扫描周期骤增。后来把画面变量分组刷新问题解决。这些经验说明CPU资源查看不是孤立的操作而是程序优化的起点。看懂数据背后的含义才能做出正确的优化决策。提示如果你在项目中遇到CPU资源相关的问题建议先在线诊断看数据再用轨迹功能记录趋势最后结合程序逻辑分析原因。不要一上来就改参数那样可能掩盖真正的问题。