The Robot Controller (RC) sits at the same level as the Tool Controller (TC) and below the Workstation Controller (WC) in the architecture. The RC is expected to control exactly one robot or gantry. It may—in the case of a 3D printer—control the extruder/s and heated bed. It may also control the 4th or 5th degrees-of-freedom (DOF) or sensors related directly to the robot (e.g., position sensors, leveling sensors).
As with the RepRap 3D printer model of control by RepetierHost, Cura, etc., it is responsible for path, feedrate, and environmental control—controlling temperatures, etc.—of the robot. As an entity within the workcell ecosystem, it is responsible for communicating positional sensor information to the WC, to be used for collision avoidance or cooperative behavior in an environment where this may be used. Alternatively, it may be configured to operate only within its own confined space. This is the normal case for a simple 3D printer, and could be a reasonable case for a Visible Robot with more than one gantry mounted.
In the case of multiple gantries mounted on the same machine–as with the Visible 3Bot, the choice is whether to allow the gantries to share workspace; or whether to section off portions of the workspace and dedicate one portion to each of the gantries. The former makes sense in cases where the gantries either need to interact, or where the workspace required for the given tasks exceeds that which could be dedicated to each. The latter makes sense where the tasks given each gantry are independent of the others. This latter case allows for the hardware and software of each gantry to run completely independent of each other, without even the need to communicate—except possibly when one gantry is dependent on the position of another, as in homing, where one gantry’s minimum position along one axis depends on another gantry being at its maximum position on that axis. (E.g., The gantry being homed senses its minimum limit against the maximum position of the other gantry).
At this point in time (early 2017), an Arduino Mega, with a RAMPS1.4 shield is more-or-less the de facto standard for DIY builds. There has been talk on the www.RepRap.org site of a more capable ARM-architecture board which would better future-proof the controller and give it some protection from vendor lock-in. Other boards such as Printrboard and Megatronics are, of course, also available.
The E0 and E1 motor controls of the RAMPS board—used for extruder control on 3D printers—may be re-purposed for gantries without 3D printer extruders to drive, for example, to control 4th and 5th degree-of-freedom (DOF) joints.
The Megatronics V3 board has six motor-control outputs which can be used to control three axes plus three extruders, or three additional DOFs, or three motorized tools mounted on an end-effector platform (EEP).
Tasks will be received from the WC via USB and stored locally for the current session on an SD or memory stick or in internal memory if that is available. The task includes the tool or tools to be used—in the case of a task where multiple-tools will be used simultaneously–as with the 3-port Finix ATC; the tool-paths to be followed; the feedrate; spindle speed, environment (heaters, misting, vacuum, etc.) to be set up, sensed, and maintained; and the end-effectors (e.g., tool-bits, camera) and sensors required.
On a “Start task” command, the task will be run from the SD.
Inasmuch as the workstation environment is likely to be dynamic during any work shift, the RC isn’t expected to maintain all the possible configurations of its environment. Instead, the WC provides the changes affecting the RC, including, if the robot is setup to interact with other machines in the environment—a forum for the entities within the environment to negotiate for space and tool-use.