Resolving TIA Portal Special Character (°C) Warning on S7-300

1. Problem Overview

When compiling a STEP 7 project in TIA Portal targeting an S7-300 CPU (or S7-400, WinAC, and earlier S7-200 SMART generations), engineers that assign temperature units such as °C or °F directly inside a Data Block string field receive the following compiler information:

The text '°C' contains special characters. Note that the display of special characters depends on the regional and language settings on the programming device.

The message is classified as a Warning, not an error: the project still downloads, the PLC still runs, and the HMI still renders the string. The problem is operational, not functional. In a 300-CPU project with dozens of measurement channels (oven profiling, refrigeration, HVAC, sterilization, semiconductor wet benches, food and pharma skids), this single warning is multiplied by every tag, every recipe row, and every alarm that embeds a degree symbol. The compile log balloons to hundreds or thousands of identical messages and legitimate warnings (precision loss, uninitialized tags, pointer range violations) become effectively invisible.

The original symptom report in field installations typically shows:

• Warning count: 50 to 1,200 occurrences per project (with localized projects in French, German, Spanish, and Italian hitting the upper bound).
• CPU family: SIMATIC S7-300 (CPU 31x, CPU 31xT, CPU 31xC, ET 200S IM151-7).
• Tool: TIA Portal V15 through V19 (the warning text is identical across all versions because the source-code parser has not changed).
• Affected objects: STRING / CHAR constants in DBs, FB/FC input parameters with default values, multi-instance DB comments, and project text libraries referenced by WinCC Comfort/Advanced.

2. Root Cause Analysis

The S7-300 STRING data type is an ASCII array, not Unicode. The default code page used by TIA Portal is Windows-1252 (CP1252), an 8-bit single-byte extension of ASCII where the degree sign ° occupies code point 0xB0 (decimal 176). The TIA Portal source-code parser flags every literal character whose code point lies above 0x7F as a "special character" because the same byte value renders as a different glyph on a different code page (for example, on an Eastern-European Windows-1250 system the same 0xB0 is a different glyph entirely).

To prevent inconsistent rendering between engineering stations, the TIA compiler treats the literal as informational rather than fatal. The resulting warning has three properties that make it pathological in production code bases:

1. It is non-suppressible. There is no project-wide Suppress warning flag in the TIA Portal compiler for S7-300 targets; S7-1500 and S7-1200 targets inherit the same limitation because the warning comes from the textual SCL/ST parser, not from the PLC firmware.
2. It is not filterable. The compiler output window in TIA Portal has three toggle buttons (Information / Warnings / Errors), but no text-filtering column. The user is forced to scroll through every occurrence.
3. It is not localized. The wording is fixed in English regardless of the TIA Portal user-interface language; only the optional hint about regional settings changes.

Confirming the diagnosis is straightforward:

1. Open the affected DB in the TIA Portal project tree.
2. Select the STRING variable whose Initial Value or Default Value contains the degree symbol.
3. Switch the Monitor view to Hex to verify the byte at the string position is 16#B0 and the following byte is 16#43 (the ASCII code for 'C').
4. Note the matching warning in the Inspector window under Info > Compile.

3. Affected Versions and Targets

4. Solution Methods

Four engineering-grade workarounds exist. Each removes the warning without changing the rendered glyph on the HMI. Choose based on whether the unit string is stored in the PLC, in the HMI, or assembled at runtime.

4.1 Method A — Remove the Degree Symbol from the DB String

The fastest fix and the one preferred by most maintenance teams: drop the unit suffix from the PLC string and concatenate it at the HMI. The PLC stores a numeric value, the HMI paints the unit via a static text element placed adjacent to the I/O field. Operators see 73.4 °C, the PLC stores 73.4 as REAL, and the warning disappears completely.

Drawback: any other consumer of the string (alarm log, recipe report, e-mail notification, OPC UA tag) loses the unit suffix. Solve by either (a) prefixing the unit in the consuming application or (b) using a separate STRING constant for log output, populated through Method B below.

4.2 Method B — Hex-Encoded Constant with Chars_TO_Strg

When the unit string must live in the PLC (recipe audit trail, OPC UA server tag, archive export, or printable report), build the string from a hex literal. The degree sign is 16#B0 in CP1252 and the capital letter C is 16#43. Pack both into an ARRAY[0..1] OF CHAR constant and convert to STRING with the standard library block Chars_TO_Strg from the IEC Function Blocks palette.

Step-by-step:

1. Create a new global DB named DB_Units with the following layout:

2. Add an SCL program block FB_UnitInit (or call once in OB100) that performs the conversion in startup:

// FB_UnitInit - Build °C and °F unit strings from hex constants
// No special characters appear in the SCL source -> no warning

#degC_str := '';                       // clear target
Chars_TO_Strg(Chars := "DB_Units".degC_raw,
              pString := #degC_str,
              Cnt := 2);

3. After OB100 completes, "DB_Units".degC_str contains the two-byte sequence 0xB0 0x43, which WinCC renders as °C when the HMI project is set to the Windows-1252 codepage (the default in TIA Portal).
4. Reference the assembled STRING in your HMI tag list; bind to a symbolic I/O field or a text list.

Verification of the byte sequence: open the STRING variable in Monitor > Hex. Expected output for °C:

Offset 0: B0
Offset 1: 43
Offset 2: 00   (STRING terminator)

4.3 Method C — HMI-Side Static Text Adjacent to I/O Field

For panel families that reject extended characters in the I/O field (older MP 277, MP 377, KTP 600/1000 Basic), add a static text element on the WinCC screen positioned immediately to the right of the output field. The static text field accepts extended characters; the output field does not need to. Configure the static text as follows:

• Property Text = °C
• Property Display = transparent background, same font, same vertical alignment as the I/O field
• Property Position = right edge of the I/O field plus 2 px gap

This approach is also the recommended fix when a project must support multiple languages that use different unit glyphs (German and Italian use °C, English often uses degC). Drive the static text from a text list indexed by the current runtime language; the HMI language change automatically swaps the suffix.

4.4 Method D — Text List Indexed by Language

For multi-language projects, build a WinCC text list TextList_Units with one entry per language. The I/O field references the list by index, the runtime language selection picks the correct glyph. The list values are still subject to the same source-code warning only if the degree sign is entered through the keyboard. Workaround: paste the glyph from the Windows Character Map at code point U+00B0 (BMP, Latin-1 Supplement), and the warning still fires. The clean variant is to use a numeric I/O field with a separate symbolic I/O field for the unit, both bound to the same index tag. Avoid Method D when the unit must travel with the value through OPC UA — use Method B instead.

5. Working Code Examples

5.1 SCL Function Block — Full Implementation

FUNCTION_BLOCK "FB_UnitStrings"
VAR
    // Constant byte arrays, no literal special characters in source
    degC_raw   : ARRAY[0..1] OF CHAR := [16#B0, 16#43];
    degF_raw   : ARRAY[0..1] OF CHAR := [16#B0, 16#46];
    delta_raw  : ARRAY[0..1] OF CHAR := [16#94, 16#43];
END_VAR
VAR_OUTPUT
    sCelsius   : STRING[2];
    sFahrenheit: STRING[2];
    sDelta     : STRING[2];
END_VAR
BEGIN
    // Use the standard IEC Chars_TO_Strg function from the library
    Chars_TO_Strg(Chars := #degC_raw,    pString := #sCelsius,    Cnt := 2);
    Chars_TO_Strg(Chars := #degF_raw,    pString := #sFahrenheit, Cnt := 2);
    Chars_TO_Strg(Chars := #delta_raw,   pString := #sDelta,      Cnt := 2);
END_FUNCTION_BLOCK

5.2 STL Snippet — Equivalent in Classic STEP 7

// Assumes DB_Units is the instance DB of FB_UnitStrings
      CALL  "Chars_TO_Strg"
        Chars  := "DB_Units".degC_raw
        Cnt    := 2
        pString := "DB_Units".sCelsius
      NOP   0

5.3 LAD Network — Symbolic Approach

For engineers preferring ladder, the conversion is wrapped in an FB. Drop the FB on a network, connect the EN line to a first-cycle bit, and the two output strings are valid for the entire runtime session. The source code of the FB contains no special characters, so the compiler emits zero warnings.

6. Verification Procedure

1. Save and compile the project. Open the Inspector pane and select Info > Compile.
2. Download the project to the S7-300 CPU and switch to Online > Monitor > Hex on DB_Units.sCelsius. Confirm bytes B0 43 00 are present.
3. Start WinCC Runtime on the HMI. Confirm the I/O field bound to sCelsius shows °C as a suffix.
4. Cycle the project language in the HMI (English → German → French → Italian). Confirm the glyph remains correct in every language that uses CP1252; for non-Latin languages (Chinese, Japanese, Korean) confirm a no glyph fallback does not appear — if it does, switch the HMI codepage to UTF-8 in the WinCC project properties.
5. Export the project archive. Re-import on a second engineering station. Re-compile. Confirm zero warnings.

7. Best Practices and Field-Proven Caveats

• Source-code hygiene: avoid pasting the degree glyph from Word, e-mail clients, or web browsers. The pasted byte sequence may include a UTF-8 BOM or combining diacritic that breaks CP1252 alignment and produces garbled characters on the HMI.
• OPC UA consumers: S7-300 OPC UA servers expose STRING tags as byte arrays. Make sure the OPC UA partner application interprets the bytes as CP1252, not UTF-8. A mismatch turns 0xB0 0x43 into a replacement character on the client side.
• Recipe data sets: if the recipe stores the unit string in a binary file, the degree sign is preserved across download/upload cycles only when the codepage matches. Document the codepage requirement in the recipe header comment.
• Audit and FDA validation (pharma): Method A (drop the unit) is preferred in 21 CFR Part 11 environments because it removes a variable from the validation surface. Method B is acceptable but must be unit-tested to confirm byte-for-byte identity with the original string.
• S7-1500 / S7-1200 path forward: the same warning exists, but those CPUs support WSTRING (Unicode). For new development, prefer WSTRING in DBs and bind the HMI to a Symbolic I/O field with Unicode codepage. The TIA Portal compiler does not flag WSTRING literals because they are 16-bit per character and unambiguous.
• Template projects: maintain a project-level template with DB_Units pre-built. Distribute the template to every developer so that new projects start warning-free.

8. Troubleshooting Matrix

9. Related Siemens Documentation

For deeper coverage of STRING handling and codepage behavior, refer to the official Siemens support portal:

• SIMATIC S7-300 Automation System System Manual — chapter on data types and STRING layout.
• STEP 7 Professional V19 Programming and Operating Manual — section on Chars_TO_Strg and IEC string conversion functions.
• WinCC Comfort V19 System Manual — codepage configuration for I/O fields and text lists.