3
$\begingroup$

The application

I want to implement the control of a photovoltaic inverter. The goal would be to keep the consumption of a microgrid (the power absorbed from the grid) to a constant value.

Notes:

  • I can only measure the grid load and the PV inverter setpoint. I cannot measure the PV production.
  • My measuring frequency is about 1s

Some numbers: let's say that I have a load varying (quite fast) between 500 and 1000W and a 500W solar panel, and I want to keep the power absorbed from the grid at ~500W (this is my target). Thus, if the measured grid load is at 769W, the PV inverter should provide 769-500=269W (inverter setpoint).

This would seem trivial, in the sense that I can control the inverter and tell it to provide exactly 269W. However, due to several delays (communication latency, inverter command reception time and the time it takes to adjust to the new inverter setpoint), it might take several seconds for the new command to actually take place: by the time the 269W setpoint is reached, the new requested value will probably be different (as the measured load varies).


The algorithm

I tried implementing a PID-like algorithm to fix this, and it seems to work more or less fine. However, compared to normal PIDs, there is a key difference. In my algorithm, I measure the grid load (PV = Process Variable) and calculate the correction that needs to be applied to the inverter setpoint (SP) based on how far the PV is from the target (T):

$E = PV - T$

$C_P = k_P \times E$

$C_I = k_I \times \int_{0}^{now} E(t) \, dt $

$C_D = k_D \times \frac{\partial E}{\partial t}$

$newSP = SP - (C_P + C_I + C_D) $,

where $k_P$, $k_I$ and $k_D$ are tuning constants and $newSP$ is my new setpoint (control signal) for the PV inverter. This is different from the usual PID process, since I calculate a correction to apply to the current setpoint, and not the setpoint directly. I can do this since the PV and the SP refer to the same physical quantity, and it seems to make more sense this way. This also actually reduces or eliminates the need for an integral component, since by design we have no steady-state error that needs to be compensated for.

However, I do not have any PID training, nor I have tried producing a first-order plus deadtime model of this system. I might be completely wrong.


Testing

I've been testing this setup and it works well for this application, better than I could make a normal PID work (but to be fair I have zero experience on tuning a PID). As expected, I found that in this algorithm the integral component is mostly harmful, as it only leads to oscillations: the P and I components do not need to balance each other anymore like on a normal PID, since the P correction goes to 0 once we reach the desired target, and the setpoint becomes stable. Thus, I have found myself using mostly a PD control.


Questions

  1. Does this PID-like algorithm make any sense in this case? In particular, the choice to act on the correction value instead of the PV value itself?
  2. Is this a standard control method? I would like to find some base-level theory on this.
  3. Is this application more suited to some other control mechanism?
$\endgroup$
  • $\begingroup$ What happens if the pv cannot provide the difference? Do you exceed 500W on the grid or shut the load down? $\endgroup$ – Solar Mike Feb 24 at 8:58
  • $\begingroup$ @SolarMike I exceed 500W on the grid. The PV will do its best in this case, no problems if it cannot match the requirements. $\endgroup$ – AF7 Feb 24 at 9:50
  • 1
    $\begingroup$ Re: Question 3) Given how slow the sampling is, you’ve plenty of time for processing... have you thought about machine learning? It’s possible you could start to recognise the patterns of certain loads on the grid becoming active etc. You say it changes fast, but perhaps the system could try to predict upcoming changes based on experience... At its simplest, it might expect the steeply rising demand to level off around the maximum demand. $\endgroup$ – Jonathan R Swift Feb 27 at 19:02
  • $\begingroup$ @JonathanRSwift thanks for the suggestion, but the controller is implemented in a machine which also has other things to do (things to measure and process) so it's already struggling a little bit. $\endgroup$ – AF7 Feb 28 at 8:07
2
+25
$\begingroup$

The algorithm

The standard control system is depicted below and has the following signals

Control system

  • reference signal: $r(t)$
  • error signal: $e(t) = r(t) - y_m(t)$
  • input/control signal: $u(t) = K_p e(t) + K_i \int_0^t e(\tau)\mathrm{d}\tau + K_d \frac{\mathrm{d}e(t)}{\mathrm{d}t}$
  • output signal: $y(t)$
  • measured signal: $y_m(t)$.

Using your notation, we get

  • $r(t) = T$
  • $y(t)$ = PV
  • $e(t) = r(t) - y(t) = T - PV = -(PV - T) = -E$
  • $u(t) = K_p e(t) + K_i \int_0^t e(\tau)\mathrm{d}\tau + K_d \frac{\mathrm{d}e(t)}{\mathrm{d}t} = -C_P - C_I - C_D = - (C_P + C_I + C_D)$.

So the first difference is the sign change you introduce by setting the error as $E = PV - T$ instead of the default notation $E = T - PV$. This is just a minor difference and does not affect the performance.

The second difference is in how you define the control input. The default method would be $$u(t) = K_p e(t) + K_i \int_0^t e(\tau)\mathrm{d}\tau + K_d \frac{\mathrm{d}e(t)}{\mathrm{d}t}.$$ However, you're expressing the control input in discrete time. The most straight forward method to translate this continuous type controller to a discrete time controller at sample $k$ is $$u(k) = K_p e(k) + K_i \sum_{l = 0} ^k e(l) T_s + K_d \frac{e(k) - e(k-1)}{T_s},$$ where $T_s$ is the sampling time. However, you could imagine that this controller would not have the same performance as this just a simple discretization method (forward Euler). There are many different discretization methods, but I'll not bother with it since I came across this site: http://bestune.50megs.com/typeABC.htm.

This site shows three discrete PID implementations (type A,B,C). You're controller implementation $$u(k) = u(k-1) + (C_P + C_I + C_D)$$ looks very similar to the once used there. However, they determine $C_P$, $C_I$ and $C_D$ in a different manner.

I think the base-level theory you're searching for is mostly on controller implementation and discrete time /digital (tuning and) control.

Tuning

The implemented controller is a PID controller, however this does not mean that you have to use all three terms. Depending on the system dynamics and the performance demands you can choose between the following controllers:

  • P
  • PI
  • PD
  • PID.

If there is an integrator present in your system dynamics, it would be a bad choice to choose a PI or PID controller (since the I-term is already embedded in your system dynamics). Based on the description of your testing results I assume that there is an integrator present in the system. Therefore, you should go for a P or PD controller instead (thus set $K_I = 0$). The choice between P or PD is fairly easy. If you increase the gain ($K_P$), while having $K_D = 0$ and you get overshoot, you should use the PD controller (since the D-action adds damping). If there is no overshoot, just stick to the P controller.

If you have problems finding proper values for $K_P$ and $K_D$, you could use some tuning rules e.g. the Ziegler Nichols tuning method.

Choosing a better control strategy to cope with the long delay and low sampling frequency is hard if you do not have any knowledge about your system. To overcome the delay you should have some prior knowledge about how your system is going to react on the input, since measuring the output includes the delay. Hence, you should move to Model Predictive Control (MPC), where the most simplest form would be the Smith predictor. An other possibility is to estimate the disturbance in advance (thus before measuring it) and already start reacting to it by means of feed-forward.

| improve this answer | |
$\endgroup$
  • $\begingroup$ Thanks for your answer. I do not thing the algorithm that is presented in the link is similar to mine, the key difference being in the way in which the corrections ($C_{P,I,D}) are calculated: directly in my case, as a difference with previous timesteps in their case. In fact (this is my biggest doubt yet) in their case the integral component is still crucial, while in mine I think it does not have a great role (might be wrong though). $\endgroup$ – AF7 Feb 28 at 10:37
  • $\begingroup$ You never showed what your implementation is to determine the controller outputs $C_{P,I,D}$. If the integral or derivative is crucial or not, is just a matter of tuning the coefficients $K_{P,I,D}$. The implementation should still be correct. Furthermore, as I pointed out, mixed up discrete and continuous time in your description above. Since I don't know the dynamics of the system and your implementation I cannot help you any further. $\endgroup$ – useless-machine Feb 28 at 23:11
  • $\begingroup$ I don't think the implementation really matters though. For what it's worth it is extremely similar to the "C" type of the page you linked to. My issue is more of a theoretical one. As I said, the Integral part in my system plays a different role to the "usual" Integral: I do not need any balancing between P and I around the target since the P correction is 0 in this case: in the "usual" PID, from what I understand, the P and I components are meant to balance each other out in this case. $\endgroup$ – AF7 Mar 1 at 10:18
  • $\begingroup$ I don't get the balancing. The Integrator (I-term) is used to remove a steady state error (which you get if there is no integrator present in your system). $\endgroup$ – useless-machine Mar 1 at 15:01
  • 1
    $\begingroup$ I added a bit more explanation about the choosing/tuning a PID. I hope this will help you. $\endgroup$ – useless-machine Mar 4 at 11:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.