Siemens CP 440 RS 485: Resolving EXT/INT LED and F008 Errors

1. Problem Statement

An S7-400 station with a Siemens CP 440 communication processor fails to exchange ASCII data over RS 485 with a third-party slave — in this case an MKS mass flow controller. The slave has been independently verified with a USB-to-RS 485 adapter on a laptop using a terminal emulator; the request/response frames match the MKS manual. After loading the standard Siemens example project for ASCII communication on the CP 440, the following symptoms persist on every transmission attempt:

• CP 440 front-panel LEDs SF, INTF (Internal Fault), and EXTF (External Fault) are all lit.
• The CPU diagnostic buffer logs a module-related entry containing the identifier F008.
• The ASCII send function block returns ERROR = TRUE with STATUS = 0008h.
• The CP 440 RX/TX LED never flashes; no character ever leaves the X27 port.

The combination of lit fault LEDs and a STATUS of 0008h is a fingerprint of a missing or untransferred CP 440 parameterization SDB, not of an actual line or protocol fault. The remainder of this article documents the field-verified root cause and the corrective procedure for the CP 440 in an RS 485 multipoint topology with third-party ASCII slaves.

2. CP 440 Hardware Reference

The CP 440 is a single-port serial communication processor for the SIMATIC S7-400. The relevant hardware characteristics for an RS 485 ASCII link to a mass flow controller are summarized below. Source: CP 440 Installation and Parameter Assignment Manual.

The CP 440 differs from the CP 441 (modular, two ports, plug-in interface submodules) and from the CP 341 (S7-300 platform). Confirm the catalog entry in HW Config matches the order number printed on the module front panel; a one-digit mismatch causes HW Config to download an incompatible GSD, after which the module refuses all parameterization SDBs.

3. LED and Diagnostic Buffer Interpretation

The CP 440 front panel has four status LEDs. Their collective state is the fastest first-pass diagnostic:

The diagnostic buffer entry F008 against the CP 440 slot is consistent with a missing or rejected parameter SDB. The STATUS value 0008h returned by the ASCII send FB on a freshly booted CP is the standard "job accepted, no error" return code; it does NOT by itself indicate healthy operation. When STATUS = 0008h occurs simultaneously with INTF and EXTF lit, the FB has accepted the request into its internal queue, but the CP has no valid ASCII frame to transmit and rejects the job at the firmware layer.

4. Root Cause Analysis

Three concurrent defects are typically present in a CP 440 station that exhibits the symptom set above:

4.1 CP 440 parameterization SDB not downloaded

The CP 440 stores its protocol parameters (baud rate, parity, data bits, stop bits, end delimiter, handshake, receiver enable timing, RS 422/485 mode, termination behavior, etc.) inside a system data block (SDB) that lives in the SDB container managed by SIMATIC Manager. The SDB is generated when the engineer opens the CP 440 properties dialog in HW Config and fills in the ASCII driver parameters.

The SDB is part of the HW Config download. It is NOT distributed via NetPro. NetPro only handles S7 connection configuration; it has no mechanism to push CP parameterization SDBs. If the engineer follows the Siemens example project but only triggers a NetPro download (or only downloads the user program blocks), the SDB never reaches the CPU, the CP 440 powers up with default parameters (typically 9600 8N1, no handshake, RS 422), and the configured ASCII frame is rejected.

4.2 REQ input not edge-triggered

The CP 440 ASCII send FB (the parameterized block generated for the project, not a generic FB number) is edge-triggered on its REQ input: a rising edge (FALSE → TRUE) launches one transmission. Holding REQ = TRUE continuously causes only the first command to leave the CP 440. All subsequent commands are silently discarded because the FB has no new edge to react to. Engineers accustomed to level-triggered sends see a "the slave never replies" symptom and assume a wiring or protocol problem when in fact the CP 440 has already transmitted the first frame once and ignored every later call.

4.3 RS 485 physical-layer termination or biasing fault

RS 485 is a transmission standard, not a protocol. The bus requires 120 Ω termination at both physical ends and fail-safe biasing (a pull-up on the non-inverting line and a pull-down on the inverting line) at one node, typically the master. If the MKS mass flow controller sits mid-bus without termination, or if the CP 440 end lacks biasing, the bus floats when idle and the receiver inside the CP 440 sees spurious characters that the firmware logs as framing errors — which light EXTF even when no intentional traffic has been sent. Multipoint cabling mistakes are the most common source of a stubborn EXTF after the SDB is corrected.

5. Resolution Procedure

Address the three root causes in this order: SDB first, REQ second, physical layer third. Each step is independently verifiable.

5.1 Download the CP 440 parameterization SDB

1. Open the STEP 7 project in SIMATIC Manager.
2. Open HW Config (double-click "Hardware" under the S7-400 station).
3. Locate the CP 440 in the rack — its slot is given by the diagnostic buffer entry.
4. Double-click the CP 440 → Properties → Parameters (or the protocol-specific tab, depending on the firmware version of the catalog entry).
5. Configure the ASCII driver to match the MKS manual: target baud rate (commonly 9600 or 19200), 8 data bits, parity (none, even, or odd as specified), stop bits (1 or 2 as specified), end-of-frame delimiter (CR, LF, or CR+LF), no hardware handshake, RS 485 2-wire mode for a half-duplex link, receiver enable timing matching the device's silent interval.
6. Save and compile: Station → Save and Compile.
7. Select the S7-400 CPU in the rack, right-click → "Download to Target" → "Hardware Configuration" (not "S7 Connections").
8. After the download completes, open the CPU online → Diagnostic Buffer and confirm a "Parameter download to CP 440 OK" entry.

5.2 Correct the REQ edge handling

Ladder logic pattern for OB1 / OB35 / OB40 cycle calls:

A   M    100.0      // "Send Now" operator command (pushbutton or HMI flag)
FP  M    100.1      // positive-edge flag, MUST be a static (retain or non-retain) bit
=   DB100.DBX  0.0  // REQ input of the CP 440 ASCII send FB

Structured Text pattern (IEC 61131-3 ST):

IF bSendNow THEN
    bSendEdge := NOT bSendEdge;   // toggle on each call
ELSE
    bSendEdge := FALSE;
END_IF;
bReq := bSendEdge;                // REQ sees one rising edge per command

Each operator command produces exactly one rising edge on REQ, which causes the FB to enqueue one transmission. The next transmission requires a new FALSE → TRUE transition on REQ.

5.3 RS 485 bus termination and biasing

1. Identify the two physical ends of the RS 485 bus.
2. Enable the 120 Ω termination resistor at both end nodes. On the CP 440 this is typically a DIP switch or a software option inside the parameter dialog (depending on the firmware); on the MKS mass flow controller it is usually a DIP switch or a jumper on the RS 485 board.
3. Install fail-safe biasing at one node — most reliably the master (CP 440 side) — using a 680 Ω pull-up to +5 V on the non-inverting line and a 680 Ω pull-down to GND on the inverting line. Some Siemens CP 440 versions provide internal biasing via a parameter flag.
4. Use twisted-pair cable, shield grounded at one end only (typically the cabinet end), keep the shield continuous through any intermediate junction boxes.
5. Verify A/B polarity. On Siemens the X27 pinout is documented in the manual; on the MKS device the lines are commonly labeled A (or D+) and B (or D-). Inverted polarity is invisible until the bus is exercised and then produces all-framing-error traffic with EXTF lit.

5.4 Match the ASCII frame to the MKS device

Cross-check the frame against the MKS manual. Typical MKS / Brooks MFC ASCII request frame structure:

STX  ADDR  CMD  DATA  ETX  BCC
 02    31   30   ...   03  XX

• STX (0x02) and ETX (0x03) are common MFC delimiters; some devices use ':' (0x3A) start-of-frame as in Modbus ASCII.
• ADDR is the slave address byte, often an ASCII numeral ('1' = 0x31) for slaves numbered 1–9.
• CMD is the read/set command code as documented in the MFC manual.
• BCC is the block-check character — XOR of all bytes between STX and ETX, or a two-character hex checksum, depending on the device generation.

Configure the CP 440 ASCII driver with the exact character frame, end delimiter, and (if the MFC supports it) the start delimiter. A single mismatch on parity, stop bits, or delimiter selection causes EXTF to light on the first outbound byte.

6. Verification

After executing section 5.1 through 5.4 in order, perform the following checks:

1. Cycle power on the S7-400 station. Confirm SF, INTF, and EXTF are OFF within 5 seconds of CPU RUN.
2. Toggle REQ from FALSE to TRUE on the send FB.
3. Observe STATUS = 0000h (job complete, no error) and DONE = TRUE within the configured FB monitor timeout (typically 1–5 s for short MFC replies).
4. Confirm the RX/TX LED on the CP 440 flashes green during frame exchange.
5. Confirm the receive DB contains the expected ASCII response string from the MFC.
6. Confirm no new CP 440 error entry has been appended to the CPU diagnostic buffer.

If STATUS returns 0008h repeatedly with LEDs still lit, the parameter SDB has not been loaded correctly. Repeat section 5.1 and confirm with the CPU diagnostic buffer that the parameter download event is present and timestamped after the latest configuration change.

7. ASCII Driver STATUS Code Reference

The exact STATUS values are firmware-version dependent; refer to the manual bundled with the specific CP 440 catalog entry installed in HW Config.

8. Common Pitfalls When Integrating Third-Party ASCII Slaves

1. MFC silent interval: Mass flow controllers typically need 50–200 ms of silent bus time before they respond. Set the CP 440 receiver enable / silent interval parameter to at least 50 ms greater than the device's worst-case response time.
2. Address byte format: Some MFC generations expect a hex address byte (0x01), others expect an ASCII numeral (0x31). The CP 440 sends raw bytes; the engineer must format the address byte in the user program to match the device manual.
3. RS 485 direction control: In 2-wire RS 485 mode the CP 440 handles transmit/receive direction internally. Do NOT enable RTS-based hardware flow control on the MFC side; an RTS-forced receive state will leave the bus in listen mode and the CP 440 will see no reply.
4. Duplicate slave addresses: On a multipoint bus each slave must have a unique address. Two devices with the same address cause permanent bus collision, intermittent EXTF, and corrupted responses that pass framing checks but fail checksum.
5. GSD vs. order number: A wrong catalog entry in the HW Config hardware catalog (e.g., selecting a CP 440 variant that does not exist in your firmware range) downloads an incompatible GSD. The CP 440 boots, accepts the SDB, but the parameter layout is offset and the ASCII frame is wrong from the first byte. Always match the catalog entry to the order number printed on the module.
6. Diagnostic buffer on the CP only: Operators often read only the CP 440's diagnostic buffer. CPU-to-CP errors never appear there. Always read the CPU diagnostic buffer AND the FB STATUS output.

9. Extended Diagnostic Procedure (If Symptoms Persist)

1. Loopback test: Disconnect the MKS device and install a loopback plug on X27 that ties TX+ to RX+ and TX- to RX- with 120 Ω termination. Send a known string from the CP 440. If STATUS = 0000h and DONE = TRUE, the CP and its parameterization are confirmed correct; the problem is in the wiring or the slave.
2. Bus sniffer: Connect a USB-to-RS 485 adapter to a laptop running a serial analyzer (raw mode, hex view). Compare the captured frames against the expected MKS request. Mismatched baud rate or inverted A/B polarity is the most common cause of an otherwise-correct configuration failing on real traffic.
3. Module swap: Replace the CP 440 with a known-good spare of the same order number. If the spare boots clean, the original module has a hardware fault on the RS 485 transceiver that masquerades as a parameterization problem because INTF and EXTF both light and the diagnostic buffer reports F008-equivalent events.
4. Firmware consistency: Confirm the CP 440 firmware version is compatible with the STEP 7 version that owns the project. Mismatched firmware and STEP 7 catalog data cause SDB acceptance with silent parameter corruption. The CP 440 firmware version is shown in the module's diagnostic buffer under "Module identification".
5. NetPro versus HW Config: If the project has only one PLC and no S7 connections to other stations, NetPro is irrelevant to the CP 440. Skip the NetPro download entirely; perform HW Config download only.

10. Related Siemens Communication Processors

Engineers familiar with other Siemens serial modules sometimes confuse catalog entries. The CP 440 is the S7-400 single-port module; alternatives and successors include:

If the application grows beyond a single ASCII master and a handful of slaves — for example multiple MFCs on a multipoint bus with Modbus RTU/ASCII — consider the CP 441-2 with the Modbus master loadable driver. The diagnostic flow and SDB handling are similar but the parameterization surface is larger. Reference: CP 440 in a multipoint topology with RS 422/485 protocols.

11. FAQ