areadetector-driver

Implement EPICS areaDetector ADDriver subclasses with NDArray acquisition and threading.

1|1|Updated Apr 14, 2026
One-click install
npx skills add https://github.com/BCDA-APS/opencode-skills --skill areadetector-driver
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: areadetector-driver
Source: https://github.com/BCDA-APS/opencode-skills/tree/main/areadetector-driver
Command: npx skills add https://github.com/BCDA-APS/opencode-skills --skill areadetector-driver

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It helps you design and implement EPICS areaDetector camera/detector drivers that acquire hardware images, package them as NDArray objects, and expose standard detector controls to the IOC ecosystem.

Core Features & Use Cases

  • ADDriver-based detector implementation: Create a C++ driver class inheriting from ADDriver (via asynNDArrayDriver/asynPortDriver) to provide a consistent control and data publication model.
  • NDArray allocation, metadata, and publication: Allocate NDArray buffers from the NDArrayPool, fill image data, set array-level parameters (dimensions, datatype, color mode, timestamps), publish to downstream plugins, and correctly release buffers to avoid pool exhaustion.
  • Acquisition and threading pattern: Implement a robust acquisition thread pattern driven by PV writes (e.g., ADAcquire), including correct lock/unlock behavior around blocking hardware I/O and handling single/multiple/continuous acquisition modes.
  • IOCDB template and iocsh registration support: Define driver-specific records via templates and register an IOC shell configuration function so the driver can be instantiated reliably.

Quick Start

Ask the AI to generate a skeleton ADDriver-based C++ class (headers, constructor, acquisition thread, NDArray publish path, writeInt32 handling for ADAcquire) for your detector, including the matching Makefile DBD registrar snippet and a minimal .template file for one driver parameter.

Frequently Asked Questions about areadetector-driver

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I implement an EPICS areaDetector driver for a custom camera?

To implement an EPICS areaDetector driver, you create a C++ class inheriting from ADDriver to convert hardware image acquisition into NDArray objects. This involves managing NDArray buffers, setting dimensions and metadata, and publishing data through asynNDArrayDriver mechanisms to downstream plugins.

What is the correct way to manage NDArray buffer allocation in an asyn driver?

NDArray buffer management requires allocating objects from the NDArrayPool, filling them with image data, and correctly releasing them after publication. Proper allocation and release cycles are critical to avoid pool exhaustion and ensure stable data streaming to areaDetector plugins.

How do I handle ADAcquire and ADImageMode control via writeInt32 in areaDetector?

Handling ADAcquire and ADImageMode involves wiring PV writes through the writeInt32 method and synchronizing with the acquisition thread. This pattern correctly drives single, multiple, or continuous image acquisition modes based on user requests from the GUI.

How does the acquisition thread pattern work for blocking hardware I/O in areaDetector?

The acquisition thread pattern requires correct lock and unlock behavior around blocking hardware I/O operations. This ensures the driver remains responsive to asyn port requests while waiting for hardware exposure and readout to complete during image capture cycles.

Do I need iocsh registration and database templates to build an areaDetector driver?

Yes, you need to define driver-specific records via database templates and register an IOC shell configuration function. This iocsh registration allows the ADDriver subclass to be instantiated reliably within the EPICS IOC startup environment.

Why does my areaDetector driver cause NDArrayPool exhaustion during continuous acquisition?

NDArrayPool exhaustion occurs when NDArray objects are not correctly released after publication via doCallbacksGenericPointer. Releasing buffers back to the pool immediately after downstream plugins process them prevents pool depletion and maintains continuous acquisition stability.