You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This should be an independent project (i.e. create new repository on github). This very simple application just has one DeviceModule opening a single device. This DeviceModule is then connected to a ControlSystemModule with connectTo(). Since many devices have only poll-type variables, there should also be a configurable trigger. Use a PeriodicTrigger module for this purpose and specify its tick variable in the connectTo() call as second argument. Both the tick and the period of the trigger should be visible in the control system inside a directory "/trigger".
The idea if this application is of course to use it in combination with the LogicalNameMapping backend, so the registers which should be visible in the control system can be selected and properly named. Also register plugins can be used e.g. to convert raw values to physical units.
The application can also double as a starting point for writing new, more complex applications. It is therefore useful to document the code well and use a structure of the project which is suitable for extension, i.e. put a header file into the include directory and the source file into the src directory and follow best practises in CMakeLists.txt. The project should link against a user-selected control system adapter, refer to the LLRF server for an example how to do that (maybe: put that code into a cmake module in project-template and use that module).
DoD:
New source code repository
Implementation
Inline code documentation so beginners understand what's going on
Test based on ApplicationCore testable mode and a dummy device
Example configuration files with a dummy device, a logical name mapping layer and DOOCS config files (if the DOOCS adapter is found)
User documentation doxygen page how to use it as a simple server
Setup Jenkins job
The text was updated successfully, but these errors were encountered:
We decided to split this into two subprojects: First, a template for new servers (see #64). This should be placed in the ApplicationCore repo as an additional example. It should not yet define a specific triggering (i.e. PeriodicTrigger vs. external trigger from a device). Later, a real standalone server can be constructed from the template.
This should be an independent project (i.e. create new repository on github). This very simple application just has one DeviceModule opening a single device. This DeviceModule is then connected to a ControlSystemModule with connectTo(). Since many devices have only poll-type variables, there should also be a configurable trigger. Use a PeriodicTrigger module for this purpose and specify its tick variable in the connectTo() call as second argument. Both the tick and the period of the trigger should be visible in the control system inside a directory "/trigger".
The idea if this application is of course to use it in combination with the LogicalNameMapping backend, so the registers which should be visible in the control system can be selected and properly named. Also register plugins can be used e.g. to convert raw values to physical units.
The application can also double as a starting point for writing new, more complex applications. It is therefore useful to document the code well and use a structure of the project which is suitable for extension, i.e. put a header file into the include directory and the source file into the src directory and follow best practises in CMakeLists.txt. The project should link against a user-selected control system adapter, refer to the LLRF server for an example how to do that (maybe: put that code into a cmake module in project-template and use that module).
DoD:
The text was updated successfully, but these errors were encountered: