If you have followed the first and second parts of the VCDS guide, you now understand what VCDS is and how Volkswagen and Audi vehicles organize their electronic control systems.

You have learned that VCDS is much more than a generic OBD-II code reader. It can communicate with individual control modules, display manufacturer-specific diagnostic information, access live data, perform adaptations and Basic Settings, execute Output Tests, and provide detailed diagnostic information.

In addition, you learned that a modern Volkswagen or Audi is essentially a network of electronic control modules communicating through systems such as CAN and LIN, with the Gateway playing an important role in vehicle communication.

Now it is time to connect those concepts to the actual VCDS software.

In this article, we will walk through the VCDS Main Menu and explain what each major function does, when you would use it, and—just as importantly—when you should not use it.

The goal is not simply to learn which button to press. Instead, you should understand the diagnostic purpose of each function, how it relates to the vehicle’s control systems, and how it fits into a structured diagnostic process.

Critical Note on Version and Vehicle Differences:
Do not assume that every VCDS installation will look exactly like any screenshot. Older VCDS versions, newer versions, and different vehicle generations may present functions differently. A function available on one control module may not be available on another. Terminology also varies—modern UDS-based controllers commonly provide Advanced Measuring Values, while older controllers may use traditional Measuring Blocks.

The important skill is therefore not memorizing the screen. Instead, focus on understanding the diagnostic purpose of each function and the technical architecture behind it.

Technical Note: VCDS communicates with Volkswagen Group control modules through different diagnostic architectures and protocols depending on the vehicle, controller, model year, and interface. Therefore, the protocol examples in this article are presented as technical context rather than universal rules that apply to every VCDS-supported vehicle.

The VCDS Main Menu: What Does Each Function Actually Do?

The easiest way to understand VCDS is to think of its functions as different diagnostic tools. The table below summarizes what each function is for. We will explore each one in detail in the sections that follow.

This distinction is fundamental. Confusing these functions—for example, using Basic Settings as a “fix-all” or treating Coding as a place to experiment—can lead to incorrect diagnostic procedures.

1. Auto-Scan

Auto-Scan is one of the most important functions in VCDS.

It allows VCDS to communicate systematically with the vehicle’s control modules and generate a report containing information about the vehicle’s electronic systems. Instead of manually entering modules such as 01-Engine, 03-ABS, 09-Central Electronics, 19-CAN Gateway, and others, Auto-Scan provides a systematic way of checking the vehicle.

Technical Implementation

The exact Auto-Scan process depends on the vehicle’s diagnostic architecture. VCDS uses vehicle-specific information and the available diagnostic communication paths (which may involve different protocols, physical addressing methods, gateway routing, and data services) to identify and communicate with supported control modules. VCDS handles much of this complexity automatically.

Possible Auto-Scan Results

A scan may encounter:

• A module that responds normally
• A module containing stored faults
• A module that is not installed or not applicable to the vehicle
• A module that does not respond
• Communication problems involving a gateway or network

Therefore, a non-responsive module should be investigated rather than automatically interpreted as a failed ECU.

Why Auto-Scan Matters

Imagine that your Volkswagen has an EPC warning. You could immediately enter 01-Engine and look for engine faults. That can be useful; however, it may cause you to overlook information stored in other modules.

An Auto-Scan may reveal engine faults, ABS faults, transmission faults, gateway communication faults, body-control faults, and other module communication problems. Consequently, the relationship between faults can sometimes be more important than any individual fault code.

That is why Auto-Scan is usually one of the first steps in a systematic diagnostic process.

Think of Auto-Scan as your vehicle’s starting point. It answers: “What is happening throughout the vehicle?” It does not necessarily answer: “Why did this particular fault occur?” That distinction is critical.

2. Select Control Module

The Select Control Module function allows you to communicate directly with a specific control unit.

This differs from performing an Auto-Scan. Instead of asking “What is happening throughout the vehicle?” you are asking “What is happening inside this specific control module?”

For example:

• Engine problem → 01-Engine
• ABS warning → 03-ABS Brakes
• Airbag system → 15-Airbags
• Gateway investigation → 19-CAN Gateway

Technical Communication

When you select a control module, VCDS establishes diagnostic communication with that particular controller using the addressing and diagnostic protocol appropriate to the vehicle. On CAN-based systems, for example, a controller may use a physical diagnostic address such as 0x7E0 for an engine ECU, with a corresponding response address such as 0x7E8. However, you should not treat these addresses as universal. VCDS handles the addressing and protocol details required for supported vehicles.

Once communication is established, VCDS can expose the diagnostic functions supported by that controller.

Why Direct Module Access Is Important

Suppose your Auto-Scan reports P0299 — Turbocharger Underboost in the engine controller. The Auto-Scan tells you that a problem exists. You can then enter 01-Engine and access the detailed diagnostic functions supported by that controller, such as Fault Codes, Measuring Values, Basic Settings, Adaptation, Coding, and Output Tests.

At this point, VCDS transitions from vehicle scanning into detailed diagnosis.

3. Fault Codes

Before moving into live data and advanced testing, it is important to understand the role of Fault Codes.

A fault code tells you that the control system detected a particular condition. It does not automatically prove that a particular component has failed.

What Information Can a Fault Record Contain?

Depending on the controller and diagnostic architecture, a fault record may contain information such as:

• Fault code and description
• Fault status and frequency
• Mileage or operating information
• Environmental data and freeze-frame information (e.g., engine speed, vehicle speed, coolant temperature, load, voltage, or other system-specific parameters)

However, do not assume that every controller stores the same information or that freeze-frame data represents a fixed period of time immediately before the fault.

Fault Code ≠ Failed Part

This is one of the most important lessons for a beginner.

If VCDS reports P0299 — Turbocharger Underboost, that does not mean “Replace the turbocharger.” Possible causes may include boost leaks, wastegate problems, diverter valve problems, sensor or wiring problems, exhaust restrictions, turbocharger problems, control-system problems, or other conditions.

The fault code tells you where to begin investigating. It does not finish the diagnosis for you.

For example, two vehicles may both have a P0299 fault, but the supporting information may be completely different. One may have experienced the fault once under unusual operating conditions; another may experience it repeatedly under heavy engine load. As a result, those situations require different diagnostic thinking.

The DTC is therefore the starting point for investigation, not the final answer.

4. Measuring Values

One of the most powerful diagnostic functions in VCDS is Measuring Values, which lets you examine the information a control module monitors, calculates, and reports.

Depending on the module and vehicle generation, this information may include engine speed, coolant temperature, intake air temperature, airflow, boost pressure, fuel pressure, throttle position, oxygen-sensor information, fuel trims, ignition timing, camshaft adjustment, wastegate position, engine load, torque information, and sensor status.

Measuring Blocks and Advanced Measuring Values

The terminology depends on the control module.

• Legacy Controllers — Measuring Blocks: Older controllers may provide predefined Measuring Blocks organized into fixed groups containing specific values defined by the controller.
• Modern Controllers — Advanced Measuring Values: Modern UDS-based controllers commonly provide Advanced Measuring Values, exposing a larger set of individual data items that the controller makes available through its diagnostic data structure.

Technical Implementation

At the protocol level, modern diagnostic systems can use services such as ReadDataByIdentifier (0x22) to request specific data. However, the VCDS display is an abstraction of the underlying communication. Therefore, you should not assume that every VCDS measuring value corresponds directly to one universal UDS identifier across all vehicles.

Measuring Values vs. Fault Codes

A useful way to think about the difference is:

• Fault Code: “The control system detected a problem or condition.”
• Measuring Value: “This is what the system is measuring, calculating, or reporting.”

Both are important. Together, they provide a much stronger diagnostic picture than either one alone.

Example: Turbocharger Underboost

Suppose VCDS reports a turbocharger underboost fault. Replacing the turbocharger immediately would be poor diagnostic practice.

Instead, you might examine relevant Measuring Values or Advanced Measuring Values:

You can then compare expected behavior with actual behavior. For example, if the requested boost is significantly higher than the measured boost and the control system is commanding the actuator toward the position needed to increase boost, the evidence may point toward a mechanical or pneumatic problem.

However, the exact interpretation depends on the engine, ECU strategy, operating conditions, and the meaning of each displayed value. This is the foundation of data-driven diagnosis.

5. Basic Settings

Basic Settings lets you perform specific procedures that enable a control module to initialize, calibrate, learn, test, adapt positions, and execute other vehicle-specific routines.

Examples may include throttle body adaptation, turbocharger actuator adaptation, steering-angle calibration, and other vehicle-specific procedures.

The exact procedures available depend on the vehicle and control module.

Technical Implementation

The underlying diagnostic sequence for a Basic Settings procedure is controller-specific. On some UDS-based controllers, a procedure may involve RoutineControl (0x31) and may require SecurityAccess (0x27) before the controller permits the requested operation. Other controllers and diagnostic architectures can use different procedures. The key concept is this: VCDS gives you access to procedures that the control module implements, while the controller determines what each procedure does and which conditions you must satisfy.

Basic Settings Is Not a “Fix” Button

A common beginner mistake is to see a Basic Settings function and run it simply because it is available. Instead, do not do this.

Before performing a Basic Settings procedure, understand:

1. Why you need the procedure — Is it for component replacement, adaptation reset, system initialization, or another specific purpose?
2. What conditions you must meet — Check the required temperature, battery voltage, ignition state, engine state, and other specified requirements.
3. What the control module expects — Specific parameter values, sequence, timing, or operating conditions.
4. What the procedure actually changes — Learned values, calibration information, initialization states, or other controller data.
5. How you will verify the result — Measuring values, status information, fault memory, or system behavior.

If you replace a component that requires a specific adaptation or calibration procedure, you may need to perform the correct Basic Settings routine. Running unrelated procedures, however, can create additional problems or leave the system in an unexpected state.

6. Adaptation

Adaptation lets you adjust, initialize, or reset certain control-module parameters and learned values.

The exact available adaptation channels depend heavily on the vehicle and control module.

Adaptation can manage learned values, component configurations, calibration-related parameters, convenience functions, service procedures, and other controller-specific settings.

Technical Implementation

The technical implementation depends on the controller and diagnostic architecture. Older controllers may expose adaptation through traditional channel-based structures. In contrast, modern UDS-based controllers may expose parameters through diagnostic data identifiers and controller-specific routines.

An appropriate UDS implementation may use services such as WriteDataByIdentifier (0x2E) for a write operation, but you should not treat this as a universal rule.

The controller determines which parameters you can access, which values you can enter, what access level you need, whether you must complete a security procedure, how it stores the values, and which conditions you must meet.

Coding vs. Adaptation

This distinction is important. Coding generally configures a module according to its installed equipment and intended operation.

Adaptation generally deals with adjustable, learned, or service-related parameters within the module.

However, the exact terminology and functionality vary by controller. Therefore, never assume that an adaptation channel found online for one vehicle will have the same meaning on another vehicle.

7. Coding

It is one of the most powerful—and potentially consequential—functions in VCDS.

Coding changes the configuration of a control module. Depending on the vehicle, coding can influence lighting, convenience features, vehicle equipment configuration, display behavior, control-module options, and other vehicle-specific functions.

Coding Structure

Different Volkswagen Group controllers and generations use different coding structures.

• Short Coding: A relatively compact coding value representing a set of configuration choices.
• Long Coding: A multi-byte coding structure in which individual bytes and bits can represent different configuration options. For example, a Long Coding string may contain numerous hexadecimal bytes (Byte 0, Byte 1, Byte 2, etc.), and individual bits within those bytes may correspond to specific equipment or configuration options.

The exact meaning is controller-specific. Therefore, you should never interpret Long Coding by looking at an isolated byte or bit without understanding the controller and vehicle configuration.

Technical Constraints

Coding may involve controller-specific requirements such as security or access authorization, valid coding values, configuration consistency, gateway or vehicle-network dependencies, controller-specific validation, and ignition-cycle or restart requirements. Not every coding operation uses the same security or validation mechanism.

CRITICAL CODING WARNING

Never treat coding as a place to experiment blindly. Avoid “I’ll change this bit and see what happens.”

Instead, before changing coding:

1. Record the original coding.
2. Understand exactly what the change is intended to accomplish.
3. Confirm that the vehicle supports the function.
4. Make only the necessary change.
5. Save documentation of the new configuration.
6. Verify vehicle operation afterward.

The objective is to make a controlled and documented change. Whenever possible, preserve the original configuration so that you have a reference point if something does not behave as expected.

When Should a Beginner Avoid Coding?

If you do not know what a coding change does, why the vehicle needs it, or what the original configuration was, then do not change it. Learn first.

8. Output Tests

Output Tests allow VCDS to command certain supported components or actuators to operate. This can be extremely useful when determining whether a component responds to a command from the control system.

Depending on the module, Output Tests may involve cooling fans, relays, solenoids, actuators, pumps, motors, and other controlled devices.

Technical Implementation

The underlying diagnostic mechanism depends on the controller. On appropriate UDS implementations, actuator control can involve InputOutputControlByIdentifier (0x2F). However, not every Output Test in VCDS should be assumed to use the same UDS service. Legacy controllers and other diagnostic architectures may implement output testing differently.

VCDS presents the supported test to the technician while handling the controller-specific communication.

What an Output Test Can Tell You

For example, if a cooling fan is suspected of having a problem, an appropriate Output Test may help determine whether the control system can command the fan.

If the fan responds, this can provide evidence that the control module can initiate the test, the relevant output stage can operate, the electrical path may be functional under the test conditions, and the actuator can respond to the command.

But there is an important diagnostic limitation: An Output Test does not prove the entire system is healthy.

If an actuator does not operate, possible causes include a failed actuator, wiring problem, power-supply problem, ground problem, control-module problem, safety condition preventing activation, incorrect test conditions, or mechanical failure.

Conversely, if the actuator operates during the test, this does not necessarily prove mechanical performance under load, correct operation at operating temperature or under real driving conditions, pneumatic or hydraulic integrity, or correct operation under every operating condition.

Likewise, an actuator that operates during an Output Test may still fail intermittently or under load.

VCDS provides information and control. Ultimately, it does not eliminate the need for diagnostic reasoning.

9. Applications and Utility Functions

VCDS also includes additional functions and utilities that are not necessarily tied to one specific control module. These may include functions for vehicle information, service-related functions, diagnostic utilities, output and logging functions, interface testing, and other VCDS-supported operations.

For beginners, there is no need to memorize every utility. Instead, focus first on mastering the core diagnostic functions: Auto-Scan → Control Module → Fault Codes → Measuring Values → Basic Settings → Adaptation → Coding → Output Tests.

These functions form the foundation of VCDS diagnostics.

The Most Important Lesson: Scanning Is Not Diagnosis

This is one of the most important lessons in the entire VCDS Master Academy.

Scanning is not the same as diagnosis.

An Auto-Scan may tell you “The vehicle has a P0299 fault.” Diagnosis asks: “Why is the vehicle producing P0299?” That question requires investigation.

For example, possible causes could include vacuum or boost leaks, wastegate problems, diverter valve problems, sensor problems, wiring, exhaust restrictions, turbocharger problems, control-system problems, or other conditions.

VCDS provides the information needed to investigate those possibilities. The technician has to interpret the information.

A Simple VCDS Diagnostic Workflow

For a beginner, the following workflow provides a useful mental model:

1. Scan — Perform an Auto-Scan when appropriate.
2. Identify — Determine which control modules contain faults and whether there are communication-related issues.
3. Investigate — Enter the relevant control module.
4. Read — Review the fault codes and supporting information.
5. Measure — Examine relevant Measuring Values or Advanced Measuring Values.
6. Test — Use appropriate diagnostic procedures such as Basic Settings, Output Tests, electrical tests, mechanical inspections, or manufacturer-specific procedures.
7. Repair — Correct the actual cause of the problem.
8. Verify — Clear faults when appropriate and confirm that the problem has been resolved.

This workflow prevents a common mistake: replacing a component simply because a fault code mentions it.

Common Beginner Mistakes

Understanding what not to do is just as important as learning the functions.

Check Your Understanding

Before moving to the next lesson, see if you can answer these questions.

Question 1: Your vehicle has several warning lights and you do not know which control modules are involved. Which function should you normally start with?

Answer: Auto-Scan.

Question 2: Your Auto-Scan identifies a fault in the Engine controller and you want detailed information. What should you do next?

Answer: Enter the relevant Control Module, such as 01-Engine.

Question 3: You want to see requested boost and actual boost. Which function is most useful?

Answer: Measuring Values / Advanced Measuring Values, depending on the controller.

Question 4: You replaced a component that requires a manufacturer-supported calibration procedure. Which VCDS function may be appropriate?

Answer: Basic Settings, provided the specific procedure and conditions are correct for that vehicle.

Question 5: You want to change how a control module is configured. Which function might be involved?

Answer: Coding.

Question 6: You want to command a supported cooling fan or actuator to operate. Which function might be appropriate?

Answer: Output Tests.

Question 7: Your VCDS scan reports P0299. Should you automatically replace the turbocharger?

Answer: No. P0299 identifies an underboost condition; the cause must be investigated using fault information, Measuring Values, testing, inspection, and the vehicle-specific diagnostic procedure.

If you understand why each answer is correct—not just which button to press—you are ready to move forward.

What Should You Learn Before Moving On?

At this point, you do not need to memorize every VCDS function. Instead, you should understand what each major function is designed to accomplish and the technical context behind it.

The key word in this table is controller-specific. The diagnostic service used underneath VCDS is determined by the control module and its diagnostic architecture.

Therefore, VCDS abstracts much of this complexity so the technician can work with the supported diagnostic functions without manually constructing every diagnostic message.

Understanding the Difference Between Information and Action

A useful way to remember the major VCDS functions is to divide them into three broad categories:

1. Information — Functions that help you understand the condition of the vehicle:

• Auto-Scan, Fault Codes, Measuring Values, Advanced Measuring Values
• They answer: What systems are present? What faults are recorded? What is the controller measuring?

2. Diagnostic Procedures — Functions that allow you to perform specific supported diagnostic operations:

• Basic Settings, Output Tests
• They answer: Does this actuator respond to a command? Can this system complete its calibration procedure?

3. Configuration — Functions that change controller behavior or stored configuration:

• Adaptation, Coding
• They answer: What configuration is stored in this controller? Which supported parameters or functions can be adjusted?

This distinction is useful because not every VCDS function should be used simply because it is available.

What Comes Next? Part 1-4 — Your First Auto-Scan

Now that you understand the VCDS Main Menu and the purpose of its major functions, it is time to actually use one of the most important tools in VCDS: Your First Auto-Scan.

In VCDS Part 1-4, we will perform an Auto-Scan step by step. We will examine:

• How to prepare the vehicle
• Battery and ignition considerations
• How to select the correct vehicle profile
• How to start the scan
• What VCDS is doing during the scan
• How control modules are identified
• What happens when a module does not respond
• How faults are reported
• How to distinguish a clean scan from a fault-rich scan
• How to save and organize scan files
• Why the original scan should be preserved
• Common Auto-Scan mistakes

The objective is to make your first Auto-Scan a structured diagnostic procedure, rather than simply pressing a button.

The Fundamental Principle

VCDS is a diagnostic instrument—not a magic button.

The software can communicate with the vehicle, retrieve information, display data, perform supported procedures, and command certain components.

However, the final diagnosis depends on how you interpret that information.

Learn the function. Understand the system. Test the evidence. Then make the repair.

That is how you move from simply using VCDS to actually diagnosing with VCDS.