.. currentmodule:: taurus.qt.qtgui.panel .. _diagnostics: Inspect a running Taurus GUI ============================ Taurus provides a diagnostics window for inspecting the models used by a running GUI. The window is read-only: opening or refreshing it does not create models, register listeners, start polling, or change event subscriptions. Open the diagnostics window --------------------------- Press :kbd:`Ctrl+Shift+D` in any application containing a Taurus widget. Applications based on :class:`~taurus.qt.qtgui.container.TaurusMainWindow` also provide a ``Tools > Diagnostics`` menu action. Only one diagnostics window is created for the application. It can be resized or maximized, and its tables can be sorted by clicking their column headers. Inspect process information --------------------------- The **Process** tab shows the application, Taurus, Python, Qt, Qt binding, window system, and operating-system versions. It also lists the available control-system schemes and factory plugins. Factories may provide additional backend-specific information, such as the PyTango version and configured Tango event subscription mode (with PyTango 10.1 or newer), or the pyepics version. The optional ``plotpy`` and ``taurus_pyqtgraph`` packages are reported as installed or not installed. The ``taurus_pyqtgraph`` entry also shows the ``pyqtgraph`` version when available. Authors of scheme plugins can expose their own information through :meth:`~taurus.core.taurusfactory.TaurusFactory.getDiagnosticInfo`; see :ref:`custom_scheme_diagnostics`. The tab also shows the process identifier, start time, CPU usage, memory usage, and resident memory. CPU and memory information requires the optional ``psutil`` dependency. Inspect devices --------------- The **Devices** tab lists device models which already exist in the process. The table provides: * **Device name**: the complete Taurus model name. * **IDL version** and **Events support**: optional backend-specific capabilities. Tango provides these values; backends without equivalent information display ``N/A``. * **Listeners**: the number of local callbacks registered on the Taurus device model. * **Event count**: the accumulated events dispatched by attributes belonging to the device while diagnostic statistics were enabled. Hover over the value to see the count for each event type. Select a device to see its registered listeners below the table. Backend capabilities such as the Tango IDL version are cached after the first query. Inspect attributes ------------------ The **Attributes** tab lists existing attribute models and provides: * **Subscription**: the current event subscription state, when supported by the backend. * **Listeners**: the number of callbacks registered on the Taurus model. * **Polling** and **Period**: whether client-side polling is active and its configured period. * **Event count**: the accumulated number of all dispatched event types. Hover over the value to see the count for each event type. * **Change (Hz)** and **Periodic (Hz)**: event rates measured between window refreshes. * **Errors**: the accumulated number of error events. * **Last event**: the local time of the last event dispatched by the model. Columns are initially sized to their contents and remain manually resizable. The automatic refresh updates only the visible tab. Its interval can be changed at the bottom of the diagnostics window and defaults to three seconds. Use the ``Refresh`` button to update all tabs immediately. Understand listeners and subscriptions -------------------------------------- A listener in this window is a local Python callback, not a separate subscription to the control system. One Taurus attribute model normally owns the backend subscription and distributes received events to its local listeners. Event statistics and performance -------------------------------- Event counters are disabled by default. They advance only while the diagnostics window is visible, avoiding work in the normal event dispatch path when the feature is not in use. Existing counter values are preserved when the window is closed and resume the next time it is opened. The diagnostics implementation is control-system agnostic. Common information is collected through Taurus model and factory APIs, while backend-specific capabilities are supplied by the corresponding factory.