Omron 3G3FV VFD Multi-Speed Control via Arduino UNO R3

System Overview and Architecture

This article documents the integration of an Arduino UNO R3 as a serial-controlled digital interface between a PC and an industrial control chain composed of a Siemens SIMATIC S7-200 CPU 215, an Omron SYSDRIVE 3G3FV variable frequency drive (VFD), and an ABB MU80A19 three-phase induction motor. The goal is to implement an automated multi-speed sequence: 5 s forward rotation, 5 s stop, 10 s reverse rotation, followed by a ramped speed profile (20 %, 60 %, 100 % of nominal), and finally a controlled stop.

The signal flow is intentionally layered rather than direct:

1. PC client issues plain ASCII commands over a USB virtual COM port (recommended terminal: PuTTY or the Arduino IDE Serial Monitor at 9600 baud, 8N1).
2. Arduino UNO R3 parses each command and energizes five 5 V TTL digital outputs. Three outputs drive the multi-speed binary selector of the 3G3FV, and two outputs drive forward/reverse logic.
3. Siemens S7-200 CPU 215 reads the Arduino lines as 24 V discrete inputs through a level-translation stage, applies safety interlocks and timing, and re-issues the same five commands as 24 V sourcing outputs.
4. Omron 3G3FV accepts the 24 V commands on terminals S1-S5 and produces a three-phase PWM output to the ABB motor at the preset frequency selected by the binary combination on S3-S5.

Each layer has a defined responsibility. The PC owns the recipe. The Arduino owns the human-machine interface role at the 5 V logic level. The PLC owns the safety chain, e-stop handling, and latching logic. The VFD owns the power conversion and motor protection. Splitting responsibilities this way means a single failure mode (lost USB cable, watchdogged Arduino, jammed PLC output) cannot command the motor to an unsafe state without tripping the safety chain.

Prerequisites and Bill of Materials

The minimum hardware and software stack required to reproduce the project is:

You also need a USB-A to USB-B cable for the Arduino, a PPI multi-master cable (RS-485) or USB-PPI adapter for the S7-200, and a shielded multi-conductor cable for the 24 V signal runs between the cabinet and the motor junction box.

Omron 3G3FV Multi-Speed Terminal Configuration

The 3G3FV drives multi-speed references through three binary-coded digital inputs on its control terminal strip. The full preset matrix is selected by the combination of three hardware inputs (commonly S3, S4, S5 on the 3G3FV control card), giving 2^3 = 8 possible speed selections. The MAIN reference (analog or jog) takes priority when all three inputs are open, and multi-step speeds 1 through 7 are addressed in binary from 001 to 111. The default frequency for each step is configured in parameters n36 through n42.

Refer to the official Omron 3G3FV product family page and the 3G3FV multi-function compact inverter manual (CSM4173) for frame-specific defaults and full parameter listings.

Parameter Table for Multi-Step Speed and Digital Inputs

The S3, S4, S5 bits form a 3-bit binary word in little-endian order: bit 0 = S3, bit 1 = S4, bit 2 = S5. The motor will run at the frequency stored in n36 (LSB=001) through n42 (MSB=111) whenever the corresponding input combination is held active. The 3G3FV latches the latest valid combination on the rising edge of S1 (forward) or S2 (reverse). Once started, changing S3-S5 while running will ramp the motor to the new frequency using the acceleration time set in n09.

The percentages assumed above are based on a 50 Hz nominal motor. If the ABB MU80A19 is rated at 60 Hz, multiply all n36-n42 values by 1.20 to retain the same proportional speed. If the motor nameplate voltage is 230 V and the drive is wired for 400 V, lower the V/f curve parameter n11 (or n12 for torque boost) accordingly to avoid magnetic saturation at low frequencies.

Arduino UNO R3 Firmware - Issues With the Provided Sketch

The sketch circulated with the original learning project contains several errors that prevent it from compiling or running. The following is a verbatim list of the issues observed in the source code:

1. The variable command is referenced in the conditional checks (command == F("11000")) but is never declared.
2. pinMode() calls are missing in setup(), so the AVR DDR registers remain in their default (input) state and digitalWrite() will only enable or disable the internal pull-up rather than drive the pin.
3. The line Serial.println(F"Motor FORWARD")); has a stray closing parenthesis.
4. The line digitalWrite(8,1) is missing its trailing semicolon.
5. Serial.end() is placed outside the if (Serial.available() > 0) block and runs unconditionally on every loop iteration, which disables the UART the moment the buffer drains and prevents further commands from being received.
6. All seven speed combinations rely on independent sets of digitalWrite() calls rather than a binary helper, doubling the maintenance cost and inviting copy/paste errors.
7. There is no fail-safe transition: a speed command received while the motor is reversing will change speed bits without clearing direction, which can latch a contradictory command on the drive if the PLC has latched both S1 and S2 simultaneously.

These defects mean the firmware as posted will not build under Arduino IDE 1.8.x or 2.x and would not function as a motor controller even if the syntax errors were corrected manually.

Corrected Arduino Sketch

The following sketch fixes every defect, exposes the speed bit pattern through a single helper function, and routes all direction changes through a dedicated state machine that always clears the inactive direction line before energizing the new one.

/*
 *  Arduino UNO R3 - Serial interface to Omron 3G3FV
 *  Five TTL outputs drive S1 (FWD), S2 (REV), and multi-speed
 *  binary selector S3, S4, S5.
 *
 *  Compile target: Arduino UNO, ATmega328P, 16 MHz
 *  Baud: 9600 8N1
 */

#include <Arduino.h>

// ---- Pin map (Arduino UNO R3) ----
const uint8_t PIN_FWD      = 13;   // -> 3G3FV terminal S1 (via level translator)
const uint8_t PIN_REV      = 12;   // -> 3G3FV terminal S2
const uint8_t PIN_SPEED0   =  8;   // -> 3G3FV terminal S3 (multi-step bit 0)
const uint8_t PIN_SPEED1   =  9;   // -> 3G3FV terminal S4 (multi-step bit 1)
const uint8_t PIN_SPEED2   = 10;   // -> 3G3FV terminal S5 (multi-step bit 2)

const unsigned long SERIAL_BAUD = 9600;
const unsigned long SERIAL_TIMEOUT_MS = 50;

// Last received command (debug/observability)
String command;

void applySpeedBits(uint8_t bits) {
  digitalWrite(PIN_SPEED0, (bits & 0x01) ? HIGH : LOW);
  digitalWrite(PIN_SPEED1, (bits & 0x02) ? HIGH : LOW);
  digitalWrite(PIN_SPEED2, (bits & 0x04) ? HIGH : LOW);
}

void stopMotor() {
  digitalWrite(PIN_FWD, LOW);
  digitalWrite(PIN_REV, LOW);
  applySpeedBits(0);                // 000 = MAIN reference (often zero)
  Serial.println(F("STOP Motor"));
}

void motorForward() {
  digitalWrite(PIN_REV, LOW);       // clear opposite direction first
  digitalWrite(PIN_FWD, HIGH);
  Serial.println(F("Motor FORWARD"));
}

void motorReverse() {
  digitalWrite(PIN_FWD, LOW);
  digitalWrite(PIN_REV, HIGH);
  Serial.println(F("Motor BACKWARD"));
}

void setVelocity(uint8_t step) {
  // step is 1..7, mapped to 3-bit binary 001..111
  applySpeedBits(step & 0x07);
  Serial.print(F("Motor VELOCITY step "));
  Serial.println(step);
}

void setup() {
  Serial.begin(SERIAL_BAUD);
  Serial.setTimeout(SERIAL_TIMEOUT_MS);

  pinMode(PIN_FWD,    OUTPUT);
  pinMode(PIN_REV,    OUTPUT);
  pinMode(PIN_SPEED0, OUTPUT);
  pinMode(PIN_SPEED1, OUTPUT);
  pinMode(PIN_SPEED2, OUTPUT);

  stopMotor();                      // energize a safe state at boot
}

void loop() {
  if (Serial.available() <= 0) return;

  command = Serial.readStringUntil('\n');
  command.trim();

  if (command == "11000" || command == "stop_motor")          stopMotor();
  else if (command == "12000" || command == "motor_forward")  motorForward();
  else if (command == "13000" || command == "motor_backward") motorReverse();
  else if (command == "14000" || command == "motor_velocity_1") setVelocity(1);
  else if (command == "15000" || command == "motor_velocity_2") setVelocity(2);
  else if (command == "16000" || command == "motor_velocity_3") setVelocity(3);
  else if (command == "17000" || command == "motor_velocity_4") setVelocity(4);
  else if (command == "18000" || command == "motor_velocity_5") setVelocity(5);
  else if (command == "19000" || command == "motor_velocity_6") setVelocity(6);
  else if (command == "20000" || command == "motor_velocity_7") setVelocity(7);
  else {
    Serial.print(F("UNKNOWN CMD: "));
    Serial.println(command);
  }
}

Note the absence of Serial.end(): that call is intended for power management, not for routine loop termination, and was responsible for bricking the UART in the original sketch. The corrected code also collapses the seven speed cases into a single applySpeedBits() helper, removing the copy/paste duplication.

Serial Command Protocol

The command set is intentionally simple ASCII so it can be typed by hand from PuTTY. Each command is terminated by a newline (carriage return is ignored by the Arduino readStringUntil('\n') parser). The numeric prefix encodes the command class; the textual alias is for readability and logs.

Because the direction command and the speed command are sent as separate messages, the PLC can latch the speed bits before the run command and the VFD will ramp to the new frequency on the next start. A typical sequence typed into PuTTY to run the project:

14000        <-- step 1 (20 %)
12000        <-- forward run
11000        <-- stop after 5 s
13000        <-- reverse after another 5 s
16000        <-- step 3 (60 %)
18000        <-- step 5 (100 %)
11000        <-- final stop

In an automated recipe, the PC host (a Python or Node-RED script) can drive the same sequence with timing controlled by the host. Treat the Arduino as a stateless terminal: every command is independently interpreted, no session is held.

Siemens S7-200 CPU 215 Ladder Logic

The S7-200 sits between the Arduino (5 V) and the 3G3FV (24 V). It performs three jobs: read the five Arduino lines through 24 V digital inputs, apply a hardwired e-stop interlock, and re-emit the validated pattern on five 24 V sourcing outputs.

For a CPU 215 with the integrated I/O (14 DI / 10 DO on the base unit), allocate the addresses as follows. The V-memory addresses shown are typical for the CPU 215; refer to Siemens S7-200 system manual entry for the I/O map of the exact order number.

Network 1 - E-Stop Pass-Through (Forward)

|    estop_ok    arduino_fwd    vfd_fwd
|------| |--------| |------------( )------|

This rung forwards the forward command only if the e-stop contact is closed. If the e-stop is pressed, Q0.0 drops and the VFD ramps down with the configured deceleration time.

Network 2 - Reverse With Mutual Exclusion

|  estop_ok  arduino_rev  NOT vfd_fwd   vfd_rev
|----| |------| |----------|/|-----------( )---|

Reverse is allowed only if e-stop is OK and forward is not currently asserted. This prevents the dangerous case where both S1 and S2 are energized at the same time, which on the 3G3FV is treated as a fast-stop input by default. A small deadband timer (TON T38, 100 ms) on the transition from forward to reverse is recommended to give the drive time to ramp to zero before reverse is asserted.

Network 3 - Speed Bits Forwarding

|  estop_ok  arduino_speed0    vfd_speed0
|----| |------| |--------------( )------|

|  estop_ok  arduino_speed1    vfd_speed1
|----| |------| |--------------( )------|

|  estop_ok  arduino_speed2    vfd_speed2
|----| |------| |--------------( )------|

The three multi-step bits are passed through directly under the same e-stop gate. Because the VFD latches the speed selection on the rising edge of the run command, the speed bits must be valid before S1 or S2 is asserted. The PC host must therefore send the speed command first, then the direction command.

For diagnostic purposes, add Network 4 to latch an ARDUINO_COM_LOST alarm if Q0.0 has not been requested within the last 10 seconds while the system is in RUN mode. This is implemented with a TON (on-delay) timer T37 resetting on every forward command. The alarm can be wired to Q0.5 and connected to the drive's external fault input S3 (if not used for multi-step) or to a panel indicator.

TTL-to-24V Level Translation

The Arduino UNO outputs 5 V TTL, but every S7-200 input is a 24 V IEC 61131-2 type 1/3 sink. A direct connection will read as "0" on the PLC because 5 V is below the type 1 threshold (typically 8 V minimum). The cleanest translation is an NPN Darlington array such as the ULN2003A:

• Arduino pin -> 1 kohm base resistor -> ULN2003 input (pins 1-7).
• ULN2003 output -> S7-200 input terminal.
• S7-200 24 V common -> ULN2003 COM pin (flyback protection, not strictly needed since the PLC inputs are resistive).

Each ULN2003 channel can sink up to 500 mA, comfortably more than the few mA drawn by a single S7-200 input. Five channels are required (FWD, REV, S0, S1, S2). The ULN2003 inverts logic: write HIGH to the Arduino pin to energize the PLC input.

If you prefer non-inverting logic, use discrete NPN transistors (2N2222, BC547) with the emitter tied to 24 V common, the collector tied through a 4.7 kohm pull-up to 24 V and to the PLC input, and the base driven from the Arduino pin through a 4.7 kohm resistor. In that topology, write HIGH on the Arduino to energize the PLC input (non-inverting). For the project size, the ULN2003 is recommended because it is a single DIP-16 part with built-in base resistors on the breakout board versions.

An alternative is the TXB0108 bidirectional level shifter, but its 8-channel count and 3.6 V maximum on the high side make it a poor fit for 24 V unless followed by a discrete driver. For learning projects, the ULN2003 is the right answer.

Wiring Topology

The Arduino never sees the 24 V side. The ULN2003A is the only component bridging the two voltage domains. The 3G3FV and the S7-200 share a 24 V DC control supply, isolated from the 3-phase power section by the drive's internal SMPS.

Commissioning and Verification Procedure

1. Inspect the wiring. With mains locked out and tagged, verify continuity on every signal conductor from the Arduino pin, through the ULN2003, into the PLC input, and from the PLC output to the VFD terminal. A 4-wire resistance check is the minimum.
2. Power the 24 V control section only. Energize the 24 V supply feeding the S7-200 and the VFD control terminals. The 3-phase section must remain locked out.
3. Verify VFD parameter write. Using the 3G3FV digital operator (the handheld keypad on the front of the drive), confirm n01, n02, n36-n42, n50-n54, n58. Cycle power once after writing to commit to EEPROM.
4. Test Arduino outputs with a multimeter. With the sketch uploaded, send motor_forward from PuTTY. Measure +5 V on D13 with reference to Arduino GND. Confirm 0 V on D12, D8, D9, D10. Repeat for each command in the table above.
5. Test level translation. With 24 V still on, probe the PLC input terminals with a multimeter in DC volts. Each input should swing between 0 V and 24 V as the corresponding Arduino line is toggled. If a channel stays flat at 24 V, the ULN2003 output transistor is shorted; if it stays at 0 V, the base resistor is open or the wiring is reversed.
6. Verify PLC outputs. Toggle the Arduino lines and confirm Q0.0-Q0.4 on the S7-200 respond. The easiest way is to add a watch table in STEP 7 Micro/WIN with the inputs forced (use only with motor locked out).
7. Enable mains and run no-load. Restore 3-phase mains with the motor uncoupled from any load. Issue the speed-1 then forward command. The motor should ramp to 10 Hz (approximately 20 % of 50 Hz) over 5 s, run smoothly, and stop on the stop command.
8. Validate the full sequence. Run the complete five-stage recipe and time each segment with a stopwatch. Verify the motor direction matches the requested segment and that there is no audible oscillation at any speed step.
9. Capture waveforms. For a deeper sign-off, capture the VFD output with a current clamp on one phase and confirm the fundamental frequency matches the requested step (10 Hz at step 1, 30 Hz at step 3, 50 Hz at step 5).
10. Document the parameter set. Use the 3G3FV's parameter copy feature or a hand-written sheet to record the final n-parameters and the ladder logic export. Store in the project folder.

Troubleshooting Matrix

Python Host Script for Automated Sequencing

For unattended runs, replace the manual PuTTY operator with a Python script using the pyserial library. The script sends the same ASCII commands with precise time.sleep() intervals between segments.

import serial, time

ser = serial.Serial('COM5', 9600, timeout=1)
time.sleep(2)  # allow Arduino reset on open

def send(cmd):
    ser.write((cmd + '\n').encode('ascii'))
    print(ser.readline().decode().strip())

# Speed step 1 (20 %), forward 5 s, stop 5 s
send('motor_velocity_1')
send('motor_forward')
time.sleep(5)
send('stop_motor')
time.sleep(5)

# Reverse 10 s at step 1
send('motor_backward')
time.sleep(10)
send('stop_motor')

# Ramp through 20 %, 60 %, 100 %
for step in ['motor_velocity_1', 'motor_velocity_3', 'motor_velocity_5']:
    send(step)
    send('motor_forward')
    time.sleep(5)
    send('stop_motor')
    time.sleep(2)

ser.close()

Replace COM5 with the actual port from Arduino IDE -> Tools -> Port. On Linux the device will be /dev/ttyUSB0 or similar. The 2-second pause after serial.Serial() is required because the Arduino UNO resets whenever the DTR line is asserted by the USB bridge; without the pause the first command is lost.

Safety Considerations

Working with a VFD-driven motor carries the same electrical hazards as any industrial installation. Three rules apply:

• Lockout/tagout (LOTO). Open the upstream disconnect, apply a personal padlock, and verify zero voltage at the drive input terminals L1/L2/L3 with a CAT III 600 V meter before any wiring change.
• E-stop wiring. The e-stop button must be a positively-driven NC contact (IEC 60947-5-1) wired directly to the S7-200 input, not through software. Software can fail; a hardware chain cannot.
• Parameter write protection. After commissioning, lock the 3G3FV against accidental parameter changes using parameter n70 (initialization lock) where supported, or apply a password if the optional Omron CX-Drive tool is used.

For a learning project at low voltage (single-phase 230 V input, 3-phase 230 V motor), the hazards are still real but reduced. For a 400 V three-phase input, the DC bus sits at approximately 540 V DC after rectifier and remains charged for several minutes after mains removal. The drive's internal discharge resistors will bring this below 50 V typically within 5 minutes, but always measure before touching.

FAQ