CP343-1 Advanced S7 Communication on PLCSIM: Troubleshooting

Problem Summary

A project containing two CPU 314C-2 DP stations (6ES7 314-6CH04-0AB0, firmware V1.0) each fitted with a CP 343-1 Advanced (6GK7 343-1GX30-0XE0, firmware V1.0) is configured in STEP 7 V5.5 with NetPro. The user is trying to commission and verify the S7 connection between the two CPUs entirely inside S7-PLCSIM V5.4 SP4 using FB8/FB9 (USEND/URCV), FB12/FB13 (BSEND/BRCV), or FB14/FB15 (GET/PUT) to mirror output word AW 124 in PLC #1 onto input word EW 124 in PLC #2, and vice versa. After two weeks of effort the connection will not establish and the status word of the S7 blocks returns communication errors. The original FC5/FC6 path was abandoned because S7-PLCSIM does not support the FC5/FC6 AG_SEND/AG_RECV path; switching to the FB family did not solve the problem. The blocks are correct - the simulation target is wrong.

Hardware and Software Identification

Pin down the exact catalog numbers and firmware versions before you touch the project. PLCSIM behavior is version-sensitive, and the CP 343-1 Advanced has several firmware revisions with different feature sets.

PLCSIM V5.4 Architecture and What It Actually Emulates

S7-PLCSIM V5.4 SP4 is a Win32 application that loads a STEP 7 V5.5 project, instantiates a virtual CPU of the type selected in the SIMATIC Manager, and runs the user program cycle-accurate. The virtual CPU exposes a subset of the real CPU's hardware:

• User program execution (OB1, OB35, OB82, OB86, OB100, OB121, OB122, etc.).
• Process image of inputs and outputs (PII / PIQ).
• Bit memory, timers, counters, data blocks.
• Integrated MPI/DP interface of the CPU - if the CPU has one. This means PROFIBUS DP master or slave operation with the SIMATIC Manager's "PLCSIM (MPI)" or "PLCSIM (PROFIBUS)" interface assignment.
• Integrated PROFINET interface of the CPU - but only on CPUs that have an integrated PN port (e.g., 6ES7 31x-2 x x 14-0AB0 and later with PN/DP suffix). The 314C-2 DP is not one of them.

PLCSIM does not emulate:

• The CP 343-1, CP 343-1 Advanced, CP 343-1 Lean, or any other external CP module.
• Any Ethernet port that physically sits on a CP, even though the CP appears in the hardware catalog inside the SIMATIC Manager.
• Web server, FTP, e-mail, OPC UA server functions of the CP.

That is why NetPro accepts the S7 connection, HW Config accepts the CP 343-1 Advanced, the project downloads cleanly into PLCSIM, OB1 runs, and the connection still never establishes: the S7 communication blocks FB8/FB9/FB12/FB13/FB14/FB15 are issuing AG_SEND/AG_RECV-style calls against an interface that the simulated CPU does not have. The CP - which would normally own the Ethernet stack - is not there.

Why FC5/FC6 Fail and Why FB8/FB9, FB12/FB13, FB14/FB15 Are the Right Family

FC5 (AG_SEND) and FC6 (AG_RECV) are the legacy "AG" blocks designed for the CP 343-1 and CP 443-1. They run over the configured connection in NetPro, and they exist in the Standard Library under Communication Blocks > SIMATIC_NET_CP. PLCSIM V5.4 does not implement the AG_SEND/AG_RECV kernel interface that FC5/FC6 calls; the blocks return STATUS = 8183h ("job pending - no CP found") or STATUS = 80A1h ("connection aborted by CP"). This is the symptom the user originally hit.

The newer "I" / "S7" / "Modbus" block families - FB8 USEND, FB9 URCV, FB12 BSEND, FB13 BRCV, FB14 GET, FB15 PUT, FB7 PUT, FB8 GET - are documented in the Siemens manual entry SIMATIC S7-300/400 - S7 Communication (entry ID 18516182). They cover the same S7 transport but use the S7 communication layer that the CPU/CP exposes through a different kernel interface. They will not magically make PLCSIM emulate the CP either - they just route through a different (and better documented) call surface, so the code you write here is the code that will run on the real CP once you switch from PLCSIM to real hardware.

All three pairs have a multi-instance capable background DB. Create a separate instance DB per connection (e.g., DB14 for GET to connection ID 1, DB15 for PUT, DB12 for BSEND, DB13 for BRCV) so the S7-300's limited work memory and connection resources are not mixed.

Root Cause: PLCSIM Does Not Emulate the CP 343-1 Advanced

Once the FB8/FB9/FB12/FB13/FB14/FB15 path is in place, the actual fault is not in the program - it is in the test bench. The S7-PLCSIM V5.4 help system and the S7 Communication manual are explicit: the simulated CPU owns only the integrated interfaces declared in HW Config. Modules inserted in slots 4 to 11 of the virtual rack are present in the configuration database so the program can compile, but they are not powered up and not bound to any I/O. S7-PLCSIM is also documented in the product list (entry ID 109750994) which states the same constraint. NetPro still lets you draw a connection that terminates on a CP that is not running, which is why the configuration accepts the project and the download succeeds. The connection never reaches "established" because the CP that would own it does not exist inside the simulator.

S7 Communication Fundamentals: ISO-on-TCP, Port 102, and TSAPs

The CP 343-1 Advanced defaults to ISO-on-TCP (RFC 1006) on TCP port 102 for S7 communication. The transport selector is encoded in a 2-byte TSAP (Transport Service Access Point). Both ends must be configured with matching local and remote TSAPs, and the connection ID in NetPro must be the same on both sides of the same connection.

The CP 343-1 Advanced supports up to 16 S7 connections; the maximum is enforced at firmware level and reported by the CP if exceeded (STATUS = 80A2h "resource shortage"). Connection resources of the CPU itself are separate: a CPU 314C-2 DP allows up to 8 communication connections (S7/HMI/PG/OP) in total, and each configured S7 connection in NetPro consumes one of those slots.

NetPro Connection Configuration

Configure the S7 connection once for each direction. STEP 7 V5.5 will mirror the partner automatically when both stations live in the same S7 project with the "PC internal" or "Ethernet" interface.

1. Open NetPro, right-click the CP 343-1 Advanced in PLC #1, choose Insert New Connection > S7 connection.
2. In the wizard, pick the partner station PLC #2, set the local ID (e.g., 1) and leave "Active connection establishment" checked.
3. Open the connection properties. Verify the local TSAP is 01.01 and the remote TSAP resolves to 01.01 on the partner CP.
4. Confirm that the displayed "Connection name" ends with the local connection ID, and that the partner's connection has the mirrored ID.
5. Save, compile NetPro, and download HW Config + NetPro to both PLCs (or to both PLCSIM instances in your test setup).

Bidirectional Mirror with FB12 BSEND / FB13 BRCV

BSEND/BRCV is the cleanest pattern for the AW 124 ↔ EW 124 requirement. The sender's output word is part of the process image that OB1 updates at the end of each cycle, so the data the sender reads from P#Q 124.0 is always consistent with the program's last write of AW 124. The receiver cannot write directly into its own I area, so it stores the data in a DB and a separate OB1 segment moves it into EW 124 with a BLKMOV or direct L/ST pair.

PLC #1 (sender of AW 124 -> PLC #2's DB):

// OB1 - PLC #1
CALL "BSEND" , DB12          // multi-instance DB12 for connection ID 1
  REQ   :=M 0.0              // rising edge triggers send
  R     :=M 0.1              // abort request
  ID    :=W#16#1             // connection ID from NetPro
  R_ID  :=W#16#A1            // any 16-bit marker; must match R_ID on receiver
  DONE  :=M 10.0             // 1 cycle pulse on success
  ERROR :=M 10.1
  STATUS:=MW 12
  SD_1  :=P#Q 124.0 WORD 1   // source: output word AW 124
  LEN   :=MW 14              // length in bytes; here always 2

PLC #2 (receiver, stores in DB and mirrors to EW 124):

// OB1 - PLC #2
CALL "BRCV" , DB13           // multi-instance DB13 for connection ID 2
  EN_R  :=TRUE               // always ready to receive
  R     :=M 0.0              // abort request
  ID    :=W#16#2             // connection ID 2 (PLC #2 side)
  R_ID  :=W#16#A1            // must match sender's R_ID
  NDR   :=M 10.0             // new data received (one cycle pulse)
  ERROR :=M 10.1
  STATUS:=MW 12
  RD_1  :=P#DB20.DBX 0.0 WORD 1   // destination: DB20.DBW0
  LEN   :=MW 14              // bytes actually received

// After BRCV returns NDR=1, mirror the DB into the process image
L     DBW 20                 // not valid - correct form:
L     DB20.DBW 0             // load received word
T     EW 124                 // write into input image of the cycle

Repeat the pair on PLC #2 (BSEND with SD_1 := P#Q 124.0 WORD 1) and PLC #1 (BRCV with RD_1 := P#DB20.DBX 0.0 WORD 1, then T EW 124) to close the reverse direction. Two R_ID values (e.g., 0xA1 and 0xA2) keep the two directions independent.

PUT/GET Pattern with FB14 / FB15

PUT/GET is the simpler choice when you do not need to write the partner's output and read the partner's input symmetrically, and when both sides expose the data through a DB or a marker area. PUT and GET each take four area pointers and four data pointers, so you can pack up to four disjoint ranges per call.

PLC #1 calls FB15 PUT to copy its AW 124 into a DB on PLC #2:

CALL "PUT" , DB15
  REQ   :=M 0.0
  ID    :=W#16#1
  DONE  :=M 10.0
  ERROR :=M 10.1
  STATUS:=MW 12
  ADDR_1:=P#DB20.DBX 0.0 WORD 1  // remote address on PLC #2
  ADDR_2:=P#M 100.0 BYTE 0       // unused - leave zero length
  ADDR_3:=P#M 100.0 BYTE 0
  ADDR_4:=P#M 100.0 BYTE 0
  SD_1  :=P#Q 124.0 WORD 1       // local source: AW 124
  SD_2  :=P#M 100.0 BYTE 0
  SD_3  :=P#M 100.0 BYTE 0
  SD_4  :=P#M 100.0 BYTE 0

PLC #2 calls FB14 GET to read PLC #1's AW 124 into a local DB, then moves it to EW 124:

CALL "GET" , DB14
  REQ   :=M 0.0
  ID    :=W#16#2
  NDR   :=M 10.0
  ERROR :=M 10.1
  STATUS:=MW 12
  ADDR_1:=P#Q 124.0 WORD 1       // remote address on PLC #1
  ADDR_2:=P#M 100.0 BYTE 0
  ADDR_3:=P#M 100.0 BYTE 0
  ADDR_4:=P#M 100.0 BYTE 0
  RD_1  :=P#DB21.DBX 0.0 WORD 1  // local destination
  RD_2  :=P#M 100.0 BYTE 0
  RD_3  :=P#M 100.0 BYTE 0
  RD_4  :=P#M 100.0 BYTE 0

L     DB21.DBW 0
T     EW 124

Important: the partner area pointer ADDR_i must be valid for the partner's own addressing - it is resolved at the partner CPU, not at the local one. A typo of P#M 124.0 WORD 1 (marker 124) instead of P#Q 124.0 WORD 1 (output 124) is the most common reason the connection establishes but the value is always 0.

Status Word, Error Codes, and Diagnostic Matrix

All three block families share a STATUS layout. ERROR=1 means the STATUS word is a 4-byte error code built as 80xx_DDss (xx = class, DD = detail, ss = source). The most common codes in the PLCSIM V5.4 / CP 343-1 Advanced scenario are:

Workarounds That Actually Run

There are four realistic ways to make this verification go. Pick the cheapest for the phase of the project.

Workaround 1: Use Real CP 343-1 Advanced Hardware

The most honest path. The FB12/FB13 or FB14/FB15 code from the sections above is the same code that runs on the real CP, and NetPro has already been configured. Hook the two CPs to a small Ethernet switch, assign each CP a fixed IP from the same /24 (e.g., 192.168.0.11 and 192.168.0.12), download both stations with the real PG cable, and the connection will establish. This is the only option that fully validates the production code path, the S7-300/CP timing, the LEDs (SF, BF, RUN, STOP), and the connection resource bookkeeping.

Workaround 2: Bridge PLCSIM to the Real Network with NetToPLCSim

NetToPLCSim is an open-source utility that opens a virtual Windows TCP/IP adapter bound to the S7-PLCSIM instance and exposes the simulated CPU as if it had a real Ethernet port. Set NetPro's interface assignment to "PLCSIM (Ethernet)" in the S7-PLCSIM tool window, point NetToPLCSim at the local IP of the virtual adapter, and the partner (a real CP 343-1 Advanced or another PLCSIM instance) can establish S7 connections through the bridge.

Workaround 3: Replace the CPU with One That Has an Integrated PROFINET Port

CPU 31x PN/DP variants (e.g., 6ES7 314-6EH04-0AB0 PN/DP, 6ES7 315-2EH14-0AB0 PN/DP, 6ES7 317-2EK14-0AB0 PN/DP) carry an integrated PROFINET interface on the CPU itself. S7-PLCSIM V5.4 SP4 can simulate the PN port of those CPUs, which means the FB12/FB13 / FB14/FB15 S7 communication blocks run against the simulated PN stack and the connection establishes between two PLCSIM instances. Migration cost is a CPU swap and a recompile of HW Config; the user program and NetPro connection are unchanged. If the project can tolerate a different CPU type, this is the cleanest in-PLC-SIM solution.

Workaround 4: Move the Project to TIA Portal and Use S7-PLCSIM V16+

S7-PLCSIM in TIA Portal V16 and later can simulate a fully virtual Ethernet segment, including TCP, ISO-on-TCP, S7 communication, PROFINET, and Web APIs. However, this path requires a full port of the S7-300 STEP 7 V5.5 project into TIA Portal, and the CP 343-1 Advanced is not a TIA-friendly device (TIA supports the CP 343-1 and CP 343-1 Advanced via HSPs, but the project still needs to be recreated from scratch in TIA Portal). For long-term maintenance, TIA Portal is the right destination; for a short PLCSIM verification of the AW 124 ↔ EW 124 mirror, Workaround 1 is faster.

Verification Procedure on Real CP Hardware

1. Wire the two CPUs, the two CPs, and a managed Ethernet switch. Use straight-through Cat 5e/6 patch cords.
2. Configure fixed IPs on each CP via the CP's "Assign IP address" tool in HW Config, or via the CP's web page. Disable DHCP on the CPs.
3. From the PG, ping each CP. A successful ping confirms the link and IP setup before S7 connection diagnostics are attempted.
4. Download HW Config and the user program to both CPUs. Put the CPUs in RUN-P. The CP's RUN LED must be solid green within 5 seconds of CPU RUN.
5. Open NCM Diagnostics > S7 Connections on the local CP. The configured connection should show status "Established" with the partner's IP and TSAP.
6. Trigger M 0.0 on PLC #1. Observe M 10.0 (DONE) on PLC #1 and M 10.0 (NDR) on PLC #2 cycle-by-cycle, or set up a VAT that watches DB20.DBW 0 on PLC #2 in Monitor/Modify.
7. If STATUS != 0, look it up in the diagnostic matrix above, then open the CP's web diagnostic page (default URL: http://<CP-IP>/diagnostics) to read the negotiated TSAPs and the last error class.

Field-Proven Commissioning Checklist

1. Catalog numbers and firmware: CPU 314C-2 DP 6ES7 314-6CH04-0AB0 V2.0 (or later) and CP 343-1 Advanced 6GK7 343-1GX30-0XE0 V2.0 (or later) - matching V1.0 is acceptable but the V2.x firmware fixes several S7 connection abort issues and is recommended.
2. CP 343-1 Advanced firmware: confirm in NCM Diagnostics > Module Information that the firmware matches the GSD/GSDML version in HW Config. Mismatched firmware on a CP that was just reflashed is the #1 cause of "connection configured but never established".
3. Connection resources: CPU 314C-2 DP allows 8 S7/HMI/PG/OP connections; reserve 1 for the PG, 1 for the HMI, and the rest for S7. CP 343-1 Advanced allows 16.
4. IP addressing: both CPs on the same /24 subnet, no router, no firewall on the engineering port.
5. TSAPs: 01.01 on both local and remote is the safe default. The first byte is the rack/slot byte of the CP, the second byte is the connection index. For a 300 station with the CP in slot 4, 01.01 is correct. For slot 5, 01.02. For slot 6, 01.03.
6. Block instance DBs: one DB per FB call. Calling FB12 four times with the same DB corrupts the connection state.
7. Trigger: REQ on BSEND and PUT must be a rising edge; EN_R on BRCV is level; REQ on GET is rising edge.
8. Length: LEN for BSEND/BRCV must be set to the actual data length, not zero. The BRCV block's LEN is an output that the block itself writes, but the BSEND's LEN is an input and you must set it to the number of bytes you are sending.
9. PLCSIM: do not use PLCSIM V5.4 to validate CP-based S7 communication. Validate on real CP hardware or with a CPU that has an integrated PROFINET port.

Frequently Asked Questions