SINUMERIK 840Di sl: Configuring Dual MCP483 on Profibus

Problem Description

On a SINUMERIK 840Di sl retrofit, two MCP483 (Machine Control Panel, full keyboard variant) handwheels are connected to the same Profibus-DP network alongside two ADi4 analog-drive interfaces and three PP (I/O) modules. Profibus-DP configuration in STEP 7 / SIMATIC Manager completes without errors, the DP slaves go online, and the I/O area updates, but only one of the two MCP483 stations is functionally active. The second MCP shows its inputs in the predefined I/O image (operator keys, feed-override, spindle-override, axis-select keys, etc., are visible in the process image), yet none of the MCP's operating functions — mode-group switching, channel selection, jog, MDI, automatic, feed/spindle start/stop, rapid-traverse, block-search — are passed through to the NCK. The behavior is consistent with the second MCP having its inputs read but its outputs (HMI/NC function dispatch) never wired to the basic-PLC program.

This symptom is not a Profibus-DP fault. The hardware, GSD-file selection, and slave diagnostics are all healthy. The root cause is a configuration gap in the SINUMERIK basic PLC program (the toolbox that links the MCP to the NCK/PLC interface) and in the FC19 signal-routing block. Both MCP stations must be explicitly declared in the basic PLC, instantiated as separate function-block calls in OB1, and assigned to distinct BAG/Channel signal areas.

Affected Components and Topology

The retrofit machine has the following Profibus-DP slaves on the integrated MPI/Profibus interface of the 840Di sl PCU:

Each MCP must occupy a unique Profibus-DP address set by its on-board DIP switches (default MCP 1 = 6, MCP 2 = 7 — the address is read by the basic PLC and must match the value placed in the MCP1Adr / MCP2Adr parameter). The two MCPs must also be configured with identical GSD files and identical slot assignments; the only thing that differs is the Profibus DP address and the I/O area used by the basic PLC program.

Root Cause Analysis

The SINUMERIK basic PLC program (FB1) reads each MCP's I/O image and translates MCP-key events into the standardized HMI/NC interface signals (DB10 / DB11 area for the operator panel, plus the mode-group and channel FC19 interface). When only one MCP is declared — by default MCPNum = 1 — only the parameter set MCP1In / MCP1Out / MCP1StatSend / MCP1StatRec / MCP1Adr is active. The inputs of the second MCP are read because its DP slave is healthy and its image is placed somewhere in the I/O area, but the basic program never decodes the second MCP's keys, never drives the second MCP's LEDs, and never forwards the second MCP's handwheel to the NCK.

Two independent configuration gaps are usually present when this symptom appears:

1. FB1 parameter block in OB100 not duplicated. The retrofit engineer added a second MCP in HW Config and downloaded the configuration, but the basic PLC's startup block OB100 — which calls FB1 with the parameter UDT — still has MCPNum = 1. As a result, FB1 ignores the second MCP entirely and uses the first MCP's I/O area for everything.
2. OB1 calls MCP_IFT only once. MCP_IFT is the interface function that handles the per-MCP cyclic decoding and signal forwarding. Calling it once dispatches only the first MCP. A second call (with its own instance DB) is required so that the second MCP's I/O image is also decoded and routed.
3. FC19 parameterized for a single BAG / Channel pair. The MCP-to-NCK signal routing block FC19 takes a BAG-number (mode-group number) and a Channel-number for each MCP. If both MCPs are pointed at the same BAG and Channel, only the last-decoded MCP wins. The second MCP must point at the second BAG or at least a Channel that the basic PLC can route independently.

The combination of (1) and (2) is the most common cause of "inputs are seen but no function is active" on the second MCP. The combination of (1), (2), and (3) causes the second MCP to look dead even when its keys are pressed (the keys arrive in the I/O area, the basic program ignores them, and the HMI receives no signal that a key was pressed on the second panel).

Solution 1: Configure FB1 Parameters in OB100

Open the SINUMERIK basic PLC project in STEP 7 / SIMATIC Manager. The basic PLC program is shipped as a library (e.g. SINUMERIK 840D sl Toolbox or the older Basic Program P3 pl library). The startup organization block OB100 calls FB1 (basic PLC initialization) with an instance of the parameter UDT (typically UDT1001 or a project-specific UDT named MCP_Param / BAG_Param). The parameter DB associated with FB1 (commonly DB7 in standard toolboxes — verify against the project's symbol table) is the only place where MCP parameters must be defined.

Edit the parameter DB and set the following values. The strings in parentheses are the exact parameter names used in the basic-PLC UDT and match the SINUMERIK 840D powerline Basic PLC Program (P3 pl) documentation.

Step 1.1 — Declare the number of MCPs

In the parameter DB (called by FB1 from OB100), set:

This single line is what activates the second MCP parameter set. With MCPNum = 1, the entire MCP2* parameter set is unused by FB1 regardless of how the rest of the DB is filled in.

Step 1.2 — Duplicate the MCP2abcd bus parameters

The four abcd parameters identify the Profibus-DP slot layout (which slots are inputs, which are outputs, handwheel slot, etc.). They are read from the GSD configuration and must be identical for both MCPs, because both stations use the same MCP 483 GSD. Copy the values from MCP1 to MCP2:

MCP2abcd[1] := MCP1abcd[1]
MCP2abcd[2] := MCP1abcd[2]
MCP2abcd[3] := MCP1abcd[3]
MCP2abcd[4] := MCP1abcd[4]

Step 1.3 — Assign unique I/O areas for MCP2

Each MCP must have a private area for its cyclic I/O and for its send/receive status words. The areas are byte pointers (P#...) that point into the S7 process image. Typical values place MCP1 in the first 32-byte block and MCP2 in the next 32-byte block:

MCP2In    := P#E 64.0 BYTE 32   // input area  (MCP -> PLC)
MCP2Out   := P#A 64.0 BYTE 32   // output area (PLC -> MCP, e.g. LEDs)
MCP2StatSend := P#A 70.0 BYTE 4 // status send to MCP
MCP2StatRec  := P#E 70.0 BYTE 4 // status received from MCP

Step 1.4 — Set the Profibus address from the MCP DIP switch

The MCP2Adr parameter must equal the physical Profibus DP address set on the MCP 483's address DIP switch (or the rotary switch on the Profibus-coupler). For example, if the second MCP is address 7:

Setting MCP2Adr incorrectly is the second most common cause of "second MCP not working": FB1 tries to read the MCP2 I/O from a slave at the wrong address and the data it gets is either the first MCP's data (collision) or empty (timeout).

Step 1.5 — Define the bus type for both MCPs

The MCP bus type is encoded as a BYTE constant. For Profibus-DP MCPs, the value is B#16#33. Set this value for both MCPs:

MCP1BusType := B#16#33
MCP2BusType := B#16#33

After all five sub-steps, save the parameter DB and re-download the hardware configuration and the parameter DB to the PCU/PLCU. The OB100 cold-restart will pick up the new MCPNum = 2 and the second MCP will be registered by the basic program.

Solution 2: Instantiate MCP_IFT Twice in OB1

FB1 handles initialization and parameterization; the per-MCP cyclic decoding is done by MCP_IFT, which is called from OB1 (or from a project-specific cyclic block) once for each MCP. The retrofit project must call MCP_IFT twice, each time with its own instance DB, and each call must point at the correct I/O area for that MCP:

// First MCP
CALL "MCP_IFT" , DB_MCP1
   BAGNo     := 1                  // BAG number for MCP 1
   ChanNo    := 1                  // Channel number for MCP 1
   MCP1In    := P#E  0.0 BYTE 32
   MCP1Out   := P#A  0.0 BYTE 32
   MCP1StatSend := P#A  8.0 BYTE 4
   MCP1StatRec  := P#E  8.0 BYTE 4
   ...

// Second MCP
CALL "MCP_IFT" , DB_MCP2
   BAGNo     := 2                  // BAG number for MCP 2
   ChanNo    := 2                  // Channel number for MCP 2
   MCP2In    := P#E 64.0 BYTE 32
   MCP2Out   := P#A 64.0 BYTE 32
   MCP2StatSend := P#A 70.0 BYTE 4
   MCP2StatRec  := P#E 70.0 BYTE 4
   ...

The exact parameter list of MCP_IFT varies between toolbox versions, but the rule is: one MCP_IFT call per MCP, with a unique instance DB, and the I/O pointers matching the addresses defined in the parameter DB used by FB1.

Solution 3: Configure FC19 BAG and Channel Parameters

FC19 is the signal-routing block that connects the MCP-decoded key signals to the HMI/PLC/NCK interface (the so-called BAG- and Channel-signals in DB10 / DB11). It is called once per active mode group / channel pair, and it is parameterized with two numbers: the BAG number (mode group) and the Channel number. When the machine has more than one BAG or more than one Channel, each MCP can be tied to its own BAG/Channel so that operator actions on MCP 1 control BAG 1 / CHAN 1, and operator actions on MCP 2 control BAG 2 / CHAN 2.

For a dual-MCP retrofit on a single-BAG, dual-channel machine (or dual-BAG, single-channel), the minimum configuration is:

If the machine is configured with only one BAG and one channel, the second MCP's keys still have to be routed to some MCP slot. The cleanest way is to configure a second channel in the same BAG (set in the NC machine data MD10200 $MN_NUM_CHANNELS = 2) and assign MCP 2 to BAG 1, Channel 2. With only one BAG and one channel, the second MCP's function keys will not produce any NC reaction, because FC19 has no target Channel 2 to forward them to.

Verify the configuration by checking the following machine data and FC19 parameter list:

• MD10200 $MN_NUM_CHANNELS — must be ≥ number of MCP-attached channels.
• MD10220 $MN_NUM_MODE_GROUPS — must be ≥ number of MCP-attached BAGs.
• MD10350 $MN_FASTIO_DIG_NUM_INPUTS / OUTPUTS — must accommodate the sum of MCP1 + MCP2 I/O areas.
• FC19 input BAGNo / ChanNo — must match a valid (BAG, Channel) pair in the NCK.

Verification and Diagnostics

After applying all three solutions and reloading the project to the 840Di sl PCU, perform the following checks in order. Each step is a binary pass/fail and stops further diagnosis if it fails.

1. OB100 cold restart. Power-cycle the PCU or trigger an NCK reset. Verify that the parameter DB initialized by FB1 in OB100 contains MCPNum = 2 at runtime (inspect with STEP 7 online > Monitor/Modify on the parameter DB).
2. Both MCPs come online in HW Config. Open the online view in HW Config. Both MCP stations must show green (OK) DP status. If one shows "station failure," the MCP2Adr does not match the physical DIP switch.
3. MCP2 I/O area updates. Monitor the I/O area pointed to by MCP2In in STEP 7 VAT. Press a key on the second MCP and confirm the corresponding bit toggles in the input area. If no bits toggle, the I/O area is wrong (overlaps with another slave, or wrong slot configuration).
4. MCP_IFT is being called. Set a breakpoint or insert a temporary bit-set inside the second MCP_IFT call. Confirm the call is hit on every OB1 cycle.
5. Mode-group and channel switching works. From MCP 2, press the mode-group select key and confirm the active BAG in the HMI changes to BAG 2 (or the configured BAG). Press the channel select key and confirm the active channel changes. This verifies that FC19 is routing the signals correctly.
6. Jog/MDI/Auto modes work from MCP 2. Select JOG on MCP 2, jog an axis, confirm motion. Select MDI, run a block, confirm execution. This is the end-to-end functional check.

If step 1 succeeds but step 2 fails, re-check MCP2Adr against the MCP DIP switch. If step 2 succeeds but step 3 fails, the I/O area overlap is the cause — re-check the MCP2In / MCP2Out / MCP2StatSend / MCP2StatRec byte ranges against the I/O layout in HW Config. If steps 1–4 succeed but step 5 fails, the FC19 BAG/Channel configuration is wrong — re-check BAGNo / ChanNo and the NCK MDs MD10200 / MD10220.

Parameter Reference Table

Common Pitfalls and Field Notes

Five issues that have been encountered in the field on dual-MCP 840Di sl retrofits. Each is a one-line configuration error that the basic PLC does not flag — the symptom is always "second MCP inputs are seen but no function is active."

1. Forgetting to call MCP_IFT a second time in OB1. Symptom: MCP 2 inputs update, MCP 2 LEDs do not respond, mode-group switching does not respond. Fix: add the second MCP_IFT call with a dedicated instance DB.
2. Reusing the same instance DB for both MCP_IFT calls. Symptom: MCP 1 stops working as soon as MCP 2 is added. Fix: generate separate instance DBs.
3. Setting MCP2Adr to the same value as MCP1Adr. Symptom: Profibus slave failure on MCP 2; or both MCPs receive garbled data. Fix: verify DIP switch vs. parameter value.
4. I/O area overlap between MCP1 and MCP2. Symptom: keys pressed on one MCP appear as inputs on the other MCP's image. Fix: assign non-overlapping byte ranges in the S7 process image.
5. Single BAG / single channel NCK configuration with two MCPs. Symptom: MCP 2 keys do not produce any NC reaction even when the basic PLC is correctly configured. Fix: set MD10200 $MN_NUM_CHANNELS = 2 (or MD10220 $MN_NUM_MODE_GROUPS = 2) and assign MCP 2 to the second channel/BAG via FC19.

FAQ