>I don't think records should have these fields.
> One solution is to use the parm
>field of the input link, another solution is to use a "Config"
>function in the vxWorks startup.cmd file (many Argonne device
>support modules use this method).
I agree. When we did CAMAC device support we did it generically, and
placed this type of configuration information in the link field after
the "@" (the parm field).
I don't think these new fields are an optimal solution, and would
not look forward to bigger records. I'm actually not overly fond
of the current set of config parameters (ESLO, etc.). Gabor's
point of separating device dependent from device independent --
>this description has (and need) two parts , the general one
>and the record type dependent one. Why I keep them in one field ?
-- is well taken, but I think that there need be only a total of
2 config fields, defining a slope and an offset, not the currently
defined set of 4 (EGUF,EGUL,ROFF,ESLO):
VAL = RVAL * ESLOPE + EOFFSET
where device support must return in RVAL a properly manipulated signed
integer, perhaps doing some integer manipulations inside the black
box to return an unscaled but decoded integer. Whatever constants
device support needs to accomplish this should be put into the @parm
field of the link.
>Rollin', Rollin', Rollin',
>Keep those records SHRINKIN!!!!!!!!!!!
- Re: Should ai, ao records have RAWH, RAWL? Jim B. Kowalkowski
- Navigate by Date:
Re: Medm help Bill McDowell
Re: [Question] Rs232c in EPICS Jeff Hill
- Navigate by Thread:
Re: Should ai, ao records have RAWH, RAWL? Jim B. Kowalkowski
Re: Should ai, ao records have RAWH, RAWL? Bill Brown