A lighter side of automation research

A

Thread Starter

Anand

:-D :-D

The Company, Decades in the field of automation,
And the million dollar research for the perfect digital filter goes on.

The old timer who had first put the small tube with reducers at both ends,
in the transmitter line to reduce the fluctuation,
from the pneumatic flow signal of
process flow coming from the outlet of a diaphragm pump.
There was beer and pats on the back, on a job done well.
Two guys from the university later found out the dyanamics of the system.
Out came a book with sixteen equations.

And in the electronics era.
The old timer, his picture in some files in a cabinet now,
In came the consultants who had written the book.
Months of research led to the design of a proper capacitor circuit.

The heat burnt the capacitor,
In they charged again,
Additional discoveries were made.
Another volumes and set of equations followed.

Then came the microprocessor revolution and The Company,
half a million, less richer,
converted the equations to five selectable digital filters.
Salesmen hovered on the diaphragm pump and showed how the filters,
gave flexibility to the operations.
More books were written.

The student sweated now,
A professor to teach noise equations,
Students who could not cram the filter equations, failed exams.
Ten reference books at a hundred bucks apiece in the second hand market,
Six websites to go through to find information.

Another quarter million for its filter logic on its PLC and DCS.
Annually Spends The Company.
And now proudly it is announced,
two teams specifically on converting the capacitor equations into logic
work.

And folks, tell you what!
A New PLC puts in a small logic for reducing the noise.
value= last value +(x%(present value -last value));
last value=value;

And by the grace of god, it does its job!!!

Anand.

P.S.
Though the circumstances seem real, the work is a piece from the authors
imagination. Lets keep it light on the list.
Since my spellcheck is not working, there could be possible spelling
mistakes,
This work being given on GNU-GPL you can correct the spellings and store
it on your disk and distribute as you wish.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Anand:
> And folks, tell you what!
> A New PLC puts in a small logic for reducing the noise.
> value= last value +(x%(present value -last value));
> last value=value;

> And by the grace of god, it does its job!!!

That should probably be in the DSP module as well... it'll be a pain working out the formulae for non-constant time period, but they shouldn't be that complicated once somebody figures them out.

Perhaps not at 2 o'clock in the morning, though.


Jiri
--
Jiri Baum <[email protected]>
http://www.csse.monash.edu.au/~jiribvisit the MAT LinuxPLC project at http://mat.sourceforge.net

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
G

Gilles Allard

There are many PV ( low-pass) filters available in PID controllers. Here is one:

Y = (PV * (1-k)) + (Y * k)

where k can vary from 0.0 to 1.0 (with a higher k, you get a slower response)
Please note that the equation is not recursive. The Y on the right side is the computed value for the preceding sample.
If you need to relate k to a time constant, here is the formula:
k = e ** (- S/T)
where S is the sampling time and T is the filter time constant (defined as the time it takes to reach 63% of the final response to a step function).
For example, to get a 5sec response time with a sampling period of 1sec, you need a k = 0.82
It would also be possible to relate k to the bandwidth (in Hz).

I have used that filter many times, with success. However I never tried it with samples non-evenly spaced in time. I do not see why it should not work if the sampling time distribution is not too large.

The filter presented by Anand is a simplified variation of the one presented above.

My personal opinion would be to keep the PID block simple; PV filter can always be used external to the PID block. Thus the user would be able to select the most appropriate filter for his/her job. I do not like PID blocks with tens (or hundreds) of parameters.

Gilles
PS: keep going Anand; your work stimulates the group.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Gilles:
> There are many PV ( low-pass) filters available in PID controllers. Here
> is one:

> Y = (PV * (1-k)) + (Y * k)

...
> If you need to relate k to a time constant, here is the formula: k = e **
> (- S/T)

Yup, that sounds like it. I wrote my post just before going to bed and I was pretty tired.

> where S is the sampling time and T is the filter time constant
...
> It would also be possible to relate k to the bandwidth (in Hz).

That might be better, as it'd make it comparable to other kinds of low-pass filters. I assume the conversion is just a simple factor?

> I have used that filter many times, with success. However I never tried
> it with samples non-evenly spaced in time. I do not see why it should not
> work if the sampling time distribution is not too large.

Done properly, it should work even then, but large gaps are going to result in less smoothing - once the gap is beyond the filter time, it must pretty well just grab the new value and use it.

> The filter presented by Anand is a simplified variation of the one
> presented above.

It's exactly your first formula, rearranged so that "k" appears only once.

> My personal opinion would be to keep the PID block simple; PV filter can
> always be used external to the PID block.

Yes, that's what I meant - sorry, should have said that.

It should be another block within the DSP module.

Jiri
--
Jiri Baum <[email protected]>
http://www.csse.monash.edu.au/~jiribvisit the MAT LinuxPLC project at http://mat.sourceforge.net

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M

Mario de Sousa

Jiri Baum wrote:
>
> Gilles:
> > There are many PV ( low-pass) filters available in PID controllers. Here
> > is one:
>
> > Y = (PV * (1-k)) + (Y * k)
>
> ...


Well folks, the current implementation of the dsp already does this.

Actually the filter block of the dsp implements a second order recursive filter (the above is a first order recursive filter). To be more precise, it implements n second order recursive filters inseries, giving you whatever order filter you would like.

Note that to build a single order recursive filter you simply set some of the second order filter parameters to zero.

The filter blocks can be built by giving the parameters for the recursive filters directly (what you would do for the above formula), or
by giving the the filter characteristics (passband, stopband, maximum atenuation in passband, minimum attenuation in stopband) and it should be able to compute the parameters for the filters itself. The only other parameters you need to give is the filter type (lowpass, highpass, bandpass, bandstop) and the filter aproximation (chebychef, butterworth, elliptic).

Giving the filter parameters directly works as intended. Unfortunately calculating the filter parameters from analog filter aproximation has
not yet been debuged. I believe to a certain extent that lowpass and highpass are working correctly, but I know bandpass and bandstop are
buggy. I haven't been able to debug them because I have yet to find a book that gives me real values with which to compare. The book I had
been using to guide myself seems to have some bugs itself... ;-(


Cheers,

Mario.

The setup for the filter block can

--
----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
K
On Fri, Jul 20, 2001 at 01:26:49PM +1000, Jiri Baum wrote:

> > There are many PV ( low-pass) filters available in PID controllers. Here
> > is one:
>
> > Y = (PV * (1-k)) + (Y * k)
>
> ...
> > If you need to relate k to a time constant, here is the formula: k = e **
> > (- S/T)
>
> Yup, that sounds like it. I wrote my post just before going to bed and I
> was pretty tired.
>
> > where S is the sampling time and T is the filter time constant
> ...
> > It would also be possible to relate k to the bandwidth (in Hz).
>
> That might be better, as it'd make it comparable to other kinds of low-pass
> filters. I assume the conversion is just a simple factor?

I usually calculate k on the fly as scan/T, and it works very well, giving very close to the ideal exponential behavior if the scan is reasonably short. The scan can vary quite a bit
with negligible effect. Ideally the period should probably be 1 (minimum) or 2 orders of magnitude greater than the average scan.


> > I have used that filter many times, with success. However I never tried
> > it with samples non-evenly spaced in time. I do not see why it should not
> > work if the sampling time distribution is not too large.
>
> Done properly, it should work even then, but large gaps are going to result
> in less smoothing - once the gap is beyond the filter time, it must pretty
> well just grab the new value and use it.

The k=scan/T result must be limited so that k<=1 to be sensible, to cover all cases.

Ken

--
Ken Irving <[email protected]>

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Johan Bengtsson

why not at two a clock? I have done this a lot of times and could do it when I am asleep...

value+=(present_value-value)*delta_time/filterTime;


delta_time=time since last calculation
filterTime=parameter equal to R*C for the analog filter
make sure delta_time never exceeds 2*tilterTime since the filter won't work well under these cirumstances


Be aware: there is no amount of digital filtering that can handle the lack of a small analog filter before the signal is sampled.


/Johan Bengtsson

----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Johan Bengtsson

Well

Y = (PV * (1-k)) + (Y * k)
and
Y=Y+(PV-Y)*p

will give you exactly the same result for p = 1-k

(PV * (1-k)) + (Y * k) = PV - PV * k + Y * k =
= PV - PV * (1-p) + Y * (1-p) = PV - PV + PV * p + Y - Y * p =
= PV * p + Y - Y * p = Y + (PV-Y) * p


and no for a time based equation should m=S/T, that means k=1-S/T, not the e** version below

You will get an exponential response by this equation that will be equal to Y(t)=1-e**(-t/T) if you start with Y=0 and set PV=1 (and keep it there)


This gives you a first order filter equal to what you would
get by a resistor and a capacitor with T=R*C


/Johan Bengtsson

----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
johan.bengtsson:
> why not at two a clock? I have done this a lot of times and could do it
> when I am asleep...

> value+=(present_value-value)*delta_time/filterTime;

Because it should be exponential :)

However, the above is a good approximation when delta_time is much smaller than filter_time, and if it isn't the filter won't do a very good job
anyway. Still, it ought to be done properly.

Jiri
--
Jiri Baum <[email protected]>
http://www.csse.monash.edu.au/~jiribvisit the MAT LinuxPLC project at http://mat.sourceforge.net

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Johan Bengtsson

Ok, I learned something new today.
I have always dealt with timesteps that is rather small and my approximation have always been good enough for me, but after some testing I see that the other one is hitting the theoretical values better for .

As long as the time between updates don't differ it would be the same, otherwise you have to do the exponent every time but it might not matter much.

/Johan Bengtsson

----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
johan.bengtsson:
> and no for a time based equation should m=S/T, that means k=1-S/T, not
> the e** version below

> You will get an exponential response by this equation that will be equal
> to Y(t)=1-e**(-t/T) if you start with Y=0 and set PV=1 (and keep it
> there)

Yes, that's what you want - that's what the Y=Y+(PV-Y)*p formula gives you.

You want to arrange the formula so that if you double the scan rate but keep everything else the same, you get the same curve on the output.

Jiri
--
Jiri Baum <[email protected]>
http://www.csse.monash.edu.au/~jiribvisit the MAT LinuxPLC project at http://mat.sourceforge.net

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top