ProTool V6.0 SP2 Oversized Fonts on New PC: DPI Fix

1. Problem Description

A ProTool V6.0 SP2 project that compiles and renders correctly on the original engineering notebook suddenly shows enlarged fonts and oversized input fields when opened on a different, newer Windows notebook. Buttons, IO fields, text lists, and status displays all appear at a larger physical size; the layout still fits the screen, but the typography is mismatched against the original panel image, and re-importing the compiled HMI binary into the target MP370 produces screens that look different from what was approved during acceptance.

This is one of the most common ProTool engineering complaints in mixed-fleet environments and almost always correlates with the engineering PC being upgraded (e.g. Windows XP SP3 with 96 DPI default replaced by Windows 7 / 10 with 100 % or 125 % scaling default). The PLC side of the system (S7-315-2DP, MPI/Profibus DP) is not at fault; the issue is purely in the ProTool configurator on the engineering workstation and in the way the configurator stores font sizes relative to the Windows display driver.

2. Affected Software and Hardware Versions

3. Root Cause: Windows DPI Scaling Mismatch

ProTool V6.0 SP2 was developed for Windows XP and assumes a 96 DPI (100 %) display. The configurator's text output, IO field sizing, and layout grid are sized in device-independent pixels relative to a 96 DPI base. When the configurator is launched on a Windows 7 / 10 / 11 notebook whose display is set to a higher DPI (commonly 120 DPI / 125 % or 144 DPI / 150 %), the Windows GDI subsystem reports a different pixels-per-inch value, and ProTool — being a legacy DPI-unaware Win32 application — scales its font metrics proportionally.

The visible symptom is unambiguous:

• Fonts in the ProTool editor (label text, button captions, alarm text) appear roughly 25 %–50 % larger than on the source PC.
• IO field input boxes are enlarged because the field height is computed from font metrics.
• The compiled *.fwd runtime file loaded onto the MP370 carries the same enlarged metrics, so the runtime panel looks different from the original.
• Object positions (X/Y on the screen grid) are unaffected — only text and field height change.

Cross-checking the original engineering PC: the source PC almost certainly runs at 96 DPI, while the new notebook is at 120 DPI (125 % scaling) or 144 DPI (150 % scaling). Reverting the new PC to 96 DPI restores correct rendering, which is the diagnostic confirmation.

4. Solution: Match DPI Settings Between Source and Target PC

1. Close ProTool V6.0 SP2 and the STEP 7 SIMATIC Manager if either is running.
2. Right-click the Windows desktop, choose Display settings (Windows 10) or Personalize → Display (Windows 8.1).
3. Under Scale and layout, set the Change the size of text, apps, and other items dropdown to 100 % (Recommended). This forces 96 DPI.
4. Click Apply and sign out / sign back in (or reboot) so all GDI handles reinitialize.
5. Re-launch ProTool V6.0 SP2 and open the project. Fonts and IO field heights will now render at the original size.
6. Re-compile the project, regenerate the *.fwd file, and re-transfer to the MP370.

5. Per-Application DPI Override for ProTool

For workstations that must remain at 125 % or 150 % scaling for usability with other tools (Office, EPLAN, TIA Portal), force ProTool to run in system DPI unaware mode at 96 DPI:

1. Locate the ProTool executable, typically:
   • C:\Program Files\Siemens\Automation\ProTool_V62\Bin\ProTool.exe
   • C:\Program Files (x86)\Siemens\Automation\ProTool_V62\Bin\ProTool.exe
2. Right-click → Properties → Compatibility tab.
3. Click Change high DPI settings.
4. Under Program DPI, check Override high DPI scaling behavior and select System (Enhanced) or Application.
5. Also enable Run this program in compatibility mode for: Windows XP SP3.
6. Click OK twice.
7. Launch ProTool — fonts will render at 96 DPI even though the desktop is at 125 %.

The same override is recommended for the ProTool runtime builder PTProCS.exe and the STEP 7 SIMATIC Manager S7MANAGR.exe when used together. Save the override to a registry-friendly manifest if you want to deploy it across an engineering team via group policy.

6. Verification

1. Open the ProTool project and visually compare a known text object (e.g. a screen title) against a screenshot from the source PC — font height and IO field height must match within 1 pixel.
2. Compile the project. The resulting *.fwd file size should be identical (or within <1 %) to the previous build — a large delta indicates object sizes changed.
3. Transfer the binary to the MP370 using ProSave over Ethernet or MPI and confirm runtime display.
4. On the MP370, navigate the screens and verify that long text strings still fit inside the IO fields (a sign that the font metric is now correct).
5. Repeat for all three MP370 panels to confirm consistent appearance.

7. Secondary Issue: VBScript FileCopy Does Not Work on MP370

The same engineering thread raises a second, common MP370 / Windows CE problem: the VBScript function call f.FileCopy filename1, filename2 is accepted by the ProTool script editor at compile time but the runtime on the MP370 does not execute the copy. The MP370 returns no error, but the destination file never appears.

Root cause: The MP370 runtime supports a subset of VBScript. The full FileSystemObject from scrrun.dll is not present on Windows CE 5.0 — only a few file I/O functions (open, read, write, close, line input) are exposed via the ProTool VBScript host. FileCopy, CopyFile, DeleteFile, and similar methods have no implementation on WinCE. The ProTool script editor does not validate against this runtime subset, so compile-time acceptance does not guarantee runtime behavior.

Siemens documents this limitation in FAQ entry Entry ID 13408815 — "Which VBScript functions are supported on Windows CE panels?" The runtime supports file stream operations through Open ... For Input / Output / Append, Line Input #, Print #, Close, plus basic directory checks via Dir(). The full FileSystemObject object model is unavailable.

8. Workaround: Replace FileCopy With Stream Read/Write

' ProTool VBScript on MP370 / WinCE 5.0
' Copy a text file using the runtime-supported stream API.

Sub CopyFile_OnRuntime(srcPath, dstPath)
    Dim fIn, fOut, sLine
    Set fIn  = CreateObject("ADODB.Stream")
    Set fOut = CreateObject("ADODB.Stream")
    fIn.Mode  = 3          ' adModeReadWrite
    fIn.Type  = 2          ' adTypeText
    fIn.Charset = "ascii"
    fIn.Open
    fIn.LoadFromFile srcPath
    fIn.Position = 0
    fIn.CopyTo fOut
    fIn.Close
    ' Persist destination via direct file write (alternative pattern):
    Dim ff, i
    Set ff = fOut
    ff.SaveToFile dstPath, 2   ' adSaveCreateOverwrite
    ff.Close
End Sub

If the ADODB.Stream object is not available on the target CE build, fall back to the explicit line-by-line read/write pattern (the approach already in use on the affected project):

' Fallback pattern - read source into array, write to destination.
' This is the method the operator is already using to bypass the
' FileCopy limitation; it works on every MP370 / WinCE build.

Dim arrLines(10000), i, n
Dim f, s
n = 0

' --- Read source file ---
f = OpenFile("\\Storage Card\\PLC\\source.csv", fmOpenRead)
Do While Not Eof(f)
    Line Input #f, s
    arrLines(n) = s
    n = n + 1
Loop
Close #f

' --- Write destination file ---
f = OpenFile("\\Storage Card\\PLC\\dest.csv", fmOpenWrite)
For i = 0 To n - 1
    Print #f, arrLines(i)
Next i
Close #f

This pattern is functionally equivalent to FileCopy for text-based logs, recipe files, and CSV exchanges between the S7-315-2DP and the panel — but executes on the WinCE 5.0 runtime. Performance is the documented concern in the original case (the operator noted "Spending a lot of time on the network"), so prefer it for small files (≤256 KB). For large data sets, consider switching the integration from file-based to tag-based block transfer over MPI/Profibus DP, where the S7-315-2DP and MP370 exchange data via process tags without any file I/O.

9. VBScript on Windows CE: Full Function Support Matrix

10. MP370 Runtime Image and Firmware Considerations

The MP370 panel comes in two primary hardware variants that share a WinCE 5.0 runtime but differ in image size and supported features:

• MP370 Touch 12" / 15" — 6AV6 545-0BA15-2AX0 / -0CA15-2AX0
• MP370 Key 12" / 15" — 6AV6 545-0BB15-2AX0 / -0CB15-2AX0

The runtime image version (read on the panel under Start → Settings → Control Panel → OP → Info) must match the ProTool configurator's expected runtime. Recommended baseline for projects using VBScript file I/O is image ≥ V6.0.4.0. Earlier images lack the ADODB.Stream registry keys even if the file is present on disk. Update the image using ProSave (Siemens order number Entry ID 21827968 — ProSave V6.x) over Ethernet, MPI, or USB.

For the S7-315-2DP side, verify that the DP bus profile configured in STEP 7 (baud rate, slot time, Ttr) is consistent across all three MP370 nodes. Mismatched DP parameters on a mixed-fleet project can produce the same "runtime looks different" symptom but originate from tag-update latency, not font metrics — rule this out before re-uploading the runtime image.

11. Long-Term Recommendation: Migrate to WinCC flexible

ProTool V6.0 SP2 is end-of-life and Windows 7 / 10 are out of mainstream engineering support for it. The recommended path forward is to migrate the project to WinCC flexible 2008 SP3 (the last release that supports MP370) and then to TIA Portal WinCC Comfort/Advanced (which supports the successor panels TP1500 / TP2200 Comfort). The migration tool is invoked from the WinCC flexible project administration:

1. Open WinCC flexible 2008 SP3.
2. File → Migration → Migrate ProTool Project.
3. Select the *.pdb / *.ldb source and the target panel (MP370 or successor).
4. Run the converter. WinCC flexible reports conversion warnings — accept and resolve fonts, area pointers, and tag connections.
5. Re-compile, transfer, and validate on the panel.

WinCC flexible handles DPI scaling on Windows 7 / 10 correctly because it is built against a modern .NET / Win32 GDI stack. The original DPI mismatch symptom disappears on the engineering side once the project is migrated. Refer to the official migration guide at Entry ID 22031831 — Migrating from ProTool to WinCC flexible.

12. Troubleshooting Matrix