The drive status and selected VFD3 parameters update over PROFINET, but the start command and frequency setpoint sent from an S7-300 project in SIMATIC STEP 7 produce no response. The same PIP2 interface and drive settings work from a TIA Portal test project. This isolates the fault to the STEP 7 output configuration, address use, or command encoding rather than to basic network reachability.
PROFINET Device Identity and Name Assignment
A PROFINET connection has separate configuration and runtime requirements. Importing the PIP2 device-description file adds the interface and its supported modules to the hardware catalog. It does not, by itself, prove that the configured station matches the physical device.
The configured device name must correspond to the name assigned to the PIP2 interface. The controller also needs a reachable IP configuration and a hardware configuration containing the correct PROFINET interface. Because STEP 7 already receives drive status, the physical link, device discovery, and input data path are operating. Still, compare the online device identity with the configured station before analyzing program logic; a duplicate name or a connection to the wrong device can produce misleading results during commissioning.
- Open the STEP 7 hardware configuration and locate the PIP2 station on the S7-300 PROFINET network.
- Compare its configured PROFINET device name with the name assigned to the physical interface.
- Confirm that the online station is reachable at the configured address and that the controller reports an established cyclic connection.
Check 1: Expect the configured PIP2 station to appear online without a device-name, configuration, or module diagnostic.
PIP2 Module and Process-Image Layout
The device-description file defines the modules available to both engineering systems, but STEP 7 and TIA Portal can assign different process addresses or permit different module selections. A working TIA Portal project therefore provides a reference configuration, not proof that the STEP 7 layout is identical.
Input data and output data are independent directions. Valid status values prove that the S7-300 is consuming the PIP2 input area. They do not prove that the configured output module has the expected length or that the program writes to the correct output area.
| Observation | Meaning | Required check |
|---|---|---|
| Drive status changes correctly | Input communication and at least part of the module layout are valid | Compare input length and addresses |
| Start and setpoint have no effect | The output path, output layout, command format, or drive control source remains wrong | Compare output modules, lengths, and addresses |
| TIA Portal project controls the drive | The PIP2 hardware and drive can accept network control | Use the working project as a field-by-field reference |
- Open the working TIA Portal device view and record the selected PIP2 modules in slot order.
- Record the input and output lengths associated with each selected module.
- Reproduce the same slot order and data lengths in the STEP 7 hardware configuration.
- Compile and download the hardware configuration to the S7-300.
Check 2: Expect the online STEP 7 module list, slot order, and input/output lengths to match the working TIA Portal configuration, with no module-difference diagnostic.
STEP 7 Output Address Binding
The output start address shown in the STEP 7 hardware configuration is the authoritative destination for the drive command data. Program addresses copied from another project can silently point elsewhere because address allocation depends on the complete station layout.
Trace every value from the application logic to the configured PIP2 output area. Watch the final output bytes or words online, not only internal command tags. If an internal start bit changes but the mapped output does not, the defect lies in the copy, move, block interface, or conditional call that transfers the command. Also check for later writes: multiple blocks writing the same output area make the last executed write effective.
- Record the PIP2 output start address and total length from the STEP 7 hardware configuration.
- Cross-reference that complete range in the S7-300 program.
- Identify every direct write, block transfer, and overlapping output assignment.
- Monitor the physical output area while toggling the start request and changing the frequency command.
- Verify that the control routine executes every scan in which network control is required.
Check 3: Expect at least one bit in the mapped command field to change with the start request and the mapped setpoint field to change with the requested frequency. Expect no later block to overwrite either field.
Command Word and Frequency Encoding
A cyclic connection transports bytes; it does not interpret an arbitrary Boolean as a valid run command. The program must construct the command field expected by PIP2 and place the frequency request in the expected field, byte order, width, sign convention, and scale. A single bit that appears to represent “start” may be ineffective if required enable or release conditions in the same command field are absent.
Use the working TIA Portal project to identify the complete output image for three controlled states: stopped, commanded to run, and commanded to run with a nonzero setpoint. Compare raw output bytes or words rather than symbolic names. This reveals byte swapping, field displacement, missing command bits, and scaling differences without guessing a telegram format.
| Test state | Expected output behavior | Fault indicated by mismatch |
|---|---|---|
| Stopped | Command field contains the valid stopped state; setpoint is controlled | Uninitialized or stale output data |
| Run request | Required command bits change as a group | Incomplete command construction |
| Nonzero frequency request | Setpoint field changes predictably with the request | Wrong address, data type, byte order, or scale |
Read the exact scaling rule and command-bit definitions from the PIP2 mapping documentation associated with the imported device-description file. Do not substitute engineering units directly unless that mapping explicitly defines them.
Check 4: Expect the STEP 7 raw output image for each test state to match the corresponding working TIA Portal output image field by field.
Drive Control-Source Commissioning
The drive must accept both run control and frequency reference from the communications interface. These can be separate source selections. The unchanged VFD3 settings used in the successful TIA Portal test make a drive-parameter defect less likely, but the active source still belongs in the commissioning check because local mode, terminal control, an interlock, or a latched fault can block a valid network command.
- Place the drive in the same operating mode used during the successful TIA Portal test.
- Confirm that the selected run-command source is the PIP2 communications path.
- Confirm that the selected frequency-reference source is the PIP2 communications path.
- Clear active faults using the drive-approved reset method.
- Check drive-ready status and all external permissives before issuing the run command.
- Send a zero setpoint first, establish the valid command state, then apply a controlled nonzero request.
Check 5: Expect the drive status to indicate ready before the command, then to acknowledge the commanded operating state when the valid command field is sent.
End-to-End Verification
Commission the channel as a closed path: PLC request, STEP 7 output image, PIP2 reception, drive response, and returned status. Checking only the internal request or only the received status leaves part of the path untested.
- Network check: Expect the S7-300 and PIP2 cyclic connection to remain established without module diagnostics.
- Command check: Expect the mapped STEP 7 output command field to change to the validated run pattern.
- Setpoint check: Expect the mapped output setpoint field to track the requested value using the documented representation.
- Response check: Expect the returned drive status to change from ready or stopped to the commanded operating state.
- Reference check: Expect the returned frequency-related value to move in the commanded direction and return when the request is removed.
- Stop check: Expect removal of the run command to produce the intended stop response and the returned status to confirm that state.
Check 6: Expect all six observations to occur in sequence without manual intervention or a change of engineering environment.
Frequently Asked Questions
How do I know whether the PIP2 device-description file works in STEP 7?
If STEP 7 imports the device, establishes cyclic PROFINET communication, and reads changing VFD3 status data, the file is usable for that connection. Next compare the configured output modules and their lengths with the working TIA Portal project.
How do I find why STEP 7 reads the drive but cannot start it?
Monitor the configured PIP2 output area while issuing the command. If the output does not change, correct the program mapping or overwrite; if it changes, compare the complete raw command field with the working TIA Portal output.
How do I verify the VFD3 frequency setpoint mapping?
Record the raw output value at several controlled requests in the working TIA Portal project, then reproduce the same values in STEP 7. Confirm the field address, width, byte order, sign convention, and documented scale.
How do I prove the STEP 7 repair is complete?
Command stop, run, a controlled nonzero frequency request, and stop again while monitoring the PLC output image and returned drive status. The final verification step is confirming that removal of the run command produces the intended stop response and matching returned status.