Experimental Physics and Industrial Control System
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
<2010>
2011
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
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024