Architecturally, the Workstation Controller (WC) sits above Robot Controllers (RC) and Tool Controllers (TC) and below the Production Controller (PC).
It is responsible for Task Management of jobs coming from the PC, Tool Inventory of the tools within its current environment, Robot Status, Tool Status, End-effector Status—including wear, sharpening and preventive maintenance information, and production and tool consumables.
Given its responsibilities, the WC must have an operating system to manage system resources and schedule computing tasks. The OS will likely be a “server’ edition of Linux, dedicated to the workstation and its environment, unencumbered by desktop applications, but possibly with a GUI frontend.
As the “glue” for holding a robotic ecosystem together, the Robot Operating System (ROS) has a lot to recommend it. ROS is open source message-passing software used in many university (and some commercial) robotic settings. Its primary goal, according to its website is to foster code reuse in robotics and enable collaborative robotic software development. www.ros.org
To communicate with the PC, RC, and TC components in the system it must have several communication ports, including Ethernet or WiFi for PC communication and USB for RC and TC communication. Though it may appear so in this strawman, the architecture is not intended to be necessarily hierarchical. The WC may communicate directly with any device in its environment. One necessary communication is that the RC be advised of any changes to its environment—possible interferences with other machines or tools, changes in tool rack or tool-bit racks, etc. The WC must have available, whether natively or via splitters, at least four USB ports; one for its own peripheral communications and three to communicate with each of the three possible auto-tool-change (ATC) locations. Another USB, HDMI or display port should be available to be used as a workstation console.
At this point in time (early 2017), a Raspberry Pi 2 or 3 Model B seems to fit the needs decently, though, not having tried it out in a production environment, we wonder if it has the horsepower needed. (We look forward to a time when it or its equivalent will be outfitted with USB Type-C ports).
Will consist of receiving jobs from the PC, and scheduling the tasks involved based on available tooling, end-effectors and consumables. Tasks will be available on storage local to the WC and sent to the RC and TC via USB.
Tool Inventory and Tool Status
The WC shall maintain the inventory, location and status of tools within its environment and those missing or unavailable for work due to PM, repair, or other cause. It shall also maintain a status—including a measure of depletion—of the consumables it uses. On “Tool due for PM” and “Consumable past warning threshold” it shall issue warnings to the PC indicating the tool or consumable to be affected. On experiencing a “Tool down” or “Consumable depleted” condition with items it requires for the given task, it shall issue an error to the PC and to the machine’s console, write a message to the log, and pause the machine.
It shall be able to respond to status queries from the PC with workstation status, task status, status of each of the tools in its inventory, and details about the consumables available.