S7 通讯有没有标准的轮询程序？

二、实现方式（以西门子 S7-300/400 或 S7-1200/1500 等 PLC 为例）
1. 基于指令编程实现轮询（以 S7-1200 为例）
建立通信连接：首先在编程软件（如 TIA 博途）中配置好主站和各从站的通信参数，包括 IP 地址（如果是以太网通信）、站号等，确保主站与从站之间物理连接正常且网络设置正确，能够建立起通信链路。
使用通信指令：对于 S7-1200，常用的 S7 通信指令有 “PUT”（用于向从站写数据）和 “GET”（用于从从站读数据）指令等。
轮询逻辑编程：
可以通过定时器配合计数器或者状态字等方式来构建轮询逻辑。例如，使用一个定时器来设定每次轮询的时间间隔，每到时间间隔触发时，通过计数器来依次指向不同的从站。假设共有 5 个从站，计数器初始值为 1，每次定时器触发后，计数器加 1，当计数器达到 6（超出从站数量范围）时，再将其重置为 1，重新开始轮询。在每次指向一个从站时，使用 “GET” 指令读取该从站的数据（比如读取从站 PLC 中存储设备状态的某个数据区的数据）或者使用 “PUT” 指令向从站写入相应的数据（如写入控制指令到从站对应的操作数据区）。
以下是简单的伪代码示例来体现这种轮询逻辑：
// 定义定时器参数
TON_TIME := T#100ms;  // 设置轮询时间间隔为100毫秒
TON_ET := 0;          // 定时器当前值初始化为0
TON_Q := FALSE;       // 定时器输出初始为假
// 定义计数器参数
COUNTER := 1;         // 从站计数器初始值为1
MAX_COUNTER := 5;     // 最大从站数量为5
// 定时器启动条件等逻辑（此处简化示例）
IF NOT TON_Q THEN
    TON(IN := TRUE, PT := TON_TIME, ET := TON_ET, Q := TON_Q);
END IF;
// 轮询逻辑
IF TON_Q THEN
    CASE COUNTER OF
        WHEN 1 =>
            // 使用GET指令读取从站1的数据
            GET(REQ := TRUE, ID := 1, ADDR_1 := P#DB1.DBX0.0 BYTE 10, RD_1 := MW100);
            // 可进行其他针对从站1的操作或判断逻辑
            // ......
        WHEN 2 =>
            // 读取从站2的数据，类似上述操作
            GET(REQ := TRUE, ID := 2, ADDR_1 := P#DB1.DBX0.0 BYTE 10, RD_1 := MW120);
            // ......
        // 依次类推，针对其他从站
        WHEN 5 =>
            GET(REQ := TRUE, ID := 5, ADDR_1 := P#DB1.DBX0.0 BYTE 10, RD_1 := MW180);
            // ......
    END CASE;
    COUNTER := COUNTER + 1;
    IF COUNTER > MAX_COUNTER THEN
        COUNTER := 1;
    END IF;
    TON(IN := FALSE, PT := TON_TIME, ET := TON_ET, Q := TON_Q);
END IF;
这段伪代码只是一个简单示意，实际编程中要根据具体的项目需求、数据结构以及通信配置等进行详细准确的编写和完善。
2. 利用函数块或库实现轮询
西门子的一些编程软件中提供了专门用于 S7 通信轮询的函数块或通信库，例如在 TIA 博途软件中，可以使用相关的通信库（如 OB1 中的组织块配合一些通信功能块等）来更方便地实现轮询逻辑。
这些函数块通常已经内置了对通信连接判断、错误处理以及按照一定顺序依次访问从站等功能，编程人员只需按照要求配置好各从站的相关参数（如从站地址、要读写的数据区等），将函数块嵌入到主程序中合适的位置（比如在 OB1 等周期性执行的组织块中调用），就能实现 S7 通信轮询，相对自行编写指令逻辑来说，更加高效且代码结构更清晰，能减少编程出错的概率。
三、注意事项
通信超时处理：在轮询过程中，要设置合理的通信超时时间。因为有可能由于网络故障、从站设备故障等原因导致主站与某个从站通信时无法及时得到响应，如果没有超时处理机制，主站可能会一直等待，影响整个轮询的效率以及后续其他从站的数据交互。可以通过检测通信指令的完成状态以及设置超时定时器等方式，当超过规定时间未完成通信操作时，进行相应的错误处理，比如记录错误信息、尝试重新通信或者跳过当前从站继续轮询下一个从站等操作。
资源分配合理：要考虑主站的通信资源（如通信接口的带宽、PLC 的内存用于暂存通信数据等）是否能够满足轮询多个从站的需求。如果从站数量过多或者每个从站每次通信的数据量较大，可能会导致通信拥堵、数据丢失等问题。此时需要合理调整轮询周期、优化从站数据结构，减少不必要的数据交互，或者考虑采用更高速的通信接口、升级主站 PLC 的硬件配置等措施来解决资源紧张的问题。
从站状态监控：在轮询过程中，最好同时建立对从站状态的监控机制，例如通过读取从站反馈的特定状态信号（如设备故障信号、运行 / 停止状态信号等），及时了解从站是否正常工作。一旦发现从站出现异常，主站可以采取相应的措施，如发出报警信息、调整轮询策略（暂时跳过故障从站等），以保障整个系统的稳定运行。
这个周期没法给出,这和很多方面都有关系:
一、硬件相关因素
PLC 性能：
通信接口类型及速率：
二、软件及程序逻辑因素
程序复杂度：
轮询程序自身的复杂程度对轮询周期影响很大。如果在轮询过程中，除了简单的数据读写操作外，还包含大量的复杂数据处理、逻辑判断、运算等额外任务，例如每次读取从站数据后要进行复杂的滤波、换算以及与其他数据进行多重比较判断等操作，那么 PLC 执行这些额外任务所花费的时间就会增加，导致轮询周期变长。相反，如果只是单纯地进行基本的数据读写，不涉及过多复杂的程序逻辑，轮询周期就更容易缩短，更有可能实现较快的轮询速度，比如在较为简单的自动化监控项目中，仅读取一些设备的状态值（开关量、简单模拟量等）并写入少量控制指令，轮询周期可能达到几十毫秒以内。
优化程度：
三、系统整体及环境因素
网络负载与干扰：
实际的网络环境中，如果存在大量的数据流量、多个设备同时进行通信或者受到外界电磁干扰等情况，即使硬件和软件本身具备实现短轮询周期的能力，也可能受到影响。例如，在一个工业现场，有多台自动化设备通过同一个网络进行通信，网络带宽被大量占用，主站在进行 S7 轮询时，数据传输速度会变慢，轮询周期就会变长。同样，若现场存在电焊机、大型电机等强电磁干扰源，干扰了通信线路，导致数据传输出现错误需要重传等情况，也会增加轮询时间，很难实现快速的轮询周期。
从站响应速度：
从站设备本身的响应速度也是关键因素之一。如果从站的处理器性能较低、内部程序执行效率不高或者正处于繁忙的其他任务处理状态，当主站发起通信请求时，从站不能及时响应并返回数据，那么主站就需要等待更长时间，从而使得轮询周期延长。比如一些简单的小型从站 PLC 在处理复杂任务时，可能响应主站 S7 通信请求的时间较长，进而影响整个轮询的节奏，导致轮询周期无法达到很快的速度。
综合来看，在理想的实验室环境下，采用高性能的 PLC（如 S7-1500 高端型号）、以太网通信方式，配合简单高效的轮询程序以及无网络干扰、从站响应迅速等条件，S7 轮询周期最快有可能达到几毫秒；但在实际复杂的工业现场环境中，由于各种因素的综合影响，轮询周期往往会相对长一些，可能几十毫秒甚至更长时间，具体要根据实际的硬件、软件及环境等情况来综合确定。