GB/T 33266-2016General high-speed communication bus performance for modular robots (English PDF)

Foreword

This standard was drafted in accordance with the rules given in GB/T 1.1-2009.

It was proposed by the China Machinery Industry Federation and is under the jurisdiction of the National Technical Committee on Automation Systems and Integration Standardization (SAC/TC 159).

The main drafting organisations are the Institute of Automation of the Chinese Academy of Sciences, its Luoyang robot and intelligent equipment research institute, and the Institute of Automation for Machinery Industry.

The principal drafters are Wang Shuo, Li En, Zhou Chao, Yang Shuai, Wang Haidan and Liu Ying.

1 Scope

This standard specifies the basic performance requirements that a high-speed communication bus in a modular robot system must meet.

It is intended for the general high-speed communication buses used between the various modules of a modular robot system.

The performance of communication buses in non-modular robots may also be assessed with reference to this standard.

The standard that makes the others work

Modularity means a robot is assembled from parts that were not designed together, and what holds those parts together electrically is a bus.

If the bus is not specified, every manufacturer chooses their own, and modules that match mechanically still do not interoperate - which is the state the industry was in when this series was written.

So of the modular robot standards, this is the one with the most immediate practical consequence: mechanical interfaces can be adapted with a plate, and a bus mismatch cannot be adapted at all.

It is also the one that dates fastest, since bus technology moves, which is presumably why the requirements are written as performance figures rather than as a named protocol.

5 Jitter and synchronisation

Two requirements distinguish a robot bus from a general industrial one, and both concern time rather than throughput.

The first is jitter: the variation in when a message arrives, as distinct from how long it takes. A bus that delivers every command reliably but at varying instants gives each joint a slightly different idea of when to act.

The second is time synchronisation accuracy, which is the same problem seen from the other side. In a coordinated multi-axis motion, all the joints must act on a common instant, because the tool path is the composition of their simultaneous positions.

Get either wrong and the robot still works - it moves, it does not fault - but the path wanders, and the error appears as a mysterious accuracy problem that no amount of calibration fixes.

5 The rest of the electrical requirements

Transmission distance and the number of station connections set how large a robot the bus can serve, which for a modular system is a question of how many modules may be chained.

Transfer rate and communication cycle set how much data can move and how often, and the cycle is the one that has to match the control loop: a bus cycle slower than the servo rate makes the bus the limiting element in the control system.

Electromagnetic compatibility is not a formality in this application. A robot bus runs alongside motor cables carrying switched currents from drives, which is among the more hostile electrical environments a data link can be asked to work in.

Bit error rate closes the group, and it is the figure that determines how often the error checking specified under network performance will actually be exercised.

6 Network behaviour and documentation

The network performance clause covers topology, error checking, maximum communication delay, bus arbitration, and fault tolerance and self-healing.

Fault tolerance and self-healing deserve attention: a modular robot has many connectors, and connectors are what fail. A bus that stops entirely when one node drops out makes the modularity a liability.

Bus arbitration determines who may transmit when, and it is what bounds the maximum delay - a bus without deterministic arbitration cannot offer a delay guarantee, however fast it is on average.

The documentation clause and the four annexes complete the standard by pointing at the existing test standards for each group of properties, and Annex D's parameter table is what a purchaser would actually put in a specification.