# SOPAS The SOPAS protocol enables communication with sensor devices from SICK AG ([http://www.sick.com](http://www.sick.com/)). ## Overview SICK sensors use the SOPAS (Sensor Operating Program for Advanced Sensors) command language, which utilizes command strings called telegrams. SOPAS supports two protocol formats: * **CoLa A (Command Language A)**: ASCII telegram format * **CoLa B**: Binary telegram format (not covered in this documentation) While the terms SOPAS and CoLa are often used interchangeably, Connectware sends SOPAS commands using the CoLa A protocol format. ## Example Device: SICK RFU620 The examples in this documentation use the [SICK RFU620](https://www.sick.com/de/en/identification-solutions/rfid/rfu62x/c/g285253) RFID reader. RFID (Radio Frequency Identification) enables reading from and writing to small RFID tags using radio frequencies. The RFU620 supports only the CoLa A protocol format. Different SICK sensors may support CoLa A only, CoLa B only, or both formats. **Note**: SICK's configuration software [SOPAS ET](https://www.sick.com/de/en/catalog/products/digital-services-and-software/engineering-tools/c/g584669) also uses the SOPAS protocol. You can monitor telegrams using its integrated terminal emulator and obtain additional documentation from SICK's website or by request. ## Understanding SOPAS Commands To integrate a SICK device, you need the following information: ### 1. Interface Type SOPAS commands are categorized into three interface types: | Interface Type | Description | Operations | | -------------- | ------------------------------------------------------ | ---------- | | **Events** | Provide asynchronous messages when subscribed to | Subscribe | | **Methods** | Execute functions on the device when called | Call/Write | | **Variables** | Store configuration values that can be read or written | Read/Write | ### 2. Command Name Each event, method, or variable has a unique string identifier used for addressing. ### 3. Parameters Methods and variable writes may require specific parameters. ## Command Structure SOPAS commands follow a specific format. Here is an example from the RFU620: {% code lineNumbers="true" %} ``` sMN TAreadTagData +0 0 0 0 0 1 ``` {% endcode %} ### Command Types The first part of the command string indicates the operation type: | Command | Description | Interface Type | | ------- | ------------------ | -------------- | | `sRN` | Read | Variable | | `sWN` | Write | Variable | | `sMN` | Method call | Method | | `sEN` | Event subscription | Event | In the example above: * `sMN`: Method call using naming scheme * `TAreadTagData`: Command name for reading RFID tag data * Remaining values: Space-separated parameters ## RFU620 Command Reference | Command Name | Type | Parameters | Description | | --------------- | -------- | ----------- | ----------------------------- | | `QSinv` | Event | None | Inventory notifications | | `MIStartIn` | Method | None | Start inventory process | | `MIStopIn` | Method | None | Stop inventory process | | `QSIsRn` | Variable | None | Check if inventory is running | | `HMISetFbLight` | Method | color, mode | Control feedback light | ## Endpoint Configuration Each [Cybus::Endpoint](https://docs.cybus.io/2-0-6/documentation/services/service-commissioning-files/resources/cybus-endpoint) requires protocol and connection definitions. Reference your connection using `!ref` and the connection name. ### Available Operations The available operations depend on the interface type: | Type | Operation | Result | | -------- | ----------- | ------------------------------------------ | | event | `read` | n/a | | | `write` | n/a | | | `subscribe` | Subscribes to asynchronous messages | | method | `read` | n/a | | | `write` | Calls a method | | | `subscribe` | Subscribes to method’s answers | | variable | `read` | Requests the actual value of the variable | | | `write` | Writes a value to the variable | | | `subscribe` | Subscribes to the results of read-requests | ### Example Endpoint Mapping Based on the RFU620 commands: * **inventory**: Subscribes to `QSinv` event messages * **inventoryStart**: Calls `MIStartIn` method * **inventoryStop**: Calls `MIStopIn` method * **inventoryCheck**: Reads `QSIsRn` variable * **inventoryRunning**: Subscribes to `QSIsRn` responses * **feedbackLight**: Calls `HMISetFbLight` method For detailed configuration options, see: * [Connection Properties](https://docs.cybus.io/2-0-6/documentation/industry-protocol-details/sopas/sopasconnection) * [Endpoint Properties](https://docs.cybus.io/2-0-6/documentation/industry-protocol-details/sopas/sopasendpoint) ## Service Commissioning File Example {% file src="" %} {% code title="sopas-example.yml" lineNumbers="true" %} ```yaml --- # ----------------------------------------------------------------------------# # Commissioning File # ----------------------------------------------------------------------------# # Copyright: Cybus GmbH (2020) # Contact: support@cybus.io # ----------------------------------------------------------------------------# # Source Interface Definition - SOPAS - RFU620, SICK AG # ----------------------------------------------------------------------------# description: > Sample commissioning file for SICK SOPAS protocol connectivity and data mapping metadata: name: SOPAS Protocol Connectivity icon: https://www.cybus.io/wp-content/uploads/2017/10/for-whom1.svg provider: cybus homepage: https://www.cybus.io version: 0.0.1 parameters: IP_Address: description: IP address of the SICK device type: string default: 192.168.10.10 Port_Number: description: Port on the SICK device. Usually 2111 (sometimes 2112). type: number default: 2112 initialReconnectDelay: type: integer default: 1000 maxReconnectDelay: type: integer default: 30000 factorReconnectDelay: type: integer default: 2 resources: sopasConnection: type: Cybus::Connection properties: protocol: Sopas connection: host: !ref IP_Address port: !ref Port_Number connectionStrategy: initialDelay: !ref initialReconnectDelay maxDelay: !ref maxReconnectDelay incrementFactor: !ref factorReconnectDelay inventory: type: Cybus::Endpoint properties: protocol: Sopas connection: !ref sopasConnection subscribe: name: QSinv type: event inventoryStart: type: Cybus::Endpoint properties: protocol: Sopas connection: !ref sopasConnection write: name: MIStartIn type: method inventoryStop: type: Cybus::Endpoint properties: protocol: Sopas connection: !ref sopasConnection write: name: MIStopIn type: method inventoryCheck: type: Cybus::Endpoint properties: protocol: Sopas connection: !ref sopasConnection read: name: QSIsRn type: variable inventoryRunning: type: Cybus::Endpoint properties: protocol: Sopas connection: !ref sopasConnection subscribe: name: QSIsRn type: variable feedbackLight: type: Cybus::Endpoint properties: protocol: Sopas connection: !ref sopasConnection write: name: HMISetFbLight type: method mapping: type: Cybus::Mapping properties: mappings: - subscribe: endpoint: !ref inventory publish: topic: !sub '${Cybus::MqttRoot}/inventory' - subscribe: topic: !sub '${Cybus::MqttRoot}/inventory/start' publish: endpoint: !ref inventoryStart - subscribe: topic: !sub '${Cybus::MqttRoot}/inventory/stop' publish: endpoint: !ref inventoryStop - subscribe: topic: !sub '${Cybus::MqttRoot}/inventory/check' publish: endpoint: !ref inventoryCheck - subscribe: endpoint: !ref inventoryRunning publish: topic: !sub '${Cybus::MqttRoot}/inventory/running' - subscribe: topic: !sub '${Cybus::MqttRoot}/light' publish: endpoint: !ref feedbackLight ``` {% endcode %} ## Communication Examples After deploying the commissioning file, you can monitor the connection in the [Data Explorer](https://docs.cybus.io/2-0-6/documentation/monitoring/data-explorer). Navigate to the tree structure of your datapoints and activate the live view by hovering over entries and selecting the eye icon. ### Sending Commands #### Starting/Stopping Inventory * **Start**: Send an empty message to the **inventoryStart** endpoint * **Stop**: Send an empty message to the **inventoryStop** endpoint Use the MQTT topic with appropriate suffixes: * **Read operations**: Add `/req` suffix * **Write operations**: Add `/set` suffix #### Method Parameters For methods requiring input arguments, provide them as a JSON string in the message payload. Multiple values should be space-separated: `"value1 value2 value3"`. ### Response Format Responses are published to MQTT topics with a `/res` suffix in JSON format: {% code lineNumbers="true" %} ```json { "timestamp": 1581949802832, "value": "sSN QSinv 1 0 8 *noread* 0 0 0 0 0 AC" } ``` {% endcode %} #### No RFID Tags Detected When no tags are present, the inventory message shows a "no read" situation. #### RFID Tags Detected When tags are recognized, the response contains detailed tag information: {% code lineNumbers="true" %} ```json { "timestamp": 1581950481059, "value": "sSN QSinv 2 E 34 0 E2 0 20 64 81 18 1 20 15 70 71 75 D Non-EPCglobal 0 FFCB 0 0 0 1 E 30 0 E2 0 20 64 81 18 1 21 27 0 8 D6 D Non-EPCglobal 0 FFD0 0 0 0 1" } ``` {% endcode %} #### Variable Responses Variable read responses are typically straightforward. For example, checking inventory status: {% code lineNumbers="true" %} ```json { "timestamp": 1581950874186, "value": "sRA QSIsRn 1" } ``` {% endcode %} This shows: * `sRA`: Read answer * `QSIsRn`: Variable name * `1`: Value (1 = running, 0 = stopped) ## Summary The SOPAS protocol provides communication with SICK sensor devices using SOPAS commands over the CoLa A telegram format. While this documentation demonstrates integration with the RFU620 RFID reader, the same principles apply to other SICK devices. {% hint style="info" %} Connectware transmits raw SOPAS messages with space-separated parameters. Applications must implement their own parsing logic for device-specific message interpretation, as SOPAS responses vary significantly between different SICK devices. {% endhint %}