先說一個結論, 前一個問題是后一個問題的基礎,沒解決前一個問題,就不可能實現后一個問題。
即要搞PLC編程標準化, 一個重要的前提是程序中不要用M和T。實現邏輯的時候,不要使用全局變量的M和T來作為其中的狀態傳遞和功能實現。
M和T的本質是全局變量,這是德系PLC中常用的代號,那么換到日系, 會是D,H等等,以及純標簽編程的,就是人為定義的字符。都是全局變量,都在要避免的范圍內。
如果程序中用了M和T ,那么這個程序就只能用于當下這個項目,當下這個PLC模塊私有,就無法重復使用到以后的項目中,以后的項目中哪怕功能和這里一模一樣, 你也不能直接使用,而是至少要做一些變量的沖突審查。然后3個4個…..100個項目, 只要需要你重新做程序,而不是直接拿一套現成的程序直接下載就是用的項目,都需要審查,調試,都需要你細心不要遺忘。只要遺忘了就要你好看,就會讓你吃盡苦頭。
所以,這兩個問題的答案是同一個,即:痛點。
因為使用中感覺到痛了, 不舒服了,所以就要想辦法找到避免痛的方法,而不是一輩子這么忍著,即便痛點苦點,也這么一直忍下去。
講一個親身經歷的故事。
大約3-4年前,我一直給做顧問的公司,一個工程師辭職了,然后新的工程師還沒招上來,他曾經干過的項目,已經交付運行了1-2年的設備,出問題了。客戶反映某一部分功能不好用,自動運行時設備亂跳。
這個項目,這個類型的設備工藝 ,是他們公司的傳統,其中的主要邏輯, 是我在N年前幫他們做了一個項目后的樣板,后來的十幾年,他們就一直使用我那套樣板改過來改過去的用,已經用到了上百套設備上面了,所以工程師的能力juedui不會有問題,不至于做爛。
因為人手緊張, 老板就求我幫忙跑一趟,項目在天津郊縣,然后我就買了機票直奔天津,到了機場直接租了個車,開過去了。
到了現場,了解了一下具體的功能,故障現象,又問下主事的設備主管, 這個功能以前有沒有用過,是否好用?主管回答設備驗收后一直在用其他的模式,唯獨這個功能從來沒用過,這是Zui近生產計劃改變,才需要用到,然后用了就發現不能用。
然后我就問,全工在當時調試的時候, 這部分功能有沒有驗證過?答:好像沒有。
然后我就明白了。因為這部分功能不是主要的功能,就有可能調試時沒有注意到里面的變量使用,留下了bug。
打開程序, 找到相關的程序塊,順著邏輯捋了一下,再查一下變量的交叉引用,很快就找到了一個使用沖突的M變量。改了一下,再讓客戶開機驗證, 立馬好了。
前后不過半小時。
然而天色已晚,工廠還在遠郊區,客戶給我安排了宿舍, 讓我住了一晚,第二天買了機票回家了。
花費兩天時間,往返機票費租車費近2000元, 就解決了一個M點的疏漏問題。什么叫痛?這就叫痛。
前面的工程師為什么離職?常年出差,常年除了干工程項目,其余的時間就是天南海北沒完沒了處理這些類似的問題?;旧蟻碚f,一年當中,就很少有老老實實呆在家里朝九晚五上班的時間。因為公司的運轉離開了你, 所以也不能給你晉升的機會,所以就只能十幾年幾十年如一日的無限重復這樣的工作。
換誰誰不痛?如果還不能理解其中痛點的,我們接著往下看。
有人會質疑說,這不就是一個粗心的問題嗎,只要小心一點,仔細一點,現場調試的時候別偷懶每一個功能都顧及到,都測試到,就不會出這樣的問題了。
我只能說,這樣的想法太幼稚了。客戶生產系統一旦有可能運行,就會全力保障生產,就沒有機會配合你做全方位調試。如果要調試輔助功能?等條件吧, 十天半個月的,生產有了條件,再給你機會試。然后怎么辦,項目正常的調試也就十天, 你在哪兒再干等10天等條件?像我去天津處理的這個功能,客戶放了快兩年才用得到,才發現。你猜他們會給你機會?
完全細心的人有沒有?有。這位工程師的主管領導,我的徒弟。那就是個非常極度細心的人,比我要細心100倍。他做項目的時候, 每個項目,每個點位,他都要重復4-5遍的審核,校對。多少次不無得意的跟我吹噓,他干過的項目juedui穩定可靠,很少有離開后再次去第二次的。贏得了客戶極大的信任。
然而這其中的代價呢,他媳婦時常抱怨, 為了做項目,他十幾年每天都是熬夜到后半夜1-2點。年紀雖然還不大,然而十多年前就早就滿頭白發了。
這苦不苦,痛不痛?
然而痛點結束了嗎?沒有。
像上面離職的工程師的工作狀態應該是大有人在吧?然后大家工作十幾年如一日,覺得辛苦,就希望老板漲工資,漲一兩次還不行, zuihao是年年漲,每年漲一次,翻倍。這種要求非常合理,可以理解。
然而,站在老板角度, 十年前的你和十年后的你,工作內容是一樣的, 工作量是一樣的,為公司的貢獻也是一樣的,而十幾年下來,市場形勢可能已經逆轉, 采購成本大幅度提高,項目競爭厲害, 拿到項目的利潤已經今非昔比了。簡單說你為公司創造的效益并沒有提高,反而有可能有所減少,十幾年老板肯定已經為你漲過幾次工資了,你這兒還獅子大開口,還不滿足, 還繼續翻倍的要, 老板那兒都想開了你,換個剛畢業的年輕人來呢!人家工資要求可沒你那么高。
你可能會說,切!新畢業的大學生啥都不會,怎么能趕上我一個十幾年工作經驗的老工程師?然而你好像忘了,十幾年前,你也剛畢業,老板重用你,還不是照樣頂下來干到現在?
更何況,前面的設備工藝沒那么成熟,現在早成熟的透透的了,根本用不上這樣富有經驗的dingji高手了。
所以你如果為工資收入感到痛, 老板同時還為你收入高,貢獻不匹配也在痛。如果現在還不痛, 那就終有一天被裁員了,才真的感到痛嗎?
要解決Zui后這個痛點, 可不僅僅是減少bug就夠的。通常在職場上,這唯一的途徑是升職。工作中做出一定的業績,被領導賞識,然后有機會提拔,上升到管理層,就可以極大程度跳離出差長工資低的苦海。然而對大部分純粹的技術人員來說,通常不諳人情世故,因而很難有機會做管理的。那么唯一的途徑是提高自己的工作效率。
比方說, 如果你是車間的車工, 你原本一小時能加工10個零件, 如果你肯動腦,善鉆研,設計一個好的工裝,一小時能加工100個零件了, 不光自己的效率提高了,別的車工使用了你的工裝后,效率也提高了, 這些所有人的提高的效率,都是你的業績。 那么公司為你漲工資提待遇是水到渠成的事。
而對于自動化工程師的工作來說,這個工裝就是程序標準化。而其實對于有機會升職到管理層的,其zuihao的業績也是為公司打造一個標準化體系。
通過建立公司設備程序的標準化體系,可以大幅度的提高工作效率,減少出差時間。
然而很多朋友暫時還沒有能力建立標準化,有些可能連標準化的意思都不知道。我們所指的PLC編程標準化,不是去跑到PLC廠家為他們制定一套通用的標準化工具,直接嵌入到PLC廠家發布的軟件系統中, 從而限制PLC的使用者的編程方式, 以逼迫他們不能任性的使用全局變量, 不能寫垃圾程序,沒辦法寫出低效率的程序, 被逼無奈只能設計出來高效率的標準化程序。
我們所說的PLC標準化編程方法,是指工程師把PLC作為工具, 在所產出的作品,即你的設備程序,使用標準化模塊化的方法搭建而成。如何叫做標準化模塊化, 不是你程序中把功能分成了若干個模塊單元就可以的, 而是這些模塊要能重復使用。即一旦開發完成, 在本公司,本行業將來的大多數項目中,都可以直接簡單使用。
簡單到什么程度?
簡單到Zui高jizhi,完全按照高內聚低耦合的目標,留給組裝環節的工作量只剩下簡單耦合, 這種耦合沒有任何技術含量,任何一個沒有設計基礎的電工,應屆畢業生,辦公室文員,都可以通過30分鐘的培訓,就可以完成。
那么,在Zuijizhi的情況下,一旦對某個工藝設備的邏輯開發成熟,后面的工程就不再需要工程師到現場出差,現場的安裝工人按照設計部門給付的設計資料,稍微整理下裝程序即可。下裝后程序邏輯即可可靠運行, 不再需要試車, 不再需要現場調試。
當然,上面所述是zhongji目標。在zhongji目標達到之前,工程師可能還需要偶爾出差,有可能只是為了到場安撫客戶,讓習慣上看著工程師調試動輒一個月的客戶心理有些安全感。然而這時候的出差,對工程師來說基本上就是商務旅游了, 沒有什么壓力, 去了以后大部分時間也就協調配合。時間也極短,原本一個月兩個月的調試時間, 現在3-5天就完成了。
然后, 原本一個工程師,一年能干5-6個項目的, 現在一年干20-30個也不在話下。而且勞動強度還降低了。這種情況下,這樣的高效率,老板如果不給漲工資, 合天理嗎?
標準化編程方法, 其實不是一種什么思想,他的實現方法很簡單, 4個字, 面向對象。如果懂的人自然早就已經懂了。
然而標準化編程,其實是一種能力。
拿我自己來說, 我在十幾年前就開始研究琢磨標準化編程的方法,然而自己一直沒能全部打通。10年前在S7-300中已經做到了程序中不使用M和T,然而系統還是需要長時間的現場調試,因為疏忽造成的bug顯著減少, 返廠次數少了。然而總體效率提高并不明顯。
這個時候我整體技能還不成熟, 同時也缺少一個關鍵點的推力。然后在5年前開始使用S7-1500, V13, V14, V15。到V15的時候, 突然發現它可以比以前更好的支持面向對象了!然后如開掛一般,除了搞出了S7-1500標準化應用, 甚至還倒回去在S7-200 SMART中實現了標準化架構。
按說S7-200的標準化與S7-1500根本沒有關系。S7-200早就存在了20年,我早用的滾瓜爛熟,為啥之前我搞不出呢, 為啥在S7-300時搞不出呢?還是自己能力不夠嘛!
我在上一個公司上班時,公司別的部門成立項目組要搞標準化,那個時候公司用的是S7-300。我自己既然沒有這個能力, 自然也幫不上什么忙。我認為搞不出,他們也不相信。然后就由他們自己搞了。
上個月, 我問了一下以前的那位同事,你們當年搞的標準化,怎么樣了???
- 圖解西門子S7-1200通訊方式 2024-11-23
- 西門子PLC程序編程wanneng模板 2024-11-23
- 如何將電氣圖轉換為西門子PLC梯形圖 2024-11-23
- 超實用西門子PLC編程算法,電氣人都該掌握 2024-11-23
- SCL與STL的區別是什么?SCL常見問題及解決辦法 2024-11-23
- 西門子S7-1500 PLC的通信基礎知識 2024-11-23
- 教你一個在HMI上顯示西門子PLC代碼流程的方法 2024-11-23
- Wincc與西門子PLC的通訊方式有哪幾種 2024-11-23
- 西門子S7-1500高速脈沖采集功能和應用及數據的處理 2024-11-23
- 西門子博途Modbus RTU通信如何編程 2024-11-23
- 西門子伺服電機速度模式 2024-11-23
- 西門子伺服電機位置控制方式 2024-11-23
- 西門子伺服電機轉矩控制方式 2024-11-23
- 西門子伺服電機通信控制方式 2024-11-23
- 西門子伺服電機模擬量控制方式 2024-11-23
聯系方式
- 電 話:13510737515
- 聯系人:董海波
- 手 機:13185520415
- 微 信:13185520415