OK. This is the correction to the correction. I now understand
the Histogram record better after going through the code with Janet.
(Somebody should rewrite the description in the Record Support
Manual.) The record could stand a little work, too (in my opinion),
but it should function as it is.
If you want to use MEDM and the Cartesian Plot with the Histogram
record, the following would be a good starting point: Enter the
Histogram process variable for y and nothing for x. X will then be
the index of the bin and go from 0 to NELM-1. If you want something
besides this for x, you can make a Waveform with the appropriate
values and enter that process variable for x. You probably want to
set the Plot Mode to "plot last n pts". You should set the Axis Data
to "auto-scale", not "from channel", which is the default. Remember
that the y values can grow, but the x values are fixed, since you
can't change NELM.
If you use "auto-scale" it doesn't matter if the record has a
get_graphic_double or get_control_double routine. By the way, MEDM
gets the value as a DBR_CTL_DOUBLE, presumably causing the
get_control_double routine to be called. I have been told by Marty
Kraimer that default values (zeros), not garbage, are returned to MEDM
if the record support does not have the routine. I believe this has
not always been so. In the case of the Histogram, it returns 0 for
the upper and lower_disp_limit in the dbr_ctrl_double struct. These
are what are typically thought of as HOPR and LOPR, and they are
called hopr and lopr in the MEDM code, though they do not have to be
the values of HOPR and LOPR fields in the record. Hopefully, I have
stated it completely correctly this time. The jist was right before.
As far as the limits: The Histogram record should probably have a
HOPR, LOPR, and PREC. These aren't needed by the record support, but
they are used by MEDM. The engineer that designs the database can
specify what he thinks is appropriate, the same as for these fields in
other records. They can also be set through channel access.
Moreover, ULIM and LLIM are not the same as HOPR and LOPR. HOPR
and LOPR apply to the counts or y axis in the plot above. ULIM and
LLIM apply to the bins or the x axis.
Regarding the PREC field. The VAL of the Histogram is a long, so
the default, 0, for the get_precision record-support routine is all
right. However, it is not appropriate for other fields in the record,
such as WDTH, ULIM, and LLIM. These values are doubles and typically
have a fractional part. They will display as integers in MEDM because
of the default precision. This is confusing. You may see a zero when
the value is really 0.4. The Histogram record should have a PREC
field and should return PREC for the precision for these fields. (In
my opinion.) Soon, you (the user or screen designer) can at least
change the number of decimal points displayed from the value returned
from channel access. Right now, you are stuck with 0.
Finally, it should be noted that MEDM changes its values when it
receives monitor callbacks. It does not poll. This means that fields
that do not send monitors, such as the WDTH or CSTA fields in the
Histogram record, do not update in MEDM. (Or Probe, or Camonitor,
etc.) There are many fields in most records that display this
behavior. The user should be aware of this. You can get current
values by closing and reopening the screen.
-Ken
- Navigate by Date:
- Prev:
beta12 & GPIB & Compiler Bug Marty Kraimer
- Next:
Re: where to find PMAC Controller support ? Andy Foster
- 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: Limits problems in MEDM and the Histogram Record Ken Evans
- Next:
Supported hardware Mark Rivers
- 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
|