Conversation
ericonr
left a comment
ericonr
left a comment
There was a problem hiding this comment.
plugins: configure set of plugins.
configure plugin set.
This set has been defined in order to be a minimal functional processing
pipeline. Pilatus4 already compress the frames, so we can directly save
it in a HDF5, but then we need to decompress it in order to visualize.
For this reason, the codec plugin is set. ROI can also be used to crop
the image in the viewer.
in an HDF5 file
the code plugin is instantiated.
directly saved into a HDF5 file.
an HDF5 file
ericonr
left a comment
ericonr
left a comment
There was a problem hiding this comment.
But we should only merge when it actually builds :p (so when eiger support is released)
gustavosr8
force-pushed
the
initial-poc
branch
7 times, most recently
from
077b317 to
f22f231
Compare
gustavosr8
force-pushed
the
initial-poc
branch
2 times, most recently
from
2914b9e to
47171d0
Compare
|
Can you fix repository permissions? I seem to lack powers to to reopen threads. |
ericonr
left a comment
ericonr
left a comment
There was a problem hiding this comment.
commit:
plugins: define default plugin configuration and processing pipeline.
define pipeline options. (?)
The data from the detector could come from both FileWriter or Stream, so
both pipelines could be configured and one can choose they in the
deploy.
both pipelines can be used, and they are chosen when deploying the IOC.
For the FileWriter option, if we stream the data in the AD pipeline, we
would need to a file to be written before actually visualize the
acquisition. To avoid this, define DataSource as None and enable Monitor
(receiving data from ADDR 10) to actually stream the data.
to wait for a file
actually visualizing
Monitor (which sends its data on address 10)
For the Stream option, the processing pipeline is define as a fork
receiving the frame from the driver, already compressed, using Stream2.
On one side, there is a Decompress/ROI/StdArray chain for visualisation;
on the other side, the frame is directly saved into an HDF5 file.
defined as a fork
into an HDF5 file and sent over PVA.
`commonDriverMakefile` is used to configure all the dependencies as well as system libraries (those built in ADSupport or not). This simplifies greatly src/Makefile. These dependencies are listed in the RELEASE file. However, no path is given as it will be determined by the container environment yet to be configured. Example IOC for Pilatus4 detector have been set, since it is the detector intended to be used by now. Eiger1 and Eiger2 can also be added in the future if needed. `device.cmd` has been created to be a template for general configuration of the device, including IOC initialization, ADEiger driver creation and database loading. This should be reused in all IOCs start-up scripts created. For other supported detectors, the specific database should be loaded. `st.cmd` serves as an example of the start-up script that includes `device.cmd`. It should also include plugin configuration from an external file. iocInit has been left to be called in it, so that one can specify whether another script should go before or after initialization.
gustavosr8
force-pushed
the
initial-poc
branch
2 times, most recently
from
d252973 to
e7ec29a
Compare
`RELEASE` file has been kept with the specification of the required EPICS dependencies. This should help to build the IOC outside our standardized container scheme. `st.cmd` has been written in way so support a local initialization script used at Sirius beamlines. This includes the commented line specifying the container image, the mounting volume and the log enabling. Mounting /ibira, the Sirius main storage.
This set has been defined in order to be a minimal functional processing pipeline. Pilatus4 already compress the frames, so we can directly save it in an HDF5, but then we need to decompress it in order to visualize. For this reason, the codec plugin is instantiated. ROI can also be used to crop the image in the viewer.
The data source is defined as being the FileWriter so we can monitor the files that is being downloaded from the MCU. By enabling the SaveFiles parameter, the files will be automatically downloaded when complete, so we don't need to use a plugin pipeline for saving the acquisition right now.
2 participants
depends on cnpem/epics-in-docker#141 being merged