Adding a Yaskawa GA500 VFD to Studio 5000 Version 38: From a Blank Project to a Running Motor

Modern variable-frequency drives are capable of much more than simply starting and stopping a motor. When a Yaskawa GA500 is connected to a Rockwell Automation Logix controller over EtherNet/IP, the PLC can command the drive, control its speed, monitor operating conditions, detect faults, and expose detailed diagnostic information to an HMI.

The challenge is getting all of the pieces working together correctly.

This article walks through the process of adding a Yaskawa GA500 AC drive to Studio 5000 Logix Designer Version 38, configuring the EtherNet/IP connection, building the PLC tags and logic, and commissioning the system until the motor is actually running.

The procedure is based in part on the workflow demonstrated in the accompanying “All You Need to Know About a Yaskawa VFD Model GA500 with Studio 5000 Version 38” video, including the use of Yaskawa DriveWizard, Yaskawa’s tag-generation resources, Studio 5000, and live commissioning.

Yaskawa officially supports EtherNet/IP communication on the GA500 through options including the SI-EN3, SI-EN3D, and JOHB-SMP3-MB. The SI-EN3/SI-EN3D installations on a GA500 require the appropriate GA500 option-card carrier. Yaskawa

1. What We Are Building

The finished control system is straightforward:

Studio 5000 / Logix PLC → EtherNet/IP → Yaskawa GA500 → AC Motor

The PLC will ultimately be able to:

• Establish an EtherNet/IP I/O connection with the GA500.
• Issue Run and Stop commands.
• Send a speed or frequency reference.
• Read drive status.
• Determine whether the drive is running.
• Monitor operating data.
• Detect drive faults and alarms.
• Reset faults when appropriate.
• Make drive information available to the rest of the machine program or HMI.

The important point is that getting a green Ethernet connection is only the first step. A successful installation requires the drive parameters, EtherNet/IP assemblies, Studio 5000 module configuration, data mapping, and PLC logic to agree with one another.

2. Hardware Required

For a typical installation you will need a Yaskawa GA500, a compatible EtherNet/IP option such as the SI-EN3 or SI-EN3D, an Allen-Bradley Logix-family controller, Ethernet infrastructure, Studio 5000 Logix Designer Version 38, and a properly wired three-phase motor.

Depending on the communication option being used, the GA500 may also require the appropriate option mounting hardware. Yaskawa specifically notes that the SI-EN3 and SI-EN3D require the JOHB-GA50 option card carrier when installed on a GA500. Yaskawa

Before commissioning the network, verify the basic drive installation independently. Power wiring, grounding, motor wiring, motor nameplate information, overload protection, STO/safety circuits, and machine safety should all be addressed before attempting to run the motor from the PLC.

A VFD should never be treated as the machine’s sole personnel-safety device.

3. Start With the Drive

One of the most common mistakes when integrating a VFD is beginning in Studio 5000 before the drive itself has been commissioned.

Start at the GA500.

Verify that the drive powers up normally and that there are no active faults. Enter the motor information required for your application and configure the appropriate control mode, acceleration time, deceleration time, maximum frequency, minimum frequency, and other machine-specific parameters.

Yaskawa publishes a dedicated GA500 Programming Manual as well as a more extensive GA500 Technical Reference covering installation, startup, programming, operation, parameters, and troubleshooting. Yaskawa

Do not blindly copy every parameter from another machine. Motor voltage, current, frequency, RPM and control requirements should correspond to the motor and application you are actually commissioning.

4. Tell the GA500 Where Its Commands Are Coming From

This is one of the most important parts of the entire setup.

A drive can have a perfectly healthy Ethernet connection while completely ignoring the PLC’s Run command because the drive is still configured to accept commands from somewhere else.

There are two fundamental questions:

Where does the speed reference come from?

and

Where does the Run command come from?

For Ethernet control, configure those selections appropriately for your GA500 and installed network option.

The equivalent Yaskawa configuration principle is:

Frequency Reference → Ethernet

Run Command → Ethernet

This is why troubleshooting should distinguish between communication and control authority. They are not the same thing.

A PLC can communicate with the VFD while the VFD still refuses to start because its command source is configured for the keypad or physical terminals.

5. Configure the EtherNet/IP Option

Next, configure the Ethernet side of the drive.

At minimum, determine:

IP Address
Subnet Mask
Gateway, if required
PLC IP Address
Network topology

For example, a small isolated machine network might use addresses similar to:

PLC:       192.168.1.85
GA500:     192.168.1.94
Laptop:    192.168.1.10

Subnet:    255.255.255.0

These addresses are only examples. Use the addressing scheme established for your machine or facility.

The GA500 EtherNet/IP option provides the interface through which the drive exchanges data with an EtherNet/IP scanner such as a ControlLogix or CompactLogix controller. Yaskawa documents both single-port SI-EN3 and dual-port SI-EN3D options for this purpose. Yaskawa

Before touching the PLC program, confirm basic network connectivity.

If the computer cannot reach the drive, Studio 5000 will not magically solve the problem.

6. Use Yaskawa DriveWizard Before Programming the PLC

This is an especially useful part of the workflow demonstrated in the video.

Yaskawa’s software provides a much better view into the drive than trying to diagnose everything exclusively from the keypad.

DriveWizard can be used during commissioning to review parameters, verify drive configuration, inspect monitor values, and determine whether the drive is actually receiving the expected commands.

This creates a valuable troubleshooting division:

Studio 5000
     ↓
PLC output data
     ↓
EtherNet/IP
     ↓
GA500 communication option
     ↓
GA500 command processing
     ↓
Motor

If the PLC says Run but the drive does not, work down that chain rather than immediately rewriting ladder logic.

7. Get the Correct Yaskawa EDS File

The Electronic Data Sheet, or EDS file, describes the EtherNet/IP device to Rockwell software.

Yaskawa publishes EDS files specifically for its EtherNet/IP options. For example, Yaskawa’s SI-EN3 EDS package explicitly lists the GA500 among the supported drives. Yaskawa

Whenever possible, use the EDS file corresponding to the actual communication option and firmware installed in the drive.

This is preferable to guessing at the module configuration.

Install/register the EDS file using Rockwell’s EDS hardware installation utility as appropriate for the workstation.

After registration, restart or refresh the applicable Rockwell software if necessary.

8. Add the Drive to Studio 5000 Version 38′

Now open the Logix Designer project.

Studio 5000 Logix Designer Version 38 is part of Rockwell’s Version 38 Logix platform release. Rockwell Automation

Navigate through the controller tree to the Ethernet network associated with the PLC.

The basic path is generally:

I/O Configuration
    └── Ethernet Network
          └── New Module

Depending on the EDS/AOP support available for the particular Yaskawa option, the drive may be added through its registered device profile or configured using the appropriate Ethernet module definition.

Enter a meaningful name rather than something generic.

For example:

YaskawaGA500

or:

GA500_MainConveyor

Good naming becomes extremely valuable when a machine eventually contains ten, twenty, or fifty drives.

Enter the GA500’s IP address and verify the module/connection definition.

9. Understand the EtherNet/IP I/O Assemblies

This is where many first-time integrations go wrong.

An EtherNet/IP VFD exchanges blocks of data with the PLC through assemblies.

Think of them as two packages.

PLC                         GA500
 |                            |
 |---- Output Assembly ------>|
 |                            |
 |<---- Input Assembly -------|

From the PLC’s perspective:

Output data

The PLC sends data to the drive.

This typically contains information such as:

Command word
Frequency / speed reference
Additional command data

Input data

The PLC receives data from the drive.

Depending on the selected assembly and configuration, this can include items such as:

Drive status
Output frequency
Output current
Fault information
Operating status
Monitor values

The exact assembly layout must come from the Yaskawa documentation or configuration tool for the option and assembly being used.

Do not assume that Word 0 or Bit 0 means the same thing on every drive.

10. Data Types Matter

Industrial Ethernet devices frequently exchange data as arrays of integers or bytes.

That means the controller might initially expose something resembling:

GA500:I.Data[x]
GA500:O.Data[x]

Those raw numbers are useful to the network but not particularly friendly to a programmer.

Instead of writing machine logic directly against anonymous array positions, convert the raw communication data into meaningful tags.

For example:

GA500_RunCmd
GA500_StopCmd
GA500_ResetCmd

GA500_SpeedReference

GA500_Ready
GA500_Running
GA500_AtSpeed
GA500_Faulted

GA500_OutputFrequency
GA500_OutputCurrent

This makes the program dramatically easier to troubleshoot.

11. Use Yaskawa’s Tag Generator

The video demonstrates an important tool that can save a substantial amount of programming time: Yaskawa’s Tag Generator Support Tool for Logix Designer/RSLogix 5000 & TIA Portal.

Instead of manually interpreting dozens of raw words and bits, the Yaskawa resources can be used to help establish meaningful tags and mappings corresponding to the selected drive communication data.

That changes the programming experience from something like:

Drive:I.Data[7]

to something that actually communicates intent:

Drive_Output_Current

or:

Drive_Fault

For a technician standing in front of a stopped machine at 2:00 AM, that difference matters.

12. Build a Clean PLC Interface

Even when generated tags are available, I recommend separating the raw drive communications from the machine logic.

Conceptually:

GA500 EtherNet/IP Data
          ↓
Drive Interface Logic
          ↓
Machine-Level VFD Tags
          ↓
Sequence / HMI / Auto Logic

For example:

Machine_Start_Request
Machine_Stop_Request
Machine_Speed_Command

feed a drive-control routine.

That routine generates:

GA500_Run_Command
GA500_Frequency_Command

The returned drive information is then converted into:

Motor_Running
Motor_Ready
Motor_Faulted
Motor_AtSpeed
Motor_ActualSpeed

The rest of the machine never needs to know that Data[3].7 happens to represent something inside a Yaskawa assembly.

That is good PLC architecture.

13. Programming the Run Command

At its simplest, the logic needs to decide whether the VFD is permitted to run.

A conceptual ladder rung might be:

In a real machine there will normally be additional permissives.

These might include:

E-stop system healthy
Guard circuit healthy
Motor overload condition healthy
Downstream equipment ready
Upstream equipment ready
Process permissive
Maintenance mode
Jam detection

Once all permissives are satisfied, the appropriate bit in the GA500 command data can be energized.

14. Programming the Speed Command

The PLC also needs to send the drive a frequency or speed reference.

Suppose an operator requests:

45.00 Hz

The value placed on the network may not literally be the floating-point number 45.00.

Industrial drives frequently represent engineering units using scaled integers.

For example, a hypothetical scaling could be:

45.00 Hz × 100 = 4500

The PLC would therefore transmit:

4500

not:

45.0

The actual scaling must be taken from the Yaskawa assembly/register definition being used.

Never guess the scaling.

Incorrect scaling is one of the classic situations where the network is healthy and the Run command works, but the motor operates at an unexpected speed—or appears not to run because the reference is effectively zero.

15. Separate Engineering Units From Network Units

A good program allows the rest of the machine to work in meaningful engineering units.

For example:

Operator_Speed_Hz = 45.0

The VFD interface performs the conversion:

Operator_Speed_Hz
        ↓
Scaling Logic
        ↓
EtherNet/IP Integer
        ↓
GA500

Likewise, incoming drive values should be converted back into engineering units.

Instead of an HMI displaying:

4376

display:

43.76 Hz

The machine programmer should not have to remember scaling factors every time a VFD tag is used.

16. Decode the Status Word

The incoming status word is just as important as the command word.

Individual bits tell the PLC what the drive is actually doing.

A properly designed interface should decode useful states such as:

Ready
Running
Zero Speed
At Speed
Faulted
Warning
Direction
Communication Healthy

The exact bits depend on the selected Yaskawa assembly.

Create descriptive BOOL tags for them.

For example:

VFD.Ready
VFD.Running
VFD.Faulted
VFD.AtSpeed

Then use those tags throughout the machine.

17. Commanded Run Is Not the Same as Running

This distinction is critical.

Suppose:

VFD_Run_Command = 1

That only tells you what the PLC asked for.

It does not prove that the motor is running.

The PLC should also monitor the drive’s returned status.

Conceptually:

Run Command = 1
Running Feedback = 1

indicates a successful start.

But:

Run Command = 1
Running Feedback = 0

for several seconds means something is wrong.

A timer can turn this into a useful machine fault:

Run command
AND NOT running feedback
AND timer done
--------------------------( VFD_Failed_To_Start )

This is far better than simply assuming that energizing a Run bit means the motor started.

18. Fault Handling

A production-quality program needs to deal with faults deliberately.

At minimum, monitor:

Drive fault active
Fault code
Communication fault
Drive ready
Running status

When the GA500 faults, the machine should generally remove the Run request and report useful diagnostic information.

A reset command should normally be a momentary action, not a permanently energized bit.

Conceptually:

Operator_Reset
     ↓
One-shot
     ↓
GA500 Fault Reset

Do not design the program to continuously reset a fault without determining why the fault occurred. Repeatedly resetting an overcurrent, overvoltage, motor overload, or other protective trip can turn a useful drive protection function into a machine hazard.

19. Communication Health

Another important state is:

VFD_Comm_OK

Do not determine communication health only by looking at the Ethernet LEDs.

The PLC should know whether the actual I/O connection is established.

A communication failure should cause the machine logic to respond appropriately.

For example:

VFD_Comm_OK = 0

might generate:

VFD Communication Fault

and prevent the sequence from attempting to run that motor.

This makes diagnostics far easier for maintenance personnel.

20. Download and Establish the Connection

Once the module and logic have been configured:

1. Verify the project.
2. Correct any programming errors.
3. Download to the controller if required.
4. Put the controller into the appropriate operating mode.
5. Go online.
6. Open the drive/module properties.
7. Verify that the EtherNet/IP connection is established.

The goal is to see a healthy device in the I/O tree rather than a warning symbol or connection fault.

If the module will not connect, investigate the communication layer before troubleshooting ladder logic.

21. First Commissioning Test

Do not immediately command full speed.

Start conservatively.

First confirm:

PLC online
EtherNet/IP connection healthy
GA500 ready
No active VFD fault
Safety circuit healthy
Motor mechanically safe to rotate

Set a low speed reference.

For example:

10 Hz

Then command Run.

Watch both Studio 5000 and the drive.

You should see the command leave the PLC, the drive recognize the command, output frequency begin increasing, the motor accelerate, and Running feedback return to the controller.

The information flow should look like this:

PLC Run Request
       ↓
Command Word
       ↓
EtherNet/IP
       ↓
GA500
       ↓
Motor Accelerates
       ↓
GA500 Status
       ↓
EtherNet/IP
       ↓
PLC Running Feedback

Once this works, the fundamental integration is complete.

22. Test Several Speeds

Now verify scaling.

Try several controlled references such as:

10 Hz
20 Hz
30 Hz
45 Hz
60 Hz

where appropriate for the motor and application.

At each point compare:

PLC command
Drive reference
Drive output frequency
Motor behavior
PLC feedback

They should agree within the expected behavior of the application.

This test catches scaling errors very quickly.

23. Test Stop Behavior

A commissioning procedure isn’t complete because the motor started.

Test the stop.

Verify that removing the Run command produces the expected deceleration behavior.

Confirm that the configured stopping method is appropriate for the machine.

A conveyor, pump, fan, spindle and high-inertia rotating assembly may all require different acceleration/deceleration behavior.

Never assume that the factory-default deceleration time is suitable for the application.

24. Test Fault Recovery

A properly commissioned system should also be tested under controlled fault conditions where safe and appropriate.

Verify that:

The PLC recognizes a drive fault.
The Run command is removed as intended.
The HMI receives the fault indication.
The fault code is available for troubleshooting.
Reset logic behaves correctly.
The machine cannot unexpectedly restart.

This is where a professional VFD program differs from a simple “make the motor spin” program.

25. Troubleshooting: PLC Sees the Drive but It Won’t Run

This is probably the most useful troubleshooting distinction to remember.

If Studio 5000 shows a healthy connection but the motor will not run, check:

Command source. Is the GA500 configured to accept Run commands from Ethernet?

Reference source. Is the frequency reference configured to come from Ethernet?

Command word. Is the correct Run bit actually changing?

Speed reference. Is a nonzero reference reaching the drive?

Scaling. Is that reference encoded correctly?

Drive status. Is the drive Ready?

Fault state. Is a fault or alarm preventing operation?

Safety circuit. Is STO or another external permissive preventing torque?

Motor/application configuration. Is the GA500 properly commissioned for the connected motor?

A green network connection proves communication. It does not prove that every condition required to run the motor has been satisfied.

26. Troubleshooting: Studio 5000 Cannot Connect to the GA500

If the I/O tree shows a fault, start with networking.

Verify:

Correct IP address
Correct subnet
No duplicate IP address
Correct physical Ethernet connection
Correct EtherNet/IP option
Correct EDS/device definition
Correct assembly configuration
Correct input/output sizes
Compatible option firmware
PLC Ethernet interface operating correctly

Yaskawa’s EtherNet/IP technical manuals document the installation, network communication and supported messaging for the SI-EN3/SI-EN3D options. Yaskawa

Also remember that module configuration choices matter in Logix Designer. Rockwell notes that some module communication-format properties cannot simply be changed after creation; changing certain configurations can require deleting and recreating the module. Rockwell Automation

27. Troubleshooting: Motor Runs at the Wrong Speed

If Run works but speed is wrong, the first suspect should be scaling.

Compare:

Desired engineering value
        ↓
PLC conversion
        ↓
Raw output value
        ↓
GA500 reference
        ↓
Actual output frequency

Watch all five while online.

This usually reveals the problem immediately.

28. Troubleshooting: PLC Commands Change but the Drive Ignores Them

Use DriveWizard and Studio 5000 together.

If the PLC output changes but the corresponding command does not appear at the drive, investigate the network configuration and data mapping.

If the command reaches the drive but the drive does not act on it, investigate the GA500’s control-source configuration, permissives, faults, and drive parameters.

This two-sided troubleshooting approach is demonstrated well in the accompanying video because it prevents the common mistake of assuming every problem must be in the PLC.

29. Build the Program for the Next Technician

A machine is not finished when the original programmer can operate it.

It is finished when somebody else can troubleshoot it.

Avoid programs full of unexplained references such as:

Local:2:I.Data[14].5

Instead expose meaningful information:

Conveyor_VFD.Ready
Conveyor_VFD.RunCmd
Conveyor_VFD.Running
Conveyor_VFD.SpeedCommand
Conveyor_VFD.ActualFrequency
Conveyor_VFD.OutputCurrent
Conveyor_VFD.Faulted
Conveyor_VFD.FaultCode
Conveyor_VFD.CommOK

Whether these are implemented through a UDT, AOI, structured tags, aliases, or generated Yaskawa tags depends on the standards used at the facility.

The principle remains the same:

Raw communication data belongs at the device interface. Machine logic should use meaningful names.

30. A Recommended Final Architecture

A clean implementation might ultimately look like:

CONTROLLER
│
├── I/O Configuration
│      └── GA500_MainConveyor
│
├── Raw Yaskawa I/O
│      ├── Input Assembly
│      └── Output Assembly
│
├── VFD Interface
│      ├── Command Mapping
│      ├── Status Mapping
│      ├── Speed Scaling
│      ├── Fault Handling
│      └── Communication Monitoring
│
├── Machine Logic
│      ├── Start Permissives
│      ├── Run Request
│      └── Speed Request
│
└── HMI
       ├── Run Status
       ├── Speed
       ├── Current
       ├── Fault
       └── Diagnostics

This approach keeps the machine logic independent of the low-level EtherNet/IP implementation.

From a Blank Project to a Running GA500

Integrating a Yaskawa GA500 with Studio 5000 Version 38 becomes much easier when the job is broken into layers.

The sequence is essentially:

Commission the GA500 → configure EtherNet/IP → establish the IP network → obtain the correct EDS/support files → add the drive to Studio 5000 → configure the I/O connection → generate/map the Yaskawa tags → decode commands and status → scale the speed reference → build Run/Stop/fault logic → establish communications → perform a low-speed test → verify feedback → test faults and stopping → document everything.

The biggest lesson is not a particular Studio 5000 instruction or GA500 parameter.

It is understanding the complete signal path.

When the motor doesn’t run, determine exactly where the command stopped:

Machine Request
      ↓
PLC Logic
      ↓
Output Tag
      ↓
EtherNet/IP Assembly
      ↓
GA500 Communication Option
      ↓
Drive Control
      ↓
Motor

Then follow the feedback in the opposite direction.

Once you understand that path, a Yaskawa GA500 stops being a mysterious Ethernet device and becomes another well-defined piece of Logix I/O.

Technical references

Yaskawa’s official GA500 documentation and programming manuals provide the drive-specific parameter information, while the Yaskawa EtherNet/IP documentation covers the network options. The SI-EN3 EtherNet/IP Technical Manual and Yaskawa SI-EN3 EDS package are particularly useful when building the Studio 5000 connection. Rockwell’s Studio 5000 Version 38 documentation covers the Logix Designer side of the system. Yaskawa

Safety note: Commissioning a VFD can cause machinery to start or rotate unexpectedly. Follow the equipment manufacturer’s procedures, applicable electrical/safety standards, lockout/tagout requirements, and the machine’s validated safety design. EtherNet/IP Run/Stop logic is operational control and should not be substituted for required safety functions.