1. Problem Definition and Architecture
Reading an 8-bit value (a byte, address VB1000) from a Siemens SIMATIC S7-200 CPU into a WinCC HMI/SCADA tag is one of the most common points of failure when the S7-200 is connected to WinCC through the S7-200 PC Access OPC server. The byte arrives correctly inside PC Access (the value 192 shown for VB1000 is verified there) but the WinCC tag either shows a wrong value, an error, or no update at all.
The root cause is almost always a data-type mismatch between the S7-200 memory representation (BYTE / unsigned 8-bit) and the way the WinCC tag manager interprets the OPC item. The fix is to set the correct WinCC data type together with the correct format adaptation rule.
The data path is:
S7-200 CPU (VB1000, BYTE)
| PPI/MPI/TCP via CP243-1
v
S7-200 PC Access (OPC DA 2.0 server, item = VB1000, BYTE)
| DCOM / local OPC
v
WinCC Tag Management (Tag = S7_200_VB1000, configured data type)
The crucial detail: the byte must be exposed by PC Access as an OPC item of type VT_UI1 (unsigned 8-bit) or, when the full register is delivered, VT_I1. The WinCC tag must then consume that item with a matching format adaptation rule.
VB1000 as an unsigned 8-bit BYTE. A value of 192 decimal = 0xC0 = 1100 0000 binary. If WinCC reads the item as a signed 16-bit WORD it will display 65472 (0xFFC0) because the high byte is sign-extended. Always force an 8-bit data type path.
2. S7-200 Memory Model – What VB1000 Really Is
The V (Variable) memory area of the S7-200 is a byte-addressable RAM region that holds the process image, retentive data, and freely usable scratch bytes. The addressing scheme is:
| Prefix | Width | Example | Range per CPU 224 XP | Range per CPU 226 |
|---|---|---|---|---|
VB |
BYTE (8 bits, unsigned 0..255) | VB1000 | VB0..VB10239 | VB0..VB10239 |
VW |
WORD (16 bits, unsigned 0..65535) | VW1000 | VW0..VW10238 (even aligned) | VW0..VW10238 |
VD |
DWORD (32 bits) | VD1000 | VD0..VD10236 (even aligned) | VD0..VD10236 |
A VB is always the lowest byte of its containing VW. So VB1000 shares the low byte of VW1000, and VB1001 shares the high byte. When you read VW1000 you are reading two bytes; this is the most common cause of the "I read 192 in PC Access but WinCC shows 65472" symptom.
3. PC Access OPC Item Configuration
Inside S7-200 PC Access (the OPC DA 2.0 server that ships with STEP 7 Micro/WIN), create an item for the byte:
- Right-click Project > New Item > Symbol.
- Enter a symbol name, e.g.
VB1000_Byte. - Set Address to
VB1000(orVB1000:Bin some PC Access versions). - Set Data Type to Byte (unsigned 8-bit) – this is the default for VB addresses but verify it is not left as Word.
- Set Memory to V.
- Click Test. The status bar must read
192for a byte whose PLC value is 192 (0xC0).
The item is exposed on the OPC DA 2.0 interface as a VT_UI1 value. The canonical Item ID has the form:
S7-200 PC Access.SymbolName (canonical string)
S7:[S7-200_PCAccess]SymbolName,B (access path syntax in WinCC)
If the OPC test client (e.g. OPC Scout) shows the correct byte, the server side is good and the bug is in WinCC.
VB1000 can also be browsed internally as the low byte of VW1000. Make sure you do not accidentally create a Word item at the same address and let the byte item be shadowed.
4. WinCC Tag Manager – Choosing the Correct Data Type
In WinCC Explorer open Tag Management > [Your driver connection, e.g. OPC > OPC Groups] > New Tag. The tag dialog exposes four data-type families:
| WinCC radio button | OPC VT_ type expected | Width | Signed? | Recommended for VB? |
|---|---|---|---|---|
| Binary tag | VT_BOOL / bit of VT_UI1 | 1 bit | n/a | No – use only for individual bits |
| Signed 8-bit value | VT_I1 | 8 bits | Yes (-128..127) | No – VB1000=192 overflows |
| Unsigned 8-bit value | VT_UI1 | 8 bits | No (0..255) | Yes – this is the correct choice |
| Signed 16-bit value | VT_I2 / VT_UI1 sign-extended | 16 bits | Yes | No – produces 65472 for value 192 |
| Unsigned 16-bit value | VT_UI2 / VT_UI1 zero-extended | 16 bits | No | Acceptable, but redundant |
| Floating-point 32-bit IEEE 754 | VT_R4 | 32 bits | Yes | No – requires format adaptation |
| Text / string | VT_BSTR | n chars | n/a | No |
The four radio buttons shown in WinCC v6 / v7 – Binary, Signed, Unsigned, Adapt format – map to:
- Binary – exposes one bit of the underlying OPC item.
- Signed – interpreted as VT_I1, VT_I2, VT_I4 or VT_R4.
- Unsigned – interpreted as VT_UI1, VT_UI2, VT_UI4.
- Adapt format – user-defined conversion from any incoming VT_ type to a target WinCC type.
For a single byte like VB1000, select Unsigned 8-bit value in the WinCC tag properties. The radio button labeled simply "Unsigned" with length 8 bits is the correct one. Do not select 16-bit or 32-bit, because WinCC will then sign-extend or zero-extend the byte into a wider variable and your process screens will show values that are 256× (or 2^24×) too large.
5. The "Adapt Format" Option – When to Use It
The Adapt format button in the tag dialog is required only when the WinCC data type is different from the OPC item data type, for example:
| WinCC target type | OPC source type | Required adaptation (S7-200 example) |
|---|---|---|
| 16-bit signed | 8-bit unsigned (VT_UI1) byte | ByteToWord or ByteToSignedWord |
| 32-bit float (REAL) | 8-bit byte (e.g. packed status) | ByteToFloat – not a direct match, requires reconstruction |
| 32-bit signed | 8-bit byte | ByteToSignedDword |
| 16-bit unsigned | 8-bit byte | ByteToWord |
| 32-bit float (REAL) | 32-bit DWORD from VD address | DwordToFloat (handles endianness) |
| 32-bit float (REAL) | 32-bit float from VD address | FloatToFloat (no conversion, but endianness still needed on S7-200) |
For a single byte where you want a numeric 0..255 in WinCC, you do not need Adapt format. Select the simple Unsigned 8-bit data type and leave adaptation off.
Use Adapt format only in these cases:
- You deliberately want the byte scaled into a 16-bit tag because the I/O field on the screen is configured for 16 bits.
- You read a 32-bit REAL from an S7-200
VDaddress and need endianness swap (S7-200 is little-endian for the high word, so the most common adaptation isFloatToFloatorDwordToFloatapplied in the correct order). - You read a packed status word and need to extract individual bits.
VD1000 occupies the bytes VB1000 (lowest), VB1001, VB1002, VB1003 (highest). On a little-endian OPC bridge the raw DWORD is delivered low-byte first. If you see 0.0 when the PLC clearly holds a non-zero REAL, the adaptation is the wrong way round – swap the byte/word order.
6. Step-by-Step Configuration Procedure
-
Open the S7-200 PC Access project and confirm that the symbol
VB1000is configured as BYTE. The PC Access Test Client should display the value192in decimal. -
Start the PC Access OPC server (icon in the system tray turns green). The server registers itself as
S7-200 PC Accessin the Windows OPC Enum. - Open the WinCC Explorer and load your project.
- In the project tree expand Tag Management > OPC > OPC Groups. If the OPC channel is not yet present, right-click Tag Management > Add New Driver > "OPC".
- Right-click OPC Groups > New Group, name it
S7_200_Group. - Right-click the new group and choose System Parameters > Filter. Browse to the PC Access server, select the item
VB1000_Byteand add it to the selected list. The Item ID WinCC writes is the canonical name of the OPC item, e.g.S7:[S7-200_PCAccess]VB1000_Byte. - Click OK; WinCC creates a tag with a default name such as
S7-200_PCAccess_VB1000_Byteand a default data type (often Signed 32-bit – change this!). - Open the tag properties dialog. In the Data Type dropdown pick Unsigned 8-bit value. Do not tick "Adapt format" unless you need byte-to-word or byte-to-dword scaling.
- Confirm the Length field reads 8 (bits) and the Format adaptation column reads No.
- Save the project, open Graphics Designer and place an I/O field on a screen. Bind the I/O field's output value to the new tag. Set the I/O field's Output/Input format to
999(three decimal digits, leading zeros suppressed) or000(zero-padded to 3 digits) to display values 0..255 cleanly. - Activate the WinCC runtime and verify on the I/O field that the value updates to 192 (or whatever the PLC program is writing into VB1000).
7. Verification Checklist
| Check | How to verify | Expected result |
|---|---|---|
| PC Access sees the byte | PC Access Test Client → Item VB1000 | Decimal value matches PLC, e.g. 192 |
| OPC server is running | Tray icon green; dcomcnfg shows S7-200 PC Access DCOM app |
Server registered and started |
| WinCC tag data type | Tag Management → Properties → Data Type | Unsigned 8-bit value |
| Item ID in WinCC | Tag properties → Item ID | S7:[S7-200_PCAccess]Symbol |
| I/O field format | Graphics Designer → I/O field → Output/Input |
999 or 000
|
| Runtime value | Activate Runtime, watch I/O field | Decimal value of the byte (e.g. 192) |
| Diagnostics channel | WinCC diag channel on the tag | No OPC quality code other than 192 (Good) |
8. Common Failure Modes and Remedies
| Symptom | Likely cause | Fix |
|---|---|---|
| WinCC shows 65472 instead of 192 | Tag configured as Signed/Unsigned 16-bit; OPC delivered byte is sign-extended | Change tag data type to Unsigned 8-bit |
| WinCC shows 192 in upper byte of a word, lower byte 0 | Wrong VW/VD address being read; byte shared with VW1000 | Confirm PC Access item is on VB1000 not VW1000; align VW reads on even addresses |
| WinCC tag shows constant 0 | OPC server not running, or DCOM permissions | Start PC Access, configure dcomcnfg launch/activate permissions for the WinCC user |
| WinCC tag quality = Bad | PLC not connected (PPI/MPI cable, wrong baud, wrong station address) | Check PC Access test client; verify PC/PPI cable DIP switches match the CPU baud rate (9.6 / 19.2 / 187.5 kbps) |
| Value flickers / oscillates | PLC program writes VB1000 faster than WinCC polls; or multiple tags pointing at same byte with different types | Reduce update rate, remove duplicate tags |
| WinCC shows 255 always | Byte overflow in PLC (e.g. 256 → 0 wrap) | Check PLC ladder logic; ensure accumulator is cleared before storing |
| Wrong value after PLC restart | V memory is retentive, value persisted from previous run | Initialize VB1000 in first scan (SM0.1) or unmark as retentive in the data block |
| Byte exposed as float value 1.92e+2 | Tag accidentally set to Floating-point 32-bit IEEE 754 | Change to Unsigned 8-bit; remove FloatToSignedByte or FloatToUnsignedByte adaptation |
9. Reference: Official Siemens Documentation
- Siemens Support Entry 21601611 – Communication between S7-200 and WinCC via OPC (PC Access)
- Siemens Support Entry 25736087 – Format adaptation in WinCC, sorted by AS data type
- Siemens Support Entry 22892718 – Step-by-step procedure for WinCC OPC tag configuration
10. Field-Proven Caveats
- Symbol name case sensitivity: PC Access symbol names are case-insensitive on the server side but the WinCC Item ID browser may render the canonical name with a different case. Always paste the canonical Item ID, never re-type it.
-
Item ID syntax differences: On WinCC v6 the syntax is
OPCServerName\SymbolNameorS7:[OPCServerName]SymbolName. WinCC v7 TIA-converted projects may use the long form with an access path. The browse dialog in WinCC produces the correct syntax for the project version – use that, not a hand-written string. - Poll group load: Putting too many byte tags in a single OPC group raises the per-group update load on the S7-200 CPU. Split into several groups with staggered update intervals if you have more than ~500 bytes.
-
Variable storage in STEP 7 Micro/WIN: A symbol declared as
VB1000BYTE in the symbol table is functionally identical to a direct address; both expose the same memory cell to PC Access. -
Retentivity: V memory is fully retentive on the S7-200 by default. If your process requires the byte to start at 0 on power-up, clear it in the first scan using
SM0.1as the enable contact.
11. Frequently Asked Questions
What WinCC data type should I pick for a single S7-200 byte like VB1000?
Pick Unsigned 8-bit value in the WinCC tag manager. Do not enable Adapt format. The S7-200 stores the byte as 0..255, and Unsigned 8-bit is the only choice that preserves the value 192 (0xC0) without sign-extending it to 65472 (0xFFC0).
Why does WinCC display 65472 when the PLC byte holds 192?
WinCC is reading the byte into a 16-bit or 32-bit signed tag. A value of 192 (0xC0) has the high bit set, so sign extension to 16 bits produces 0xFFC0 = 65472 decimal. Change the tag data type to Unsigned 8-bit and the value will display as 192.
Do I need format adaptation to read a byte from S7-200 PC Access into WinCC?
No. Format adaptation is only required when the WinCC data type differs from the OPC item data type (for example, byte-to-word scaling, or 32-bit REAL reconstruction from a 32-bit DWORD). For a plain 0..255 byte display, leave Adapt format off and use Unsigned 8-bit directly.
Can I read a 32-bit REAL from the S7-200 (for example VD1000) into a WinCC float tag?
Yes. Create the PC Access item on VD1000 as a 32-bit DWORD, then in WinCC set the tag to Floating-point 32-bit IEEE 754 with format adaptation FloatToFloat (or DwordToFloat depending on the PC Access version). The S7-200 is little-endian for the high word, so the adaptation is required to swap the byte order.
PC Access Test Client shows 192 but WinCC shows 0. What is wrong?
The OPC server is fine. The WinCC tag has a wrong data type or the Item ID is misspelled. Open Tag Management, double-click the tag and confirm (a) the Item ID matches exactly the PC Access symbol name, and (b) the data type is Unsigned 8-bit. Also verify that the WinCC runtime is logged in as a user with DCOM launch/activate permission on the PC Access DCOM application (dcomcnfg → Component Services → Computers → DCOM Config → S7-200 PC Access → Security).