This is mandatory according to the documentation, otherwise we have 0
all the time and lose persisted data

BREAKING CHANGE: The new interface no longer allows to create the same type of
location with arbitrary location codes, hence we have to decide for a fixed
code now. Using a location code which is not 10 (as used by default) now
results in an exception.

Dietrich Rothe authored 1 year ago and Dietrich Rothe committed 1 year ago

code was still referring to the ControlSystemAdapter location

* image encoding concept

byte-array which is reinterpreted via templated view

* add xml option D_image for DOOCS image

MappedImage now has the code which shall be included from the server application. 
DoocsImage has DOOCS-dependent stuff.
MappedImage builds on generic interface for opaque structs.

* discussion points and some small improvements

- OpaqueStructHeader: use type_index
- rework ImgHeader definition
- rename xml tag D_image -> D_imagec
- add some documentation
- add unit tests
- refactoring

* move MappedImage.h to ControlSystemAdapter

* get rid of compiler warning

which was due to overly strict check of definition=declaration

* refactoring

- get rid of much of the code duplicates by moving functionality to base
class PropertyBase
- make timestamp handling more consistent
- make data consistency group usage more consistent accross different classes
- formal code style fixes
- some formal code cleaning and documentation

* copyright headers

* apply clang-format-14 -i <files>
* fix include order where messed up by autoformat

* docu for D_xy
* enable ZMQ for D_xy

* reduce number of linter warnings

* PropertyBase as seperate file

* put error into ZMQ status

Co-authored-by: Dietrich Rothe <dietrich.rothe@desy.de>
Co-authored-by: Martin Hierholzer <martin.hierholzer@desy.de>

This can happen e.g. if the ProcessArray length in the application has
changed but the old value is still in the DOOCS config file. If the new
length is bigger than the old one, the server crashed because it
attempted to read too many value from the property in auto_init.

This fix should also cover the case when a wrong length is set trough an
RPC call.

If a macro pulse number is attached to a property which is mapped to a
variable mapped to also other properties, the update from the other,
writeable property was not getting through due to the consistency check.
This check is now effectively disabled in that case, which is ok, since
the update is anyway uncorrelated to the macro pulse number (since
coming from e.g. the operator).

If a writeable process variable is mapped to multiple properties, so far
the values in the properties were not synchronised, i.e. writing to one
property did not propagate the value to the other connected properties.
This synchronisation is now implemented.

Note that inconsistencies might occur when more than one of the
properties is writeable, hence a warning will be displayed in this case.

* concept for error reporting to set_error
- destination is DOOCS EqFct::set_error(code, message)
- StatusMonitor variables and/or Device status variables as input
- configuration per location via xml
- only single data source for set_error
- consistent updates of error code and error message, to remove
duplicate log lines
this depends on changes in ApplicationCore/DeviceModule!
* remove deprecated use of boost/test/test_case_template.hpp
* make configuration of status message input unneccesary
it will be found from the naming convention
* some refactoring
which was neccesary because Status definitions moved to
ControlSystemAdapter
* add docu for set_error
* add basic test for set_error tag

Co-authored-by: Dietrich Rothe <dietrich.rothe@desy.de>

* partial fix for #9836

This fixes that cleared error codes appear in DOOCS history where error
is not yet cleared.
It is only a partial fix since the history still contains more data than
was intended; intended was only first invalid data point

* remove comments about outdated concept

Co-authored-by: Dietrich Rothe <dietrich.rothe@desy.de>

Identical time stamps are considered to have identical data when DOOCS checks for inconsistencies on silent ZeroMQ connections. If on the same property new data is set without changing the VersionNumber, the timestamp will now be altered by 1 microsecond.

This is more like a temporary work around. A feature request to DOOCS should be made to introduce a distinction between a "server timestamp" and a "source timestamp" like it is realised in OPC UA.

Also a potential better solution to the other part of the problem inside ApplicationCore is described here: https://redmine.msktools.desy.de/issues/9723 

This will be used unless overriden in doocs server conf

This can potentially be a severe performance issue, if an application has many persisted large arrays.

- arrays are now by default saved just like spectra
- Short arrays go into main server config file, long into separate files
- only if array is writable
- behaviour is configurable in order to return to default behaviour of
DOOCS

Also, for the "trivial" datatypes such as scalar, array, IFFF enable
attaching a macropulse number on incoming variables so we can send out
updates from e.g. JDDD panels out via ZMQ

No test yet, hence ticket added on github #63

Reason: otherwise error messages are sometimes appearing at server start/shutdown because sending is not possible at that time.

this will be cleared once the initial value has been received

dmsg_info.ident is set to 0 when DoocsProcessArray and
DoocsProcessScalar do not have a macropulse source defined.  This is
what the other supported types do currently; behavior should be
consistent between the types with this commit.

Revert this if it is not the intended behavior.

The adapter publishes value changes made from the control system side
for the following types:
  DoocsSpectrum
  DoocsIfff
  DoocsProcessArray
  DoocsProcessScalar

This avoids multiple map lookups.

This is a workaround for the following DOOCS bug:
https://rt-system.desy.de/Ticket/Display.html?id=985653

All IFFF sources must be consistently readable/writable. A logic error
is thrown if this is not the case.