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