Adding a Yaskawa GA500 VFD to Studio 5000 Version 38 Using Yaskawa’s Add-On Instruction

Introduction

Integrating a variable frequency drive into a PLC program can be as simple as sending a run command and a speed reference, but a well-designed system should do much more. Operators and maintenance personnel need clear drive status, fault information, speed feedback, reset capability, and a program structure that is easy to troubleshoot.

The Yaskawa GA500 can be integrated into Rockwell Automation Studio 5000 Logix Designer Version 38 using EtherNet/IP and Yaskawa’s supplied Add-On Instruction (AOI). Using the AOI significantly reduces the amount of logic that has to be created manually and provides a cleaner interface between the ControlLogix/CompactLogix program and the drive.

In my accompanying video, “Yaskawa VFD Add-On Instruction with Studio 5000 Version 38 – 2026,” I demonstrate this process in an actual Studio 5000 project, including the PLC logic and an HMI-style interface for controlling and monitoring the drives.

This article walks through the same basic process and explains how the pieces fit together.

What We Are Building

The goal is to establish communication between Studio 5000 and a Yaskawa GA500 and then use Yaskawa’s AOI to create a reusable drive-control structure.

At a minimum, we want the PLC to be able to:

• Start and stop the GA500
• Send a speed/frequency reference
• Determine whether the drive is running
• Monitor drive status
• Monitor actual operating information
• Detect faults
• Reset drive faults
• Provide useful information to an HMI
• Maintain a program structure that can easily be duplicated for additional drives

The last point becomes particularly important on machines containing multiple VFDs.

1. Start With the GA500 Hardware

Before writing PLC logic, the physical drive and communications hardware need to be configured correctly.

The GA500 must have the appropriate EtherNet/IP communications capability installed/configured for the application. The drive also needs an IP address that is compatible with the PLC’s Ethernet network.

For example, a machine network might use addresses such as:

PLC
192.168.1.10

GA500 Drive 1
192.168.1.20

GA500 Drive 2
192.168.1.21

The actual addresses are entirely dependent on the machine’s network architecture.

The important part is that every device has a unique address and that the PLC can communicate with the drive.

Before spending time troubleshooting ladder logic, verify basic network communication first.

2. Configure the GA500 for Network Control

A VFD can be communicating perfectly over Ethernet while still refusing to run from the PLC.

Why?

Because communications and command sources are two different things.

The GA500 must be configured so that its run command and frequency reference come from the intended communications interface rather than the keypad or physical terminals.

Conceptually, the drive needs to know:

Where does my RUN command come from?

Where does my SPEED reference come from?

For a PLC-controlled application, those sources normally need to correspond to the network/communications configuration being used.

This is one of the first things I check when a drive communicates but will not respond to PLC commands.

3. Add the GA500 to the Studio 5000 Project

With the hardware prepared, open the project in Studio 5000 Logix Designer Version 38.

Navigate to the controller’s Ethernet configuration under the I/O tree and add the drive/network device.

Once the drive has been configured correctly, Studio 5000 establishes cyclic I/O communication between the controller and GA500.

This produces the fundamental exchange of data:

PLC  ───────────────►  GA500
     Command Data
     Speed Reference

PLC  ◄───────────────  GA500
     Status Data
     Speed Feedback
     Operating Information
     Fault Information

The PLC’s output data controls the drive, while the drive’s input data reports what is actually happening.

That distinction is extremely important when troubleshooting.

4. Download Yaskawa’s Add-On Instruction

Rather than manually decoding every command bit and status word, Yaskawa provides programming resources for Rockwell controllers, including an Add-On Instruction.

An AOI is essentially a reusable block of Logix code.

Instead of having dozens of instructions scattered throughout a program handling individual bits and words, you can create a structured interface around the drive.

Conceptually, the AOI turns raw communication data into something much easier to work with:

Raw EtherNet/IP Data
        │
        ▼
┌─────────────────────────┐
│   Yaskawa GA500 AOI     │
│                         │
│ Start / Stop            │
│ Speed Reference         │
│ Status                  │
│ Feedback                │
│ Fault Reset             │
│ Fault Information       │
└─────────────────────────┘
        │
        ▼
Machine Control Logic

This is one of the biggest advantages of using the manufacturer’s AOI.

5. Import the AOI Into Studio 5000

After obtaining the appropriate Yaskawa AOI files, import them into the Studio 5000 project.

In the Controller Organizer, locate:

Assets → Add-On Instructions

and import the Yaskawa instruction.

Depending on the Yaskawa package being used, there may also be supporting:

• User-defined data types
• Tags
• Instructions
• Routines
• Documentation
• Example logic

It is important to import all required dependencies.

Afterward, the Yaskawa instruction becomes available just like other instructions in Studio 5000.

6. Create an Instance for the GA500

An AOI requires an instance tag.

Think of the AOI definition as the blueprint and the instance tag as the actual copy being used for a particular drive.

For example:

GA500 AOI Definition
       │
       ├── Conveyor_1_Drive
       │
       ├── Conveyor_2_Drive
       │
       └── Exhaust_Fan_Drive

Each drive can use the same AOI while maintaining completely independent operating data.

This makes the approach very scalable.

If a machine eventually grows from two drives to ten drives, you don’t need to reinvent the drive-control architecture ten times.

7. Map the Physical Drive Data to the AOI

This is one of the most important parts of the integration.

The Studio 5000 I/O connection contains the actual data being transferred between the controller and the GA500. The AOI needs access to that information.

In simplified terms:

GA500 Input Data
       │
       ▼
Yaskawa AOI
       │
       ▼
Status / Feedback / Faults


Machine Commands
       │
       ▼
Yaskawa AOI
       │
       ▼
GA500 Output Data

The exact tag names and parameters depend on the version of the Yaskawa AOI and the communications configuration.

This is why I prefer using the manufacturer’s instruction rather than manually recreating the data structure—the AOI provides a consistent framework for dealing with the drive.

8. Build the Start/Stop Logic

Once the AOI is communicating with the GA500, machine permissives can be tied into the drive command.

A real machine normally shouldn’t simply say:

Start Button = Drive Run

Instead, I prefer separating the operator’s request from the machine’s permission to run.

For example:

Operator Start Request
        AND
Machine Auto Mode
        AND
Safety Circuit Healthy
        AND
No Drive Fault
        AND
Motor Permissive
        AND
Process Ready
        │
        ▼
GA500 Run Command

That architecture makes troubleshooting much easier.

If the operator presses Start and the motor doesn’t run, maintenance can determine which condition is preventing the command rather than simply seeing that the drive isn’t running.

9. Send the Speed Reference

The next major command is the frequency or speed reference.

For example, an operator may enter:

Motor Speed Setpoint = 45.0 Hz

The PLC then sends the appropriate reference to the GA500 through the AOI.

However, pay close attention to engineering units and scaling.

Depending on the AOI and communication data being used, a value representing 45 Hz might internally be represented differently.

Never assume that:

45 = 45 Hz

until the AOI documentation and actual drive behavior confirm it.

Incorrect scaling can result in a drive that runs but operates at an unexpected speed.

10. Use Feedback Instead of Assuming the Drive Is Running

One programming mistake I strongly recommend avoiding is assuming that a drive is running simply because the PLC commanded it to run.

These are two different conditions:

Run Command

means:

The PLC wants the drive to run.

Whereas:

Running Status

means:

The drive reports that it is actually running.

A good program monitors both.

That allows the PLC to recognize conditions such as:

Run Command = TRUE
Running Feedback = FALSE

If that condition exists for too long, the program can generate a Failed to Start alarm.

The same principle applies when stopping a motor.

11. Fault Handling

Fault information is one of the most valuable reasons to integrate a VFD through the PLC rather than treating it as a simple start/stop device.

The AOI can be used to expose drive fault and status information to the machine program.

The control system can then provide an HMI indication such as:

DRIVE FAULTED

rather than leaving the operator wondering why the motor stopped.

Even better, the HMI can display useful diagnostic information associated with the fault.

A fault-reset command can also be provided through the PLC.

However, fault reset logic should be intentional.

A reset should not automatically cause machinery to restart unexpectedly. The machine’s safety and restart philosophy should always determine what happens after a fault is cleared.

12. Build an HMI Around the AOI

The video also demonstrates why structured drive programming becomes particularly useful when developing an HMI.

A drive faceplate can display items such as:

Motor Status

STOPPED
RUNNING
FAULTED

Speed Command
Actual Speed

Start
Stop

Fault Reset

Drive Communication Status

Because every GA500 uses the same programming structure, essentially the same HMI object can be reused.

Instead of creating a completely different screen for every motor, the programmer can create one standard drive object and associate it with the appropriate drive tags.

That creates consistency for both operators and maintenance technicians.

13. Scaling the Program to Multiple GA500 Drives

This is where AOIs really start paying off.

Suppose the original machine contains:

Conveyor 1

and later another drive is added:

Conveyor 2

With a standardized AOI architecture, much of the programming already exists.

The second drive receives:

Its own Ethernet connection
Its own I/O tags
Its own AOI instance
Its own command structure
Its own HMI object

but the programming philosophy remains identical.

In the project demonstrated in my video, you can see this kind of structure being used with multiple drive/motor objects on the interface.

For a maintenance technician, consistency matters enormously. Once you understand how one drive is programmed, you essentially understand how all of them are programmed.

14. Commission the Drive in Stages

When bringing the system online, I recommend testing one layer at a time rather than immediately trying to run the entire machine.

A practical commissioning sequence is:

1. Verify Ethernet communication.
2. Verify the controller recognizes the drive.
3. Verify input data from the GA500 is changing.
4. Verify output data is reaching the drive.
5. Confirm the drive command source is configured correctly.
6. Confirm the frequency reference source is configured correctly.
7. Test the drive at a low speed.
8. Verify the reported running status.
9. Compare commanded speed with actual drive operation.
10. Test Stop.
11. Test a controlled fault/reset condition where appropriate.
12. Verify HMI status and alarms.
13. Finally test the drive as part of the complete machine sequence.

This approach isolates problems.

Trying to commission the PLC logic, network, drive parameters, HMI, motor, and machine sequence simultaneously makes troubleshooting unnecessarily difficult.

Common Problems

When the GA500 doesn’t operate as expected, the symptom usually gives you a clue about where to look.

The key is to determine which layer has failed rather than immediately changing PLC code.

Why Use Yaskawa’s AOI?

You certainly can communicate with a GA500 by manually manipulating command words, status words and data registers.

But on a production machine, the Yaskawa AOI provides several advantages.

It gives the programmer a standardized interface, reduces repetitive ladder logic, makes programs easier to read, simplifies HMI development, improves troubleshooting, and makes adding additional drives much easier.

Most importantly, it creates a separation between the raw EtherNet/IP communications and the machine-control logic.

Instead of the rest of the machine program needing to understand every bit inside a drive communication word, the AOI becomes the interface between the two.

The architecture becomes:

                    MACHINE PROGRAM
                          │
            Start / Stop / Speed / Reset
                          │
                          ▼
                 YASKAWA GA500 AOI
                          │
                 EtherNet/IP Data
                          │
                          ▼
                    YASKAWA GA500
                          │
                          ▼
                        MOTOR

And feedback travels in the opposite direction:

MOTOR / DRIVE
      │
      ▼
YASKAWA GA500
      │
      ▼
EtherNet/IP
      │
      ▼
YASKAWA AOI
      │
      ▼
Status / Speed / Faults
      │
      ▼
PLC LOGIC + HMI

That is a much cleaner architecture than spreading drive-specific communications logic throughout the PLC program.

Final Thoughts

Adding a Yaskawa GA500 to Studio 5000 Version 38 is more than simply getting a motor to turn. A properly integrated drive should become part of the machine’s overall control and diagnostic system.

Using Yaskawa’s supplied Add-On Instruction gives you a strong foundation for doing exactly that.

Once communication is established and the AOI is mapped correctly, the PLC can manage run commands, speed references, operating feedback, fault handling, resets, and HMI diagnostics through a consistent programming structure.

For someone learning Studio 5000, this project is also a good example of an important controls concept:

Don’t just program equipment to operate. Program it so the next person can understand why it isn’t operating.

That difference becomes extremely important when the machine reaches the production floor.