自動化工程師未來是不是需要添加高級語言編程的技能?
最近在LinkedIn上交流的人比較多,而且從各種群組裡面,發現許多自動化領域的牛人基本都會高級語言編程。而且將來PLC編程的趨勢我也覺得是向高級語言靠攏,比如PLC程序設計的框架結構都應用起IT類的程序框架。
在面向工業4.0和IoT方面我覺得不應該只是那些雲計算 大數據公司參與,自動化領域的人也應該積極發揮作用,最近在領英上加了一個從工業控制領域轉向雲計算的專業人士。請各位自動化的兄弟們說說你們的意見。更新1/24/2017:沒想到我知乎上的第一個問題有這麼多的關注度和討論,還有@Patrick Zhang 電氣大牛的回答。大家的回答讓我收益匪淺。我是一位在自動化行業有幾年工作經驗的小朋友(因為自己還有很多不懂的自動化知識和技術)。我主要是使用Beckhoff 的PLC(說是PLC,不如說是PC),用的也是IEC61131-3使用的是ST語句,沒有太多接觸傳統的PLC。我現在使用的是TwinCAT2,而以下是Beckhoff TwinCAT3 編程環境,其實就是直接集成到Visual Studio了: 以下是看過某一篇文章的一端摘錄(LIGO,Laser Interferometer Gravitational Wave Observatory,引力波探測儀),當然下面關於C++和Python可能不是是自動化工程師編寫(可能是懂數據處理的工程師):
我們來設想一件事:某企業需要構建全廠的生產過程式控制制系統DCS。企業的決策者認識某高校負責高級編程語言的教學的教授們和老師們,當然也十分熟悉本廠的過程式控制制高級工程師們。那麼企業決策者會把這個任務交給誰來研發?其實答案連想都不要想,一定會交給企業的過程式控制制高級工程師團隊們。對於自動控制而言,最重要的就是控制對象的在物理、化學、傳動、位置、熱工和控制等諸方面的工作特性。如果撇開這些,空談所謂編程,即使知曉了編程方法,但也只是空中樓閣,毫無價值。編程語言是人們為了測控而專門創建的,當然要方便人們的使用。類似地,包括PLC編程,也是如此。因此,如果有任務在身,即使對這些語言絕對外行,但只要通曉了對象的控制方式,並且手邊有編程軟體和系統,那麼編程的執行者就一定能在很短時間內編寫出學生們打破腦袋也想不出來的控制程序。我本人學習PLC編程只用了1個星期,編寫出針對某化工企業生產線中近百台電動機的信息交換和現場測控的PLC通信管理機程序,又用了半個月,編寫了後台電力監控系統的全部測控軟體。在此之前,我對此款PLC毫不知曉。什麼意思呢?
作為學生,不要太過把學習重點放在這些看起來高大上的編程技術上,而是要學好更重要的專業課程,例如自動控制原理、工廠供電技術、工業感測器技術、過程式控制制技術等等。這些課程才具有根本性。
說實在的,我在招聘工程師時,若被招聘對象說他會某某程序編程,而豪不知曉與工作直接相關的各種專門知識和技術,那麼此人是絕對不會被考慮的。同理,若某同事只會編程,而對業務所必須的知識十分陌生,會被大家看不起,個人前途堪憂。==============以上這些看法僅供參考。===============看到知友「無力的西西里安」的評論,覺得有必要來說明一下:第一:這篇帖子其實是寫給學校的學生的,目的是讓學生不要過度沉迷於編寫程序,而忽視了各種專業課。第二:回答知友無力的西西里安對工程人員在實際編寫程序時的若干看法和建議首先,我覺得知友無力的西西里安的看法非常好,並且涉及到工程人員在編寫程序時容易出現的問題。我在工作中,能看到許多德國人、日本人和印度人編寫的程序,當然還有我們中國人編寫的程序。從程序的文本和界面中可以看出有很大的不同。
老外寫程序,有一個傳統。他們認為:寫程序是一種工作態度:編寫的程序不但要能實現它的功能,同時,自己當然要能看懂,別人也要能看懂。因此,程序的完整性和可讀性十分重要。老外,尤其是印度人,他們程序的編寫者,哪怕明天就要辭職離開公司了,但今天還是會認真地把程序給寫完整,並且把程序所涉及到的問題以及前因後果都會以文件的形式留給接續者。反觀我們,我們的工程人員當下寫完的程序,過段時間自己去看,都覺得不知所云。特別地,當某人要離開公司前,甚至把自己能涉及到的東西都清除掉,和老外反差極大。其次,為了實現程序功能,就採取了許多取巧的辦法。但老外不是這樣,他們老老實實按步就班地編寫,該要的都要。看似程序很冗長,但卻十分完整,既便於分析,也有利於程序的實際運行。我覺得,我們真的應當在這方面向印度人學習。第三:PLC當下的語言應當是模塊化的語言體系,不再是梯形圖。事實上,我寫的程序絕大部分都是模塊化的語言結構。見下圖:這是我編寫的程序局部,可以看到程序中有許多說明,目的就是讓自己和他人能方便理解和檢索。這種編程語言是符合IEC61131-3的。
IEC61131-3提出了幾種不同的PLC編程語言,裡面就有梯形圖語言和模塊化的邏輯語言,並且此編程語言體系是全球所有PLC生產商都必須遵守的標準準則。結論是什麼呢?一句老話:編寫程序時要老老實實按規程去寫,切忌取巧,並且做好程序的規範化和可讀性工作,以便日後檢索。需要,特別是對於自動化專業的學生,和自動化工程師想轉職的時候。
首先作為學生,有些知識學校里學不到,有些知識出了學校很難學。自動化專業的學生,我指報考專業為「自動化」而不是「電氣工程及其自動化」或者「機械工程及其自動化」的學生,在學校里很難接觸到繼電器邏輯控制一類的知識。我在學校里接觸器熱繼電器是什麼飛機根本不知道。反過來,等幹上自動化的工作了,再想系統地學習編程,很困難。特別是在學校里基礎沒打牢,彙編單片機一知半解,再要全職或者半脫產學編程難上加難。正規自動化本科出身,學工控,花一個月就能幹活。
再說轉職。搞自動化的人,錢多錢少看公司,事多和離家遠基本都跑不掉。一年到頭在外地出差,工地上摸爬滾打加班調試程序,半夜出事了一個電話打過來屁滾尿流地跑到現場去處理,還要挨罵,不少搞自動化的都有這樣的經歷。同樣是996,我憑什麼非要到外地的工地上去996,不像碼農這樣996了起碼能回家輕鬆一下?當你厭倦了一年365天里300天在外奔波,或者膝下有子含飴弄孫的時候,想換個能常回家的工作卻發現自己只能幹這個了,難道不後悔當初該多學點別的技能?
我就是搞了5年自動化,從底層感測器到上位機都了解,出差出得抑鬱了回去重新讀碩士出來搞SOC和Firmware的人,還是現在好(地主比較舊社會和新中國的趕腳)我的答案是:相比於高級編程語言,數據結構和軟體工程才是值得每個學自動化的學生好好打基礎的。
我本科是自動化專業,也學了PLC,但後期被kernel吸引轉學計算機了。轉計算機之前已經能玩溜單片機編程,也會一些mfc。讓我下定決心轉計算機除了考慮到工資,最重要的原因是:我雖然能用c和彙編寫出完成功能的單片機程序,但寫的很醜也不好維護,寫一些大點兒的項目都是拿之前寫的類似的修改。期間報考了計算機四級,大部分理論都是死記硬背的,但OS和軟體工程這兩部分讓我突然意識到我的程序為什麼丑。
學了軟體工程,在你寫PLC的時候也會幫助你寫出更好的圖。本人從事自動化多年,從最開始的步進,變頻器,plc,hmi,組態軟體,到現在的工業機器人,再到最近的惡補工業視覺主要是halcon和高級語言c#,個人感覺高級語言是個趨勢,也看到行業內的高手基本上都是高級語言+控制器(plc)+傳動+感測器,全能。當然上面所說僅限於應用層面。研發未必。
兩年前上課的時候學PLC用的是梯形圖編程,圖形界面應該算是非常「高級」(離機器碼更遠)了,甚至可以直接看作一個工具而不是編程語言,開發人員已經做好模塊化的工作,用戶只要按照控制邏輯拖模塊就可以了。然而跟 @twincat 說的一樣,這樣的「高級語言」是專用的。題主問的應該是自動化是否需要學C++/Java這類「高級編程語言」中通用的語言,題主如果想做雲計算是肯定要學的,不管是應用還是infrastructure。繼續做工控方面的話,學了至少也可以給新的PLC系統造輪子。題目描述里提到的「比如PLC程序設計的框架結構都應用起IT類的程序框架」,因為現在不怎麼接觸PLC了不知道具體指什麼。不過語言其實是次要的問題,控制理論(對工業控制來說)、數據計算引擎/存儲模型(對雲計算來說)這些還是更重要的東西吧。
PLC語言本身也是一類高級編程語言,只不過是專用語言,底層也是C或C++實現。自動化專業本科的必修課里有高級編程語言,因此控制領域的從業人員會C, C++, JAVA都很正常。技能樹上加上編程能力當然是好的,現在高級的plc編程環境已經加入了C, C++編程的功能了。至於雲計算,智能製造,我感覺實現是早晚的事,但是現在不成熟,炒作的成分仍比較大。
作為一名合格的自動化工程師,高級語言可以說是必備的。所以結論就是,必須會。一般是c/c++/c#。
自動化這個概念太寬泛,你說的PLC主要應用在工控領域,實際上PLC並不怎麼高端,很多培訓機構專門培訓PLC編程。工控主要在於整個控制系統的規劃,圖紙設計,圖紙出來以後編程還是比較容易的。工控領域涉及到上位的時候也是需要高級語言如c#等來實現對PLC及其它設備的監控。如果只會PLC,基本沒什麼競爭力。
其他領域,高端點的,如機器人運動控制,這會涉及到控制理論,涉及到演算法以及c/c++等高級語言。
另外,自動化實在是太寬泛了,基本上所有和設備相關的涉及到控制的都和自動化沾邊。
比如智能家居,機器視覺,物聯網,還有一些嵌入式行業都會涉及到高級語言編程。很多高校的自動化必修課是有編程語言學習的。如果還是學生的話。奉勸一定要學點。
學演算法的:labview,matlab,python做界面的:c#,html三件套做單片機的:c,linux,vhdl學校的任務是面相未來需求,不會點開發工具怎麼迎接未來的技術更新浪潮。即使不專精也沒關係,今日入個門,他日好相見。
PLC面相快速開發,面向現場工程,用到了再入門,難度不大。結合本人的職業經歷來講,一開始是PLC入門,熟悉現場匯流排,串口通信,感測器技術,RFID,以及附屬和PLC相關的運動控制,視覺等知識。PLC是大腦,PLC語言只要符合IEC61131-3標準就行。我經歷的PLC也不少,beckhoff,mitisubish,phoniex contact,bosch rexroth,schneider electric.
PLC重要是設備的軟體框架模型,這個在大公司裡面是很完善的。標準化是很重要。後來設備複雜後,都是PC+PLC混合控制,PC負責數據採集處理分析,PLC負責人工交互操作,動作實現,錯誤處理。PC基於Labview平台。PC和PLC基於開放協議或者OPC,這樣就慢慢進入工業互聯領域。NI的平台也能做很大的項目。包含MES等,只不過C+,Visual studio更開放。
在設備控制系統這款就積累了很多的經驗,然後往設備項目管理上面轉變,技術+項目管理是一個不錯的發展路徑。plc作為自動化行業行業最基層的邏輯判定和處理機構,這個角度的功能定位,大方向來說很長一段時間都是這樣,高端大型的plc會逐步融合一些高級語言模塊來更好的融合到pc端,讓更優質,更時實的生產數據在資料庫得到積累,沉澱,方便後續質量的持續提高和生產過程的進一步優化,簡單來說,pc端把plc生產過程中產生的數據(溫度,壓力,時間,亮度等物理信號)加以分析處理,生成產品生產有用的數據模型,在更短的時間裡,做出很好的產品。概括來講:pc負責提煉數據,分享數據兼顧人機交互的部分,plc負責產生數據,又反過來利用pc產生的數據。之前用的plc.後來梯形圖開始模塊化編寫的時候,程序編寫已經變得相對容易了,學好一門高級語言給人的感覺是很多控制部分的知識不在是孤立了,plc也只是應用層的一個執行元件,和伺服,變頻器,機器人的功能差不多,都是解決某個問題環節的一個器件!
真正的自控工程師,什麼語言都是小菜一碟
先說說我們公司現階段的自動化情況吧。據說作為佔Intel各類網卡80%份額的代工廠,從smt貼片開始,到測試、包裝、出貨等整個生產流程自動化機器的參與率佔到90%,從之前公司購買機器,到後來的成立我們自動化部門自己做機器,到現在自主研發的機器已經中大規模替換掉了之前購買的機器了。 作為一名自動化軟體工程師,主要就是按照公司流水線各個站別的生產要求,寫出符合邏輯,人機交互友好且穩定可靠的機器運動程式。我們的大型機器現在都是以運動控制卡來作為運動控制核心,結合vc++,C#和qt等高級語言來作pc端軟體開發。外圍的小任務還是輔以plc來控制,總的來說運動控制卡配合pc來做自動化軟體越來越成熟可靠了,而且現在我們的機器都是要和公司的shopfloor系統相關聯,事實監控每顆產品的情況。
從寬泛自動化看,有必要,特別是大風口人工智慧和物聯網,不管是雲端、pc端還是終端端,都需要高級語言支持的演算法實現和系統開發。雲端和pc端太多了,python,go,java;終端端鑒於資源問題,目前仍然只有c++,rust有可能。
PLC應該歸為DSL的一種,工控用的較多,面向用戶和功能開發人員為主。梯形圖、ST中支持OO錦上添花,但順控類的邏輯控制還是過程化編程更切合。不排除以後PLC應用的更廣,語法更高級智能,數據挖掘、雲端交互都由PLC一個搞定,那還是稱早學吧。現在的plc程序已經向高級語言靠近。像CoDeSys ,很多廠商用它來做編程軟體底層。很多廠家支持的結構化文本(ST),與高級語言相近,有面向對象的特性,有繼承,方法,屬性,介面,功能塊,函數等,方便了程序的編寫。學習一下其他編程語言也是有必要的,至少拓寬了思維。
您好,我也做Beckoff的plc的,正在學習ST語言,有時間我們討論一下哦WeChatnumber18351986989
單純的自動化控制,IEC61131裡面描述的幾種語言以及足夠了。例如歐姆龍plc裡面主要使用梯形圖,遇到複雜的演算法時用st,基本上已經可以應付絕大部分情況了。但是如果考慮更多的情況,比如說上位機的話,懂點vb,c#,labview之類的肯定比只會用組態軟體好。有些控制要考慮降低成本,可以考慮用c語言配合單片機,。有些控制比較簡單,但是速度要非常快,比如說微秒級別的控制,可以用單片機或者fpga來做。甚至還有一些需要將數據傳到資料庫里的要求,最好還是懂點sql之類的語言。但是我在招人的時候發現,大部分搞plc控制的工程師,很少懂高級語言的,也許是懂高級語言的都去從事IT行業了吧。
非標自動化行業編程一直缺少系統性標準,自由發揮的風格更佔主要。都覺得梯形圖挺簡單的,所以會存在短期了解後就能編出想要的控制效果,其實離真正的精通還是挺遠的,這也是非標這個行業的現狀,精品的很少。有想法完全可以追求「整個控制系統在技術水平上達到了藝術級別」,畢竟人的需求是在求變的。
「PLC程序設計的框架結構都應用起IT類的程序框架」。最新的PLC框架模板都是按照IEC6113標準來做的,已經有應用了,框架對應面向對象(也不是說就是完美的),模塊化,這樣的模板針對自動流水線設備可以說是萬能的,降低應用門檻,只要簡單會操作就行。所以今後我們的工作也許就是熟悉工藝流程、熟悉執行機構,剩下的就是交給電氣IT,完善各種底層程序框架,對現場維護進一步降低要求了,也許會對行業起到促進作用。
打一個很不恰當的比方。PLC好比是任勞任怨的老工人,可靠性強工資低,但學習能力不行操作不了太複雜的運動。你讓老工人去適應時代學習新技術,為什麼不聘請單片機,解決工作環境導致的可靠性問題就行。PLC原本就是為了簡單控制而存在的,簡單穩定上手快就是優點。為什麼要PLC拋棄優點去做不擅長的事呢?知識壁壘還純粹就為了炫技?
這麼說吧,工作中用到了plc用了一周學會了,個人愛好電子,做點小東西,c語言花了一個月重拾(大一學過半年),做好了硬體,得有軟體啊!用了一個月自學了c#,算是入了門。所以軟體編程結合硬體,再加上愛好進步神速,打好理論基礎,編程用到時很容易學會,不過精通比較難。
自動化工程師用到的比較多的計算機語言是VB6.0,C#和資料庫,主要用在畫面製作,寫通信介面程序,組態軟體腳本,編寫報表軟體等。
直接用io讀取感測器高低電平,io置高置低控制電磁閥。
推薦閱讀:
※什麼是智能製造?如何發展?
※Rv減速器和諧波減速器的區別?
※工業3.0是自動化信息化,4.0是智能化、物聯網。中國還未實現3.0,能彎道超車實現4.0嗎?3.0和4.0核心區別是?
※量子計算機會不會是下一次技術革命的突破口?
※德國工業4.0和中國製造2025有什麼區別?