.. _troubleshooting_access_control_loss:

7.2 Access Control Loss
===========================

A. Error Case
-------------

Commands sent without control authority are not executed. The controller reports a warning alarm through TOnLogAlarmCB for every fourth such command.

This indicates that your client program cannot obtain robot control authority from the controller.

B. Root Cause Analysis
----------------------

The Doosan Robot system allows **only one active client** to have control authority at a time.  
If another process — such as **DART Studio**, **another API client**, or an **RT monitoring tool** — is currently connected,  
additional clients will be denied access until the holder answers a request with MANAGE_ACCESS_CONTROL_RESPONSE_YES. A client that sends MANAGE_ACCESS_CONTROL_FORCE_REQUEST takes control without an answer.

This issue often occurs when:

- DART Studio is left connected in **Monitor or Control Mode**.  
- A previous API session did not close properly (e.g., abnormal termination).  
- Multiple applications are trying to control the same robot simultaneously.  

C. Solution
-----------

1. Open **DART Studio** and check whether another connection is active.

   - Navigate to **Settings → API Control Authority**.  
   - Click **Release Control** if another client holds it.

2. If using multiple devices, ensure only one program connects to the same robot IP.

3. Restart the controller service to clear stale sessions (if necessary):

   .. code-block:: bash

      sudo systemctl restart dsr-control

4. In your client code, always close the connection after use:

   .. code-block:: cpp

      Drfl.close_connection();

.. note::
   The controller ignores every request from a client without control authority, except get_system_version, get_safety_configuration and setup_monitoring_version. A client without control authority still receives monitoring data, state and alarm callbacks; use the monitoring getters (get_current_posj, get_robot_state, ...) for position and state information.