epid final_value signal not found

[prjemian]

When using the epid object at APS 8-ID-I, we did not find the final_value (.VAL) signal.

[prjemian]

The class is defined:

apstools/apstools/synApps/epid.py

Line 34 in 8fbbbd9

class EpidRecord(EpicsRecordFloatFields, EpicsRecordDeviceCommonAll):

[prjemian]

epid record documentation: https://cars9.uchicago.edu/software/epics/epidRecord.html

[MarkRivers]

The documentation appears to be wrong. It says that the CT field is a ULONG in clock ticks, and that it is accessible from Channel Access.

However, this is from the epidRecord.dbd file:

        field(CT,DBF_NOACCESS) {
                prompt("Time")
                special(SPC_NOMOD)
                interest(4)
                extra("epicsTimeStamp  ct")
        }
        field(CTP,DBF_NOACCESS) {
                prompt("Previous time")
                special(SPC_NOMOD)
                interest(4)
                extra("epicsTimeStamp   ctp")
        }

So CT is in fact it is an epicsTimeStamp structure with the attribute DBF_NOACCESS.

Source code never lies :-).

[prjemian]

You (re)teach a valuable lesson today.

[prjemian]

In this issue, the object created in a bluesky session does not show the final_value attribute that should be connected to the .VAL field of the attribute. I wrote that instruction assuming the connection should come from the superclass EpicsRecordDeviceCommonAll as it is defined here:

apstools/apstools/synApps/_common.py

Lines 41 to 63 in 56cd7ce

	class EpicsRecordDeviceCommonAll(Device):
	"""
	Many of the field common to all EPICS records
	Some fields are not included because they are not interesting to
	an EPICS client or are already provided in other support.
	"""
	description = Component(EpicsSignal, ".DESC")
	processing_active = Component(EpicsSignalRO, ".PACT")
	scanning_rate = Component(EpicsSignal, ".SCAN")
	disable_value = Component(EpicsSignal, ".DISV")
	scan_disable_input_link_value = Component(EpicsSignal, ".DISA")
	scan_disable_value_input_link = Component(EpicsSignal, ".SDIS")
	process_record = Component(EpicsSignal, ".PROC")
	forward_link = Component(EpicsSignal, ".FLNK")
	trace_processing = Component(EpicsSignal, ".TPRO")
	device_type = Component(EpicsSignalRO, ".DTYP")
	alarm_status = Component(EpicsSignalRO, ".STAT")
	alarm_severity = Component(EpicsSignalRO, ".SEVR")
	new_alarm_status = Component(EpicsSignalRO, ".NSTA")
	new_alarm_severity = Component(EpicsSignalRO, ".NSEV")
	disable_alarm_severity = Component(EpicsSignal, ".DISS")

But this is my mistake since the .VAL field is provided in a different mixin class:

apstools/apstools/synApps/_common.py

Lines 66 to 78 in 56cd7ce

	class EpicsRecordInputFields(Device):
	"""
	some fields common to EPICS input records
	"""
	input_link = Component(EpicsSignal, ".INP")
	raw_value = Component(EpicsSignal, ".RVAL")
	final_value = Component(EpicsSignal, ".VAL")
	# will ignore simulation mode fields
	@property
	def value(self):
	return self.final_value.value

and this class is not included in the definition of the epid support here:

apstools/apstools/synApps/epid.py

Line 34 in 56cd7ce

class EpidRecord(EpicsRecordFloatFields, EpicsRecordDeviceCommonAll):

[prjemian]

The .VAL field is not common to all EPICS records?

Apparently not: https://wiki-ext.aps.anl.gov/epics/index.php/RRM_3-14_dbCommon

[MarkRivers]

The common record fields need to have the same type in every record. VAL does not, since it might be a double, a string, or an array of some type depending on the record.

[prjemian]

That underscores the finding that EpicsRecordInputFields is not a good superclass mixin for this support. It defines an RVAL field that is not available in the epid record.

The .VAL field will be added directly to the EpidRecord definition.

[prjemian]

... as a read-only signal: final_value = Component(EpicsSignalRO, ".VAL")

with final_value to match similar usage in EpicsRecordInputFields