The acquisition device control and status messages logic have been successfully implemented

March 03, 2024 — Written by Haris Turkmanovic


Share this article

The acquisition device control and status messages logic have been successfully implemented

Control and status message logic represent one of the system's core functionalities. It is responsible for configuring the acquisition device, overseeing its operation, and providing updates on the system's execution status. The Figure 1 illustrates the key components of the logic behind the overall control and status message-handling mechanism.

Control Logic OverviewFigure 1 - Overall control and status logic working mechanism illustration

As depicted in the figure, this mechanism comprises:

  • Control and status message logic integrated into the acquisition device firmware.

  • Control and status message logic integrated into the OpenEPT GUI application.

  • Links for control and status messages exchange, facilitating the transmission of control commands and status reports.

Acquisition device’s control and status messages logic

Within the device firmware, the logic for control and status messages is encapsulated within a distinct service. This service is responsible for receiving control messages, parsing their content, executing the appropriate actions based on the message content, and generating responses accordingly. The core logic and operational mechanisms of this service are depicted in the Figure 2.

Firmware Control ServiceFigure 2 - Acquisition device control service architecture diagram

Control messages are sent to the Acquisition device in the form of a control message request. These requests are sent from the HOST side on the previously opened TCP port on the acquisition device. A control message request is received inside the Control service server task, and it is forwarded to Message parsing logic to analyze control message content. Message parsing logic is part of Control service logic in charge of analyzing the content of received control messages and calling corresponding callback functions previously assigned to specific control messages. Part of the Control service code that creates a mapping between callback functions and control messages is presented in Figure 3. When callback functions that correspond to request control messages are executed, corresponding control message responses are generated based on callback function execution results. This response is sent back to the HOST machine.

Message parsing callback functionsFigure 3 - Supported commands and corresponding callback functions

All control messages are in ASCII format with predefined structures. Control message structures, as well as commands implemented within the current software version, are presented in this document

Besides control messages, there are also status messages that are used to inform the host machine about the system execution status. To enable this service, the device-side control message for configuring the status messages server should be utilized.

GUI Application control and status messages logic

The GUI application, located on the host side, which communicates with the device through the utilization of control and status messages, is developed using the QT C++ framework. An architecture diagram illustrating the classes involved in handling control and status messages, along with their connections utilizing QT slots and signals, is illustrated in Figure 4.

GUI Logic ArchitectureFigure 4 -GUI Control and status messages handling mechanism working principle illustration

OpenEPT Class

The OpenEPT class represents the main application window for the OpenEPT software. It inherits from QMainWindow and provides the primary user interface for managing devices and configurations. This class includes slots for handling actions such as adding a single device, closing device windows, and managing device containers. Additionally, it manages subcomponents such as the AddDeviceWnd, device containers, and connected devices menu.

DeviceContainer Class

The DeviceContainer class serves as a manager for coordinating interactions between a hardware device (represented by the Device class) and its corresponding user interface window (represented by the DeviceWnd class). It handles signals and slots for various device events, facilitating communication between the device and the user interface.

Device Class

The Device class represents a physical hardware device within the application. It encapsulates functionality for controlling the device, managing its configuration parameters, and interacting with it through control and status communication links. The class provides methods for starting and stopping device acquisition, setting and retrieving parameters such as resolution and sampling time, and handling communication with the device through control and status links.

DeviceWnd Class

The DeviceWnd class is responsible for managing the user interface window associated with a hardware device. It provides a graphical interface for users to interact with the device, adjust its settings, and visualize data. The class includes methods for setting device parameters, handling user input events, and displaying information related to device operation. Additionally, it manages subcomponents such as plotting charts and displaying advanced configuration options. 

StatusLink Class

The StatusLink class handles the status communication link for the device. It operates a TCP server to listen for incoming connections from clients (potentially other devices or components in the system). It manages client connections and facilitates the exchange of status messages between the device and connected clients.

ControlLink Class

The ControlLink class manages the control communication link for the device. It establishes and maintains a TCP socket connection to communicate with the device for control purposes. This class handles sending control commands to the device, receiving responses, and managing the connection status. It includes functionality for reconnecting to the device if the connection is lost.

Log Class

The Log class provides logging functionality for the application. It is responsible for managing and displaying log messages generated by various components within the system. The class allows logging messages of different types (info, warning, error) and provides a mechanism for printing these messages to a specified output widget, such as a console or log window.

AdvanceConfigurationWnd Class

The AdvanceConfigurationWnd class represents an advanced configuration window for a device. It provides functionality for setting various configuration parameters such as resolution, clock division, sample time, averaging ratio, voltage offset, and current offset. This class includes methods for assigning options lists for configuration parameters and setting specific values for each parameter. It also handles different load profile types and emits signals when the configuration is changed or requested. The GUI Window that represents this class is presented in Figure 5.

Advance Configuration WindowFigure 5 - Advanced configuration of GUI application's window

ConsoleWnd Class

The ConsoleWnd class represents a console window for displaying control messages and logging information. It provides functionality for printing messages to the console and sending control messages. This class includes slots for handling events such as sending control messages and receiving acknowledgment messages. Additionally, it manages logging functionality using the Log utility class. The console Window that represents this class is presented in Figure 6.

Console WindowFigure 6 - Console Window

© 2023 Open Energy Profiler Toolset. All Rights Reserved. made by