Resolving CP341 NMEA 0183 GPS Missing First 13 Bytes on S7-300

Overview

Receiving NMEA 0183 GPS sentences on a Siemens CP341 communication module connected to an S7-300 PLC (CPU 315-2DP) is a common field requirement for time synchronization, fleet tracking, and position logging. When the receive path is built around FB7 (P_RCV_RK) with the ASCII driver and <CR>/<LF> as message terminators, an intermittent symptom appears in which the first 13 bytes of the leading $GPRMC sentence are truncated, while the trailing payload and the eleven subsequent sentences arrive intact.

This article documents the hardware, the FB7 parameterization, the NDR/ERROR diagnostics that must be observed, and the deterministic root-cause path that eliminates the dropped leading bytes. It also covers a parallel architecture using twelve DBs indexed by a counter, and a comparison path that uses an ET200S 1SI with FB2.

Problem Details

Hardware and Software Configuration

Refer to the CP 341 Point-to-Point Communication manual (PDF) for the canonical parameter list. The key fields that govern this case are:

The FB7 (P_RCV_RK) interface, as shipped in the Siemens sample project zXX21_01_PtP_Com_CP34X, supplies the receive interface to the CPU. Relevant FB7 inputs for the diagnostic path:

• EN – enable; cyclically TRUE in OB1.
• REQ – request new receive job.
• R – reset of the receive job.
• LADDR – I/O base address of the CP341 (e.g., 256).
• DB_NO – destination data block for the received frame.
• DBB_NO – byte offset inside the destination DB.
• L_TYP – frame length storage location.
• L_NO – word offset of frame length inside the DB.

Relevant outputs:

• NDR (DB45.DBX 0.4) – new data received, single-cycle TRUE.
• ERROR / STATUS – diagnostic flags. Both must be evaluated every cycle.

Root Cause Analysis

The repeatable loss of the leading 13 bytes of $GPRMC is not a CP341 silicon defect; it is a synchronization mismatch between the start of the GPS burst and the first CP341 receive job triggered by FB7. Three plausible contributors must be distinguished before a fix is selected.

Candidate 1: FB7 issued before any character has arrived

If FB7 is started in OB1 with a fixed-cycle rate (e.g., OB1 scan time of ~10 ms) and the GPS receiver emits its 12-sentence burst once per second, the very first FB7 invocation after power-up typically finds the CP341 receive buffer empty. CP341 will return without raising NDR. On the next FB7 call, the first 13 bytes of $GPRMC,... are already buffered inside the CP341's UART FIFO. The ASCII driver treats them as part of the current receive job, but the CP341 ring-buffer pointer logic paired with the FB7 L_NO offset has been observed to discard characters that arrived before the FB7 job started when the start-of-text flag is latched but the delimiter flag was already set by a stray idle-line interpretation of an earlier boot string.

Candidate 2: Spurious early <CR> recognition

Garmin eTrex boot messages and some firmware revisions emit short strings (for example, firmware announcement lines beginning with $P) that may contain <CR> or <LF> bytes that the CP341 ASCII driver interprets as end-of-message markers. If such a string is received between FB7 jobs, the internal CP341 state machine believes a previous message terminated early, and the first 13 bytes of the next legal $GPRMC line are attributed to the previous (incorrectly terminated) message.

Candidate 3: Buffer overrun between sentences 12 and 1

NMEA 0183 sentences are emitted in a single burst every 1 Hz. Between bursts the line is idle for hundreds of milliseconds. If the application counter logic that switches DB_NO (see NMEA Sentence Handling Architecture below) overruns the CP341 ring buffer, the first sentence of the next burst can be truncated to the remainder of the previous job. This matches the observation that the missing bytes are exactly 13 – the CP341 FIFO size minus the trailing <CR><LF> already consumed.

Diagnostic Procedure

1. Connect a PC running a serial terminal (HyperTerminal, Tera Term, or PuTTY) to the GPS receiver directly. Confirm 12 sentences per second at 4800 bps 8N1, each terminated by <CR><LF>.
2. Use a serial tap or a Y-cable with a line monitor to capture the bytes the CP341 actually sees. Compare against the direct capture. If the direct capture contains the first 13 bytes of $GPRMC but the CP341 capture does not, the truncation is inside the CP341/FB7 path.
3. Expose STATUS and ERROR of FB7 in VAT. STATUS = 0000h on success; non-zero values indicate CP341 internal diagnostics. The common STATUS values for the CP341 ASCII driver are listed in the CP 341 manual, Section 6.
4. Add COUNT_NDR and COUNT_ERROR counters and read them online. If COUNT_NDR rises exactly 12 per burst and COUNT_ERROR stays at 0, the receive path is healthy and the truncation is a buffer-management issue.
5. Add a watchdog timestamp in OB1 and log the OB1 cycle at each NDR rising edge. If the first NDR after a 1-second idle gap carries a stale OB1 cycle counter, the FB7 job began before the GPS burst arrived.

Solution

The fix is twofold: (a) gate FB7 so it only issues a receive job when the CP341 has flagged data ready, and (b) use a small state machine to drop the first burst after power-up, which is the one most affected by cold-start desynchronization.

Solution A: Gate FB7 on CP341 status flags

Read the CP341 status word (input area at LADDR) and call FB7 only when the receive buffer not empty flag is set. This is the canonical pattern documented for the ASCII driver and prevents FB7 from issuing a receive job against an empty buffer. A simplified skeleton in STL:

A   IW [LADDR]      // CP341 status word
A   "CP341_RDY_RCV"  // bit assigned in HW Config
JC  CALL_FB7
BEU

CALL_FB7: CALL FB7, DB45
         REQ   :=TRUE
         R     :=FALSE
         LADDR :="CP341_ADDR"
         DB_NO :=#curDB
         DBB_NO:=0
         L_TYP :='B'
         L_NO  :=2
         NDR   :="cp341_ndr"
         ERROR :="cp341_err"
         STATUS:="cp341_status"

Solution B: Discard the cold-start burst

Force a CP341 reset (set R TRUE for one cycle after power-up) and ignore the first NDR sequence. Add a BURST_VALID flag that becomes TRUE only on the second burst after power-up. This eliminates the cold-start race because by the second burst the CP341 internal ring buffer and the FB7 receive pointer are aligned.

Solution C: Suppress stray delimiter interpretation

If the diagnostic tap shows stray <CR> or <LF> bytes from the GPS boot string, configure the CP341 ASCII driver to use only <LF> (0x0A) as the end-of-message delimiter, not <CR><LF>. NMEA 0183 sentences are always terminated by <CR><LF>, so a single-byte <LF> delimiter is sufficient and immune to the trailing <CR> that some boot strings emit on its own line.

NMEA Sentence Handling Architecture

The original site implementation uses 12 destination data blocks (DB51–DB62), one per NMEA sentence type. A counter C3 holds the currently active destination DB number. C3 is incremented on every NDR rising edge (DB45.DBX 0.4) and reset to C#51 when the inter-sentence gap (measured by a 100 ms tick counter C4) exceeds 8, which corresponds to the typical 1-second NMEA burst interval.

The implementation in STL:

// NDR rising edge -> advance slot
A   DB45.DBX 0.4
CU  C3
R   C4

// 100 ms tick -> accumulate idle gap
A   M0.0
CU  C4

// If gap > 800 ms -> wrap to first sentence slot
L   C4
L   8
>I
L   C#51
S   C3

// Mirror to FB7 DB_NO
A   DB45.DBX 0.4
L   C3
T   DB45.DBW 2

Verification

1. Force a CP341 reset and observe VAT BURST_VALID. It must rise after the first full 1-Hz burst is received and discarded.
2. Watch DB51 in VAT or with a table view during a burst. The first 6 characters of DB51 must read $GPRMC in ASCII.
3. Confirm STATUS remains 0000h for the full 12-sentence burst.
4. Confirm COUNT_NDR advances exactly 12 per burst and COUNT_ERROR stays at 0 over a 10-minute observation window.
5. Capture the GPS burst with a serial tap and compare byte-for-byte against DB51–DB62 contents.

Alternative Architecture: ET200S 1SI with FB2

The Siemens Support entry referenced in the source (Siemens entry ID 22865909) demonstrates a CP341-class receive using an ET200S 1SI serial interface module (6ES7 138-4DF01-0AB0) and the FB2 (P_RCV) block. The architectural differences relevant to the missing-bytes symptom:

For sites that already operate the S7-300 on PROFIBUS and need a distributed GPS receiver per station, the ET200S 1SI path with FB2 is more deterministic and avoids the cold-start 13-byte loss because PROFIBUS DP startup does not begin transmitting application data until the slave is in data exchange, by which time the GPS burst has already been framed.

Robustness Considerations and Field Notes

• Baud-rate mismatch: some Garmin eTrex firmware revisions reconfigure to 9600 bps after cold start. Verify the receiver stays at 4800 bps 8N1; CP341 will report STATUS = 0E01h (framing error) under rate mismatch.
• Cable length: RS232 is specified to 15 m. For an outdoor GPS antenna mount, use a short RS232 pigtail and a longer RS422 segment with the 6ES7 341-1CH0x-0AE0 CP341 variant.
• Checksum validation: every NMEA 0183 sentence ends with *hh followed by <CR><LF>. Add a CRC16-XOR checksum check on the received string inside the destination DB before using the data.
• Modbus coexistence: if the same CP341 is later re-tasked as a Modbus slave using MODB_341, the ASCII driver must be replaced by the MODB_341 driver. The two drivers are not co-resident on the same CP341 firmware image.

Summary of Recommended Fixes