Closed
Conversation
Generated with EPICS 7.0.8 as follows: makeBaseApp.pl -t ioc -u root Pilatus makeBaseApp.pl -i -t ioc -p Pilatus -u root Pilatus
Contributor
Author
|
depends on cnpem/epics-in-docker#141 being merged |
ericonr
requested changes
Mar 9, 2026
| @@ -0,0 +1,22 @@ | |||
| # EPICS IOC for Pilatus4 detector based on ADEiger | |||
Member
There was a problem hiding this comment.
This is a general issue, but we might acquire Eiger2 detectors in the future, and I don't think they should be in a separate repo, no?
Contributor
Author
There was a problem hiding this comment.
This is actually a big deal here. If we want to build Eiger2 support in the same project, then it cannot be called ad-pilatus4-epics-ioc. Do you think that this repo should be repurposed then?
`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. `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. `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.
`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 /tmp for testing purposes and /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 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.
The processing pipeline is define as a fork receiving the frame from the driver, already compressed. On one side, there is a Decompress/ROI/StdArray chain for visualisation; on the other side, the frame is directly saved into a HDF5 file.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.