If you had a PushInputWB mapped to DOOCS but changed it not to be
writeable, you would not receive a proper initial value but 0.

Now, if there is only one variable connected to this, write down the
initial value nevertheless.

Issue was introduced with 1992ded5

* feat: Add support for D_IIII

Simple support that maps a D_IIII to an array

* fixup! feat: Add support for D_IIII

* fixup! feat: Add support for D_IIII

* fix: Remove type() function

* fixup! fix: Remove type() function

* fixup! fix: Remove type() function

* fix: Weird fomatting

fix(project-template): (re-)enable DOT support in Doxygen

fix(project-template): find pattern in coding style check

update project template

This is no longer needed by DOOCS.

EqFct::set() requires the caller to acquire the location lock. This is
important even in non-threaded contexts since the lock is released
internally (which is not allowed if the mutex is not locked).

"Remove this once we can get rid of xenial"

Dietrich Rothe authored 7 months ago and Dietrich Rothe committed 7 months ago

check that even when statusCodeSource for set_error is not explicitly
mapped to DOOCS, it is kept as 'used variable'
This is a regression test for bug #11853.

The version of EPICS (3 or 7) is now defined by which EPICS version is
used by the found adapter. There are no distinct names any more, also
EPCIS3 is effectively phasing out.

Dietrich Rothe authored 7 months ago and Dietrich Rothe committed 7 months ago

Fix set_error feature in case statusCodeSource is not explicitly mapped as DOOCS property.

See bug #11853.
There is no regression test here since the bug does not show up with ReferenceTestApplication.
The latter does not optimize the variable network, but the bug depends on the optimization.

This is not strictly necessary, as it still compiles without this change due the compatibility include.

With a value of 1, sending a second value on the same property before
the previous value has been processed (by ZeroMQ) will cause the second
value to be lost. This was observed to happen spuriously in some
cases. The new value should reduce the probability massively, the
remaining cases will be corrected by the DOOCS watchdog generating an
error due to mismatching data.

The timestamp is used by DOOCS to check whether the last update received
via ZMQ is consistent with the current value (for slowly changing PVs).
Previously it was possible that the timestamp was identical desipte the
value has changed, if the PV changed very fast an odd number of times
with the same timestamp:

1. Very fast changes seem to get lost on ZMQ, only the first update is
transported (despite the latest value ends up in the property and hence
is visible via RPC). This happens also with multiple consecutive
updates.

2. The old mechanism added 1 microsecond, if the timestamp of an update
was identical to the previously sent one, which means the 3rd update
will again get the original timestamp. This renders the DOOCS
consistency check useless if two changes with the same source time stamp
are lost.

This caused ZMQ connections to be interrupted due to the DOOCS-internal
watchdog checking the connection after the ZMQ timeout with an RPC
request.

The reference test application has been extended to include boolean and
void, the test was missing this

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

update project template