# Drive **Drives** control the movement of GameObjects along a defined axis. They are used for any moving component in the scene—except for freely moving [MUs](https://doc.realvirtual.io/components-and-scripts/mu-movable-unit) (Movable Units), which are handled differently. A Drive itself does *not* provide signal interfaces for PLC communication. To enable PLC interaction, you must attach a [**DriveBehavior**](https://doc.realvirtual.io/components-and-scripts/motion/drive-behavior) component to the same GameObject that contains the Drive script. This separates the motion logic from the signal interface logic, keeping the system modular and flexible. > **💡 Hint**\ > The Drive direction for a **linear axis** is always defined based on the **local coordinate system** of the GameObject the Drive is attached to.\ > For a **rotational axis**, the **origin of the local coordinate system** acts as the center of rotation, and the object rotates around the defined axis.\ > A Drive can also be connected to a **Transport Surface**—in this case, only **MUs on the Transport Surface** will be moved by the Drive. > **💡 Hint**\ > The standard units for Drive positions in all **realvirtual** components are:\ > • **Millimeters** for linear Drives\ > • **Degrees** for rotational Drives > > Corresponding speed units are:\ > • **Millimeters per second** for linear movement\ > • **Degrees per second** for rotation > > In Unity, **1 millimeter equals 1 Unity unit**, meaning that **1 meter = 1000 Unity units** in realvirtual.\ > While you can change this scaling in the [realvirtualController](https://doc.realvirtual.io/components-and-scripts/game4automation), doing so is **not recommended**, as it may lead to inconsistencies in physics and interaction. {% embed url="" %} Youtube tutorial about creating a first model and adding drives {% endembed %} This picture shows how two drives are connected to the axis of the handling system in the [Demo Model](https://doc.realvirtual.io/basics/demo-model):

In the demo cell, **Drives** are responsible for moving the different parts of the CNC machine. The motion structure is defined by the **parent-child hierarchy** of GameObjects in Unity, which establishes the **kinematic chain** of the machine. > **💡 Hint**\ > If the imported CAD data does not match the required **kinematic hierarchy**, you can use the **Kinematic** component to define a **separate motion hierarchy** that references the original CAD parts.\ > This allows you to build a clean and functional motion structure without modifying the original CAD GameObject hierarchy. The **Drive component** in the Unity Inspector includes several properties that control motion behavior and configuration. These properties are explained in detail below.

## Drive handles in editor mode ### Modern Drive Gizmos (Updated in 6.0.3) When you select a Drive in the Unity Editor, enhanced visual handles and real-time feedback are displayed to help you configure and monitor drive behavior:

Modern Drive Handles and Gizmos — Modern Drive gizmos showing rotational handles, real-time position (137.2°), and speed display (26.5°/s)

### Interactive Handle Features #### Visual Elements * **Blue Circular Handle**: Interactive rotation control for rotational drives * **Green/Yellow Directional Arrows**: Show drive direction and movement indicators * **Real-time Position Display**: Shows current drive position (e.g., "137.2°" for rotational drives) * **Speed Indicator**: Displays current movement speed (e.g., "26.5°/s") #### Handle Interaction * **Direction Control**: Click directional arrows to change drive axis direction * **Visual Feedback**: Current direction highlighted with distinct colors * **Real-time Updates**: Position and speed values update continuously during movement * **Precision Control**: Interactive handles allow precise drive configuration ### Changing Drive Directions #### Visual Direction Selection * **Active Direction**: Currently selected axis shown with prominent visual indicators * **Alternative Directions**: Other available axes shown in secondary colors * **Direction Inversion**: Click the current direction arrow to invert positive/negative orientation * **Axis Switching**: Click alternative direction arrows to change drive axis ### Linear Drive Handles For linear drives, the modern gizmo system displays directional arrows for all three axes:

Linear Drive Handles — Linear drive handles showing X (red), Y (green), and Z (blue) directional arrows for precise axis selection

#### Linear Drive Features * **Color-Coded Axes**: Red (X), Green (Y), Blue (Z) following Unity's standard color scheme * **Direction Arrows**: Clear visual indicators for each possible movement direction * **Axis Selection**: Click any arrow to set the drive's primary movement axis * **Visual Clarity**: Clean, modern appearance integrated with Unity's gizmo system #### Gizmo Visibility Settings Drive handles are only displayed if the **Drive Gizmo** is enabled in Unity's gizmo settings. You can control gizmo visibility through Unity's Preferences:

Drive Gizmo Settings — Unity Preferences showing Drive gizmo visibility controls in the Scripts section

**Gizmo Controls:** * **Drive Gizmo Toggle**: Enable/disable drive handle visibility globally * **Icon Display**: Show/hide drive component icons in Scene view * **Recently Changed**: Quick access to recently modified gizmo settings * **Per-Component Control**: Individual visibility settings for different drive types {% hint style="info" %} Alternatively you can change the drive directions with hotkeys. By pressing on **SPACE** you invert the direction of the currently selected Drive.\ By pressing **TAB** you iterate through all 6 possible directions (3 linear and 3 rotational). {% endhint %} ### Drive limits You can define upper and lower limits for drives. These limits are only used when driving the drive with the **Jog Forward** and **Jog Backward** signals. The modern limit display shows precise values and visual indicators:

Modern Drive Limits Display — Modern drive limits showing lower limit (-500 mm) and upper limit (1000 mm) with directional handles

#### Modern Limit Display Features * **Precise Value Display**: Shows exact limit values (e.g., "-500 mm" for lower, "1000 mm" for upper) * **Visual Range Indicators**: Clear visual representation of the allowable movement range * **Integration with Handles**: Limit display works seamlessly with directional handle system * **Real-time Updates**: Limit values update immediately when changed in the Inspector #### Limit Behavior For linear axes, the limits define the exact positions where the drive will stop when using jog commands. The drive can only move within the defined range between the lower and upper limits. For rotational axes, the limit is displayed by a trimmed circle. The drive can only rotate in the white area. #### Practical Usage Example When setting up a linear conveyor, you might configure: * **Lower Limit**: 0 mm (start position) * **Upper Limit**: 2000 mm (end of conveyor) This prevents the drive from moving beyond the physical conveyor length during jog operations. > **💡 Hint**\ > Avoid using **position limits** on Drives that are connected to a **motion or robot controller**.\ > These controllers usually handle motion constraints internally. Enabling limits in this case might **hide incorrect target positions**, making it harder to detect configuration or control errors. ## Troubleshooting ### Drive Not Moving * **Check Active Setting**: Ensure "Active" is set to "Always" or appropriate condition * **Verify Target Speed**: Confirm Target Speed > 0 for movement * **Limit Conflicts**: Check if limits are preventing movement * **Drive Behavior**: Ensure proper DriveBehavior is attached for PLC control ### Jerky or Erratic Motion * **Enable Acceleration**: Turn on "Use Acceleration" for smoother starts/stops * **Acceleration Values**: Set appropriate acceleration values (typically 10-50% of target speed) * **Speed Override**: Check if global speed override is affecting motion * **Physics Issues**: Verify proper collision detection and Rigidbody settings ### Performance Issues * **Multiple Drives**: For many drives, consider using Drive Behaviors for optimized control * **Complex Hierarchies**: Use Kinematic component for complex motion chains * **Update Frequency**: Check FixedUpdate frequency for smooth motion > ⚠️ **Attention**\ > **Jogging with acceleration** and **Drive limits** is currently **not supported**.\ > If you enable both features, the Drive behavior may not function as expected. ## Drive handles in simulation mode During Play Mode, drive handles provide real-time monitoring and manual control capabilities. The modern interface displays live position and speed information directly in the Scene view:

Drive Handles in Simulation Mode — Drive handles during simulation showing real-time position (-327.8 mm), speed (620.0 mm/s), and QuickEdit integration

### Real-Time Display Features * **Live Position Display**: Shows current drive position floating near the drive (e.g., "-327.8 mm") * **Speed Monitoring**: Displays current movement speed (e.g., "620.0 mm/s") during motion * **QuickEdit Integration**: Drive selection and control through the realvirtual QuickEdit panel * **Visual Feedback**: Clear identification of active drives with highlighted information ### Manual Control During Simulation * **Direction Control**: Cannot change drive directions (set in Edit Mode) * **Jog Mode**: Use QuickEdit controls or handles to manually jog drives * **Limit Respect**: Manual jogging respects defined drive limits * **Real-time Updates**: Position and speed values update continuously ### Alternative Control Methods **Keyboard Shortcuts:** * **Key 1**: Move drive in negative direction * **Key 3**: Move drive in positive direction **QuickEdit Panel:** * **Back/Forward buttons**: Manual jog control for selected drive * **Target Speed**: Adjust movement speed in real-time * **Drive Selection**: Shows active drive name (e.g., "GantryZ") ### Rotational Drive Simulation For rotational drives, the simulation interface provides specialized circular gizmos and angular position display:

Rotational Drive in Simulation Mode — Rotational drive during simulation showing circular rotation gizmo, real-time angle display (0.0°), and Axis1 drive control

**Rotational Features:** * **Circular Rotation Gizmo**: Blue circular handle indicating rotation axis and range * **Angular Position Display**: Real-time angle shown in degrees (e.g., "0.0°") * **Direction Indicators**: Color-coded arrows showing rotation directions * **Axis Identification**: Drive name displayed in QuickEdit (e.g., "Axis1") * **Precise Control**: Manual rotation control through handles or QuickEdit interface ## Drives and Unity Physics By default, **linear** and **rotational Drives** operate **without using Unity's PhysX Rigidbody system**. This approach is generally **more stable and predictable**, especially for automation and simulation scenarios. In some cases, however—such as when interacting with physical objects or colliders—it may be necessary to move the **Rigidbody** component directly. To do this, you must enable the **"Move This Rigid Body"** option in the Drive component. > **💡 Hint**\ > Only enable **"Move This Rigid Body"** if you explicitly need Drive motion to affect Unity physics.\ > In most use cases, this setting should remain **disabled** to ensure optimal simulation stability and performance.

## Drive properties ### Settings * **Active**: Defines whether the Drive is active. Usually this should be set to Always. For more information please check **ConnectionStatus** in [Runtime UI](https://doc.realvirtual.io/basics/runtime-ui) * **Direction**: Selects the movement axis. Choose from linear (`X`, `Y`, `Z`) or rotational (`Rotation X`, `Rotation Y`, `Rotation Z`). Movement is always defined in the local coordinate system. * **Reverse Direction**: Inverts the movement direction along the selected axis. * **Offset**: Applies an offset to the Drive's position. This value is **added to the internal position** during simulation.\ For example, if the `Offset` is set to **100** and the `Current Position` is **50**, the resulting position in the simulation is **150**.\ This is useful when aligning Drive values with external systems, such as PLCs, where a consistent value shift is required for coordination. * **Start Position**: The Drive's starting position when the scene starts or the Drive is reset. * **Speed Override**: Multiplies the base speed to dynamically adjust how fast the Drive moves. * **Speed Scale Transport Surface**: Scales the speed if connected to a Transport Surface (default: 1). * **Move This Rigid Body**: Enables the Drive to move the attached Rigidbody (not recommended unless Unity physics interaction is required). * **Transport Surfaces**: Allows linking [Transport Surfaces](https://doc.realvirtual.io/components-and-scripts/motion/transportsurface) to the Drive. Only [MUs](https://doc.realvirtual.io/components-and-scripts/mu-movable-unit) on linked surfaces are moved. ### Drive IOs The **Drive IOs** section contains input and output fields that allow you to interact with the Drive during simulation. * **Jog Forward**\ Boolean input to jog the Drive forward as long as the signal is active.\ Uses the set **Target Speed** without acceleration smoothing. * **Jog Backward**\ Boolean input to jog the Drive in the opposite direction.\ Also uses **Target Speed** and ignores acceleration settings. * **Target Position**\ A numeric input defining the desired position (in millimeters or degrees) that the Drive should move to.\ Can be controlled via script or PLC. * **Target Speed**\ Defines the maximum speed the Drive can reach when moving toward the **Target Position**.\ Value is in mm/s (for linear) or deg/s (for rotational). * **Target Start Move**\ Boolean input signal to start the move toward the **Target Position** using the defined **Target Speed**.\ Only starts the motion; does not affect target value. * **Reset Drive**\ Resets the Drive position to the configured **Start Position**.\ Can be triggered manually or via a PLC signal. * **Stop Drive**\ Immediately stops the Drive's motion, overriding current target or jogging input. * **Is At Upper Limit**\ Boolean output indicating whether the Drive has reached its defined **Upper Limit** (if limits are enabled). > **💡 Hint**\ > The **Drive IOs** can be accessed and controlled via **custom scripts**, making them flexible for user-defined behaviors.\ > In most cases, they are used by [**Behavior components**](https://doc.realvirtual.io/components-and-scripts/motion/drive-behavior) which handle the connection between the Drive and external systems such as **PLC signals**.\ > This setup separates physical motion from control logic, allowing clean integration with automation environments. ### Limits The **Limits** section allows you to define positional constraints for the Drive. These are useful for preventing movements beyond mechanical boundaries or for guiding logic in manual or automated scenarios. * **Use Limits**\ Enables or disables the use of movement boundaries. When enabled, the Drive will be restricted to the range defined by the **Lower Limit** and **Upper Limit**. * **Lower Limit / Upper Limit**\ Define the minimum and maximum allowed positions for the Drive.\ Values are in millimeters (for linear Drives) or degrees (for rotational Drives). * **Jump to Lower Limit on Upper Limit**\ If enabled, once the Drive reaches the **Upper Limit**, it immediately jumps to the **Lower Limit** and continues motion.\ This is useful for circular or rotary indexing systems, e.g., turntables. * **Limit Ray Cast**\ Optional field for assigning a **sensor GameObject** (typically a virtual proximity sensor).\ This allows detection of the limit not only by position but also via **raycast-based sensor feedback**. > **💡 Hint**\ > Avoid enabling **Limits** when the Drive is controlled by an external **motion or robot controller**.\ > The controller may send positions outside the defined range, and the limits could silently clip or block the motion—making it harder to detect misconfiguration or errors. ### Acceleration The **Acceleration** section allows you to simulate smooth motion profiles by controlling how the Drive accelerates and decelerates. * **Use Acceleration**\ Enables acceleration-based motion. When disabled, the Drive moves at constant speed directly toward the target. * **Smooth Acceleration (only Professional Version)**\ Activates smoothing of acceleration and deceleration using a jerk-controlled motion profile.\ This results in more realistic movement, particularly for robotics and high-speed systems. * **Acceleration**\ Maximum allowed acceleration in mm/s² (linear) or deg/s² (rotational).\ This value defines how quickly the Drive can ramp up or down in speed. * **Jerk (only Professional Version)**\ Maximum rate of change in acceleration (mm/s³ or deg/s³).\ Helps to create **soft starts and stops** by avoiding abrupt changes in force or torque. > **💡 Hint**\ > Avoid using acceleration together with **Jogging**, as they are not compatible. ### Smooth Motion (only Professional Version) The **Smooth Motion** section is available exclusively in the **Professional edition** of realvirtual.io. It provides detailed visualization and control of the motion profile calculated for the Drive based on the configured **Acceleration** and **Jerk** settings.

**Profile** This subsection visualizes the generated motion curves for the current move: * **Position** – The Drive's motion over time. * **Velocity** – The rate of change of position. * **Acceleration** – The rate of change of velocity. * **Jerk** – The rate of change of acceleration. * **Duration** – Total time (in seconds) required to complete the current motion based on the active profile. These curves are generated in real time and give insights into how the Drive will behave during its movement. 🔗 For more information about **jerk** in physics, see: **State** * **Position / Velocity / Acceleration** – The current state of the Drive in simulation time. **Target State** * **Position / Velocity / Acceleration** – The values the Drive is targeting. These update based on user input or external control signals. ### Drive Status The **Drive Status** section provides real-time diagnostic information about the current motion and condition of the Drive. These values are continuously updated during simulation and are useful for debugging, monitoring, and interfacing with automation systems. **Fields** * **Current Speed**\ Displays the Drive's current speed in mm/s (linear) or deg/s (rotational). * **Current Position**\ The current absolute position of the Drive, including offset and any external overrides. * **Position Overwrite Value**\ Shows a temporary value applied when overriding the position manually or via external control logic. * **Is Position**\ Displays the final calculated position of the Drive after applying offset and override. This is the effective position used in simulation. * **Is Stopped**\ True if the Drive is currently not moving and not jogging. * **Is Running**\ True while the Drive is in motion, either toward a target position or while jogging. * **Is At Target Speed**\ Indicates whether the Drive has reached the defined **Target Speed**. * **Is At Target**\ True when the current position equals (within tolerance) the **Target Position**. * **Is At Lower Limit**\ True when the Drive has reached or exceeded the defined **Lower Limit** (if limits are enabled). * **Is Sub Drive**\ Marks whether this Drive is being controlled as a sub-drive in a more complex motion chain (e.g., a multi-axis system). ### Drive Events The **Drive Events** section provides Unity Events that are triggered at specific points during the Drive's simulation cycle. These are intended for **expert users** who want to attach **custom logic** directly to the Drive's behavior. **Available Events** * **On Before Drive Calculation (Drive)**\ Called **before** the Drive calculates its movement each frame.\ This is useful for injecting custom control logic or modifying inputs before the Drive updates. * **On After Drive Calculation (Drive)**\ Called **after** the Drive completes its motion logic for the frame.\ Useful for monitoring state, triggering custom events, or applying additional logic. > **💡 Hint**\ > **Drive Events** are intended for advanced users who need **low-level access** to the Drive's behavior.\ > For typical applications and PLC connections, it is recommended to use **Behavior components** such as `DriveBehavior`. > 🔗 For more information about the Drive update cycle, please refer to **Section: Motion for Developers** in this documentation. Please check the [Realvirtual.io Class Reference](https://realvirtual.io/apidoc/classrealvirtual_1_1_drive.html) for more information about the properties and methods of this component. \ © 2025 realvirtual GmbH [https://realvirtual.io](https://realvirtual.io/) - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher.