Add generic support for features in EGrabber modules other than RemoteModule.

[MarkRivers]

Kuktae Kim wrote the following on an EPICS tech-talk message:

I am currently developing an EPICS IOC for the AXIS-SXRF-60 camera and the Euresys Coaxlink CXP-12 Quad Frame Grabber.
Thanks to ADGenICam and ADEuresys, I’ve been able to save a significant amount of time and effort.

Using the Euresys gentl utility, I extracted the XML files for both the camera and the frame grabber as below:

$ gentl xml  
$ ls  
6060CXP.xml  
Euresys_Coaxlink_TLDataStream_25_02_0.xml  
Euresys_Coaxlink_TLDevice_25_02_0.xml  
Euresys_Coaxlink_TLInterface_25_02_0.xml  
Euresys_Coaxlink_TLSystem_25_02_0.xml  

Next, I used the Python scripts in ADGenICam to generate the EPICS database files and OPI screens from the camera’s XML file. These were saved in:
• Database templates: ADGenICam/GenICamApp/Db
• OPI screens: ADGenICam/GenICamApp/op/edl

I’d like to know if a similar process can be applied to ADEuresys using the XML files from the Euresys frame grabber.
I created the EPICS database template and OPI screens and placed them in "/ADEuresys/EuresysApp/Db" and "/ADEuresys/EuresysApp/op/edl."

However, when I launched the GUI, most of the PVs displayed zero or N.A as below:

If I can use the database template and GUI in ADEuresys, it would be helpful for troubleshooting and diagnostics.

Does anyone know if ADEuresys has plans to support this in the same way as ADGenICam?

[MarkRivers]

Hi Kuktae,

You raise an interesting question. The Euresys EGrabber software is nice because grabber it uses GenApi to read and write feature values for both the camera and the frame grabber.

For example, integer features on the camera itself are read with this code: https://github.com/areaDetector/ADEuresys/blob/03fdd23dc59118d89863aa3a895c3e108f32d8ee/EuresysApp/src/EuresysFeature.cpp#L81C10-L82C9

value = mGrabber->getInteger<RemoteModule>(mFeatureName);

Note that getInteger is a template function, where the template defines the module that feature belongs to, RemoteModule in this case.

ADEuresys currently handles RemoteModule features in a generic way using this function. https://github.com/areaDetector/ADEuresys/blob/main/EuresysApp/src/EuresysFeature.cpp

The features you would like to use are in other modules. ADEuresys currently handles just a few of those in a non-generic way. For example, this is the ADEuresys::readStatus function:

asynStatus ADEuresys::readStatus()
{
    mGrabber_->setString<StreamModule>("EventSelector", "RejectedFrame");
    epicsUInt64 rejectedFrames = mGrabber_->getInteger<StreamModule>("EventCount");
    setIntegerParam(ESRejectedFrames, (int)rejectedFrames);
    epicsUInt64 CRCErrors = mGrabber_->getInteger<InterfaceModule>("CxpStreamDataPacketCrcErrorCount");
    setIntegerParam(ESCRCErrorCount, (int)CRCErrors);
    epicsUInt64 outputQueue = mGrabber_->getInfo<StreamModule, uint64_t>(GenTL::STREAM_INFO_NUM_AWAIT_DELIVERY);
    setIntegerParam(ESOutputQueue, (int)outputQueue);
   
    return ADGenICam::readStatus();
}

Note that it reads features from the StreamModule and InterfaceModule.

ADEuresys could be enhanced so that it provides generic support for the StreamModule, InterfaceModule, and other modules. It would not be too difficult. The EuresysFeature class would need to be extended so that it knows which module a feature belongs to. That information would need to be encoded in the link fields of the records that the Python parser produces. This is an example record for a camera feature that uses the RemoteModule.

record(ao, "$(P)$(R)GC_AcqFrameRate") {
  field(DTYP, "asynInt64")
  field(OUT,  "@asyn($(PORT),$(ADDR=0),$(TIMEOUT=1))GC_I_AcquisitionFrameRate")
  field(DISA, "0")
}

Note that drvInfo string is GC_I_AcquisitionFrameRate. “GC” flags that this is a GenICam camera parameter (i.e. RemoteModule), “I” means that it is an integer, and AcquisitionFrameRate is the feature name from the camera XML file. We could use ST for StreamModule, IN for InterfaceModule, etc. The Python code would need to use those strings when writing the database file, and the GenICam parser would need to understand them and create a GenICam feature with the correct module identifier.

[MarkRivers]

I have now completed this enhancement. It required changes to the following:

• The Python scripts that generate the database and OPI files in ADGenICam. These now accept an optional 2-letter prefix. The default is GC.
• The parser in ADGenICam::drvUserCreate. It now allows any 2-letter prefix, not just GC.
• EuresysFeature class. It is now a template class which uses the GenICam module template parameter.
• ADEuresys:createFeature(). It now uses the prefix in the drvInfo string to determine which module to use:
  • GC = RemoteModule
  • DV = DeviceModule
  • DS = DataStreamModule
  • IF = InterfaceModule
  • SY = SystemModule

ADGenICam now contains the XML, database, and OPI files for the Euresys TL modules.

The release notes for ADGenICam and ADEuresys explain the changes.
https://github.com/areaDetector/ADEuresys/blob/main/RELEASE.md
https://github.com/areaDetector/ADGenICam/blob/master/RELEASE.md

These are the new medm screens corresponding to the edm screens in the first post in this issue. Note that now the PVs are showing the actual values of the features and they can be controlled.