Totalizer block (was On delay Timer routine)

M

Thread Starter

Mario de Sousa

Jiri Baum wrote:
>
> Anand:
> > Timer clarifications:
>
(... huge snip)
>
> > Next algorithm is the totalizer block.
>
> This probably belongs in Mario's DSP module, so I'll leave it up to him to
> respond in detail, but...

If you could please explain what it is exactly that you want the totalizer to do, I'll probably implement it right away. I'm mucking about in the dsp at the moment!

Mario.


--
----------------------------------------------------------------------------
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
 
Anand:
> > > Next algorithm is the totalizer block.

Jiri:
> > This probably belongs in Mario's DSP module, so I'll leave it up to him
> > to respond in detail, but...

Mario:
> If you could please explain what it is exactly that you want the
> totalizer to do, I'll probably implement it right away. I'm mucking about
> in the dsp at the moment!

I'd call it an integral, myself, but then I used to be a mathematician...

Given a rate input, it multiplies it by the time (divides by frequency) and adds it to a cumulative total.

total += input / frequency
or
total += input * time-since-last


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

> Mario:
> > If you could please explain what it is exactly that you want the
> > totalizer to do, I'll probably implement it right away. I'm mucking about
> > in the dsp at the moment!
>
> I'd call it an integral, myself, but then I used to be a mathematician...
>
> Given a rate input, it multiplies it by the time (divides by frequency) and
> adds it to a cumulative total.
>
> total += input / frequency
> or
> total += input * time-since-last
>


Thats what the I in the PID does. Simply set the P and D to 0, and I to
1, and presto, you have your totalizer. It even works if it isn't called
periodically, because it checks what time it is called, and determines
the delta from the previous time it was called.

Of course, this can get a little heavy, so it probably might make sense
to create a simple integrator in the future. For now, I would leave it
as it is...

Another option of implementing an integrator / totalizor if the modules is running under a fixed period, is to use an add block that adds the integrated value to it's own result, for e.g.:
point input
point output
add output input 1.0 output 1.0
# i.e., add the input to the output, and place the result in output...



Cheers,

Mario.


--
----------------------------------------------------------------------------
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
 
Mario de Sousa wrote:

Jiri Baum wrote:
Anand:
Timer clarifications:
(... huge snip)
Next algorithm is the totalizer block.
This probably belongs in Mario's DSP module, so I'll leave it up to him torespond in detail, but...
If you could please explain what it is exactly that you want thetotalizer to do, I'll probably implement it right away. I'm muckingabout in the dsp at the moment! Mario.
i guess that i am thinking from the Instrumentation Engineer, point of view. Generally flow rates in process plants are of three types. the per hour rates, the per minute rates and the per second rates. A totalizer block acts on this flow rates and converts it into quantities (volume or mass).
A 100 Kg/hr flow when totalized for an hour should lead to 100 kgs.
A 100 Kg/min flow when totalised should yield 6000 kgs.
and a 100Kg/sec flow when totalized should yield 360000 kgs.
The only problem is that flows fluctuate very fast and therefore the algorithm generally used is

1. Get the flow rate (analog processed signal).
2. Generate a time pulse (say 10 ms or 100ms, generally the later).
3. On each time pulse the flow rate divided by the time yields the quantity which flows in the time period.
4. this is accumulated in a totalised value.
5. This totalised value further goes through three stages of addition, shift totalised value (generally 8 hours), daily values, monthly values and yearly values.

The totalised values reflect the consumption or generation figures for a process.

Anand

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
K
In my PID implementations (derived from scratch, not following any
particular standard) the bias is the output (the integral value) of the I
term, and can also be used for feedforward or for manually influencing the
loop. I think this leads to a simpler and more intuitive implementation
than many that I've seen. The integral term can be thought to float
the bias value up or down in proportion to error, and over the integral
time timebase. Antiwindup is done by min & max limits on the bias value,
before (usually) or after calculating the final P+I output for the loop.
The bias can also be described as the zero-error-output value (assuming
the D term is inactive).

Just FWIW,

Ken

--
Ken Irving <[email protected]>


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

Johan Bengtsson

Actually it won't work, at least not with normal PID equations It is right that it is what the I part does, but P is logically put before (or after) not parallel to the I block if you use
the normal PID equations, that means gain=0 effectively kills the entire PID, not just the P part of it


/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
 
M

Mario de Sousa

Hi Johan,


Actually, it will work because the current implementation does the P, I and D in parallel.

Any reason not to do it this way?

Cheers,

Mario.

----------------------------------------------------------------------------
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
 
A

Andrew Kohlsmith

> Actually it won't work, at least not with normal PID equations
> It is right that it is what the I part does, but P is logically
> put before (or after) not parallel to the I block if you use
> the normal PID equations, that means gain=0 effectively kills
> the entire PID, not just the P part of it

I've never run across this before... All the PID equations I use follow this basic rule

error = desired / actual;
P = error * Pgain;
I += error * Igain;
D = (error - last_error) * Dgain;
output = P+I+D;

With this, the gains all work independently.

Regards,
Andrew


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

Bob Peterson

BTW-the standard ISA equation does not follow this approach. The proportional constant is applied to all three terms, and is the most commonly used process control PID loop. Personally I prefer the independant form such
as what you listed above as it seems a little easier to tune, and AB allows you to choose which form you want in its PLC5 PID block. Sadly this
capability is lacking in the SLC5 processor.

BTW-all PID loops I have worked with also have a 4th term. This is generally refered to as bias, but I commonly use it as a feedforward value by
calculating it to be something close to what the output ought to be (maybe 80% or so) and allowing the loop to get the rest of it from the error. Tends to reduce the wild swings you can get otherwise at startup.

Bob Peterson

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

Harald Albrecht

>BTW-all PID loops I have worked with also have a 4th term. This is generally
>refered to as bias, but I commonly use it as a feedforward value by
>calculating it to be something close to what the output ought to be (maybe
>80% or so) and allowing the loop to get the rest of it from the error. Tends
>to reduce the wild swings you can get otherwise at startup.
>

And then there's still Siemens... I remember TELEPERM PID controllers having somthing similiar to a damping coefficient for the differential
part to avoid D playing too much a huge role when there are large transients. But the TELEPERM PID block is really a beast; print a schematic of it on an A4 (or legal) sheet, and you will still have problems recognizing all its internal parts without a magnifying glass.

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

Johan Bengtsson

Most tuning methods won't work well without parameter conversion.

Most PID:s don't work this way witch means that the technician chaning the tuning will not get expected results from a parameter change he/she is used to do.

/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

Yes, this is right, but how is the Igain and Dgain calculated?
Normally:

Pgain=gain
Igain=gain*timeStep/Itime
Dgain=gain*Dtime/timeStep

The input parameters (that the techican will see) to the PID is normally gain, Itime and Dtime

this means setting gain to 0 kills the entire controller.

Besides:

First you have an error, I think it is just a typing error but anyway (someone else might read this too) error = desired - actual (not divided by, difference)

and there are other implementations, a more "normal" implementation is to calculate the D part as D = (last_actual - actual) * Dgain
(ie a change in desired (ie setpoint) does not give you a change in D) it is in most cases a better implementation (but not always) what is most used is another debate and we could drop that.

Further there usually is a filter applied to the D part

Dfilt += (D-Dfilt) * filterAmount

Where filterAmount is a number >0 and <=0.5
and calculated as
filterAmount = timeStep/Dtime/leadQuote

leadQuote is a parameter changeable on some controllers and fixed on others and usually in the range 5 to 15, but this are not hard limits. A normal value is for some reason 9.

There are futher implementation issues but we can probably drop them for now, for example there should be a way of changing bewteen direct and reversed action, the transistion between manual and auto should be bumpless and other stuff.

/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

The PID block in teleperm is one of the few that have the leadQuote (that is the damping coefficient you mention) that I mentioned in my other post as a paramter accessable from the HMI.

Yes it is a good one.


/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
 
On Tue, Jul 17, 2001 at 09:39:52AM -0400, [email protected] wrote:
>
> BTW-all PID loops I have worked with also have a 4th term. This is generally
> refered to as bias, but I commonly use it as a feedforward value by
> calculating it to be something close to what the output ought to be (maybe
> 80% or so) and allowing the loop to get the rest of it from the error. Tends
> to reduce the wild swings you can get otherwise at startup.

In my PID implementations (derived from scratch, not following any particular standard) the bias is the output (the integral value) of the I term, and can also be used for feedforward or for manually influencing the loop. I think this leads to a simpler and more intuitive implementation than many that I've seen. The integral term can be thought to float the bias value up or down in proportion to error, and over the integral time timebase. Antiwindup is done by min & max limits on the bias value, before (usually) or after calculating the final P+I output for the loop. The bias can also be described as the zero-error-output value (assuming the D term is inactive).

Just FWIW,

Ken

--
Ken Irving <[email protected]>


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
> > Actually it won't work, at least not with normal PID equations It is
> > right that it is what the I part does, but P is logically put before
> > (or after) not parallel to the I block if you use the normal PID
> > equations, that means gain=0 effectively kills the entire PID, not just
> > the P part of it

Andrew:
> I've never run across this before... All the PID equations I use follow
...
> With this, the gains all work independently.

Suggestion:

error = (desired - actual) * masterGain;
P = error * Pgain;
I += error * Igain;
D = (error - last_error) * Dgain;
output = P+I+D;

That way those used to Mario's way ignore masterGain (set it to 1) and tune using Pgain, Igain and Dgain, and those used to the other way ignore Pgain and tune using masterGain, Igain and Dgain.

Most will probably tune using all four.

(Obviously with the corrections for varying timebase as Mario had them.)

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

Aprt from some facts:
- it is unstandard, people used to PID controllers
will not intuitively do the right thing when tuning and otherwise changing the parameters.
- Igain and Dgain is not times, what you enter as
integral parameter is either a time (most common)
or a 1/time (revolutions per minute) (less common)
and for D you always enter a time.

The implementation could be done like that, but the values for the various gains should normally be calculated from the real parameters rather than being the parameters.

There is one other slight drawback, this requires constant time between updates, something I don't think you actually will get in a PC, this might be possible to ignore if you make sure the average time is kept at the one used for
calculating the different gains.

To get integration (and derivation) separately I think this should be separate blocks availiable in the system. (That is where this thread started)

/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:
> There is one other slight drawback, this requires constant time between
> updates, something I don't think you actually will get in a PC, this
> might be possible to ignore if you make sure the average time is kept at
> the one used for calculating the different gains.

It's easy enough to put a correction for time into the formulas - I thought Mario had done it up-thread, but I can't find it now...

> error = (desired - actual) * masterGain;
> P = error * Pgain;
> I += error * Igain;

this becomes
I += error * Igain * time

> D = (error - last_error) * Dgain;

this becomes
I += (error - last_error) * Dgain / time

> output = P+I+D;


(This even gives Igain and Dgain the units you mentioned - Igain in Hz and Dgain in s.)

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

Hey guys,

Sorry for not jumping in on the thread, but I don't have time to look into this at the moment. Maybe next week.

Cheers,

Mario.

----------------------------------------------------------------------------
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
 
J

Johan Bengtsson

That is right (apart from some misstyping :) )
The Igain and Dgain should still be calculated as Igain=gain/Itime and Dgain=gain*Dtime and a filter applied to teh D part be implemented

Do you want me to try to implement a more full-blown PID controller (including bumpless transfer and so on)

I don't know when I would be able to do that but I could try to put that in the schedule :)

/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
 
Top