TwinCAT任务周期记录：设定值、上次耗时和超时标志分开看

控制器日志里同时出现CycleTime和LastExecTime，能否把它们都标成“运行周期”？这样写会丢失关键区别：一项描述设置，另一项描述上一周期所需时间。再加上一个超时标志，三者分别回答不同问题，不能用同一个中文列名替代。

Beckhoff的TwinCAT3文档说明，PlcTaskSystemInfo中的CycleTime是设定任务周期，LastExecTime是上一周期所需时间，两项均以100纳秒为单位倍数。CycleTimeExceeded则表示是否超出设定任务周期，值在每个周期更新；前一周期在预定时间内完成时为0，否则为1。[1] 本文解释这些字段定义，不据单条日志判断现场故障原因。

日志标题先保留原字段名

团队可以同时写出原字段名、中文解释与单位。若展示层为了便于阅读换算了单位，应保存原始数值及换算说明，避免另一位人员把已经换算的数据再次换算。字段长得相似，不代表含义相同；导入其他分析工具时也应核对映射。

一次观察不等于整段历史

超时标志逐周期更新，所以某次读取为0，只能说明对应更新所表达的状态，不能自动证明过去从未发生过超时。采样记录应注明读取时间、间隔和记录方式。没有连续证据时，就不要在报告里写“全程没有超时”，更不能用最后一次状态覆盖此前异常记录。

任务身份同样不能省略

官方文档指出，CycleCount关联实际系统任务，而非只关联PLC项目中的任务引用，多个PLC项目或模块可能共享任务。[1] 因此，整理记录时可以保留任务名称、任务标识和相应项目版本，避免仅凭项目名将数据归到错误对象。本文不推断任何现场系统是否实际共享了任务。

把读数与原因分析分层

日志呈现的设定值、耗时或状态，是进一步分析的输入，并不能独自指出程序、调度、硬件或通信中的哪一项有问题。现场诊断还需要完整配置、版本和相关事件，由专业人员处理。本文不提供修改任务周期、优先级或运行模式的步骤，也不把字段状态当成设备安全保证。

一份可交接的周期记录，应能说明“哪个任务、哪个字段、什么单位、何时读取”。先把这四点记录完整，之后的性能讨论才能建立在同一组事实之上，而不是在不同含义的数值之间来回比较。

参考来源：[1] Beckhoff Automation，TwinCAT3 PLC — PlcTaskSystemInfo，字段定义及CycleCount说明；本次核对未见发布日期或具体现场build信息。