Jens Georg authored 2 years ago and Martin Christoph Hierholzer committed 2 years ago

 - ApplicationModule can only be owned by ModuleGroup

Jens Georg authored 2 years ago and Martin Christoph Hierholzer committed 2 years ago

Move everything inside TestableMode and add decorator helper functions
to TestableMode

Jens Georg authored 2 years ago and Martin Christoph Hierholzer committed 2 years ago

While at it, fix linter issues in ModuleGroup as well

it was anyway dysfunctional and mainly slightly reducing performance.

The VoidAccessor comes along with the convenience classes VoidInput and VoidOutput,
and the TestFacility function getVoid()

This fixes together with another change in DeviceAccess the LNM
MathPlugin with push-type variables as parameters.

Introduce StatusWithMessage and StatusWithMessageReader which handle this.
It is used in DeviceModule error reporting.
This is a preparation in order that we can report errors consistently to DOOCS, in DoocsAdapter

make StatusAggregator use StatusWithMessage

it should output always status code + string
on the input side, connects to either status or status + string
corresponding string input is found automatically
NOTE: DeviceModule API change, the status output variables are
renamed from (status, message) to (status, status_message)!

update testing of DeviceModule outputs

because of API change of DeviceModule  (renamed message ->
status_message)

fix crash and improve message and test

- fix crash due to incorrect handling of cast to Derived
- improve message output
- make existing tests pass
- add test for status message of StatusAggregator

move StatusWithMessageReaderBase and Status def to ControlSystemAdapter

since it is required from ApplicationCore as well as from the adapters

makes test move_invalid pass

Sometimes several long running modules in a row might have caused false alarms. So seen in tests of the llrfctrl server with multiple devices (which require some time to open and initialise).

Simply add timeout to acquiring the testable mode lock and print an error message with the last thread which successfully obtained the thread. Finally throw an exception to help debugging.

Slashes are not allowed in module names, but the DeviceModule crates a status module using the CDD (or alias) as a name. The slashes are now replaced by underscores.

See #7425

It can be static and it may make sense to use it outside modules. The implementation should probably move to a Application member function to make it easier to reach from non-module code.

to check whether stepApplication() can execute...

This generates graphviz code to visualise the connections between modules

The previous implementation using the mutex had two issues:

1. The mutex was locked in a different thread than unlocked (DeviceModule constructor vs. handleException() thread). This results in undefined behaviour.
2. The boost::shared_mutex::lock_shared() function is not an interruption point, so applications did not terminate while waiting for initial values. (boost::latch::wait() is an interruption point.)

This will print always a lot of information if one or more devices is unavailable at server start. There is a high risk that these messages distract from the actual issue (broken hardware), hence it is better to remove this.