Re: looking for OSI version of epid record

[Andrew Johnson <anj@aps.anl.gov>]

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.

- Andrew
--
There is considerable overlap between the intelligence
of the smartest bears and the dumbest tourists.
  -- Yosemite National Park Ranger