Resolving SIMOCODE Parameter Download Failure on S7-315-2DP

Problem Overview

Engineers commissioning large SIMOCODE pro fleets frequently encounter a hard lockout when editing parameters of an already-parameterized device through STEP 7 / SIMATIC Manager HW Config. The PLC downloads a new PROFIBUS DP configuration to the SIMATIC S7-315-2DP, the DP slave list is updated, and the SIMOCODE pro basic unit stops responding. A subsequent parameter change request from SIMOCODE ES (integrated or standalone) is rejected with the message:

Parameter changes currently not possible due to system state. Motor is maybe in operation.

The reported fleet size in field cases is in the 40-60 unit range, all hanging off a single DP master. The failure is not a hardware fault, a GSD file mismatch, or a PROFIBUS termination problem. It is a state-machine guard inside the SIMOCODE pro firmware that protects the motor branch against in-flight parameter changes. The error message text is misleading: even with the motor confirmed OFF, the device still blocks the download when one of three internal conditions is true.

SIMOCODE pro System Architecture

SIMOCODE pro is the Siemens SIRIUS family motor management system. The relevant hardware variants for this troubleshooting case are:

Communication to the SIMOCODE pro basic unit is via PROFIBUS DP (RS-485) at 9.6 kbit/s to 12 Mbit/s, or via PROFINET on the pro V PN variant. A standard S7-315-2DP hosts up to 32 DP slaves per segment without repeater. With 60 SIMOCODE units you will need at least two DP segments and one RS-485 repeater (e.g., 6ES7972-0AA02-0XA0).

Parameter storage locations:

• SIMOCODE pro internal non-volatile memory – holds the active parameter set of the device.
• STEP 7 HW Config / SIMOCODE ES project – holds the engineering parameter set on the engineering station.
• PLC CPU load memory – holds the configuration that is downloaded on PG-to-CPU or CPU-to-DP transfer.

The lockout occurs when the engineering-side parameter set and the device-side parameter set are out of sync, AND the device-side state machine refuses to accept the new parameters because of a guarding condition.

Root Cause: The Three Guarding Conditions

Siemens defines three explicit conditions under which a "restricted parameter download" to a SIMOCODE pro device is refused. Any one of them is sufficient to block the download.

Condition 1 is the most common root cause in field cases and the one that maps to the error string shown by SIMOCODE ES. The phrase "Motor is maybe in operation" is a firmware-side uncertainty flag – the device does not know whether the motor is genuinely rotating; it only knows that the Feedback On binary input, the bus status word bit, or a configured fixed level is asserting. The SIMOCODE pro cannot distinguish between a real running motor and a hard-wired feedback loop held high by a parameter misconfiguration.

Diagnostic Procedure

1. Read the device diagnostic buffer. Open SIMOCODE ES, go online to the affected device, and read the diagnostic buffer. Look for the entry Parameter changes currently not possible due to system state and the timestamp.
2. Check operating mode. In SIMOCODE ES, navigate to Parameters > Control > Control Stations and confirm the active Control Function source. The status byte at the top of the online view shows the current mode (Local 1, Local 2, Local 3, Remote, PC).
3. Inspect the I/O status. Open Diagnostics > I/O Status in SIMOCODE ES. Verify each binary input (BU inputs, DM inputs, EM inputs) against the wiring. The Feedback On input must read 0 before the parameter download is accepted.
4. Check the Control Station command bits. Confirm that no ON command is latched in the active control function. This includes the bus command word from the PLC, the hardwired inputs assigned to ON/OFF, and the PC control station. Look at the S7 program: the control word to the SIMOCODE (commonly in DB of the instance DB) often has the ON bit stuck from a prior logic path.
5. Read the device identification. Compare the device firmware version and article number against the SIMOCODE ES project. A firmware mismatch on the same GSD can also block parameter download silently.

For SIMOCODE pro V devices, the parameter set is mirrored in the SDP file (SIMOCODE Data Parquet / parameter file). Open the offline SDP file in SIMOCODE ES and compare it against the online device using Device > Compare. Mismatches at the bit level (e.g., a changed trip class, a changed thermal reset mode) are highlighted and must be reconciled before the download.

Solution 1: Force Device into Local Mode and Clear Feedback

The first escalation step, when the device is reachable online, is to put the SIMOCODE pro into a non-blocking state and re-issue the download.

1. Set the operating mode to Local 2 (or Local 1, or Local 3) from SIMOCODE ES, or rotate the selector on the basic unit to Local 2.
2. Clear the Feedback On input. If the input is wired to a contactor auxiliary, verify the contactor is open. If a fixed level was assigned, navigate to Parameters > Inputs > Feedback On and remove the fixed level. Save locally only at this stage.
3. Confirm that the active Control Function has no ON command asserted. In the S7 program, force the control word output to the SIMOCODE instance DB to 0. The control word is typically in DBxx offset 0 (bit 0 = ON, bit 1 = OFF).
4. Re-trigger the STEP 7 HW Config download to the CPU, or use Device > Download to Device in SIMOCODE ES standalone.

If condition 1 was the only guard, the download completes and the device is in sync with the PLC project.

Solution 2: Direct Download from SIMOCODE ES Standalone

When HW Config from STEP 7 fails because the CPU is in RUN and the routing path is busy, escalate to a direct PROFIBUS connection from the engineering PG to the SIMOCODE pro. This bypasses the CPU entirely.

1. Connect the PG directly to the DP segment of the affected SIMOCODE pro (or use the PLC as a router with PG routing enabled).
2. Open the affected SDP file in SIMOCODE ES standalone.
3. Go online to the device. Confirm the device is in a quiescent state (mode = Local, Feedback On = 0, no ON command).
4. Use Device > Download to Device. The progress dialog should reach 100% without invoking the guard.

Solution 3: Factory Reset via Test/Reset Button

When the device is locked out and SIMOCODE ES cannot break the guard remotely, perform a manual factory reset. This is the documented procedure from the SIMOCODE pro system manual and is the only way to clear a corrupted parameter state when the local mode selector and feedback inputs cannot be reconfigured from the tool.

1. Switch off the supply voltage to the SIMOCODE pro basic unit.
2. Press and hold the Test/Reset button on the basic unit front face.
3. While holding the button, switch on the supply voltage. The Device LED lights up yellow.
4. Release the Test/Reset button after approximately 2 seconds.
5. Press the Test/Reset button again after approximately 2 seconds.
6. Release the Test/Reset button after approximately 2 seconds.
7. Press the Test/Reset button again after approximately 2 seconds.
8. Release. The Device LED returns to green, the parameter set is cleared to factory defaults, and the device is reachable online with the default PROFIBUS address (default = 126).

After a factory reset, the device must be re-parameterized from scratch. Re-assign the PROFIBUS address (DP address 1-125), load the engineering SDP file, set the control function, configure the inputs, and push the configuration back to the CPU. The basic unit LED pattern is the verification: solid green at power-up indicates healthy operation with a valid parameter set.

Common Misconfigurations That Lock the Device

Across the S7-300 / SIMOCODE pro install base the following parameter assignments account for the majority of "stuck on Feedback On" complaints. Verify each in the SDP file before assuming a hardware fault.

The most frequent offender is the Fixed Level - 1 assignment to Feedback On. This was historically used in test rigs to force a status without wiring a real contactor. Once committed to non-volatile memory, every subsequent download attempt fails because the firmware cannot accept parameter changes while Feedback On reads 1.

Overload and Voltage Monitoring Functions

Engineers integrating SIMOCODE pro V with current and voltage measuring modules often need to distinguish between inrush, sustained overload, and a supply-side breaker trip. The device exposes two related but distinct events:

For breaker-trip detection (loss of supply voltage to the motor), the SIMOCODE pro V supports two functional blocks:

• Voltage Limit Monitoring (Umin) – monitors the minimum of all three phase voltages; trips when the minimum drops below a configured threshold. This block integrates the three phase voltages internally and is the simpler approach for three-phase supplies.
• Limit Monitor – monitors a single analog value. To monitor all three phases independently, three Limit Monitor blocks are required (one per phase). Use this only when a specific phase requires an independent threshold.

Whichever block is used, place the voltage measurement on the load side of the breaker (after the breaker, not after a contactor). If the contactor opens before the measurement, the measurement collapses and a false trip is generated. Alternatively, configure the monitoring block to be active only when the motor is running, using the Trip Level Activity parameter tied to the Motor On status.

Verification After Recovery

Use the following checklist to confirm the SIMOCODE pro is back in a clean state and aligned with the STEP 7 project.

1. Device LED is solid green at power-up (no yellow, no red blink codes).
2. SIMOCODE ES reports Online with no diagnostic buffer entries from the recovery period.
3. STEP 7 HW Config shows the SIMOCODE pro DP slave as OK with no diagnostic interrupt pending.
4. The SDP file comparison tool reports No differences between offline and online parameter sets.
5. The PLC diagnostic buffer shows the DP slave reached DP-V1 exchange state without subsequent parameterization retries.
6. The control word from the S7 program drives the motor through one full start-stop cycle, with feedback reading correctly and the trip flag returning to 0.

For a 60-unit fleet, repeat the verification for each unit and capture the parameter version in a commissioning log. A future firmware update on the SIMOCODE pro will detect the parameter version mismatch and trigger a partial re-parameterization, so keeping a per-unit record of the parameter version (visible in the device identification) is the only way to plan a fleet-wide update without extended downtime.

Troubleshooting Matrix

FAQ