.net全棧開發-c#面向對象與工控自動化分揀上位機

1、前言

開始作了兩年web、期間也整了一段時間winform。後來作了兩年工控上位機，也就是作工控這兩年發現機器跟面向對象真是如此貼切，也是我從處理數據和流程的思惟轉變爲面向對象思惟的開始。這對我後來學習mvc五、owin、.net core以及其它各類框架的學習有很是大的幫助，我發現我能看懂源碼，也能理解這些大牛爲何要這麼去設計這些類，這些類是如何協同工做去實現一個複雜的可擴展的框架，由於這些框架、設計模式最最根本仍是以面向對象的思惟來處理具體場景的具體問題。這一瞬間有一百萬種可能，轉變思路也許就在一瞬間。

本篇以一個機器上的一個組件來聊下面向對象這回事。以及c#開發工控是多麼的方便，其它方式我不咋懂，大概曉得有MFC/QT/PLC之類的

2、案例

動態稱重魚分選機

視頻：案例視頻

初代版本，雖然看着挺low，可是功能性和效率仍是挺高的。分揀效率150條/分鐘 精度±0.5g，帶按數量或重量自動分包功能

功能：人工擺魚上料，通過稱重臺稱重，上位機實時獲取重量計算獲得魚的重量，根據設置決定應該分揀到哪一個料斗。上位機程序發送開關量指令控制分選。

物流包裹分揀系統

視頻：案例視頻 視頻沒拍全

功能：人工上包裹，通過掃碼、稱重、 由上位機將條碼發往海關接口 ，海關返回包裹狀態，由上位機根據狀態控制分揀設備進行分揀

別人家的是視頻，可是看樣子不如咱們公司的，咱們分揀速度比它快，並且是雙邊分的

2、面向對象在自動化設備中的應用

 

 

 

 

 

省略掃碼、稱重、API請求等步驟，咱們單單來看看這個分揀機部分，從圖中咱們能夠看到有包裹、光電、分揀機。
包裹一個接一個從左往右傳輸，包裹之間有必定間隔；
包裹觸發到紅外線（光電）時，程序就知道包裹的狀態了，此時程序根據包裹狀態控制分揀機進行左分揀/右分揀 仍是流向下一個分揀機

流程和功能很是簡單，如今想一想你會怎麼來實現.......

問題來了，公司考慮成本，和機器不斷改進，不管是結構上仍是選用的設備上均可能不斷變化
包裹狀態是根據條碼和重了發到一個api接口，有接口返回狀態的；接口某些客戶可能本身公司給你提供了，也有可能要你直接調用政府部門給的那個
光電傳感器可能會用不一樣廠家的，有時候能夠將光電接到主機上，有時候須要一個輸入輸出模塊
分揀機控制往左分、右分、直行 可能直接用開關量，也可能用伺服電機，若是用開關量可能直接連電腦或中間加一個輸入輸出模塊，用伺服電機可能廠家也不同

如今再思考下，這些要求合理嗎？你會怎麼作？

面向對象的思想來講就是每一個東西對應一個對象，變化地方用接口隔離
包裹類：

條碼、重量、狀態、等熟悉；
當狀態變化時觸發、當條碼被賦值時觸發、當重量被賦值是觸發等事件；
相關方法...
固然仍是涉及到對象的轉換問題，由於機器檢測到衣蛾包裹，軟件界面上要有個方塊或包裹圖片顯示出來，包裹在機器上傳輸時界面也要有體現，包裹的各類狀態觸發時也要有體現；主要使用c#的委託、事件和多線程來完成

光電：

將它定義爲一個抽象類或接口，由於它內部包含一個通信接口，好比某些時候咱們用的輸入模塊來做爲信號採集，那麼咱們同窗組件要有一個實現類，某些時候咱們是經過工控電腦直接連的光電，就直接調用win32API。可是對於咱們光電類，它只要關心獲取當前光電狀態就好了，不關心到底經過什麼樣的方式去獲取
光電有個線程一直在獲取狀態， 當發現狀態變化時觸發相應的事件就好了。這樣咱們的光電可能被多種其它機器結構來使用，並且能應對通信方式變化的狀況
屬性包含：當前狀態；方法包含：開啓監聽、事件包含：中止監聽等方法；上升沿事件；降低沿事件；（就是光電從被擋住到沒有被擋住的事件，裏面包含這個狀態變化的時長）

分揀機：

分揀機的主要工做是當光電觸發時從包裹隊列去除第一個包裹，檢查狀態，調用通信模塊發送指令。所以它內部包含一個光電對象，並註冊光電的相關事件。關於通信又得作成接口，以應對不一樣的控制方式

3、總結

哈哈，觸不及防的總結。由於不想寫了。總之就是這個場景，若是你來作會怎麼作？思考下把機器的各個部件都定義爲類，會怎麼樣，整個機器哪些地方會可能變化，類與類之間儘可能用組合，界面與這些機器對象如何保持同步。

這樣設計出來的上位機控制程序，相比PLC仍是有極大的優點，至少應對變化，好比換另一種機器，你的大部分組件可能均可以複用。

咱們的思想被三層機構坑了，看了太多的分層業務邏輯要麼在aspx.cs裏 要麼在controller裏，要麼在dal裏 還有不少車主存儲過程裏。若是你考慮下全部對象都在內存裏，不考慮持久化，也許更能理解。

我TM寫了些啥...