Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017 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
<== Date ==> <== Thread ==>

Subject: RE: EPID bumpless restart
From: Mark Rivers <rivers@cars.uchicago.edu>
To: "'Crisp, Daniel'" <CrispD@nscl.msu.edu>, "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Mon, 4 Dec 2017 18:29:10 +0000
Hi Daniel,

> I suppose it's possible that the reason it's not doing a bumpless restart, is because it is instead
> grabbing it's last output held in my 'EPID_OBUF' channel rather than the current value of
> the supply. Maybe, instead of re-writing the I term in the EPID, I should be re-writing the
> value of my output buffer channel.. Also, to answer your other question, the link is PP.

Yes, that is probably your problem.  When the feedback is turned off are you changing the power supply through the EPID_OBUF record, or by talking directly to the power supply PV?  If you are talking directly to the power-supply PV then that is the problem.  The EPID record assumes that it can read the value from it OUTL link to determine the current value of the controlled PV.  You need to arrange for EPID_OBUF to be updated when the power supply PV changes and feedback is turned off.

Mark


> -----Original Message-----
> From: Crisp, Daniel [mailto:CrispD@nscl.msu.edu]
> Sent: Monday, December 04, 2017 9:41 AM
> To: Mark Rivers; tech-talk@aps.anl.gov
> Subject: RE: EPID bumpless restart
> 
> Hi Mark,
> 
> No I haven't yet. However, I am using a few extra channels to help me control the IO to and
> from the epid record. My set up is a lot like the one Pete Jemian explains here
> https://www3.aps.anl.gov/bcda/synApps/optics/fb_epid/index.html.
> 
> I suppose it's possible that the reason it's not doing a bumpless restart, is because it is instead
> grabbing it's last output held in my 'EPID_OBUF' channel rather than the current value of
> the supply. Maybe, instead of re-writing the I term in the EPID, I should be re-writing the
> value of my output buffer channel.. Also, to answer your other question, the link is PP.
> 
> I use the extra channels because in some cases, the polarity of the supply may be negative
> while the field read back from the controller is positive.
> 
> Here is the output of the dbpr "<epid_record>",4
> epics> dbpr "REA_BTS23:DV_D1155:EPID",4
> ACKS: NO_ALARM      ACKT: YES           ADEL: 0
> ALST: 0.85615244554806                  ASG:                ASP: 0x272ea20
> BKPT: 00            CT: c6 1a 83 34 6c 2d 5c 0e
> CTP: c6 1a 83 34 6c 2d 5c 0e            CVAL: 0.856157      CVLP: 0.856157
> D: 0                DESC: Enhanced PID Control              DISA: 0
> DISP: 0             DISS: NO_ALARM      DISV: 1             DP: 0
> DPVT: (nil)         DRVH: 300           DRVL: 0             DSET: 0x7f0c63ace560
> DT: 1.00008201      DTP: 1.00008201     DTYP: Soft Channel  EGU:
> ERR: -4.55445193758841e-06              ERRP: -4.55445193758841e-06
> EVNT: 0             FBON: Off           FBOP: Off
> FLNK:DB_LINK REA_BTS23:DV_D1155:EPID_LMTS.VAL               FMOD: PID
> HHSV: NO_ALARM      HIGH: 0             HIHI: 0             HOPR: 300
> HSV: NO_ALARM       HYST: 0             I: 167.689240882694
> INP:DB_LINK REA_BTS23:DV_D1155:EPID_INP NPP NMS             IP:
> 167.689240882694
> KD: 0               KI: 1.175           KP: 34.5
> LALM: 0.85615244554806                  LCNT: 0             LLSV: NO_ALARM
> LOLO: 0             LOPR: 0             LOW: 0              LSET: 0x2723540
> LSV: NO_ALARM       MDEL: 0             MDT: 0.1
> MLIS: e0 5d 79 02 00 00 00 00 80 2c 79 02 00 00 00 00 08 00 00 00
> MLOK: 40 ce 70 02 00 00 00 00           MLST: 0.85615244554806
> NAME: REA_BTS23:DV_D1155:EPID           NSEV: NO_ALARM      NSTA:
> NO_ALARM
> ODEL: 0             OUTL:DB_LINK REA_BTS23:DV_D1155:EPID_OBUF PP NMS
> OVAL: 167.689083754102                  OVLP: 167.689083754102
> P: -1.571285918468e-04                  PACT: 0             PHAS: 0
> PINI: NO            PP: -1.571285918468e-04                 PPN: (nil)
> PPNR: (nil)         PREC: 6             PRIO: LOW           PROC: 0
> PUTF: 0             RDES: 0x2692550     RPRO: 0             RSET: 0x7f0c63ace4c0
> SCAN: 1 second      SDIS:CONSTANT       SEVR: NO_ALARM      SMSL: supervisory
> SPVT: 0x2729ec0     STAT: NO_ALARM      STPL:CONSTANT 0
> TIME: 2017-12-01 15:15:02.240922343     TPRO: 0             TRIG:CONSTANT
> TSE: 0              TSEL:CONSTANT       TVAL: 0             UDF: 0
> VAL: 0.85615244554806
> 
> -Dan
> 
> -----Original Message-----
> From: Mark Rivers [mailto:rivers@cars.uchicago.edu]
> Sent: Friday, December 01, 2017 9:12 AM
> To: Crisp, Daniel <CrispD@nscl.msu.edu>; tech-talk@aps.anl.gov
> Subject: Re: EPID bumpless restart
> 
> Hi Dan,
> 
> 
> Have you had a chance to test this?
> 
> 
> I had an idea what could be causing your problem with the Integral term not being set
> correctly.  Can you send the output of dbpr of all fields for the epid record, i.e.
> 
> 
> dbpr "myEpidRecord",4
> 
> 
> Is the link to the power-supply PV a CA link?
> 
> 
> Mark
> 
> 
> 
> ________________________________
> From: Crisp, Daniel <CrispD@nscl.msu.edu>
> Sent: Wednesday, November 29, 2017 6:07 PM
> To: Mark Rivers; tech-talk@aps.anl.gov
> Subject: RE: EPID bumpless restart
> 
> 
> Hello Mark,
> 
> 
> 
> Ah, great! For what it's worth, that looks good to me. I'll try this tomorrow and let you
> know how it works. I'll also double check how the bumpless restart is/isn't acting so I can
> answer Matthew.
> 
> 
> 
> Thank you for the quick responses!
> 
> -Dan
> 
> 
> 
> 
> 
> From: Mark Rivers [mailto:rivers@cars.uchicago.edu]
> Sent: Wednesday, November 29, 2017 6:57 PM
> To: Crisp, Daniel <CrispD@nscl.msu.edu>; tech-talk@aps.anl.gov
> Subject: RE: EPID bumpless restart
> 
> 
> 
> Hi Daniel,
> 
> 
> 
> I think this patch to devEpidSoft.c should implement ODEL.  Let me know if this works
> and I will commit it.
> 
> 
> 
> diff --git a/stdApp/src/devEpidSoft.c b/stdApp/src/devEpidSoft.c
> 
> index 62c753f..118fb0c 100755
> 
> --- a/stdApp/src/devEpidSoft.c
> 
> +++ b/stdApp/src/devEpidSoft.c
> 
> @@ -41,6 +41,8 @@
> 
>   *  dT(n)   Time difference between n-1 and n
> 
>   */
> 
> 
> 
> +#include    <math.h>
> 
> +
> 
> #include    <alarm.h>
> 
> #include    <dbDefs.h>
> 
> #include    <dbAccess.h>
> 
> @@ -207,7 +209,9 @@ static long do_pid(epidRecord *pepid)
> 
>      pepid->dt   = dt;
> 
>      pepid->err  = e;
> 
>      pepid->cval  = cval;
> 
> -    pepid->oval  = oval;
> 
> +    if ((pepid->odel != 0) && (fabs(pepid->oval - oval) > pepid->odel)) {
> 
> +        pepid->oval  = oval;
> 
> +    }
> 
>      pepid->p  = p;
> 
>      pepid->i  = i;
> 
>      pepid->d  = d;
> 
> 
> 
> Mark
> 
> 
> 
> 
> 
> From: tech-talk-bounces@aps.anl.gov<mailto:tech-talk-bounces@aps.anl.gov> [mailto:tech-
> talk-bounces@aps.anl.gov] On Behalf Of Crisp, Daniel
> Sent: Wednesday, November 29, 2017 2:48 PM
> To: tech-talk@aps.anl.gov<mailto:tech-talk@aps.anl.gov>
> Subject: EPID bumpless restart
> 
> 
> 
> Hello,
> 
> 
> 
> I'm currently using the EPID record to stabilize a dipole fields. It is reading a magnetic field
> from a hallprobe controller, and driving a power supply current to match the hallprobe
> reading to a target value specified by the user.
> 
> 
> 
> 1)      How can I make the EPID record perform a 'bumpless restart'?
> 
> Currently, if the power supply set point is significantly changed while the EPID feedback is
> off, the epid record will drive around the supply wildly once turned back on. I have some
> channels set up which pause a user's request to turn on feedback until the '<epid_channel>.I'
> field can be automatically set with the live value in the supply. And when I monitor the
> '<epid_channel>.I' value, I see that it in fact does get set, but it then gets overwritten and
> ignored. What's the best way of dealing with this?
> 
> 
> 
> 2)      How to best implement a deadband? (It appears there was a thread about the ODEL
> field being present, but not used in the epid support code? Am I wrong? Is this still the
> case?)
> 
> Especially for some magnets that require a less frequent touch, I'd like the epid to only act
> on the supply when the error reaches a larger percent difference. Specifically, I'd like it to
> only react to errors in field greater than, say, .01% of the target field. We had tried to simply
> decrease the KP value enough that resulting P values are less than what can be acted on by
> the supply (supply doesn't recognize a difference in set points differing by the 3rd
> significant figure), but this isn't ideal.
> 
> 
> 
> Thank you!
> 
> -Dan
> 


References:
EPID bumpless restart Crisp, Daniel
RE: EPID bumpless restart Crisp, Daniel
RE: EPID bumpless restart Crisp, Daniel

Navigate by Date:
Prev: RE: EPID bumpless restart Crisp, Daniel
Next: Re: caget() from C++ Church, Eric D
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
Navigate by Thread:
Prev: RE: EPID bumpless restart Crisp, Daniel
Next: Release or Tags in epics-modules Jeong Han Lee
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
ANJ, 04 Dec 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·