Skip to content
Start free evaluation

SECS-I

SECS-I (SEMI E4) sends SECS-II messages over an RS-232 serial line. It predates HSMS, but plenty of installed equipment still uses it. The line connects exactly two devices. Messages travel as blocks, one at a time, and the receiver acknowledges every block.

Block structure

Section titled “Block structure”

A block is a length byte, a 10-byte header, up to 244 data bytes and a 2-byte checksum (SEMI E4, block format):

+--------+-------------------------------+------------------+----------+
| length | header (10 bytes)             | data (0..244)    | checksum |
| 1 byte |                               |                  | 2 bytes  |
+--------+-------------------------------+------------------+----------+


header byte  1          2           3              4          5          6           7..10
             R-bit +    device ID   W-bit +        function   E-bit +    block no.   system bytes
             device ID  (low 8)     stream                    block no.  (low 8)
             (high 7)                                         (high 7)
  • The length byte counts the header and data bytes, from 10 to 254.
  • The R-bit (reverse bit) gives the direction: 1 means equipment to host, 0 means host to equipment.
  • The E-bit (end bit) marks the last block of a message.
  • Block numbers count up from 1 within a multi-block message.
  • The checksum is the 16-bit sum of all header and data bytes.

A message larger than 244 bytes is split into several blocks. The receiver collects the blocks in order and reassembles the message.

Line control

Section titled “Line control”

SECS-I passes control of the line back and forth with four control characters:

Character Value Meaning
ENQ 05h “I have a block to send.”
EOT 04h “Ready to receive.”
ACK 06h The block arrived intact.
NAK 15h The block was bad.

One block moves like this:

Sender                                Receiver
  |  ------------ ENQ -------------->  |
  |  <----------- EOT ---------------  |   within T2
  |  ---- length, header, data, ---->  |   characters within T1
  |       checksum                     |
  |  <----------- ACK (or NAK) ------  |   within T2
  • If the sender gets a NAK or no answer within T2, it resends the block. After the retry limit (RTY), the send fails.
  • If both sides send ENQ at the same moment, that’s contention. The master keeps sending; the slave backs off and receives first. E4 makes the equipment the master and the host the slave.

Timers

Section titled “Timers”
Timer Name Meaning
T1 Intercharacter timeout The longest gap between characters while a block arrives.
T2 Protocol timeout How long to wait for EOT after ENQ, and for ACK or NAK after a block.
T3 Reply timeout How long to wait for the reply to a W-bit message.
T4 Interblock timeout How long to wait for the next block of a multi-block message.

The PDComm SECS-I endpoint

Section titled “The PDComm SECS-I endpoint”

The PDComm SECS-I endpoint never opens a serial port itself. Your application supplies read and write callbacks, and the endpoint moves bytes through them. That way the same code drives a real COM port, a virtual serial port or an in-memory test line.

  • Callbacks must not block. When there’s nothing to read, return PDCOMM_SECS1_IO_WOULD_BLOCK.
  • Callbacks run synchronously, and only inside poll. Call every endpoint function on the thread that created the endpoint; calling back into the endpoint from a callback returns PDCOMM_INVALID_STATE.
  • Time is a tick value that you pass to poll, and the timer options use the same tick unit. The .NET worker uses milliseconds as ticks.
  • Results arrive as events: a received message (INBOUND), a completed send (OUTBOUND_COMPLETE), a failed send (OUTBOUND_FAILED) and a line fault (FAULT).

The timer fields of PdcommSecs1Options map to the E4 timers as follows:

PDComm field E4 Description
priority Master/slave Decides who backs off on contention (PDCOMM_SECS1_MASTER or PDCOMM_SECS1_SLAVE).
retry_limit RTY How many times a block is resent.
grant_wait_ticks T2 Wait for EOT after sending ENQ.
ack_wait_ticks T2 Wait for ACK or NAK after sending a block, and for the length byte after sending EOT.
inbound_progress_ticks T1 Gap between characters while receiving a block.
inter_block_ticks T4 Gap before the next block of a multi-block message.

The SECS-I endpoint handles block transfer and delivers messages. Your application pairs requests with replies by their system bytes and times the reply timeout (T3) of W-bit messages.

To send, call pdcomm_secs1_submit with the device ID, the direction (PDCOMM_SECS1_TO_HOST or PDCOMM_SECS1_TO_EQUIPMENT), stream, function, W-bit, system bytes and body. A body beyond the size limits (max_outbound_body_bytes, max_body_bytes) or the block limits (max_outbound_blocks, max_blocks) of the options returns PDCOMM_LIMIT_EXCEEDED. E4 tells line control to ignore any byte other than ENQ, EOT, ACK and NAK; PDComm counts such bytes and records them in the optional diagnostics log.

APIs by language

Section titled “APIs by language”
  • C: create the endpoint with pdcomm_secs1_create and drive it with pdcomm_secs1_poll. Creating and starting it need a license for the secs-gem module (Install and check a license).
  • C++: Secs1Endpoint wraps your callbacks type-safely and keeps exceptions from escaping through the C function pointers.
  • .NET: Secs1Worker creates the endpoint on a dedicated thread and runs the poll loop. It offers StartAsync, SubmitAsync, ReadEventsAsync, StopAsync, ResetAsync and DisposeAsync. The worker never opens or closes the serial port. Keep callbacks short, and don’t call worker methods from inside them.

Testing without a serial line

Section titled “Testing without a serial line”

You can exercise SECS-I without any serial hardware:

  • In-memory virtual pair: the simulator connects a host-side (slave) and an equipment-side (master) SECS-I endpoint through an in-memory line. The SECS-I workspace of the GUI simulator, the MCP server and the secs1-virtual-pair scenario of the headless simulator all use it. You can watch block splitting and reassembly and inject line faults without a serial port.
  • Virtual serial ports: when you need a port pair that behaves like real COM ports, use the virtual serial ports in the PDComm tools. Your application opens one like any serial port and reads and writes it from the SECS-I endpoint’s callbacks.

The SECS/GEM guides show how to use the simulator.

Privacy Policy