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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: looking for OSI version of epid record |
From: | Tim Mooney <[email protected]> |
To: | Andrew Johnson <[email protected]> |
Cc: | "LYNCH, Damien" <[email protected]>, [email protected] |
Date: | Mon, 21 Aug 2006 10:02:55 -0500 |
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