5.3 Management of Control Right
=======================================

Because the robot controller is configured to be controlled by only one application, the user application should implement the logic for acquiring and transferring the control right with the manage_access_control function and the TOnMonitoringAccessControlCB callback function after robot initialization is complete, and should send control commands only while it holds the control right.

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.

Control authority is handed over only on request. When another client (for example the teach pendant) requests control, the holder receives MONITORING_ACCESS_CONTROL_REQUEST in TOnMonitoringAccessControlCB. When another client sends MANAGE_ACCESS_CONTROL_REQUEST, authority moves only if the holder answers manage_access_control(MANAGE_ACCESS_CONTROL_RESPONSE_YES); the requester then receives GRANT and the holder LOSS. If the holder answers MANAGE_ACCESS_CONTROL_RESPONSE_NO or does not answer, the requester does not get control, and further requests are not forwarded while the first one is pending. There is no function to give up control without a request. manage_access_control returns as soon as the request is made; the outcome arrives later in TOnMonitoringAccessControlCB. If your application must let the teach pendant take over, answer REQUEST with RESPONSE_YES. A client that sends MANAGE_ACCESS_CONTROL_FORCE_REQUEST takes control without an answer.