cmsgemos merge requestshttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/merge_requests2022-06-15T14:10:34+02:00https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/merge_requests/36Layout tree loader2022-06-15T14:10:34+02:00Louis MoureauxLayout tree loader## Description
<!--- Describe your changes in detail -->
This MR adds a loader class that supports the YAML-based format discussed in #72. The format is briefly described in the documentation. Significant effort has been put towards pro...## Description
<!--- Describe your changes in detail -->
This MR adds a loader class that supports the YAML-based format discussed in #72. The format is briefly described in the documentation. Significant effort has been put towards providing helpful error messages, and as a consequence about 2/3 of the code is doing error reporting. This can be further improved once the addressing system is ready, and in the future with yaml-cpp >= 0.5.2 (CC8).
Based on !32 (even if not strictly required).
The limitation that prevents YAML anchors from spanning multiple files can be lifted later by inserting a thin layer between the yaml-cpp SAX interface and its document builder.
## Related Issue
<!--- This project only accepts pull requests related to open issues -->
<!--- If suggesting a new feature or change, please discuss it in an issue first -->
<!--- If fixing a bug, there should be an issue describing it with steps to reproduce -->
<!--- If addressing multiple issues, comment on their relation if needed -->
<!--- Please link issues accordgin to the automation rules: -->
<!--- https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically -->
Closes #72.
## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->
Bundled unit tests.
## Screenshots
```
node of type b: ERROR: "number" must be a positive integer
Expected a number >= 0, got -1
```
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
- [x] My code follows the code style of this project.
- [x] My change requires a change to the documentation.
- [x] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [x] I have added tests to cover my changes.
- [x] All new and existing tests passed.Laurent PetreCamilla GalloniLaurent Petrehttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/merge_requests/32Add layout tree base classes2022-06-15T14:10:33+02:00Louis MoureauxAdd layout tree base classes## Description
<!--- Describe your changes in detail -->
This adds the classes discussed in #43
I tried to provide some design considerations in the commit messages.
## Related Issue
<!--- This project only accepts pull requests rela...## Description
<!--- Describe your changes in detail -->
This adds the classes discussed in #43
I tried to provide some design considerations in the commit messages.
## Related Issue
<!--- This project only accepts pull requests related to open issues -->
<!--- If suggesting a new feature or change, please discuss it in an issue first -->
<!--- If fixing a bug, there should be an issue describing it with steps to reproduce -->
<!--- If addressing multiple issues, comment on their relation if needed -->
<!--- Please link issues accordgin to the automation rules: -->
<!--- https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically -->
Closes #43
## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->
Bundled tests and visual inspection of the documentation.
<!--- ## Screenshots (if appropriate): -->
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [x] Breaking change (fix or feature that would cause existing functionality to change)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
- [x] My code follows the code style of this project.
- [x] My change requires a change to the documentation.
- [x] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [x] I have added tests to cover my changes.
- [x] All new and existing tests passed.Mykhailo DalchenkoLaurent PetreCamilla GalloniMykhailo Dalchenkohttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/merge_requests/31Install missing packages in CI2022-06-15T14:10:32+02:00Laurent PetreInstall missing packages in CI## Description
<!--- Describe your changes in detail -->
Python 3 was not installed in the CI. In the previous version of the packages, the CI passed because it was implicitly installed. This is no longer the case and requires an explic...## Description
<!--- Describe your changes in detail -->
Python 3 was not installed in the CI. In the previous version of the packages, the CI passed because it was implicitly installed. This is no longer the case and requires an explicit Python 3 installation.
In addition, a version version of the MR lead to discover #82. The behavior in newer version of CMake (version 3.17) slightly changed and exposed an issue in `FindxDAQ.cmake` and `FindCACTUS.cmake` Fixing this issue as well. More information is available in the commit message.
## Related Issue
<!--- This project only accepts pull requests related to open issues -->
<!--- If suggesting a new feature or change, please discuss it in an issue first -->
<!--- If fixing a bug, there should be an issue describing it with steps to reproduce -->
<!--- If addressing multiple issues, comment on their relation if needed -->
<!--- Please link issues according to the automation rules: -->
<!--- https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically -->
Fixes #80 and #82.
## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->
Waiting for the CI to fail, or, hopefully, pass...
<!--- ## Screenshots (if appropriate): -->
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
- [x] My code follows the code style of this project.
- [x] My change requires a change to the documentation.
- [x] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [ ] I have added tests to cover my changes.
- [x] All new and existing tests passed.Mykhailo DalchenkoLouis MoureauxCamilla GalloniMykhailo Dalchenkohttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/merge_requests/30Fix Error caused by Monitor-Supervisor conflict in XDAQ2022-06-15T14:10:32+02:00Dylan Oliver TeagueFix Error caused by Monitor-Supervisor conflict in XDAQ## Description
When trying to run the Supervisor code in XDAQ when the monitor is added, the supervisor code crashes. The fix is as simple as having the supervisor code ignore gem monitor calls
## Related Issue
More details of this bug ...## Description
When trying to run the Supervisor code in XDAQ when the monitor is added, the supervisor code crashes. The fix is as simple as having the supervisor code ignore gem monitor calls
## Related Issue
More details of this bug can be found in #53
## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->
The XDAQ code was started and the initialize button was pressed in the Supervisor widget and the error messages don't show up anymore and allows one to go to initialize the supervisor
<!--- ## Screenshots (if appropriate): -->
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
- [x] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.Laurent PetreCamilla GalloniLaurent Petrehttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/merge_requests/28Layout tree iterator tools2022-06-15T14:10:31+02:00Louis MoureauxLayout tree iterator tools## Description
<!--- Describe your changes in detail -->
This MR adds tools to facilitate traversal of the layout tree, as described in #42. Two new syntaxes are introduced:
* `parent.recursive_children()` returns a range that comprise...## Description
<!--- Describe your changes in detail -->
This MR adds tools to facilitate traversal of the layout tree, as described in #42. Two new syntaxes are introduced:
* `parent.recursive_children()` returns a range that comprises all descendants of a node/ I preferred `recursive_children` to not have functions called `children` and `descendants`, which I found confusing.
* `range | filter_nodes<type>` (where `range` is either `children()` or `recursive_children()`) returns a new range with only nodes of the given `type`, returned as references rather than pointers. The pipe syntax is taken from the `boost::adaptors` library, but I didn't follow its naming convention (would have been `filtered_nodes`).
<!---WIP because I had a new idea, will add to #42.-->
## Related Issue
<!--- This project only accepts pull requests related to open issues -->
<!--- If suggesting a new feature or change, please discuss it in an issue first -->
<!--- If fixing a bug, there should be an issue describing it with steps to reproduce -->
<!--- If addressing multiple issues, comment on their relation if needed -->
<!--- Please link issues accordgin to the automation rules: -->
<!--- https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically -->
Closes #42.
## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->
Bundled unit tests.
<!--- ## Screenshots (if appropriate): -->
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
- [x] My code follows the code style of this project.
- [x] My change requires a change to the documentation.
- [x] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [x] I have added tests to cover my changes.
- [x] All new and existing tests passed.Laurent PetreCamilla GalloniLaurent Petrehttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/merge_requests/27Fix known issues discovered with compiler warnings2022-06-15T14:10:31+02:00Louis MoureauxFix known issues discovered with compiler warnings## Description
<!--- Describe your changes in detail -->
Fixes #58, #57, #20 and #19. Few different cases:
* The involved code paths were probably crashing -> throw instead
* There was a clear intent that the code failed to achieve -> ...## Description
<!--- Describe your changes in detail -->
Fixes #58, #57, #20 and #19. Few different cases:
* The involved code paths were probably crashing -> throw instead
* There was a clear intent that the code failed to achieve -> fix the code
## Related Issue
<!--- This project only accepts pull requests related to open issues -->
<!--- If suggesting a new feature or change, please discuss it in an issue first -->
<!--- If fixing a bug, there should be an issue describing it with steps to reproduce -->
<!--- If addressing multiple issues, comment on their relation if needed -->
<!--- Please link issues accordgin to the automation rules: -->
<!--- https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically -->
Closes #58, #57, #20 and #19.
## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->
Code compiles.
<!--- ## Screenshots (if appropriate): -->
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
- [x] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [ ] I have added tests to cover my changes.
- [x] All new and existing tests passed.Mykhailo DalchenkoLaurent PetreCamilla GalloniMykhailo Dalchenkohttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/merge_requests/24Use STATUS for cmsgemos_add_module messages (was NOTICE)2022-06-15T14:10:31+02:00Louis MoureauxUse STATUS for cmsgemos_add_module messages (was NOTICE)## Description
<!--- Describe your changes in detail -->
Fix issue #60, using `STATUS` instead of `NOTICE`.
## Related Issue
<!--- This project only accepts pull requests related to open issues -->
<!--- If suggesting a new feature or c...## Description
<!--- Describe your changes in detail -->
Fix issue #60, using `STATUS` instead of `NOTICE`.
## Related Issue
<!--- This project only accepts pull requests related to open issues -->
<!--- If suggesting a new feature or change, please discuss it in an issue first -->
<!--- If fixing a bug, there should be an issue describing it with steps to reproduce -->
<!--- If addressing multiple issues, comment on their relation if needed -->
<!--- Please link issues accordgin to the automation rules: -->
<!--- https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically -->
#60
## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->
Changed a random variable in `ccmake`.
<!--- ## Screenshots (if appropriate): -->
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
- [x] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [ ] I have added tests to cover my changes.
- [x] All new and existing tests passed.Mykhailo DalchenkoLaurent PetreCamilla GalloniMykhailo Dalchenkohttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/merge_requests/23Layout tree base classes2022-06-15T14:10:30+02:00Louis MoureauxLayout tree base classes## Description
<!--- Describe your changes in detail -->
This MR adds the three base classes that will be used to define the hardware layout tree, along with the corresponding tests and documentation.
## Related Issue
<!--- This projec...## Description
<!--- Describe your changes in detail -->
This MR adds the three base classes that will be used to define the hardware layout tree, along with the corresponding tests and documentation.
## Related Issue
<!--- This project only accepts pull requests related to open issues -->
<!--- If suggesting a new feature or change, please discuss it in an issue first -->
<!--- If fixing a bug, there should be an issue describing it with steps to reproduce -->
<!--- If addressing multiple issues, comment on their relation if needed -->
<!--- Please link issues accordgin to the automation rules: -->
<!--- https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically -->
#40
## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->
Built-in unit tests and inspection of the generated documentation. Style checked against the common style definition.
<!--- ## Screenshots (if appropriate): -->
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
- [x] My code follows the code style of this project.
- [x] My change requires a change to the documentation.
- [x] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [x] I have added tests to cover my changes.
- [x] All new and existing tests passed.Mykhailo DalchenkoLaurent PetreCamilla GalloniMykhailo Dalchenkohttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/merge_requests/12Add a simple CI2022-06-15T14:10:29+02:00Louis MoureauxAdd a simple CI## Description
<!--- Describe your changes in detail -->
This adds a simple CI that's able to:
1. Compile the software, including the RPC modules
2. Run the tests
3. Check the formatting style
4. Build the Doxygen documentation and sav...## Description
<!--- Describe your changes in detail -->
This adds a simple CI that's able to:
1. Compile the software, including the RPC modules
2. Run the tests
3. Check the formatting style
4. Build the Doxygen documentation and save it as an artifact
The only difference with respect to issue #24 is that no custom Docker image is used. Given how slow `yum` tends to be, this would certainly be an optimization; however the current code runs in less than 10 minutes, which is a good start.
This MR is certainly a step forward towards a working Docker image, because the installations step have been worked out. A custom image will raise additional questions: for instance, I think that we should run the tests on a system with the a minimal number of development packages (basically only `cmake`).
## Related Issue
<!--- This project only accepts pull requests related to open issues -->
<!--- If suggesting a new feature or change, please discuss it in an issue first -->
<!--- If fixing a bug, there should be an issue describing it with steps to reproduce -->
<!--- If addressing multiple issues, comment on their relation if needed -->
<!--- Please link issues accordgin to the automation rules: -->
<!--- https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically -->
This was primarily motivated by Doxygen concerns in !7, but also requested in #24. The custom image requested in #24 can be created later from the `setup` commands found in the Gitlab CI configuration.
## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->
Ran 111 pipelines in my own private repo.
<!--- ## Screenshots (if appropriate): -->
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
- [x] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.Mykhailo DalchenkoLaurent PetreMykhailo Dalchenkohttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/merge_requests/272Fix package versions in the CI Dockerfile2022-06-10T15:09:10+02:00Laurent PetreFix package versions in the CI Dockerfile## Description
<!-- Describe your changes in detail -->
This MR fixes a long-standing issue where the package version constraints were not taken into account by `yum`. Since the versions are checked by the build system, we just let `yum...## Description
<!-- Describe your changes in detail -->
This MR fixes a long-standing issue where the package version constraints were not taken into account by `yum`. Since the versions are checked by the build system, we just let `yum` install the most recent version.
Additionally, implement an host independent xDAQ configuration for simple tests on machines other than `gem904daq04` (currently powered off).
## Related Issue
<!-- This project only accepts pull requests related to open issues -->
<!-- If suggesting a new feature or change, please discuss it in an issue first -->
<!-- If fixing a bug, there should be an issue describing it with steps to reproduce -->
<!-- If addressing multiple issues, comment on their relation if needed -->
<!-- Please link issues accordgin to the automation rules: -->
<!-- https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically -->
## How Has This Been Tested?
<!-- Please describe in detail how you tested your changes. -->
<!-- Include details of your testing environment, and the tests you ran to -->
<!-- see how your change affects other areas of the code, etc. -->
The CI should pass.
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [x] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
## Checklist:
<!-- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!-- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
- [x] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [ ] I have added tests to cover my changes.
- [x] All new and existing tests passed.Laurent PetreLaurent Petrehttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/merge_requests/273Fix data taking with the CTP72022-06-10T15:06:07+02:00Laurent PetreFix data taking with the CTP7## Description
<!-- Describe your changes in detail -->
After the merge of !268, it was noticed that data taking was impossible with the CTP7. Indeed, the TTC B-channel (i.e. commands) was disabled after the AMC register reset. This MR ...## Description
<!-- Describe your changes in detail -->
After the merge of !268, it was noticed that data taking was impossible with the CTP7. Indeed, the TTC B-channel (i.e. commands) was disabled after the AMC register reset. This MR aims at restoring the correct behavior in case the TTC generator is not enabled.
It was also noticed that the TTC phase monitoring target value was reset. Preserve this value during the AMC reset.
Finally, this MR includes a fix for #216. It was deemed to be the right moment to do so since the "TTC MMCM reset" is only aligning the TTC clock phase. Would a real TTC MMCM be implemented in the future, the ordering would already be correct and debugging, if needed, could take place at that moment.
## Related Issue
<!-- This project only accepts pull requests related to open issues -->
<!-- If suggesting a new feature or change, please discuss it in an issue first -->
<!-- If fixing a bug, there should be an issue describing it with steps to reproduce -->
<!-- If addressing multiple issues, comment on their relation if needed -->
<!-- Please link issues accordgin to the automation rules: -->
<!-- https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically -->
Fixes #216.
## How Has This Been Tested?
<!-- Please describe in detail how you tested your changes. -->
<!-- Include details of your testing environment, and the tests you ran to -->
<!-- see how your change affects other areas of the code, etc. -->
Trivial change, but cannot be tested on hardware. :confused:
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
## Checklist:
<!-- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!-- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
- [x] My code follows the code style of this project.
- [x] My change requires a change to the documentation.
- [x] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [ ] I have added tests to cover my changes.
- [x] All new and existing tests passed.Laurent PetreLaurent Petrehttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/merge_requests/268Implement a generic BoardManager application2022-06-09T17:25:31+02:00Laurent PetreImplement a generic BoardManager application## Description
<!-- Describe your changes in detail -->
This MR implements a new generic `BoardManager` application to control the basic board functionalities: FPGA reloads, synthesizers, MGTs, etc... It is defined to control the multi-...## Description
<!-- Describe your changes in detail -->
This MR implements a new generic `BoardManager` application to control the basic board functionalities: FPGA reloads, synthesizers, MGTs, etc... It is defined to control the multi-AMC setups in which the AMC are mostly independent except for anything that relates to the board.
Please note that the CTP7 workflow should _not_ have changed due to the absence of the `0xBEFE` system registers for this back-end board.
## Related Issue
<!-- This project only accepts pull requests related to open issues -->
<!-- If suggesting a new feature or change, please discuss it in an issue first -->
<!-- If fixing a bug, there should be an issue describing it with steps to reproduce -->
<!-- If addressing multiple issues, comment on their relation if needed -->
<!-- Please link issues accordgin to the automation rules: -->
<!-- https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically -->
## How Has This Been Tested?
<!-- Please describe in detail how you tested your changes. -->
<!-- Include details of your testing environment, and the tests you ran to -->
<!-- see how your change affects other areas of the code, etc. -->
Taking data on the GE1/1 integration setup in b904 with a CTP7 is still working smoothly.
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [x] Breaking change (fix or feature that would cause existing functionality to change)
## Checklist:
<!-- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!-- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
- [x] My code follows the code style of this project.
- [x] My change requires a change to the documentation.
- [x] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [ ] I have added tests to cover my changes.
- [x] All new and existing tests passed.Laurent PetreLaurent Petrehttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/merge_requests/271Do not scan the HYST DAC by default2022-06-09T16:58:45+02:00Laurent PetreDo not scan the HYST DAC by default## Description
<!-- Describe your changes in detail -->
This MR fixes a recently discovered error in the VFAT configuration. The `HYST` DAC must not be scanned but set depending on the `THR_ARM_DAC`.
* Do not select the `HYST` by defau...## Description
<!-- Describe your changes in detail -->
This MR fixes a recently discovered error in the VFAT configuration. The `HYST` DAC must not be scanned but set depending on the `THR_ARM_DAC`.
* Do not select the `HYST` by default
* Set the `CFG_HYST` to twice the value of `THR_ARM_DAC` by default, re-organizing the configuration parameters by topic at the same time
* Add support for `xdata::Boolean` in the `ScanInfo` bag, fixing a xDAQ bug...
## Related Issue
<!-- This project only accepts pull requests related to open issues -->
<!-- If suggesting a new feature or change, please discuss it in an issue first -->
<!-- If fixing a bug, there should be an issue describing it with steps to reproduce -->
<!-- If addressing multiple issues, comment on their relation if needed -->
<!-- Please link issues accordgin to the automation rules: -->
<!-- https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically -->
## How Has This Been Tested?
<!-- Please describe in detail how you tested your changes. -->
<!-- Include details of your testing environment, and the tests you ran to -->
<!-- see how your change affects other areas of the code, etc. -->
Compiles, scan parameters are passed correctly from the web interface to the xDAQ applications.
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [x] Breaking change (fix or feature that would cause existing functionality to change)
## Checklist:
<!-- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!-- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
- [x] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [ ] I have added tests to cover my changes.
- [x] All new and existing tests passed.Laurent PetreLaurent Petrehttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/merge_requests/270Add configuration options for the for S-bit rate scan (comparator mode, thres...2022-06-09T15:10:56+02:00Camilla GalloniAdd configuration options for the for S-bit rate scan (comparator mode, threshold to be scanned, one channel scan)## Description
<!-- Describe your changes in detail -->
This MR aims at introducing the possibility to choose in the calibration interface the threshold type to scan during an S-bit scan. Also, the comparator mode should be selectable.
...## Description
<!-- Describe your changes in detail -->
This MR aims at introducing the possibility to choose in the calibration interface the threshold type to scan during an S-bit scan. Also, the comparator mode should be selectable.
## Related Issue
<!-- This project only accepts pull requests related to open issues -->
<!-- If suggesting a new feature or change, please discuss it in an issue first -->
<!-- If fixing a bug, there should be an issue describing it with steps to reproduce -->
<!-- If addressing multiple issues, comment on their relation if needed -->
<!-- Please link issues accordgin to the automation rules: -->
<!-- https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically -->
Fixes #215
## How Has This Been Tested?
<!-- Please describe in detail how you tested your changes. -->
<!-- Include details of your testing environment, and the tests you ran to -->
<!-- see how your change affects other areas of the code, etc. -->
<!-- ## Screenshots (if appropriate): -->
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
## Checklist:
<!-- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!-- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
- [x] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [ ] I have added tests to cover my changes.
- [x] All new and existing tests passed.Camilla GalloniCamilla Gallonihttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/merge_requests/202Implement ME0 compatibility2022-05-30T14:21:27+02:00Antonello PellecchiaImplement ME0 compatibility## Description
This MR finalizes the basic support of ME0. The SCA and OH FPGA actions are removed and the lpGBT can be configured. This should allow seamlessly taking data with ME0.
## Related Issue
<!-- This project only accepts pull...## Description
This MR finalizes the basic support of ME0. The SCA and OH FPGA actions are removed and the lpGBT can be configured. This should allow seamlessly taking data with ME0.
## Related Issue
<!-- This project only accepts pull requests related to open issues -->
<!-- If suggesting a new feature or change, please discuss it in an issue first -->
<!-- If fixing a bug, there should be an issue describing it with steps to reproduce -->
<!-- If addressing multiple issues, comment on their relation if needed -->
<!-- Please link issues accordgin to the automation rules: -->
<!-- https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically -->
## How Has This Been Tested?
The GE1/1 and CTP7 code still works on the GE1/1 integration setup. Was tested with the CVP-13 and a ME0 narrow GEB (behavior didn't change since then).
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
## Checklist:
<!-- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!-- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
- [x] My code follows the code style of this project.
- [x] My change requires a change to the documentation.
- [x] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [ ] I have added tests to cover my changes.
- [x] All new and existing tests passed.Laurent PetreAntonello PellecchiaLaurent Petrehttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/merge_requests/267Update the register-based memhub to the last specifications2022-05-17T16:19:51+02:00Laurent PetreUpdate the register-based memhub to the last specifications## Description
<!-- Describe your changes in detail -->
One commit whose message should well describe the MR:
> More specifically, we follow the new system where the magic register is
independent of the address table (i.e. always the l...## Description
<!-- Describe your changes in detail -->
One commit whose message should well describe the MR:
> More specifically, we follow the new system where the magic register is
independent of the address table (i.e. always the last register in the
GEM block address space) and filled with a status code describing the
outcome of the last transaction.
## Related Issue
<!-- This project only accepts pull requests related to open issues -->
<!-- If suggesting a new feature or change, please discuss it in an issue first -->
<!-- If fixing a bug, there should be an issue describing it with steps to reproduce -->
<!-- If addressing multiple issues, comment on their relation if needed -->
<!-- Please link issues accordgin to the automation rules: -->
<!-- https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically -->
## How Has This Been Tested?
<!-- Please describe in detail how you tested your changes. -->
<!-- Include details of your testing environment, and the tests you ran to -->
<!-- see how your change affects other areas of the code, etc. -->
Code compiles, tests pending (firmware and hardware availability).
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [x] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [x] Breaking change (fix or feature that would cause existing functionality to change)
## Checklist:
<!-- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!-- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
- [x] My code follows the code style of this project.
- [x] My change requires a change to the documentation.
- [x] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [ ] I have added tests to cover my changes.
- [x] All new and existing tests passed.Laurent PetreLaurent Petrehttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/merge_requests/263Implement a RAW file reader2022-05-16T12:54:23+02:00Laurent PetreImplement a RAW file reader## Description
<!-- Describe your changes in detail -->
From the commit message:
> The reader class reads one event at a time from a RAW file. The reader
is able to automatically detect if the file is uncompressed or ZSTD
compressed. I...## Description
<!-- Describe your changes in detail -->
From the commit message:
> The reader class reads one event at a time from a RAW file. The reader
is able to automatically detect if the file is uncompressed or ZSTD
compressed. In the later case, it is decompressed on the fly.
## Related Issue
<!-- This project only accepts pull requests related to open issues -->
<!-- If suggesting a new feature or change, please discuss it in an issue first -->
<!-- If fixing a bug, there should be an issue describing it with steps to reproduce -->
<!-- If addressing multiple issues, comment on their relation if needed -->
<!-- Please link issues accordgin to the automation rules: -->
<!-- https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically -->
One step of many in #200.
## How Has This Been Tested?
<!-- Please describe in detail how you tested your changes. -->
<!-- Include details of your testing environment, and the tests you ran to -->
<!-- see how your change affects other areas of the code, etc. -->
Test files can be read and unpacked by a modified version of !261. The end-of-file conditions is properly handled.
<!-- ## Screenshots (if appropriate): -->
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
## Checklist:
<!-- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!-- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
- [x] My code follows the code style of this project.
- [x] My change requires a change to the documentation.
- [x] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [ ] I have added tests to cover my changes.
- [x] All new and existing tests passed.Laurent PetreLaurent Petrehttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/merge_requests/229Usability gemrpc updates2022-05-11T18:32:22+02:00Laurent PetreUsability gemrpc updates## Description
<!-- Describe your changes in detail -->
This MR aims at providing two options for `gemrpc` targeting usability:
1. A configurable port (required for the test beam and the multi-GEM block setups)
2. A possibility not to d...## Description
<!-- Describe your changes in detail -->
This MR aims at providing two options for `gemrpc` targeting usability:
1. A configurable port (required for the test beam and the multi-GEM block setups)
2. A possibility not to daemonize the `gemrpc` server (should allow for easier debugging on the CVP13-based setups)
The current behavior is the default one so no change is expected if the options are not used.
## Related Issue
<!-- This project only accepts pull requests related to open issues -->
<!-- If suggesting a new feature or change, please discuss it in an issue first -->
<!-- If fixing a bug, there should be an issue describing it with steps to reproduce -->
<!-- If addressing multiple issues, comment on their relation if needed -->
<!-- Please link issues accordgin to the automation rules: -->
<!-- https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically -->
## How Has This Been Tested?
<!-- Please describe in detail how you tested your changes. -->
<!-- Include details of your testing environment, and the tests you ran to -->
<!-- see how your change affects other areas of the code, etc. -->
All features work as expected on the GE1/1 integration setup. The default behavior is consistent with the current behavior.
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
## Checklist:
<!-- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!-- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
- [x] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [ ] I have added tests to cover my changes.
- [x] All new and existing tests passed.Laurent PetreLaurent Petrehttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/merge_requests/266Add a cyclic mode to the latency scan2022-05-11T16:59:03+02:00Laurent PetreAdd a cyclic mode to the latency scan## Description
<!-- Describe your changes in detail -->
This MR aims at implementing a cyclic latency scan mode. It should allow better timing studies (e.g. during test beams); it should also give more flexibility for configuring the la...## Description
<!-- Describe your changes in detail -->
This MR aims at implementing a cyclic latency scan mode. It should allow better timing studies (e.g. during test beams); it should also give more flexibility for configuring the latency scans at p5.
Also includes a fix on the GEM supervisor scan point update timer. It is now stopped at Stop and cancel the scan. Previously, the scan was continuing in the background at Stop.
## Related Issue
<!-- This project only accepts pull requests related to open issues -->
<!-- If suggesting a new feature or change, please discuss it in an issue first -->
<!-- If fixing a bug, there should be an issue describing it with steps to reproduce -->
<!-- If addressing multiple issues, comment on their relation if needed -->
<!-- Please link issues accordgin to the automation rules: -->
<!-- https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically -->
Closes #211
## How Has This Been Tested?
<!-- Please describe in detail how you tested your changes. -->
<!-- Include details of your testing environment, and the tests you ran to -->
<!-- see how your change affects other areas of the code, etc. -->
All modes (particles vs calibration pulses and cyclic vs non-cyclic) work seamlessly on the GE1/1 integration setup in b904.
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [x] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
## Checklist:
<!-- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!-- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
- [x] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [ ] I have added tests to cover my changes.
- [x] All new and existing tests passed.Laurent PetreLaurent Petrehttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/merge_requests/265Allow setting a common VFAT threshold for physics runs2022-05-11T15:52:35+02:00Camilla GalloniAllow setting a common VFAT threshold for physics runs## Description
<!-- Describe your changes in detail -->
This merge request aims at being able to set a threshold to be applied to all VFATs in a physics run.
A small change in the default definition of the threshold source type was nee...## Description
<!-- Describe your changes in detail -->
This merge request aims at being able to set a threshold to be applied to all VFATs in a physics run.
A small change in the default definition of the threshold source type was needed to simplify the implementation.
Was tested for normal physics runs, physics run with the desired threshold, and also s-curves.
## Related Issue
<!-- This project only accepts pull requests related to open issues -->
<!-- If suggesting a new feature or change, please discuss it in an issue first -->
<!-- If fixing a bug, there should be an issue describing it with steps to reproduce -->
<!-- If addressing multiple issues, comment on their relation if needed -->
<!-- Please link issues accordgin to the automation rules: -->
<!-- https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically -->
Closes #210
## How Has This Been Tested?
<!-- Please describe in detail how you tested your changes. -->
<!-- Include details of your testing environment, and the tests you ran to -->
<!-- see how your change affects other areas of the code, etc. -->
<!-- ## Screenshots (if appropriate): -->
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
## Checklist:
<!-- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!-- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
- [x] My code follows the code style of this project.
- [x] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
- [ ] I have added tests to cover my changes.
- [x] All new and existing tests passed.Camilla GalloniCamilla Galloni