When connecting to a fast reacting server, if may be possible that
the "_communicate" function sends it command earlier than the question
for the SECoP version inside the "_inner_run" function. A new variable
showing the connection status forces to wait inside "_communicate".
Change-Id: Id521bbd53fea9e2e980b9c11b849d36cfdeb1ec2
Signed-off-by: Lutz Rossa <rossa@helmholtz-berlin.de>
Reviewed-on: https://forge.frm2.tum.de/review/17006
Tested-by: JenkinsCodeReview <bjoern_pedersen@frm2.tum.de>
Reviewed-by: Enrico Faulhaber <enrico.faulhaber@frm2.tum.de>
create the correct descriptive data.
Main use case is for unit-tests and testing custom configs.
Change-Id: I3077f80cb9fdbf2443ee9da796c3749707fd2b55
Reviewed-on: https://forge.frm2.tum.de/review/16806
Tested-by: JenkinsCodeReview <bjoern_pedersen@frm2.tum.de>
Reviewed-by: Enrico Faulhaber <enrico.faulhaber@frm2.tum.de>
also make interface more explicit
Change-Id: Ib104e2c050d3e98e9d434d502951e33619784e2e
missing: test cases for *.from_string(input) methods
Reviewed-on: https://forge.frm2.tum.de/review/16893
Tested-by: JenkinsCodeReview <bjoern_pedersen@frm2.tum.de>
Reviewed-by: Enrico Faulhaber <enrico.faulhaber@frm2.tum.de>
StringIO::multicommunicate can now only handle up to 100 messages.
Should be sufficient.
Change-Id: Id3ccdf03143b80a37aa0ef0b87c47090ef802a42
Reviewed-on: https://forge.frm2.tum.de/review/16288
Reviewed-by: Enrico Faulhaber <enrico.faulhaber@frm2.tum.de>
Tested-by: Enrico Faulhaber <enrico.faulhaber@frm2.tum.de>
+ rework GUI
- include a combobox for selection of visibility
- include a checkbox wether validation should be done in the client
- remove unused lineEdit
+ improve datatypes
+ improve tests for new descriptive data
+ metaclasse: fix overlooked read_* or write_* func's
+ improve polling
+ Introduce new ErrorClasses
+ dispatcher: use new features of datatypes + PARAMS
+ improve lib
+ autopep8
+ first working version of MLZ_entangle integration
+ split specific stuff into it's own package (MLZ,demo,ess)
Change-Id: I8ac3ce871b28f44afecbba6332ca741095426712
second approach, better fitting what was agreed upon so far.
- pv_names are local to SEC-node, so not exporting via json and marking
them 'private'
- 2 devices for 2 temperature control loops, not one 'monster' device
which handles everything.
- read_status implemented
- write_target also updates the status (may be sensible to go to the core?)
- provide working stubs in case epics is not installed (-> testing possible)
- tested with the stubs.
- tests with real epics.
found problems:
in EpicsTempCtrl(EpicsDriveable) the read/write_<paramname> methods from
EpicsDriveable needed to be reimplemented. This should not be needed!
Change-Id: I9e4eeaff83114131d117c8f04fba758dfe22237b
+ make parameter-properties configurable
+ better derivation of automatic properties
+ implement 'group' properties (how to display in gui???
+ clean up descriptive data by omitting unset and live properties
Change-Id: Icd2b6e91e09037e9d4a8d6ad88483f8509a2cf5f
