need help for speed control at lower speeds

Here is a general comment on tuning the PID loop for speed control application - PID tuning becomes more challenging if the speed range varies widely. Finding a single set of co-efficients applicable for a high speed and low speed range needs compromise and trade-offs in performance. It is better in many cases to utilize different set of co-efficients depending on your speed range. You may find one set for your low speed range (the range defined by you) and another set for the high speed range. This division of co-efficients will allow you to optimize.

Hi Vaibhav, Arefeen

First thing I would try is increase the speed loop prescaler as it has fundamental effect on the speed resolution. From your description at 200rpm, 20kHz ISR, and speed loop prescaler at 10 the speed resolution would be +-30RPM (+-1 tick out of 4096 at 500us, 500us is period of speed loop, 4096 is the range of your sensor ->12bit).But be aware that increasing speed loop prescaler lowers the limit on the highest speed that you can still calculate properly.

As Arefeen said, things might be mitigated if you re-tune your speed controller with another coefficients (probably lower), but I think your main problem is speed resolution.

If you use QEP unit i recommend that you obtain the speed (in the low speed region) via time measurement between qep pulses. It is much more accurate

Regards, Mitja

Hi Arefeen and Mitja,

thanks for your valuable suggestions.

Arefeen suggested to have different sets of gains for lower and higher speeds. this i have tried, but not working. as Mitja mentioned, I have found variation in speed measurement as i go below measurable speed allowed by sensor resolution. this may be suitable once i could narrow down the variation in speed measurement with some means.

now i have one custom built RDC board which gives me absolute 12 bit angle, whereas the same can give me incremental output with 1024 ppr. the angle i am using for electrical theta calculation. also i have tried to measure speed with period measurement at lower speeds with channel A output from RDC board with 1024 ppr. here you can measure lower speeds with increased timer prescaler, but there will be limitation on higher speed measurements. at build level 4, i could measure speeds with low pass filtering on, but this also could not work when i tried to close the loop. with this approach 60rpm will approximately corrospond to period of 1 ms. if i keep speedloop prescaler around 20 i.e. 1 msec, speed loop should run which is my expectation, still it is not working. one more thing, in TI's code, speed is calculated every 50us, but regulated every 500us to ensure the bandwidth requirements. then why not calculate it every 500 us. this might be helpful when you measure period in place of counting pulses. again this is my expectation.

i am planning to have new RDC board with 16 bit resolution with which i should be able to measure as low as 20 rpm.

i have another question for you guys. how to make sure that my id and iq loops are ok. is it to be validated by changing iqref and crosschecking whether iqfeedback is following or not?

thanks,

Vaibhav

Hi Vaibhav

I usually tun current loops to the step response. Generate a short (10 to 100 ISR periods) pulse as a current reference and observe the response (TI's DLOG module comes quite handy). Set the parameters so that you do not get any overshoot with pulse amplitude set to 50% of drive rated current (with drive in standstill and rated DC-link voltage). If drive has considerate reluctance you should do this once with d-axis and once for q axis controller otherwise it is enough to do this once and copy-paste the parameters to the second controller.

Regards, Mitja

Mitja,

 I am dealing with both problems referred to in this post. First, the low speed measurement. The qep modules are setup in such a way that QCPRDLAT captures the number of clock ticks it took to cross a set number of encoder transitions (32 in most cases). A constant is calculated, which when divided by QCPRDLAT gives the speed. When I run the motor in open loop speed control to observe the speed calculation, I notice that QCPRDLAT is rather variable even though the shaft is rotating smoothly. Because of this the calculated low speed value oscillates a large amount the actual speed value. Any ideas on how to get more consistent values of QCPRDLAT? Secondly, because of the issues with speed resolution does one need to slow the speed loop down as well? 

Second, using the Datalog module to observe a step response has caused some interesting problems. I try to store about 5ms of data to see the current settle. But the pulses have caused my processor to behave funny, values automatically change to astronomical levels. Regular actions such as LED flashing cease and processor stops responding and I get into the illegal ISR. Anyway, once you set the rotor to an initial position do you switch current off (if so, by disabling the power stage completely?) or command it to be zero before sending the pulse? The current pulses that I using a much 10-20% of max inverter current. 

Hi Newtothis

Regarding speed measurement:

When measuring speed through period measurement between two QEP clock pulses, you have to be aware that, when measuring at low speed, QEP timer can and will overflow, thus the result will be wrong. You should check the overflow flag, and if it is set, than the speed is below what you can measure.

You might also have noise in the speed signal, if measuring time between A and B signals. If they are not exactly 90° apart, you might get some ripple in the signal.

Regarding the controller, I'd say yes if you have plenty of noise in the feedback value, you have to either: slow the controller down or filter the value (thus slowing the controller down)

Regarding the datalo module:

how much is 5ms of data ? 10 point, 100 point or 10000 points? How big is your DLOG section?

check the "DLOG4CHC.asm" to see how big are the buffers. I suspect you are trying to write more data than you have available space (this particular code form TI is particularly bad as is written in assembly for no good reason (it is probably rewrite of DLOG module for 24xx family), it operates with pointers and it has no boundary checks.

I recommend that you take a day of from current projects and write proper data logger (support for long and float types, variable number of channels, separate trigger input, configurable trigger slope, level and support for "Auto" and "Single shot" mode). It will make your life a lot easier.

Regards, Mitja

Thanks for getting back Mitja. I am focusing on the current loop tuning at the moment, so I think I will come up with a datalogger. In the initialization for the Datalog module (dlog.size), I changed the buffer size to 200 and prescalar to 1. The PWM frequency is 20k Hz so thats 10ms data. Once I have this figured out, I will move back to the speed measurement problem. 

I am also having similar to problems in this thread so I decided to post here.

I am trying to implement velocity calculations using the Edge Capture unit, it seems to work fine for lower frequency ranges, but issues arise in higher ranges. I also use the second method to get more accurate ranges, but we need the slower method as well to get a quicker calculation.

Here are two examples that I have implemented at different frequencies:

500 Hz:

System Clock: 300 MHz

Scaled Clock (CCPS): 1:128  --> 300MHz becomes 2.34MHz

Input Frequency: 2000Hz

Scaled Input (UUPS): 1:4 -->  2000Hz becomes 500Hz

For a 16-bit timer, we will get 65536 pulses at 2.34Mhz (or 426ns)

So at 2000Hz (or 500us), we should get  500us/426ns = 1171 pulses or timer counts.

I confirmed this and the QCPRDLAT does in fact see the correct value, +/-1 count value which is understandable. At this frequency I know the module is working as intended, but then I try higher frequencies shown below. I am careful not to modify the UPPS register because of unwanted side effects mentioned in the user manual:

90kHZ:

System Clock: 300MHz

Scaled Clock (CCPS): 1:2 --> 300MHz becomes 150MHz

Input Frequency: 90000Hz

Scaled Input (UUPS): 1:4 --> 90000Hz becomes 22500Hz

For a 16-bit timer, we will get 65536 pulses at 150MHz (or 6.66ns)

So at 22500Hz (or 44us), we should get 44us/6.6ns = 6666 pulses or timer counts

However, instead of latching the correct value, the QCPRDLAT register is latching random values between 6643 and 6663. I am using a function generator and watching the signal with a scope so I know that the signal is stable.

Can anyone explain this behavior at all?

Hi David,

the thing that comes to mind is input qualification. Check the GPIO configuration, an if you have it enabled, check the errata document as I know there were some troubles regarding this in some devices (I don't know exactly, which were affected)

Hope it helps, Mitja

Hi Mitja,

Thanks for the fast response! I went back and looked over the qualification stuff again. I originally had thought that might be the problem.

To verify that it was something else. I disabled the qualification and tried running it straight through and unfortunately got the same performance.

I hadn't seen the section about the qualification in the errata until you mentioned it.

Thanks again,

David

Hi David,

did it help?

If it didn't, may I ask you what are the rise and fall times of the signal? Can you observe any jitter on the signal?

Regards, Mitja

Hi Mitja,

No, disabling the qualification had no effect, so I don't think that is the problem.

On the 90kHz signal, the rise time is 21ns, which I think should be acceptable.

There is no jitter on the line.

Thanks again for your help!

David

Hi David,

I don't have any experience with this issue, but I would imagine, that your rise time has to be at least equal or faster than your sampling clock signal which is 6.6 ns. 

While device input buffer should have consistent switching characteristics, I'd try putting a buffer/schimtt trigger at the input to QEP unit.

Regards, Mitja

Hi Mitja,

Thanks so much for the ideas. You've kept me looking at things to make sure they make sense.

I left out part of the story. I can see why a 20ns rise time would cause a problem with a 6.6ns clock. What I failed to mention though, is I am doing qualification (except I did test it disabled to see if it would help with the performance). Check if my reasoning is right on this one...

The qualification is currently set to 0x0014 (decimal 20) sample period. So, 6.66ns * 20 = 133ns. It is taking 3 samples at this period, so 3 * 133 = 400ns.

Our 90kHz (11us)  rise time of 20ns should fall nicely inside the qualification window and be ignored, am I right?

The interesting thing is, I get the same performance whether or not I have qualification enabled. I imagine this means that the line really isn't noisy at all, and is triggering where it should?

Thanks,

David

Hi David,

Can you clarify a bit what are the three samples that you are talking about?

Anyhow, input qualification is just a delay line. If you have clean signals, it should not have and inpact (unless it has a bug, as it is mentioned in errata)

Can you describe your signal source a little more in detail.

I've seen cases where quarature signals A and B were not 90° apart. Thus measuring time between clock pulses (decoded from A and B signals) can yeiald significant error.

Mitja

Hi Mitja,

For the samples, I am referring to the setting for the qualification, it can either be 3 or 6 samples. I apologize if I am not describing it correctly.

The signal source is very simple. I am just using an Agilent function generator to generate the signal, which is injected straight into the EQEP 1A pin. I was trying to simplifiy the situation as much as possible, which is why I am just using a pulse/direction format, not a quadrature signal.

Does that help?

Thanks again,

David

Hi David, 

Thanks for clarification and system description. Given that you have exhausted most sources of error, I'd try to capture the signal also with eCap unit, just to confirm that eQep is working properly. I'd also try and put a buffer to increase rise/fall times. And disable signal qualification, just to make isolation of the source of error a bit easier.

Good luck, and if you find the problem let us know.

Mitja

Hi Mitja,

I wanted to let you know that I ended up solving the problem. It was because of the qualification settings. The non-synced signals between the DSP clock in the incoming signals was in fact causing the problem even though I thought my filtering was well within an operable range. When I took your idea and tried disabling qualification all together, I saw worse error because there was so much noise on the line, so I overlooked that possibility.

Thanks again for your help,

David Tietz