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
<2006>
2007
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
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|