Skip to content

Commit 94a6748

Browse files
markus-zollikermarkus-zolliker
committed
add minutes of the last 3 vidconf
+ update pending tasks
1 parent 6a39282 commit 94a6748

File tree

4 files changed

+391
-3
lines changed

4 files changed

+391
-3
lines changed

‎protocol/minutes/2024-12-03_vidconf.rst‎

Lines changed: 116 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,116 @@
1+
meeting 2024-12-03 (via ZOOM)
2+
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
3+
4+
.. sidebar:: participants
5+
6+
* Alexander Zaft
7+
* Enrico Faulhaber
8+
* Markus Zolliker
9+
* Bastian Klemke
10+
* Niklas Eckström
11+
12+
13+
.. contents:: Agenda
14+
:local:
15+
:depth: 3
16+
17+
18+
approval of the minutes 2024-11-05
19+
==================================
20+
21+
Minutes approved. previous minutes are still to be uploaded.
22+
23+
24+
RFC process: UDP Autodetection
25+
==============================
26+
27+
Alex reminds all to have a look at the github issue.
28+
29+
30+
Measurable interface class
31+
==========================
32+
33+
Some of the proposed names (see minutes of last meeting) are discussed.
34+
Discussion is postponed.
35+
36+
Some of the suggestions are repeated here:
37+
38+
**`Collector`**
39+
- Markus favourite
40+
41+
**`Measurable`**
42+
- Current name
43+
44+
**`Acquisition`**
45+
- Markus favourite
46+
47+
Here are a few ChatGPT generated names:
48+
49+
**`Observable`**
50+
- **Why**: The device represents a value that can be observed over time. This works well if you expect the device to allow polling or subscribing to value changes. It suggests that obtaining the value requires waiting for it to be available.
51+
52+
**`Lazy`**
53+
- **Why**: Suggests that the value is not immediately available and might require some time to "lazily" load or fetch. It implies that there's a delay in accessing the value.
54+
55+
**`StaleReadable`**
56+
- **Why**: Implies that the value can be read, but there's a delay (or potential for staleness) in obtaining the most up-to-date value.
57+
58+
**`DelayedReadable`**
59+
- **Why**: This directly conveys that while the device's value is readable, there is some delay involved in accessing or obtaining that value.
60+
61+
**`Fetchable`**
62+
- **Why**: Indicates that the value can be fetched, but the process involves some waiting or delay, aligning with the idea of fetching data over time.
63+
64+
**`LazyReadable`**
65+
- **Why**: A combination of "lazy" and "readable," this name communicates that reading the value will take time, suggesting it's not instantaneous.
66+
67+
**`TimedReadable`**
68+
- **Why**: This suggests that there is a timing aspect to reading the value, similar to how you have "Drivable" to indicate actions that take time.
69+
70+
**`SlowReadable`**
71+
- **Why**: Indicates that reading the value takes more time than usual, directly addressing the delay without being overly technical.
72+
73+
**`Refreshable`**
74+
- **Why**: The device provides a value that can be read, and the value can be refreshed (or updated) by triggering a new measurement. This implies the need for explicit action to get a fresh value.
75+
76+
**`Measured`**
77+
- **Why**: This is simple and to the point: the value is the result of a measurement, and the interface implies that the value is only updated when a new measurement is explicitly triggered.
78+
79+
80+
The `preset` parameter should be renamed to `goal`. Further discussion with other colleagues is adviced.
81+
82+
83+
Finalize Matrix Datainfo
84+
========================
85+
86+
Bastian asked for clarification on the format string specifier.
87+
Alexander explained its analogy to the datainfo used e.g. in numpy.
88+
89+
https://github.com/SampleEnvironment/SECoP/blob/measurable/protocol/secop_specification_draft_wip.rst#binary-matrix-matrix
90+
https://github.com/SampleEnvironment/SECoP/blob/abd1c12b88617c93edee1e0629d29c02599988c7/protocol/specification/datainfo.rst#binary-matrix-matrix
91+
92+
Essentially agreed, but all members not participating in this meeting are welcome to check.
93+
If there are no objections until next meeting, this is expected to be accepted.
94+
95+
96+
Finalize check message and checkable property
97+
=============================================
98+
99+
check message:
100+
https://github.com/SampleEnvironment/SECoP/blob/4fc717017a83254155060e30e64ab33ca30a920a/protocol/specification/buildingblocks.rst#check-value
101+
102+
Markus found a typo (3rd bullet point of the remarks).
103+
104+
checkable property:
105+
https://github.com/SampleEnvironment/SECoP/blob/4fc717017a83254155060e30e64ab33ca30a920a/protocol/specification/buildingblocks.rst#optional-accessible-properties
106+
107+
Essentially accepted. If there aro no objection until next meeting,
108+
this is expected to be accepted.
109+
110+
111+
next meeting
112+
============
113+
114+
A preliminary discussion found the weeks 13-17/20-24 january
115+
acceptable.
116+
Markus will send a poll around.

‎protocol/minutes/2025-02-12_vidconf.rst‎

Lines changed: 163 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,163 @@
1+
meeting 2025-02-12(ZOOM)
2+
@@@@@@@@@@@@@@@@@@@@@@@@@
3+
4+
.. sidebar:: participants
5+
6+
* Markus Zolliker
7+
* Alexander Zaft
8+
* Bastian Klemke
9+
* Klaus Kiefer
10+
* Enrico Faulhaber
11+
* Niklas Eckström
12+
* Peter Braun
13+
14+
.. contents:: Agenda
15+
:local:
16+
:depth: 3
17+
18+
19+
1) approval of the minutes 2024-11-05
20+
=====================================
21+
approved.
22+
23+
24+
2) RFC-005: UDP Autodetection
25+
=============================
26+
27+
Markus presents his current data-collection procerss which collects data from all sec-nodes (in a network) and
28+
stores them in a common database. This is especially useful for collecting historic data.
29+
It also requires mangling of the equipment id.
30+
31+
Klaus asks for a practical test. Markus replies that it is in use as documented in RFC-005. klaus seems happy with this.
32+
33+
Conclusion: general acceptance.
34+
35+
36+
Help for GitHub Pull requests:
37+
38+
https://github.com/SampleEnvironment/SECoP
39+
40+
- click on "Pull requests" (item 3 on 2nd line in header)
41+
- click on the selected one: "add RFC for UDP discovery"
42+
- click on Commits (on top of conversation, 2nd item)
43+
- either:
44+
- to see the changes in raw source: click on "add RFC for UDP discovery"
45+
- to see the rendered version: click on <> on the right of the topmost commit and then browse to the file to be seen
46+
47+
48+
3) 'Measurable'
49+
===============
50+
51+
see also https://github.com/SampleEnvironment/SECoP/issues/24
52+
53+
Discussion started at the Proposition: discard the condition: "at least one channel MUST have a preset."
54+
55+
Markus presents his use case of some ultrasonic measurement device, which doesn't take that long.
56+
Peter shows an example of an atomic mass spectrometer, where had to leave the preset as there
57+
is no sensible parametrisation connected to a preset value.
58+
59+
In a longer discussion several points are discussed:
60+
61+
- Klaus dislikes the name 'preset' and prefers 'goal' or smth. similiar
62+
- Enno acknowledges the fact that there may be use case where there is no sensible preset
63+
- Enno propose to change the wording from 'MUST' to 'SHOULD' to cover those cases.
64+
- Enno also states that always having the preset eases implementation
65+
- above presented use cases could also use a 0..100% value with a preset of 100%.
66+
This would allow gui's to show the progress.
67+
- Georg states that for showing progress bars in a gui an extra parameter of the controller seems better.
68+
- Markus discusses the difference between measurement (channels) representing an increasing value (e.g. time, counts,...)
69+
from values where the statistical significance improves, i.e. the value itself roughly stays the same, but gets more precise.
70+
- Enno thinks that instead of joining a controller with the only channel, the controller may get a 'representative' value,
71+
which in all cases could be useful. wording seems important here.
72+
- further discussion about integration into ECS (e.g. nicos, bluesky): what is needed?
73+
it seems, a mapping is needed from the SECoP module name to the named preset names used by ECS's.
74+
(e.g. 't' as the preset for measurement time)
75+
- wordings!
76+
- agreement on discarding the condition: "use_preset must be there when preset is" (default when not present: use_preset=True)
77+
- renaming Measurable -> Acquisition (Controller keeps name Controller), MeasurableChannel -> AcquisitionChannel
78+
- Georg proposes the Controller to have a 'representative' value (and maybe a 'preset')
79+
- a Controller is required to have a 'go' command.
80+
- instead of defining a merged (controller+Channel) class, we may also list both in the 'interface_classes' list.
81+
- Peter states that this is not a good idea, as the ECS should treat a module like the first known interface from interface_class.
82+
- Enno agrees and proposes to use the 'features' list, though this means that corresponding features need to be defined.
83+
- Markus proposes to rename 'preset' to 'target'. Enno has no objection. Georg doesn't like it. further discussion.
84+
- agreement on renaming 'preset' to 'goal'.
85+
86+
Georg will rework the RFC.
87+
88+
89+
4) finalize matrix datainfo
90+
===========================
91+
92+
https://github.com/SampleEnvironment/SECoP/blob/abd1c12b88617c93edee1e0629d29c02599988c7/protocol/specification/datainfo.rst#binary-matrix-matrix
93+
94+
Since there are no objections, this is be accepted.
95+
96+
97+
5) finalize check message and checkable property
98+
================================================
99+
100+
if there are no objections, this should be accepted
101+
102+
check message:
103+
104+
https://github.com/SampleEnvironment/SECoP/blob/4fc717017a83254155060e30e64ab33ca30a920a/protocol/specification/buildingblocks.rst#check-value
105+
106+
checkable property:
107+
108+
https://github.com/SampleEnvironment/SECoP/blob/4fc717017a83254155060e30e64ab33ca30a920a/protocol/specification/buildingblocks.rst#optional-accessible-properties
109+
110+
Both are accepted as-is.
111+
112+
113+
6) final reports of SECoP@HMC
114+
=============================
115+
116+
Klaus asks anyone to check the deliverables/reports Peter prepared.
117+
118+
- https://nubes.helmholtz-berlin.de/apps/files/files/627996505?dir=/HMC_SECoP%40HMC/Steering_Board/Reports/Final_Report_2025
119+
- https://nubes.helmholtz-berlin.de/apps/files/files/625971700?dir=/HMC_SECoP%40HMC/Steering_Board/Reports/Deliverable_D1
120+
- https://nubes.helmholtz-berlin.de/apps/files/files/619391848?dir=/HMC_SECoP%40HMC/Steering_Board/Reports/Deliverable_D3.2
121+
122+
123+
7) Website
124+
==========
125+
126+
Klaus asks for a search function on the web docu.
127+
Alex proposes the one on the top right. It seems not very comfortable.
128+
Markus proposes to use google....
129+
130+
Shall/OctoPy are missing at the website as well.
131+
132+
Peter has problems to access the website repo (access expired) and asks if it can be moved to github.
133+
No objection, but no excitement either.
134+
135+
136+
8) Access levels
137+
================
138+
139+
Klaus is working on a gashandling rack, consisting of several mass flow controllers (as individual sec-nodes)
140+
and then combined into a 'management' sec-node.
141+
There seem to be difficulties with 'locking' some modules from external access.
142+
143+
Markus proposes to use different port numbers for distinct access levels.
144+
145+
After some discussion it becomes clear that a paragraph in the spec mentioning the
146+
problem of different 'access' levels and showing exemplary ways to tackle this problem.
147+
148+
149+
9) outlook
150+
==========
151+
152+
There are some project application deadlines approaching. (Oscars, automated beamline,...)
153+
Klaus proposes a few project ideas.
154+
155+
The discussion did not trigger any storms of enthusiasm.
156+
157+
Klaus states that the NIAG will probably not do anything if we don't keep pushing.
158+
159+
160+
10) Date of next video meeting
161+
=============================
162+
163+
5(th) of March (Ash Wednesday), 09:00 via zoom.

‎protocol/minutes/2025-03-05_vidconf.rst‎

Lines changed: 111 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,111 @@
1+
meeting 2025-03-05 (ZOOM)
2+
@@@@@@@@@@@@@@@@@@@@@@@@@
3+
4+
.. sidebar:: participants
5+
6+
* Markus Zolliker
7+
* Alexander Zaft
8+
* Klaus Kiefer
9+
* Enrico Faulhaber
10+
* Niklas Eckström
11+
* Georg Brandl
12+
13+
.. contents:: Agenda
14+
:local:
15+
:depth: 3
16+
17+
18+
1) approval of the minutes 2025-02-12
19+
=====================================
20+
21+
approved.
22+
23+
2) meeting software
24+
===================
25+
As reported in the Invitation:
26+
27+
.. cite::
28+
PSI is trying to save money by reducing the licence costs, e.g. for Zoom.
29+
So I might not be able to further host zoom meetings - if I can not justify that there is no
30+
viable alterative.
31+
Recommended alternative: Microsoft Teams. Objections?
32+
Possible alternative: somebody living at an institute with a less restrictive software policy
33+
hosts the meetings.
34+
Other alternatives?
35+
36+
- Teams is rejected
37+
- Markus will check in at PSI, alternatively someone else will provide a Zoom Meeting
38+
39+
3) Acquisition proposal
40+
=======================
41+
42+
From the invitation:
43+
Georg has moved the proposal form the old SECoP issue to an RFC, taking into account the
44+
things we discussed last time.
45+
46+
What is still lacking or at least not fully satisfying to me, is how the ECS can determine
47+
exactly which modules belong to an acquisition. It is specified that they must belong to
48+
the same group. But is is not specified that there might be no other modules in the group
49+
and more important, the case where an channel belongs to several acquisitions, which would
50+
be possible. In addition, we have the question how to assign the channels to the preset names
51+
in NICOS. My proposition to solve above issues is to add a new module property 'acquisition_channels',
52+
with a JSON object with a name as keys and module names as values.
53+
54+
Example: acquisition_channels = {"t": "timer", "cnt": "counter"}
55+
56+
The names for the keys may be choosen freely, but we might also have some predefined names,
57+
mainly "t" for a timer. Later we might add more predefined items if it makes sense.
58+
59+
In case of an Acquisition class a reference to its own module must be included.
60+
61+
Enno likes the proposed acquisition_channels property.
62+
Klaus proposes a general solution similar to controlledBy: controls, which list all modules which are controlled, but lacks a distinct use case.
63+
He dislikes to maybe have to change some acquisition specifc solution later to a more general one.
64+
Georg ponders whether this can be expressed by the systems already.
65+
Enno points out that the systems are very specific, i.e. adding a channel to an acquisition would mean, a new system needs to be specified.
66+
Additionally, he would prefer waiting for uses before generalizing.
67+
Markus wonders about a different name, which is more generic.
68+
Klaus proposes to use the proposed syntax and, if needed, rename the property later.
69+
70+
Since the proposed property already groups together, the group requirement can be removed.
71+
72+
Markus is going to write a pull request.
73+
74+
75+
4) other pull requests pending
76+
==============================
77+
78+
The following pull requests are open
79+
80+
- clarify RFC life cycle
81+
- add websocket RFC
82+
83+
Klaus asks whether the port used in the discovery RFC is known to be regularly used by other programs and how to prevent abuse.
84+
The general information on port numbers don't list any registered or unofficial uses for the port.
85+
Markus points out that due to the message structure a valid message can be distinguished from an invalid one.
86+
Essentially there is no way to prevent accidential/abusive use of this port for/from other stuff.
87+
Since broadcasts are typically restricted to instrument nets, there seems to be no big issue.
88+
89+
90+
RFC lifecycle
91+
~~~~~~~~~~~~~
92+
93+
Georg ponders if the a new pull request should be open for a longer time to have a specific place to discuss it,
94+
or if it would be beneficial to merge quickly and discuss afterwards and make changes, if needed, later on.
95+
Markus and Klaus propose to keep it like it is now.
96+
All agreed to merge pull request #25 ( https://github.com/SampleEnvironment/SECoP/pull/25 ).
97+
98+
Websocket RFC
99+
~~~~~~~~~~~~~
100+
101+
As it is an optional suggestion, it is fine like it is but will be left open for more discussion.
102+
103+
5) AOB
104+
======
105+
106+
Klaus will follow up on calls/grants (OSCARS,HMC,LEAPS) when he is no longer sick.
107+
108+
6) date of next meeting
109+
=======================
110+
111+
07.05.2025 9:00 (zoom)

0 commit comments

Comments
 (0)