EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: looking for OSI version of epid record
From: "Mark Rivers" <[email protected]>
To: <[email protected]>
Cc: "LYNCH, Damien" <[email protected]>, "Tim Mooney" <[email protected]>, <[email protected]>, "Andrew Johnson" <[email protected]>
Date: Tue, 22 Aug 2006 13:38:14 -0500
Folks,

Sorry for taking a while to respond to the discussion on the epid
record.  I've been travelling.  I'll respond to all of the posts here.

Damien Lynch wrote:

> 1. What should I expect from the calculated value that goes in OVAL? A
value
> that I can write straight into what OUTL links to (which is what I was
> expecting from reading the doco), or a value that I should add to
OUTL.VAL
> (which is what I am seeing).

The calculated value is the absolute number that should go into the OUTL
link, not an increment.

> To explain a little further, I am currently in the tuning phase and
have only
> set KP. Let's say I have set KP to 0.03. When I change my set point by
one
> unit value I am getting 0.03 in OVAL. Is this what I should expect?

If KI and KD are 0, then OVAL will be equal to the error (setpoint minus
readback) times KP.

> 2. This isn't really a question, more of an observation.
> 
> I had to modify the epidRecord.c file as follows to get the correct
value
> into the VAL field.
> 
> 185c185 <             status = dbGetLink(&(pepid->stpl),DBR_FLOAT,
> &(pepid->val),0,0); ---
> 
>> status = dbGetLink(&(pepid->stpl),DBR_DOUBLE, &(pepid->val),0,0);
> 
> 
> I notice in the documentation that the VAL field is specified as a
float, but
> in the epidRecord.dbd file it is a DBF_DOUBLE.

Thanks for finding that problem, and thanks to Tim Mooney for fixing it.
The fix is in the CVS version of the synApps "std" module, and will be
in the next release.

Benjamin Franksen wrote:
>>The major improvements in the EPID record compared to the PID record
include: 
>> [...]
>> Changed the time units of the KI and KD terms from minutes to seconds
>However, Section "Feedback Parameters" says
>> Field Summary                                [...]
>> KP    Proportional Gain                      [...]
>> KI    Integral Gain, in repeats per minute   [...]
>> KD    Derivative Gain, in repeats per minute [...]
> which leaves me to wonder whether I would have to re-scale KI and KD 
> when moving from pid to epid or not.

Thanks for pointing out the problem with the documentation. The units
are seconds, not minutes.  I have fixed the documentation to reflect
this.

> Another question with regard to replacing pid by epid: Apart from teh 
> above scaling issue, have I understood it correct that if the
following 
> scenario:
> a pid record controlling an ao record, the latter in OMSL=closed_loop,

> output OIF=incremental mode, DOL referencing pid's DM
> would be replaced by
> epid record having OUTL point to ao record's VAL, ao record in
OIF=full 
> and OMSL=supervisory mode?
> then everything should work the same as before (modulo bugs/unwanted 
> features)?

Yes, that is correct.

Damien Lynch wrote:
> I see the EPID record producing a value that should be added to the
>  ao record's VAL field, implying the ao record should have
OIF=Incremntal.

No, that's not right.  The EPID record does not produce a value to be
added, it produces the absolute amount of the output.

> But with the EPID record putting OVAL into what's pointed to by OUTL 
> (ie the ao record) I'd expect to have OMSL=supervisory in the ao
record.
> The way I read the doco I thought EPID would calculate a value that
would
> be put into the ao record (not added to what's already there).

That's correct, it should not be added to what is there.

> But this value now in OVAL is one that I would want to add to the 
> VAL field in the ao record pointed to by OUTL (which in my case writes

> to a magnet power supply). Is it up then to the database designer to 
> perform an OVAL + ao.VAL calculation and get the result into ao.VAL?

No, you should not be using OVAL as an increment.  If you have set KI
and KD to 0, then OVAL is just the correct "Proportional" term in the
PID equation.  You need to use the "Integral" term in the EPID record
(KI != 0), rather than treating the Proportional term as an increment.
 
In a process control system where a finite output is required even when
the error is 0 (such as a furnace where power is required to hold a
constant temperature) you need KI != 0 in order to get the error to
eventually go to 0.  Maybe that is what is causing confusion here.

Let me know if there are more questions or problems.

Cheers,
Mark




Navigate by Date:
Prev: Re: VCCT and CA sniffer Brad Cumbia
Next: Setting option flags for building system libraries David Dudley
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: looking for OSI version of epid record Tim Mooney
Next: Original Motorola MVME 167 PROM Jiro Fujita
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·