Experimental Physics and
Industrial Control System

LYNCH, Damien 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. 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.

Hang in there and see what happens as the controlled value responds
to the new output value.  With KP!=0 and KI==KD==0, you should see
ERR=VAL-CVAL, and OVAL=KP*ERR.  If not, do a "dbpr" on the record
and send that.  There might be some control field we're not
thinking about with an unexpected value.

ERR is calculated correctly and OVAL contains the value == KP * ERR.

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?

Damien has a point -- do the EPID record authors realise that the AO record only looks at OIF and performs the required integration when OMSL=Supervisory and the delta is being fetched through DOL? The integration is implemented in fetch_value() which is only called if ((pao->dol.type != CONSTANT) && (pao->omsl == menuOmslclosed_loop)), thus if DOL is not set and a value is poked straight into the AO's VAL field using the EPID.OUTL link, no integration will take place.

This behaviour of the AO record was probably designed for the old PID record which expected you to use DOL with OIF, and is not something we can change now.

The EPID record does the addition or integration before it writes the
value, so it doesn't matter what the AO record does.  This is pretty
handy because it means you don't have to drive an AO record with the
EPID record; you can drive any record.

I would recommend new users use the database and medm displays supplied
with the record (pid_control.db, pid_control*.adl).  This might make the
intended use clearer.  Also, there's a substitutions file in the xxx
module (pid_slow.substitutions) that gives an example of how the macros
in pic_control.db are specified.  Don't forget to set the SCAN and FBON
(FeedBackON) fields, or the record will just sit there looking pretty.

--
Tim Mooney ([email protected]) (630)252-5417
Beamline Controls & Data Acquisition Group
Advanced Photon Source, Argonne National Lab

References:

RE: looking for OSI version of epid record LYNCH, Damien

Re: looking for OSI version of epid record Andrew Johnson

Navigate by Date:

Prev: Re: looking for OSI version of epid record Andrew Johnson

Next: Re: Dev Asyn and Cygwin/Win IOCs , Modbus and scheduling. Bill Nolan

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 Andrew Johnson

Next: RE: looking for OSI version of epid record Mark Rivers

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