The RMP Motion Controller APIs
RapidCodeRemote

Description

Create motion and IO applications over a network using gRPC: a high performance, open source universal RPC framework. If you are using C++ or C# on Windows or INtime operating systems, you should use RapidCode, not RapidCodeRemote.

In gRPC, a client application can directly call a method on a server application on a different machine as if it were a local object, making it easier for you to create distributed applications and services. As in many RPC systems, gRPC is based around the idea of defining a service, specifying the methods (RPCs) that can be called remotely with their parameters and return types. On the server side, the server implements this interface and runs a gRPC server to handle client calls. On the client side, the client provides the same methods as the server. (source)

Requirements

RPC - Remote Procedure Call

Every RapidCodeRemote RPC follows a common pattern. Each request takes optional configuration settings or actions, and each response contains the latest configurations, action details, read-only infomation and the latest status.

For example, here is the MotionController RPC definition:

rpc MotionController(MotionControllerRequest) returns (MotionControllerResponse) {};

Request (set)

Request example

message MotionControllerRequest {
// Common request header.
RSI.RapidServer.RequestHeader header = 1;
optional MotionControllerConfig config = 2;
optional MotionControllerAction action = 3;
}

Response (get)

Responses contain all the types of data mentioned below. The data is read in the following order:

Response example

message MotionControllerResponse {
// Common response header. Always check the response header for errors.
RSI.RapidServer.ResponseHeader header = 1;
optional MotionControllerConfig config = 2;
optional MotionControllerAction action = 3;
optional MotionControllerInfo info = 4;
optional MotionControllerStatus status = 5;
}

Response errors

If there are connection issues with the RapidServer, gRPC clients will throw exceptions with gRPC error codes.

Assuming there are no high-level gRPC errors, all RapidCodeRemote RPCs will report errors in the header of each response. Users are required to check the errors field, which contains details about any RapidCode errors encountered during the RPC execution. RapidCodeRemote response header:

message ErrorMessage {
// An error that occured on the server while executing the remote procedure call.
string message = 1;
// Any relevant information to accompany the error.
google.protobuf.Any data = 2;
}
message ResponseHeader {
// Return the RequestHeader back to the client.
RequestHeader request_header = 1;
// The time the server received the request (according to the server's clock).
google.protobuf.Timestamp time_request_received = 2;
// The time the server send the response (according to the server's clock).
google.protobuf.Timestamp time_response_sent = 3;
// Errors to report back to the client.
repeated ErrorMessage errors = 4;
// Return the request message to the client.
google.protobuf.Any request = 5;
}

Supported RPCs

There is one RPC for each RapidCode object. If you need to operate on more than one object of particular type at one time, you can use the Batch RPC. A common use case is where you might want to get the status of several Axis objects with one RPC. Use AxisBatch in that case.

RPC Batch
MotionController n
Axis y
MultiAxis y
Network n
NetworkNode y
UserLimit y
Recorder y
RTOS y

Supported Languages

🌐 Subsections

Modules

 Enums
 
 RPCs
 
 Sample Apps
 
RSI