.. _state_engine_viewer: State Engine Viewer =================== The state engine viewer provides visible access to all SCXML based state-machines that publish their state changes via rsb. You cannot alter any behavior but instead observe state changes of said state-machines. The engine-viewer's behavior is explained with the help of the following screenshot: .. figure:: /images/software/taskvis.png :scale: 100 % :figclass: align-center A screenshot of the engine viewer component. The general direction of reading is **top-to-bottom** as indicated by the red arrow. Every time a state-change occurs, a new row is being inserted into the table which is then automatically highlighted. Furthermore, the very next row is being cleared for readability. Please note that the visualization does not provide a scroll-back history but wraps around like a ring buffer. Each state-change (row) is thereby characterized by a time-stamp, the name and unique identifier of state-machine that the change occurred in. The **prior state (a)**, the **reason for changing (b)** if applicable, and the new **current state (c)** are given in the next three columns. For example, the highlighted row in the screenshot is caused by a change from the state *InvokeTask* to *Ready* because the invoked sub state-machine with the name *task* completed. The state-machine *Coordination* therefore currently is in the *Ready* state. In the **bottom part of the window (d)**, a summary of all observed state-machines by their name is given. The number in square brackets indicates how many different state-machines (by identifier) with the same name have been observed. Because for example every task consists of a newly invoked state-machine, one can see the total number of executed tasks while the visualization has been running. The coordination should in general only occur once except the component has been restarted. The latest observed state is colored in blue. Error states are highlighted in orange, success in green. If you are not interested in certain events, a simple text filter can be applied in the **filter text field (e)**. As a typical example, if you are only interested in coordination and behavioral states, you can filter out all events of the *Recording* process. Additionally, you can (re-)start the observing and alter the default listening scope if really needed. Related resources ----------------- Currently, in the apartment there are at least two SCXML based state-machine-components that can be investigated: :ref:`scenario_coordination` and :ref:`auto_recording`. These three components also share the same repository. Component repository: - Browse component repository: `scenario-coordination-cfg `_. - ``git clone https://projects.cit-ec.uni-bielefeld.de/git/lsp-csra.scenario-coordination-cfg.git/`` System startup: - The ``engine-viewer`` component can be found in ``lsp-csra-supplementary.sh`` on the ``tools`` tab. - The component script is called ``component_engine_viewer`` - Start via console: ``$ csra-engine-viewer`` Related projects: - Browse repository `system-startup `_. - Browse IDE project `rsb-dsl `_.