- created secop_v2017-09-14.rst, based on the GoogleDocs SECoP Preliminary V2016-11-30 (rc 2) - this Document is supposed to contain the full SECoP standard - created SECoP issues - moved everything else to "outdated" (kept for reference) Change-Id: I87d69d1846fc4ed55f1c78b22fd4650d8550152b Reviewed-on: https://forge.frm2.tum.de/review/16573 Reviewed-by: Enrico Faulhaber <enrico.faulhaber@frm2.tum.de> Tested-by: JenkinsCodeReview <bjoern_pedersen@frm2.tum.de>
40 lines
1.3 KiB
ReStructuredText
40 lines
1.3 KiB
ReStructuredText
SECoP Issue 9: Module Meaning (under discussion)
|
|
================================================
|
|
|
|
meaning
|
|
-------
|
|
|
|
For the ECS an automatic detection of the main modules would be desirable.
|
|
|
|
For example a SEC Node could tell which sensor would be the closest one to
|
|
the sample, which should be registered in the ECS as the sample temperature.
|
|
|
|
For this, a module property "meaning" is proposed. This can get one of the
|
|
following values:
|
|
|
|
* sample_temperature
|
|
* magnetic_field
|
|
|
|
importance
|
|
----------
|
|
|
|
But what to do, if several modules claim to be the sample temperature?
|
|
There might be a SEC node controlling cryostat, which has a sample temperature sensor,
|
|
but another SEC node controlling an insert with a sample sensor. As the insert
|
|
is put into the cryostat, we declare the cryostat to have importance=1 and
|
|
the insert an importance=2. To resolve the ambiguity, the ECS chooses the
|
|
module with the highest importance to be labelled as the read sample temperature.
|
|
|
|
Proposal:
|
|
|
|
predefined importance:
|
|
|
|
* importance=1 for a device which can not be inserted or added to another one
|
|
* importance=2 for a device which can be inserted into an other one
|
|
|
|
Higher values are to be used when an additional device may be inserted into an insert
|
|
and the like.
|
|
|
|
We should allow importance to be a floating point number, in case later a value
|
|
between 1 and 2 has to be used.
|