什么Shadow Buffer和Stack Buffer?
Shadow Buffer和Stack Buffer手冊(cè)中沒(méi)有定義，為了讓大家理解TCP的通信原理，我們需要知道這兩個(gè)Buffer。前者是在TCP的規(guī)范中定義，需要這個(gè)緩沖區(qū)緩存數(shù)據(jù)，PLC中的這個(gè)緩沖區(qū)用于DB和Stack Buffer的橋梁，而且用來(lái)決定數(shù)據(jù)一致性的大小。稱(chēng)為Shadow Buffer，影子Bufffer，是因?yàn)橄袢说挠白右粯?，Shadow Buffer的大小都會(huì)小于等于DB區(qū)的大小。
Stack Buffer是系統(tǒng)決定的，ISO/OSI參考模型的第4層，用于緩存數(shù)據(jù)的打包和解包，大小為8K。
什么是Keepalive?
當(dāng)網(wǎng)線(xiàn)斷開(kāi)，Keepalive定時(shí)器超時(shí)，會(huì)清空發(fā)送端和接收端的Shadow Buffer和Stack Buffer緩沖區(qū)中的數(shù)據(jù)。S7-1500CPU例外，不會(huì)清除接收端Shadow Buffer中的數(shù)據(jù)。
什么是流量定形？
是否采用可變長(zhǎng)度的TCP/IP協(xié)議來(lái)通信？
不推薦采用，AD-hoc模式是可以實(shí)現(xiàn)變長(zhǎng)的TCP/IP通訊的，但使用AD-hoc模式需要注意兩點(diǎn)：
（1）1500字節(jié)減去IP頭20個(gè)字節(jié)，減去TCP頭20個(gè)字節(jié)，即1460個(gè)字節(jié)的數(shù)據(jù)傳輸。大家想用第三方設(shè)備和PLC做通訊，要使用TCP協(xié)議的話(huà)，可能需要變長(zhǎng)的模式，在1460字節(jié)范圍內(nèi)是可使AD-hoc模式做通訊。
（2）比較底層的原因，即使使用小于1460字節(jié)的長(zhǎng)度去AD-hoc通信，也有可能造成數(shù)據(jù)對(duì)應(yīng)不一致，可能的原因就是接收端的接收速度慢。
交換機(jī)的規(guī)格不一樣，分別有些什么配置？
測(cè)試環(huán)境使用了Scalance 200 系列的交換機(jī)204-2，另外一個(gè)實(shí)際上不是交換機(jī)而是2個(gè)雙口TAP，實(shí)現(xiàn)物理硬件的網(wǎng)絡(luò)連接。對(duì)于200系列交換機(jī)，采用端口鏡像來(lái)實(shí)現(xiàn)數(shù)據(jù)抓包；XM400，使用其TAP功能，可以捕捉IRT的數(shù)據(jù)，而且是雙向IRT的數(shù)據(jù)，不需要改網(wǎng)卡的設(shè)置，也可以看VLAN Tag的標(biāo)簽。
設(shè)置Minimum Cycle Time對(duì)Communication Load有什么影響嗎？
如果PLC不設(shè)置最小循環(huán)周期，那么程序中斷加上通訊能運(yùn)行多長(zhǎng)時(shí)間就是多長(zhǎng)時(shí)間，沒(méi)有富余的時(shí)間去處理其他操作。對(duì)1500來(lái)說(shuō)，設(shè)置默認(rèn)的通訊負(fù)載是50%，在有大量的通訊存在的情況下，通訊負(fù)載是超不過(guò)50%的，如果設(shè)置了Minimum Cycle Time，假設(shè)程序運(yùn)行的時(shí)間純粹為2毫秒，設(shè)置的Minimum Cycle Time為10毫秒，意味著有8毫秒是free的，可以用來(lái)做通訊，此時(shí)即使設(shè)置了50%的通訊負(fù)載的上限，有大量通訊的情況下實(shí)際通訊負(fù)載照樣可以超過(guò)50%。
TCP的通信數(shù)據(jù)量最大64k, 那么當(dāng)通信傳送的數(shù)據(jù)變化很快，是否有數(shù)據(jù)一致性的保證，比如發(fā)送16k數(shù)據(jù)，只有8k是一致的？
TCP/IP通訊要想保持?jǐn)?shù)據(jù)一致性，只有DONE信號(hào)結(jié)束完成之后，你才能去修改數(shù)據(jù)，否則不能保證你發(fā)送的64k數(shù)據(jù)全是一致的，而只能保證每個(gè)8k的數(shù)據(jù)是一致的，即最大的一致性數(shù)據(jù)是8k。
交換機(jī)出現(xiàn)數(shù)據(jù)風(fēng)暴的由來(lái)？
數(shù)據(jù)風(fēng)暴其實(shí)就是所謂的廣播風(fēng)暴，簡(jiǎn)單理解就是本地網(wǎng)絡(luò)中存在大量的廣播報(bào)文，導(dǎo)致通訊無(wú)法進(jìn)行甚至網(wǎng)絡(luò)癱瘓。實(shí)際上它是一種普遍的網(wǎng)絡(luò)問(wèn)題，解決這個(gè)問(wèn)題的關(guān)鍵是減少?gòu)V播報(bào)文的出現(xiàn)，產(chǎn)生廣播報(bào)文的原因有很多種，最常見(jiàn)的在工廠里有PC中了蠕蟲(chóng)病毒，向網(wǎng)絡(luò)中發(fā)送大量的廣播數(shù)據(jù)，引起網(wǎng)絡(luò)堵塞，造成廣播風(fēng)暴。另外一個(gè)點(diǎn)是工廠使用一些測(cè)試網(wǎng)絡(luò)工具，會(huì)周期性的向網(wǎng)絡(luò)發(fā)送大量廣播以獲得網(wǎng)絡(luò)狀態(tài)信息。還有一些其他原因，比如網(wǎng)線(xiàn)短路等。
常用的Ping和ARP指令有什么區(qū)別？如果一臺(tái)設(shè)備不知道IP,如何快速知道IP？
兩者其實(shí)并不能放在一起比較。Ping指令用于檢測(cè)通信方是否可達(dá)。用Ping去控制時(shí)間，可以用短時(shí)間Ping大量數(shù)據(jù)。比如：可以Ping 8k的數(shù)據(jù)，底層用的都是IP的協(xié)議。ARP是對(duì)自己的設(shè)備來(lái)說(shuō)去查表，比如ARP-A，可以看到里面的ARP的IP地址和MAC地址的映射關(guān)系，只有獲得對(duì)方的MAC地址才能與對(duì)方進(jìn)行通信，如果沒(méi)有，則發(fā)送ARP廣播來(lái)獲取通信方MAC地址。
上位機(jī)的TCP/IP 跟1500的TCP/IP傳輸時(shí)間一樣嗎？
無(wú)論是兩臺(tái)PC做TCP/IP還是1500之間做TCP/IP通訊，肯定的一點(diǎn)是網(wǎng)絡(luò)傳輸?shù)乃俣仁且粯拥?，打包，解包的堆棧時(shí)間，取決于網(wǎng)卡的性能，對(duì)于西門(mén)子網(wǎng)卡和市面上普通網(wǎng)卡這兩部分的時(shí)間應(yīng)該都是類(lèi)似的，最后剩余的就是我發(fā)送的循環(huán)周期和接收的循環(huán)周期誰(shuí)快，對(duì)于PC來(lái)說(shuō)未必比PLC快。如果PC發(fā)送周期比PLC長(zhǎng)，那么PC的TCP/IP通訊肯定會(huì)慢。如果兩者發(fā)送周期一樣，發(fā)送速度幾乎是一樣的，沒(méi)有太大差距。
環(huán)形網(wǎng)絡(luò)需要在交換機(jī)設(shè)置才能避免數(shù)據(jù)廣播風(fēng)暴？
首先以太網(wǎng)是不支持環(huán)網(wǎng)的，需要環(huán)網(wǎng)管理協(xié)議，比如用MRP，HSP(快速冗余環(huán)網(wǎng)協(xié)議)等，這些都是有管理器和客戶(hù)端的，由這些協(xié)議來(lái)控制環(huán)網(wǎng)。這種冗余方式當(dāng)有一臺(tái)設(shè)備壞了，可以切換過(guò)去，保障其他設(shè)備繼續(xù)進(jìn)行通訊，此時(shí)是避免了數(shù)據(jù)廣播風(fēng)暴的。
掃描周期不一樣，會(huì)出現(xiàn)丟包的問(wèn)題嗎？
這個(gè)掃描周期是指做CPU的掃描周期，比如說(shuō)設(shè)10毫秒，20毫秒或1毫秒等。TCP/IP的丟包有很多原因，比如網(wǎng)線(xiàn)短路或者做路由通信，路由器所造成的一部分丟包等等。但丟包沒(méi)關(guān)系，TCP是可靠的安全的連接，有丟包其會(huì)重新發(fā)送，與掃描周期沒(méi)關(guān)系，是由TCP/IP協(xié)議來(lái)決定的。
輪流跟多臺(tái)西門(mén)子CPU通信，周期約5s，是否需要主動(dòng)建立或斷開(kāi)連接？
一個(gè)CPU取決于PLC的連接資源的數(shù)量，假如一個(gè)PLC可以連接16個(gè)做TCP/IP通訊，也就是可以連接16臺(tái)設(shè)備，連到第17臺(tái)設(shè)備的時(shí)候要想通訊，需要斷開(kāi)一臺(tái)TCP的連接，把資源釋放掉再重新跟第17臺(tái)做通訊，這種情況下才可以做輪流通訊。但至于說(shuō)5s，因?yàn)椴恢罃?shù)據(jù)量多大，如果數(shù)據(jù)通訊量很少，5s夠用。
使用TCON建立了解發(fā)送和接受數(shù)據(jù)，會(huì)影響CPU的掃描周期嗎？
首先TCON是建立一個(gè)通訊資源，通訊資源的建立注冊(cè)是一個(gè)程序的執(zhí)行，并沒(méi)有完成發(fā)送和接受數(shù)據(jù)，所以不影響掃描周期，只是消耗數(shù)據(jù)代碼的時(shí)間。
連接建立后，TSEND和TRCV數(shù)據(jù)量大小對(duì)掃描周期的影響？
對(duì)掃描周期的影響很大，CPU默認(rèn)的通訊負(fù)載是50%的情況下，它會(huì)處理PG在線(xiàn)程序等等，這些都會(huì)增加通訊負(fù)載里50%的負(fù)載，那么你的數(shù)據(jù)量越大，你要消耗的CPU的時(shí)間片的通訊部分就會(huì)越大，所以對(duì)掃描周期的影響就會(huì)越大。
CPU通訊負(fù)載可以調(diào)節(jié)的嗎？
CPU通訊負(fù)載可以調(diào)節(jié)，因?yàn)樵贑PU設(shè)置的屬性里，通訊負(fù)載是可以調(diào)節(jié)的，對(duì)1500PLC來(lái)說(shuō)，默認(rèn)是50%。
Keepalive時(shí)間是固定間隔發(fā)的嗎？那如果斷線(xiàn)后，再連接網(wǎng)線(xiàn)，重連的時(shí)間就不固定了？
Keepalive參數(shù)open出去了，意味著允許用戶(hù)修改，默認(rèn)時(shí)間是30s。設(shè)置多長(zhǎng)時(shí)間，Keepalive探測(cè)幀就按照多長(zhǎng)時(shí)間發(fā)送。還有在Keepalive設(shè)置為0的情況下，Keepalive就被禁止了。重連的時(shí)間取決于網(wǎng)絡(luò)端口，例如自適應(yīng)的端口時(shí)間，還有就是REQ的發(fā)送頻率，越快重連時(shí)間越短。
Keepalive是客戶(hù)端行為還是服務(wù)器端行為？
Keepalive與是客戶(hù)端行為還是服務(wù)器端行為沒(méi)有關(guān)系，是雙方根據(jù)自定義的時(shí)間間隔，周期性的向通訊伙伴發(fā)送Keepalive探測(cè)幀，然后伙伴予以應(yīng)答。
雙方設(shè)定的Keepalive時(shí)間是如何協(xié)調(diào)的？是在通信握手的時(shí)候就協(xié)商時(shí)間，按最短的設(shè)置時(shí)間發(fā)送嗎？
首先在握手的時(shí)候和Keepalive沒(méi)有關(guān)系，也不會(huì)協(xié)商這個(gè)時(shí)間，握手只是做連接，主要確定堆棧Buffer大小。
1500TCP通訊怎么清緩存區(qū)，固定長(zhǎng)度報(bào)文，對(duì)方發(fā)送長(zhǎng)度造成接受混亂錯(cuò)位？
清緩存區(qū)不是人為可以清除的，除非釋放資源TDISCON。Keepalive超過(guò)30s后會(huì)清緩沖區(qū)，但清緩沖區(qū)是發(fā)生斷線(xiàn)的時(shí)候去清，那么除了斷線(xiàn)，也有可能是網(wǎng)絡(luò)擁堵而造成的超時(shí)等問(wèn)題。
“如果指的是發(fā)送和接收的數(shù)據(jù)不匹配的話(huà)”，在做TCP/IP通訊的時(shí)候，我們?cè)谛∮?460個(gè)字節(jié)的時(shí)候，可以使用AD-hoc模式，可以進(jìn)行變長(zhǎng)的數(shù)據(jù)通訊，這時(shí)數(shù)據(jù)可以基本爭(zhēng)取的被接收，具體看問(wèn)題4。
CPU的緩沖區(qū)是針對(duì)所有通訊鏈接使用同一個(gè)緩沖區(qū)，還是不同鏈接開(kāi)辟不同緩沖區(qū)？
這個(gè)直接關(guān)系到CPU通訊資源的問(wèn)題，比如315-2PN/DP有16個(gè)TCP/IP的連接，大家首先想到的肯定是可以連接16個(gè)通訊伙伴，但實(shí)際上來(lái)說(shuō)，在內(nèi)部當(dāng)中，就表示我有多少內(nèi)存大小分配給通訊去做數(shù)據(jù)交換。說(shuō)白了，就是能給一個(gè)通訊分配多大的Shadow Buffer 和堆棧Buffer。既然有16個(gè)連接，有8k的Shadow Buffer和8K的堆棧Buffer，就意味著我們以Shadow Buffer或堆棧Buffer為例，都是8k。所需要的緩沖區(qū)大小至少是2x8x16，即CPU給你資源的分配都是按照內(nèi)存的大小分配好的，不是共用的，每一個(gè)TCP的通訊都是individual，去用自己的Shadow Buffer和堆棧Buffer。
如何理解數(shù)據(jù)一致性的概念？
例如我從A向B發(fā)送1040個(gè)字節(jié)，但是由于我PLC的性能決定它最大的一致性是800的字節(jié)，那么多了的字節(jié)需要第二次才能發(fā)送出去。如果在你第二次發(fā)送給B剩余的240個(gè)字節(jié)的時(shí)候，B的PLC修改了后240字節(jié)中的數(shù)據(jù)，那么這時(shí)我們第一次發(fā)送的800個(gè)字節(jié)和后面發(fā)送的240個(gè)字節(jié)就不一致了。不一致最重要的影響在于，如果你做項(xiàng)目的時(shí)候利用這1040個(gè)字節(jié)做運(yùn)算，eg：復(fù)雜的工藝上的計(jì)算、運(yùn)行數(shù)據(jù)上的計(jì)算，那么計(jì)算時(shí)我需要這些數(shù)據(jù)是一致的。從A到B的過(guò)程中這些數(shù)據(jù)不能出現(xiàn)變化，要保持同一時(shí)刻數(shù)據(jù)是一致的，這時(shí)你算出來(lái)的結(jié)果才是正確的。如果單純傳數(shù)據(jù)作為顯示，大家可能不會(huì)注意到。但是計(jì)算時(shí)不能忽略數(shù)據(jù)的一致性。
探測(cè)幀怎么用于斷線(xiàn)診斷？程序怎么寫(xiě)？
編程是不需要的，只需要修改Keepalive參數(shù)。如果你希望在5秒內(nèi)判斷斷線(xiàn)故障，你就把參數(shù)設(shè)成5秒。同時(shí)REQ不能手動(dòng)去使能。如果REQ 20秒使能一次，那么判斷出錯(cuò)故障至少需要20秒。如果REQ 100毫秒的循環(huán)周期使能，那么就能在5秒鐘左右發(fā)現(xiàn)斷線(xiàn)故障。
Shadow Buffer和堆棧Buffer在CPU的哪個(gè)存儲(chǔ)區(qū)？
這個(gè)手冊(cè)中并沒(méi)有說(shuō)明，最近講的都是我總結(jié)出來(lái)的。這里希望給大家展示原理的探秘。手冊(cè)即使沒(méi)有說(shuō)，但在老s7-400的手冊(cè)中有提到：通信資源建立后，要在系統(tǒng)存儲(chǔ)器中建立通訊緩沖區(qū)。所以對(duì)于400來(lái)說(shuō)，Shadow Buffer是存在在系統(tǒng)存儲(chǔ)器中。堆棧Buffer在網(wǎng)卡的緩沖區(qū)里。對(duì)于300確切的位置手冊(cè)里沒(méi)有說(shuō)。在建立通訊緩沖區(qū)時(shí)就是在建立通信資源，Buffer都是獨(dú)立分開(kāi)的，開(kāi)啟Shadow Buffer就是在占用CPU資源。堆棧Buffer都是存在的，只是用的協(xié)議不同，誰(shuí)要用誰(shuí)就建立連接占用這部分通信資源。然而理論上這兩個(gè)緩沖區(qū)都應(yīng)該存儲(chǔ)在CPU的接口網(wǎng)卡中。
OB1程序段里先通過(guò)TCON建立通訊，最后一行再TDISCON，CPU是真的在每個(gè)掃描周期都要重新建立一次通訊，然后再斷開(kāi)一次釋放通訊資源嗎？會(huì)不會(huì)一個(gè)周期內(nèi)無(wú)法完成？
我們?cè)诮⑦B接和斷開(kāi)連接的一個(gè)循環(huán)周期里，同樣，如果我們使用一個(gè)wait指令，使用一個(gè)loop循環(huán)去循環(huán)三秒鐘。有些事情如果大家想不清楚大家可以去延長(zhǎng)CPU的循環(huán)周期。在最開(kāi)始使用TCON建立連接，實(shí)際上并沒(méi)有通訊起來(lái)，只是建立了資源和緩沖區(qū)，包括對(duì)應(yīng)的端口號(hào)、IP等，都注冊(cè)進(jìn)去。結(jié)尾再TDISCON斷開(kāi)，資源就被釋放了。是這樣一個(gè)過(guò)程。
一般有多個(gè)通訊的CPU，怎么把握CPU掃描周期設(shè)為多少合適？
大家還是自己去思考，如何優(yōu)化設(shè)置多少合適。如果設(shè)置最小掃描循環(huán)周期為15ms，且CPU的代碼執(zhí)行是5毫秒，這是為了給更多的通訊讓路，給更多的通訊分配額外的資源，但這就損失了你的循環(huán)周期，進(jìn)一步損失了你的響應(yīng)周期。這是一把雙刃劍，可能會(huì)影響你實(shí)時(shí)的控制，那么你可以設(shè)置10ms，來(lái)滿(mǎn)足你現(xiàn)場(chǎng)的控制。還是要看通訊有多少輸入量。如果現(xiàn)場(chǎng)用到很多的連接，那么必須通訊優(yōu)先，通訊荷載設(shè)置50%，為了通訊響應(yīng)更好，那就要設(shè)置合適的循環(huán)周期，一方面保證我的通訊，一方面保障我現(xiàn)場(chǎng)控制的實(shí)時(shí)要求。
在通訊時(shí)，RT通訊為什么比TCP快？
這個(gè)問(wèn)題比較系統(tǒng)。第一，對(duì)于TCP/IP通訊和PN通訊，我們?cè)诳偩€(xiàn)上傳輸?shù)乃俣仁且粯拥?，都?00兆，這一點(diǎn)大家可以忽略比較；第二，就是堆棧。上幾節(jié)課我提到了關(guān)于ISO/OSI參考模型的堆棧，PN RT使用的第七層和物理層（也就是第一二層），中間沒(méi)有TCP/IP，也就意味著應(yīng)用層（第七層）的數(shù)據(jù)會(huì)直接加載到物理層上去，為什么PB DP也快，原因是一樣的，都是第七層落到物理層。對(duì)于TCP/IP，它堆棧沒(méi)有PN快，因?yàn)閿?shù)據(jù)進(jìn)來(lái)需要TCP的打包、需要IP的打包，再在接收時(shí)解包，堆棧角度沒(méi)有PN快。還有一個(gè)條件在于我們的芯片，芯片性能要一致，要在同樣的性能上做比較。還有一點(diǎn)在于數(shù)據(jù)處理，Shadow Buffer對(duì)于通訊的處理。PN在數(shù)據(jù)發(fā)送中能以最小的以太網(wǎng)GAP進(jìn)行發(fā)送，以太網(wǎng)之間最小的時(shí)間間隔時(shí)12個(gè)字節(jié)，TCP做不到，因?yàn)樗鎯?chǔ)、等待、加載，于是從發(fā)送的角度PN RT也比TCP快。綜上三個(gè)角度，RT通訊比TCP快。
TCP的變長(zhǎng)接收是什么原理呢？
原理很復(fù)雜，原因在于我們看TCP標(biāo)準(zhǔn)沒(méi)有AD-hoc模式，我們只在接收方有這個(gè)參數(shù)，接收的CPU告訴網(wǎng)卡要截取堆棧緩沖區(qū)取得數(shù)據(jù)，然后給Shadow Buffer。如果是1460的字節(jié)，就不會(huì)出錯(cuò)，但如果超過(guò)1460，無(wú)法取得正確數(shù)據(jù)。例子中還按1024字節(jié)去發(fā)送，發(fā)送9次，TCP/IP接收不激活的情況下，接收端就堆滿(mǎn)了，當(dāng)滑動(dòng)窗口放開(kāi)，發(fā)送的數(shù)據(jù)就變?yōu)榱?460字節(jié)，這樣數(shù)據(jù)的位置會(huì)發(fā)生變化，導(dǎo)致不能收到正確的數(shù)據(jù)。ISO on TCP是最佳的可變長(zhǎng)度協(xié)議。
ISO on TCP與PC端也能通信嗎？
ISO on TCP也是開(kāi)放式通信協(xié)議，跟TCP UDP一樣，只要 PC端支持，就可以和西門(mén)子的PLC做通信。
S7協(xié)議和以太網(wǎng)協(xié)議有什么區(qū)別？
S7協(xié)議是西門(mén)子內(nèi)部私有協(xié)議，不對(duì)外公開(kāi)，只在西門(mén)子產(chǎn)品進(jìn)行使用；是以太網(wǎng)協(xié)議的一部分，以太網(wǎng)協(xié)議范圍很廣泛。
TCP 和S7 協(xié)議怎么選擇？
如果使用TCP，在底層處理效率會(huì)更高，因?yàn)镾7是在加載TCP基礎(chǔ)之上的。但是差異不明顯，只是使用S7協(xié)議的時(shí)候，是在西門(mén)子產(chǎn)品之間；如果和第三方通訊的話(huà)，就要選擇TCP協(xié)議。所以根據(jù)目標(biāo)對(duì)象支持的協(xié)議進(jìn)行選擇即可。
只用Wireshark 與交換機(jī)連接，不是需要做端口鏡像嗎？
不使用交換機(jī)，就要用TAP 或者Bany設(shè)備，Bany Scope是結(jié)合硬件設(shè)備去使用的?？梢韵荣I(mǎi)價(jià)格較低的TAP做測(cè)試，性能上有一些限制。如果大家想做這方面研究，性?xún)r(jià)比最高的是鏡像，條件允許就買(mǎi)Bany設(shè)備。
