Legacy remote API modus operandi

A legacy remote API function is called in a similar fashion as a regular API function, however with 2 major differences:

  • most legacy remote API functions return a similar value: a return code. Always remember that the return code is bit-coded (so you will have to test the individual bits in order to correctly interpret it).
  • most legacy remote API functions require two additional argument: the operation mode, and the clientID (identifier returned by the simxStart function)

    • The need for an operation mode and a specific return code comes from the fact that the legacy remote API function has to travel via socket communication to the server (CoppeliaSim), execute a task, then return to the caller (the client). A naive (or regular) approach would be to have the client send a request, and wait until the server processed the request and replied: in most situations this would take too much time and the lag would penalize the client application. Instead, the legacy remote API lets the user chose the type of operation mode and the way simulation advances by providing four main mechanisms to execute function calls or to control the simulation progress:

  • Blocking function calls
  • Non-blocking function calls
  • Data streaming
  • Non-blocking, non-streaming data query
  • stepping mode (previously synchronous mode)


    • Blocking function calls: a blocking function call is the naive or regular approach, and meant for situations where we cannot afford not to wait for a reply from the server, like in following situation:

    // Following function (blocking mode) will retrieve an object handle: if (simxGetObjectHandle(clientID,"myJoint",&jointHandle,simx_opmode_blocking)==simx_return_ok) { // here we have the joint handle in variable jointHandle! }

    Following diagram illustrates a blocking function call:

    [Blocking function calls]


    Non-blocking function calls: a non-blocking function call is meant for situations when we simply want to send data to CoppeliaSim without the need for a reply, like in following situation:

    // Following function (non-blocking mode) will set the position of a joint: simxSetJointPosition(clientID,jointHandle,jointPosition,simx_opmode_oneshot);

    Following diagram illustrates non-blocking function calls:

    [Non-blocking function calls]


    In some situations, it is important to be able to send various data within a same message, in order to have that data also applied at the same time on the server side (e.g. we want the 3 joints of a robot to be applied to its CoppeliaSim model in the exact same time, i.e. in the same simulation step). In that case, the user can temporarily halt the communication thread in order to achieve this, as shown in following example:

    simxPauseCommunication(clientID,1); simxSetJointPosition(clientID,joint1Handle,joint1Value,simx_opmode_oneshot); simxSetJointPosition(clientID,joint2Handle,joint2Value,simx_opmode_oneshot); simxSetJointPosition(clientID,joint3Handle,joint3Value,simx_opmode_oneshot); simxPauseCommunication(clientID,0); // Above's 3 joints will be received and set on the CoppeliaSim side at the same time

    Following diagram illustrates the effect of temporarily halting the communication thread:

    [Temporarily pausing the communication thread]


    Data streaming: the server can anticipate what type of data the client requires. For that to happen, the client has to signal this desire to the server with a "streaming" or "continuous" operation mode flag (i.e. the function is stored on the server side, executed and sent on a regular time basis, without the need of a request from the client). This can be seen as a command/message subscription from the client to the server, where the server will be streaming the data to the client. Such a streaming operation request and reading of streamed data could look like this on the client side:

    // Streaming operation request (subscription) (function returns immediately (non-blocking)): simxGetJointPosition(clientID,jointHandle,&jointPosition,simx_opmode_streaming); // The control loop: while (simxGetConnectionId(clientID)!=-1) // while we are connected to the server.. { // Fetch the newest joint value from the inbox (func. returns immediately (non-blocking)): if (simxGetJointPosition(clientID,jointHandle,&jointPosition,simx_opmode_buffer)==simx_return_ok) { // here we have the newest joint position in variable jointPosition! } else { // once you have enabled data streaming, it will take a few ms until the first value has arrived. So if // we landed in this code section, this does not always mean we have an error!!! } } // Streaming operation is enabled/disabled individually for each command and // object(s) the command applies to. In above case, only the joint position of // the joint with handle jointHandle will be streamed. // Before disconnecting from CoppeliaSim, make sure to disable the streamings you previously enabled: simxGetJointPosition(clientID,jointHandle,&jointPosition,simx_opmode_discontinue); simxGetPingTime(clientID,&pingTime); // needed to insure that above reaches CoppeliaSim before disconnection

    Following diagram illustrates data streaming:

    [Data streaming]


    Once you are done streaming the data, the legacy remote API client should always inform the server (i.e. CoppeliaSim) to stop streaming that data, otherwise the server will continue to stream unnecessary data and eventually slow down. Use the simx_opmode_discontinue operation mode for that. Also, if you have enabled data streaming for a specific command (e.g. simxGetJointPosition), then you shouldn't use any other operation mode with that specific command than simx_opmode_buffer or simx_opmode_discontinue, otherwise streaming will be interrupted on the client side (but data still sent on the server side).


    Non-blocking, non-streaming data query: if data needs to be queried in a non-blocking fashion, but not constantly as would data streaming do, one can use following:

    // Request vision sensor data (function returns immediately (non-blocking)): simxGetVisionSensorImage(clientID,sensorHandle,res,&img,0,simx_opmode_oneshot); ... // Check later if some data has arrived (non-blocking): if (simx_return_ok==simxGetVisionSensorImage(clientID,sensorHandle,res,&img,0,simx_opmode_buffer)) { // yes, we have an image! ... }

    stepping (or synchronous) mode: from above function calls you might have noticed that a simulation will advance or progress without taking into account the progress of the legacy remote API client. Legacy remote API function calls will be executed asynchronously by default. There are however situations where the legacy remote API client needs to be synchronized with the simulation progress, by controlling the simulation advance from the legacy remote API client side. This can be achieved by using the stepping mode. The legacy remote API server service needs in that case to be pre-enabled for stepping operation (this can be achieved via the simRemoteApi.start function, or via the continuous remote API server service configuration file remoteApiConnections.txt). Following is an example of the stepping mode:

    simxSynchronous(clientID,true); // Enable the stepping mode (Blocking function call) simxStartSimulation(clientID,simx_opmode_oneshot); // The first simulation step waits for a trigger before being executed simxSynchronousTrigger(clientID); // Trigger next simulation step (Blocking function call) // The first simulation step is now being executed simxSynchronousTrigger(clientID); // Trigger next simulation step (Blocking function call) // The second simulation step is now being executed ...

    Following diagram illustrates the stepping mode:

    [stepping mode]


    When calling simxSynchronousTrigger, the next simulation step will start computing. This doesn't mean that when the function call returns, the next simulation step will have finished computing. For that reason you have to make sure to read the correct data. If no special measure is taken, you might read data from previous simulation step, or from current simulation step, as illustrated in following diagram:

    [stepping mode, uncertain data update]


    You have several possibilities to overcome above problematic situation. The simplest is to call a function in a blocking fashion directly after calling simxSynchronousTrigger:

    simxSynchronous(clientID,true); // Enable the stepping mode (Blocking function call) simxStartSimulation(clientID,simx_opmode_oneshot); // The first simulation step waits for a trigger before being executed simxSynchronousTrigger(clientID); // Trigger next simulation step (Blocking function call) // The first simulation step is now being executed simxGetPingTime(clientID); // After this call, the first simulation step is finished (Blocking function call) // Now we can safely read all streamed values

    Following diagram illustrates above procedure:

    [stepping mode, correct data update]




    Following diagram illustrates how incoming legacy remote API commands are handled on the server side (i.e. on the CoppeliaSim legacy remote API plugin side):

    [Remote API command handling, server side]



    Additional details

    On the client side (i.e. your application), at least 2 threads will be running: the main thread (the one from which you will be calling legacy remote API functions), and the communication thread (the one that will be handling data transfers behind the scenes). There can be as many communication threads (i.e. communication lines) as needed on the client side: make sure to call simxStart for each one of them. The server side, which is implemented with a CoppeliaSim plugin, operates in a similar way. Following figure illustrates the legacy remote API modus operandi:

    [Remote API functionality overview]


    Following describes the various supported modes of operations:

  • simx_opmode_oneshot: non-blocking mode. A command is sent to the server for execution (1)-(b)-(3). A reply to a same command, but previously executed, is returned from a local buffer, if available (i)-(2). The function doesn't wait for a reply from the server (7)-(i). On the server side, the command is stored temporarily (4)-(d), executed once (d)-(9)-(g) and a reply sent back (g)-(6). This mode is often used with "set-functions" (e.g. simxSetJointPosition), where the user doesn't care about the return value.
  • simx_opmode_blocking: blocking mode. A command is sent to the server for execution (1)-(b)-(3), and the function waits for the reply from the server (7)-(i)-(2). The received reply will then be erased from the inbox buffer (i), which doesn't happen with the other operation modes. On the server side, the command is stored temporarily (4)-(d), executed once (d)-(9)-(g) and a reply sent back (g)-(6). This mode is often used with "get-functions" (e.g. simxGetObjectHandle), where the user requires a reply to the sent command.
  • simx_opmode_streaming: non-blocking mode. A command is sent to the server for execution (1)-(b)-(3). A reply to a same command, but previously executed, is returned from a local buffer, if available (i)-(2). The function doesn't wait for a reply from the server (7)-(i). Similar to simx_opmode_oneshot, but with the difference that the command will be stored on the server side (4)-(e), continuously executed (e)-(9)-(g), and continuously sent back to the client (g)-(6). This mode is often used with "get-functions" (e.g. simxGetJointPosition), where the user requires a specific value constantly.
  • simx_opmode_oneshot_split (not recommended): non-blocking mode. A command is sent gradually (in small data chunks) to the server for execution (1)-(a)-(3). A reply to a same command, but previously executed, is returned from a local buffer, if available (i)-(2). The function doesn't wait for a reply from the server (7)-(h)-(i). When the command was fully sent, it is removed from (a). On the server side, the command chunks are remporarily stored (4)-(c) and when the command was fully received, the command will be executed once (5)-(d)-(9)-(f) and a reply gradually sent back to the client (f)-(6). The client receives the reply in small chunks (7)-(h) and when the reply is complete, it is stored in the local buffer (8)-(i). This mode is often used with "set-functions" associated with large amounts of data (e.g. simxSetVisionSensorImage), in order not to overload the communication network.
  • simx_opmode_streaming_split (not recommended): non-blocking mode. A command is sent gradually (in small data chunks) to the server for execution (1)-(a)-(3). A reply to a same command, but previously executed, is returned from a local buffer, if available (i)-(2). The function doesn't wait for a reply from the server (7)-(h)-(i). When the command was fully sent, it is removed from (a). On the server side, the command chunks are remporarily stored (4)-(c) and when the command was fully received (5)-(e), the command will be executed continuously (e)-(9)-(f) and a reply gradually sent back to the client (f)-(6). The client receives the reply in small chunks (7)-(h) and when the reply is complete, it is stored in the local buffer (8)-(i). This mode is often used with "get-functions" associated with large amounts of data (e.g. simxGetVisionSensorImage), where the user requires data constantly without overloading the communication network.
  • simx_opmode_discontinue: non-blocking mode. A command is sent to the server (1)-(b)-(3). A reply to a same command, but previously executed, is returned from a local buffer, if available (i)-(2). The function doesn't wait for a reply from the server (7)-(i). On the server side, the command simply clears a similar command that is located in (e). A reply is sent to the client (6)-(7) that will also clear a similar reply located in (i). This mode is used to release some memory in (i) (similar to simx_opmode_remove), or to interrupt streaming commands (i.e. by removing them from (e)).
  • simx_opmode_buffer: non-blocking mode. No command is sent to the server, but just a reply to a same command, previously executed, is returned from a local buffer, if available (i)-(2). This mode is often used in conjunction with the simx_opmode_streaming or simx_opmode_streaming_split operation mode: first, a constant command execution is started with a streaming command, then only command replies fetched.
  • simx_opmode_remove: non-blocking mode. No command is sent to the server, but just a reply to a same command, previously executed, is cleared from the local buffer, if present (i). The function doesn't return any values, except for a return code. This mode can be used to release some memory on the client side, but is rarely necessary.