ST意法半导体
直播中

席毖庸

7年用户 1037经验值
擅长:596874
私信 关注
[问答]

电机在100 RPM以上运行到最大额定速度

我在控制电机速度低于~100 RPM(大厅的~10Hz)时遇到了麻烦。我在霍尔效应和无传感器模式方面遇到类似问题。我可以理解这是无传感器模式的一个问题,因为当前信号在这些级别难以解释。但是除了kp和ki之外我似乎没有太多调整来使用Hall Effects更好地工作,并且在无传感器模式下使用Rev Up配置在此范围内获得最小响应。我不断得到速度反馈错误,这通常可以归因于PID失控时的增益配置,但有时候它显然不是很明显......


理想情况下,我需要能够以相当慢的速度(~20-40 RPM)使电机蠕动,因此启动时的过冲并不是非常可接受的......

电机似乎在100 RPM以上运行到最大额定速度。

也许有些东西我缺少或者应该仔细观察?

此固件是否还有其他可能相关的操作限制?

感谢您的时间。

以上来自于谷歌翻译


以下为原文




I am having troubles controlling the speed of my motor below ~100 RPM (~10Hz on the halls). I am having similar issues with both Hall Effect and sensor-less modes. I could understand this being an issue with the sensor-less mode due to the current signal getting hard to interpret at these levels. But there doesn't seem to be much I can tweak other than the kp and ki to get this working better with the Hall Effects, and I get minimal response in this range playing with the Rev Up config in sensorless mode. I continually get Speed Feedback errors, which often can be attributed to gain configuration it seems when the PIDs get out of control, but other times it's not terribly obvious what is wrong...


Ideally I need to be able to creep the motor along rather slowly (~20-40 RPM) for this application, so overshoot on startup isn't terribly acceptable...

The motor seems to run just fine above 100 RPM to it's max rated speed otherwise.

Perhaps there is something I am missing or should be looking at closer?

Are there other operational limits for this firmware that may be relevant here as well??

Thank you for your time.

回帖(5)

张秀兰

2019-3-7 16:19:59
Ciao Raddix
 
 
 我认为,通过实施的FW,您无法实现目标。
 
 我解释得更好。控制回路考虑作为测量单位,考虑机械赫兹(0.1Hz)的十分之一,这意味着在数字中uint对应于6rpm。因此,在20-40 RPM的范围内,速度控制器正在使用目标和测量速度值,这些值非常小,以便进行良好的调节。必须更改测量单位才能实现良好的控制,但这种修改对代码有很大影响。
 
 再见
 梁咏琪

以上来自于谷歌翻译


以下为原文





Ciao Raddix


I think that with the implemented FW you can't achieve your target.

I explain better. The control loop is done considering as measurement unit the tenth of mecchanical herz (0.1Hz) this mean that in digit the uint corresponds to 6 rpm. So in the range of 20-40 RPM the speed controller is working with target and measurement speeds value that have very very small for a good regulation. A change of measurement unit is mandatory to achieve a good control but this modification has big impact on the code.

Ciao
Gigi
举报

席毖庸

2019-3-7 16:32:51
谢谢你这么快回复我。
 
 
我有点担心这会成为一个问题。然而我确实注意到我能够使用加速周期在这个低速区域驱动电机如果我手动设置加速段需要相当长的更大的扭矩请求(你可以告诉它正在与磁力作斗争并且开槽一个在这个水平位)。这可能不是非常有效,显然这里的反馈选项并不多,但是如果我们可以访问完整的源代码或者操纵我们对API的调用,这可能是一种让事情在这个范围内工作的方法吗?
 
 
我关心的是使用给定的软件处理该区域中的扭矩命令,并最终(希望平滑)过渡到反馈控制模式。
 
如果这不是非常可行,我们可能需要重新评估我们将如何处理这个应用程序...
 
再次感谢您的反馈。

以上来自于谷歌翻译


以下为原文





Thank you for getting back to me so soon.


I was somewhat afraid that would be an issue. I did notice however that I was able to drive the motor in this low speed area using the rev up period if I manually set the rev up segments to be rather long with a larger torque request (you can tell it's fighting the magnetics and notching a bit at this level). This likely isn't terribly efficient and obviously there is not much for feedback options here, but would this possibly be a way to make things work in this range if we had access to the full source or by manipulating our calls to the API?


My concern here is handling the torque command in this area with the given software and the eventual (hopefully smooth) transition into a feedback control mode.

If this isn't terribly feasible we may need to re-evaluate how we will approach this application...

Thank you again for your feedback.
举报

张秀兰

2019-3-7 16:45:31
也许我想念你的建议,
 
 你是想以固定的速度在开环中运行电机,给它提供大量的电流来旋转它?
 如果您的最终应用程序没有考虑到全局效率,那么这可以是一个选项。
 
 另外,另一个选择是修改代码,将速度单位改为例如0.01机械Hz或更低,但我同意这不是一件容易的事。
 
 再见
 梁咏琪

以上来自于谷歌翻译


以下为原文





Maybe I missunderstand your proposal,

you are thinking to run the motor in open loop at fixed speed giving a lot of current to spin it away?
If your final application doesn't take care of the global efficiency, ok this can be an option.

Othwerwise the other option shall be to modify the code changing the speed unit to, for instance, 0.01 mechanical Hz, or less, but I agree that this is not an easy task.

Ciao
Gigi
举报

席毖庸

2019-3-7 17:02:03
当然,如果我们不需要,我们宁愿不在这个区域燃烧大量电流,但我开始怀疑这里是否有太多其他选择。应用的性质可能需要相当高的扭矩,速度相当低。
 
 
更糟糕的情况是,如果我们无法在SDK中运行,我想我们可以使用自举或低速模式,我们将使用自己的PID手动控制扭矩。我仍然会关注切换或转换到反馈模式。这样的事情是否可行?
 
说到SDK的来源,我在我附近尝试了3个不同的ST办公室,并且无法与真人讨论如何访问它。您能否在中西部,美国或其他地方给我联系?
 
感谢您的帮助和见解。

以上来自于谷歌翻译


以下为原文





Of course we would rather not burn a ton of current in this area if we don't have to, but I am starting to wonder if we have too many other options here. The nature of the application could require rather high torque at pretty low speeds.


Worse case if we can't make it work in the SDK, I suppose we could have a bootstrap or low speed mode where we would manually control the torque with our own PID. I would still be concerned about the hand off or transistion into a feedback mode. Would something like this be feasible??

Speaking of source for the SDK, I have tried 3 different ST offices near me and have not been able to get through to a real person to discuss getting access to it. Could you possibly give me a contact in the Midwest, US or elsewhere?

Thank you for your help and insight.
举报

更多回帖

发帖
×
20
完善资料,
赚取积分