Jupyter notebook should:

Include

• Example usage of grid scans (both bounded, unbounded)
• Images describing scan procedures
• LivePlot functionality
• Steps to bring up past results and learn about scan parameters
• How to deal with stage object / methods (setting positions, moving to positions)

Requires:

• simulated ophyd objects
• databroker setup
• hitp stage object

This notebook should:

Include

• proper warnings about not collecting data from notebook. Commands should all be replicated in ipython console
• example of alignment with point detector, as with beam stop detector (LivePlot)
• example of alignment with roi on xspress3, for finding masked point (LiveGrid?)

Require

• proper alignment procedure understanding
• simulated ophyd objects for beam, stage

Jupyter notebook should

Include:

• basic databroker
• note on what databroker is (way to access data, not the database itself)
• How to grab metadata vs images
• how to export tiff (suitcase)
• how to process waxs images specifically (calibration, integration)

Requires:

• example database (databroker pack?)
• processing package (dataproc? pyFAI?)

Simulated beamline components

Tasks:

• simulated detector with file store output (tiff)
• link motors to detector (only return when over valid sample)
• ... ?

Build out subset of ophyd devices necessary to simulate alignment behavior

Tasks

• level stage, pico motors linked to laser range finder
• stage z-alignment
• align to center of wafer with Xspress3 fluorescence signal

Different kickers may result in different functionality, hopefully it doesn't...

Things to check

• cursor functionality (select points)
• curve fitting
• line scan
• selecting correct axes

General functionality needed to properly simulate transmission HiTp

• Rocking Scan
• Virtual Diffractometer integration (GSASII)
• Calibration (Exposure time. on the fly? Prompt?)
• Automated data analysis

In an effort to allow db[-1].table(fill=True) to work, we need to pass the handler the correct arguments.

Looking at area-detector-handlers doesn't seem to fix things. Current error is a duplicated submission of filename to the handler, but I seem to only define it once.

Perhaps going deeper into ophyd implementations of the filestores will bear fruit.