PID controller

The integrator part of PID may be slow, it should be adjust a less difference to get a zero value of the remaining controlling error

It is usual not sufficient to use a float type for the integrator. Why: The float format has a mantissa of 24 bit, and hence a resolution of 2^-23..2^-24 or 0.00000006..0.00000012. Your factor for the growth of the integral may be for example 0.0001 because the integration time is 10000 * Tstep, it is 500 ms for 50 µs step time, an expectable value. Then on a difference wx = 0.001, no more is added because the product is < 2^-23. 0.001 is 0.1%, and this is the remaining error. The digital integration hangs. An analog integrator is better.

But you see it depends on the timing relations. If you have only fast integration times, or you use slow integration times with accepted error, then float may be sufficient.

For a specific solution you can decide whether a float resolution of the integrator is sufficient. But for a common usage you have an additional necessary decision which complicates the development.

Hence a common way is: Using double. You have a resolution of 0.00000000000001, that’s enough. A simple decision is: Using double instead float for all. Why it is worse for most embedded controlling? :

Often embedded control processors have float arithmetic on hardware, not double. Using double is a simple decision in C programming, but has impact to the calculation time. The calculation time for double is maybe 10 times more then for float because it is not simple "using two float operations for one double`". `double is possible of course, but with specific machine instructions. The worse decision is: general using double. If you have in the moment enough calculation time, some enhancements may be destroy this approach.

The integrator of a PID control has usual the output range of the actuator. It is defined. It means, not float, instead fix point is proper for that. It is also not necessary to increase the accuracy or resolution for small values. Small values should be handled in the same resolution, the resolution of the actuator is given.

Hence, three solutions are possible:

The solution 1) is of course proper for a controller, which has no float arithmetic. It is recommended to use either an int32 format for all, or int16 for input calculation and int32 for the integrator, or int32 for input calculation and int64 for the integrator. In opposite to float vs. double a 32 bit addition in a 16 bit controller or a 64 bit addition in a 32 bit controller is only the double effort, and it is only necessary for the integrator itself, not for all. It is proper.

But, the solution 1) is not optimized for a controller, which supports float in its hardware. Why? float is fast, if supported. In opposite, integer arithmetic needs usual additional shift operations for multiplication. It is real slower than float. Hence the solution 2) or 3) is more proper for a float supporting controller.

In conclusion, several implementations of PID_ctrl_emC are offered in the emC library and also as Simulink SFBlocks:

A special int16 PID or int32 PID is not offered. If you use a 16 bit processor, often the lesser and native solution of 16 bit is proper. For a 32 bit processor, calculation with int32 is not a higher effort and hence anyway possible.

If the input value wx as controlling error is given, then the integrator of the PID ctrl growths, either to positive or negative. On a closed loop in a near static state the input value is anyway zero or is oscillating near zero, so the integrator does not go away. That is expected.

But, if any false condition is met, especially an opened loop in control, or an actuator limitation, and a controlling error remains, maybe also temporary for a little bit longer time, the integrator goes to its limits.

The worse scenario is, the integrator is not limited and the addition in machine code overflows. That is not usable.

Hence the so named 'integrator windup prevention' is very substantial.

There are more possible solutions. But usual the windup is only a secondary problem. It should be prevented, but in normal states it is not present. Hence a simple solution should be given.

The windup preventation for all emC PID control works in the following manner:

See the following result in closed loop as example:

This example can be found in emC/test/cpp/emC_Test_Ctrl/test_PIDx_Ctrl.cpp. Parameters:

The red curve is the x value, the output of the environment or system. As you can see, the system is a little bit sluggish. It needs a while till the output is changed though the output of the controller is on max for the step response, the green curve. It is a smoothing 3th order with the above shown factors (fT ~= Tstep/Ts). If the integrator starts immediately, it will reach a too high value during limitation, and on left limitation the integrator is too high.

The integrator curve (violet) is firstly hold on its current value (0 because it is a step response from 0). Why?

The correct feedback for the integrator is broken by the limitation. The integrator has an abbreviating behavior in comparison to the normal unlimited reaction, till the system is in a proper range. Hence it is helpful that the integrator does not work, holds its own value while limitation of the output. Only if the limitation is left, the proper calculated behavior for non limitation situation allows to calculate the integrator. Then, for this example, the integrator reaches a value near the necessary output in an expected time. Because of the system is 3th order, you see an oscillation for fast control.

In the diagram above you also see right side a lesser step response without limitation.

To see and compare the effect of this integrator wind-up prevention, compare to the following image, where this wind-up is switched of (by changing the PID software):

As you see, the integrator, violett curve, starts immediately and runs to an overflow. The output of the environment (red) overruns because of the longer time high output. It needs additional time to capture the correct value of controlling.

The question for the algorithm is: Need the integrator an extra limitation additional to the output limitation (software calculation time effort). The answer is no, because if the integrator is in the proper range, the addition of the P value is anytime in the same order as the direction of integrator changing. It means if the output is not limited, the integrator can work and will not reach the limit.

But: What’s happen if the limitation itself is changed to a value lesser than the current integrator value? Then of course the integrator value should be checked whether it is range to the new limit. That is implemented in the setLim_PIDx_Ctrl_emC(…​) operation and only executed if the limits are changed. This may be done in another step time or only on demand, it does not use calculation time in the normal step routine.

The C-code for the PIDf with wind-up shows as:

The wind-up preventing solution is very simple. It is combined with the limitation. It does not need additional calculation time.

You see that the integrator is calculated after building the y value. That is admissible and more simple for the machine code. But if you are very near on the limit, this addition can cause a value over the limit. That is not a problem for the algorithm, because in the next step time the limitation is detected and the integration is not done. But you should not stay on the limits of the numeric value range. Elsewhere an overflow may occur. This overflow is safely prevented if it is checked in the parameter calculation that the growth, calculated with the limited P-part, is not too high. That is done. The assertions (ASSERT_emC(…​)) are always true. It is only for test and documentation.

The D part of a PID control should stabilize the control. If the D-part is correct tuned, then a fast change of the input signal decreases the output, so that it should be slower. That is the view in the timing. From view of stabilization criteria (https://en.wikipedia.org/wiki/Nyquist_stability_criterion) the D-part forces a phase advance, so the Nyquist-point is passed right side. So the theory.

The output decreasing effect of the D-part is sometimes misunderstood. But look, the feedback value in the closed loop is used with - sign. Fast changes of the feedback value from the environment or system (x) forces a negative impact on the controller output. Only if the D-part is too high, it oscillates. But, from view of the reference value, the effect of the D-part is positive. The controller input is usual (w-x) whereby w is the reference value and x is the feedback from the outer system or environment. It means that change of the reference value has a high increasing effect to the controller output.

Regarding the last statement, it is interesting that sometimes the D-part should not be built with the control error (w - x), instead only with the controlled value x. Then the stabilization effect is also given, because the loop is closed. But a change of the reference value w does not force a D-part as 'acceleration'. Especially on a step response the D-Part will be high on beginning because of the suddenly high change of the reference value. This can be prevented.

Because also of the reason the the D-part can be built with different approaches, smoothed or as difference to older values, the PID*Ctrl_emC has an extra input for the difference named dx and an associated Parameter dt for the step time spread of this dx. You can decide how the D-part is built. smoothed or not, from w-x or only from -x.

If you have a exploration of a controlled system with pure mathematics, you can follow the theory on paper and pencil. If you have a simulation with a proper solver which solves near the physic (continues sample time) and double or also float arithmetic, you are near the mathematics. You get an behavior adequate to the mathematics.

But for real applications you have always defined fixed step times for controlling. The step times are often interrupts of a controller, and they can work only with defined times. In a simulation you can select also this fixed step times. The mathematics support that for example with the theory of z-Transformation.

But their is still another problem. Your calculation can be use float (or double) accuracy, but a measurement and actuators has anyway a defined and limited resolution. You can use an ADC (analog digital converter) with 16 bit resolution it it is possible but often only 12 bit are available. For fast measurements sometimes you get only 10 bit. Also an actuator has a limited solution, for example a pulse width modulation with a fast frame, but your controller has only a limited clock frequency.

If one have a sampled system with an integer measurement signal resolution, the changing of the input values from one to the next step are sometimes less with steps. This is typical, because the sampling rate of the controller should be high in comparison to the system behavior. If the change is less, the difference of change is also less or inaccurate. If the D part is immediately built with the difference of the inputs, then, because of the inaccuracy in fine solution, the D-part has a high noise. That is mostly disturbing.

Example: In a fast sample time (for example 50 µs for electrics or 1 ms for mechanical) you get an input signal which has a less growth or near zero. Then the ADC input switches from one value to the next as accident because of noise if the growth is near zero, or it switches in more as one sample times. For example your signal is changed from 50% to 51% for a mechanical system with 1 ms sampling rate in in 20 ms. If you have (only) 10 bit resolution, the measurement values are

As you see you have stages. The differential is

On the other hand for stabilization it is necessary to regard very fast changes. That changes are a point of interest, which are in the time of the oscillating frequencies of the system, or the frequencies near the 0-dB crossing in the Bode Diagram (https://en.wikipedia.org/wiki/Bode_plot).

Often the necessary D-gain inclusively kP is a factor of for example 100.0 (Example kP = 5.0 and Td = 20* Tstep = 20 ms for the mechanical example). Then the D-Part in the output has shocks of 100, which is 10% of the output with the same as input solution. This is bad.

A floating point solution for all signals, near mathematical, is nice:

A little bit noise is shown, but the differential is stable ~ 0.4 and the output is a signal with this noise in range 37.0 .. 43.0 which is acceptable. The pure mathematics may not have noise.

One possible solution of that is: Combine the D-part with a smoothing. That is a general solution. One can set the smoothing time to 0, then the input of the D-part is immediately, not smoothed.

It is one stage harder: You should have a 2-step smoothing as the following examples as simulation results (which follows the reality) shows.

You can first build the D-part with the input differences, and afterwards smooth,

but it is also possible to first smooth the input and then built the difference from the smoothed signal. The second one has the advantage that also the input value can be visited in smoothed form (data viewing).

For the double smoothing twice smoothing from the input is used, from the second smoothing the addition part is the D-part:

Another possibility to build a smoothed D-part is: Using the current value and building the difference not with the immediate previous value, instead build the difference with a little bit more older value and divide by the number of values. This division increases immediately the resolution of the differential. Usage of an older value to build the difference is similar as smoothing: It result in a dead time. On smoothing it is a phase difference, or with another view, the smoothed value contains and depends from also the older values.

How is the smoothing of the D-part implemented?

Because there are at least two possibilities, and the differentiated signal may be built also with stuff outside, the Controller has an extra input for the differentiated value. So it can be decide outside how to build.

For smoothing there is a function block either T1f_Ctrl_emC as simple smoothing block or even T2f_Ctrl_emC for a two-stage smoothing. Both FBlocks have a dx data element useable as output. The dx is related to the step time. It means it is the value of change in one step cycle.

Look on the implementation of this FBlocks:

You see the two stage smoothing. Follow the results in the after-next chapter.

The other possibility is using a simple delay FBlock Delayf_Ctrl_emC. This FBlock stores data values in a ring buffer and returns a requested earlier value. Building the difference between the current and the returned earlier value is the differential. This differential is related to the delay time. It means the value is greater as for using the smoothing block. To prevent additional effort for dividing (multiply with a constant) this is regarded in the parameterizing of the PID controller.

To see real test results, follow the next curve. It is executed by the same algorithm as the integrator wind-up test. Here the D-part is activated, which reduces oscillation. The following controller parameter are used on the same environment parameter:

In comparison to the solution without D-part, the P-gain (kP) is higher, 30.0 instead 4.0, because the instability without D-part is solved by the damping effect of the D-part. The D-part has no smoothing, but the resolution of the input signal is +/- 20000, adequate to an ADC bit width of 15 bit.

The environment output x (green curve) is fast towards the end value, very more better than without D-Part. There is only a little bit overdrive. The overdrive is seen on the P-part (proportional to the controlling error wx, but with the P-gain, here 30.0) which is near the 0. This is also true on the non limited step response from 0.5 to 0.4 right side.

The D part is the violet curve. First, it goes in the same direction as the P-part because of the rising reference value. But after a small time, the rising of the input x value forces a negative value till max. But both are not effective because the controlling error forces a high P part till limitation. Hence also the integrator is hold, and the reaction of the system is firstly the same.

The controller output lefts the max value on an earlier time , because the negative D-part forces this limitation-left already on P-part = 2.0, not only on 1.0 because the D-part delivers -1.0. For this reason the integrator starts a little bit earlier which is also proper for the result.

The D-Part decreases the output (green) and the system stops changing. Then the output oscillates a little bit, and following the environment’s output x (red) goes in spurts to the final value. This is not so very nice, but it prevents the overflow of the output x (red) which may be necessary. The system itself is susceptible to vibration. That is the fact.

On the unlimited little step response in the mid you see the adequate behavior. Firstly the D-part goes in the direction of the step response, but then it follows changing of the x value. It damps the x value (red) which would be have elsewhere an overdrive.

You can also see a little restless in the D-Part and in the output. If you would use an only float simulation also for the input value this restless will be not seen. The float resolution is 24 bit, only on a large zoom it may be visible. If you use double - nothing. Such results from a theoretical exploration are proper to explain theory or maybe proper to offer a possible result, but they are not proper for practice.

The resolution of the input signal is programmed as:

For the value quantization the expression (int)(xquant*(wCtrl - xEnv)/valrange + 0.5f ) is essential. It converts the values to a range adequate xquant, then removes the fractional part by building an integer. The valrange is 1000.0. It is only necessary because of course the visible effect of the resolution depends on the zoom for the curves and the used range of possible range. The values for w are 500 and 450 to compare it with the interger version of PID, it is the half of possible range for the resolution.

Now compare it with a resolution of 12 bit which may be familiar for some measurements. For a mechanical system it is a resolution of 0.5 mm for a spread of +/- 1 m.

The only one change is

You see the resolution also in the P-Part (red) because for a gain of 30.0 the step width is 15.0 in the output by changing the input signal in one resolution step 0.5. The D-part is 'terrible'. Any step in input forces a change of D-part and output from 300, approximately a quarter of the output range, which is the result of the D-gain Td/Tctrl = 20. But, the output signal of the environment does not show this restless. It is filtered by the environment (a 3^th order smoothing system). The restless is visible only on the output which is an actuator signal. This may be non acceptable.

Then compare it with smoothing of the D-part. The problem on smoothing is: The P-gain kP should be decreased and you get nevertheless more oscillation. This can be simple explained by a Niquist plot or also Bode plot. The phase angle is more worse, more near >180 degree, so the system get instable on higher gain. The same effect is occurring if you have a 4^th smoothing time in your system.

If you compare this result with the result without D-part, it is really better. If you compare with the higher resolved x input with higher gain, of course it is more worse, but it is the possible one. You see a little bit restless in the output, but only on exactly viewing.

To see this a little bit more exactly, the zooming for D-part and P-Part are increased. The P part shows the measurement value in 0-level, as controlling error:

The scaling is 10.0/Div instead 250.0/Div, sorry the graphical tool CurveView is a little bit faulty. The P-Part (red) is (w-x) * kP. Because kP=6.0 and the visible step size is 3.0, the input x is quantized with 0.5. But the output is quantized because of the P-part with this visible step of 3.0 because of kP. Additional the D-part is added. This restless is 0.6% from the current value 500.0. This is smoothed in the system, on the system’s measurement signal you can only see a little bit movement arround one step of the x input. But the actuator is restless. If you have a mechanical system, it is a restless movement around the current point. This comes from the effect of resolution of the input with 12 bit.

What is the result of a only one stage smoothing, with approximately double time:

The osciallation is similar the same. But the D-Part and also the output signals has more hard shocks instead rounding shocks, of course result of the 2-stage smoothing.

In comparison to the non-filtered D-part: You have here as step response of the controlling error (red curve) an area with D-part value and the time. The area is the same as an only one impulse (dirac, https://en.wikipedia.org/wiki/Dirac_delta_function). But, of course, it is worn away in time.

Average:

Look on the result in smoothed form, the result without smoothing is really similar as above, The difference between the values is 12, hence the dead time is 6 Tstep or 0.3 ms for this example.

The rest of the arguments are the same, he ndxDelay is used as:

The algorithm to built the smoothed differential can be seen as 'average of the differential from n points'. The disadvantage of this algorithm is: It needs memory for the possible number of points to build the average. Depending on the possible smooth time of ..16*Tstep. It needs 32 value buffer in this test example. More is not possible, or dynamic memory should be used.

Also here it is the same with the area of the step response to the changing of the controlling error. Instead a dirac impulse you get a square area with value * time with the same value. Note that the dirac impulse in a discrete time system is not infinitely high and zero-width, it has also an area with the appropriate high to the step time width.

Non-restless output in stable state

To get a non-restless output for example for a mechanical system it may possible to decrease the D-part on a less controlling error, respectively on reaching the end state. On electrical outputs (voltage converter) usual the voltage has not a static behavior, it is alternate current. The smoothed shocks in the actuator signal may be acceptable. The effect is filtered by chokes and capacitors in the electric circuit. But for that the rounded shocks may be better as hard shocks in a pulse width output.

To get an decreased D-part, you can use the FBlock

The smoothing here is called with

If you can see, the gain is decreased in a time if the value is below the xmin. This FBlock can also be used for a non linear controlling, for example to provide an higher gain on higher controlling error for a fast reaction.

The D part on the stable state becomes really lower. In following also the movement of the environment is lesser. One can also adapt such possibilities to the P-part. If you have really a less remaining error, the P-part can be lower.

Especially on a mechanical system with some stable end positions, this is a proper feature.

The D-part is responsible to damping from view of the system’s or environment’s response, and it is similar responsible to force fast changes in direction of reference value changes. This may be interesting also on ramp stimulations.

But only seen for the aspect of damping, it is also sensitive to build the D-part only from the environment response, not from the changing reference value. That is supported by a special input of the controller to build the D-part, named wxd. You can connect the same value as wx there then it is the standard behavior. If you only connect the input of the controller (output of the system or environment) 'x' then you have to negate it, use -x. Then you get in this example the following result:

In comparison with the behavior using wx for the D-part you have lesser oscillation of the controller output because the effect of w change is prevented. But also the changing of the environment output 'x' is even lesser. Here you have no temporary overdrive, only damping. It is a specific decision to decide because both possibilities. The core algorithm of the controller supports both, without more effort than the second input value.

The considerations of smoothing the D-part are the same.

The core algorithm are organized as C struct for the data and as correspond C routines (extern "C" declaration in C++. So it can be used in pure C environments.

There are wrapping C++ class definitions which allow a smart usage in C++ programming environments. The code overhead between C or C++ is exected as zero. The wrapper are inline operations, which are expanded to the immediately C routine call. Only the calling and data environment is adapted to C++ approaches.

It is important the the PID*_Ctrl_emC algorithm is executed also in a very fast time. This is true also for the float variant (on more rich controllers) and the integer variants for poor controllers. Hence focus on what is important in which time is necessary.

For example prevent a division in the fast step time though parameter may be changed given in natural units.

The PID control is generally divided into too parts with different data struct:

That dispersion is also used because more as one PID*_Ctrl_emC for example for more axis of a movement system can and should use the exact same parameter setting. Only one instance of Par_PID*_Ctrl_emC should be exists. Then also changing of parameters are exact similar effective. The relation between both is an Aggregation (as in UML) from the PID*_Ctrl_emC to its Par_PID*_Ctrl_emC, as simple ascii UML class diagram:

The step_PID*_Ctrl_emC(…​) is that operation which should be executed unconditionally in the controller cycle. This may be a 50 µs cycle for electric control. Next this operation is completly shown (referenced from C file to this docu):

Of course also the D-part alone should be limited. Elsewhere it is possible especially on a large step response, that a negative D-part is added with a P-part the result is not limited, but the P-part is high positive and the D-part is highly negative.

The comment before integration is a hint of functionality on limits, which is asserted by the ASSERT_TEST. This assertion is (should) only active in test situations. The case is prevented, is never expected in runtime. It has completely no impact to the calculation time in an application.

On demand means either in an event system, or with specific conditions.

A cyclically change of parameterization may be necessary if no parameter event is available. This is for example true in a standard Simulink environment or also on simple application solutions. But the changed parameters may be necessary not in the fast step time, can be done in a slower step time, or in a loopback with a maximal cycle time. It can be also called on demand. For cyclical call this routine checks first whether somewhat is changed. It calculates only newly on given changes:

In this routine a double buffer system is used. Firstly the new values are calculated in a second not used buffer. Then this buffer is declared as current with on atomic operation. The step_PIDf_Ctrl_emC(…​) does never see inconsistent parameter values.

Here the ASSERT_emC can be left active also in runtime. It is not a ASSERT_TEST_emC. It needs a little bit time to check but not to calculate the additional values to show because it is implemented as macro. If the user gives a faulty Ts, then a TROW occurs which can be catched. This is possible also in a runtime application. See chapter Assertion in Base/ThCxtExc_emC.html

Some more operations are existing which can also be called on demand, in an if condition, for only test conditions or never used:

A reset of a controller may be necessary for some operations, for example on the opened loop if the loop is opened because physical conditions. For example a main breaker is not closed for electric lines. Then the controller should be reseted by reseting of the parameter using the set_Par_PIDx_Ctrl_emC(…​) operation. You may not need new values for the parameter, use the stored one. Use only the reset argument.

A reset can be given either with the set_Par_PIDf_Ctrl_emC(…​) operation see chapter above especially in a slower thread or in a background tassk, or it can be given in the fast controller thread or interrupt by calling:

This routine is implemented as inline. It has less operations which can be better expand in the current program than execute a call intruction. A reset can also be given with the set_Par_PIDf_Ctrl_emC(…​) operation above.

The controller parameter set has a en boolean element. This is set either immediately with this reset_Par…​ routine or with a new parameter set in the set_Par…​ routine or also initial via init_Par…​. Hence you can determine both on startup and on new parametrizing whether all controllers connected to one parameter set are reseted or enabled.

On reset the output of all controllers which are associated to this Par_PIDx_ctrl_emC is set to 0, the integrator is set to 0 (important for enabling after) and also the smoothing of the differential is cleared. So on eabling the controller starts with a smoothed differential and 0 for the integrator.

You can change the output by setting the variable yAdd in the struct either manually by the Inspector tool or with a special part in the software. This is only thought for debugging.

The limitation of the controller can be changed in the running state, for example if a following limitation condition occurs or the limitation of the more complex calculated output should be controlled. Note that the limitation value is symmetrically, and this value must be lesser or equal than the given maximal value on constructor.

If the limitation is never invoked, the maximal value on constructor is valid for that. The operation can be called conditionally. But it have to be executed in the same thread (interrrupt) as the step routine, because consistency of internal data.

Here the strategy "correct a violate design by contract, don’t report it" is used. It is adequate because the value of the limit should of course be appropriate to the given ranges. A faulty too high limit value is replaces with the maximum, a deficient behavior is prevented.

This operation can also be used only in special cases, for example if a proper value for the integral part is saved before, and the state should be recovered. Here also a faulty value for intg is simple limited to an admissible value.

In the correct order this operations should be named firstly. But often the user may firstly interest on the step routine. The ctor and init is executed only one time.

The constructor for the parameter is widely empty. The assertion can be remain active also in the target system, it is only checked one time and needs hence only ROM space, but it detects a maybe memory error if the software was quickly changed and hence sometimes dirty.

The initialization with the ObjectJc* othiz argument which should refer the whole data and returning the correct pointer, after assertion test, is an emC convention, see chapter Initializing in ObjectJc_en.html

The variable Tstep is not used. It is especially for Simulink S-Functions as information for the Sfunction wrapper about the step time of the step function if the step time is no elsewhere defined. It is a non-tunable parameter of the S-Function.

This is the constructor of the controller itself adequate to the parameter constructor. But this constructor stores the given Tstep temporary (in thiz→yctrl) to compare it with the given Tctrl on parametrizing.

The both constructors should be firstly executed on startup before init. Both expects a basic initializing of the ObjectJc base structure. The ObjectJc base data contains some information depending on settings see ../Base/ObjectJc_en.html. The construction of the ObjectJc basic data should be done on the creation of the instances, for example as static in C with the INIZ…​ macro, see example:

For C++ usage this is done in the {c++} constructor, see

This can be adequate done also on dynamic allocation in C.

The init operatios should be executed after construction.

The init operation of the parameter does not need any other information. Hence it is finished unconditionally (return true) and sets is initialized status setInitialized_ObjectJc(&thiz→base.obj);. Before that all parameter are calculated. The set_Par_PIDf_Ctrl_emC(…​) routine is executed one time, see chapter above: set_Par: Cyclically called in a slower thread or on demand.

For using see chapter Construction and initialization in startup.

Look firstly on the data of the controller itself:

The data contains not only state variable (which should be stored and remembered). It contains also some intermediate values which can be evaluated for internal view. If you look on the graphical shown results in chapter Some implementation details this results can only be shown because the access to the intermediate values are possible. If the controller should be used on systems with really less data space, a conditional compilation is given in the integer variants of the PIDi_Ctrl_emC, valid for the whole application, see sources. For controller which supports floating point operation usual this less additional memory space is not a problem.

The meaning of the ObjectJc as base data is for data inspection, size check and for the initializing state, see also ../Base/ObjectJc_en.html.

For the integrator, both 32 bit and 64 bit are preferred. The 64-bit-Variant can use exactly the same data, the same parameter set. The difference is only in the data width of the integration.

All data are aligned on a position which is able to divide by its size. Thats why the position of the qI is tuned and commented and a sp (spare) element is given. It is not an disadvantage to do so, but it clarifies data images for example if you get a data excerpt for debugging or tracing approaches. The size of the data should always be divide by the sizeof(void*) which also helps on data sorting, if the data size is not too small.

The data of the parameter has two parts. Firstly the prepared data for controlling. In the step_PIDf_Ctrl_emC(…​) operation only this data are used :

How this values are calculated - see chapter set_Par: Cyclically called in a slower thread or on demand

The data of the parameter FBlock contains two areas for the ParFactors_PIDf_Ctrl_emC which are used as double or switch buffer on parameter changes. The calculation of the factors with the changed values is firstly done in the not used yet buffer. Afterwards the pointer f to the buffer is switched, see also implementation of set_Par_PIDf_Ctrl_emC(…​ ) This assures data consistency, because the set_Par_PIDf_Ctrl_emC(…​ ) operation is called usual in another thread. If this is not done, intermediately the controlling may be faulty (instable or slow).

The PID*_Ctrl_emC and the Par_PID*_Ctrl_emC are also presented as C++ class.

It is presented here only for the PIDf_Ctrl_emC, the Par…​ is similar:

The struct definitions have alwas the postfix _s because the identifier without _s is preferred for the class name.

The class inherits all data of the struct and has no more own data. It hasn’t also no virtual operations and also not a virtual destructor. This is not necessary here. Virtual operations are sometimes not safe, see also ../Base/VirtualOp.html. Hence the class data are exact equal to the struct data. No additional effor in data.

All operations are presented by inlined class operations ('methods'). They call the C level functions. Also here no additonal effort. The code using C++ is exactly the same as C code.

But why using C++: For this approach it is better to read. You can write:

If you have a class instance myData with composites (nested instances) for the pid…​, one can use the pointer operator or use a reference. It is simple to read. The machine code is the same. Instead in C you should write:

Only you have the type designation in the name. This is an information for reading the source, but this information can be gotten on viewing the pid2 element too, and it decreases flexibility.

But look to the constructors, this is the difference. C has a simple approach to instantiate static data:

whereby INIZ_…​ is a macro for a proper initalizer list { …​ }. This macro initializes especially the ObjectJc base data.

This is not possible in {c++}. If you want to create a static instance one can write:

The invocation of the ctor_PIDf_Ctrl_emC() is no more possible in the application’s startup code, instead it is executed in the automaticly application construction phase before reaching main. That is not an disadvantage, but it is harder to debug. If you set a breakpoint on main, the construction is already done. The given sampling time (constructor parameter, 50 µs in the example) can also be a variable, but it should be defined on static instantiation in a static way too. That is because it is a construction argument.

If you have a class which contains some other classes, especially this controllers, the situation on static initialization of the whole composed class is the following:

The situation is adequate. The constructor of the whole composed data are executed before main() is reached. But you can set a breakpoint in the constructor. The values for step times and limitation are given here as numbers, because it is only one time in the application. But this numbers can also be defined from another data source (with generated header) or from before given other static data. Also constructor arguments are possible and may be recommended.

C++ is primary thought for a dynamic instantiation:

As you see now the constructor is executed in a routine which may or should be called on startup time of the application after main(). You can use a heap in your embedded application only for startup allocations. That may be a proper style guide. Hence you don’t need delete and destructors, because the data are destroyed only on reset of the hardware. But you can have also destructors if necessary.

The rest is adequate in C in C++. See also remarks for init_…​ in chapter Construction and init

You can also refer to ../Base/ObjectJc_en.html#initC.

Independent of the fact of reset, you can set a variable open in the PIDx_Ctrl_emC data either initial by parameter of init_Par_PIDf_Ctrl_emC(…​, bool openLoop_param) or changed only manual by a debug tool on runtime. If this variable is set, the controller output is stored in the element PIDx_ctrl_emC::yCtrl so it can be viewed or tested, but the output of the controller in PIDx_ctrl_emC::y remains to its given value, which is 0 on startup. It means you can open the controller loop any time whereby the controller output is hold in a maybe before found stable working point. Now you can make some tests. If you close the controller afterwards, it remain working. Such tests can also be done in practical use in a real physical environment. But you should assure that the system is stable, no disturbing effects occur. You can made such tests also for a limited time by an automatism. The usual application for that is: Check the transmission function of the opened loop to get results for stability estimation.

You can switch off the integrator by setting the disableIntg variable to 1 in the PIDx_Ctrl_emC data. Then the integrator does not go away on remaining wx inputs. If you close the loop afterwards, the integrator was remaining on its proper value. Then measurements are done without consideration of the I part. You can also follow the program:

This is possible and necessary also as test case in a open loop szenario (see chapter above) else also for special tests in closed loop.

The variable disableIntg in the data struct of the controller can be set to non-zero, then the integrator remains on the last current value. You can change this value by a debug tool effective for the currently controller by changing the variable yIntg. If you set disableIntg =0 then the integrator continues of course with this value.

There are 16- or 32 bit controller. It is the width of the integer hardware arithmetic. Usual it is also the register width. But a 32 bit controller can also work usual with 16-bit register and memory access. The next question is, how is the int type defined by the compiler. In C and also C++ language the bit width of int is not determined, it is usual the bit width of the CPU register. But, some controller has 32-bit-arithmetic and define the bit widht of int nevertheless with 16. This ensures compatibility with often used older programs which uses this 16 bit-int definition.

Because of this undefined situation from view of an independent C/++ program the type

is used. This should be defined in the compl_adaption.h either as int or long or also as short for special test conditions depending on the compiler definition for 'int' and proper to the length of the arithmetic unit in the controller. Adequate the value of

should be defined as 16 or 32 adequate to the defined type. This type INT_NUM_emC is proper to use for the simple calculations to make it fast on the controller. For the PID controller it is the type of inputs and outputs.

Independent of the bit width of INT_NUM_emC, for the PIDi_ctrl_emC it can be decide to use 16 or 32 bit width int for the internal values of P and D. Why?

If you use 16 bit int as input, and you have 12 bit as output width, you have only 2 bits to fine-adjust a kP-value if you store the (kP * wx) also in 16 bit. Follow the calculation example:

The wxP = wx * fP is calculated in the example with 0x1200 = 0x0400 * 0x0005. The wxP is limited to a max value of 0x2710, because also the I and the D-part can have the same value, and the sum of all should not cause an overflow. It means the number of bits for the intermediate result is not 16, it is only 14. Hence the resolution of the kP part is limited to 0.25. This may be too inaccurate. It the output has 14 bit, the kP resolution is limited to 1.0.

Hence, working with a 10 or 12 bit output gives the opportunity to have proper maybe sufficient kP resolutions, but a higher resolution of the output decreases the resolution of kP, if you have only 16 bit.

Calculating for addition or subtraction with 32 bit is not a high effort though the processor supports only 16 bit arithmetic. It needs two assembly statements using the carry flag and two 16-bit-locations (register) for the operands. The adaption from C/++ to the necessary machine code is well done by the compiler.

More as that, if your processor defines ìnt as 16 bit and you want to have it as normal numeric resolution, but the controller has really a 32 bit arithmetic and registers, it will be stupid to use only 16 bit for intermediate results.

That`s why the combination of 16 bit inputs and outputs and 32 bit intermediate values is very sensible.

You should define

to use the native 16 bit int. Then on the PID controller you should use the step32_PIDi_Ctrl_emC(…​) operation which works internally with 32 bit intermediate values.

The P part is built with a simple multiplication of the input value with the f→fP factor. This is a 16-bit-with multiplication with 16 bit result for int16 as INT_NUM_emC type and step16_…​(…​) for a 16 bit intermediate result:

The multiplication uses either a built in multiplication assembly statement or a simple software emulation determined by the compiler. As you see the input value is checked for limit before, see next chapter. This prevents an overflow. The resolution of the kP depends on the value range of the output. If the output should have a full value range of 16 bit, but the intermediate result of one part has only 14 bit (because p + I + D should be added), then a f→kP = 1 means a kP of 4.0. This is because f→nShy = -2, the output y can only be gotten left shifting the intermediate result of 14 valid bits. That is not sufficient. It means for an output width of 16 bit an intermediate bit width of 32 bit should be used only.

But if the output has for example a range from +- 1000 which needs 11 bit, it is sufficient to use 16 bit for internal calculation. The kP resolution is then 0.125 because the intermediate result is shifted to 3 bits to the right for the output. That is usual enough for a typical application for simple embedded control.

If you use a 32 bit intermediate result, respectively 32 bit for the separated P, I and D part, then you have a little, not large effort for a simple 16 bit processor, but you calculates also the growth for the P part with a high resolution of kP. You can use 16 or more bits for the output value, for example not as physical output but as output in a cascade (as reference value for an internal controller). That is done always independent of the defintion of INT_NUM_emC as 16 or 32 bit if you use the step32_PIDi_CTrl(…​) step routine.

The integer variant has a possible overflow problem on multiplications. In the float variant you can multiply and afterwards limit. In the integer variant a non limited input can overflow with multiplication.

For float arithmetic you can calculate

for any input value, also high controller error (wx) with a high kP part. The controller output is limited of course, but afterwards. If float is used, the intermediate results do not need limitation, the float range is proper.

But for integer arithmetic you may get overflows on multiplication results.

The proper solution to prevent that is: Check a limit for the input values, depending on the parameterized fP and fD factor. If the inputs are in a range, the multiplication do never overflow. The pattern for that is:

How the wxlim should be calculated? It depends on the max admissible value for wxP.

The wxP has a resolution of 16 or 32 bit depending of the decision about intermediate value bit length, see chapter above. But you cannot use the full range:

It should be regarded that P, I and D are calculated independently and sum afterwards. It means that the maximal value for the P part is not its native range, it is 1/3 or a little bit lesser because of possible integrator overflows which should also regarded.

A simple decision is: Using 10000 instead the theoretical 32767/3 ~ 10922. for 16 bit width. That is 0x2710, or adequate 0x27100000 for a 32 bit intermediate result of P, I and D. The I-Part can have a overdrive of (32767-30000) = 0x2767 or ~ 27% from 10000. This overflow allows a factor for fI of 0.27, which is adequate to an Integration Time of 4 step times. If you would use 10500 as nominal limit, you have a reserve for the Integrator of (32767 - 31500) = 1267 which is 12.5% or an Integration Time of 8 step times which may be also proper.

For a given 16 or 32 bit width intermediate results, the calculation is done with:

With them the

can be proper calculated, depending on a currently given kP gain.

This value is calculated firstly as float for calculation the integer factors from the given natural float factors. This calculations can be done also from the compiler itself using constexpr in C++.

Using this 16 bit resolution for the intermediate result, the output resolution is also limited to this value, or 8191 (0x2000 …​ 0x1fff) if you need a full bit range output. That is the limitation of a cheap and fast solution for a really poor 16 bit controller.

Using the 32 bit resolution for the intermediate result, you have a better resolution also for the output.

A bit width of the integrator of 16 bit is anytime too less for proper operation. The integrator should use always 32 bit. Also on a 16 bit controller the necessary twice additions with carry can be emulated in software, which is already done by the C/++ compiler.

The range of the I part is not the full 32 bit range because it is added to P and D, see last chapter. The maximual value of the I part is 0x31fdffff.

To prevent an overflow for the integrator, the following is done:

The maximal value of the P-part is the value of /- `0x2720xxxx` for 16- or 32 bit. This is the input of the I-part to calculate the growth. But the I part is only growing if the output is not limited. The limitation check of the output is sufficient, because all three parts are not overdriven then. But there is a remaining possibility that the P is near the limit for example positive, the D is near the limit then negative, and the sum is not limited. If this situation remains (not desirable), than the I part integrates till 2* the max value. Then because of P + 2*I -D the limitation is reached and the integration stops. It means the I-part need not be checked to overdrive, it is done already while checking the sum. But the I-part has more as the twice range because its limits are `-0x80000000 ... 0x7fffffff`, the limitation of output occurs at least at `- 0x2710xxxx`. It means the integrator is stopped on max +- 0x4e200000. The rest of the range is not used. It is away from the numeric overflow.

Look on the implementation if the I-part for 16 bit calculation

As you can see the calculation for the growth of the integrator is done with a cheap 16 x 16 bit multiplication which’s result is 32 bit. The used macro is defined either in emC/Base/Math_emC.h as

With this definition the compiler may create proper simple assembly instructions for this approach using only 16 bit register. In C and also C++ the rule is given that only 32 bit inputs results in 32 bit. Hence the additional casting. Or this macro can be specific defined in the compl_adaption.h using assembly instructions for specific processors for example with an additional multiply hardware.

Following some ready to use parameter are shown for the fix point arithmetic for P and I, based on given floating point inputs in the left two columns. Also the result of P and y for one step is shown for an input of 1. It is also a test of the algorithm.

This results are produced with the following test:

Look on the result for 16 bit intermediate results and an output range of 11 bit, till +- 1023:

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

for the intermediate result as shown, ~ 1/3 of the integer range. For a optimal calculation time only a 32 bit multiplication should be used, not 64 bit. For an intermediate result of 16 bit, it is done with a simple cheap 16 x 16 ⇒ 32 bit multiplication with the proper factor of fI. Look for an value example:

This overdrive can occure because firstly the limitation is tested and afterwards the integration is done. Near the limit the limitation is not detected and the growth is added to the integrator which is not extra tested. Hence the growth can be max 0xacf which is ~25% of the range. Hence the Integration time can be min 4*Tstep. See functionality of integrator.

Look for calculated examples of the fI and also the nShKI:

The factors are based on a control Step time of 1 ms: Tctrl = 0.001f. They are calculated with the algorith in Test_emC\src\test\cpp\emC_Test_Ctrl\test_PIDf_Ctrl.c

As you see for Tn⇐0.002f, that is really extremely fast, it calculates bad results. But from 0.0021f, it is also extremely fast, the results are proper. The sensible range of Tn starts from ~ 32 ms, this is 32 step times, till ~ 100 seconds which is extremely slow. For a controller which 1 ms step time, an integration time in range of 100 ms till seconds is normally.

For the 16 bit intermediate result you can see that on 2.1 ms the 16 bit value for the P-Part is multiplied with a little bit lesser than 0x7fff, the greatest positive value, and the result is the half. That is correct. Look on the example:

Also for 16 bit intermediate result a value of Tn=5.0 sec or from > 4.0 sec the P-Part is shifted to the right which is a division by 2. Then it is multiplied with a value in the range 0x10..0x1f. It means, depending on kP the importance of the last input bits becomes less, they are shifted out. That is the effect that an remaining error is occured though the controller has a I part. It is because the integration time is too high in comparison to the step time.

On the other hand the accuracy or better resolution of the Tn time is limited to 1/16 …​ 1/32. Using 5.1 ms results in the same `kI`as for 5.2 ms. If the resolution should be higher then the number of shifts should be greater, and hence the importance of the last bits will be lesser. That is the disadvantage of the simple using 16 x 16 bit ⇒ 32 bit for multiplication. But for normal usage in a poor controller that is not a meaningful disadvantage.

The 32 bit intermediate result for 16 bit input values (or lesser, 12 bit DAC or such) has native more bits, which presents a resolution with an accuracy which is not really given. Hence it is not so an problem to shift out for example 11 bits for Tn = 80 ms or 14 bit for Tn = 1.0 sec to multiply it afterwards with a factor with 4..5 bit resolution. The result is proper.

The value example for a 32 bit intermediate result is:

For the kP part there is an additional distinction, whether the input value is 16 or 32 bit, defined with the type INT_NUM_emC. But both operations result in the value 0x0028'0000. This is the kP part. Its distribution for the output depends on the shift for f→nSh32y which is 0x13 for this case. The output value is only in range -1000…​1000 which needs only 11 bits of the output. It means for this calculated intermediate value for the P part the output is (0x0028'0000 >>0x13) ⇒ 5 which is expected for wx = 1 and kP = 5.

The integrator takes this value, shifts it with 11 bits to right and gets 0x0500 in the 32 bit calculation.

For the 32 bit intermediate result, the result is first shifted to right with 7 bit, and then multiplied with

As well for the float variant the following three data struct are defined:

That are the factors immediately used for control. As you see they are only integer values. As you can also see there are some values for shifting. This is necessary for integer arithmetic.

As you can see the given parameters are float values. You need on (re-) parameterizing float operations. But this is done either only on startup or in a really slow step time, so a float emulation can work.

If you have a really poor processor with low Flash memory, you can remove this data struct and work only with the ParFactors_PIDi_Ctrl_emC_s data. You should calculate the proper values outside of the controller and set it in this struct. This can also be done by a second processor in the environment, or from a tool on PC, or as only one initialization with compiler calculated values (using for example the constExpr C++ facility).

Look on the algorithm how the used parameters are calculated:

The first important values are xBits and yBits. They are given on construction. it is the number of the bits for the input signals (wx, wxd) and the output signal y. The input signal should not overflow the given number of bits, elsewhere the result is undefined. For example if you have a 12 bit value from a ADC which is used immediately, and also the reference value is in the same range, the number of bits for the input is 13. It is not 12 because the max value of the ADC can be subtract with the min (negative) value of the reference. The subtraction does never produce values outside. If you calculate it with int arithmetic, also the padding of sign bits are correct. You can use 13 for xBits.

Adequate with the output. You should only use bits for the output which are defined by yBits. For example you have a DAC output with 8 bit inclusively sign, 8 bit are enough. If you have a PWM (PulsWidthModulation) with a conter range till max. 1023, 10 Bits are enough.

The internal accuracy is higher if you use lesser bits.

The problematic is always: Preventing overflow. Hence shift in correct ranges before arithmetic operations.

The data are: