Resolving PROFIdrive 0xBF00 PRM Data Record in Encoder Profile

Problem Overview: Unexpected 0xBF00 Record from S7-1500

When commissioning a PROFINET encoder device on a Siemens S7-1500 controller using the PROFIdrive V4.2 specification (PROFIdrive_3172_V42_Oct15.pdf), the controller transmits a record-data write request to PROFINET slot 0, subslot 1, index 0xBF00 immediately after AR (Application Relationship) establishment. The content and structure of that record are not defined in the published PROFIdrive profile, the Encoder Profile, or in any clause of the GSDML schema used for the encoder submodule.

Reference of the gap: PROFIdrive Profile V4.2 (October 2015), Table 186 "Parameter Access Mode (PAP) Definition" on page 271 of 289, lists the Parameter Access Point (PAP) index range. The row for INDEX 0xBF00 reads only "Reserved for further definition." There is no octet layout, no length field, no block header description, and no encoding rule provided for that record anywhere in the published profile documents. New encoder developers following the Encoder Profile specification encounter this record from the controller and have no official documentation describing the payload the controller expects, the response structure the encoder must return, or the error handling semantics when the record is not understood.

Root Cause: A Legacy PRM Record from the Historic Encoder Profile

The 0xBF00 PROFINET record is a vestige of an earlier version of the PROFIBUS/PROFINET Encoder Profile, dating back approximately 15 years (circa 2010 and earlier revisions of the PROFIdrive Encoder profile specification). In those revisions, the profile mandated a standardized Parameter Record (PRM) hosted at record index 0xBF00. The intent was to provide interoperability for the basic parameter channel between the controller and the encoder.

The profile working group later determined that the PRM record was not an interoperability concern and removed the mandatory definition from the Encoder Profile. The 0xBF00 record was discarded from the profile specification because:

1. Parameter channel structure is vendor-specific by nature; vendors require freedom in encoding resolution, scaling, units, and proprietary extensions.
2. No interoperability benefit arose from standardizing the record index, because every vendor still defined a different payload structure.
3. PROFINET reserves a vendor-specific data record range (1 to 0x7FFF) for exactly this purpose, making the profile-specific 0xBF00 index redundant.

However, the record index 0xBF00 is still tolerated on deployed encoders that shipped during the legacy era. The PROFINET controller sequencer on the S7-1500 family (and other PI-compliant controllers) was modified to send a default 0xBF00 record to any encoder submodule that exposes a PROFIdrive profile ID, because the controller cannot, in all cases, distinguish legacy encoders from new encoders based on GSDML alone.

Current Status in PROFIdrive V4.2 and Encoder Profile

As of PROFIdrive Profile V4.2 (October 2015) and the corresponding Encoder Profile specification, the official statements are:

• Table 168 of the PROFIdrive V4.2 document does not include 0xBF00 in any active definition. The row in Table 186 marking 0xBF00 as "Reserved for further definition" is a hold-over entry; no further definition will be issued at the profile level.
• The Encoder Profile specification, clause 9.4 on page 106, explicitly directs vendors to define their own parameter records inside the vendor-specific PROFINET record range (1 to 0x7FFF) and to describe the record layout in the GSD file (GSDML for PROFINET).
• 0xBF00 will not be used for profile-specific definitions in the future. The PI working group has confirmed that no semantic content will be assigned to 0xBF00 in upcoming revisions of either PROFIdrive or the Encoder Profile.

Vendors still shipping encoder products that entered the market in the legacy era are permitted to continue using 0xBF00 as a profile-specific parameter record, because removing the record could break the parameter channel of those installed-base devices. New encoder developments are expected to follow clause 9.4 and place the PRM record inside 1–0x7FFF.

Encoder Profile PRM Record Specification (Clause 9.4)

Per the Encoder Profile, clause 9.4, the PRM (Parameter Record for Module/Module Parameter) is structured as a sequence of indexed parameter blocks. The base layout is:

Each parameter block follows the PROFIdrive parameter channel rules: an index/PNU reference, a subindex, the number of elements, the attribute byte (read/write, constant, etc.), and the data payload. The exact block structure is left to the vendor and must be documented in the GSDML RecordDataList section.

For new encoders, the vendor chooses any unused record index in the range 0x0001–0x7FFF and assigns it to the PRM function. The selection is then declared in the GSDML using <RecordDataList> and <ParameterRecordDataItem> entries, with the byte layout of the record fully described so the controller can correctly build and parse the write/read requests.

S7-1500 Sequencer Behavior at System Startup

The S7-1500 / S7-1500T controller, when configured with a PROFIdrive or Encoder Profile submodule, executes the following sequence at PROFINET AR establishment:

1. The controller reads the GSDML ModuleInfo to identify the submodule's profile ID and PRM record configuration.
2. For submodules with profile ID = 0x3D (Encoder Profile) or 0x3A/0x3B (PROFIdrive drive profiles), the controller issues a record-data write to index 0xBF00 with an empty or short default payload, regardless of whether the vendor has defined a record at 0xBF00.
3. If the encoder returns a record-data negative response (ErrorCode1 = 0xFE, ErrorCode2 = 0xFF / "Record not supported"), the controller logs a warning and continues commissioning. The PRM channel is not established through 0xBF00.
4. If the encoder returns a positive response with valid PRM data, the controller parses the payload according to its own internal (Siemens-specific) expectation. Vendors that did not originally follow that internal structure may see "Invalid parameter record" alarms in the controller's diagnostic buffer.

Reference for controller-side handling is the TIA Portal documentation, "Configuring PROFIdrive telegrams (S7-1500, S7-1500T)" available at docs.tia.siemens.cloud.

Recommended Implementation for New Encoder Designs

New encoder products targeting the PROFIdrive Encoder Profile should follow this sequence to avoid the 0xBF00 ambiguity entirely:

1. Assign a unique vendor-specific record index in 0x0001–0x7FFF (for example, 0x3F00, 0x4F00, or another index already used by the vendor in their product family).
2. Define the PRM record payload structure to match the PROFIdrive parameter channel format (PNU/subindex/attribute/data) used elsewhere in the vendor's tooling.
3. Add a ParameterRecordDataItem entry in the GSDML RecordDataList that fully describes the record layout, including byte offsets, lengths, and data types. Example GSDML fragment:

   <RecordDataList>
     <ParameterRecordDataItem Index="0x3F00" TransferSequence="0" WriteAccessSupported="true" WriteAccessByPrmDevice="true" ReadAccessSupported="true" MaxDataLength="240" />
   </RecordDataList>

4. In the encoder firmware, return ErrorCode 0xFE ("Record not supported") to any record-data write to 0xBF00. This signals to the controller that the legacy record is not used, suppresses the diagnostic warning on newer TIA Portal versions, and avoids accidental parameter misinterpretation.
5. Verify that the chosen vendor record (for example, 0x3F00) is not already assigned to another profile function in the same submodule; PROFINET allows multiple records per submodule, but the controller indexes them by (slot, subslot, index) and conflicts will surface as commissioning errors.

Migration Strategy for Legacy Encoders Using 0xBF00

Vendors that still ship encoders based on the older Encoder Profile revision and use 0xBF00 for the PRM record should:

• Continue to support 0xBF00 in firmware for backward compatibility. Removing the handler is not advisable while installed-base devices are in service.
• Document the exact payload layout of 0xBF00 in the product manual, since the profile-level documents do not describe it. Customers integrating such encoders on an S7-1500 need the byte-level layout to interpret any write request the controller issues.
• For new product variants, ship a GSDML revision that adds a vendor-specific record (for example, 0x3F00) for the PRM function. Use the GSDML versioning mechanism (GSDML-V<vendor>-<date>.xml) so existing projects continue to load the legacy 0xBF00 record while new projects use the vendor record.
• When validating against the Encoder Profile Test Specification, recognize that 0xBF00 is not part of the conformance test cases; only the new vendor record must be verified.

Interaction with OPC UA Companion Specification for PROFINET Drives

The OPC UA Companion Specification for PROFINET Drives (PNDRV, clause 4.1.5) describes how drive and encoder parameters are exposed via OPC UA over the PROFIdrive profile. The companion specification assumes the PRM record is available for parameter read/write from a controller; it does not constrain which PROFINET record index the vendor uses. New encoders following clause 9.4 of the Encoder Profile and using a vendor-specific record index are still PNDRV-compliant, provided the GSDML describes the record and the controller can route the request.

Verification and Test Procedure

To confirm the encoder handles the 0xBF00 record correctly and that the PRM channel works through the vendor record, execute the following checks during commissioning:

1. Install the encoder GSDML in TIA Portal V18 or later. Confirm no GSDML schema validation error is reported.
2. Wire the encoder to the S7-1500 PROFINET port and download the project.
3. Open the online diagnostics for the encoder submodule. Confirm the PROFINET AR is established (no "AR establishment failed" diagnostic).
4. Inspect the controller's diagnostic buffer. Look for any entry referencing record 0xBF00. With a properly implemented new encoder, this entry should appear as a benign "Record not supported" warning (EventID 0x001E, ID2 0xBF00) and not as an error.
5. Issue a parameter read through the PROFIdrive parameter channel (for example, read PNU 7 / sub 0 — encoder code). Confirm the returned value matches the encoder's actual code.
6. If using TIA Portal V20, validate the record-data list is parsed correctly by viewing the submodule's "Parameter assignment" tab; the vendor record (for example, 0x3F00) should appear in the list of writable records.
7. Run a hot-restart test: disconnect and reconnect the PROFINET cable. The encoder should re-establish the AR and the controller should re-issue the 0xBF00 record, with the same benign response pattern.

Troubleshooting Matrix

Key Constraints and Field-Validated Notes

• PROFINET record index 0xBF00 (48896 decimal) is outside the 0x0001–0x7FFF vendor-specific range and is therefore not assignable to a new function. The profile working group has reserved it as a legacy marker, not as an active definition.
• The S7-1500 sequencer does not check the GSDML RecordDataList before issuing the 0xBF00 write. The record is sent unconditionally for submodules that declare an Encoder Profile or PROFIdrive drive profile ID, regardless of whether the vendor has a record defined at that index.
• For S7-1500T motion-control configurations, the same 0xBF00 behavior applies. The S7-1500T adds technology-object-level parameter reads (for example, load gear, encoder mode) that flow through the same PRM record; ensure the vendor record supports the full set of PNUs the technology object requires.
• PROFIdrive and the Encoder Profile are standardized in IEC 61800-7 Parts 203 and 303. The PRM record semantics are not duplicated in the IEC standard; IEC 61800-7 references the profile documents for the parameter channel.
• For multi-encoder submodules (for example, a drive with two encoder channels), each encoder submodule receives its own 0xBF00 write. The handler must therefore be implemented at submodule granularity, not only at module level.

Summary Recommendations

For any new encoder development targeting PROFIdrive V4.2 and the Encoder Profile:

1. Do not attempt to interpret or rely on 0xBF00. Return ErrorCode 0xFE ("Record not supported") to any record write at that index.
2. Define the PRM record at a vendor-specific index in 0x0001–0x7FFF and document its layout in the GSDML RecordDataList.
3. Test the encoder against the S7-1500 startup sequence (AR establishment, record writes, parameter reads) to confirm the diagnostic buffer is clean and the parameter channel functions correctly through the vendor record.

Vendors with installed-base products on 0xBF00 should continue to support the legacy record but should also expose a new vendor-specific record for new projects, following the clause 9.4 guidance of the Encoder Profile specification.

FAQ