Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Thu, 16 Aug 2001 15:11:10 -0500

Benjamin Franksen wrote:
> 
> Interestingly, whenever I talked about this with colleagues, I received
> the impression that *being able* to set ESLO and EOFF directly instead
> of letting device support do it, would be appreciated as a matter of
> *more convenience and tranparency* in a number of cases, regardless of
> whether device support is able to do so or not.

I was all set to post this reply to the above:

> Ok, I'm convinced that there are situations where being able to set EOFF
> and ESLO is desirable, and the addition of an extra state to the LINR
> menu will make this completely backwards compatible.  The "LINEAR_MANUAL"
> state name seems kind of unwieldy - how about "SLOPE" as one possible
> alternative, unless someone thinks of a better name.  We'd change the ao
> record code so that the device support's special_linconv routine is only
> called when LINR=LINEAR (and EOFF is only set to the EGUL value by the
> record in this case too).  The ESLO and EOFF fields become
> promptgroup(GUI_CONVERT) and thus configurable by DCTs.  EGUL and EGUF
> both have pp(TRUE), so the same should be true for ESLO and EOFF (meaning
> that changing either through CA will cause a new value to be read and
> converted using the new settings).
> 
> Should these fields have CA monitors posted?  I think so - we can call
> db_post_events() from inside the record's special() routine after calling
> dset->special_linconv(), which means that CA clients that are providing
> the ability to set ESLO and EOFF will know their latest values if EGUL or
> EGUF change while LINR=LINEAR.
> 
> What should happen if device support doesn't provide a special_linconv()
> routine?  Currently EOFF is set from EGUL, but ESLO keeps its old value
> (1.0 by default).  It's easy to allow manual setting of both in this case
> too, although I'm not sure whether this is the right thing to do when
> LINR=SLOPE is available to permit that.  I note that the Raw Soft
> supports both provide a special_linconv() routine which does nothing so
> unless these are also changed they will retain the current behaviour
> anyhow.

when Marty pointed out that by introducing a new state into
menuConvert.dbd we would break any existing applications that add their
own breakpoint tables (because they provide their own copy of
menuConvert.dbd and are only allowed to add items to the end of the menu
defined in base), and possibly the AllenBradley 1771IXE device support
which apparently makes assumptions about the LINR field.  Aarrrgghh!!! 
These changes can be made, but probably not in a minor release (breaking
backwards compatibility is generally verboten for minor releases).  Thus
Marty is willing to accept the above in 3.14, but not in a 3.13.x release.

Life is never as simple as we'd like it to be.

- Andrew
-- 
The world is such a cheerful place when viewed from upside-down
It makes a rise of every fall, a smile of every frown

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System