**Integration Guide for TransSECS OPCUA and OPCDA Servers**

----

**Starting the OPCUA or OPCDA Server**

Use the run.bat or run.sh file generated for the server deployment. This will start a command shell or terminal.

**Tag Names**

The OPCUA or OPCDA server will generate tags prefaced by your toolname. For the examples in this guide the tool name is "GEMTool". The tags will be grouped into .vids, .ceids, .alids, and .messagenames. Within the .vids will be each vid (svid or ecid) by .name. For each alid and ceid, there will be an enable (not usually used except for testing) and a trigger.

**Set the SVIDs OnlineOfflineState and LocalRemoteState to "true" (enabled) for testing.**

Use your OPCUA or OPCDA Client to set both of these vids to "true" so that the test Host may connect to the tool for testing. These VIDs are normally set with a hardware or software (GUI) switch or button on the tool. 

**Triggering Messages**

SECS messages are sent to the host by first setting the data values in the message, if any, then setting the sendmessage tag of the outgoing message to a non-zero value. Before sending the message set the "responsestatus" tag to a value > 10. This response status value will change after the message is triggered to a value reflecting the success of the sent message. A "0" indicates success. Other values indicate an error.

JSON is used to format the list elements of a message, for example, a list of recipe names for an S7F20 message. These will all be strings in a JSON format. Per the JSON standard, all keys should be quoted, as you will see in the examples below. 

For example, S7F20 for the recipe list, if you have defined the message with an empty list you will see a hint in the OPCUA Server.  The OPC Tag corresponding to the recipe list will look something like:

<code javascript>
{ "values": [ ] }
</code>

in your OPCUA or OPCDA client you will make a string  of the recipe names in this format and write it to the tag for this list.

For example, it might look like:

<code javascript>
{ "values": [ "recipe1","recipe2", "recipe3", "recipe4"] }
</code>

then send the message as usual using the trigger data item.

There are more things you can do with the JSON format for the lists, including making lists of lists and specifying the SECS format for the data in the list. See the JSON Hints below.

**Receiving Messages**

When a message is received the data values from the incoming message will appear in the message tags. If you have defined a Host Message generically with an empty parameter list, the received list data can be parsed as a JSON string to get the host command parameters.

**ECID value updates**

When the host sends an S2F15 message with a ECID value changes, the tag corresponding to the ecidname (that you defined in TransSECS) will be automatically updated with the value.  The ECID tags are in the toolname.vids branch.

**Important Note On Initial Values of ECIDs**

When the OPCUA or OPCDA server starts up these values will not have been initialized by the client or host yet, and they will all be "0" and bad quality. Make sure that when your Client reads these values that you only accept quality "good" data to update your client. As soon as your Client writes an initial value to the server the quality will become good, or if the host writes new values in an S2F15 message the quality will also be good.

**Updating SVIDs**

The OPCUA Client should update the SVID data values in the toolname.vids tags.

**Triggering Alarms (ALIDs)**

Use the boolean "trigger" data item for the toolname.alids.alidname to trigger an alarm. The alarm will not be sent to the host unless the host has enabled the alarm. The ALCD and Enabled tags for the alarm are exposed in the OPC Server but should not be used by the Client except for testing purposes.

**Triggering Events (CEIDs)**

SECS Events are triggered by setting the <file>toolname.ceids.eventname.trigger</file> value with a String. The event will only be sent from the tool if the host has enabled this event. The enabled tag is exposed but should not be set by the Client except for testing purposes.

For a simple CEID, without using DVIDs, the event is triggered by an empty string value (or a string containing only spaces). If the CEID was defined with DVIDs, the string should contain a JSON formatted list of DVID values, for example:

<code javascript>
{  "values":[
    { "dvid":"WaferCount", "dvval":"15"  },
    { "dvid":"ProcessProgram",  "dvval":"25SecDip"  }
 ] }
</code>

More JSON Hints

Some reference notes on JSON as it applies to TransSECS (SECS formats and list structures)

If a specific type is required, it can be specified if needed. For example for the recipe list, the data is ASCII, type 20:
<code javascript>
 { "values": [ "recipe1","recipe2", "recipe3", "recipe4"], "type":"20" }
</code>

type is per the SECS Standard:

  * 00 - List
  * 10 - Binary (can be an array)
  * 11 - Boolean
  * 20 - String
  * 30 - 8 byte floating point
  * 34 - 4 byte floating point
  * 40, 41, 42, 44 - 8, 1,2,4 byte signed integers
  * 50, 51, 52, 54 - 4 byte signed integer

 each element of the array can have a different type in this format (might be useful in some message replies with different data types):

<code javascript>
 {"values":[
      {"value":"1.2", "type":"34"},
      {"value":"Test", "type":"20"},
      {"value":["5","6","7","8"], "type":"10"},
      {"value":"1", "type":"10"}
   ]
 }
</code>

Events can be triggered with a list of DVVALS if DVIDs have been associated with the event. To do this you can define the list, then use this as the trigger input to the CEID. If you are using DVVALs in your tool project you would associate the DVVALS when you define your CEID (you may have noticed this list if you have DVVALS, this is a recent change to TransSECS).

Example of DVVALS as a JSON String sent to the trigger of a CEID:

<code javascript>
{  "values":[
    { "dvid":"WaferCount", "dvval":"15"  },
    { "dvid":"23456",  "dvval":"Hello World"  }
 ] }
</code>
Another note:
You can specify any VID with either its name (for example WaferCount), or its vid number (for example 23456) as the above example demonstrates.

Example, Host Command

If you publish the whole of the data from a host command, the structure is a list (with the host command), then the list elements for the parameters for the command.

It may look something like:
<code javascript>

 { "values": [  { "value":"PP-SELECT", "type":"20" } } { "values": [  { "values": [ "LOTID" ] , "type":"20" } { "values": [  { "value":"CHAMBER", "type":"20 } } { "value":"1", "type":"51" } } ]  } { "values": [ "PPID" ] , type:"20" } ]  } ]  }
</code>

Host commands received from the host are order independent, that is, the OPC Tag corresponding to the parameter name will be updated with the correct value regardless of the position in the message from the host.

**Equipment TransSECS/GEM IDs**

Refer to the section: [[TransSECS VIDs]]