尝试计算一下电机运行情况 有刷电机太复杂 不考虑火花放电和线圈切换 假设其模型是R+L+U串行 U是某转速下反电动势是不变量 V是供电电压
$\dot I=(V-U-IR)/L$
I应该是$a+be^{ct}$形式
$ \dot I=bce^{ct}=(V-U-R(a+be^{ct}))/L$
所以 V-U-Ra=0 -> a=(V-U)/R
----路上又发现 从这里开始推导有问题 少了个L 只能再来!!! 不好意思 下面是更正过的---
且 -Rb/L=bc -> c=-R/L
设边界条件 $I_{t=0}=I_0$ 则$a+b=I_0 -> b=I_0-(V-U)/R$
令$I_m=(V-U)/R$是PWM导通时候最大电流 而PWM关断时忽略续流二极管压降 $I_m=-U/R$
最终 $I=I_m+(I_0-I_m)e^{-R/L*t} $
当PWM关断时 由式子可知电流会负 但是续流的是二极管 这不可能 最多到电流为0 这时候不再有电流给电机提供力矩 有个断流时间
我测过电机 L=6mH R=12Ohm 供电12伏 电机号称空载3200RPM 实际观测 在上蠕动管带空气时候 远小于这个转速 只有1/10左右 估计U=1.2伏 假设从电流$I_0=(V-U)/R=0.9A$开始下降 且$I_m=-U/R=-0.1A$ 画出$I=-0.1+e^{-2000t}$图像 可见0.001秒后 续流结束
如果更低转速下 比如最大负载转速的1/10 U=0.12伏 $I=-0.01+e^{-2000t}$ 电流持续时间更长了
干脆连PWM导通图像(电流从0开始)$I=0.9-0.9e^{-2000t}$也画了 可见差不多也0.002秒就接近最终电流了
如果PWM周期小于0.001秒 这时候线圈续流蓄能是起作用的 我唯一担心的是 当电刷切换线圈时候 旧线圈的能量不仅在铁心中储存 还有不少通过火花放电的形式释放掉 哎 先忽略掉吧
由电流在PWM导通关断时候连续 互为起始条件
$I_{0off}=(V-U)/R+(I_{0on}-(V-U)/R)e^{-R/L*t_{on}} $
$I_{0on}=-U/R+(I_{0off}+U/R)e^{-R/L*t_{off}} $
得$I_{0off}=(V-U)/R+(-U/R+(I_{0off}+U/R)e^{-R/L*t_{off}} -(V-U)/R)e^{-R/L*t_{on}} $
$I_{0off}(1-e^{-R/L*T})=(V-U)/R+U/R*e^{-R/L*T}-V/R*e^{-R/L*t_{on}} $
$I_{0off}R(1-e^{-R/L*T})=U*(e^{-R/L*T}-1)+V*(1-e^{-R/L*t_{on}})$
$U=V*(1-e^{-R/L*t_{on}})/(1-e^{-R/L*T})-I_{0off}R$
反电动势应该于转速正比 一般情况 也假设电流与转速正比(假设负载力矩和转速正比)再设全导通时候转速为 $\omega_m$
于是 转速 $\omega=\omega_m*(1-e^{-R/L*t_{on}})/(1-e^{-R/L*T})$
这当然是非线性的 有趣的是 推到最后 居然只与R有关(但愿我路上推导没出错)" src="/default/XXXXXXXXXXXXXg">
联系实际画图 我发现 线性度在一般情况下其实蛮高的 而且PWM频率越高 电机线圈电阻越小 电感越大 线性度越高 下面是1kHz和5kHz下 转速和导通比例的关系
之比例所以做以上推导 是想确定个PWM频率 因为MCU直驱AO3400 频率不可能太高 否则驱动不到位会让AO3400过热
而且网上有经验说 PWM频率太高 转速反而上不去 我这里理想模型没有出现这种情况 但我想实际情况难说 想办法评估到一个较好用又不太高的频率好了
现在看来 可能频率最好在1kHz以上 毛估一下 AO3400栅极充电需要7nC 5mA充电需要1.4us 放电当它一样 总需要3us
按最大电流1A 供电12伏 1kHz时候 0.3%耗损率 约36mW 3kHz接近0.1w 对它封装是可以接受的值 就试试3kHz吧
--------4.19-------
刚测试了PWM频率和转速
果然当频率够高 PWM占空比和转速的关系 就越发线性了
但是频率越高 启动越难 网上说的"PWM频率太高 转速反而上不去" 在低速时是有道理的 考虑到频率高时候 近乎是恒电流驱动 力矩也恒定 如果不先克服摩擦力 就转不起来 我之前的分析简化了 只考虑速度的阻力 没有考虑摩擦力 尤其是蠕动泵本身的摩擦力就大
说实在的 100Hz 和 1kHz 有可以听闻 令人不快的音频声 而10kHz没有声音 10Hz的声音与蠕动泵本身声音混杂不易听闻 最后的算法我还在考虑中
现在最恼火的还是Micropython 就这样几天 我已经提过一次bug 两次feature要求了 ... 用起来有很多细节与之前认为的不一样 比如在esp32不支持硬中断 奇怪的GC报告 感觉项目中充满了无可奈何的补丁 不情愿使用的显然不理想不通用的实现方法 很令人不爽
时段 | 个数 |
---|---|
{{f.startingTime}}点 - {{f.endTime}}点 | {{f.fileCount}} |