完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
对于PowerSTEP01,L6470和L6480,BEMF补偿不适用于步进时钟模式(电机状态停止)。通过改变PWM频率加速电机时,输出(电机)电压不会增加。没有BEMF补偿,输出电流在高速时太低。因此,步进时钟模式在电压模式下完全无用。
我有一个临时解决这个问题的方法,我设置KVAL_HOLD寄存器来改变速度时的电压。但SPI通信占用了很多CPU圈,因此速度有限,因为间隔不能低于SPI通信需求。菊花链更糟糕:总线上的设备越多,SPI通信消耗的时间就越多。因此,难以在两步脉冲之间改变电压。 还有一个问题:在SPI通信(设置KVAL_HOLD)结束(所有字节都是从MCU发送)之后,电压实际变化需要多长时间?我们必须保证在脉冲达到更高速率之前电压足够高,所以我认为这是一个重要的问题。如果不知道命令(设置参数)和实际执行的动作之间的经过时间,我们就无法估计出正确的引导(发送命令的时间)来满足条件。请问有人给我们答案吗? 或者,任何机构能否为我们提供更好的解决方案,以便在电压模式下使用步进时钟模式?恕我直言,使用RUN命令和速度配置文件无法完成步进时钟模式可以执行的所有操作。并且只有电压模式具有1/128微步。那么如何使步进时钟模式和电压模式组合工作对我来说很重要。 (我还没有尝试过当前模式,因为1/16微步对我的项目来说不够好。所以我不知道当前模式是否有类似问题。步进时钟模式在当前模式下工作得更好吗?如果有人知道,您可以在这里提供一些信息,其他人可以从您的知识和建议中获益。) 任何建议表示赞赏。谢谢。 #bemf#powerstep01#voltage-mode #step #compensation 以上来自于谷歌翻译 以下为原文 With PowerSTEP01, L6470 and L6480, the BEMF compensation does not work with step-clock mode (the motor status is stop). The output (to motor) voltage won't be increased when speeding up the motor by changing PWM frequency. without BEMF compensation, the output current is too low at high speed. Thus, step-clock mode is totally useless in voltage mode. I have a temporary solution for this problem, I set KVAL_HOLD register to change the voltage when changing speed. But the SPI communications eat many CPU circles, so there is a limitation of speed because the interval can't be less than a SPI communication needs. It is even worse with daisy chain: more devices on the bus, more time is consumed by SPI communications. So, changing voltage between two step pulses is difficult. And there is a question: after the SPI communication (setting KVAL_HOLD) ends (all bytes are sent from MCU), how long does it take before the voltage is actually changed? we must guarantee the voltage is high enough before the pulses achieve a higher rate, so I think this is a important question. Without the knowledge about elapsed time between command (setting parameters) and action actually executed, we cannot estimate a proper lead (time to send the command) to satisfy the condition. Could anybody give us an answer please ? Or, Could any body give us a better solution to use step-clock mode in voltage mode? IMHO, using the RUN command and speed profiles can't do everything the step-clock mode can do. And only voltage mode has 1/128 micro-step. So how to make the combination of step-clock mode and voltage mode work is important to me. (I haven't tried current mode yet, because the 1/16 micro-step is not good enough for my project. So I don't know if current mode have similar problems. Does step-clock mode work better in current mode? If somebody know, you may provide some info here, others can get benefits from your knowledge and advice.). Any suggestions is appreciated. Thank you. #bemf #powerstep01 #voltage-mode #step #compensation |
|
相关推荐
7个回答
|
|
|
|
|
|
电压模式算法详细描述于
http://www.st.com/content/ccc/resource/technical/document/application_note/ad/fc/fb/f0/f7/c7/4c/48/DM00061093.pdf/files/DM00061093.pdf/jcr:内容/翻译/ en.DM00061093.pdf 。关于其他问题: - 更新KVAL_HOLD后,占空比在下一个PWM周期更新。 - 实现电压模式补偿曲线的另一种方法是使用ADCIN输入和电源电压补偿功能。分辨率低于通过SPI更新KVAL_HOLD所获得的分辨率,但我认为它可以提供良好的结果。 - 步进时钟操作的替代方案取决于应用程序的用途,您可以分享更多详细信息吗? 以上来自于谷歌翻译 以下为原文 The voltage mode algorithm is described in details in the http://www.st.com/content/ccc/resource/technical/document/application_note/ad/fc/fb/f0/f7/c7/4c/48/DM00061093.pdf/files/DM00061093.pdf/jcr:content/translations/en.DM00061093.pdf .About the other questions: - After the KVAL_HOLD is updated, the duty-cycle is updated at the next PWM cycle. - An alternative way to implement the voltage mode compensation curve is to use the ADCIN input and the supply voltage compensation feature. The resolution is lower than the one you can obtain updating the KVAL_HOLD through SPI, but I think it could give good results. - Alternatives to step-clock operation depends on the purpose of your application,can you share more details? |
|
|
|
谢谢!
如果我没有误解,你提到的PWM('下一个PWM周期')是控制施加到步进电机相位的电压正弦波的PWM。我误解了吗?从MCU发送所有字节后(命令的最后一个字节到达powerSTEP01),实际更新KVAL_HOLD之前需要多长时间? 通过SPI更新KVAL_HOLD的分辨率高于使用ADCIN输入的分辨率,但它有任何缺点吗?它与运动引擎执行的电压补偿(运行命令等)有什么不同吗? 我可以接受步进时钟操作的替代方案。事实上,我正试着自己找一个。 一个简单的例子:CNC有两个轴。 我们想绘制一个cricle或曲线,但我们不希望电机频繁停止,因此我们不能使用MOVE命令。我认为我们应该使用RUN命令,但是当电机运行时,ACC / DEC寄存器的值不能改变(对于下一个RUN命令),所以我们无法控制加速和减速中的比率dy / dx。 我们可以在每个微步之间以不同的速度发送RUN命令。但通过这种方式,电机可以达到的最大速度受到SPI通信的限制。特别是SPI通信在菊花链配置和多个电机上花费了太多时间。我们必须等待繁忙的销钉才能被释放。因此,MCU上的任务(包括SPI通信本身)变得难以安排,除非我们放慢一切。 我做错了什么或犯了什么错误?还有其他替代方法可以做这个例子吗?任何帮助 将 是 非常 赞赏 ! 以上来自于谷歌翻译 以下为原文 Thank you! If I don't misunderstand, the PWM you mentioned ('the next PWM cycle') is the one to control voltage sinewaves applied to the stepper motor phases. Do I misunderstand? After all bytes are sent from MCU (the last byte of a command arrives at powerSTEP01), how long it will take before KVAL_HOLD is actually updated? Updating the KVAL_HOLD through SPI has higher resolutions than using ADCIN input, but does it have any disadvantages? does it have any difference from the voltage compensation performs by motion engine(RUN command, etc)? I can accept an alternatives to step-clock operation. In fact, I am trying to find one myself. An simple example: A CNC has two axes. We want to draw a cricle or a curve, but we don't want the motors stop frequently, so we can't use MOVE command. I think that we should use RUN command, but the value of ACC/DEC register cannot be changed (for next RUN command) when motors are running, so we can't control the ratio dy/dx in acceleration and deceleration. We may send RUN commands with different speed between every micro-steps. But in this way, the max speed that motors can reach is limited by SPI communications. Particularly the SPI communications take too much time with daisy chain configuration and several motors. And we have to wait on the busy pin to be released. Thus the tasks (including SPI communications themselves) on the MCU become difficult to arrange, unless we slow down everything. Did I do something wrong or make any mistake? Are there other alternatives to do things like this example? Any assistance would be very much appreciated ! |
|
|
|
'特别是SPI通信在菊花链配置和多个电机上花费了太多时间。 “
你能说'太多时间'是什么?你需要达到什么样的速度?你在运行什么处理器?我设法在一个8位Atmel芯片上获得了一个单字节命令并响应了大约20us的三个L6474板的堆栈。 (Uno) IIRC SCK限制在8MHz。你应该能够在STM32上加快速度。 以上来自于谷歌翻译 以下为原文 'Particularly the SPI communications take too much time with daisy chain configuration and several motors. ' Could you say what 'too much time' is ? What step speeds to you need to achieve? What processor are you running? I managed to get a one byte command and response to a stack of three L6474 boards in around 20us on an 8bit Atmel chip. ( Uno ) . IIRC the SCK is limited to 8MHz there. You should be able to go way faster on STM32. |
|
|
|
STM32更快,但powerSTEP01 / L647x不是。根据powerSTEP01 / L647x文档,最大SPI时钟频率限制为5MHz。特别是,取消选择时间为625ns。实际上,最大SPI时钟频率可以达到约22.5MHz,但是在这个频率下我们会遇到通信错误。我认为16MHz~18Mhz使用是安全的,但我不确定是否还有其他问题。一个RUN命令是4个字节,所以对于STM32和5~6 powerSTEP01 / L647x,即使我们使powerSTEP01 / L647x'超频'(5MHz - > 16MHz)的SPI时钟,我们仍然达到一个没有明显改善的限制你的(8MHz)。比使用步进时钟模式慢得多。
另一方面,使用RUN命令需要我们为MCU侧的SPI通信做更多的工作,这些工作需要很多CPU周期。如果我们必须在每个微步骤发送RUN命令,如果我们在MCU端有其他事情要做,那么很难进行优化。考虑到我们有一些计算(如速度,加速度,减速度等),与其他设备的通信(从用户获取路径,移动和其他操作),安全防护例程(检测非法移动,处理用户断开连接等)和其他一些杂项工作,把所有这些放在一起,而我们必须发送RUN命令,这不是一件容易的事。使用步进时钟更容易,因为设置和复位引脚占用的CPU周期更少。 无论如何,这只是我的想法。如果有人能指出更好的方法,我准备改变主意。 这不是我需要达到的步速。对于一种产品/设计,600个全步/秒可接受的偏差可能就足够了,但如果我们能够获得更高的速度和更高的精度,为什么不呢?我们正在开发一种解决方案,“一劳永逸”可能听起来精神病,但覆盖更多病例则不然。我们的 目标是 制造 充分 使用 的 这些芯片 。 以上来自于谷歌翻译 以下为原文 STM32 is faster but the powerSTEP01/L647x is not. According to powerSTEP01/L647x documents, the maximum SPI clock frequency is limited to 5MHz. Especially, the deselect time is 625ns. In practice, the maximum SPI clock frequency can reach about 22.5MHz, but we encounter communication errors at this frequency. I think that 16MHz ~ 18Mhz is safe to use, but I'm not sure if there are other problems or not. a RUN command is 4 bytes, so with STM32 and 5~6 powerSTEP01/L647x, even we make the SPI clock of powerSTEP01/L647x 'overclocked' (5MHz -> 16MHz), we still meet a limit that is not significantly improved than yours (8MHz).it's much slower than using step-clock mode. On the other hand, using RUN command need us to do more works for SPI communication at MCU side, these works eat many CPU cycles. if we must send RUN commands with every micro-steps, It's difficult to optimize if we have other things to do at MCU side. Considering that we have some calculations (like speed, acceleration, deceleration, etc), communication to other devices(fetching paths, moves and other actions from user), safe guard routines(detecting illegal moves, handling user disconnection, etc) and some other miscellaneous works, putting all these together while we must send RUN commands precisely it's not an easy job. Using step-clock is easier because setting and resetting pins eat much less CPU cycles. Anyway, it's just my thoughts. I'm ready to change my mind if someone can point out a better way. It's not about what step speeds I need to achieve. 600 full-steps/s with acceptable deviation may be enough for one product/design, but if we could get higher speed and more precision, why not? And we are developing a solution, 'once for all' may sound mentally ill, but covering more cases is not. Our goal is making full use of these chips . |
|
|
|
实际上,我正在使用SPI_BaudRatePrescaler_32,它提供3.125MHz,这是发布规范中最快的选项。使用更高速度的结果很有用。
无论如何,在每一步中动态改变参数似乎都不是一种明智或强有力的方法。似乎这些芯片设计用于控制车窗等应用,其中处理加速的内部运行机制很好但不适合机器控制应用。 支持经典步进模式作为一种向后兼容功能,但其他控件功能并未完全支持。 以上来自于谷歌翻译 以下为原文 Indeed, I'm using SPI_BaudRatePrescaler_32 which gives 3.125MHz, the fastest option within the published spec. Your results using higher speeds are useful. In any case changing parameters on the fly at every step does not seem like a sensible or robust way of going about this. It seems that these chips are designed for applications like controlling car windows where the internal run mechanism which handles the acceleration is fine but is not suitable for machine control applications. The classic step mode is supported as a kind of backwards compatibility feature but is not fully supported by other control features. |
|
|
|
我的结果主要是powerSTEP01。而SPI时钟频率并没有告诉我们整个故事。取消选择时间不能减少很多。当它小于500ns时,通信通常会失败。我想芯片需要一些时间从SPI加载字节并完成其工作,或者还有其他原因。因此,当我们使用非常高的频率时,实际上通信速度不会得到很大改善。
这些芯片是否适合机器控制?我现在不确定。我认为他们提供的机制可以做很多事情,但它们并不容易使用。 让我们等一下ST会说些什么。 注意:原始帖子包含大量线程对话,只能迁移到第9级 以上来自于谷歌翻译 以下为原文 My results are mostly with powerSTEP01. And SPI clock frequency does not tell us the whole story. the deselect time can not be decreased a lot. when it is less than 500ns, the communication usually fails. I guess that the chip need some time to load bytes from SPI and do its job, or there are other reasons. So actually the communication speed won't be improved very much when we use very high frequency. Are these chips suitable for machine controlling or not? I'm not sure at the moment. I think that the mechanisms they provided can do many things, but they are not easy to use. Let's wait for what ST will say. Note: the original post contained a large number of threaded conversations and was only able to be migrated to the 9th level |
|
|
|
只有小组成员才能发言,加入小组>>
请教:在使用UDE STK时,单片机使用SPC560D30L1,在配置文件怎么设置或选择?里面只有SPC560D40的选项
2724 浏览 1 评论
3237 浏览 1 评论
请问是否有通过UART连接的两个微处理器之间实现双向值交换的方法?
1807 浏览 1 评论
3646 浏览 6 评论
6034 浏览 21 评论
1336浏览 4评论
197浏览 3评论
对H747I-DISCO写程序时将CN2的st-link复用为usart1,再次烧录时无法检测到stlink怎么解决?
350浏览 2评论
STM32G474RE芯片只是串口发个数据就发烫严重是怎么回事?
442浏览 2评论
STM32处理增量式编码器Z信号如何判断中断是正转的还是反向转的?
268浏览 2评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-12-22 11:33 , Processed in 1.303779 second(s), Total 90, Slave 73 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号