Control loop precision

On Mon, 06 Jun 2016 08:47:18 +0200, alb wrote:

> On 06.06.2016 04:28, Tim Wescott wrote:
> []
>> Are you driving the PWM from software on a processor, or is it on the
>> FPGA?
> 
> It's in the FPGA, no software allowed :-/. In some sectors of the space
> industry software is still seen as a witchcraft and avoided at any cost,
> at least in some types of application. I find it completely idiotic but
> that's how it is.

Well, BAD software certainly has range to be Really Bad.  Although, given 
a big enough FPGA I think there's plenty of room for the designers to get 
in trouble with poor design practices.

Do you use one set of math hardware and do the control loop calculations 
with a state machine?  I assume you do because you say it's a small FPGA, 
and you have (I'm pretty sure) 512 clocks between samples.

If that's the case, then you could add the sigma-delta stuff into the 
state machine, hopefully without making it much bigger.

>> If you can take a quick look at the PWM command you'll know -- if it's
>> already bouncing all around from noise, then there's no need to add
>> dither of your own.
> 
> The unfortunate thing is that we're only building the controller, while
> the integration with the motor is performed on the customer site. On our
> site we simulate the motors with passive loads and any effect related to
> the motor is addressed by design (back-emf, dynamics, etc.).
> 
> But as Lasse mentioned it shouldn't be complicated to include a first
> order delta-sigma. I'd try to model it first and see the effect.

Can you ask your customer about noise level, or have them check?  FPGA, 
software or vacuum tubes, fewer functions means fewer opportunities for 
bugs.

-- 
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work!  See my website if you're interested
http://www.wescottdesign.com

On Sun, 05 Jun 2016 15:41:12 +0200, alb wrote:

> Hi Tim,
> 
> On 05.06.2016 01:55, Tim Wescott wrote:
> []
>>> Lasse, you beat me to this. I was going to say that to shape the
>>> spectrum of the dither noise you'd need to put feedback around the
>>> quantization.
>> 
>> Fully explained here -- at least up to a 1st-order sigma-delta.  I
>> don't know more is necessarily better for most plants.
>> 
>> <http://www.embedded.com/design/configurable-systems/4006431/Sigma-
delta-
>> techniques-extend-DAC-resolution>
> 
> While the paper in general is quite clear on the advantage of the
> sigma-delta, I didn't quite understand the examples, especially the
> first one.
> 
> On the phase-locking system, why would you need a 10 or even 12-bit DAC?
> I reckon that for 0.5 degree requirement a 200/512=0.39 degree would be
> more than sufficient, therefore a 10-bit would suffice.

My son and I have a running joke about a world where we all have personal 
time machines, and can go back in time to harangue our past selves when 
they're about to make a mistake.

At any rate, I know it couldn't have existed in 2004, because Future Me 
did not appear and tell Past Me to double-check his math.

On re-doing my math, I get a peak-peak variation of about 0.2 degrees.  
This wouldn't be tight enough to satisfy me (thereby raising questions 
about "well enough"), because you can't count on any one thing to be your 
entire error budget -- my usual rule of thumb is that, if you're not 
doing a detailed spreadsheet, pound the easy stuff down to 1/10 of your 
total error budget, and get the hard stuff down to 1/4.  And, if you 
can't do that, do a spreadsheet.

So, to get down to 0.02 degrees you'd need more bits -- I'm not going to 
do the calculation, but I hope that it fairly works out to 10 to 12 bits.

> Secondly, how do you get to the 0.031 degrees/sample^2 with the
> sigma-delta? I didn't quite get that.

With a math error.  Once again, Present Me is looking for a time machine 
to go back and harangue Past Me.

I must have been assuming a unidirectional DAC, going from 0 to 255 (I 
was actually drawing on my first paid gig doing motion control, and that 
was the case then).  With 8 bits, the acceleration is roughly 8000 deg/
sec^2/count.  To get that into terms of sample rate just substitute in Ts 
= 1/(sample rate):

(8000 deg/sec^2/count) * (1/100Hz)^2 = 0.8 deg/Ts^2/count.

Now again at 8000Hz:

(8000 deg/sec^2/count) * (1/8000)^2 = 125 * 10^(-6)

The theory is still valid, but I think I need to republish the paper, 
with corrections.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!