A brief conceptual introduction to the main features of the YRC controller and API, relevant to extension development, is given below.
A tool defines a set of properties for end-of-arm tooling and payloads, including weight, center-of-mass/gravity, (T)ool (C)enter (P)oint offset & orientation from the mounting flange and moment of inertia.
The performance of the manipulator depends on an accurate dynamics model including the tool & payload. Hence, to minimize cycle-times it is recommended to accurately represent tool and payload weight and other properties. The pendants have functions for automatically determining TCP positions and mass properties for unknown tools and payloads.
On the controller, tools are referenced by number and can be associated with motions to taught positions. For this reason, it is common to define tool properties, not just for an empty end-of-arm tool (e.g. a gripper), but also for the tool with work pieces that may be grasped. This is so that during motions holding a work piece, the robot will have accurate mass properties for its internal model and can control for expected forces during motion. For Power & Force Limited robots (Collaborative robots), accurate tool weights will also avoid unexpected force-limit stop events.
The controller provides storage for variables that can be used by controller jobs (e.g. INFORM jobs).
Types: YRC Controllers support variables with types Byte, Integer (16bits), Double Integer (32bits), Real (floating point), String (text character sequences) and Position.
Scope: Global scope variables persist on the controller independently of any running programs/jobs and can be accessed by any job, whereas Local scope variables are job-specific and only exist while a job is running. Extension can access global variables to communicate with INFORM jobs or MotoPlus apps running on the controller.
Variables can be accessed by name or address.
Addresses: Most developers are accustomed to their programming language of choice managing the
relationship between named variables and their storage location (numeric memory address), though in some languages the address of a variable is accessible (e.g. C). In such languages, all variables, regardless of type, occupy a single address-space.
However, in the YRC controller series, variables are segregated according to type into different addresses spaces. These different address-spaces and numeric addresses are presented to the user by prefixing variables with their type. For example:
B000 - the Byte variable at address (index) 0I050 - the Integer variable at address 50P200 - the Position variable at address 200D200 - the Double Integer at address 200P200 and D200 are different variables since they live in difference address-spaces - the Position address-space and the Double Integer address-space respectively.
Variables may or may not have an associated name. The names of Global variable can be set via the API. It is good practice to use globally unique names for variables.
Controllers may support multiple types of Input/Output, including physical digital wires, network
I/O with various protocols, virtual controller states etc.
I/O can be referenced via two different address spaces:
The mapping from user input & output numbers to the underlying Logical I/O address is configurable (though often setup during manufacturing infrequently changed).
Inputs & Outputs represent single bits. An I/O group is a set of 8 inputs/outputs (i.e. a byte).
1-4 groups can be read & written together, represented as 1-4 bytes (8, 16, 24, or 32 bits).
Fetching multiple I/O bits synchronously frequently via the Controller I/O functions is inefficient
and should be avoided. Prefer adding relevant I/O numbers to the monitored set and reacting
to IOValueChanged events instead.
Zones represent a physical space within the manipulator workspace. They can be specified using either axis ranges or via a rectangular prism (box shape) in Cartesian coordinates (corners or center & dimensions). When the TCP enters a configured zone, either an alarm (stop condition) can be generated or the status can be reflected via an output bit (also accessible programmatically).
If your robot controller has a Functional Safety Unit (FSU), Safety range limits can be defined using Cubic, Plane and Custom volumes to exclude all parts of the manipulator from inside or outside defined spaces. Custom volumes can be defined using a set of Cylispheres (Capsules). Safety range limits can also be associated with output signals and signals can be used to programmatically enable and disable them, providing great flexibility.
User frames are user-defined coordinate frames. Once defined, these coordinate frames can be referenced in, for example, stored positions and motion commands. For example, a program may perform motions relative to workpiece fixtures or palletes, so that the same sequences can be used for multiple fixtures. User frames can also be manipulated programmatically, for example to update them with data from a vision system so that motion commands can remain relative to workpieces that may be placed arbitrarily.
User frames are defined via an origin Cartesian point and two other points to define a plane. Together this uniquely determines an arbitrarily positioned and oriented coordinate system in 3D space.
A ControlGroup represents a set of axes that can be controlled - such as a robot, an external base (e.g. a rail) or a station (e.g. a part fixture able to rotate and tilt).
In many cases, the only control group defined is R1 - a single robot connected to the controller.
However, the YRC1000 Controller can support up-to 8 robots (or 72 axes). The YRC1000micro and Smart Pendant only support a single robot.
Custom control groups can be configured on the controller, by combining simple groups - for example, by combining a robot and a base and station, or two robots etc.
In addition, the controller may support coordinated motion between a master & slave control group,
such that one will move in response to commanded motions of the other. For example, a control
group including a robot and a station where the station is the master, allows motions commanding the station (e.g. holding a part) to cause the robot to move in order to maintain the same relationship between the robot tool and the part on the station.
For example, R1+R2+B2+S1:S1 designates a combined control group, consisting of the simple control groups corresponding to Robot 1, Robot 2 including a Base, and Station 1. Additionally, Station 1 is the master control group.