Arch Image 1
Figure 1. RCF Architecture
A typical implementation of RCF is shown in Fig.1 block diagram. The Real-time Platform runs rtSystemController while the higher level tasking in the Non RT block is run under a separate process or computer on a GPOS (general purpose operation system, i.e. non-RTOS). The RT block handles I/O and fast control of the robot state. The Non-RT application block handles tasking and application logic. This flexible architecture allows for fine tuning of the control and application components. Options for real-time include QNX and vxWorks. GPOS can Windows or Linux.

The hardware interface for the robot is found in the transfer layers of the RT block. Different transfer layers exist for EtherCAT, UR RTDE, CAN and other vendor specific hardware interfaces.

Fig 2. System Controller Hierarchy

The system controller (Fig. 2) handles the tasks, threads, and multiple manipulator controllers. RCF comes complete with all the framework components, with the requirement that the developer add transfer layers, state machines definitions, and call back functions for custom elements.

Fig 3. RCF Deployed for UR Control with ActinViz
The UI for a deployed system is shown in Figure 3. This application runs in the Non-RTOS block, communicating with the controller through the data store. The data store resides in the Real-time block.

The Architecture is made up of these components

  • System Controller : executes the state machine and control tasks
  • Data Store : stores primitive data, objects, and resources.
  • Data Access Layer : provides access to the data store in a thread-safe manner
  • Data Transfer Layers : provides I/O and client services. Moves data to/from the data store.

The RCF pages to follow will explain each of these components and how to configure and customize your RCF-based application.