你的設備你做主

admin

大家有沒有遇到過這樣的客戶，初期方案討論時侃侃而談，把設備的動作講得一清二楚，但是當你按他講的東西披星戴月的做出來後，他覺得這個要改、那個要調整，今天要增加一個步驟，明天要增加一個產品，三天兩頭改工藝。甚至有些人自己對具體的操作的步驟都時雲裏霧裏的。在下不幸，就遇到了這樣的客戶。

遇到這樣的客戶怎麼辦？每當他靈光乍現的時候，你就跑現場去改程序嗎？一次兩次的，想想客戶是上帝，就幫他改一下吧。可他客氣當福氣，沒完沒了的給你打電話，你還去嗎？其一是費用問題，這跑一趟可能無所謂，跑多了花下去的成本就可觀了。問客戶要吧，客戶的臉色立馬由晴轉陰，總覺得你在訛他，搞不好背地裏在你老板麵前說你幾句不陰不陽的話。其二是領導那裏怎麼交代？要知道領導都不追究細節的，隻會認為你的水平有問題，現場去了這麼多次還沒解決問題，下次的獎金和調薪可就懸了呀。

我們自控人當然用技術征服客戶。隻要做到客戶自己能夠隨意改工藝路線，想讓設備怎麼動作就隻要在觸摸屏上點點就好了，豈不兩全其美？所以最終方案就是做一個工藝路線的組態程序。

做這樣的程序當然要用麵向對象編程，分析好係統中的類和對象，最好用數組的形式建立對象，便於程序上的處理，而且可以適當的增加數組長度，以防客戶將來增加硬件，到時候軟件就不需要再改了。如果使用S7-1500的plc，則可以用數組數據塊，數組長度就是可變的了。除了完成每個對象固有的編程之外，還需要完成一個“工藝對象”的編程。

首先，對於每一個控製對象，列出所有的動作，通過對一個“指令”變量賦值，就能讓它執行相應的動作，例如一個閥對象的指令有開閥和關閥兩個，可以分別定義為“1”和“2”，再加上保持原來狀態的指令，定義為“0”。對於每一個檢測對象，則列出所有的狀態，還是以閥為例，其狀態有“全開”、“全關”、“正在開”、“正在關”、“故障”，5個狀態，分別用1~5來定義。對於模擬量則需要離散化，比如要設定幾個區間，或者定義一個運算過程，按運算結果來定義狀態。此外，考慮到某一個檢測對象的狀態與某一步工藝無關，所以所有檢測對象都還有一個“不相關”狀態，也用”0”表示。

然後，把每個對象的狀態和指令彙集成整個係統的狀態集和指令集，即為所有對象的狀態和指令的組合。把狀態集和指令集分別定義在兩張表中，並給每個狀態和指令指定一個不可重複的序號。這兩張表可以自動生成，優點是編程簡單，缺點是可能浪費存貯空間、程序執行效率低。也可以人為逐條添加，優缺點則和自動生成正好相反。

接著還需要一個工序表，定義每一道工作步驟要進行什麼樣的操作，既執行哪一條指令。

最後再建立一個工藝表，定義每一道步驟執行後各種可能的狀態下所對應的後序步驟，如果後序步驟為空值（實際用零表示）則表示該步驟為最後一步，所有工序執行結束。

至此，完成了一個小小數據庫的設計，如圖1所示。

這些表在博途中全部以UDT的數組（或數組數據塊）形式建立。由於這些表都需要添加、修改和刪除一條記錄的操作，所以可以定義一個表的通用函數用於這些操作,用Variant數據類型作函數的輸入輸出接口。需要注意的是，對指令表的刪除操作需要先確認工序表中是否有使用該指令的工序，如果有就不能刪除該指令。否則將來執行相應工序時，就不知道要做什麼了。同理，對狀態表的刪除操作也需要在工藝表中確認。

程序執行時，先從工序表中調入第一條工序作為當前工序，並按當前工序對應的指令序號在指令表中找出相應的指令進行操作，操作完成後，將設備的當前狀態與狀態表中的記錄比較，找到對應的狀態序號，然後用工序序號和狀態序號在工藝表中找出後續工序序號，將後續工序序號賦值到當前工序，如此循環直到後續工序為空值。下圖展示了程序的偽代碼。

按此思路完成PLC程序和hmi的設計就萬事大吉了，剩下的事就可以交給客戶自己去折騰了。且慢！還漏了重要的一件事：教會客戶怎麼在HMI上操作??（後期就電話遠程指導吧）。

有的時候一套設備可能會用於不同的產品，那麼隻要多建立一張產品表，把產品和該產品的首道工序聯係起來就可以了，如圖2所示。但是需要注意的是，即使工序的指令是一樣的，但是隻要是不同的產品，就應該定義不同的工序序號，除非所有後續工序和工序切換條件都是一樣的。