EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  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  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Analog output device support design
From: Ralph Lange <[email protected]>
To: [email protected]
Date: Wed, 28 Jul 2010 09:51:47 -0400
Some comments to (hopefully) clarify the situation further...

On 28.07.2010 04:45, Luedeke Andreas wrote:
Angus Gratton wrote on 27/07/10 01:00:
Thanks Ralph& Mark.

On Mon, 2010-07-26 at 09:40 -0400, Ralph Lange wrote:

That way an ao with "...@5V BIP" and EGUF/EGUL = +/- 5 will convert from
"output voltage" to the 16-bit integer your card needs, while setting
EGUF/EGUL to something else will do the linear conversion from that
"something else" range to your raw value. This is the whole point of
having EGUF/EGUL/EGU as design fields -
OK, sounds great. It's possible to have device support set the defaults
though, right? To avoid the designer having to repeat themselves in each
record if they just want the default case?
If I understood correctly, you want to have a two-step conversion:
1.) convert from physical units (double) to DAC output voltage (double)
2.) convert from output voltage (double) to DAC 16 bit integer (int16)

Here I would like to ask Angus, if the two-step conversion is really needed.


While in some cases (Andreas was giving examples) the two-step conversion might be useful and appropriate, it is *not* the regular case.
Usually the database designer sets LINR, EGU, EGUF, and EGUL. They will do that for every analog record that does linear conversion, so I would not consider this an extra burden.


While the first part has to be configured in the database, the second
should be set automatically
depending on your OUT link.

I think this makes sense, if the device support actually sets the output
mode of the DAC.
If the mode is jumpered, why should the device support know at all how?
It would be fully sufficient to do the conversion in the record support
via EGUF/EGUL,
the device support just passes the int16 to the DAC.
Therefore you would not need the VMEIO parameter string at all, just
specify card and signal.
That way, all information needed is in the EGUF/EGUL/EGU fields: it is
maybe wrong, but not inconsistent :-)

Again, this is the usual case.
If Device Support can read back the jumper settings (it is not strictly necessary that it is able to set the mode), it has all information to convert from engineering units via EGUF/EGUL to the raw value.
If the jumper setting is unknown to Device Support, the OUT link would usually contain a hint for the device support to allow correct conversion. In that case you have to manually check that the jumper settings are matching, else your conversion does not work correctly.


In case you can set the DAC polarity and range from the driver,
you will have the problem that it is not foreseen in the normal "ao"
record support to have a two stage conversion.
It will use EGUF/EGUL to convert a double (either physical units or
output voltage) to an integer.
You could set EGUF/EGUL from the device support, depending on your
parameter string in the OUT link.
But EGUF/EGUL is normally set in the database, so it would may confuse
some people.

Yes. That would not be the usual way such devices are handled, and I would try to avoid introducing an unusual behavior without good reason.


If you still want to do it, you could call your parameter like "...@5V
BIP setEGUx" to give a hint
and then set EGUF/EGUL and EGU.
Another "standard" way would be to handle everything in the database
template:
Your parameter string could be defined like "...@$(EGU) $(EGUL) $(EGUF)"
and allowed values are:
for 5V bipolar ->  {EGU=V,EGUL=-5,EGUF=+5} ->  "...@V -5 +5"
for 10V unipolar ->  {EGU=V,EGUL=0,EGUF=10} ->  "...@V 0 10"
Those substitution values can be used to define the fields, too:

record(ao,"xxx") {

         field(DTYP,"DACyyy")
         field(OUT,"#C$(CARD) S$(SIGNAL) @$(EGU) $(EGUL) $(EGUF)")
         field(EGU,"$(EGU)")
         field(EGUL,"$(EGUL)")
         field(EGUF,"$(EGUF)")

}

Which nicely demonstrates that this is redundant, and database designers would be confused and left without a clue what is happening.


In both cases I would suggest a second record to convert from
engineering units to output voltage.

I would suggest implementing the standard behavior (direct conversion from engineering to raw value), and use an additional CALC record that converts from raw value to output voltage in exactly the cases where you need to know the voltage.


Another case where we wanted to have a two-stage conversion at the SLS
was a pre-calibrated DAC.
The DAC have some, hopefully little systematic non-linearity.
You can measure those with a precise volt-meter and generate breakpoint
tables from those measurement.
If you do that, you get a perfectly linear DAC over the full range.
In particular, if you ever have to change the DAC, you put in a new DAC,
change to the new breakpoint table and the output voltages will be
perfect again.
But then of course you should not mix physical unit conversion with the
DAC voltage conversion,
but have two independent records.

Note that the analog records actually do a two-stage conversion: there are two additional fields, AOFF and ASLO, that can be used for a second, device related linear conversion.
If you need a breakpoint table for that second conversion, you best bet is adding a second record, as Andreas pointed out. (Although you might get by with using the breakpoint table and then ASLO/AOFF for the two conversions.)


I know, it's confusing... sorry
Ralph

Replies:
Re: Analog output device support design Angus Gratton
References:
Re: Analog output device support design Luedeke Andreas

Navigate by Date:
Prev: RE: Developing of record / driver / device support? Asyn? Steiner, Mathias
Next: Re: Analog output device support design Ralph Lange
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Analog output device support design Luedeke Andreas
Next: Re: Analog output device support design Angus Gratton
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·