cmsgemos issueshttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues2024-03-26T13:25:00+01:00https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/263Enable integration with the X2O control & monitoring libraries2024-03-26T13:25:00+01:00Laurent PetreEnable integration with the X2O control & monitoring libraries## Description
<!-- Describe the bug encountered or feature you want to add -->
An initial version of the X2O control & monitoring software libraries (and executables) has been shared. We should start integrating them within `cmsgemos`....## Description
<!-- Describe the bug encountered or feature you want to add -->
An initial version of the X2O control & monitoring software libraries (and executables) has been shared. We should start integrating them within `cmsgemos`. It however comes with multiple questions:
* Since we are in the early stages of development, quick development and iteration are desired features. A Git submodule seems ideal... except that the X2O libraries Git repository isn't as open as this one, which would lead to potential clone issues. We could envison stable releases to be provide as part of the extern libs directory (as we already include largish libraries -- `log4cplus`). Alternatively, the libraries could be provided somewhere outside of the `sysroot`: builds would exist for stable releases and alternative locations would be easy to configure.
* Each project using the libraries could include its own build. That works if common parts remain compatible (e.g. semaphores core lib). It also raises the question of the configuration files which should ideally be shared and stored in a common location.
* If `cmsgemos` provides its own build, possibly statically compiled, one needs to ensure that the right libraries are picked-up at runtime.
All in all some attempts seem required before settling on a solution.
<!-- ## Steps to reproduce -->
<!--- How one can reproduce the issue - this is very important -->
<!-- ## Possible fixes -->
<!-- If you can, link to the line of code that might be responsible for the problem -->
<!-- ## Relevant logs and/or screenshots -->
<!-- Paste any relevant logs - please use code blocks (```) to format -->
<!-- console output, logs, and code as it's very hard to read otherwise -->https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/176Save the monitorables for time-series analysis2022-06-14T15:01:40+02:00Laurent PetreSave the monitorables for time-series analysis### Summary
<!--- Summarize the new feature you would like to add concisely -->
<!--- and describe the actual behavior -->
As discussed in #76, the monitorables should be stored in a time-series database for later analysis, detector bah...### Summary
<!--- Summarize the new feature you would like to add concisely -->
<!--- and describe the actual behavior -->
As discussed in #76, the monitorables should be stored in a time-series database for later analysis, detector bahevior understanding,...
### What is the expected correct behavior?
<!--- What you should see instead -->
The monitorables are stored in the longer term for further analysis, either in a DB (preferred option) or in JSON files (fallback option).
### Possible fixes
<!--- If you can, provide a code snippet which may implement the requested feature -->
Push the monitorables into an InfluxDB database as proposed in #76. Pending confirmation that it can be used at p5.https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/170Sanitize SOAP messaging2022-08-23T18:27:44+02:00Laurent PetreSanitize SOAP messaging### Summary
<!--- Summarize the new feature you would like to add concisely -->
<!--- and describe the actual behavior -->
Faults in SOAP communication are not handled properly or at all.
### What is the expected correct behavior?
<!--...### Summary
<!--- Summarize the new feature you would like to add concisely -->
<!--- and describe the actual behavior -->
Faults in SOAP communication are not handled properly or at all.
### What is the expected correct behavior?
<!--- What you should see instead -->
Every fault in SOAP communication should be handled properly and acted upon.
<!--- ### Relevant logs and/or screenshots -->
<!--- Paste any relevant logs - please use code blocks (```) to format -->
<!--- console output, logs, and code as it's very hard to read otherwise -->
<!--- ### Possible fixes -->
<!--- If you can, provide a code snippet which may implement the requested feature -->https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/155Simplify the GEM web applications classes2021-02-05T13:53:10+01:00Laurent PetreSimplify the GEM web applications classes### Summary
<!--- Summarize the new feature you would like to add concisely -->
<!--- and describe the actual behavior -->
In order to more easily implement the shadow DOM idea being discussed in #151, some refactoring and simplificatio...### Summary
<!--- Summarize the new feature you would like to add concisely -->
<!--- and describe the actual behavior -->
In order to more easily implement the shadow DOM idea being discussed in #151, some refactoring and simplification of the web interface rendering must be achieved.
### What is the expected correct behavior?
<!--- What you should see instead -->
* `GEMWebApplication` only contains common code for all GEM applications.
* A child class, `GEMFSMWebApplication` is created to implement the web FSM features.
<!--- ### Relevant logs and/or screenshots -->
<!--- Paste any relevant logs - please use code blocks (```) to format -->
<!--- console output, logs, and code as it's very hard to read otherwise -->
<!--- ### Possible fixes -->
<!--- If you can, provide a code snippet which may implement the requested feature -->Laurent PetreLaurent Petrehttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/62Generate artifacts for the back-end boards2022-06-14T15:31:06+02:00Laurent PetreGenerate artifacts for the back-end boards### Summary
<!--- Summarize the new feature you would like to add concisely -->
<!--- and describe the actual behavior -->
The new (and old) software architecture requires artifacts to be pushed to the back-end board to ensure correct o...### Summary
<!--- Summarize the new feature you would like to add concisely -->
<!--- and describe the actual behavior -->
The new (and old) software architecture requires artifacts to be pushed to the back-end board to ensure correct operations. These artifacts include (not exclusive list):
* The firmware bitstreams
* The software RPC modules
* The address table (as long as it useful on the back-end board)
Depends on #61, although the work on the RPC modules could be started before.
### What is the expected correct behavior?
<!--- What you should see instead -->
The artifacts are copied to a well-known location during the installation process so that high-level software can use them to configure the back-end board.
The well-know location prefix is likely to be `${CMAKE_INSTALL_FULL_DATAROOTDIR}`, i.e. `/opt/cmsgemos/share`. The precise suffix should be discussed here and must be able to cope with the different GEM stations and back-end boards (let's call the combinations, flavors).
<!--- ### Relevant logs and/or screenshots -->
<!--- Paste any relevant logs - please use code blocks (```) to format -->
<!--- console output, logs, and code as it's very hard to read otherwise -->
<!--- ### Possible fixes -->
<!--- If you can, provide a code snippet which may implement the requested feature -->Brendan RegneryBrendan Regneryhttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/47Add a RPC method to scan the TTC stream sampling phase2022-06-14T15:31:05+02:00Laurent PetreAdd a RPC method to scan the TTC stream sampling phase### Summary
<!--- Summarize the new feature you would like to add concisely -->
<!--- and describe the actual behavior -->
The new back-end firmware to be released integrates a new, more versatile and more robust clocking scheme. This n...### Summary
<!--- Summarize the new feature you would like to add concisely -->
<!--- and describe the actual behavior -->
The new back-end firmware to be released integrates a new, more versatile and more robust clocking scheme. This new scheme allows to shift the TTC data stream sampling phase in order to center it in the center of the validity window. The concept is similar to the GBT RX phase scan.
The exact firmware implementation details are to be released along with example Python script.
### What is the expected correct behavior?
<!--- What you should see instead -->
A TTC data stream phase scan RPC method should exist.
<!--- ### Relevant logs and/or screenshots -->
<!--- Paste any relevant logs - please use code blocks (```) to format -->
<!--- console output, logs, and code as it's very hard to read otherwise -->
<!--- ### Possible fixes -->
<!--- If you can, provide a code snippet which may implement the requested feature -->https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/265Ensure that the VFAT external reset is applied for long enough2024-03-26T19:16:52+01:00Laurent PetreEnsure that the VFAT external reset is applied for long enough## Description
A few days after merging a feature that manually applies the external VFAT reset on ME0 via the LpGBT (see commit https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/commit/079073d76849700dd4ce4dca640b0d483c7a7073), we...## Description
A few days after merging a feature that manually applies the external VFAT reset on ME0 via the LpGBT (see commit https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/commit/079073d76849700dd4ce4dca640b0d483c7a7073), we learned that the new ME0 VFAT plugin cards have an RC circuit with a time constants of 10 milliseconds installed on the reset line. We should ensure that the reset pulse is long enough to properly assert and de-assert the external reset -- 50 milliseconds seems like a good baseline.https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/264Provide a base image for the CTP7 SD card2024-03-26T16:35:07+01:00Laurent PetreProvide a base image for the CTP7 SD card## Description
<!-- Describe the bug encountered or feature you want to add -->
Lately new SD cards for the CTP7 have been prepared by mirroring one from another working CPT7. This is not convenient and may not be possible in all situat...## Description
<!-- Describe the bug encountered or feature you want to add -->
Lately new SD cards for the CTP7 have been prepared by mirroring one from another working CPT7. This is not convenient and may not be possible in all situations. Additionally, it provides no documentation to reproduce the system. :confused:
Instead, we should provide a base image for the CTP7 SD card, updated whenever needed. That does not prevent - but simplifies - the writing of a proper documentation. In some way, it supersedes !167.
<!-- ## Steps to reproduce -->
<!--- How one can reproduce the issue - this is very important -->
<!-- ## Possible fixes -->
<!-- If you can, link to the line of code that might be responsible for the problem -->
<!-- ## Relevant logs and/or screenshots -->
<!-- Paste any relevant logs - please use code blocks (```) to format -->
<!-- console output, logs, and code as it's very hard to read otherwise -->https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/262Allow to take S-curves in ZCC mode2024-03-26T12:36:24+01:00Laurent PetreAllow to take S-curves in ZCC mode## Description
<!-- Describe the bug encountered or feature you want to add -->
While performing R&D on the GEM timing, it became clear that a better understanding of the ZCC mode and ZCC threshold was required. Amongst others, the S-cu...## Description
<!-- Describe the bug encountered or feature you want to add -->
While performing R&D on the GEM timing, it became clear that a better understanding of the ZCC mode and ZCC threshold was required. Amongst others, the S-curves are always a precious tool. If one can always prepare configuration files to enable select mode or another, allowing the user to configure the comparator mode (and its threshold) via the calibration suite Web UI is a pleasant feature for the operator.
In general, we should probably revise how the detector can be configured via the calibration suite in order to reduce duplication. We would want "sections" to be available in all or some of the scans: common (e.g. thresholds, masking); timing (S-curves, calibration pulse scan); or scan-specific (e.g. the number of triggers of the GBT RX phase scan).
<!-- ## Steps to reproduce -->
<!--- How one can reproduce the issue - this is very important -->
<!-- ## Possible fixes -->
<!-- If you can, link to the line of code that might be responsible for the problem -->
<!-- ## Relevant logs and/or screenshots -->
<!-- Paste any relevant logs - please use code blocks (```) to format -->
<!-- console output, logs, and code as it's very hard to read otherwise -->https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/261Disable the fake multi-BX readout during calibration runs2024-03-26T12:30:59+01:00Laurent PetreDisable the fake multi-BX readout during calibration runs## Description
<!-- Describe the bug encountered or feature you want to add -->
When enabling the (newish) fake multi-BX readout via the AMC configuration file - as it should be -, the tracking & non-tracking data calibration runs can -...## Description
<!-- Describe the bug encountered or feature you want to add -->
When enabling the (newish) fake multi-BX readout via the AMC configuration file - as it should be -, the tracking & non-tracking data calibration runs can - and are - screwed up. The Online Software must make sure the feature is disabled whenever relevant and left untouched if the run/scan mode does not require any specific configuration.
More generally, the configuration sources and their precedence should be revisited to deal more cleanly with such features.
<!-- ## Steps to reproduce -->
<!--- How one can reproduce the issue - this is very important -->
<!-- ## Possible fixes -->
<!-- If you can, link to the line of code that might be responsible for the problem -->
<!-- ## Relevant logs and/or screenshots -->
<!-- Paste any relevant logs - please use code blocks (```) to format -->
<!-- console output, logs, and code as it's very hard to read otherwise -->https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/260Monitor the VFAT S-bit rate2024-03-26T12:27:23+01:00Laurent PetreMonitor the VFAT S-bit rate## Description
Request received from the (ME0 stack) ops team: monitor the VFAT S-bit/trigger rate and expose it in the monitoring suite Web UI. The metric(s) could be the sum of the VFAT S-bit rates or the per-VFAT S-bit rates. I'm lea...## Description
Request received from the (ME0 stack) ops team: monitor the VFAT S-bit/trigger rate and expose it in the monitoring suite Web UI. The metric(s) could be the sum of the VFAT S-bit rates or the per-VFAT S-bit rates. I'm leaning towards the second option since it provides more information (and since we are already monitoring a few per-VFAT parameters).https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/259Scan routine for detecting broken S-bit lines2023-10-31T15:48:21+01:00Camilla GalloniScan routine for detecting broken S-bit lines## Description
<!-- Describe the bug encountered or feature you want to add -->
Watching by eye the S-bit scans result to see which VFATs might have broken S-bit lines is time-consuming and error-prone. A dedicated routine would be desi...## Description
<!-- Describe the bug encountered or feature you want to add -->
Watching by eye the S-bit scans result to see which VFATs might have broken S-bit lines is time-consuming and error-prone. A dedicated routine would be desired to replace the script currently available to check the broken S-bit lines for a given oh.
Note: at the beginning of the routine, the masked S-bit lines from the OH config files should be unmasked.
<!-- ## Steps to reproduce -->
<!--- How one can reproduce the issue - this is very important -->
<!-- ## Possible fixes -->
<!-- If you can, link to the line of code that might be responsible for the problem -->
The implementation can be staged in 2 parts.
1) the creation of a new scan type and interface on the calibration suite
2) the implementation of the routine as an rpc function, paying attention to the possible transaction failures due to instability and related masking.
<!-- ## Relevant logs and/or screenshots -->
<!-- Paste any relevant logs - please use code blocks (```) to format -->
<!-- console output, logs, and code as it's very hard to read otherwise -->https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/258Allow quick measurement of the DAC currents and voltages2023-07-20T18:08:41+02:00Laurent PetreAllow quick measurement of the DAC currents and voltages## Description
<!-- Describe the bug encountered or feature you want to add -->
Recently, doubts about the DAC currents and voltages have recently been raised from time to time. Among others, during the "empty S-curves vs threshold inve...## Description
<!-- Describe the bug encountered or feature you want to add -->
Recently, doubts about the DAC currents and voltages have recently been raised from time to time. Among others, during the "empty S-curves vs threshold investigations" and during the "empty S-curves and S-bit rate scan investigations". At the moment, one is forced to measure the DAC current and voltages by hand or to retake a complete DAC scan. This is long, error-prone, and/or useless.
<!-- ## Steps to reproduce -->
<!--- How one can reproduce the issue - this is very important -->
## Possible fixes
<!-- If you can, link to the line of code that might be responsible for the problem -->
Develop a new tool, possibly a Python script, ideally a new feature in the `AMCManger`. The feature is relatively tricky to implement in the current design of the software since calibration constants are exclusively used and available in the analysis suite. It might be easier after the `cmsgemos`-`cmsgemos-analysis` merge. Additionally, the `AMCManager` version only makes sense when taking into account the most recent ideas about an Automator and the consequential Online Software restructuration.
<!-- ## Relevant logs and/or screenshots -->
<!-- Paste any relevant logs - please use code blocks (```) to format -->
<!-- console output, logs, and code as it's very hard to read otherwise -->https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/257Implement OptoHybrid FPGA programming re-tries2023-02-27T17:39:14+01:00Laurent PetreImplement OptoHybrid FPGA programming re-tries## Description
<!-- Describe the bug encountered or feature you want to add -->
The title says it all...
On GE1/1, it has been seen that GBT link can lose lock while programming the OptoHybrid FPGA. If that happens on GBT0, the SCA als...## Description
<!-- Describe the bug encountered or feature you want to add -->
The title says it all...
On GE1/1, it has been seen that GBT link can lose lock while programming the OptoHybrid FPGA. If that happens on GBT0, the SCA also gets unready and the FPGA may or may not be programmed. If that happens on GBT1 or GBT2, the corresponding VFAT are masked. This is a random and transient issue.
<!--- ## Steps to reproduce -->
<!--- How one can reproduce the issue - this is very important -->
## Possible fixes
<!-- If you can, link to the line of code that might be responsible for the problem -->
Whenever a GBT link loses lock during the OptoHybrid FPGA programming, the corresponding GBTx must be re-configured from scratch (to ensure its state) and the software blaster routine must apply all subsequent action (e.g. reset the SCA and reprogram the FPGA on the OH for which GBT0 lost lock).
<!-- ## Relevant logs and/or screenshots -->
<!-- Paste any relevant logs - please use code blocks (```) to format -->
<!-- console output, logs, and code as it's very hard to read otherwise -->Laurent PetreLaurent Petrehttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/253Incorrect derivation of the day field in the local run number generation2023-02-05T20:06:47+01:00Laurent PetreIncorrect derivation of the day field in the local run number generation## Description
<!-- Describe the bug encountered or feature you want to add -->
It should have been addressed in https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/merge_requests/298, but it wasn't...
The interpretation of the `tm_...## Description
<!-- Describe the bug encountered or feature you want to add -->
It should have been addressed in https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/merge_requests/298, but it wasn't...
The interpretation of the `tm_yday` field of the `struct tm` is incorrect: the field starts at `0` on the 1st of January and as such should be used as-is in the local run number creation formula. This is required in order to be able to easily deduce the run timestamp from the local run number itself.
## Possible fixes
<!-- If you can, link to the line of code that might be responsible for the problem -->
Replace:
``` c++
localRunNumber += ((now.tm_year - 100) * 365 + now.tm_yday - 1) * 100'000; // Epoch on 1 January 2000 00:00:00 UTC
```
by:
``` c++
localRunNumber += ((now.tm_year - 100) * 365 + now.tm_yday) * 100'000; // Epoch on 1 January 2000 00:00:00 UTC
```
in [the `gem::supervisor::GEMSupervisor::getNewLocalRunNumber()` function](https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/blob/ced5760d15e64a93757b2607243a86a64d4de1d7/gemsupervisor/src/GEMSupervisor.cpp#L887).Laurent PetreLaurent Petrehttps://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/251GEMSupervisor stuck during state transitions2022-11-22T19:57:19+01:00Laurent PetreGEMSupervisor stuck during state transitions## Description
<!-- Describe the bug encountered or feature you want to add -->
There are a few conditions in which the `GEMSupervisor` can get stuck during state transitions. It can be due to (1) an undefined global state or (2) unknow...## Description
<!-- Describe the bug encountered or feature you want to add -->
There are a few conditions in which the `GEMSupervisor` can get stuck during state transitions. It can be due to (1) an undefined global state or (2) unknown reasons such as in http://cmsonline.cern.ch/cms-elog/1169110.
While condition (1) should not happen in regular operations, condition (2) can. This should be understood and fixed.
## Steps to reproduce
<!--- How one can reproduce the issue - this is very important -->
For (1), it is enough to put the system in an undefined state (e.g. triggering state transitions directly in the `AMCManager`) before triggering state transitions from the `GEMSupervisor`. For (2), it is a rare and difficult situation to reproduce as stated in the e-log. So far, I haven't been able to reproduce it.
## Possible fixes
<!-- If you can, link to the line of code that might be responsible for the problem -->
Re-write the `GEMSupervisor` state transitions to make them robust.https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/250Check the BC0 lock status in the configuration sequence2022-10-19T00:32:42+02:00Laurent PetreCheck the BC0 lock status in the configuration sequence## Description
<!-- Describe the bug encountered or feature you want to add -->
During the TCDS LPM reload tests, it was noticed that the TTC stream from the AMC13 to the CTP7 can be corrupted. It is however not warned until starting (a...## Description
<!-- Describe the bug encountered or feature you want to add -->
During the TCDS LPM reload tests, it was noticed that the TTC stream from the AMC13 to the CTP7 can be corrupted. It is however not warned until starting (and blocking) a run. We should check the TTC stream validity status during the configuration, once the clock and TTC streams are declared stable. In particular, the BC0 lock is a good indicator.
<!-- ## Steps to reproduce -->
<!--- How one can reproduce the issue - this is very important -->
## Possible fixes
<!-- If you can, link to the line of code that might be responsible for the problem -->
Check the BC0 lock after the clocks reset and TTC configuration. Would the BC0 be unlocked or unstable, the FSM must go to the Error state.
<!-- ## Relevant logs and/or screenshots -->
<!-- Paste any relevant logs - please use code blocks (```) to format -->
<!-- console output, logs, and code as it's very hard to read otherwise -->https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/249Configure the in-OptoHybrid S-bit monitor at the end of the configuration seq...2022-10-19T00:29:26+02:00Laurent PetreConfigure the in-OptoHybrid S-bit monitor at the end of the configuration sequence## Description
<!-- Describe the bug encountered or feature you want to add -->
In order to monitor the S-bit clusters with invalid addresses (see https://gitlab.cern.ch/emu/0xbefe/-/issues/50), a new S-bit monitor mode of operation as ...## Description
<!-- Describe the bug encountered or feature you want to add -->
In order to monitor the S-bit clusters with invalid addresses (see https://gitlab.cern.ch/emu/0xbefe/-/issues/50), a new S-bit monitor mode of operation as been discussed to trigger on this specific case (see https://gitlab.cern.ch/emu/0xbefe/-/issues/60). The new feature is actually already implemented in the in-OptoHybrid firmware deployed at p5 (see https://gitlab.cern.ch/emu/0xbefe/-/merge_requests/119).
We should make use of this new feature to detect invalid clusters generated within the OptoHybrid, if any.
<!-- ## Steps to reproduce -->
<!--- How one can reproduce the issue - this is very important -->
## Possible fixes
<!-- If you can, link to the line of code that might be responsible for the problem -->
After OptoHybrid configuration, configure the S-bit monitor to trigger on invalid addresses. Checking it from time-to-time should be easy.
<!-- ## Relevant logs and/or screenshots -->
<!-- Paste any relevant logs - please use code blocks (```) to format -->
<!-- console output, logs, and code as it's very hard to read otherwise -->https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/247Implement a cold-reset routine for the X2O2024-03-26T13:25:00+01:00Laurent PetreImplement a cold-reset routine for the X2O## Description
<!-- Describe the bug encountered or feature you want to add -->
After the implementation and merge of !291, the X2O board will be minimally supported. In order words, data taking should be possible once the hardware will...## Description
<!-- Describe the bug encountered or feature you want to add -->
After the implementation and merge of !291, the X2O board will be minimally supported. In order words, data taking should be possible once the hardware will be configured (e.g. synthesizers, optics, firmware,...) by an external means. No facility will be provided in `cmsgemos` for this initial configuration.
Instead, a cold-reset procedure, similar to the one for the CTP7 should be implemented. It consists in powering up the TX lasers, configuring the clock synthesizers, loading the firmware(s), and establishing the Chip2Chip communication,... Like in the case of the CTP7, calling external tools should be avoided as much as possible. It has two purposes: (1) facilitate the deployment and (2) provide good error-checking and then error-reporting to the user. Python code _can_ be called, if the library exists only in that form, via `pybind11`. Calling a rogue script is discouraged.
<!-- ## Steps to reproduce -->
<!--- How one can reproduce the issue - this is very important -->
<!-- ## Possible fixes -->
<!-- If you can, link to the line of code that might be responsible for the problem -->
<!-- ## Relevant logs and/or screenshots -->
<!-- Paste any relevant logs - please use code blocks (```) to format -->
<!-- console output, logs, and code as it's very hard to read otherwise -->https://gitlab.cern.ch/cmsgemonline/gem-daq/cmsgemos/-/issues/244Specify which applications should be supervised in the XML configuration file2022-06-14T19:22:40+02:00Laurent PetreSpecify which applications should be supervised in the XML configuration file## Description
<!-- Describe the bug encountered or feature you want to add -->
Following up on #243, XML attributes could be used to specify which applications are to be supervised. More specifically, the attribute would be used as an ...## Description
<!-- Describe the bug encountered or feature you want to add -->
Following up on #243, XML attributes could be used to specify which applications are to be supervised. More specifically, the attribute would be used as an override of the default. It could be interesting in cases such as QC7 where the `BoardManager` application is common between different `AMCManager` and `GEMSupervisor`, but should be automatically touched by the supervisor.
<!-- ## Steps to reproduce -->
<!--- How one can reproduce the issue - this is very important -->
## Possible fixes
<!-- If you can, link to the line of code that might be responsible for the problem -->
XML attributes to the xDAQ applications exist and are used to override whether an application is to be supervised and, optionally, with which priority. As in #243, using a `cmsgemos`-specific XML namespace is a good idea if possible.
<!-- ## Relevant logs and/or screenshots -->
<!-- Paste any relevant logs - please use code blocks (```) to format -->
<!-- console output, logs, and code as it's very hard to read otherwise -->