Overview
This technical reference decodes the structure of PROFIBUS DP telegrams exchanged between a Siemens S7-300 PLC (Class 1 master) and an HMI (Class 2 master). It explains the SD2 variable-length frame, the S7 communication protocol encapsulation on PROFIBUS DP, and the S7ANY address specification required to map protocol data units back to PLC memory areas such as MW0, MB0, and MB1.
Use this article to:
- Interpret a raw PROFIBUS DP frame captured with a serial tap or oscilloscope
- Identify the address fields (DB number, byte offset) of S7 data items in a read or write response
- Understand how a Class 2 master (HMI) obtains the token and exchanges acyclic data with an S7-300
- Migrate HMIs and verify that the new panel reads the same memory locations as the old one
Note on terminology: The terms SSAP (Source Service Access Point) and DSAP (Destination Service Access Point) are part of the PROFIBUS FMS specification, not PROFIBUS DP. PROFIBUS DP uses only the DA (Destination Address) and SA (Source Address) bytes. The S7 communication protocol runs on top of PROFIBUS DP's SRD (Send and Request Data) service and uses an internal function-group / service-id field in place of legacy FMS SAPs.
PROFIBUS DP Protocol Stack and Master Classes
PROFIBUS DP (Decentralized Periphery) is defined in IEC 61158-6 (Type 3) and EN 50170. It operates on OSI layers 1, 2, and 7. The DP variant was designed for high-speed cyclic data exchange between controllers and distributed I/O. Three device classes are defined in the user plane:
| Class | Role | Example | Bus Behavior |
|---|---|---|---|
| DPM1 (Class 1) | Controller / PLC | S7-300 CPU 315-2 DP | Cyclic I/O exchange with assigned slaves; owns the GSD-derived configuration |
| DPM2 (Class 2) | Commissioning / HMI / SCADA | Siemens TP / OP panel, programming device | Acyclic read/write; borrows the token briefly during gap time |
| Slave | Distributed I/O | ET 200S, drive, valve island | Responds to master requests; never initiates communication |
An HMI is therefore a Class 2 master. It does not own the cyclic exchange. It borrows the token from the Class 1 master during the gap time at the end of each Class 1 cycle. This is why the HMI's data updates are inherently acyclic — the latency depends on the Class 1 master's Token Hold Time (TH1) and the number of slaves in the cyclic list.
Class 1 vs Class 2 Master Operation
In a multi-master system, the token circulates between Class 1 masters via SD4 telegrams (Start Delimiter 0xDC). Each Class 1 master retains the token for its Token Hold Time (TH1), which it computes dynamically from the GSD-derived cycle time of its assigned slaves. After the Class 1 master finishes its cyclic exchange with all of its assigned slaves, the gap time slot opens. The Class 1 master then passes the token to the next Class 1 master (or, if configured, to a Class 2 master) for a brief interval.
The Class 2 master (HMI) has a Token Hold Time (TH2) to perform acyclic operations. After the TH2 expires — or the HMI completes its acyclic work — the token returns to the Class 1 master and the cyclic exchange resumes.
Key behavioral differences:
- Class 1: Telegram structure is fixed by the GSD. Inputs and outputs are exchanged at deterministic intervals (typically 1–10 ms). Configuration is downloaded once at startup via the Chk_Cfg and Set_Slave_Param services.
- Class 2: Telegram structure is dynamic. The HMI builds the SD2 payload on demand to satisfy the current tag request (e.g., read 8 words from MW0). The Function Code (FC), addressing fields, and Data Unit change every cycle based on the active function blocks in the HMI runtime.
This is the reason the same HMI panel can issue 4-byte read requests one moment and 64-byte multi-tag requests the next, even though the bus is the same. The HMI is not bound by the slave GSD; it constructs its own SD2 payload for S7 communication services.
PROFIBUS DP Telegram Types
PROFIBUS DP defines four telegram types, distinguished by the Start Delimiter (SD) byte:
| SD Value (hex) | Type | Total Length | Purpose |
|---|---|---|---|
| 0x10 | SD1 | 6 bytes | Fixed-length acyclic message without data (diagnostic request, no-data ack) |
| 0x68 | SD2 | 5 + LE bytes | Variable-length data telegram (cyclic I/O, S7 communication, parameterization) |
| 0xA2 | SD3 | 11 bytes | Fixed-length 8-byte data telegram (clock synchronization, time broadcast) |
| 0xDC | SD4 | 3 bytes | Token telegram — passed between masters to grant bus access |
SD2 is by far the most common telegram on a running PROFIBUS DP network. All S7 communication, all cyclic I/O, and all parameter assignment services use SD2.
SD2 Variable-Length Frame Structure
An SD2 telegram consists of the following fields in order:
| Field | Length (bytes) | Description |
|---|---|---|
| SD | 1 | Start Delimiter, always 0x68 |
| LE | 1 | Net data length = DA + SA + FC + DU (range 4–249) |
| LEr | 1 | Repeated LE for safety; receivers reject the frame if LE != LEr |
| SD | 1 | Repeated Start Delimiter |
| DA | 1 | Destination Address (0–127 = node address; 127 = broadcast) |
| SA | 1 | Source Address (sender's PROFIBUS node address) |
| FC | 1 | Function Code — encodes service type, frame class, request/reply |
| DU | LE − 3 | Data Unit (variable length; contains the user data or protocol payload) |
| FCS | 1 | Frame Check Sequence (8-bit sum without carry over DA through DU) |
| ED | 1 | End Delimiter, always 0x16 |
On-wire size = 5 + LE bytes. For the captured frame with LE = 0x44 (68 decimal), the on-wire size is 5 + 68 = 73 bytes. The FCS checksum is the unsigned 8-bit sum (modulo 256, without carry) of all bytes from DA through DU; both sender and receiver compute and compare. If they differ, the frame is discarded and a retry occurs at the next token rotation.
Function Code Reference Table
The FC byte is composed of two fields. The low nibble (bits 0–3) carries the function code; the upper nibble (bits 4–7) carries the frame class and request/reply bits.
| FC (hex) | Function Code (low nibble) | Service | Typical Master |
|---|---|---|---|
| 0x40 | 0x0 | Time-out (no service) | — |
| 0x44 | 0x4 | Read Inputs (RD_IN) | Class 2 |
| 0x47 | 0x7 | Read Outputs (RD_OUT) | Class 2 |
| 0x5C | 0xC | SRD (Send and Request Data), high | Class 1 / Class 2 (S7 comm) |
| 0x5D | 0xD | SRD, low | Class 1 / Class 2 |
| 0x6C | 0xC | SRD high (Class 1 variant) | Class 1 |
| 0x6D | 0xD | SRD low (Class 1 variant) | Class 1 |
| 0x7C | 0xC | SRD high (Class 2 broadcast) | Class 2 |
| 0x7D | 0xD | SRD low (Class 2 broadcast) | Class 2 |
| 0xB4 | 0x4 | Read Inputs, reply | Slave |
| 0xB7 | 0x7 | Read Outputs, reply | Slave |
The captured frame uses FC = 0x5C. Decoding the bits: low nibble = 0xC (SRD), bit 4 = 1 (data frame with variable length), bit 6 = 1 (request data with reply). This is the most common FC for S7 communication services from a Class 2 master to a Class 1 master (or directly to an S7-300 acting as a DP slave).
Token Passing and Gap Time
The PROFIBUS token is a 3-byte SD4 telegram with the structure: SD (0xDC) | DA (next master) | ED (0x16). When the Class 1 master finishes its cyclic exchange and the gap time opens, it transmits the SD4 token to the next master in the LAS (List of Active Stations) — typically the HMI at the address configured in HW Config.
The Token Hold Time is bounded by:
TH1 = Tcyc - Tgap
Tcyc = sum(slave_frame_times) + Ttoken + Tidle
TH2 <= Tgap - Tret_gap
Where Tret_gap is the reserved return gap (typically a few hundred microseconds). The Class 2 master must complete all of its work and pass the token back within TH2. If the HMI is slow to respond, the Class 1 master detects a token timeout and restarts the bus cycle, which manifests on the HMI as a connection break.
S7 Communication Encapsulation on PROFIBUS DP
The S7 communication protocol (often called S7-Comm or S7comm) is a Siemens proprietary protocol for PG/OP/HMI communication with S7 PLCs. On PROFINET, it runs over ISO-on-TCP (RFC 1006) on port 102. On PROFIBUS DP, it runs on top of the SRD service (FC 0x5C or 0x5D) as a Class 2 master function.
The DU of an SD2 telegram carrying S7 communication has a PROFIBUS-specific prefix of 4 bytes before the standard S7-Comm header:
| Offset in DU | Field | Length | Value / Description |
|---|---|---|---|
| 0–1 | PDU identifier | 2 | 0x14 0x14 (constant for S7-Comm on PROFIBUS DP) |
| 2 | Function group | 1 | 0xF1 (F1 = S7 standard functions) |
| 3 | Service ID | 1 | 0x5C = S7 SRD with data; 0x51 = S7 SRD without data |
| 4+ | S7-Comm PDU | variable | Standard S7-Comm header and payload (protocol ID 0x32) |
The PDU identifier 0x14 0x14 is constant for S7 communication on PROFIBUS. It is NOT a length field; the actual PDU length comes from the LE byte of the outer SD2 frame. In the Wireshark PROFIBUS DP dissector, this prefix is decoded as the "S7 Communication Layer."
S7-Comm Header Layout (Protocol ID 0x32)
After the PROFIBUS-specific prefix, the standard S7-Comm header is structured as follows:
| Byte Offset | Field | Size (bytes) | Description |
|---|---|---|---|
| 0 | Protocol ID | 1 | Always 0x32 (identifies S7-Comm) |
| 1 | ROSCTR | 1 | 0x01 = Job (request), 0x02 = Ack, 0x03 = AckData (response with data), 0x07 = UserData |
| 2–3 | Redundancy ID | 2 | Usually 0x0000 (high-availability systems set a non-zero value) |
| 4–5 | PDU reference | 2 | Sequence number; the receiver echoes it back so the originator correlates request/response |
| 6–7 | Parameter length | 2 | Length of the parameter field in bytes (big-endian) |
| 8–9 | Data length | 2 | Length of the data field in bytes (big-endian) |
| 10 | Parameter | PL | Function-specific parameters (function code, item count) |
| 10+PL | Data | DL | Function-specific data (address specifications, read/write values) |
Total S7-Comm PDU size = 10 + Parameter length + Data length. All multi-byte integers are big-endian. S7-Comm is the same protocol on PROFINET and PROFIBUS DP — only the transport differs. This is why the same S7-Comm dissector in Wireshark decodes frames from both networks.
Decoding the Captured Frame
The captured 74-byte frame is shown below with column offsets for clarity:
Offset Hex Bytes
------ -----------------------------------------
0x00 68 44 44 68 81 87 5C 14 14 F1 5C 32 03
0x0D 00 00 00 01 00 02 00 2F 00 00 04 08 FF
0x1A 04 00 08 A7 00 FF 04 00 08 A6 00 FF 04
0x27 00 08 A5 00 FF 04 00 08 A4 00 FF 04 00
0x34 08 A3 00 FF 04 00 08 A2 00 FF 04 00 08
0x41 A1 00 FF 04 00 08 A0 C0 16
Field-by-field interpretation:
| Offset | Hex | Field | Decoded |
|---|---|---|---|
| 0x00 | 68 | SD | Start Delimiter = 0x68 → SD2 variable-length frame |
| 0x01 | 44 | LE | Net data length = 68 bytes (DA through DU inclusive) |
| 0x02 | 44 | LEr | Repeated length (must equal LE; receiver sanity check) |
| 0x03 | 68 | SD | Repeated Start Delimiter |
| 0x04 | 81 | DA | Destination Address = 129 (0x81) — the HMI |
| 0x05 | 87 | SA | Source Address = 135 (0x87) — the S7-300 master |
| 0x06 | 5C | FC | Function Code = SRD, request with reply, variable data |
| 0x07–0x08 | 14 14 | S7-DP prefix | Constant identifier for S7-Comm over PROFIBUS DP |
| 0x09 | F1 | Function group | 0xF1 = S7 standard functions |
| 0x10 | 5C | Service ID | S7 SRD with data payload |
| 0x11 | 32 | Protocol ID | S7-Comm magic byte |
| 0x12 | 03 | ROSCTR | 0x03 = AckData (response with payload) |
| 0x13–0x14 | 00 00 | Redundancy ID | 0x0000 — single-CPU system |
| 0x15–0x16 | 00 01 | PDU reference | Sequence number 1 (echoed from the HMI's request) |
| 0x17–0x18 | 00 02 | Parameter length | 2 bytes of parameter follow |
| 0x19–0x1A | 00 2F | Data length | 47 bytes of data follow |
| 0x1B–0x1C | 00 04 | Parameter | Function code 0x04 (Read Var) in big-endian |
| 0x1D | 08 | Item count | 8 data items returned |
| 0x1E+ | data | Item array | 8 read-response items of 6 bytes each (48 bytes total) |
| 0x49 | C0 | FCS | Frame Check Sequence (8-bit sum, modulo 256, of bytes DA through DU) |
| 0x4A | 16 | ED | End Delimiter = 0x16 |
Each of the 8 read-response items in the data field follows the S7-Comm item structure:
| Item Field | Bytes | Description |
|---|---|---|
| Return code | 1 | 0xFF = success; 0x0A = item not available; 0x05 / 0x07 = access error |
| Transport size | 1 | 0x04 = WORD; 0x02 = BYTE; 0x06 = DWORD; 0x01 = BIT |
| Length (bits) | 2 | Data length in BITS (not bytes) — 0x0008 = 8 bits = 1 byte (or 0x0010 = 16 bits for a WORD) |
| Data | variable | Returned value, big-endian |
Item-by-item extraction of the captured response:
| Item | Return | Size | Length (bits) | Data (hex) | Value (decimal) |
|---|---|---|---|---|---|
| 1 | 0xFF | 0x04 (WORD) | 0x0008 | A7 00 | 0xA700 = 42,880 |
| 2 | 0xFF | 0x04 (WORD) | 0x0008 | A6 00 | 0xA600 = 42,496 |
| 3 | 0xFF | 0x04 (WORD) | 0x0008 | A5 00 | 0xA500 = 42,240 |
| 4 | 0xFF | 0x04 (WORD) | 0x0008 | A4 00 | 0xA400 = 41,984 |
| 5 | 0xFF | 0x04 (WORD) | 0x0008 | A3 00 | 0xA300 = 41,728 |
| 6 | 0xFF | 0x04 (WORD) | 0x0008 | A2 00 | 0xA200 = 41,472 |
| 7 | 0xFF | 0x04 (WORD) | 0x0008 | A1 00 | 0xA100 = 41,216 |
| 8 | 0xFF | 0x04 (WORD) | 0x0008 | A0 00 | 0xA000 = 40,960 |
Note on length interpretation: The Length field of 0x0008 (8 bits) is ambiguous. It could represent one BYTE (8 bits) for a sub-item, or it could indicate an unaligned 8-bit item within a WORD-granularity response. The original user reported 8 distinct values A7, A6, A5, A4, A3, A2, A1, A0 — one per item — which matches a multi-item read of MW0 through MW14 in big-endian byte order. Confirm by checking the request frame that originated this response; the request defines the address and transport size, the response mirrors it.
S7ANY Address Specification
The address of each item in an S7 read/write request (not the response) is encoded in the S7ANY structure:
| Offset | Field | Size (bytes) | Values |
|---|---|---|---|
| 0 | Item specification | 1 | 0x12 = variable specification |
| 1 | Length of address | 1 | 0x0A (10 bytes) for S7ANY |
| 2 | Syntax ID | 1 | 0x10 = S7ANY |
| 3 | Transport size | 1 | 0x01=BIT, 0x02=BYTE, 0x04=WORD, 0x06=DWORD, 0x07=REAL, 0x09=TIMER/COUNTER, 0x11=STRING, 0x12=COUNTER, 0x13=TIMER |
| 4–5 | Count | 2 | Number of elements (words, bytes, bits) |
| 6–7 | DB number | 2 | Data block number; 0 = no DB (for Merkers, Inputs, Outputs) |
| 8 | Area | 1 | 0x81=Inputs (I), 0x82=Outputs (Q), 0x83=Merkers (M/MB/MW/MD), 0x84=Data Blocks (DB), 0x1C=Counter (C), 0x1D=Timer (T) |
| 9–11 | Byte offset | 3 | Byte address within the area (big-endian, 24 bits) |
| 12 | Bit offset | 1 | Bit address within the first byte (0–7); only for BIT transport size |
For an HMI reading MW0 (Merker Word 0), the S7ANY in the request would be: 12 0A 10 04 00 01 00 00 83 00 00 00 00. This means: variable specification, 10-byte address, S7ANY, WORD, count = 1, DB 0, area = Merkers, byte offset = 0, bit offset = 0.
Memory Address Mapping for MW0, MB0, MB1
PROFIBUS DP does not carry symbolic tag names; it carries numeric addresses. The HMI configuration defines the mapping from tag name to S7ANY. For a tag "MW0" (Merker Word 0), the byte layout in the response is:
| PLC Address | PLC Memory Byte | Byte Order (Big-Endian) |
|---|---|---|
| MW0 low byte | MB0 | First byte of the item data |
| MW0 high byte | MB1 | Second byte of the item data |
| MW1 low byte | MB2 | First byte of the next item data |
| MW1 high byte | MB3 | Second byte of the next item data |
For the captured response, the first item returns 0xA7 0x00 in big-endian. Therefore:
- MB0 = 0x00 (low byte of MW0)
- MB1 = 0xA7 (high byte of MW0)
- MB2 = 0x00 (low byte of MW1 = 0xA6 0x00)
- MB3 = 0xA6 (high byte of MW1)
- MB4 = 0x00 (low byte of MW2 = 0xA5 0x00)
- MB5 = 0xA5 (high byte of MW2)
- ... and so on through MB15 = high byte of MW7 = 0xA0
The byte order depends on the S7 CPU. S7-300 and S7-400 store WORD values in big-endian on the wire (high byte first). The S7-1200 and S7-1500 families follow the same convention for backward compatibility. If you observe reversed byte order on the HMI, the issue is typically in the HMI's interpretation (e.g., a little-endian display) rather than in the S7 protocol itself. Check the HMI's tag properties dialog for a byte-swap option.
Diagnostic Tools and Frame Capture
To capture a PROFIBUS DP frame for analysis, use one of the following tools:
| Tool | Type | Capability |
|---|---|---|
| Procentec ProfiHub / ProfiTrace | Hardware tap + software | Live frame capture with telegram statistics, scope view, signal quality |
| Softing PROFIusb / PROFIcab | USB/CAN tap | Frame capture and live decode |
| Wireshark with PROFIBUS dissector | Software | Decodes SD2 telegrams, S7-Comm PDUs, and S7ANY structures |
| RS232 / RS485 converter + serial capture | Low-cost | Raw byte capture (no PROFIBUS decoding; manual analysis required) |
| Siemens SIMATIC Automation Tool | Software | Network diagnostics from a programming device |
When migrating an old HMI to a new HMI on PROFIBUS DP, the following points must be verified:
- Address assignment: The new HMI must use the same PROFIBUS address as the old one (in our example, 0x81 = 129). Mismatched addresses prevent the Class 1 master from passing the token.
- Tag configuration: Import the tag database from the old project. If the old project is in a proprietary binary format (the *.img / backup image), use the original HMI configuration tool (e.g., WinCC flexible, ProTool, TIA Portal) to export it as CSV or open it in TIA Portal.
- S7 connection parameters: Rack and slot of the S7-300 CPU (e.g., rack 0, slot 2 for a CPU 315-2 DP). These are encoded in the S7 connection establishment and are separate from the cyclic exchange.
- Bus parameters: Baud rate (typically 1.5 Mbit/s or 12 Mbit/s) and slot time must match across all masters. Mismatches cause the Class 1 master to fail to enumerate the HMI.
- HMI image restore: The image file from the old HMI contains a binary backup that is version-locked to the original firmware. Restoring to a different firmware revision may fail; the safest path is to use the configuration tool to transfer the project fresh.
Note on HMI image files: A backup image taken from a TP/OP panel via serial (RS232) is tied to that specific panel's hardware and firmware. It cannot be transferred to a panel of a different type or firmware version using a generic upload tool. Use the original configuration software (ProTool, WinCC flexible, TIA Portal) to recompile the project for the new panel. If the source project file is lost, contact the panel manufacturer for image-conversion services or rebuild the project from the PLC tag list.
Troubleshooting PROFIBUS DP Communication
Use the following matrix to diagnose common faults observed when decoding PROFIBUS DP traffic:
| Symptom | Likely Cause | Verification / Remediation |
|---|---|---|
| LE != LEr | Frame corruption (bit error, noise) | Check cable shielding, termination, baud rate; verify signal with scope |
| FCS mismatch at receiver | Bit error after transmission; cable too long | Reduce baud rate, add repeater; check segment length (e.g., 200 m at 1.5 Mbit/s, 100 m at 12 Mbit/s) |
| SA = 0xFF | Invalid source address (reserved) | Reconfigure the offending master's address; 0xFF is broadcast |
| DA = 0x00 | Reserved address | PROFIBUS does not assign address 0; check for default slaves |
| Token cycle stalls | Class 2 master holds token beyond TH2 | Reduce HMI tag poll rate, offload heavy logic to Class 1 |
| ROSCTR = 0x02 instead of 0x03 | Response with NO data (error or empty read) | Check return code in data field (0xFF = success, others = error) |
| Return code 0x0A in item | Item not available / invalid address | Verify S7ANY area code and byte offset against PLC hardware configuration |
| Return code 0x05 or 0x07 | Access error / protection violation | Check S7 password protection, data block access rights in STEP 7 |
| PDU reference mismatch | Lost or reordered frames | Check retransmission counter; investigate bus errors with ProfiTrace |
| Identical values for all 8 items | HMI polling the same address repeatedly | Verify tag configuration in HMI project; check for stale cached values or merged tags |
| S7 protocol ID not 0x32 | Different protocol (FMS, DP-V1 services) | Check Function Code; FMS uses FC < 0x10; DP-V1 uses FC 0x6C with MS1/MS2 acyclic calls |
Verification Checklist
Run through the following checks after interpreting a captured frame:
- The first byte is 0x68 (SD2), 0x10 (SD1), 0xA2 (SD3), or 0xDC (SD4) — anything else indicates framing error.
- LE == LEr — otherwise the receiver will discard the frame.
- DA is the expected destination address (in our example, 0x81 for the HMI).
- SA is the expected source address (in our example, 0x87 for the S7-300).
- FC is valid for the observed service (SRD = 0x5C, Token = 0xDC in SD4, etc.).
- If S7-Comm is present, the first 4 DU bytes are
14 14 F1 5C(or14 14 F1 51for no-data services). - The S7 protocol ID is 0x32 and ROSCTR is one of 0x01/0x02/0x03/0x07.
- Parameter length and data length in the S7 header are consistent with the total S7-Comm PDU size:
10 + PL + DL = PDU size after the 4-byte prefix. - The S7-Comm PDU fits inside the outer DU:
PDU size + 4 (prefix) = LE - 3 (DA + SA + FC). - FCS equals the unsigned 8-bit sum (modulo 256) of bytes DA through DU.
- The last byte is 0x16 (ED).
Frequently Asked Questions
What is the difference between Class 1 and Class 2 master in PROFIBUS DP?
Class 1 masters (DPM1) are controllers such as the S7-300 CPU that cyclically exchange I/O data with assigned slaves. Class 2 masters (DPM2) are HMI panels, SCADA servers, or programming devices that acyclically read/write parameters during the token gap time. An S7-300 with a DP port is a Class 1 master; an HMI connected via PROFIBUS DP is a Class 2 master that receives the token briefly from the S7-300.
Why is the SD byte 0x68 in the captured frame?
The 0x68 value identifies an SD2 variable-length data telegram, which is the format used for S7 communication, cyclic I/O exchange, and parameter assignment. PROFIBUS DP defines four SD values: 0x10 (SD1, fixed, no data), 0x68 (SD2, variable), 0xA2 (SD3, fixed 8-byte data), and 0xDC (SD4, token). The 0x68 in your frame therefore signals an SD2 telegram.
Where is the MB0 address in the frame?
The byte-level address is not carried in the response — the S7 response contains only data values. The address is defined in the S7ANY field of the request. For an HMI reading MW0 (Merker Word 0), MB0 is the low byte (first byte returned) and MB1 is the high byte (second byte returned) in big-endian. In your captured frame, MW0 = 0xA7 0x00 means MB0 = 0x00 and MB1 = 0xA7.
What is the S7 protocol ID 0x32 and where does it appear?
0x32 is the S7-Comm protocol magic byte that begins the S7 communication header inside the PROFIBUS DP data unit. It appears after the 4-byte PROFIBUS-specific prefix (0x14 0x14 0xF1 0x5C) and before the ROSCTR byte. The same magic byte 0x32 is used on PROFINET and PROFIBUS DP, making the S7-Comm PDU transport-independent.
Why does the Function Code (FC) change between telegrams from the same HMI?
The FC field encodes the service type and frame class. For a Class 2 master, the FC is dynamically selected by the S7 runtime to match the current operation: 0x5C for SRD with data (most read/write responses), 0x5D for SRD low, 0x44 for Read Inputs, 0x47 for Read Outputs. A new tag request may produce a different FC than the previous one even if both are reads.
How can I find the source address (SA) of my S7-300 on PROFIBUS DP?
The S7-300 PROFIBUS address is set in the hardware configuration (HW Config) in STEP 7, under the CPU properties → PROFIBUS interface → Parameters → PROFIBUS address. The default is 2, but it can be 1–125. In the captured frame, the SA byte 0x87 = 135 is the S7-300's configured address. Verify against the PLC project file to confirm.
How do I transfer the old HMI's image file to a new HMI?
An image file taken from an HMI is firmware-locked to the specific panel model. It cannot be transferred to a panel of a different type or firmware version using a generic serial upload. The reliable path is to open the original configuration in ProTool, WinCC flexible, or TIA Portal, change the target device to the new panel, recompile, and download the project. If the source project file is unavailable, rebuild the tag list from the PLC's symbol table or by reading the S7ANY addresses from the captured PROFIBUS traffic.