加入收藏 在線留言 聯系我們
        關注微信
        手機掃一掃 立刻聯系商家
        全國服務熱線13185520415
        公司新聞
        為什么PLC程序中不要用M和T,而是需要PLC編程標準化
        發布時間: 2023-12-08 10:33 更新時間: 2024-11-23 08:00
        觀看為什么PLC程序中不要用M和T,而是需要PLC編程標準化視頻

        先說一個結論, 前一個問題是后一個問題的基礎,沒解決前一個問題,就不可能實現后一個問題。

        要搞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。我自己既然沒有這個能力, 自然也幫不上什么忙。我認為搞不出,他們也不相信。然后就由他們自己搞了。 

        上個月, 我問了一下以前的那位同事,你們當年搞的標準化,怎么樣了???


        聯系方式

        • 電  話:13510737515
        • 聯系人:董海波
        • 手  機:13185520415
        • 微  信:13185520415