TransSECS Message Matching
TransSECS will attempt to match all incoming messages against known messages. As soon as a match is found, not further matching is performed and the data is published and any notifications associated with the message are executed.
If no match is found, if a message of the given stream exists in TransSECS then an S9F5 message will be generated. If the stream is unknown, an S9F3 message will be generated.
Whenever TransSECS receives a message is will first check to see if any of the messages match a known GEM standard message. This matching is described in the links below for tools and hosts.
If the message does not match any of the GEM message TransSECS will attempt to match the incoming message against the messages your defined in the project tree.
Messages marked as “Out Messages”
will not be checked for an incoming match.
The search occurs in the order you defined the messages. Here the first message checked will be the S1F4 message (the S1F3 message is marked as an “Out Message”) and the last the S6F20 message.
The first check is to match the stream and function of the incoming message against the defined message. An incoming message with a different stream and function will not match the TransSECS message.
If the stream and functions match, TransSECS will examine the structure of the message. The structure must match exactly. For example, the OnlineAck message:
must have exactly one element that is a binary type. If the exact type is unknown, the “ANY” type may be used. I this case the element must exist, but the type of the element is not checked. The SVIDResponse message uses an “ANY” type.
When an element of a message is a list, the length of the list is not checked by default. For example, the RequestedEventMessage:
Starts with a list. That list must contain two U4's and a List. However, additional elements of that list will not prevent the message matching. The same is true of the final zero-length list <L [0]> . When received, this list is likely to be non-zero length with variable parameters that can be parsed programmatically or in scripts. Even though those parameter are not listed in TransSECS, and the incoming message has a list that is not zero-length, the message will be matched.
More precise message matching
There are, infrequently, cases where messages with similar structures should be identified differently.
The most commonly used feature in this case is the “Key” field.
When the “Key” property is checked, the element at that location in the incoming message must exactly match the element defined in the “Default Value” field of TransSECS. In this case:
the CEID in the incoming “RequestedEventMessage” must be 7502. Any CEID value other than 7502 will prevent TransSECS from matching this message and matching will again be attempted at the next message in the tree.
Similar to a “Key”, the default list-length matching behavior can be changed by selecting the “Match Exact List Length” option on the list editor node:
If selected, TransSECS will not match the list unless the incoming list exactly matches the list defined in the TransSECS message.
Somewhat common is to rely on the order of the message matching in TransSECS to match a “default” message after all more-precise messages have been matched. Messages are ordered either by stream/function/alphabetical or alphabetically. In this case, create a message that starts with a Z_ and it will be moved to the last element of the matched list and so matched last.
Type Length and Fixed Length
The “Type Length”/“Fixed Length” property are not strictly part of the message matching logic. These properties apply only to values being sent. If “Type Length” is unchecked, then the value will be sent with the length provided in the “Fixed Length” box. Two common uses are old tools that require string fields to be padded to some length and sending zero-length values -particularly IDs.
Remote Command Messages
For a tool interface, there is the option for special handling of S2F41 and S2F49 - remote or host command messages.
To enable this special handling, check the “Remote Command” checkbox. The “Command” field should be marked as a key in almost all cases.
When enabled, the message will be matched regardless of the order of the parameters. In the example, if the PPID CPName is first and the LOTID second, the message will match. The published data will match the CPName and not the location in the message. All the CPNames must exist for the message to be matched. There must not be unknown CPNames.
If the “Send Err Msg” box is checked, if the “Key” field matches, or there is no “Key” field but the rest of the match fails, TransSECS will automatically return an S2F42 with an error description. If there is only one message with a given “Key” the “Send Err Msg” button should be checked on that message. If there are multiple messages with the same Key, the last message in the tree should have the “Send Err Msg” checked. It's also possible to add “Default” S2F41 messages that do not have a key to force particular errors. Make sure that they are the last S2F41 message and that the “Send Err Msg” box is checked.
Ensure that the “Remote Command” and “Send Err Msg” check boxes are checked for your S2F41 and S2F49 message.
These checkboxes will only be available for valid S2F41/F49 messages. If you message is an S2F41 or S2F49 and these options are not available, check that the format of the messages is valid.
The first check is that the command is valid. For example, in this case, there are no S2F41 messages matching “START1”.
S2F41 W <L[2]
<A 'START1'>
<L[1]
<L[2]
<A 'PPID'>
<A 'something'>
>
>
> .
RECEIVED: 2020.06.05 15:24:33.386
S2F42 <L[2]
<B 0x1> /* Decimal[1]: 1 */
<L[0]
>
> .
Next the CPName/CPVal pairs are checked
SENT: 2020.06.05 15:27:31.854
S2F41 W <L[2]
<A 'START'>
<L[1]
<L[2]
<A 'PPID1'>
<A 'something'>
>
>
> .
RECEIVED: 2020.06.05 15:27:36.589
S2F42 <L[2]
<B 0x3> /* Decimal[1]: 3 */
<L[2]
<L[2]
<A 'PPID1'>
<B 0x1> /* Decimal[1]: 1 */
>
<L[2]
<A 'PPID'>
<B 0x4> /* Decimal[1]: 4 */
>
>
> .
This error indicates that the CPName “PPID1” was found in the message from the host but not in any message at the tool and that the CPName “PPID” was expected and not found in the message from the host.
The order of the CPName/CPVal lists is unimportant. TransSECS will match them in any order:
SENT: 2020.06.05 15:40:56.908
S2F41 W <L[2]
<A 'PP-SELECT'>
<L[2]
<L[2]
<A 'PPID'>
<A 'RecipeName'>
>
<L[2]
<A 'LOTID'>
<A 'LOTIDxxxxxx'>
>
>
> .
RECEIVED: 2020.06.05 15:40:56.918
S2F42 <L[2]
<B 0x0> /* Decimal[1]: 0 */
<L[0]
>
> .
SENT: 2020.06.05 15:41:01.292
S2F41 W <L[2]
<A 'PP-SELECT'>
<L[2]
<L[2]
<A 'LOTID'>
<A 'LOTIDxxxxxx'>
>
<L[2]
<A 'PPID'>
<A 'RecipeName'>
>
>
> .
RECEIVED: 2020.06.05 15:41:01.307
S2F42 <L[2]
<B 0x0> /* Decimal[1]: 0 */
<L[0]
>
> .
Advanced Message Matching
It is unusual to need the TransSECS advanced message matching features. In programmatic usage it's often easier to publish the list of values and hand-parse the values. In other environments, parsing the generated JSON can be more convenient.
However, on rare occasions the “Repeat” and “Optional” fields can be used to match a message that is not in a consistent format.
In this simple example, we send a request for the list of ECIDs. The response is a message containing lists of values - one list for each ECID.
S2F30 <L[10]
<L[6]
<U4 2000>
<A 'SetPoint'>
<U4 50>
<U4 400>
<U4 50>
<A ''>
>
<L[6]
<U4 33007>
<A 'TimeFormat'>
<U4[0] 0>
<U4[0] 0>
<U4 16>
<A ''>
>
<L[6]
<U4 33009>
<A 'EstablishCommunicationsTimeout'>
<U4[0] 0>
<U4[0] 0>
<U4 0>
<A ''>
>
<L[6]
<U4 33012>
<A 'EnableSpooling'>
<U4[0] 0>
<U4[0] 0>
<U4 0>
<A ''>
>
<L[6]
<U4 33013>
<A 'MaxSpoolTransmit'>
<U4[0] 0>
<U4[0] 0>
<U4 5>
<A ''>
>
<L[6]
<U4 33014>
<A 'MaxSpoolSize'>
<U4[0] 0>
<U4[0] 0>
<U4 100>
<A ''>
>
<L[6]
<U4 33015>
<A 'OverWriteSpool'>
<U4[0] 0>
<U4[0] 0>
<U4 0>
<A ''>
>
<L[6]
<U4 33018>
<A 'S5F1ReplyBit'>
<U4[0] 0>
<U4[0] 0>
<U4 1>
<A ''>
>
<L[6]
<U4 33019>
<A 'EventReportsReplyBit'>
<U4[0] 0>
<U4[0] 0>
<U4 1>
<A ''>
>
<L[6]
<U4 33020>
<A 'EventReportFunction'>
<U4[0] 0>
<U4[0] 0>
<U4 11>
<A ''>
>
> .
We can define the message in TransSECS as a single list of 6 elements and give a meaningful name to each element.
We then enter the maximum number of lists we might ever expect in the “Repeat” box. On a real tool, the number of ECIDs may exceed 20 and so 200 or 2000 might be a better choice. To avoid having to populate this field with the exact number of ECIDs on the tool, we also check the “Optional” box. This means the message will match with any number of repeated lists less than or equal to the maximum number of Repeats we specified. Mark the list as “Publish”.
When the S2F30 message is received, the list, and the contents of the list, will be Published repeatedly - in this case, once for each ECID. In all cases, the contents of the list will be published first and the list itself will be published last. You can register for notification of the list value changing and be sure that all the list values will be populated on that notification. For example, in an OPC factory automation application you could add a notification script to the “ECIDList” tag and read the values of the ECID, ECIDName, etc. tags in that script. Programmatic examples are provided in the appropriate sections.
Another likely use for Repeat and Optional is when the tool may return a list that contains values for “up to” the maximum number of wafers in a cassette. If the tool can process cassettes of up to 25 wafers, it may report 25 values on a full cassette but only report 10 values if the cassette had only 10 wafers.
The use cases really are few and far between, so double check that you haven't missed a more obvious option before proceeding - checking matching with Repeat and Optional can be tricky.