Reading a GEM Report on Demand: S6F19, S6F15, and the S6F0 You Get Instead

A host that drops and reconnects does not know the tool's current values. Waiting for the next S6F11 works, except the equipment decides when that event fires. It may not fire again until the lot on the tool finishes. So you go looking for a message that reads a report right now, and SECS-II has two of them: S6F19 names one RPTID, S6F15 names one CEID. I sent both. Both came back S6F0. The communication gate was open before either went out.

The capture

A socket opened directly against the simulator's passive listener. A socket, not the API — the equipment side has to log an RX or the frame was never on the wire.

TX Select.req   00 00 00 0A 00 0B 00 00 00 01 00 00 00 01
RX Select.rsp   00 00 00 0A 00 0B 00 00 00 02 00 00 00 01

Select Status is byte 3, 00. The session went SELECTED.

TX S1F13 W      00 00 00 0C 00 0B 81 0D 00 00 00 00 00 02 01 00
RX S1F14        00 00 00 37 00 0B 01 0E 00 00 00 00 00 02 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

This pair is the premise of the whole article. 21 01 00 is B[1] 0 — COMMACK 0. E30's communication gate opened and commState went to COMMUNICATING. Nothing below is the gate's fault. The behaviour where a closed gate turns every data message into an SxF0 is its own article.

TX S6F19 W      00 00 00 10 00 0B 86 13 00 00 00 00 00 03 B1 04 00 00 00 64
RX S6F0         00 00 00 0A 00 0B 06 00 00 00 00 00 00 03

Byte 2 is 86 — top bit the W-bit, the rest Stream 6. Byte 3 is 13 = 19. The body B1 04 00 00 00 64 is a single item: the top six bits of B1 are 44, which is U4, the bottom two say one length byte, and that byte 04 gives four bytes of payload. RPTID 100.

The answer is 14 bytes of header and nothing else. Byte 2 06 is Stream 6 with the W-bit cleared, byte 3 is 00 — function 0. In E5 a function 0 aborts the transaction. The SystemBytes 00 00 00 03 are the request's own, handed straight back.

TX S6F15 W      00 00 00 10 00 0B 86 0F 00 00 00 00 00 04 B1 04 00 00 04 4E
RX S6F0         00 00 00 0A 00 0B 06 00 00 00 00 00 00 04

0F is 15 and the body is U4 00 00 04 4E = CEID 1102. Same S6F0.

That second one matters more than the first. CEID 1102 is an event this tool really has — Process Complete, present in its own event list. RPTID 100, by contrast, is a number I never defined anywhere. An ID that exists and an ID that does not drew the identical answer. So this S6F0 does not mean "no such ID". It is a refusal of the function itself.

TX S1F3 W       00 00 00 12 00 0B 81 03 00 00 00 00 00 05 01 01 B1 04 00 00 00 65
RX S1F4         00 00 00 34 00 0B 01 04 00 00 00 00 00 05 01 04
                41 07 45 78 65 63 75 74 65
                81 08 40 50 5B 85 1E B8 51 EC
                81 08 40 1D F5 C2 8F 5C 28 F6
                41 09 45 54 43 48 5F 42 41 53 45

Same socket, same session, 2 ms later. This one answers. 01 01 B1 04 00 00 00 65 is L,1 { U4 101 } — one SVID asked for. What came back is 01 04, four elements. 41 07 is a 7-byte ASCII Execute; 81 08 is an 8-byte F8, and 40 50 5B 85 1E B8 51 EC is IEEE 754 double 65.43, with 7.49 after it. The last item is ASCII ETCH_BASE.

One asked for, four returned. This listener does not resolve the SVID list and just hands over every variable it holds, which the S1F11 article covers. Here the S1F4 proves exactly one thing: the socket is fine and the gate is open.

An S6F0 is not a missing reply

Put those two in the same bucket in host code and your diagnostics stop working.

In the capture above, the millisecond the S6F19 was written is the millisecond the S6F0 was logged. Nothing waited on T3 — 45 seconds by default in E37, and the timers have their own article. A host log line reading "S6F19 failed" erases the difference. Record that function 0 came back, in those words.

So what do you do after a reconnect

Design as if S6F19 is not there. Reading a report as a report is closed off, which leaves the host expanding it by hand.

• The RPTID-to-VID mapping is yours already. The host is the side that pushed the definition down with S2F33, so that table belongs in the host's own store — not something to ask the tool for. The ordering trap in pushing those definitions is in the S2F33/S2F35/S2F37 article.
• On recovery, expand that table into a VID list and send S1F3. The answer is a run of values, not a report, and re-grouping it into report shape is the host's job.
• Values read with S1F3 carry no sample time. They are current values, not the "values as of this event" that an S6F11 hands you. Mixing the two skews a trace.
• If you do intend to use S6F19, fire one at the tool on the first day it is on the network, not during integration test, and write down the answer. An S6F0 there is where the design forks.

What I did not verify

Nothing about the body shape of S6F16 or S6F20 was verified here. No body ever came back, so there were no bytes to read. If you have to work against the item structure E5 defines for those two, read the copy on your desk.

Whether E30 makes S6F15 and S6F19 required capabilities or optional ones I also did not check against the document. All I confirmed is that this listener does not implement them.

And this is one listener's behaviour. Equipment exists that answers S6F20 properly, and against that tool the design above is merely the safer one rather than the necessary one. Build the recovery path on S6F19, though, and a single tool that replies S6F0 deletes the whole path.

Every frame above was exchanged over a socket opened against the passive listener in the public SECS/GEM simulator. Send one S6F19 from your own driver and you will see immediately whether your host stack surfaces function 0 as an error or as a timeout. That is the part worth finding out.