2017-10-10 12:30 PM
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.
#powerstep01 #bemf #voltage-mode #step #compensation Note: this post was migrated and contained many threaded conversations, some content may be missing.2017-10-16 04:39 AM
Some years ago I asked
'Problem with dSPIN L6470 chip in step-clock mode.'
I have a problem with a
L6470
chip, when I use it instep-clock mode. In this mode, I can get the necessary torque.....
They answred me:
The
L6470
works in voltage and needs bemf compensation. For that you need to know the speed. When you use the motion engine (run command for instance) our chip performs the voltage compensation . When you use the step clock, be definition we do not know the speed so there is no Bemf compensation. Then the current decreases Vs the speed.Think to use the current mode Like the L6472. In that case you will get the same torque using step clock or motion engine.
2018-01-03 05:53 PM
Thank you.
Their answer does make sense but it's helpless. Because they don't show us a way to apply voltage compensation by ourselves. they (our their chip) don't know the speed but we, the users DO know.
And it disappoints me that they don't answer me if my approach is workable or not. I think we need more details.
Thanks again for the information you provided. It's an important confirm for me.
2018-01-04 05:56 AM
The voltage mode algorithm is described in details in the
.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?
2018-01-25 11:37 PM
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
!2018-01-26 10:18 AM
'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.
2018-01-26 06:55 PM
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
.
2018-01-27 02:17 AM
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.
2018-01-27 11:10 AM
My results are mostly with powerSTEP 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.