工業(yè)以太網(wǎng)協(xié)議要解決的問題精(可編輯).doc_第1頁
工業(yè)以太網(wǎng)協(xié)議要解決的問題精(可編輯).doc_第2頁
工業(yè)以太網(wǎng)協(xié)議要解決的問題精(可編輯).doc_第3頁
工業(yè)以太網(wǎng)協(xié)議要解決的問題精(可編輯).doc_第4頁
工業(yè)以太網(wǎng)協(xié)議要解決的問題精(可編輯).doc_第5頁
已閱讀5頁,還剩23頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領

文檔簡介

1、工業(yè)以太網(wǎng)協(xié)議要解決的問題精(可編輯 )精選資料工業(yè)以太網(wǎng)協(xié)議問題上表,EtherCAT 中的數(shù)據(jù)鏈路層是否要解決通信中的流量控制為什么通信棧是由什么實現(xiàn)的我理解EtherCAT 協(xié)議為 , “協(xié)議標準實際上在談兩個問題:服務與協(xié)議。服務的含義是提供何種功能 ,網(wǎng)絡通信各層的服務都是圍繞如何進行可靠數(shù)據(jù)傳輸所定義的服務 ,屬于通信類服務 ,即服務是解決服務者做什么的問題。協(xié)議是解決實現(xiàn)服務時應該怎樣做的問題 ,即如何做才能實現(xiàn)具體的服務?!笨煽繑?shù)據(jù)傳輸主要針對通信中遇到的電磁干擾 ,因此在物理層與鏈路層上要思考如何應對干擾的解決措施 ,但數(shù)據(jù)鏈路層與應用層之間的數(shù)據(jù)傳輸已經(jīng)是在系統(tǒng)內(nèi)的傳輸,是

2、否存在相關的可靠數(shù)據(jù)傳輸問題為什么 “數(shù)據(jù)傳輸 ”從字面意義上講是數(shù)據(jù)信號波形的流動,除此之外 ,能否將 “數(shù)據(jù)傳輸 ”與“數(shù)據(jù)存儲 ”聯(lián)系在一起接在現(xiàn)場總線上的設備功能各異 ,那么 EtherCAT 是以何種思想解決對各種功能設備的聯(lián)網(wǎng)控制提示 :計算機是一臺通用設備 ,但可以實現(xiàn)各種功能。請盡可能多的給出你知道的ASE。如何構建一個 ASE 設想一個應用過程 (例如遠程對溫度傳感器測溫監(jiān)控 ,如何利用多個 ASE 協(xié)同完成該應用過程。EtherCAT 使用了哪些技術與方法來應對“時間關鍵 ”的數(shù)據(jù)傳輸上面是 EtherCAT 定義的一個模板。為什么要定義該模板 ,主要解決數(shù)據(jù)傳輸中的什么問

3、題。若沒有協(xié)議規(guī)定數(shù)據(jù)的結構化表示方法,是否會造成混亂上圖是物理層通用模型。請以你自己的理解方式解釋媒體相關、媒體無關、媒體附屬的含義“物理層的功能是以一種適合于通信媒體的形式對傳輸接收的信號進行編碼譯碼 ,規(guī)定通信媒體的特性 ”。你認為編碼譯碼工作是在上圖中的哪個部分中完成的(PhDIS、PhMDS、PhMAU 為什么上圖中有四個接口:DLPh 接口、DTEDCE 接口、 MDSMAU 接口、媒體接口。試述這些接口的主要作用 (通常接口的主要作用是 :數(shù)據(jù)格式變換、阻抗匹配、信號波形變換、 時序配合、機械特性等哪些接口可能屬于設備內(nèi)部接口哪些接口可能屬于設備間的外部接口上圖是DLLPHL接口

4、數(shù)據(jù)單元間的映射。試指出圖中的錯誤所在之處 ,并描述映射的含義與實現(xiàn)的過程 (思路。圖中為什么要定義四個數(shù)據(jù)單元 ,它們各自存放什么樣的數(shù)據(jù) (帶有幀格式的數(shù)據(jù)幀、 部分幀還是完整幀在數(shù)據(jù)單元后面加 “序列 ”說明什么依據(jù)上圖 ,是否應該設置一些存儲器單元來傳輸數(shù)據(jù)請給這些存儲器起一些名稱 ,并注明它們所起的具體作用對于上圖 ,協(xié)議標準給出了如下幾項注釋 :注 : “DLLPHL 接口是一種虛擬機間的虛擬服務接口”。既然是一種相互聯(lián)接的接口 ,那么物理層與數(shù)據(jù)鏈路層雙方就好像是兩個獨立的設備 ,要通過該接口交換數(shù)據(jù)。通常兩臺設備交換數(shù)據(jù)時要定義數(shù)據(jù)收、發(fā)緩沖區(qū)。對于虛擬接口 ,你認為是否也該這

5、樣做為什么數(shù)據(jù)鏈路層與物理層要通過接口交換數(shù)據(jù),那么雙方怎樣獲知有數(shù)據(jù)要交換例如,對于數(shù)據(jù)鏈路層來說 ,它是如何知道物理層有新數(shù)據(jù)要傳輸給自己。數(shù)據(jù)鏈路層中的數(shù)據(jù)幀中不會含有前同步碼、后同步碼、幀定界符,這些控制數(shù)據(jù)是在物理層中加上的 ,那么物理層中是否應該定義一些相應的寄存器 ,用來存放同步碼、 定界符等幀格式控制信息注 , “依據(jù)工業(yè)實踐 ,定義了許多不同的 DLLPHL 接口 ”,你對此是如何理解這話的對你實現(xiàn) DLLPHL 接口有無啟示協(xié)議規(guī)定物理層須有特性指示原語:Ph 特性指示 (minimumdatarate,framingoverhead 定義該原語的目的是什么該原語在何種情況

6、下發(fā)出發(fā)給誰特性指示原語中兩個參數(shù)minimumdatarate,framingoverhead所起的作用是什么有關服務原語,我在網(wǎng)上看到的資料描述如下:用戶和協(xié)議實體間的接口,實際上是一段程序代碼 ,但其具有不可分割性。通過服務原語能實現(xiàn)服務用戶和服務提供者間的交流,與協(xié)議不同的是 ,服務原語用于服務提供者與服務用戶,而協(xié)議是用于服務用戶之間的通信。在同一開放系統(tǒng)中 ,(N 實體向 N 實體請求服務時 ,服務用戶和服務提供者之間要進行交互,交互信息稱為服務原語四種基本原語: 請求(Request用戶實體要求服務做某項工作源(N實體源(N實體指示(indication用戶實體被告知某事件發(fā)生目

7、的(N實體目的(N實體響應(Response用戶實體表示對某事件的響應目的(N 實體目的(N 實體確認(Confirm 用戶實體收到關于它的請求的答復源(N 實體源 (N 實體服務和協(xié)議常常被混淆 ,而實際上二者是迥然不同的兩個概念。為此我們再強調(diào)一下兩者的區(qū)別。服務是網(wǎng)絡體系結構中各層向它的上層提供的一組原語(操作。盡管服務定義了該層能夠代表它的用戶完成的操作 ,但絲毫也未涉及這些操作是如何實現(xiàn)的。服務描述兩層之間的接口,下層是服務提供者 ,上層是服務用戶。而協(xié)議是定義同層對等實體間交換幀、數(shù)據(jù)包的格式和意義的一組規(guī)則。網(wǎng)絡各層實體利用協(xié)議來實現(xiàn)它們的服務。只要不改變提供給用戶的服務和接口

8、,實體可以隨意地改變它們所使用的協(xié)議。這樣 ,服務和協(xié)議就完全被分離開來。工業(yè)以太網(wǎng)協(xié)議有如下的描述:試問:原語PHDATA請求(CLASS,DATA 這個過程函數(shù)是位于物理層還是數(shù)據(jù)鏈路層調(diào)用該原語的實體是物理層的實體還是數(shù)據(jù)鏈路層的實體參數(shù)CLASS 的含義到底是什么網(wǎng)絡協(xié)議的版本經(jīng)常升級,CLASS 是否與具體協(xié)議內(nèi)容有關,例如規(guī)定幀頭的特定格式你認為我的下述理解有無問題數(shù)據(jù)鏈路層的某個用戶實體希望將數(shù)據(jù)鏈路層中的數(shù)據(jù) (存放在協(xié)議數(shù)據(jù)單元DLPDU 發(fā)送緩沖區(qū)通過 DLLPHL 接口將其送到物理層中的協(xié)議數(shù)據(jù)單元 PHPDU 發(fā)送緩沖區(qū)中 ,于是調(diào)用物理層中的請求原語:PHDATA請求

9、 (CLASS,DATA, 該請求的過程實現(xiàn)函數(shù)會先將幀頭放入PHPDU,然后將 DLPDU 中的數(shù)據(jù)逐字節(jié)地傳送到PHPDU,全部傳完后 ,再將幀尾放入 PHPDU。對于工業(yè)以太網(wǎng)協(xié)議有如下的描述:請以自己的理解描述PHDATA指示 (CLASS,DATA原語及其實現(xiàn)過程。如何將物理層正在接收來自其它節(jié)點的數(shù)據(jù)及事件告之數(shù)據(jù)鏈路層又如何實現(xiàn)將已接收的物理層數(shù)據(jù)傳輸?shù)綌?shù)據(jù)鏈路層如何實現(xiàn)對于錯誤接收數(shù)據(jù)的事件指示對于物理層的管理,工業(yè)以太網(wǎng)標準給出的規(guī)定并不十分明確,因為處于物理層中的不同硬件可能有著不同的特性 ,因此要實現(xiàn)對硬件的管理,就必須先明確硬件的特性。工業(yè)以太網(wǎng)標準將物理層的管理視作為

10、一個與物理層并行的模塊該模塊中最重要的一個過程函數(shù)是復位原語的編寫。請回答由誰來發(fā)出復位請求試舉例說明復位時要做一些具體工作。上述話語是對于整個DIS 要實現(xiàn)的功能的具體描述。你認為物理層在收到了一幀中的部分字節(jié)還是全部字節(jié)后開始傳輸給 PhID 需不需要規(guī)定PhSDU 的最大字節(jié)數(shù)標準中有如下的話語,我不明白 ,你是如何理解的關鍵是不明白要傳輸?shù)男蛄惺峭ㄟ^哪些已定義的控制信號來實現(xiàn)交互標準中關于低層通信功能的描述如下:由于工業(yè)以太網(wǎng)在眾多技術規(guī)范上與以太網(wǎng)是相同的,所以能否找到實,現(xiàn)低層通信的專用芯片及技術資料使用通用芯片實現(xiàn)上述功能還是非常麻煩。上述的 PhPDU 中存放的 PhSDU 序

11、列是表示一個字節(jié)的字符還是多個字節(jié)的字符串字符是否是已進行了曼徹斯特編碼上述是標準中關于網(wǎng)絡的拓撲連接方面的描述 ,我不明白。分支把線型結構提升為樹形結構。這如何實現(xiàn)端口有何特殊之處 ,為什么它不能接收以太網(wǎng)幀 (n 不為如果沒有設備連接或者端口被主站關閉 ,發(fā)送到該端口的請求被處理。如何處理對于上圖 ,標準中稱其為數(shù)據(jù)鏈路層參考模型。你認為這是主站參考模型還是從站參考模型圖中有許多小矩形 , 內(nèi)部標有標識文字 ,如 DLLinfo,FMMUn 等,我認為這些小矩形都是存儲器 ,標識的文字表明其為實現(xiàn)字面含義所需要存儲的參數(shù) ,這樣的認識對嗎物理層要負責將接收到的數(shù)據(jù)傳輸?shù)綌?shù)據(jù)鏈路層 ,數(shù)據(jù)鏈

12、路層要對收到的數(shù)據(jù)進行地址檢查、 CRC 查錯等多項工作 ,因而需要花費一定的時間 ,這個時間你認為會小于微妙嗎從站在實際運行中需要對來自總線的信號進行邊接收、邊處理、邊轉發(fā)以實現(xiàn) “飛速 ”,接收、處理、轉發(fā)的數(shù)據(jù)長度是否固定若在處理的過程中發(fā)現(xiàn)有錯誤 ,還會繼續(xù)轉發(fā)嗎在以太網(wǎng)幀中需要給出通信雙方的地址 ,但由于邏輯尋址是尋址 GB 空間的一段區(qū)域 ,對于區(qū)域范圍 ,在以太網(wǎng)幀中如何表示 GB 邏輯地址空間是位的 ,若某個從站物理存儲器的位長是位 ,該如何表達映射關系定義了映射方向 (輸入或輸出是否意味著從站對應的物理存儲器就只能是接收或輸出來自物理層的數(shù)據(jù)輸入、 輸出的方向定義是針對 FM

13、MU 與 DLPDU 兩個實體中的哪個實體而言的對于 FMMU, 實際中你會如何實現(xiàn) ,請給出較為詳細的技術實現(xiàn)思路。按上述功能定義 ,同步管理器作用是控制對 DLS 用戶內(nèi)存的訪問。此處同步的含義是解決存儲器訪問中的什么問題 DLS 用戶內(nèi)存指的是哪個層中的內(nèi)存可能實際中有三處內(nèi)存區(qū)域 A、B、C,三個數(shù)據(jù)區(qū)域都有功能含義不同的定義,而且它們都可能被數(shù)據(jù)鏈路層與應用層訪問 ,那么同步管理器的通道數(shù)應該為幾個上圖是從站的通信結構 , 你認為這種通信結構是否也適應于主站為什么將通信過程進行層次化的規(guī)定 ,主要是解決什么問題為什么對圖中寄存器的訪問操作與對存儲器的訪問操作在規(guī)定上有所不同 (例如主

14、站對于寄存器的讀操作無需通告 DL 用戶 ,而對存儲器的讀操作需通告 DL 用戶寄存器中主要存放什么數(shù)據(jù)存儲器中又主要存放何種數(shù)據(jù)圖中的事件指示該如何具體實現(xiàn)上述話語中的“一致性限制 ”是什么意思上圖中,主站對從站的讀寫訪問是用客戶機服務器模型來實現(xiàn)的嗎上圖表示 ,無論主站發(fā)送什么請求 ,都一定會得到從站的回應 ,這樣理解對嗎請解釋上表的自增式物理讀的工作過程 (主要是如何產(chǎn)生請求、證實的過程其中參數(shù)Devicedataarea是從站中的物理內(nèi)存位置 ,主站是如何知道從站的物理內(nèi)存位置 ,是預先約定的嗎請解釋上表中的 C 的意思 ,原文的含義我無法理解 ,你是這樣理解的。在主站發(fā)出自增式物理讀

15、請求時,上表中 “DATA”中的數(shù)值是什么上表是主站對于自增式物理讀的 EtherCATPDU 的規(guī)定 ,那么從從站返回給主站的 EtherCATPDU 是否采用相同的格式若相同 ,如何解釋表中證實一列中的 Devicedataarea參數(shù)缺失對于上述 PNV 服務 ,我無法理解,其中的參數(shù)含義也不懂,上表中不知為何還用 “指示 ”替代了 “證實 ”,你能否給出該如何使用 PNV 服務 (在什么情況下會使用該服務或者說你是怎樣理解該服務的上述中 , “從站與從站間的通信通過類似路由器的主站進行管理 ”,這話的含義是什么換句話說如從站之間需要進行數(shù)據(jù)交換的通信 ,大體的實現(xiàn)過程是什么上表是郵箱寫

16、服務 ,它的基本功能也是向指定的內(nèi)存中寫入數(shù)據(jù) ,它與前述的其它請求命令如自增式物理位置寫有什么不同為什么在自增式物理位置寫的表中僅有兩列 (請求、證實 ,而在郵箱寫中有三列 (請求、指示、證實在工業(yè)以太網(wǎng)中 ,我認為通信只能是主站發(fā)出 ,從站被動接收或轉發(fā) ,這意味著通信時不需要知道主站的地址 ,但在上表中 ,有兩個地址 ,Daddress(目的地址與 Saddress(源地址 ,若通信中源為主站 ,目的為從站 ,主站的地址該如何表示若通信中源為一個從站 ,目的為另一個從站 ,兩個從站的地址又該使用何種尋址方式下的地址上表與下表顯然無法對應 ,你對此這樣理解對于郵箱服務 ,有幾個參數(shù)如 :T

17、YPE、Cnt,你是如何理解的對于表中的地址描述,我不理解,你是怎樣理解的對于上述中的Mailboxwriteevent,readlocal 你是這樣理解的我的如下理解有問題嗎主站向從站發(fā)送寫郵箱命令,從站接收到該命令幀后,將幀中的郵箱數(shù)據(jù)取出放入到從站的數(shù)據(jù)鏈路層的郵箱接收緩沖區(qū)中,數(shù)據(jù)鏈路層的管理單元再通過同步通道管理器將郵箱接收緩沖區(qū)中的數(shù)據(jù)寫入到郵箱中 (這個過程可能比較漫長,這就是readlocal 的含義 ,在成功寫入郵箱后 ,數(shù)據(jù)鏈路層的管理單元再產(chǎn)生一個郵箱數(shù)據(jù)被更新的狀態(tài)事件,通知從站應用層來使用郵箱中的數(shù)據(jù),即 event。由于寫入郵箱的時間不確定,從站對于請求的轉發(fā)又不能

18、等待,那么從站該如何應答主站的請求上述的本地讀操作是在從站的應用層與數(shù)據(jù)鏈路層之間進行的嗎對于上述的本地事件,你認為該如何具體實現(xiàn)你是如何理解上表的,如 EtherCATxxx 中的 xxx 的含義是什么為什么只有自增式地址而無其它尋址方式的地址LEN 代表的是什么長度上述話語給出了如下幾個意思,一是 EtherCATPDU 可以作為普通以太網(wǎng)幀中的數(shù)據(jù) ,二是多個EtherCATPDU 可以視為一個整體數(shù)據(jù),并放入一個以太網(wǎng)幀中三是可以使用的以太網(wǎng)幀有兩種格式,一種是帶有 IP 路由的幀 ,另一種是不帶 IP 路由的幀 ,當然不帶 IP 路由時 ,就只能在局域網(wǎng)中進行傳播。那么我們到底該使用

19、哪種以太網(wǎng)幀格式我們的使用環(huán)境可能不是網(wǎng)絡環(huán)境 ,就是一條工業(yè)控制局域現(xiàn)場總線 ,此時幀中的目的地址與源地址該如何填寫我們能使用網(wǎng)卡讀取以太網(wǎng)幀嗎若能 ,試想有什么方法再從中提取出 EtherCATPDU。對于上圖 ,請解釋第一個 EtherCATPDU 與第二個 EtherCATPDU 中的 Data 下方標注的字節(jié)數(shù) ( 與( 為何有差異上表是工業(yè)以太網(wǎng)標準對于屬性的描述示例。為什么表中要給出兩種訪問類型對于數(shù)據(jù)鏈路層,我們可以將其視為一個虛擬設備或?qū)ο?若從監(jiān)控、管理的角度出發(fā),應在 DL 中設置一些什么專用部件例如從站地址寄存器。DL 信息寄存器包含從站控制器的類型、版本和被支持的資源

20、。你認為從站的資源有哪些(注意 ,一個具體的從站可能因功能各異,所具有的資源數(shù)量可能各不相同,因此此處的資源僅限定為服務于工業(yè)以太網(wǎng)網(wǎng)絡通信的資源上表是 DL 信息的部分內(nèi)容 ,請問表中的物理地址值能否被改變?yōu)槠渌到忉?PORT 的值的含義。請解釋下表中各參數(shù)取值的含義。下表是從站地址屬性描述 ,請問站別名是否可為長度受限的字符串標準中描述 DL 控制寄存器的話語為 “DL控制寄存器通常被主站用來控制從站控制器 DL 端口的操作 ”。工業(yè)以太網(wǎng)中的從站控制器可將從一個端口上接收的以太網(wǎng)幀轉發(fā)到另一個端口上 ,控制寄存器中的內(nèi)容決定了轉發(fā)的一些具體行為 , 這樣理解有問題嗎 DL 控制寄存器中

21、的幾個重要控制參數(shù)如下 :請你根據(jù)自己的理解 ,給出端口的可能操作行為以及相應的對外狀態(tài)指示。要想控制好端口 ,對于端口控制寄存器屬性描述的理解就非常關鍵。例如端口的 “打開 ”、“關閉 ”、“自動打開 ”、“自動關閉 ”、“l(fā)inkdown、”“ linkup?!币韵率菢藴手薪o出的解釋你能否使用下圖解釋端口的狀態(tài)。通常的 IO 接口設備僅有控制與狀態(tài)寄存器 ,但由于 DL 是一個較為復雜的虛擬設備 ,它管理物理層的端口、負責與應用層交互數(shù)據(jù) ,所以其存在三組寄存器 :信息、狀態(tài)、控制。信息與狀態(tài)均是對外提供可用的信息,但兩者還是有些不同之處,你認為信息寄存器與狀態(tài)寄存器的本質(zhì)差異在哪兒請你以

22、自己的理解 , 對如下幾個端口狀態(tài)參數(shù)的差異性進行解釋:linkstatusport 、loopbackport(loopstatusport、signaldetectionport 下圖是譯文與原文中主站對于從站的 DLS 用戶控制寄存器的一次寫操作描述,兩圖有差異 ,你能肯定譯文有錯誤嗎譯文想表達什么思想上表是 DLS 用戶屬性描述表。譯文與原文存在一些差異 ,請指出差異所在 ,哪個描述不合理哪些寄存器可作為控制寄存器 ,哪些可作為狀態(tài)寄存器 ,哪些作特殊用途寄存器 R 是作為控制寄存器 ,那么 R 能否作為一個備用的控制寄存器此處的控制是控制誰的行為標準中定義了一個名詞 “事件寄存器 ”

23、,事件寄存器與狀態(tài)寄存器有什么相同的作用又有什么不同之處以上是標準中對于事件參數(shù) DLuserRChg 的描述。請問 “寫服務 ”是由哪里來的以上兩張表是標準中給出的 DLuser 事件表與外部事件表,兩張表中有多項參數(shù)名稱相同的事件,如“ DCEvent、” Syncmanagerchannelevent等。 ”這些同名參數(shù) ,其代表的事件是同一個嗎若相同,為什么要對相同的事件安排在兩張表中若不同,其各自代表的事件具體差異在哪里以上是標準中關于RX 錯誤計數(shù)寄存器的功能描述與操作描述。其中的操作描述 “往任何一個計數(shù)器中寫入數(shù)據(jù)將清零所有計數(shù)器”,這話該如何理解請分別給出物理層錯誤與幀錯誤的

24、一個典型示例。什么情況下會發(fā)生丟失鏈接錯誤附加計數(shù)器統(tǒng)計的是什么錯誤你能否給出具體實例。為什么這些統(tǒng)計計數(shù)器在標準中都是以可選方式給出的從上述的描述中 ,你能得出系統(tǒng)時鐘頻率的具體數(shù)值為多少嗎 DL 用戶看門狗的數(shù)值用于監(jiān)視 DL 用戶 ,這話該如何理解你準備在實際中如何做才能體現(xiàn)該功能同步管理器看門狗攜帶有一個表征其狀態(tài)的寄存器 ,即同步管理器看門狗狀態(tài)寄存器 ,但 DL 用戶看門狗卻沒有設置狀態(tài)寄存器 ,這是為什么上表是從站信息接口訪問表, 請解釋表中參數(shù)“ Owner、”“ Lock所”代表的具體含義 ,該表主要起什么作用從站信息接口中定義了數(shù)據(jù)寄存器、狀態(tài)寄存器、控制寄存器 ,標準將狀

25、態(tài)與控制寄存器放入了同一個表中 ,即表。請示例描述三者怎樣配合完成讀寫操作。為什么要規(guī)定寫操作是位,讀操作是位或位上述兩個表中的內(nèi)容顯然有差異 ,你如何看待為什么說一個DLE 可能包含幾個FMMU 實體我們?nèi)粘I钪兴褂玫泥]箱是有體積大小限制的 ,一個郵箱可以容納多封郵件 ,直到其不能在裝載新郵件時 ,我們才認為郵箱的狀態(tài)是滿的 ,空郵箱是指郵箱里面沒有任何郵件 ,郵箱還有第三種狀態(tài) ,就是不空也不滿。EtherCAT 中的郵箱是用于接收來自主站或來自DL 用戶的數(shù)據(jù) ,使用物理存儲器來存放數(shù)據(jù),如下圖所示 : 圖中使用了兩個郵箱,分別作為接收來自主站的數(shù)據(jù)與來自DL 用戶的數(shù)據(jù)。郵箱的狀態(tài)

26、僅定義了滿與空,而沒有第三種非空也非滿的狀態(tài),這是為什么難道實際中不存在第三種非空非滿狀態(tài)嗎圖中每個郵箱的內(nèi)存大小又該怎樣設定上述話語中有一句話我認為非常重要,即“不管讀出數(shù)據(jù)需要多長時間”。我認為該句話其表達的中心思想是數(shù)據(jù)的生產(chǎn)者與數(shù)據(jù)的消費者對數(shù)據(jù)產(chǎn)生的能力與消費的能力不一致 ,因而需要使用郵箱來控制平衡兩者的速度 ,若數(shù)據(jù)的產(chǎn)生能力大 ,通過郵箱就可以減緩新數(shù)據(jù)的產(chǎn)生速率。這樣的認識有問題嗎上圖是對于周期性過程數(shù)據(jù)的交互模式。圖中使用了兩組緩沖區(qū),分別作為接收來自主站的數(shù)據(jù)與來自DL用戶的數(shù)據(jù)。每組緩沖區(qū)又定義了個存儲區(qū)域 ,每個存儲區(qū)域的大小是否與一個郵箱的容量大小相等在郵箱模式下

27、,可犧牲的是什么 (數(shù)據(jù)還是時間在過程模式下 ,可犧牲的是又什么 (數(shù)據(jù)還是時間從數(shù)據(jù)消費者看 ,對于兩種模式 ,相隔一段時間間隔的前后兩次讀數(shù)據(jù)操作 ,所讀到的數(shù)據(jù)內(nèi)容哪一種模式下一定存在差異哪一種模式下不一定存在差異上圖是過程數(shù)據(jù)交換模式下的緩存區(qū)分配圖 ,對于圖中的 “可見 ”、“不可見不用 ”、“僅配置了緩存 ”、 “下一個緩存 ”你是如何理解的同步管理器有多個屬性參數(shù) ,請解釋以下的參數(shù)含義 ( 我沒有搞懂 : “Repeat、”“ RepeatAck?!编]箱有發(fā)送與接收 ,過程緩存也分為發(fā)送與接收 ,一共四個 ,即我們只需要四個同步管理器通道應該就夠了 ,但為什么標準中要定義個同步

28、管理器通道你認為標準中的如下規(guī)定是否必須遵循:上圖是關于分布時鐘的描述 ,我對分布時鐘的理解是 :圖中的 M 表示的是主站時鐘 ,S表示各個從站的時鐘 , t表示主站與從站的時間差。若將主站的時鐘作為參考時鐘,各個從站與參考時鐘間的時間誤差要小于微妙 ,若誤差大于微妙 ,從站就應該調(diào)整自身的系統(tǒng)時鐘頻率,使時鐘同步精準在一個微妙之內(nèi),我這樣理解有問題嗎有問題的話指出問題所在。微妙是一個極小的時間差,為保證達到如此小的誤差,EtherCAT 采用了哪些具體關鍵技術所謂關鍵技術是指保證同步精度所必須采取的措施。例如主站的系統(tǒng)運行時鐘頻率與各個從站的系統(tǒng)運行時鐘頻率由于是獨立運行的,因此必然存在時鐘

29、頻率的微小差距,若整個EtherCAT 指定主站或某個從站的時鐘作為參考時鐘,這樣就可獲得從站間的時間差 ,這是基準設立 ,以解決到底大家與誰同步的問題。請明確 EtherCAT 是如何設立基準的除基準設立關鍵技術外,存在誤差就要調(diào)節(jié) ,但基準的系統(tǒng)運行時鐘也存在隨時間漂移的問題,因此要解決跟隨調(diào)節(jié)問題 ,跟隨調(diào)節(jié)意味著每間隔一段時間要調(diào)節(jié)一次,這個調(diào)節(jié)時間間隔該如何確定基于誤差的調(diào)節(jié)首先是要獲得(測量誤差的大小 , 而實際的誤差是非常小的,對時間差的測量精度要求很高,EtherCAT 是如何做到的以上是標準中關于時延的測量描述。請給出時間戳的具體數(shù)據(jù)描述。延遲測量中 ,主站發(fā)出的獨立幀是否具

30、有廣播性質(zhì),即使用一個幀令所有從站往該幀中填入時間戳主站是如何計算出延遲的,請以圖解的方式描述各個具體延遲。假設整個網(wǎng)絡僅有個從站,若從站的系統(tǒng)時鐘頻率較從站的時鐘頻率低很多 ,從站的系統(tǒng)時鐘頻率較從站的時鐘頻率高很多,所獲得的整個幀中各個時間戳會是什么情況(有無矛盾數(shù)據(jù)產(chǎn)生分布時鐘是EtherCAT 的一個亮點 ,必須給予高度的重視。我認為分布時鐘的成功實現(xiàn)是整個課題中的一個關鍵點 ,對此應搞清楚分布時鐘所涉及到的每一個細節(jié)。圍繞分布時鐘的實現(xiàn),我們應在從站中記錄些什么信息使用些什么硬件器件對于上述的 DL 用戶的本地時間參數(shù) DCuserP,我根本無法理解其含義 ,你知道這些參數(shù)的物理含義

31、嗎以下是標準中給出的一段描述主站對于從站郵箱的讀操作敘述 ,你認為主站讀操作沒有成功嗎真正的操作失敗在何處上圖是標準中給出的從站協(xié)議狀態(tài)機結構圖。狀態(tài)機 ,又稱有限狀態(tài)自動機 ,簡稱狀態(tài)機 ,是表示有限個狀態(tài)以及在這些狀態(tài)之間的轉移和動作等行為的數(shù)學模型。它反映從系統(tǒng)開始到現(xiàn)在時刻的輸入變化 ,轉移指示狀態(tài)變更 ,并且用必須滿足來確使轉移發(fā)生的條件來描述它動作是在給定時刻要進行的活動的描述。有了狀態(tài)機 ,可以很容易地將其轉換為相應的處理程序 ,因此可以將圖中的各個狀態(tài)機與程序聯(lián)系在一起 ,給你一個具體的狀態(tài)機 ,你能將其變?yōu)槌绦騿?,若不能就需要查閱一些相關資料。以后對于狀態(tài)機與程序不進行區(qū)分

32、。請根據(jù)上圖的狀態(tài)機聯(lián)接方式,大體說明整體 DL 層的工作流程。上圖中的 PSM、Port 是處于物理層還是數(shù)據(jù)鏈路層若兩者均處于物理層 ,為什么將它們放在數(shù)據(jù)鏈路層中進行描述又為何沒有畫出物理層與鏈路層之間的接口 (注意 DHSM 一定是處于鏈路層的若兩者均處于數(shù)據(jù)鏈路層 ,那么端口 PORT 該如何理解難道它不是用于與傳輸媒體進行串行數(shù)據(jù)收發(fā)的嗎若兩者 Port 處于物理層、 PSM 處于數(shù)據(jù)鏈路層 ,那么 PSM 就起到了一個協(xié)調(diào)下層端口 PORT與上層 DHSM 的接口作用 ,若如此 ,PSM 如何從下層端口 PORT 的接收數(shù)據(jù)緩沖器中讀到串行輸入數(shù)據(jù) ,又如何將輸入數(shù)據(jù)交給DHSM

33、PSM 如何從 DHSM 獲得要發(fā)送的數(shù)據(jù) ,如何向PORT 輸送該發(fā)送數(shù)據(jù)以上是關于端口狀態(tài)機的描述。上述描述非常不容易懂,我個人的理解是端口狀態(tài)機負責從一個端口接收總線上的通信幀數(shù)據(jù),并將整個幀以字節(jié)為單位逐個傳遞給PDU 處理機 ,PDU 處理機對幀數(shù)據(jù)進行分析處理后,幀經(jīng)另一個端口進行轉發(fā)。在無另一個端口的情況下,幀經(jīng)原端口被回送。上述過程若出現(xiàn)錯誤 ,要進行統(tǒng)計計數(shù)的更新。這種理解不知是否正確我不理解的有: “對于具有個或更多DL 接口的 DL 都分配一個狀態(tài)機 ”,而結構圖中給出的是兩個PSM 狀態(tài)機 ,是不是獨立的端口都應該有一個狀態(tài)機“如果一個端口沒有鏈接Txreq 原語 ,那

34、么將導致一個Rxind 原語。”這些話是什么意思你是怎樣理解上述話語的我的理解是:主站發(fā)送給從站的以太網(wǎng)幀可視作為一個多字節(jié)的字節(jié)流,端口 PORT 采用串并轉換的方式接收字節(jié)流中的每個字節(jié),并存于接收緩沖區(qū)中,PSM負責將接收到的每個字節(jié)逐個上傳于DHSM 。這里有幾個問題 ,PSM 如何獲知端口 PORT中的接收緩沖區(qū)已經(jīng)存有接收到的幀 PSM 是否需要判斷 PORT所接收的幀是否完整 (我認為 PORT 不具有對幀的判斷處理能力 ,其主要功能應是串并轉換 ,對于幀的處理應該在 DHSM 中進行 ,因此 PSM 所起的作用應該是數(shù)據(jù)的上傳與下送 ,即對于端口收發(fā)緩沖器數(shù)據(jù)指針的管理功能DH

35、SM 中是否應該有一個以太網(wǎng)幀緩沖器,其存放的是一個完整格式的幀,這樣 DHSM就可以獲知緩沖器在何時收到最后一個標志幀結束的字節(jié),之后就可以處理該幀。幀處理中的一項工作是從整個以太網(wǎng)幀中尋找到與從站通信地址匹配的EtherCATPDU,將其從以太網(wǎng)幀中取出(這就是上文中的 “在第一個端口分拆以太網(wǎng)幀給單獨的EtherCATPDU”,對其進行解釋處理 ,解釋處理后會形成一個新的EtherCATPDU,將其覆蓋太網(wǎng)幀中的舊EtherCATPDU, 然 后 轉 發(fā) 整 個 以太 網(wǎng) 幀 ( 上 文 “在 第 二 個 端 口ReceiveTime 寫請求 ”。你對上文中的話語是如何理解的上圖中的Txrequest 原語的發(fā)出者是誰接收者又是誰帶有參數(shù)的原語該怎樣在兩個獨立的功能體上具體實現(xiàn)上圖中的 Rxindication 原語的發(fā)出者是誰試舉例說明該原語中參數(shù)的具體值。對于上述話語的正確理解十分關鍵 ,它涉及到具體工作中的功能實現(xiàn)。你是怎樣理解的 “DHSM構成遠程互動和本地內(nèi)存之間的接口 ”,其中的重點是 “接口 ”,接口涉及相互操作的時序配合 ,請給出具體的操作過程描述 “如果端口發(fā)出指示

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論