查看驅動的故障記錄，發現每臺驅動的歷史紀錄中有許多 代碼8501 （設定值超時）；按說應該停機，但沒有發現停機現象。
而且也存在 報警信息 8526 PROFINET 沒有循環連接。

對于報警 A8526 估計是系統上電或拉閘過程中遺留的報警。
對于 故障8501 （設定值超時）理應是在 驅動ON 之后出現的，但仔細看看故障出現時間和故障清除時間是同一時間。設備也能正常啟動，真奇怪。

由此關注了 PEOFINET下的IO刷新時間

看資料，系統的刷新時間，應該由以下幾個時間決定。
T1 IO設備本體的刷新時間（這里是G120-2的CU 240E-2PN）
T2 IO設備PN接口的刷新時間
T3 PN網絡的刷新時間
T4 IO控制器循環掃描時間（PLC的讀取PIO的刷新時間）

仔細查看各部分的時間設置如下：

6臺驅動的參數中，PN網絡監控時間（看門狗）100mS(默認值)
在設備組態中，每臺G120驅動的接口IO周期。刷新周期選擇為自動，但是各臺并不相同，有的是2mS，有的是4mS。
看門狗時間為6mS、12mS。
圖3 驅動IO周期

Zui后， PLC 1214C的發送時鐘為 1mS, 而PLC的掃描周期為5-8mS.
圖 PLC 掃描周期

還有一點，給定的輸出，采用了40mS循環時間中斷的斜率輸出給定（起始從0開始）。

我的問題是：
1、這些時間周期如何設定是合理、zuijia的。
2、發送時鐘1mS的含義是：每毫秒發送全部6臺的控制字和設定值等等的報文，還是每毫秒發送1臺的報文（輪詢方式）？
3、在網絡視圖中，各臺驅動接口的IO刷新時間是否應該手動設置為一致？

4、如何確定PN網絡的刷新周期（在沒有RT的情況下，是通過PING嗎）？

以下描述都是通俗易懂的描述方式。

發送時鐘：定義的是控制器可以說話的時間間隔

更新時間：更新時間為發送時間的倍數。

例如：PLC 定義的發送時鐘是1ms，則PLC下面掛的IO站的刷新時間，Zui小是1ms，不可能比1ms還小。

如果PLC的發送時間是1ms，PLC下掛了2個分布式IO，更新時間都是2ms，那么PLC和這2個分布式IO是這樣通信的。第一個發送時鐘和第一個分布式IO站通信，第二個發送時鐘，和第二個分布式IO站通信，依次循環。

又例如：PLC 定義的發送時鐘是2ms，2個分布式IO，更新時間都是2ms。則每個發送周期內，PLC要先后和2個分布式IO站完成通信。

又例如：PLC 定義的發送時鐘是2ms，2個分布式IO，一個更新時間是2ms，另一個是4ms，則在每個發送周期內，PLC都要和2ms更新時間的IO站通信，而4ms的站則是每兩個發送周期通信一次。

在非等時模式下，PLC的程序掃描和PLC的PN接口對分布式IO站的掃描是異步的。

只有在等時模式下，才是同步的。

關于Y版的疑問，此處再進一步詳細闡釋一下（通過一個略微大一點的系統）：

如果PLC的發送時間是1ms，PLC下掛了4個分布式IO，更新時間都是2ms，那么PLC和這4個分布式IO是這樣通信的。第N個發送時鐘和其中2個分布式IO站通信，第N+1個發送時鐘，和剩余2個分布式IO站通信，依次循環。。。

如果PLC的發送時間是1ms，PLC下掛了4個分布式IO，更新時間依次為1ms，2ms，4ms，4ms，那么PLC和這4個分布式IO是這樣通信的：

每N發送時鐘，都和1ms的IO站通信；而每N*2個周期，都和2ms的IO站通信，對于4ms的兩個分布式IO，雖然其循環時間都是4ms，但卻不是在同一個發送周期內通信的，因為那樣的話，此發送周期內處理的數據太多，而其它發送周期處理的數據又比較小，所以是錯開的，CPU內部會協調此事。比如，（N+0）*4個周期和一個4ms的IO站通信，（N+2）*4個周期和另一個4ms的IO站通信。