Device features aren't periodically scanned by default

[henriquesimoes]

Some time ago I noticed that database records generated by the GenICam makeDb.py script do not include a periodic SCAN. In addition, ADAravis doesn't have its own scan thread to read the feature values and update the readback PVs that are I/O Intr, which means such features will only be read by default during initialization or when processing a user request (by calling GenICamFeatureSet::readAll, e.g. in writeInt32). For most features, this isn't a problem because they are static. The problem arises when they are values that change overtime, such as temperature.

By digging a bit further along with @ericonr, we noticed that the refactoring done to move from aravisGigE to ADGenICam + ADAravis dropped a reading mechanism that took place when no acquisition was running. There is no commit that explains the rationale for this in either repositories. What was that?

As of now, users can somewhat overcome this by overriding the automatically generated records to define a scan period for each readback PV of interest. The downsides of this are that it requires a manual intervention for having parameters properly handled and it is device-specific, which hinders the deploy for new devices (where feature names might change, as do their corresponding PVs).

Let me know if I'm missing something.

[MarkRivers]

This is simply incorrect. All drivers derived from ADGenICam have the ability to periodically poll all GenICam features.

If you look at the documentation for ADAravis you will see that the medm screen has a widget labeled "Poll features" in the Status panel in the upper right. That controls the rate at which all GenICam features are polled.
https://areadetector.github.io/areaDetector/ADAravis/ADAravis.html#medm-screens

This is implemented in the ADGenICam base class here:
https://github.com/areaDetector/ADGenICam/blob/eae8d1a775421b99d08ca25891be5cd588e7289c/GenICamApp/src/ADGenICam.cpp#L122

and here:
https://github.com/areaDetector/ADGenICam/blob/eae8d1a775421b99d08ca25891be5cd588e7289c/GenICamApp/src/ADGenICam.cpp#L336

[MarkRivers]

The ReadStatus record is documented in the ADDriver base class:
https://areadetector.github.io/areaDetector/ADCore/ADDriver.html

You need to keep in mind that areaDetector drivers are built on a class hierarchy. For ADAravis this hierarchy is:

1. asynPortDriver
2. asynNDArrayDriver
3. ADDriver
4. ADGenICam
5. ADAravis

Records, parameters, and functionality can be defined at any level in this hierarchy.

[henriquesimoes]

The ReadStatus record is documented in the ADDriver base class

Thanks. That was the missing piece for me. If I understand this correctly, GenICam's support for ReadStatus is the reason why we dropped the custom implementation we previously had in aravisGigE, right? They are not really equivalent as now the driver port lock will be held, blocking the acquisition thread (what never happened before). I hope Aravis' feature caching makes reading time negligible. I'll give it try and see how it goes.

All drivers derived from ADGenICam have the ability to periodically poll all GenICam features.

Yet it is no longer enabled by default for ADAravis. Users migrating from aravisGigE must know they must change the ReadStatus PV default value from Passive to a defined scan period. Have I also missed this migration step documented anywhere? Not sure if anyone else is still needing to migrate, but I'll be happy to provide a documentation patch for this if needed.

[MarkRivers]

They are not really equivalent as now the driver port lock will be held, blocking the acquisition thread (what never happened before).

The aravisGigE driver had its own limitations. It was hardcoded to read no more than 40 features/s. The FLIR_BFS_PGE_19S4M camera in ADGenICam has 315 features, so each one would only be read every 7.9 seconds.

I hope Aravis' feature caching makes reading time negligible. I'll give it try and see how it goes.

Note that when I was developing ADAravis I discovered that aravis did not do feature caching correctly, and it was taking 12 seconds to read all the features on some cameras. I raised it in this issue:
AravisProject/aravis#253

Users migrating from aravisGigE must know they must change the ReadStatus PV default value from Passive to a defined scan period. Have I also missed this migration step documented anywhere?

I don't think it is documented. But i think it is fairly obvious because it is in the OPI screen, right above the Temperature readback. Did you not see it because you are using pyDM and that does not have a translator from medm?

[prjemian]

because you are using pyDM and that does not have a translator from medm

https://anaconda.org/conda-forge/adl2pydm

[MarkRivers]

https://anaconda.org/conda-forge/adl2pydm

Oh, htat's good to know. Someone told me last week they didn't know of one. Would it make sense to provide autoconverted files for all synApps and areaDetector repositories, like we do for CSS/Boy, CSS/Phoebus, caQtDM, and edm?

[prjemian]

We could. Like all such translators, some MEDM widgets do not translate very well. The features do not match exactly.

[henriquesimoes]

But i think it is fairly obvious because it is in the OPI screen, right above the Temperature readback.

I've never treated the OPI screens as a source of information or documentation for IOCs. For me, it was a (sample) client application living in the same repository as the IOC. I'll start to treat them as a reference, although it feels awkward for me to depend on a GUI to understand which features an IOC implements. I'd rather have everything documented based on the PV layer, which is the actual IOC interface.

Of course, pretty much every PV a driver defines by itself is documented the way I'm referring to, including ADAravis. What is missing is a proper documentation with respect to the class hierarchy aforementioned in this thread. Which parameters from superclasses does ADAravis implement? For instance, which PVs from ADDriver does it properly implement? Which features does it depend on for proper operation?

Did you not see it because you are using pyDM and that does not have a translator from medm?

Sort of. We usually have application-specific PyDM-based GUIs. It is up to the GUI developer, with the help of the IOC developer or integrator (and often the operator), to choose which PVs from each IOC are relevant to be on screen. It turns out ReadStatus wasn't needed before. As I said, I didn't try to use the OPI screens as reference, so it wasn't the lack of a translator that hindered me.