Re: Analog input record offsets

[mooney@aps.anl.gov (Tim Mooney)]

re...

> From npr@jach.hawaii.edu Mon Nov 28 20:22:08 1994
> To: tech-talk@aps.anl.gov
> Subject: Analog input record offsets
> Content-Length: 2155
> X-Lines: 46
> 
> 
> I have a rotary encoder with a range of travel less than 360 degrees
> that I want to read into an analog input record. (Yes, its the
> telescope mount encoder).  Unfortunately I have no guarantee where the
> encoder zero point is. The zero point adjustment has to be added to the
> raw value in encoder units, and then the value circularly normalised so
> the value from the encoder always lies between two accepted values.
> 
> I have to write analog input device support for the hardware, so I was
> intending to do this fiddling in device support. Looking at the record
> support, it would seem that the ROFF field might be a field I could use
> - it is in digitizer units (the most convenient in this case) and is
> added to the raw value just after it is returned from device support.
> Device support would then:
> 
> a. Read the value.
> b. Add ROFF
> c. Circularly normalize between the maximum and minimum possible values.
> d. Subtract ROFF (so that it can be added once again in record support).
> 
> A few questions:
> 
> 1. How do I set ROFF? The documentation says `it is the responsibility
>    of the device support routines to use EGUF and EGUL to compute ESLO
>    and ROFF'. All very well but none of the device support routines I
>    have reference ROFF. (grep roff ~epics/share/src/dev/*.c returns nothing).
>    What gives? Am I missing a trick somewhere?
> 
> 2. Can I use EGUF and EGUL in ways that were not intended? (i.e. basically
>    ignore them - they don't have sufficient precision). I presume so.
> 
> 3. If ROFF isn't used by device support, can I just set it at
>    initialization - or even in dct (this would require a change to
>    aiRecord.ascii) to a specific value without breaking things?
> 
> I admit it is a bit ugly, but the alternative is to write a new analog
> input record for the special case of a circular encoder - and still
> have to write device support for it. If people think this is a better
> way (or have any other suggestions), do tell me.
> 
> Nick Rees
> 
> Joint Astronomy Centre                    Ph:       +1 (808) 961-3756
> 660 N. Aohoku Place                       Fax:      +1 (808) 961-6516
> Hilo, HI.  96720                          Internet: npr@jach.hawaii.edu
> 
> 

There are lots of alternatives, of course.  If the analog-input record
can't be made to do what you want all by itself, how about a long-in
followed by a calc?

Tim Mooney