Re: [心得] PLC 過往工作及最近面試

作者: snaken (snaken)   2017-10-21 01:31:30
難得有人想要討論這一個問題,這邊也來分享一下小弟的看法。
其實在伺服控制裡面,控制脈波與編碼器回授脈波兩者是有關係的
在位置環控制中的第一件事就是
(控制脈波) x (某個倍率) - (編碼器回授) = deltaP
dP 之後才開始處理位置增益之後的速度環、電流環
這個不知所以然的 (某個倍率)被某個偉大的前輩構思出了 "電子齒輪比" 這個概念
這東西的目標,其實就是希望使用者把這個值後面的東西都當作一個黑盒子
畢竟大家是用伺服的人,不是開發伺服的人,把自己的人生搞那麼複雜做甚麼呢?
以現狀來說,我們通常就是跟客戶講說:
阿你就看馬達轉一圈,載台走多少填進去就對了
(對不起我們就是那種亂教的人....)
然後默默的三菱還真的設計了參數只要填螺距一個參數即可....
我也不是沒有遇過真的有興趣想學想了解的客戶,反正講清楚一點也不花多少時間
但大家身在這個行業應該也了解,不是每個人都這麼有慧根
順便附帶說明,編碼器解析度拉高,其實對於位置控制的精確度提升是非常有限的
講白點,你要控制一組滑台系統走出1um,最大重點之一是機構要夠力
難道真的有人為以為買了一隻20bit (1,048,576)的馬達,配上1mm的螺桿
可以做出1nm的控制?
編碼器的解析度提升,主要的功能在於速度環頻寬的拉高。
用白話點來說就是這個馬達加速更有力,更有貼背感(!?)
目標速度再快都可以追得上!
位置控制的精度要拉高,其實到位區間(Inpos)的影響遠遠大於其他任何參數
而雜訊影響又遠遠大於一切
這時通訊型的好處就出來了,通訊基本上可以當作是一個完全沒有雜訊的東西
但在初期(大約十來年前),RT通訊不像現在暴力,所以通訊型的伺服反而比較慢
因為那個年代的通訊時間可能只有10ms才給一次封包
對於需要高速變換動作的機台而言,這個東西顯得不是很夠力
其實一直到這幾年,比較精確地講應該是 Mechalink2 / SSCnet / EtherCAT之後
大家把通訊時間一鼓作氣縮到1ms以下,通訊型才在高階伺服站穩腳步
不然以前高階都還是DSP 軸卡做全閉迴路控制的天下。
科技進步本來就是要減少腦力消耗,這些控制元件以後一定也會越來越無腦好用
電控人的精力就可以專注在其他更有價值的事情上!
※ 引述《wisdom ()》之銘言:
: : 推 syatoyan: 誠心發問 為什麼電子齒輪比害人不淺? 10/09 05:46
: : → syatoyan: 靠調整電子齒輪比 可以藉由較高的回授脈波數 得到更精準 10/09 05:47
: : → syatoyan: 的誤差 不是可以做更精準的誤差修正嗎? 10/09 05:48
: : → syatoyan: 還是說 那樣得到的誤差值其實是假的 實際誤差還是以 10/09 05:49
: : → syatoyan: 編碼器的規格為基準? 10/09 05:50
: : → syatoyan: 可是使用者卻認為有電子齒輪比 所以我只要以最低階的 10/09 05:51
: : → syatoyan: 所以造成 只要使用最低階的編碼器 + 電子齒輪比設定 10/09 05:54
: : → syatoyan: 也可以做到誤差0.1mm的精準控制 這種錯覺? 10/09 05:54
: : → syatoyan: 弱弱的推測是不是這樣的現象 所以電子齒輪比不好? 10/09 05:55
: 你的觀念有誤,這是我說電子齒輪比害人不淺的原因之一
: 電子齒輪比的存在原因
: 是因為編碼器解析度越來越高,使用者需求的馬達轉速增加
: 但脈波發送/接收模組的反應速度跟不上造成的
: 我們舉個例子,為求容易理解 & 計算方便,我用非真實數據來解釋
: 假設編碼器解析度是 360 inc/rev,意即馬達每轉一度,編碼器可以輸出一個訊號
: (這裡我不用"脈波",是因為很多人又會被編碼器脈波跟控制脈波搞混)
: 換句話說,編碼器的解析度是 1度,那麼這個伺服系統能達到的理論控制精度也就是1度
: 理論控制精度有兩個函義
: 1. 你能控制馬達往前/後轉1度。
: 2. 定位精度極限理論上是 +- 1度
: 接下來,我們要把脈波控制跟編碼器"脈波"混在一起講了
: 理論上,以pulse chain作為控制命令,一個控制脈波 = 一個編碼器脈波
: 也就是說,驅動器接收到一個脈波,會控制馬達轉一個編碼器單位
: 以這裡的例子,就是轉1度。
: 請注意,在這裡的例子裡,你是無法控制馬達轉0.5度或任何小於1度的角度
: 假設你希望馬達每秒轉10圈(10rps = 600rpm)
: 意即你要控制脈波輸出10 x 360 = 3600 Hz
: 再假設,你使用的脈波輸出模組,最高的輸出頻率只有2k Hz(先別管哪來這麼爛的模組)
: 換句話說,在這套系統裡,你無法得到你要的目標轉速
: 於是聰明的製造商,就引入了電子齒輪比這個參數
: 電子齒輪比讓控制脈波 = 編碼器脈波 x 電子齒輪比
: 換句話說,如果電子齒輪比設成 2
: 一個控制脈波,驅動器會讓馬達轉 2度
: 這樣的話,只要1800Hz的脈波頻率,就能讓馬達達到600rpm的轉速
: 不改變任何硬體條件的前提下,立刻解決這個問題。
: 請留意,這才是電子齒輪比最初設計出來的初衷,
: 只是為了解決脈波產生/接收模組的反應速度不夠快的問題而已。
: 而使用電子齒輪比會造成一個根本問題,就是你的控制精度直接下降
: 以上面的例子,你最小只能控制馬達一次轉2度,控制精度會下降
: 意即你只能控制馬達走0、2、4..... 這些角度,命令無法給1、3、5.....這些度數
: (當然定位精度不會改變,一樣是 +- 1度。)
: 所以現在所有電子齒輪比的延伸應用
: 包含用來將減速比、螺桿導程計算後導入電子齒輪比
: 讓PLC的控制單位 = 機構單位,這種作法看似讓應用變得方便了
: 實際上並不是正確的使用。
: 而業界不僅是大教特教這種用法,還出書教你怎麼算
: 幾乎工控人都把這套方法當成聖經不容挑戰了....
: 當然很多人會說,編碼器解析度這麼高,換算到螺桿精度後,
: 一個編碼器解析度可能是1nm,我只需要1um的控制就好,
: 何必管設定電子齒輪比後造成的控制精度下降? 不影響使用啊
: 這我同意,這也是電子齒輪比在應用上,這麼多年來也沒有人有意見的原因。
: 不過我說的害人不淺,不完全是應用上不合理,其實稍微不那麼低階的驅動器
: 都可以讓你設定減速比跟螺桿導程,驅動器內部會自動幫你換算
: 但因為根深蒂固長久以來的使用習慣,太多人已經寧願就他原本那套電子齒輪比
: 算好丟一個參數進去就好,也不願意去使用正確的參數設定。此其一
: 再者是,控制脈波跟編碼器回授脈波,本質上兩者是沒有關係的
: 只是在控制上,一開始為求最大控制精度
: 自然會讓控制脈波跟回授脈波 = 1:1
: 電子齒輪比的引入,造成為數不少的工控人對這兩者產生誤解
: 錯誤觀念一久,就很難改了。
: 很多人真的以為,控制命令(脈波),跟編碼器回授(脈波),兩者一定要有一個比例關係
: 當使用到比較進階的系統時,反而一直糾結在控制命令的問題上
: 結論
: 1. 電子齒輪比的使用會導致控制精度下降
: 2. 沒搞懂電子齒輪比的使用者一大票
: 3. 搞懂但被電子齒輪比這個觀念限制住的使用者又是一大票
作者: GOFEN (豬阿布)   2017-10-21 01:36:00
U文
作者: b2481 (RayGetRUA-RUA)   2017-10-21 02:05:00
推,好文!!但是為什麼解析度提高 能提高速度迴路頻寬? 有點難理解
作者: duser ( )   2017-10-21 02:14:00
受益良多,希望這系列文章能繼續討論下去
作者: nfs258147 (258)   2017-10-21 07:59:00
解析度提高>代表更能掌握物體真實的狀態假設有一個編碼器,它每圈只能輸出一個pulse、代表它只有偵測一圈以上的能力。如果馬達以正負30度高速來回運轉,則這顆編碼器完全不知道發生什麼事。接著再想看看,如果換一顆解析度更高的編碼器會怎樣?不知道這樣講對不對當你越清楚一個人,你越會知道他會怎麼跑XD但我也很推Snaken的觀念。在這個時代要學的事太多,必須站在巨人的肩膀上才能思考更多重要的事。電子齒輪比也許會讓控制精度會下降,但依據80/20法則,它可以滿足80%沒那麼要求的場合了。以前我都會糾正客戶。但後來發現,讓他們能會去運用比較重要(即使是有一點錯誤的觀念),因為他們真的不在意事情的正確性;而且糾正客戶,常常不會有好下場。
作者: sony0955 (索尼亞)   2017-10-21 09:23:00
希望可以有更多討論 謝!
作者: snaken (snaken)   2017-10-21 09:31:00
非常同意nfs的看法順便更正一下,現在的伺服,其實編碼器不回傳脈波驅動器事實上也是透過通訊讀取encoder的值所以driver上面的"編碼器ABZ輸出"事實上也是"電子齒輪比" 處理過的結果喔 :)
作者: Kayusumi (Left)   2017-10-21 13:51:00
解析度拉高 低轉速控的比較穩
作者: nfs258147 (258)   2017-10-21 13:55:00
Snaken大,謝謝分享!以前都只是會用而已,沒想到背後有這些故事
作者: b2481 (RayGetRUA-RUA)   2017-10-23 07:03:00
謝謝nfs大的解惑!

Links booklink

Contact Us: admin [ a t ] ucptt.com