This document describes how to use AMQP 1.0 routing keys (tag addresses) to send SECS/GEM commands to equipment and monitor responses. All communication uses an AMQP 1.0 broker; you publish values to request tags and subscribe to response/variable tags to observe results.

Throughout this document, <toolname> refers to the name assigned to the equipment controller (e.g. e300host). All routing keys are lower-case and dot-separated.

Most SECS/GEM operations follow a common three-step pattern:

1. Set parameters — publish values to one or more parameter tags (e.g. an SVID list, a terminal ID, text, etc.)
2. Trigger — publish 1 to the corresponding sendmessage tag
3. Monitor — subscribe to the responsestatus tag and/or the output variable tags to observe results

The responsestatus tag will change to 0 on success. You can seed it with a non-zero value (e.g. 99) before triggering so that the transition to 0 is unambiguous.

Simple (scalar) tags accept plain string values published directly to the routing key. The equipment knows the expected SECS type for each tag and will interpret the string accordingly.

Examples:

• Publishing an integer: just send the numeric string

30508

• Publishing a text string:

Hello from the operator console

• Publishing a binary byte value of 1 (as a raw byte):

\x01

No JSON wrapper is required for simple types.

List-type tags (such as SVID lists) require a JSON object with a “values” array. Do not send a bare JSON array — it must be wrapped in an object.

If every item in the list is the same SECS type, include a “type” field:

{"values": [30503, 30508], "type": 54}

This produces a list of two U8 (type 54) values. If “type” is omitted, each element defaults to ASCII (type 20) strings.

{"values": ["recipe1", "recipe2", "recipe3"]}

Without a “type” field and with simple string elements, each item becomes a SecsFormat20 (ASCII) value.

When list elements have different types, use the value/type object form for each element:

{"values": [
  {"value": "1.2", "type": 34},
  {"value": "Test", "type": 20},
  {"value": "15", "type": 54}
]}

{"values": []}

A list can contain sub-lists by setting the type of an element to 0 (list) and providing a JSON string as the value:

{"values": [
  {"value": "{\"values\": [\"a\", \"b\"], \"type\": 20}", "type": 0},
  {"value": "standalone", "type": 20}
]}

For report data variables, the format uses a “values” array of “dvid”/“dvval” pairs:

{"values": [
  {"dvid": "WaferCount", "dvval": "15"},
  {"dvid": "23456", "dvval": "Hello World"}
]}

Request multiple status variable values in a single S1F3 transaction.

Example — request CLOCK (SVID 30508) and ControlState (SVID 30503):

1. Subscribe to e300host.svrequest.responsestatus
2. Subscribe to e300host.variables.vid.clock
3. Subscribe to e300host.variables.vid.controlstate
4. Publish 99 to e300host.svrequest.responsestatus
5. Publish {“values”: [30503, 30508], “type”: 54} to e300host.svrequest.svidlist
6. Publish 1 to e300host.svrequest.sendmessage
7. Wait for e300host.svrequest.responsestatus to become 0
8. Read the updated values from e300host.variables.vid.clock and e300host.variables.vid.controlstate

Request a single status variable value.

Example — request CLOCK only:

1. Subscribe to e300host.svrequestone.responsestatus
2. Subscribe to e300host.variables.vid.clock
3. Publish 99 to e300host.svrequestone.responsestatus
4. Publish 30508 to e300host.svrequestone.svid
5. Publish 1 to e300host.svrequestone.sendmessage
6. Wait for e300host.svrequestone.responsestatus to become 0
7. Read the updated value from e300host.variables.vid.clock

Send a text message to the equipment's terminal display (S10F3).

Example — display a message on terminal 1:

1. Subscribe to e300host.terminaldisplay.responsestatus
2. Publish 99 to e300host.terminaldisplay.responsestatus
3. Publish byte value 0x01 to e300host.terminaldisplay.tid
4. Publish Hello from the operator to e300host.terminaldisplay.text
5. Publish 1 to e300host.terminaldisplay.sendmessage
6. Wait for e300host.terminaldisplay.responsestatus to become 0

Equipment variables are published to routing keys under <toolname>.variables.vid.<varname>, where <varname> is the lower-case variable name defined in the equipment model (e.g. clock, controlstate).

Subscribe to these tags to receive updated values whenever the equipment reports them — either in response to an SV request or as part of an event report.

When the equipment sends an event report, it is encoded as JSON and published to the event's routing key. The format is:

{"EventName": [
  {"ReportName": [
    {"GasFlow": "1.2", "type": 34},
    {"WaferCount": "15", "type": 54}
  ], "rptid": 109}
], "ceid": 1003, "timestamp": "2025-03-22 14:29:13.306"}

Each report within the event contains a list of named values with their SECS type codes.

Alarm events are published as JSON:

{"alid": 1002, "altx": "Temperature Alarm", "alcd": 2, "action": "set", "timestamp": "2025-03-22 14:29:13.306"}

The “action” field is either “set” (alarm raised) or “clear” (alarm cleared).

Trace data reports follow a similar structure to event reports:

{"TraceName": [
  {"GasFlow": "1.2", "type": 34},
  {"Temperature": "350.5", "type": 40}
], "trid": 5, "timestamp": "2025-03-22 14:30:00.000"}

Tags that are not part of the SECS/GEM protocol (e.g. devices.utilityservers_servers.variable) use plain string publish/subscribe with no special formatting. Publish a string value and any subscriber on that routing key will receive it directly.

Using some small scripts, it's possible to create and send messages and manipulate other properties.

Additional Details