... | ... | @@ -37,6 +37,36 @@ Pending actions as of 02/10/2020: |
|
|
* Actions 13, 19 , 23, 27, 29 & 31 closed during August 2020 BSC Meeting. Action 30 merged into #28
|
|
|
* Actions 36 and 32 closed during October BSC
|
|
|
|
|
|
Summary of the meeting (04/12/2020)
|
|
|
-----------------------------------
|
|
|
|
|
|
**Attendees** : Jordi Bodera, Veijo Honkimaki, Jens Meyer, Armando Solé, Manfred Burghammer, Wout De Nolf, Matias Guijarro, Andy Gotz, Thomas Roth and Jean-Michel Chaize
|
|
|
|
|
|
Jean-Claude Biasci, Harald Reichert and Jean Susini were excused (they were called for a post-council debrief director's meeting).
|
|
|
|
|
|
It was decided to start the meeting with Jean-Michel's presentation (action 37). Jean-Michel explained how the Insertion Device Energy Scan can be done by moving the insertion device and synchronously move the crystals in the monochromator. The movements to be done can be draw in a graph and to implement this solution it is possible to create "control points" every 100ms when the speed of movement can change. Jean-Michel showed how all of this could work and a planning with timescales involving IDM (ASD), ACU, BCU and ID26. The idea is then to have a custom development for ID26, test it and then generalise this in BLISS.
|
|
|
|
|
|
Jean-Michel confirmed that all the teams involved are available for the work presented in the planning.
|
|
|
|
|
|
Veijo added that the formula controling the speeds may be different for other undulators and asked whether in the long run a hardware solution wouldn't it be better (with ICEpaps). Jean-Michel replied that for the hardware solution more resources from the ID group are required and confirmed that it would be better controlling by hardware rather than software, however he highlighted the fact that the ID group does not have the resources to do this.
|
|
|
|
|
|
Jean-Michel confirmed that brief tests with hardware for IDJOG were performed and that depending on the undulator (we have different units with different characteristics) mechanics have different resolutions for speed.
|
|
|
|
|
|
Jens asked about the limits for low and high speeds and Jean-Michel again replied that this depends of the ID device controller and that he can't change these. Veijo added that it would be useful to know highest and lowest possible speed. Jean-Michel explained that we have different versions of the controllers depending on the ID. We use a privative embedded system that can take care of security and offer us a simple interface. That has the advantage that we cannot create trouble for ourselves by mistake but at the same time impose us some restrictions.
|
|
|
|
|
|
Armando asked then about having a constant speed at the undulator and a variable one at the monochromator, which could be easier and Jens explained that we already do this. Veijo added that Spectroscopy BLs have a valid reason to ask for this project as the old system is not satisfactory. Andy added that O. Mathon (BM23) has asked for this for a long time. Armando was invited to check with Blanka Detlefts and report back to the Bliss Steering Committee if required.
|
|
|
|
|
|
It was then decided to talk jointly about actions 34 and 39 during Matias' presentation. Matias explained that v1.7 of BLISS will be released by 14th December. Matias explained that while they try very hard to ensure there are no compatibility issues with the new versions, a bugfix introduced an error that ended up affecting ID10.
|
|
|
|
|
|
Matias expressed his wish for new releases to be beta-tested, but without further time for testing there are inevitably some issues discovered at a later stage. Wout said that integration tests at the BLs is the solution to this kind of problem, however that takes time.
|
|
|
|
|
|
Jens explained that as BLs want to add new and the latest features, these have been tested more sparsely and therefore the BLISS version becomes less stable. As BLISS becomes more mature and less new features are added all the time the software will be more stable.
|
|
|
|
|
|
Manfred expressed his requirement for being able to have two versions of BLISS installed and being able to switch back to a previous version if a new version installed does not work (so, kind of allowig an easy rollback for BLs). Jens explained that BLISS installations include two environments, so this is technically possible, however due to the significant number of patches and bugfixes rolled out in rapid succession this is not easy to do at the moment. Manfred then said that a clear procedure for testing and deploying BLISS would be useful, including how to rollback if required.
|
|
|
|
|
|
Andy finished the meeting by saying that it would be useful if the strategy for the next proposal run would be known. That could allow the BCU to know in advance what features of BLISS would be used and focus on these ones. It was agreed that Jordi will raise this question with the DoRs.
|
|
|
|
|
|
|
|
|
|
|
|
Minutes from previous meetings:
|
|
|
* [17th BSC 28/10/2020](https://gitlab.esrf.fr/bliss/bliss/-/wikis/17th-BLISS-Steering-Committee-end-October)
|
... | ... | |