ADBase.template equivalent for 1D detectors

[hinxx]

I'm using areaDetector with many ADC (digitizers), mostly on uTCA platform. Number of channels varies from 1 to 10 or more, but I tend to have them split into individual asyn addresses within the driver (not using a 2D NDArray).

I have developed couple of ADDrivers and I'm including NDArrayBase.template at the top of my driver DB files. The reason being that ADBase.template provides lots of 2D detector (camera?) specific records. OTOH, I find myself defining (per driver) generic records like serial number, manufacturer, status messages, and similar since NDArrayBase.template does not include those.

Would it be acceptable to provide 1D detector ADBase.template equivalent only with records ticked below (some are marked with ? as I'm not sure if they would be needed)? See below for an idea of what would be included. In addition, looking at the ADCSimDetector.template I think some of those records would be candidates for this new 1D template, too. There might be some new records added, 1D specific, but haven't gone that far just yet to identify some.

I assume that template C++ counterpart would be needed also.

√	$(P)$(R)Manufacturer_RBV
√	$(P)$(R)Model_RBV
√	$(P)$(R)SerialNumber_RBV
√	$(P)$(R)SDKVersion_RBV
√	$(P)$(R)FirmwareVersion_RBV
√	$(P)$(R)MaxSizeX_RBV
	$(P)$(R)MaxSizeY_RBV
√	$(P)$(R)BinX
√	$(P)$(R)BinX_RBV
	$(P)$(R)BinY
	$(P)$(R)BinY_RBV
√	$(P)$(R)MinX
√	$(P)$(R)MinX_RBV
	$(P)$(R)MinY
	$(P)$(R)MinY_RBV
√	$(P)$(R)SizeX
√	$(P)$(R)SizeX_RBV
	$(P)$(R)SizeY
	$(P)$(R)SizeY_RBV
√	$(P)$(R)ReverseX
√	$(P)$(R)ReverseX_RBV
	$(P)$(R)ReverseY
	$(P)$(R)ReverseY_RBV
√	$(P)$(R)AcquireTime
√	$(P)$(R)AcquireTime_RBV
√	$(P)$(R)AcquirePeriod
√	$(P)$(R)AcquirePeriod_RBV
√	$(P)$(R)TimeRemaining_RBV
	$(P)$(R)Gain
	$(P)$(R)Gain_RBV
√	$(P)$(R)FrameType
√	$(P)$(R)FrameType_RBV
√	$(P)$(R)ImageMode
√	$(P)$(R)ImageMode_RBV
√	$(P)$(R)TriggerMode
√	$(P)$(R)TriggerMode_RBV
?	$(P)$(R)NumExposures
?	$(P)$(R)NumExposures_RBV
?	$(P)$(R)NumExposuresCounter_RBV
√	$(P)$(R)NumImages
√	$(P)$(R)NumImages_RBV
√	$(P)$(R)NumImagesCounter_RBV
√	$(P)$(R)Acquire
√	$(P)$(R)Acquire_RBV
√	$(P)$(R)SetAcquireBusy
√	$(P)$(R)AcquireBusy
√	$(P)$(R)AcquireBusyCB
√	$(P)$(R)ClearAcquireBusy
√	$(P)$(R)WaitForPlugins
√	$(P)$(R)DetectorState_RBV
√	$(P)$(R)StatusMessage_RBV
√	$(P)$(R)StringToServer_RBV
√	$(P)$(R)StringFromServer_RBV
√	$(P)$(R)ReadStatus
	$(P)$(R)ShutterMode
	$(P)$(R)ShutterMode_RBV
	$(P)$(R)ShutterControl
	$(P)$(R)ShutterControl_RBV
	$(P)$(R)ShutterStatus_RBV
	$(P)$(R)ShutterOpenDelay
	$(P)$(R)ShutterOpenDelay_RBV
	$(P)$(R)ShutterCloseDelay
	$(P)$(R)ShutterCloseDelay_RBV
	$(P)$(R)ShutterControlEPICS
	$(P)$(R)ShutterFanout
	$(P)$(R)ShutterOpenEPICS
	$(P)$(R)ShutterCloseEPICS
	$(P)$(R)ShutterStatusEPICS_RBV
?	$(P)$(R)Temperature
?	$(P)$(R)Temperature_RBV
?	$(P)$(R)TemperatureActual

[MarkRivers]

That would be fine. The inheritance for araDetector 2-D drivers such as ADProsilica is:

Driver	Template file
asynPortDriver	None
asynNDArrayDriver	NDArrayBase.template
ADDriver	ADBase.template
ADProsilica	ADProsilica.template

I have written a number of drivers that inherit from asynNDArrayDriver for other types of devices. These include dxp and dxpSITORO for DSP spectroscopy systems (https://github.com/epics-modules/dxp, https://github.com/epics-modules/dxpSITORO), and quadEM for quad current meters/BPMs (https://github.com/epics-modules/quadEM). There is also a base class for transient recorders that inherits directly from asynPortDriver (https://github.com/epics-modules/transRecorder).

For devices that don't fit into these categories then making a new base class that derives from asynNDArrayDriver and provides a new database on top of NDArrayBase.template makes sense. The question is whether it belongs in the areaDetector project, or in its own repository in epics-modules, for example.

[hinxx]

I was thinking of a new asynNDArrayDriver derived class and template that would include NDArrayBase.template that would live in ADCore. Maybe I should just create proof of concept and do a PR, and you can see what I mean.

Then I would use this new class and template as basis for ADC drivers.

I would prefer to be as close as possible to the ADCore code. Looking at transientRecorder repo it looks unmaintained; two years of no activity..

If I would opt to have those drivers in epics-modules, are there any requirements/restrictions for code to be living there?