Dumbcat's Note

NPort是MOXA旗下的序列設備伺服器(Serial Device Server)， 主要的功能是提供序列設備與各種網路連接的能力，無論是乙太網路、無線網路、甚至行動網路； 在現今常見的網路通訊與傳統的序列通訊之間，NPort在其中作為伺服器的角色為雙方提供服務，使雙方發送出的訊息經由NPort的處理之後，可以正確的傳送到另外一端。 Benefits of NPort 作為工業自動化的基礎設備，NPort以工業等級的硬體規格，提供了諸如寬溫、突波保護、訊號隔離等功能，強化在惡劣環境中，NPort穩定運行的可靠性；除此之外NPort也提供了許多軟體功能，讓NPort在使用上更便利、更彈性，也提供更穩定的資料傳輸能力。 Host Reliability Maximum Connection允許多達8台(NPort 5000系列支援4台)備援主機同時自動接收序列數據，可以確保資料傳送到所有備援主機中。 Command by Commande(NPort 6000系列)允許多台主機同時發送命令與接收序列數據，可以讓不同主機可以同時各自存取相同設備中的資料。 Network Reliability MOXA的Turbo Ring網路備援也支援NPort系列(NPort 6000、S8450系列)，提供小於20ms的網路快速復原機制，確保資料傳輸的穩定。 NPort在硬體介面上提供了Dual-LAN的規格(NPort CN2600系列)，雙MAC與雙IP提供使用者無論是在同主機或不同主機的備援上有更多應用彈性。 Device Reliability COM Grouping(NPort 5000、IA5000、IA5000A、IA5000AI-M12系列)可以將不同NPort的序列埠綁定為單一個序列埠，讓主機可以一次對多個序列設備傳輸資料，也避免多次相同的設定來加速部屬設備的時間。 NPort支援基於UART的軟體流量控制，識別序列設備的流量控制訊號，給予序列設備足夠的緩衝時間來處理資料。 Data Buffer(NPort 6000、CN2600、W2X50A系列)可以在主機端網路斷線時，將序列設備送出的資料暫存，等到主機端連線恢復後再將資料送出。 Module of NPort NPort相關的型號

這篇文章是在完成 MDN的Django課程 後，將Django專案佈署到Raspberry Pi 3 B+的Apache伺服器的步驟紀錄；如果有任何疑問、錯誤，歡迎留言討論。 Environment Development Deployment Windows 10 ver 1909 Python ver 3.8.3 Django ver 3.0.7 virtualenv ver 20.0.23 whitenoise ver 5.1.0 Raspberry Pi 4.19.118-v7+ apache2 ver 2.4.38-3+deb10u3 libapache2-mod-wsgi-py3 ver 4.6.5-1 Python ver 3.7.3 Django ver 3.0.7 virtualenv ver 20.0.23 whitenoise ver 5.1.0 Directory Structure 下圖是開發環境與佈署環境的專案目錄結構，圖中並沒有將所有檔案列出來，只有配合文章列出一些定位用的檔案；因為在開發環境與佈署環境中，目錄結構有一些變動，所以加上紅色斜體字輔助說明資料夾的用途。 Deploy Step 在開始佈署前，Django本身有個很好用的 deployment checklist ，可以檢查整個專案中重要的設定，包括安全性、效能、以及操作性，尤其當網站是要佈署到網際網路時，要特別留意安全性的部分；在開發環境下輸入這行指令來檢查專案的設定。 python3 manage.py check --deploy Step 1 首先要在佈署環境上安裝virtualenv，然後建立並啟動一個虛擬環境；Raspberry Pi本身有Python 2.7與3.7兩個版本，安裝時要安裝在專案使用的版本中；這邊是使用3.7版本，所以以pip3來安裝。 pi@raspberrypi:~ $ sudo pip3 install virtualenv pi@raspberrypi:~ $ cd DjangoProject pi@raspberrypi:~/DjangoProject $ virtualenv -p python3 venv pi@raspberrypi:~/DjangoProject $ source

Introduction IEX-402 Series IEX-402系列 是MOXA推出的乙太網路延伸器，基於 G.SHDSL(single-pair high-speed digital subscriber line) 與 VDSL2(very-high-bit-rate digital subscriber line 2) 標準並使用雙絞銅線為媒介，以點對點的方式延伸乙太網路線路；IEX-402-SHDSL支援G.SHDSL標準， 最高有15.3Mbps的傳輸速率以及8公里的傳輸距離， IEX-402-VDSL2支援VDSL2標準， 最高有100Mbps的傳輸速率以及3公里的傳輸距離。 IEX-402系列可以讓相距超過100公尺的乙太網路設備，利用如電話線路之類的既有線路，透過 DSL(digital subscriber line) 技術延伸乙太網路的通訊距離；在設定上，IEX-402系列主要DSL通訊設定都是透過設備外的指撥開關(DIP switch)進行設定。 DIP Switch Settings IEX-402-SHDSL有4組開關，IEX-402-VDSL2則有3組開關，如下圖所示；除了第一組指撥開關之外，每對IEX-402系列的其餘指撥開關設定都必須相同，如此才可以正確的建立連線。 1st DIP Switch：CO/CPE IEX-402系列在使用時需要指定其中一端為CO (central office)，並與另一端為CPE (customer premise equipment)的設備配對運作；在DSL架構中，CO代表著服務端的設備，如 DSLAM(digital subscriber line access multiplexer) ，CPE代表用戶端的設備，如家中ADSL的數據機；然而，IEX-402系列是點對點的架構，線路的兩端無論誰是CO或CPE都不會對通訊有所影響。 預設IEX-402系列設備皆為CO，當兩端設備都設定為CO時，IEX-402系列的自動協調功能會在建立連線時，使其中一台成為CPE；使用者也可以手動指定CO/CPE來略過自動協調的過程，加速連線建立的時間。 在自動協調CO/CPE的設定中，依據線路的品質條件，從設備啟動到連線就緒需要70秒到6分鐘，若使用手動指定CO/CPE，可節省大約20秒到

Case Brief 客戶現場以1台PLC作為Master，以RS-485串接的方式向另外2台Slave的PLC發起通訊，並利用MOXA NPort W2250A的Pair Connection Mode，將RS-485的實體串接線路轉換為無線通訊，架構如下圖所示；Master PLC的NPort W2250A的Port 1會與Slave 1 PLC的NPort W2250A的Port 1建立Pair Connection，Master PLC的NPort W2250A的Port 2會與Slave 2 PLC的NPort W2250A的Port 1建立Pair Connection，而RS-485訊號線則是在Master PLC的NPort W2250A進行串接。 在這個系統中，Master PLC的工作是輪詢Slave PLC的DI點位狀態，並將其ON/OFF狀態寫到自己的DO點位，這是種常見於工控領域中遠端設備控制的應用，例如當現場的設備產生告警時，要同時觸發遠端的中控室的蜂鳴器或警示燈；或者是透過控制端的介面，遙控遠端的機械設備； 這類型的應用除了系統的穩定度之外，反應的即時性也是客戶在乎的重點。 而在這個案例中，系統經過半天到一天的運作後，Master PLC的反應會越來越慢，當Slave PLC的DI點位改變時，Master PLC需要好幾秒鐘的時間才會作動，造成操作人員無法準確的操作機械，對於客戶造成很大的困擾，這個系統也可以說是完全無法使用。 Cause Analysis 在了解問題與系統架構後，歸納出兩個需要測試釐清的重點：第一是PLC的程式是否正常，第二是無線通訊的品質是否良好；先以實體線路串接三台PLC，經過幾天的連續運行後，並沒有出現反應變慢的情況，據此可以斷定PLC的程式是正常的。 接著加入NPort W2250A進行測試，嘗試調整NPort W2250A的無線與序列通訊參數，以及將NPort W2250A改為使用乙太網路的NPort配合其他無線設備，經過多次的交叉測試，確認在無線與序列通訊品質穩定的條件下，依舊無法改善反應變慢的情況。 根據上述的測試得知， PLC的程式是正常的，而在NPort W2250A的無線與序列通訊的品質良好的情況下，只要透過NPort W2250A連接就會出現問題； 這樣的結果意味著，

ioLogik 4000系列是MOXA早期推出的模組式I/O，最高支援32塊模組(除E4200僅支援16塊模組)，提供乙太網路(NA-4010、E4200)、RS-232(NA-4021)、RS-485(NA-4020)的介面，支援Modbus RTU/TCP通訊協定；使用模組式I/O的好處在於可以照自己的需求，選擇DI、DO、Relay、AI、AO、RTD、TC模組進行搭配，以及在乙太網路中節省IP位址的使用，在序列通訊中節省輪詢的時間，並且將大量的I/O資訊，用較少的通訊次數全部獲取。 在Modbus位址的排序上，因為模組式I/O無法預測使用者會使用多少模組，所以Modbus位址會依照使用者使用的模組的數量與通道數而改變；原則上Modbus位址的排序都會有固定的邏輯，例如銜接上一塊模組的位址繼續往下排，或者每塊模組固定占用多少個Modbus位址等方式。 Environment 可能因為ioLogik 4000系列是早期的I/O設備，並沒有針對這部分的設定做一些user-friendly調整，導致某些模組的組合，會造成Modbus位址讀取到的數值與I/O數值不相符的問題，須要透過特別的計算方式，或者改變模組的組合方式，才可以讓該Modbus位址直接讀取I/O數值；測試中以ioLogik NA-4020為例，並依序銜接下列四塊模組： M-2801，8 DOs，24 VDC，0.5 A，source type M-1801，8 DIs，24 VDC，source type M-3411(已停產，今以M-3810取代)，4 AIs，0 to 10V，14-bit M-4210(已停產，今以M-4410取代)，2 AOs，0 to 10 V，12-bit Test 透過ioAdmin Configuration Utility連線NA-4020後，確認正確抓取到四塊模組的資訊，並且以Export System Configuration匯出設定檔，將設定檔開啟後可在檔案的最後方看到所有模組的Modbus位址， 其中會發現第一片DO模組與第四片AO模組第一個通道都使用了0x0800的Modbus位址， 但DI與AI模組卻沒有相似的狀況產生。 同時也測試AO輸出的最大RAW值為4095，二進位為1111 1111 1111，使用12 bits，與

Case Brief 客戶的機台中安裝了MOXA DE-308，將機台內部的RS-232訊號透過網路傳送到電腦，來監控機台的運作狀態；時隔多年DE-308已經停產，客戶為了後續機台的維護，確保DE-308故障時有其他設備可以替代，希望以用現在的 MOXA NPort 5610-8 取代DE-308。 Cause Analysis DE-308是MOXA過去的8埠Serial Device Server，可說是NPort 5610-8的前身，兩者都是將序列通訊轉為乙太網路通訊的設備，除了一些設定細項不同之外，軟體上兩者主要的差異在於建立序列埠映射的驅動程式不同；DE-308使用NPort Pro Manager建立COM Port Mapping，現在的NPort系列則是使用NPort Administration Suite或Windows Driver Manager建立COM Port Mapping。 而在硬體的部分， 過去的Serial Device Serve若是使用 Registered Jack 的介面，大都是10P10C的RJ50接頭， 而現在的NPort系列使用的則是8P8C的RJ45接頭；這樣的差異說明了這個案例中最重要、也是最基礎的問題，是序列通訊的腳位是否連接正確。 Solution 根據網路上DE-308的手冊可得知RJ50孔座的腳位，如下圖所示，其中與通訊重要相關的是第4(GND)、5(TX)、6(RX)、7(GND)腳位。 機台商使用8P8C的RJ45接頭的自製線路連接到DE-308，8P8C的接頭可以插入10P10C的孔座，只是10P10C的孔座會多出左右各一根的接腳，但不影響通訊；根據客戶提供的文件資料，RJ45的第4、5、6腳位分別為RX、TX、GND，確實對應到DE-308的第5、6、7腳位；這驗證了客戶提供的文件的正確性，同時也確認機台只需TX、RX、GND便可以通訊；所以根據目前的資訊可以歸納出現行的接線圖。 測試當天現場使用 NPort 5210 進行(NPort 5610與NPort 5210的RJ45腳位相同)，根據手冊可知RJ45孔座的腳位如下圖，其中與通訊重要相關的是第3(GND)、4(TX)、5(RX)腳位。 根據先前腳位的資料可以確認，若將機台8P8C的RJ45直接接入NPort

Case Brief 客戶現場的設備透過PLC接收數值來進行監控，而設備會隨著案場在不同地區移動，所以客戶希望透過行動網路(GPRS/HSPA/LTE)，讓遠端的OPC Server可以存取現場PLC的數值，相關人員便可以不必跑到現場，透過OPC Server與SCADA的來即時監控現場設備的狀態。 Cause Analysis 有類似需求的客戶其實很常見，許多案場的通訊並不方便，例如偏遠的山區、新建的廠房、或著像案例中不固定的場所等；以目前的通訊技術發展，可以選擇的除了一般手機使用的行動通訊之外，還有 LPWAN(LTE-M/NB-IoT) 、MDVPN、以及其他可以遠距離傳輸的無線技術(WiFi、Microwave)等。 然而每種不同的技術都有其優點與缺點，必須依照現場的需求與可用的資源審慎評估；LPWAN是近代專為物聯網設計的通訊技術，但因為還處於發展階段，在相關設備與環境上還沒有達到穩定的階段；MDVPN使用上與一般的行動通訊相同，但是申請的過程與設備、環境的需求每家ISP商可能不完全相同，以及流量資費的計算上需要精打細算一些；WiFi、Microwave這些遠距離的無線傳輸在硬體上的花費很高，而且距離最遠也只能在幾公里以內，後段可能還是需要依靠實體的網際網路來實現遠端存取。 行動網路申請與使用上相對方便， 最大的問題在於設備使用行動網路時，無法取得固定的Public IP位址； 如果設備是向遠端主機主動拋出資料，只要遠端主機有固定的Public IP，這樣影響並不大；但如果設備是被動等遠端主機來存取，就必須思考如何解決浮動Public IP位址的問題。 Solution 對於客戶的需求，規劃的架構如下圖；PLC以乙太網路連接 MOXA OnCell G3150-HSPA ，並連上網際網路，遠端的OPC Server便可透過網際網路向PLC存取數值，而後端的SCADA經由OPC Server監控設備的狀態。 補充說明一點，規劃當時因為LTE尚未普及，沒有相關的OnCell設備可以使用，至今MOXA有推出 OnCell G3150A-LTE ，也可以完成同樣的架構，與OnCell G3150-HSPA在設定上需要注意的部分會在後文中說明。 在這個架構下會衍生兩個問題，測試的步驟會依這兩個問題分為以下兩個階段： OPC Server與