Smoothing analog process values

Hello guys,
please read this and comment. It's about ways you can use to smooth analog process value.

I think it would be a good idea to write the filter's implemetation in Siemens STEP 7 and AB's programming software. I know there are a lot of gurus here. I myself can write STEP 7 SCL implementation, but don't think this can be very much efficient. I invite others to try to write more efficient implemetation in STL.

I'm looking forward to your feedbacks...

You must be careful

Noise is a random or statistical thing with averages, standard deviations and skew. Even if you think you know the limits of the process noise there will still be 6 sigma events where the noise will exceed the +/- 0.2 limits. You should also check that the next few points also exceed the +/- 0.2 limits. At least check the next point because getting two six sigma events in a row would be very rare but even that can still happen.

We once made a press monitor that measured load cell forces in the die for Bruder and Stolley presses. We had to set the error limit at 6 to 7 sigma to keep from getting false trips. As it turns out the foreign object creating the error would either stay in the die or move with the lid. This also provided some cluse as to whether the spike was noise or real.

In short, don't depend too much on just one reading when playing tricks as you suggest.

Pandiani, why don't you raise the high bar a bit and show how one can implement a two pole Butterworth filter? Then plot the Butterworth filters response relative to the single pole filter response.

BTW, I have figured out how do make Scilab slider bars. Would you like an example? There is also a scilab user group.

Pandiani said:

I myself can write STEP 7 SCL implementation, but don't think this can be very much efficient.

Click to expand...

What makes you think this, have you examined the STL that the SCL compiler produces ?
If you want an STL implementation done, please post the working SCL implementation.

L D[AR2 said:

What makes you think this, have you examined the STL that the SCL compiler produces ?
If you want an STL implementation done, please post the working SCL implementation.

Click to expand...

Well, I'm not an expert when it comes to STEP7. I've already worked with SCL, please have a look at SOPDT simulator.
To be honest I don't know what is more efficient, I assume it is STL since it is similar to assembler code, and smart asembler implementation is usually more efficient then any other high language solution.

And, I'll write SCL implementation when I have more time (hopefully tomorrow).

Peter, I'll need first to read a lot, and if I feel I can do it, I'll do it.
Anyway, I think this solution is much better then traditionally "increase damping time" approach...

Thank you for your comments

Here is SCL implementation:

I'm able to see STL conversion, but since I don't understand it it will be interesting if someone can compare and actally measure efficiency of STL and SCL code. L D[AR2,P#0.0], I'm waiting your move.

Peter, as usual, is right in his comments and I do understand them. However, this filter is much better solution and I'm conviced it is worth of little extra effor to be implemented.

In the following picture you can see how this filter handles sudden changes in signal.

So what happens if ......

So what happens if the input is ramping? What if the ramp is at a rate where x changes 90% if the limit each time period? Try using a sine wave as an input signal and add noise to that.

I notice that you changed the condition where x must be within y +/ a limit? What if y is increasing? Perhaps then the new x must be within y plus the estimate change in y +/- the limit. To put it another way, x needs to be within +/- limit of the estimated value if y. You must remember that y will lag during a ramp and even more if the second derivative is changing.

Pandiani, you are tackling this problem as if the PV is normally not changing. Many of us do motion applications where the PV is always changing and the first derivative is constant as in a constant speed. There are speeds where your technique will not work without taking into account the rate of change or even the second rate of change in the process variable.

There are better solutions.

Peter Nachtwey said:

So what happens if the input is ramping? What if the ramp is at a rate where x changes 90% if the limit each time period?

Click to expand...

It all depends on the actual application. Upper and lower limits of input signal are parameters and engineer can change them until satisfactory result, or drop first order filter at all and try something else. In my opinion, it is not good idea to use first order filter with ramp input. For example, if ramp has slope 1, that is x = t, then application of first order filter will introduce offset error. If filter with time constant T = 2 is applied, at t = 10, offset will be cca 2. Advanced FO filter can reduce this offset.

Peter Nachtwey said:

Try using a sine wave as an input signal and add noise to that.

Click to expand...

I tried that also, and results are very much different depending on parameters. I used sine wave with w = 1rad/s, Ts=0.1, deviations set to zero, T =1/20 sec, and I get something like in attached figure.
http://www.plctalk.net/qanda/uploads/Sine_filter.jpg

In this case I set deviations to zero because they're no needed for this particular application.

http://www.plctalk.net/qanda/uploads/Sine_filter_response.jpg

Filter's output is shown in yellow colour, and noise signal is purple.

Peter Nachtwey said:

I notice that you changed the condition where x must be within y +/ a limit? What if y is increasing? Perhaps then the new x must be within y plus the estimate change in y +/- the limit. To put it another way, x needs to be within +/- limit of the estimated value if y. You must remember that y will lag during a ramp and even more if the second derivative is changing.

Click to expand...

Not sure I understand this. Where I changed these conditions? Conditions were y > x+upper, and y < x-lower...

Peter Nachtwey said:

Pandiani, you are tackling this problem as if the PV is normally not changing. Many of us do motion applications where the PV is always changing and the first derivative is constant as in a constant speed. There are speeds where your technique will not work without taking into account the rate of change or even the second rate of change in the process variable.

Click to expand...

Yes, that is target group of this filter's application. In my plant most process variables are not supposed to change rapidly like in motion control. Most variables are temperatures and pressures.

Peter Nachtwey said:

There are better solutions.

Click to expand...

Of course, maybe to try to implement a kind filter that can be applicable to a wide range of applications, and even write an article together.
Remember, this "advanced filter" is intended for use in application where first order filter is an acceptable solution.

I'd like other members to try this filter in practice and give their feedbacks, I'm sure it will be very interesting to read.

You persist. I think I need to be more blunt.

Pandiani,
1. What make you think that the value you are jumping to is correct? If it is a noise spike then you will set your filtered value to the noise spike.
2. The response of your filter will also cause problems as the rate of change in the PV goes larger then smaller than the limit/Ts. The derivative gain will cause the controller's output to make large swings.
3. Can the system really respond that quickly? If so there are better options.

The problem you are trying to solve is to increase the effectiveness of the filtering but also have a faster response. Here is my solution.
1. You need a model. You can do that. For our purposes lets assume the model is

PVest(n+1)=A*PVest+K*B*u+C
Where PVest is the estimated temperature in degrees C.
A=exp(-Ts/Tp) // Pandiani, you should know this
Tp=1 // Plant time constant in minutes
B=(1-A)
K=2 // is the gain in degrees C per percent output.
C=(1-A)*PVss
PVss=20 // Steady state temperature

C is required so that PV will approach PVss when u=0

Now, who needs a filter? I have a model free of noise. I can estimate PV exactly, well almost. We all know there will be small unmodeled 'features' that will cause the the model's estimated PV, PVest, to drift away from the measured or actual PV, PVact. This is a problem that we fix by adding another term to the model.

PVest(n+1)=(A-L)*PVest+L*PVact(n+1)+K*B*u+C

L=(1-exp(Ts/Tf)
Note, this is really a combination of two filters.

Tf is the time constant of the filter. Tf is usually smaller than Tp by a factor of 2-10. The larger Tf is the smaller L will be. As L gets smaller the estimated value depends more and more on the model. As Tf is made smaller, L increases and the feed back make a bigger contribution to the estimated PV but now the PVest will also be affected more by the noise. If the model is known to be good then Tf can be made made relative large so PVest relies mostly on the control output and the plant time constant Tp. If the model isn't very good then one must make the model time constant small so the feedback can keep the model from drifting too far from reality.

Now notice. There is still a filter for the feedback. There isn't any arbitrary limit that causes funny things to happen. If the control output makes a step change the PVest will follow PVact very closely because the control output now has a say in what the filtered value of the PV is.

This technique is getting close to what an observer does. This would be an observer IF we were estimating states we can't directly measure.

Another but similar approach

We will start with this again.
PVest(n+1)=A*PVest+K*B*u+C // MAKE ESTIMATE
PV(n+1)=PVest+G*(PVact(n+1)-PVest(n+1) // CORRECT ESTIMATE

In this case G is a gain that corrects the estimated PV. If G is small there isn't much correction and the noise if the actual feedback ,PVact, will not have much effect on the PV. A Kalman filter works like this except the Kalman filter gain(s) G are computed to statistically minimise the error between the actual and estimated PV.

The point of all of this that it is better to make estimates of the PV and correct them and to use arbitrary limit tricks that may work well until the don't.

We use observers to estimate the velocity AND acceleration in our motion controllers. Feed back devices do not usually have that much noise if they are wired correctly. Often the quantizing error causes most of the 'noise'. We have seen may threads on filtering velocity. Filtering velocity can be much easier if one have a model for the system that is being modeled.

Peter Nachtwey said:

BTW, I have figured out how do make Scilab slider bars. Would you like an example? There is also a scilab user group.

Click to expand...

I would...

Thanks,

Hello guys,
I didn't respond for a long time because I had some problems at home. Hopefully, situation is getting better now.
Peter, I knew something interesting would come up to the surface if I persist.
It is very interesting to read what you proposed. If I understood correctly trick is to make first order model of the system that will be "close enough".
Do you use these techniques you have described when design motion controllers?
From my personal experience, that "advanced FO filter" performed well in one level control application in my plant. I never tried to implement observerand then state feedback controller, because I still don't have enough understanding to convert pure theory in practice.

I tried to design PID controller using procedure described on controlguru web site. It was about level control in condenser. I failed because, simply, when controller was in manual mode, and control valve opened, for example 40%, I still had level oscillations. I simply couldn't performed that step test. I wonder what would be right procedure, but that is whole another story.

I have found one very interesting filter application. Measured process value is first filtered with described "advanced FO filter", then it is paased through derivative block before forming error (deviation) signal which is passed as PID controller input. Scheme is given in attachment and I'd like to hear your opinions about this. Have you ever seen anything like this?
I'm not sure why there is need for derivator at all, and what are potential benefits from this type of realisation?

Regards,
Pandiani

Butterworth Filter

The filter you described in the PDF still look like a simple first order low pass filter. It will lag. I thought you were looking for a filter that doesn't lag.

Here is a Butterworth filter. It is fairly easy to implement but it will exhibit lag.
ftp://ftp.deltacompsys.com/public/PDF/Mathcad%20-%20Butterworth.pdf

If you access to the control signal then I would be looking at using an observer. That is what I do since I have access to the control output from the controller.

Peter, I'll need to spend some time understanding your pdf file. I need to learn more about Butterworth filter, first.
To be continued...

Article about observers. No math..... yet.

http://www.motioncontrolonline.org/i4a/pages/Index.cfm?pageID=3622