Experimental Physics and
| |||||||||||||||
|
On 28.07.2010 04:45, Luedeke Andreas wrote: Angus Gratton wrote on 27/07/10 01:00:Thanks Ralph& Mark. 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. 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: 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
| ||||||||||||||
ANJ, 02 Sep 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |