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)

🔹 Available 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

• C#
• C++
• Python
• Dart
• Go
• Java
• Kotlin
• Node
• Objective-C
• PHP
• Ruby

🔹 Requirements

• RMP licensed with the RapidCodeRemote feature bit.
• RapidServer must be running (Windows or INtime). Start it using command-line interface or as a new process.

🔹 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 for MotionController: Sends config/actions, receives updated config, action details, status, and read-only info.
  rpc MotionController(MotionControllerRequest) returns (MotionControllerResponse) {};

Request (set)

• Config - Configuration values you want to set. Every value is optional. Configurations are set in the order in which they are listed in the .proto.
• Action - Perform one or more actions. Every action is optional. Actions are performed in the order in which they are listed in the .proto

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:

• Config contains the latest Configuration values gotten from the object.
• Action contains any responses from requested actions. Not all requested actions have return values. Those that do will be included here.
• Info Read-only information, which is data that changes infrequently, such as version information, etc.
• Status Read-only status is read last, so its data is the most recent. This contains values which change frequently, such as Axis positions, etc.

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 ErrorSource {
  // Object index (0-based index of the object that has the error)
  int32 object_index = 1;
  
  // Whether the error is or is not a warning.
  bool is_warning = 2;
  
  // Source file name.
  string file_name = 3;
 
  // The name of the function that raised the error.
  string method_name = 4;
  
  // The line number in the source code
  int32 line_number = 5;
}
 
message ErrorMessage {
  // An error that occured on the server while executing the remote procedure call.
  string message = 1;
  
  // An error code. Will have to be casted to the appropriate enum type.
  int32 code = 2;
 
  // The human-readable name of the error code.
  string code_name = 3;
 
  ErrorSource source = 4;
 
  // A shorter, more concise version of the error message.
  string short_message = 5;
}
 
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;
}

🔹 RMPService Client/Stub

To perform an RPC, you will have to create a gRPC Channel to connect to a server listening for requests at a specific IP address and port. That channel can then be used to create a client (C#) or a stub (C++ and Python). The client or stub will contain all of the RPCs provided by the RMPService as defined in rapicode.proto.

• C#

        channel = new Channel(ipAddress, PORT, ChannelCredentials.Insecure);
        rmpClient = new RMPService.RMPServiceClient(channel);

• Python

   
          # # Create the stub for using the RMPService
          # rmp_stub = rapidcode_stubs.RMPServiceStub(channel)

🌐 Subsections

Topics
	Enums
	RPCs
	Sample Apps