GeoBrick LV speed control problem

[wlewis]

I am using a GeoBrick LV to drive a brushless servo motor on channel 3 using Hall sensors as the encoder input (I70300 = 11). When jogging the motor at speeds up to approximately 600 ct/s, the motor runs correctly. At any higher speeds, it runs too fast, then slows down significantly as the position loop error increases sufficiently, then speeds up again to faster than the requested velocity.

 

In open loop, the speed increases linearly until approximately 10% output (#3O10) where it is running at bit over 600 ct/s, and then it jumps non-linearly to around 1200 ct/s when the output is increased to 11 or 12%.

 

I have tried a different channel on the same controller (channel 2 vs channel 3) and the result is the same.

 

Some of the settings on this controller are:

 

I357=2963

I358=0

I366=1399

I369=8383

I370=1

I371=192

I372=683

I7000=1473

I7030=11

[curtwilson]

You are using the 1/T interpolation function of the encoder conversion table to increase the resolution of your feedback from the 6 hardware states to 192 estimated states. It's great for smoothness, but it introduces time delays.

 

The ECT executes as a servo task, which always comes after the phase task. And most people run the servo update at a lower frequency than the phase update (default by a factor of 4). With a divide-by-N to the servo update, you are then using feedback position that is 1 to N phase cycles old. This does not matter much at low speed, but at high speed it can be important. I suspect this is what you are seeing.

 

I would try two things:

 

First, set your servo update equal to your phase update (I7002 = 0, I7102 = 0 if you have it). If you don't want to retune your motors for a new servo update rate, set all your Ixx60 parameters equal to what I7m02 used to be. Now the ECT will update at the same frequency as the phase tasks, so you will always be using 1-cycle-old data.

 

To improve further, you can use the Ixx56 "phase advance" parameter that is intended to compensate for time delays from input to output in the phase routine. All systems have time delays; you just have this extra one, so this compensation is more important. Most people set this interactively, but note that typical numbers are much smaller than 1.0.

[wlewis]

Thanks Curt.

 

I will test this at the next available opportunity, which will be in a couple of weeks. I'll let you know how it goes.