Simovert MasterDrive VC: DriveMonitor Invalid Data Type Fix

David Krause14 min read
SiemensTroubleshootingVFD / Drives
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

Problem Overview

Engineers performing commissioning or service on legacy Siemens Simovert MasterDrive VC drives (6SE70 series with CUVC control boards) frequently encounter a configuration mismatch when attempting to go online with the DriveMonitor commissioning tool. The drive is discovered on the USS bus, the operator panel OP1S communicates normally, but DriveMonitor reports “Invalid data type” for every parameter as soon as it switches to online RAM or online EEPROM mode. The “Drive type” column in the connection dialog lists the unit with question marks (e.g. ?? 6SE70 ??) instead of a recognized model string, and parameter downloads/uploads complete but contain garbage values.

This is one of the most common DriveMonitor issues on compact MasterDrive units (TC61 variant) carrying CUVC firmware V3.1 or V3.2. Because basic serial communication is established — the bus scan finds the node — and because the OP1S reads/writes without error, the root cause is almost always parameter-definition mismatch between the offline project inside DriveMonitor and the firmware block running on the CUVC, not a physical layer or addressing fault.

Affected Products and Versions

Item Part Number / Version Status
Simovert MasterDrive VC compact 6SE7022-6TC61-Z (option G13, D99) Affected (confirmed)
Simovert MasterDrive VC compact 6SE7027-6TC61-Z Affected (confirmed)
CUVC firmware V3.1, V3.2 and earlier Susceptible to project-mismatch error
DriveMonitor V5.4 base release Incomplete CUVC V3.1/3.2 definition
DriveMonitor V5.4 SP2 (SIMOVERT / MICROMASTER / SIMOREG bundle) Recommended upgrade
Simovis Any revision against CUVC V3.1 Same “wrong data type” message
Operator panel OP1S Communication works (confirms healthy bus)
The OP1S uses a separate elementary protocol over the same RS-485 USS bus. A working OP1S therefore confirms the wiring, address, baud rate and basic telegram handling — but it does NOT prove that DriveMonitor’s higher-level parameter definition file matches the firmware in the drive.

Physical and Protocol Layer Reference

The 6SE70 CUVC board exposes the USS interface on a 9-pin Sub-D connector (typically X100 on the compact unit, or terminal block on the inside). USS is a master/slave, half-duplex RS-485 protocol where the host (DriveMonitor or PLC) polls each drive by its bus address.

Signal Pin / Terminal Direction
RS-485 + (T(A)) X100 Pin 1 Bidirectional
RS-485 – (T(B)) X100 Pin 2 Bidirectional
GND / reference X100 Pin 8 (or 4) Common
Bus termination DIP on CUVC or external 120 Ω Master + last slave only

Key drive-side USS parameters on the CUVC (parameter names are reserved on Siemens MasterDrives; refer to the Siemens Industry Online Support parameter manual for your CUVC version for exact indexes):

  • P700 – Serial interface source / activation
  • P701 – USS bus address (0–30; the active drive must match the address selected in DriveMonitor)
  • P702 – USS baud rate; 6 = 9600 bit/s (default on most compact units)
  • P703 – USS parity; 0 = even (default) for DriveMonitor
  • P704 – Number of stop bits; 2 = 2 stop bits (typical)
  • P705 – Telegram monitoring time

If the OP1S works and DriveMonitor does not, check that the PC COM port is set to the same P702/P703/P704 triple. Mismatches here are a secondary cause of “found but unreadable”, but with the OP1S already responding on the drive you can usually skip to the project-version fix.

Root Cause Analysis

DriveMonitor is a parameter-bulk-transfer tool, not a live polling tool. Before it can read or write the parameter set of a drive, it needs a parameter definition file (sometimes called the device master file or “parameter list”) that maps parameter numbers to data types, ranges, scaling and the correct grouping. That definition is tied to a specific CUVC firmware version.

If you start a new project and DriveMonitor does not know the CUVC firmware version you are talking to, it will fall back to a generic or older parameter layout. When you switch online, the tool reads the actual drive parameters but cannot interpret them against the layout it is holding — every parameter comes back with “Invalid data type”. The “?? ??” in the drive type and the single successful connect after a CUVC power-cycle are symptoms of the same root cause: the offline project firmware version does not match the firmware on the CUVC.

  • Primary cause — DriveMonitor was started with no project, with a generic project, or with a project whose CUVC version is unknown / different from V3.1.
  • Secondary cause (very rare once OP1S works) — Baud rate or parity drift between the PC COM port and the drive; usually visible as connection timeouts rather than “Invalid data type”.
  • Tertiary cause — CUVC firmware corruption in EEPROM. In that case you would also see fault codes such as F003 (EEPROM fault) or F004 (CU hardware fault) on the OP1S. If those faults are absent, this cause can be ruled out.

Pre-Diagnostic Checklist

Before changing the project, validate the simple physical and addressing items. They are fast to check and eliminate secondary causes.

  1. Power the drive, wait for the OP1S to display the drive status (e.g. r000 showing 0.0 Hz reference) without errors.
  2. Confirm the active bus address on the OP1S by reading P701. Record the value (commonly 0 for the only drive on the bench).
  3. Confirm the P702 baud rate — note the index (6 = 9600).
  4. Close any other PC software that may be holding the COM port (e.g. STEP 7 online instances, STARTER, Simovis).
  5. Plug the USS cable into the CUVC X100, not into any other port on the drive.
  6. Match the PC COM port in Windows Device Manager to 9600 / even parity / 2 stop bits / 8 data bits as a starting profile.
  7. Run DriveMonitor, go to File > Create USS drive connection, click Search / Scan. The drive should appear. The combination of “drive found” + “OP1S works” + “question-mark type” tells you this is the parameter-definition mismatch problem and the procedure below will resolve it.

Step-by-Step Resolution

Use this procedure in order. Do not skip step 3 — the project must be created BEFORE you go online.

Step 1 — Install the latest DriveMonitor 5.4 SP2

Download and install the current DriveMonitor release for SIMOVERT MASTERDRIVES, MICROMASTER and SIMOREG (V5.4 SP2 or later). This bundle bundles updated parameter definitions, including the V3.1 / V3.2 / V3.3 CUVC layouts:

Step 2 — Start DriveMonitor before attaching to the drive

This is the critical step. Do not scan the bus first.

  1. Launch DriveMonitor.
  2. Select File > New. In the device wizard choose a project of type Simovert MasterDrive VC compact (CUVC) with firmware version V3.1.
  3. If your drive is a 6SE7027 (larger rating), the wizard adapts automatically once the CUVC version is set; the parameter list inside the CUVC is the same.
  4. Save the project to a local folder. Closed V3.1-aware projects resolve the “?? ??” device-id and the “Invalid data type” error both at the same time.
Always create the project with the firmware version you actually read on the OP1S (Menu > Setup > Parameter > CU version). If the CUVC version reads V3.2, build a V3.2 project; if V3.3, build a V3.3 project. Mixing versions produces the same error.

Step 3 — Configure the USS PC interface

  1. In DriveMonitor go to Settings > COM port.
  2. Select the COM port assigned to your USB-to-RS485 converter.
  3. Set baud to match P702 on the drive (typically 9600), parity even, data bits 8, stop bits 2.
  4. Set the bus address to match P701.

Step 4 — Go online via Read from EEPROM

  1. With the V3.1 project open and configured, use Online > Read from EEPROM first. This pulls the permanent parameter set, which still uses the V3.1 parameter layout.
  2. Confirm the status bar at the bottom reports a successful read and that no parameter shows “Invalid data type”.
  3. Then switch to Online > Read from RAM to verify the runtime parameter block.

Step 5 — Save a working backup

Immediately after a successful Read from EEPROM, save the project with a name that includes the CUVC version, the drive rating and the date, for example: 6SE7022-6TC61-Z_CUVC-V3.1_2025-06-19.dm4

Field practice shows that once you have a working V3.1 project, repeat drive imports succeed cleanly. The single-shot behavior after a CUVC power-cycle that some engineers report is consistent with the fact that a freshly booted CUVC has a clean telemetry session window before any half-open request is left dangling in the protocol stack. After the V3.1 project is created, that window is irrelevant — all subsequent connections are deterministic.

Edge-Case Recovery and Workarounds

Workaround A — Power-cycle Connect Trick

Some engineers have observed that they get one good upload immediately after a power-cycle of the CUVC. Treat this as a recovery window only:

  1. De-energize the master drive section.
  2. Wait 30 seconds; cycle the CUVC power supply only.
  3. Start DriveMonitor with the bus scan, the drive will appear with question marks, but Read from EEPROM will be accepted once.
  4. Capture this single upload as a backup file immediately, then immediately apply the Step-by-Step Resolution above.

Do not rely on this window for ongoing operations; it indicates a project that is mismatched and will eventually corrupt further uploads.

Workaround B — Factory Reset of the CUVC

If the CUVC firmware has been patched to a new minor version mid-life or shows fault codes F003, F004 or F001, restore the control board to the version indicated in your project:

  1. On the OP1S navigate to P060 and set 4 (factory reset; refer to the CUVC parameter manual for the exact index in your build).
  2. Confirm P700–P705 still match your PC COM port profile.
  3. Reload parameters from the saved .dm4 backup produced in Step 5.

Workaround C — Read Using OP1S Instead

OP1S proves the bus works. As a fallback when DriveMonitor cannot be brought online quickly, you can read every parameter manually on OP1S using the navigation keys. For larger parameter uploads (>50 parameters), use the OP1S’s Upload to OP / Download from OP function to dump the full set to a textual parameter file, then translate into DriveMonitor manually. This path is slow but it works on every CUVC build from V2.x upward and is the recommended last-resort method when in the field with no laptop.

Workaround D — Bypass with Simovis

Simovis is an alternative commissioning tool that supports the same CUVC. Field experience shows it returns the identical “wrong data type” message when confronted with a non-matching project file. Treat Simovis as a cross-check rather than a fix: it confirms the issue is in the parameter definition, not in DriveMonitor itself.

Verification

After a successful Resolution, run the following verification steps in order; each one removes a residual uncertainty.

  1. Drive identification — the “Drive type” column in File > Manage USS drive connection now shows the full MLFB (e.g. 6SE7022-6TC61-Z) with no question marks.
  2. Parameter scan — open the parameter list and confirm that P100 (parameter access / device identification range), P060 and at least one drive-side parameter (P200–P208 motor data) display numeric values, not “Invalid data type”.
  3. Online RAM live values — request a Read from RAM and look at r000 (status) — the value updates as the OP1S updates.
  4. Round-trip parameter write — change P701 from 0 to 31 in DriveMonitor, push to EEPROM, power-cycle the CUVC, and confirm with OP1S that P701 reads back 31. Restore the address afterwards.
  5. Disconnect/reconnect test — close and re-launch DriveMonitor and verify a clean connect without any power-cycling of the drive. This confirms the parameter-definition root cause is fixed.

All five checks must pass before you can claim the unit is back under tool control. Any persistence of the question-mark type or “Invalid data type” means Step 2 of the resolution was incomplete — delete the project, re-create it, ensure the firmware version on the wizard exactly matches the version on the OP1S.

Preventive Maintenance and Long-Term Management

  • Tag every backup with the CUVC firmware version. Spare parts, sister drives and replacement CUVC boards may carry different versions; the project must follow the firmware, not the drive MLFB.
  • Store one backup per drive per firmware version on a Windows file share with the drive serial number as the folder name. DriveMonitor .dm4 files do not contain executable code, they only contain parameter values, so sharing them does not raise licensing issues.
  • Keep one install of DriveMonitor 5.4 SP2 at the bench even after you migrate to STARTER / StartDrive / TIA Portal. Newer tools do not always support old CUVC builds, particularly V3.1 / V3.2, and you will need DriveMonitor specifically for legacy work.
  • Avoid USB-to-RS485 converters at extension lengths above 5 m. If the cable must run several meters, switch to industrial USB hubs with galvanic isolation (e.g. Siemens USS adapters) or to a hub with opto-isolation; ground loops show up as intermittent “Invalid data type” for a subset of parameters only.
  • Lock the bus address: after successful commissioning, print the final value of P701 on a label on the drive’s terminal cover so the next engineer can build the correct project without re-scanning.

Migration to SINAMICS / Modern Tools

MasterDrive VC (6SE70) was succeeded by the SINAMICS G / S platform. For long-term fleet planning the project-side migration path is:

  • Use STARTER (≤ V5.x) or SINAMICS StartDrive in TIA Portal for any new SINAMICS G120 / G130 / S120 family.
  • For converting existing MasterDrive parameter sets to SINAMICS, the STARTER tool provides a project conversion under Tools > Migrate Project; some parameter mapping is automatic, some requires manual rework of the BICO wiring.
  • DriveMonitor remains the only path for CUVC V3.1 / V3.2; STARTER does not actively support these firmware versions for online access.

If the affected drive is destined for rebuild or scrap in the next 12 months, weigh the cost of one engineer-day spent building a clean V3.1 project against buying a replacement SINAMICS unit; for many plants the SINAMICS path is cheaper on the second fault.

Parameter and Configuration Reference

Parameter Purpose Typical Value
P060 Parameter access / factory reset trigger 0/4 (4 = factory reset on CUVC)
P700 Serial interface source on CUVC 0 = USS on X100
P701 USS bus address 0 for bench, uniquely assigned for cabinet
P702 USS baud index 6 = 9600 bit/s
P703 USS parity 0 = even
P704 Stop bits 2 = 2 stop bits
P705 Telegram monitoring time 0 (no monitoring) or 100 ms on critical drives
P718 Fault message selection for serial interface Per site policy
r000 Drive status word Read-only monitor

For the complete parameter list, refer to the official Simovert MasterDrive documentation on Siemens Industry Online Support. For USS protocol details see the Siemens contributions on USS protocol implementation notes.

FAQ

Why does DriveMonitor find the drive but show question marks in the device type?

DriveMonitor identifies the drive from its parameter definition file. If the offline project was created without specifying the CUVC firmware version, the tool cannot decode the drive’s identification block, so it falls back to a placeholder string with question marks. The fix is to create a project that selects your exact CUVC version (V3.1, V3.2, etc.) before going online.

The OP1S works, so why does DriveMonitor fail with “Invalid data type”?

OP1S uses a minimum-functionality USS profile — it reads parameter numbers but does not need a parameter definition file. DriveMonitor uses the high-level parameter upload, which decodes parameter data types and ranges against the offline project; with a mismatched project every parameter comes back as “Invalid data type”. A passing OP1S confirms only that the physical bus and addressing are correct.

Why does the upload work for one session right after a CUVC power-cycle, and then fail?

On boot, the CUVC’s protocol stack is in a clean state and accepts the first bulk upload even with a wrong parameter layout. After that window expires and the project has not been re-created with the correct firmware, all subsequent uploads return “Invalid data type”. Use that single successful upload only as an emergency backup, then immediately create the correct project.

Does Simovis solve this same problem?

No. Simovis is an alternative Siemens commissioning tool that uses the same CUVC parameter definition model. It produces the same “wrong data type” message when pointed at a project whose firmware version does not match the drive. Use it as a cross-check that the issue is in the project definition, not in DriveMonitor itself.

Which DriveMonitor version is required for CUVC V3.1 / V3.2?

DriveMonitor V5.4 base release already supports V3.1 / V3.2 in most cases, but the bundled parameter definitions in V5.4 SP2 (SIMOVERT / MICROMASTER / SIMOREG package) cover wider combinations including V3.2 SPx and the G13 / D99 options commonly found on compact 6SE70 units. Always run the latest V5.4 SP2 build you can obtain from Siemens Industry Online Support.

Can STARTER or TIA Portal StartDrive take the place of DriveMonitor for an old CUVC V3.1 drive?

Not for routine online work. STARTER / StartDrive targets the SINAMICS platform and does not actively support online access to CUVC firmware older than the very latest service packs. For legacy MasterDrive VC units keep a working install of DriveMonitor 5.4 SP2 on the bench even after fleet migration.

Back to blog