in order to prevent modifying parameters without automatically
trigger updates, all datatypes must be immutable.
TupleOf and ArrayOf: change from list to tuple
StructOf: use ImmutableDict
most existing code should work properly, the only thing to consider are
equality comparisons with lists, which will result to False all the time
the changes in secop_psi/ppms.py (using tuples instead of lists for status values)
are not really necessary, but lead to less confusing code
Change-Id: I181f412b5cd55af296b2e5120af82449beb03f54
Reviewed-on: https://forge.frm2.tum.de/review/c/sine2020/secop/playground/+/22972
Tested-by: JenkinsCodeReview <bjoern_pedersen@frm2.tum.de>
Reviewed-by: Enrico Faulhaber <enrico.faulhaber@frm2.tum.de>
Reviewed-by: Markus Zolliker <markus.zolliker@psi.ch>
A proxy module is a module with a known structure, but
accessed over a SECoP connection.
For the configuration, a Frappy module class has to be given.
The proxy class is created from this, but does not inherit from it.
However, the class of the returned object will be subclass of the
SECoP base classes (Readable, Drivable etc.).
A possible extension might be, that instead of the Frappy class,
the JSON module description can be given, as a separate file
or directly in the config file.
Or we might offer a tool to convert the JSON description to
a python class.
Change-Id: I9212d9f3fe82ec56dfc08611d0e1efc0b0112271
Reviewed-on: https://forge.frm2.tum.de/review/c/sine2020/secop/playground/+/22386
Tested-by: JenkinsCodeReview <bjoern_pedersen@frm2.tum.de>
Reviewed-by: Markus Zolliker <markus.zolliker@psi.ch>
writable parameters with a configured value should call write_<param>
on initialization.
+ introduced 'initwrite' parameter property for more fine control over this
+ minor improvements in metaclass.py, param.py, commandhandler.py
+ rearranged test_modules.py
Change-Id: I2eec45da40947a73d9c180f0f146eb62efbda2b3
Reviewed-on: https://forge.frm2.tum.de/review/c/sine2020/secop/playground/+/21986
Tested-by: JenkinsCodeReview <bjoern_pedersen@frm2.tum.de>
Reviewed-by: Markus Zolliker <markus.zolliker@psi.ch>
A command handler can be used to deal with parameters which have a common
command for querying and writing to the hardware. Support for parsing
and formatting commands is included.
Change-Id: I79a1b6c9daf3af3be2e1875875ced41ec1a1829d
Reviewed-on: https://forge.frm2.tum.de/review/c/sine2020/secop/playground/+/21946
Tested-by: JenkinsCodeReview <bjoern_pedersen@frm2.tum.de>
Reviewed-by: Markus Zolliker <markus.zolliker@psi.ch>
according to the newset SECoP syntax
accept both namings on the client side
Change-Id: I23abfa163d189044d997b715c912359158c16e42
Reviewed-on: https://forge.frm2.tum.de/review/c/sine2020/secop/playground/+/21478
Tested-by: JenkinsCodeReview <bjoern_pedersen@frm2.tum.de>
Reviewed-by: Enrico Faulhaber <enrico.faulhaber@frm2.tum.de>
this change is triggered by the fact, that assigining a unit
in the config file did no longer work.
this change has several implications:
1) secop.properties must not import secop.datatypes:
- as ValueType can not be imported, the default behaviour with
'mandatory' and 'default' arguments was slightly changed
- instead of checking for DataType when exporting, a try/except
was used
2) the datatype of datatype properties is sometimes not yet defined.
a stub is used in this cases instead, which is later replaced by
the proper datatype. The number of stubs may be reduced, but this
should be done in a later change, as the diff will be much less
readable.
3) in config files, datatype properties can be changed like parameter
properties. HasProperties.setProperties/checkProperties/getProperties
are overridden for this.
the config editor seems still to work, an issue (probably py3) had
to be fixed there
Change-Id: I1efddf51f2c760510e913dbcaa099e8a89c9cab5
Reviewed-on: https://forge.frm2.tum.de/review/c/sine2020/secop/playground/+/21399
Tested-by: JenkinsCodeReview <bjoern_pedersen@frm2.tum.de>
Reviewed-by: Enrico Faulhaber <enrico.faulhaber@frm2.tum.de>
Reviewed-by: Markus Zolliker <markus.zolliker@psi.ch>
this test seems not to work always properly, as it uses threads.
anyway, the test depends on the inner functionality of the poller,
which might be replaced soon
Change-Id: I64f54046bfd1a8c70f8a9f20d518ab2f9967c33b
Reviewed-on: https://forge.frm2.tum.de/review/20921
Tested-by: JenkinsCodeReview <bjoern_pedersen@frm2.tum.de>
Reviewed-by: Enrico Faulhaber <enrico.faulhaber@frm2.tum.de>
Reviewed-by: Markus Zolliker <markus.zolliker@psi.ch>
+ DataType validators are shifted to __call__
+ as_json is moved to export_datatape()
+ new HasProperties Base Mixin for Modules/DataTypes
+ accessibles can be accessed via iterator of a module
+ properties are properly 'derived' and checked, are set with .setPropertyValue
remember: parameters only have properties, so use getPropertyValue()
Change-Id: Iae0273f971aacb00fe6bf05e6a4d24a6d1be881a
Reviewed-on: https://forge.frm2.tum.de/review/20635
Tested-by: JenkinsCodeReview <bjoern_pedersen@frm2.tum.de>
Reviewed-by: Markus Zolliker <markus.zolliker@psi.ch>
for easier distinction:
- camelCase or singleword: framework method
- snake_case: driver method
(driver) parameters are lowercase, single word framework variables may
have to start with uppercase letters to distinguish...
Change-Id: I76536b6390324625b242c4f190553014c2ca61d6
Reviewed-on: https://forge.frm2.tum.de/review/20295
Tested-by: JenkinsCodeReview <bjoern_pedersen@frm2.tum.de>
Reviewed-by: Enrico Faulhaber <enrico.faulhaber@frm2.tum.de>
Reviewed-by: Markus Zolliker <markus.zolliker@psi.ch>
- using threading.Events instead of Queue
- started_callback has no more argument
- introduced timeout for starting modules
Change-Id: I5a8b59cf552918cf7e61ae93cda907f7b0d97836
Reviewed-on: https://forge.frm2.tum.de/review/20281
Tested-by: JenkinsCodeReview <bjoern_pedersen@frm2.tum.de>
Reviewed-by: Enrico Faulhaber <enrico.faulhaber@frm2.tum.de>
except when explicitely mentioned with reorder=True
improved test_modules for unique accessibles, as this
was related with Accessible.ctr
Change-Id: I61877de9300bb0297c88a6c44bb265c634937856
Reviewed-on: https://forge.frm2.tum.de/review/19693
Tested-by: JenkinsCodeReview <bjoern_pedersen@frm2.tum.de>
Reviewed-by: Enrico Faulhaber <enrico.faulhaber@frm2.tum.de>
initialisation occurs in this order:
- object creeation (via __init__ which should consume the cfg values it knows about)
- registering each object with the dispatcher
- calling init_module() on each module (for connecting to other modules, checking hw, creating threads....)
- calling start_module(cb) on each module. after the module finished startup it should call cb(self) once.
This is the right place to do initialisation of hw which is not needed to read from the hw.
(uploading curves, polling/re-setting all parameters, etc.)
Change-Id: Ieaf9df5876e764634836861241f58ab986027f44
Reviewed-on: https://forge.frm2.tum.de/review/18566
Tested-by: JenkinsCodeReview <bjoern_pedersen@frm2.tum.de>
Reviewed-by: Markus Zolliker <markus.zolliker@psi.ch>
Reviewed-by: Enrico Faulhaber <enrico.faulhaber@frm2.tum.de>
