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