Configuring Siemens RF310R PC Communication via 3964R Protocol

Configuring Siemens RF310R PC Communication via 3964R Protocol

The Siemens RF310R is a compact industrial RFID reader that supports the proprietary 3964R point-to-point protocol over its serial interface. Many integrators select the RF310R for tag identification on assembly lines, conveyor systems, and tooling tracks, but connecting it directly to a PC for development, diagnostics, or non-PLC host applications requires explicit protocol handling that is rarely consolidated in a single document. This reference gathers the hardware, framing, control-character timing, and host-implementation paths needed to bring an RF310R online from a PC, and it documents the implementation pathways that remain available after the legacy Siemens entry ID 90472232 was retired.

1. System Overview and Topology

The RF310R is part of the SIMATIC RF300 family. The reader exposes an RS422 differential serial port. Because most PCs no longer ship with native RS422, a converter is required. The reference topology is shown below.

The PC side terminates either on a real RS232 COM port or, more commonly, on a USB-to-RS232 bridge (FTDI FT232, CH340, CP210x). The converter then translates the unbalanced RS232 voltages to the RS422 differential pair required by the RF310R's serial port. Use only converters that expose the four RS422 signals (TX+, TX-, RX+, RX-) and support full duplex with independent TX/RX pairs.

2. Prerequisites

1. Hardware
   • Siemens RF310R reader (6GT2801-3BA10 or current variant).
   • At least one RF340T transponder (or compatible RF300 family tag such as RF340T, RF350T, RF360T).
   • 8-pin M12 connector cable (Siemens 6GT2091-4xxxx) or flying-lead variant for the reader's serial port.
   • RS232-to-RS422 converter with full-duplex 4-wire operation. Industrial-grade units (Moxa TCC-80, Phoenix Contact PSI-MODEM-RS422) are recommended over consumer units.
   • PC with USB or RS232 port.
2. Power and Wiring
   • RF310R supply: 24 V DC nominal (range 19.2 V to 28.8 V), current draw approximately 100 mA without antenna load.
   • Wire TX+/TX- and RX+/RX- as a crossover: PC TX pair → RF310R RX pair, PC RX pair ← RF310R TX pair.
   • Common the DC ground between the RF310R supply and the converter supply to ensure a stable 0 V reference.
3. Software
   • Terminal program with hex view (PuTTY, Tera Term, Realterm) for low-level frame debugging.
   • Application language with a serial library: Python + pyserial, C# + System.IO.Ports, or LabVIEW VISA.
   • Optional: SIMATIC S7-1200 Communication Processor Manual — 3964(R) Communication as background protocol reference.

3. RF310R Serial Port Defaults

The RF310R is configured for the 3964R protocol out of the box. Default parameters on the device's RS422 port are:

These defaults are documented in the SIMATIC RF300 system manual. If you change them with a Siemens programming tool, confirm the new values with a configuration read before continuing.

4. 3964R Protocol Reference

The 3964R protocol is a Siemens-defined point-to-point protocol that adds a transparent character-level handshake to a raw UART. It is widely supported by SIMATIC S7 CPUs (S7-300/400 CP340/CP341, S7-1200 CM 1241, S7-1500 CM PtP) and is the same protocol used by many SIMATIC ident devices.

4.1 Control Characters

4.2 Frame Structure

A complete 3964R transmit sequence from initiator (PC) to responder (RF310R) consists of the following byte sequence:

[STX]  [data bytes ...]  [DLE][ETX]  [BCC]
0x02   user payload       0x10 0x03   XOR of all payload bytes (including DLE/ETX)

If any byte in the payload equals DLE (0x10), it must be doubled (inserted as DLE DLE) before transmission to preserve transparency. The receiver discards the duplicate. The BCC is computed over the original payload plus the DLE/ETX terminator.

4.3 Handshake State Machine

4.4 Timing Parameters

5. RF310R Command Set (3964R Payload Layer)

The 3964R envelope wraps a higher-level command/response protocol specific to the RF310R. Each payload sent to the reader is a request, and each received payload is the reply. Typical payload layer operations include presence detection, single-tag read, write, and configuration.

5.1 Request Frame (Host → RF310R)

Byte 0   Length (n-1)        number of remaining bytes
Byte 1   Command code        e.g. 0x01 = Presence, 0x04 = Read UID
Byte 2   Subcommand / param  command-dependent
Byte 3+  Parameters         optional, command-dependent

5.2 Response Frame (RF310R → Host)

Byte 0   Length (n-1)
Byte 1   Status / echo code  0x00 = OK, 0xFF = error
Byte 2+  Payload             tag UID (8 bytes for RF340T), or status bytes

5.3 Worked Example: Read Single Tag UID

Command to request the UID of the single tag currently in the antenna field:

Sample reply on success (RF340T returns 8-byte UID + 2-byte CRC):

02 0A 00 E0 04 12 34 56 78 9A BC DE F1 70 A3
^  ^  ^  ^-- UID (8 bytes) --------------------+  ^  ^  ^-- DLE ETX BCC
|  |  +-- Status OK
|  +-- Length = 11 (1 status + 8 UID + 2 CRC + 1 reserved + 1 byte trailer depending on firmware)
+-- STX

The exact byte count of the trailing portion is firmware-dependent. Always enable a hex trace during bring-up and confirm the trailing bytes against the device manual revision shipped with your RF310R.

6. Hardware Wiring Detail

Wire TX+/TX- from the reader to RX+/RX- on the converter, and RX+/RX- on the reader to TX+/TX- on the converter. If your converter offers a "DTE/DCE" switch, set it so that the converter's TX outputs drive the reader's RX inputs. Always use shielded twisted-pair cable and ground the shield at one end only to avoid ground loops.

7. PC-Side Implementation (Python Reference)

The following skeleton implements a 3964R master in Python using pyserial. It is suitable as a starting point for a host application that controls an RF310R from a PC.

import serial
import time

class Rf3964R:
    STX = 0x02
    ETX = 0x03
    DLE = 0x10
    NAK = 0x15

    def __init__(self, port='COM3', baud=19200):
        self.ser = serial.Serial(
            port=port,
            baudrate=baud,
            bytesize=serial.EIGHTBITS,
            parity=serial.PARITY_EVEN,
            stopbits=serial.STOPBITS_ONE,
            timeout=2.0,   # QAD-style wait for partner DLE
            write_timeout=2.0,
        )

    def _bcc(self, data):
        b = 0
        for byte in data:
            b ^= byte
        return b & 0xFF

    def _escape(self, payload):
        out = bytearray()
        for b in payload:
            out.append(b)
            if b == self.DLE:
                out.append(self.DLE)  # DLE doubling for transparency
        return bytes(out)

    def transact(self, payload):
        escaped = self._escape(payload)
        frame_tail = bytes([self.DLE, self.ETX])
        tail_with_bcc = frame_tail + bytes([self._bcc(escaped + frame_tail)])

        # 1) Send STX and wait for partner DLE
        self.ser.reset_input_buffer()
        self.ser.write(bytes([self.STX]))
        ack = self.ser.read(1)
        if ack != bytes([self.DLE]):
            raise IOError(f"No DLE after STX, got {ack!r}")

        # 2) Send escaped payload + DLE ETX + BCC
        self.ser.write(escaped + tail_with_bcc)

        # 3) Wait for response DLE (block accepted)
        ack = self.ser.read(1)
        if ack == bytes([self.NAK]):
            raise IOError("NAK from partner")
        if ack != bytes([self.DLE]):
            raise IOError(f"Unexpected response ack {ack!r}")

        # 4) Receive reply frame
        # (Simplified: assume partner will now send its own STX-data-DLE-ETX-BCC)
        # Implement full receive state machine for production use.
        return self._receive_frame()

    def _receive_frame(self):
        # Wait for partner STX
        b = self.ser.read(1)
        if b != bytes([self.STX]):
            raise IOError(f"No STX from partner, got {b!r}")
        self.ser.write(bytes([self.DLE]))  # ack STX

        data = bytearray()
        while True:
            ch = self.ser.read(1)
            if not ch:
                raise IOError("Timeout receiving payload")
            c = ch[0]
            if c == self.DLE:
                nxt = self.ser.read(1)
                if nxt == bytes([self.ETX]):
                    break
                elif nxt == bytes([self.DLE]):
                    data.append(self.DLE)
                else:
                    raise IOError(f"Bad DLE sequence {ch + nxt!r}")
            else:
                data.append(c)
        # Read BCC and verify (not shown for brevity)
        return bytes(data)

if __name__ == "__main__":
    rf = Rf3964R('COM3', 19200)
    # Read UID request: 0x04 command, mode 0x01, reserved 0x00
    reply = rf.transact(bytes([0x02, 0x04, 0x01, 0x00]))
    print("Reply bytes:", reply.hex())

This skeleton shows the essential 3964R envelope handling (STX/DLE handshake, DLE transparency, BCC computation, retry/NAK handling). For production, add: configurable retry count (default 6), QWZ enforcement (220 ms between bytes), QBD delay (BCC verification budget), and a thread-safe receive path for unsolicited messages from the reader.

8. Alternative Host Paths

Direct PC-to-RF310R is not the only path. Three alternative architectures are common:

8.1 PC → S7-1200 (CM 1241) → RF310R

The SIMATIC S7-1200 supports 3964(R) over CM 1241 RS232 and CM 1241 RS422/485 modules. The CPU can be programmed to issue 3964R frames to the RF310R and forward the parsed UID over PROFINET or Modbus TCP to the PC. The protocol specifics are documented in the S7-1200 communication manual at SIMATIC S7-1200 Manual — 3964(R) Communication.

8.2 PC → Beckhoff TwinCAT → RF310R

Beckhoff TwinCAT provides the P3964R function block in the TF6340 Serial Communication library. The block handles the 3964R framing and exposes a clean PLC interface. Pair with an EL6001 or EL6021 RS422 terminal to drive the RF310R from a Beckhoff controller, then expose data to a PC via ADS. Reference: Beckhoff Information System — P3964R.

8.3 ControlLogix → MVI56-S3964R → RF310R

For Allen-Bradley ControlLogix sites, ProSoft Technology's MVI56-S3964R in-chassis module acts as a 3964R gateway. It backhauls tag reads to the Logix processor via the backplane and to a PC via EtherNet/IP or OPC. Reference: ProSoft MVI56-S3964R ControlLogix Module.

9. Bring-Up Procedure

1. Power the RF310R with 24 V DC and confirm the green status LED illuminates steady (no error state).
2. Connect the converter's RS422 pair to the reader. Verify polarity with a multimeter before applying power to the converter.
3. Open Realterm or PuTTY at 19200 / 8E1 with no local echo, and confirm that the host transmits the STX/DLE handshake correctly when the user manually sends 0x02 0x10 0x03 from a test buffer.
4. Connect the host application and issue a Presence command. A successful reply contains status 0x00.
5. Place an RF340T in front of the antenna and confirm that a Read UID command returns an 8-byte UID plus 2-byte CRC.
6. Capture a full session with the hex trace and validate against the worked example in section 5.3.

10. Troubleshooting Matrix

11. Verification Checklist

• Hex trace shows STX → partner DLE → escaped payload → DLE ETX → BCC → partner DLE.
• Read UID returns 8-byte UID matching the value printed on the RF340T housing (typically E00401xxxxxxx).
• Round-trip latency at 19200 baud for a single Read UID request is < 50 ms on a quiet RS422 link.
• No BCC errors logged across 1000 consecutive transactions.
• Reader LED transitions from off to steady green within 5 s of 24 V applied.