PID error of the project about bldc-drive HOT 8 OPEN

Thanks for you comment, you are probably the first one to test my code apart from myself!

There is a setting called "encoder_counts_per_step". What value did you have there? I've set it to 10 by default. This means that for each step pulse, the requested position will go +/-10. So if you did not change the default and then give 60kHz input, the requested speed is already 9000rpm which may be too much? Are you able to run a motor with slower speed?

from bldc-drive.

Yeah, I set "encoder_counts_per_step" with 1, so the real speed should be 900 RPM. Didn't you encounter this problem?

from bldc-drive.

No I haven't encountered that. However I'm not quite sure if I understand the problem you have. You say that the pid error will decrease when this happens. I don't know what that means.. Shouldn't the pid error be close to zero when the drive is functioning properly, that way the requested position is close to the actual position? How do you monitor the pid_error when you run the motor? I published my tuning Python gui last night. It can be used to monitor pid error and other things as well.

from bldc-drive.

Thank you. Yes, the pid error decresed first and increase later, I am trying the make certain of it. I also believe the program is correct, otherwise the error will not decrease. The encoder I used before is 1000 PPR, if I understand correctly the program makes the frequency quadruple. Now I bought a new one with 3600 PPR, that may mean real PPR will be as much as 14400. I see the program brief "8096 PPR max at the moment", so whether this means this encoder can't be used at present. I print the parameters with usart. Congraduation to your tuner, it will be easier for debugging~

from bldc-drive.

Pekka, have you tested the highest speed in the step mode with the encoder, and how about the torque performance? And what's the encoder's PPR?

from bldc-drive.

First, about the encoder PPR. The number specified with the encoder is usually telling that how many quadrature pulses you will get per rotation. Every quadrature pulse includes A line rising, B rising, A falling and B falling. My firmware will increment the counter at each of those events, so yes, the PPR (also called CPR) seen by my firmware is four times the rating you often see on the label of the encoder. However, I have also seen that some encoders have their rating already multiplied by four.

So far I've always used the default encoder_counts_per_step=10. I don't have a proper signal source to generate fast enough pulses to work without that multiplier. I have encoder with 1000 lines, i.e 4000 CPR. With this combination I've been able to reach >2000rpm. If you see that the error will start getting larger when you increase speed, I would assume that the step input is still read correctly by the driver but the motor is not able to follow for some reason? Are you using hall sensors or encoder for commutation? The commutation with encoder is not tested very well I have to say and that maybe starts to limit the performance at high speed.

from bldc-drive.

Sorry to reply late, what you said is right. Now I have reached speed 3500 RPM with the new encoder. But when I try to increase the PID rate, the performance seem not to enhance. Theoretically, the PID rate should be as higher as possible, or not ?

from bldc-drive.

Nice, 3500rpm sounds good. What do you mean by PID rate? The frequency at which the PID loop is run? To some extent it should improve the performance, but there are limits. The PWM frequency is set to ~20kHz, so when PID frequency starts to get close to this value, I think updating the PID more often has no effect at all and possibly even giving some unexpected results.

from bldc-drive.