HSMS Says SELECTED, So Why Does the Equipment Abort Your S1F17 with S1F0?

The host screen says SELECTED. Select.rsp came back in 4 ms and Linktest keeps answering. Then you send S1F17 and get back 01 00 — Stream 1, Function 0 — instead of S1F18. On a less helpful tool you get nothing at all and burn T3. Both symptoms have one cause. The HSMS connection state and the GEM communication state are two separate state machines, and finishing the first does not start the second.

One socket, six requests

I opened a raw socket to the passive listener and played host. Round-trip times are measured host-side.

TX Select.req   00 00 00 0A 00 0B 00 00 00 01 00 00 05 01
RX Select.rsp   00 00 00 0A 00 0B 00 00 00 02 00 00 05 01        (4ms)
   → equipment state: hsmsState SELECTED / commState NOT COMMUNICATING

TX S1F17        00 00 00 0A 00 0B 81 11 00 00 00 00 05 02
RX S1F0         00 00 00 0A 00 0B 01 00 00 00 00 00 05 02        (1ms)

TX S2F13        00 00 00 0C 00 0B 82 0D 00 00 00 00 05 03 01 00
RX S2F0         00 00 00 0A 00 0B 02 00 00 00 00 00 05 03        (17ms)

TX S1F13        00 00 00 1A 00 0B 81 0D 00 00 00 00 05 04
                01 02 41 07 48 4F 53 54 4D 45 53 41 03 32 2E 31
RX S1F14        00 00 00 37 00 0B 01 0E 00 00 00 00 05 04
                01 02 21 01 00 01 02 41 15 56 58 2D 39 30 30 30
                20 50 6C 61 73 6D 61 20 45 74 63 68 65 72 41 0D
                53 45 43 53 47 45 4D 2D 31 2E 34 2E 31           (11ms)
   → equipment state: hsmsState SELECTED / commState COMMUNICATING

TX S1F17        00 00 00 0A 00 0B 81 11 00 00 00 00 05 05
RX S1F18        00 00 00 0D 00 0B 01 12 00 00 00 00 05 05 21 01 00  (2ms)

TX Linktest.req 00 00 00 0A 00 0B 00 00 00 05 00 00 05 06
RX Linktest.rsp 00 00 00 0A 00 0B 00 00 00 06 00 00 05 06        (3ms)

Same S1F17 both times. Only the SystemBytes changed, 05 02 to 05 05. The first was cut off with Function 0; the second got a real S1F18. One thing happened in between: the S1F13 / S1F14 exchange.

Linktest is last on purpose. It has to prove the earlier aborts were not a dead socket. It came back in 3 ms. The socket and the process are fine.

The abort header, byte by byte

Put request and reply side by side and Function 0 stops being mysterious.

TX 00 00 00 0A 00 0B 81 11 00 00 00 00 05 02
                     ^^ ^^                        byte 2 = 81, byte 3 = 11
                     W-bit 1 + Stream 1 / Function 17

RX 00 00 00 0A 00 0B 01 00 00 00 00 00 05 02
                     ^^ ^^                        byte 2 = 01, byte 3 = 00
                     W-bit 0 + Stream 1 / Function 0

The stream is still 1; only the function is 0. SystemBytes 00 00 05 02 is echoed unchanged. The length is 10 — header only, no body. S2F13 got the same shape back: 02 00, Stream 2 Function 0.

In SECS-II (SEMI E5), Function 0 means the transaction is being discarded. It is not a reject code. It carries no reason. So when the host log shows only S1F0, the cause is not in the bytes — it is in the state. There is a whole article on this one pattern: the communication gate that answers S1F0 first.

The cleared W-bit matters too. It is a reply, so it demands no answer of its own. The opposite bug — sending a request with W-bit clear and then waiting for a reply — is in header byte 2.

What S1F14 actually returned

01 02                 L[2]
  21 01 00            B[1] 0x00        ← COMMACK = 0, accepted
  01 02               L[2]
    41 15 56 58 ...   A[21] 'VX-9000 Plasma Etcher'   ← MDLN
    41 0D 53 45 ...   A[13] 'SECSGEM-1.4.1'           ← SOFTREV

Two format codes are enough to read it. 21 is Binary, one length byte; 41 is ASCII with the following byte as the length — 41 15 is 21 bytes. Item header length bytes covers that arithmetic properly.

COMMACK 0 is accept. Anything else is a refusal, but the per-value meanings have to come from the E30 table and the equipment manual — I have no capture of a non-zero COMMACK from real equipment. This listener always returns 0.

The moment S1F14 arrived, the equipment's commState moved from NOT COMMUNICATING to COMMUNICATING. That is where a host may light up "online". Not at Select.rsp.

Two state machines

SEMI E37 (HSMS-SS) governs the connection. It starts at NOT CONNECTED, becomes CONNECTED when TCP comes up, and reaches SELECTED only when Select completes. Data messages (SType 0) may flow only in SELECTED. That is the whole of E37's responsibility.

SEMI E30 (GEM) keeps its communication state above that. It separates whether the equipment permits communication at all (DISABLED / ENABLED) from whether it is actually communicating with a host (NOT COMMUNICATING / COMMUNICATING). The key from NOT COMMUNICATING to COMMUNICATING is the S1F13 / S1F14 exchange, and before it no data message other than S1F13 gets through. The S1F17 and S2F13 coming back as Function 0 above is that gate.

So SELECTED tells you only that the socket and the session are open. An MES screen that paints SELECTED as "online" shows a green light for equipment that has not established communication. Send S2F41 in that state, get S2F0 back, and the operator reports that the command was swallowed.

No reply and SxF0 are different events to a host

One cause, two shapes on the host side.

Equipment behaviour	What the host sees	Cost
Aborts with SxF0	transaction fails immediately	one round trip (1–17 ms here)
No reply at all	T3 expiry	the T3 value — E37 default 45 s

E37's parameter table gives T3 (Reply Timeout) a 45 s default with a 1–120 s range. And SxF0 is a legitimate reply under E5, so receiving it stops T3 on the spot. The equipment that aborts is being far kinder to you. The host stacks that collapse both into one "S1F17 failed" log line are where the half hour goes. Telling the timers apart is in which HSMS timeout actually fired.

What this capture does not prove

This listener always answers a data message. So the capture shows the gate's abort path only; the total silence that is common on real equipment cannot be produced with this tool. Reproducing that would need the equipment to drop S1F13 on the floor, and that behaviour is not available here.

I also have no S1F14 with a non-zero COMMACK. The refusal path is outside this capture.

Three things it does prove: the bytes crossed a real socket and landed in the equipment-side RX log; a data message sent before S1F13 is cut off with Function 0 even in SELECTED; and one S1F14 is enough to let the identical request through.

Host-side checklist

Do not treat SELECTED as established communication. Online is a decision you make after reading COMMACK in S1F14.
Log the fact that you received an SxF0. Function 0 is closer to "refused" than to "timed out". Print them as two different lines.
Do not retry S1F13 on the T3 period forever. GEM puts a separate delay on establish-communication retries, and that delay is often exposed as an equipment constant. Get the name and value from the equipment manual.
A passing Linktest proves the link and nothing else. Wire only that to a monitor screen and a session that never finished Select shows green too.
Read the equipment-side RX log first. If the bytes never arrived, this is a framing problem, not a GEM problem.

The worst time sink is elsewhere: a host stack that logs "T3 timeout" without saying which message died. A dead S1F13 and a dead S6F11 are completely different events, and the log cannot tell you which one you had.

Reproduce it

The capture came from opening a raw socket to the passive listener of the SECS/GEM simulator. Order is the whole trick — send any data message before S1F13 and check whether byte 3 of the reply is 00. If it is, stop reading bytes. It is the gate.