Configuration Format

• To ensure that user-developed custom plugin packages can be correctly imported into Rokae applications, users must strictly follow the standard format when writing the plugin package and configuration file, and ensure the configuration file name is consistent with the plugin name.

Step 1 Configuration File

• When developing a client plugin, users must strictly follow the standard to create the configuration file (plugin-name.json), and ensure the plugin name is consistent with the name field in the configuration file.

{
    "client_plugin":{
        "name":"plugin1",                     // Plugin name; must be consistent with the plugin file name; required
        "depend":["plugin2","plugin3"],       // Dependent client plugins; optional
        "ctrlDepend":[],                      // Dependent controller plugins; optional
        "enable":false,                       // Enabled state after loading; disabled by default after loading; required     
        "version":"3.0.1",                    // Plugin version; required   
        "min_hmi_version":"3.0.1",            // Minimum supported HMI version (xCore version) (optional)
        "custom_hmi_version":[],              // Custom adaptive versions; optional
        "author":"rokae",                     // Author; optional
        "description":"description"           // Description; optional
    }
}

tip

When copying the configuration file, comments must be removed! JSON files do not support '//' comment markers.

Step 2 Data Package

• Users need to create a data package. The corresponding data archive names must be fixed as client.zip (client plugin) and controller.zip (controller plugin).

/** The plugin package format created by the user must be saved according to this structure **/

client.zip
  ├── plugin1
  |     ├──plugin1.dll
  |     ├──xplugin.dll  
  |     └──plugin1.json    // configuration file
  ├── plugin2
  |     ├──plugin2.so
  |     ├──xplugin.so  
  |     └──plugin2.json    // configuration file
  |
  // Other client plugin packages
    
controller.zip
   ├── plugin1
   |    ├──plugin1.lic
   |    ├──plugin1.so  
   |    └──plugin1.json    // configuration file
   ├── plugin2
   |    ├──plugin2.lic
   |    ├──plugin2.so  
   |    └──plugin2.json    // configuration file
   | 
   // Other controller plugin packages

Step 3 Plugin Package

• After creating the data package, users also need to create a plugin package as follows. Only the plugin package can be directly imported into Rokae's RobotAssert program.

/** Documentation directory structure of the plugin **/
example.zip
├── client.zip
├── controller.zip

tip

Client plugins and controller plugins can each be loaded independently without depending on the other!

At this point, plugin package creation is complete, and you can install and import it into RobotAssert software for use.

Quick Generation with Scripts

• Packaging scripts provided with this documentation can package prepared client / controller directories into an importable plugin package in one step.

Get the Scripts

• Place the following files in the same working directory (at the same level as the client and controller folders):

File	Description
PluginPackage.bat	Packaging script for Windows; double-click to invoke PowerShell packaging
PluginPackage.sh	Packaging script for Linux

Prepare the Directory

• Place files in a flat structure (client-only or controller-only is also fine):

Working directory/
├── client/                 # optional
│   └── plugindemo/
│       ├── plugindemo.dll  # or .so
│       ├── xplugin.dll     # or .so
│       └── plugindemo.json
├── controller/             # optional
│   └── plugindemo/
│       ├── plugindemo.lic
│       ├── plugindemo.so
│       └── plugindemo.json
└── PluginPackage.bat / PluginPackage.sh

Generation Steps

(Taking Windows as an example)

1. Confirm the working directory contains PluginPackage.bat, and client and/or controller.
2. Double-click PluginPackage.bat.
3. Wait for the console to show a completion prompt; the same directory will generate <plugin package>.zip (default: current folder name).
4. Close the window. Import the zip into plugin management to finish.

Output

plugindemo.zip
├── client.zip       # packed from the client/ directory
└── controller.zip   # packed from the controller/ directory

• When only client is present, only client.zip is generated into the outer package.
• When only controller is present, only controller.zip is generated into the outer package.

FAQ

Issue	Solution
Prompt that client/controller cannot be found	Check whether the bat is at the same level as these two folders
Multi-architecture not as expected	Architecture directory names must be aarch64 / amd64 / win (controller has no win)

Example

Taking the plugindemo plugin name, the client plugin and controller plugin collection package created is shown below. plugindemo.zip is the final plugin package to import.

  plugindemo.zip                      // compressed plugin package
  ├── client.zip                      // compressed data package
  |      └── plugindemo               // folder
  |            ├── plugindemo.dll     
  |            ├── xplugin.dll  
  |            └── plugindemo.json    // configuration file
  └── controller.zip                  // compressed data package
         └── plugindemo               // folder
               ├── plugindemo.lic
               ├── plugindemo.so  
               └── plugindemo.json    // configuration file
   

Multi-Architecture Plugin Package Support

• Rokae+ plugins support storing data packages for multiple system architectures in a single plugin package. Users who are familiar with the plugin package structure can configure plugin packages for multiple different system architectures themselves.

In client.zip / controller.zip, create subdirectories by architecture first, then place the same plugin folder structure as for single-architecture:

• Client (client.zip): aarch64, amd64, win
• Controller (controller.zip): aarch64, amd64;

plugindemo.zip
├── client.zip
│   ├── aarch64
│   │   └── plugindemo
│   │       ├── plugindemo.so
│   │       ├── xplugin.so
│   │       └── plugindemo.json
│   ├── amd64
│   │   └── plugindemo
│   │       ├── plugindemo.so
│   │       ├── xplugin.so
│   │       └── plugindemo.json
│   └── win
│       └── plugindemo
│           ├── plugindemo.dll
│           ├── xplugin.dll
│           └── plugindemo.json
└── controller.zip
    ├── aarch64
    │   └── plugindemo
    │       ├── plugindemo.lic
    │       ├── plugindemo.so
    │       └── plugindemo.json
    └── amd64
        └── plugindemo
            ├── plugindemo.lic
            ├── plugindemo.so
            └── plugindemo.json

tip

Multi-architecture plugin packages are supported since plugin 1.0.2.6, with xCore control system v3.2.2 or later.