search

areaDetector / ADCore

The home of the core components of the EPICS areaDetector software. It includes base classes for drivers and code for all of the standard plugins.
https://areadetector.github.io/areaDetector
Other
20 stars 69 forks source link

{P}:cam1: prefix necessary? #442

Closed tangkong closed 4 years ago

tangkong commented 4 years ago

This is more of a question than an issue, let me know if I should redirect this somewhere else.

Why are generic AreaDetector parameters organized under "{P}:cam1:"? Are we expecting multiple "cameras" for a single detector? I understand the other plugins getting a subdivision ("{P}:TIFF:" or "{P}:HDF5:" etc)

Do we break compatibility with other EPICS modules or something similar by removing the "cam1:" sub-PV designation? I feel it's unlikely we would have several "cameras" per detector, each requiring its own settings and acquire controls, but perhaps I am missing something.

Thanks,

Robert

MarkRivers commented 4 years ago

Why are generic AreaDetector parameters organized under "{P}:cam1:"? Are we expecting multiple "cameras" for a single detector? I understand the other plugins getting a subdivision ("{P}:TIFF:" or "{P}:HDF5:" etc)

No, it is not for multiple "cameras" per detector, it is to allow multiple cameras per IOC. A single IOC could be controlling 3 cameras, cam1:, cam2:, cam3:. By using that additional $(R) prefix we also help to guarantee that the record names do not conflict with names from other modules like autosave, etc. If you want to set $(R) for the camera to "" I think that should work.

tangkong commented 4 years ago

I see, that helps clarify things. Thanks!