GS3 04:SLAVE FAIL Clears When the GS-EDRV100 Sits at the Drive

Stop Tuning the Poll Rate and Read the Symptom

The setup that produces this fault looks like this:

• A Productivity3000 Remote Ethernet port connects over a short Cat5e patch cord to a GS-EDRV100 in the same cabinet.
• The gateway drives a GS3 (GS3-41P0, with a GS3-47P5 still to come) about 130 ft away over the serial side.
• That 130 ft run is Belden 2413 Cat 6, four conductors used, terminated in RJ12 connectors.
• The ladder has one GS Drives Write block and one GS Drives Read block, both on Automatic Polling.
• The GSW Exception Response String regularly shows 04:SLAVE FAIL.

People usually try the same three quick fixes first. None of them clears the fault:

The key clue is that the link always works but responds late and unevenly. A wrong address, baud rate or protocol would fail every time. A link that mostly works but keeps retrying points to the signal quality on the wire.

Check before moving on: confirm that the Read block also shows intermittent errors or stale values. If only the Write block ever reports exceptions, record which one fails more often. You will use that baseline in the final verification.

Prove the Ethernet Leg Is Clean

There are two separate network segments here, and they fail differently:

• Ethernet leg: P3K Remote Ethernet port to the GS-EDRV100. It is a short patch cord inside one cabinet.
• Serial leg: GS-EDRV100 to the GS3 over RS-485. It is 130 ft of field cable.

The GS-EDRV100 is a gateway. The P3K talks Ethernet to the gateway, and the gateway runs the serial transaction to the drive. When the serial transaction fails, the gateway sends the failure back to the P3K as an exception. The P3K therefore reports 04:SLAVE FAIL even when its own Ethernet link is fine. The code tells you something went wrong behind the gateway. It does not mean the drive's processor is faulted.

1. Run Read System Configuration. If it discovers the GS3 automatically, the Ethernet leg and gateway are up.
2. Look at the link/activity LEDs on the gateway and the P3K port. They should show a solid link and steady activity.
3. Leave the in-cabinet Cat5e patch cord alone. A short patch cord on Ethernet is the right medium for that segment.

Check: the drive is discovered and the Ethernet link is steady. Stop here if the Ethernet link drops or discovery fails intermittently. That is a separate Ethernet or port problem, so fix it before touching the serial side.

Move the GS-EDRV100 to the Drive (Preferred Fix)

Cat 6 is built for Ethernet. RS-485 needs cable with the characteristic impedance the transceivers and terminations are designed for. Over a long run, the mismatch causes reflections, and the square edges of the signal get rounded off. The receiver then misreads bits, the frame fails its check, and the master retries. Each retry adds delay. Enough failed retries in a row produce 04:SLAVE FAIL. That explains both the erratic lag and the occasional hard exception.

The cleanest fix changes which segment is long. Put the gateway at the drive so the long run carries Ethernet and the RS-485 run shrinks to a short jumper.

1. Mount the GS-EDRV100 in or beside the GS3 enclosure.
2. Power the gateway there. Take the supply requirement from the GS-EDRV100 manual.
3. Connect the gateway to the GS3 communication port with a short RJ12 cable. Use the pinout in the GS-EDRV100 and GS3 manuals.
4. Re-terminate the existing 130 ft Belden 2413 run with RJ45 connectors, using all four pairs to standard pinout. About 130 ft (roughly 40 m) is well inside the 100 m Ethernet segment limit.
5. Plug the field run into the P3K Remote Ethernet port, or into a switch if the second drive will share the port.

This reuses the cable that is already pulled, and it scales. The GS3-47P5 gets its own GS-EDRV100 at the drive and shares the Ethernet side through a switch.

Check: test the Ethernet run with a cable certifier or at least a continuity/pair-map tester. Read System Configuration should discover the drive again with the same settings.

Or Rebuild the RS-485 Run with the Right Cable

Sometimes the gateway cannot move because there is no power, no panel space, or no room at the drive. In that case, replace the serial run with cable designed for RS-485 and wire it correctly.

1. Pull cable sold for RS-485. Confirm its characteristic impedance on the cable datasheet.
2. Put the two data lines on one twisted pair. With four conductors crimped into an RJ12, it is easy to end up with the two data signals on conductors from different pairs. Differential signalling depends on both signals riding the same pair, so a split pair alone can cause this exact symptom.
3. Run the signal common/reference on its own conductor if the port pinout provides one. This keeps the transceivers inside their common-mode range.
4. Apply line termination at the ends of the segment according to the GS3 and GS-EDRV100 manuals. Do not add termination in the middle of the run.
5. Route the cable away from motor leads and VFD output wiring, and cross power cables at right angles.

Check: before pulling new cable, set the gateway right next to the drive and connect it with a short jumper as a bench test. If the errors disappear and the response becomes quick, the 130 ft run is confirmed as the cause.

Confirm the Drive Communication Parameters

Record the drive settings before and after any wiring change so you are not chasing two variables at once. The installation used:

A mismatch in any P9 value gives total failure, not intermittent failure. The fact that this link half-works means these settings are close enough to be correct. Still, confirm them against the gateway configuration. When the second drive goes in behind its own gateway, give it settings consistent with that gateway's configuration.

Check: read the values back from the GS3 keypad and compare them line by line with the GS-EDRV100 configuration shown in the P3K software.

Tighten Polling Only After the Wire Is Fixed

A 2000 ms poll hid the errors. It did not fix them. Once the physical layer is clean, bring the poll rate back to something usable for the application.

1. Keep one GS Drives Write block and one GS Drives Read block per drive. Leave manual reads and writes off while you tune.
2. Add a rung that counts every time the GSW or GSR Exception Response String is non-empty. Latch the count into a register you can watch.
3. Step the Automatic Polling time down from 2000 ms in stages. Watch the error counter for several minutes at each step, with the motor stopped and then running.
4. Stop reducing when the counter starts moving. Back off one step and leave margin.
5. When the second drive is online, repeat the test with both drives polling. Each gateway runs its own serial transactions, but they share the P3K Ethernet port.

Check: the error counter stays at zero through a full start, speed change and stop cycle at the chosen poll time.

Separate Communication Lag from Ramp Lag

Two delays stacked up in the field:

1. The time between changing the frequency in the PLC and the drive registering the new setpoint. This is the communication delay.
2. The time for the output frequency to reach the new setpoint after the drive accepts it. This is the ramp delay.

Fixing the wire only removes the first delay. The second one is set by the GS3 acceleration and deceleration times. Read those parameters on the keypad and decide whether they suit the process. A long ramp on a jogged axis feels sluggish even with perfect communication.

To see which delay you are looking at, watch the drive display. If the frequency setpoint on the keypad updates within a poll cycle but the output creeps up, the delay is ramp time. If the setpoint itself lags, the delay is still in communication.

For occasional jogging, network command latency adds to the ramp. If jog response has to be crisp or predictable, look at the GS3 manual's multi-function input and jog options for a hardwired jog. Check how that interacts with the command source selected in P3.00 before wiring it.

Check: after a speed change, the keypad setpoint updates within one poll interval, and the output then follows the configured ramp.

Run the End-to-End Verification

1. Power up the drive and gateway. Confirm that Read System Configuration discovers the GS3.
2. Clear the exception counter. Command run at a low speed.
3. Make five or more speed changes in both directions. Time the delay from the PLC write to the keypad setpoint change.
4. Jog the motor several times the way the operator will. Confirm that start and stop respond consistently.
5. Leave the drive running under normal load for a sustained period. Confirm the GSW and GSR Exception Response Strings stay empty and the counter stays at zero.
6. Bring the second drive online and repeat steps 2-5 with both drives polling.

Pass criteria: no SLAVE FAIL exceptions, the setpoint updates within one poll interval, and the output follows the configured ramp. Get it running this way first, then clean up the cable routing and labeling.

FAQ

Stop and contact AutomationDirect technical support if the errors continue with the gateway bench-tested next to the drive on a short jumper and the P9 settings matching the gateway configuration. At that point the problem is in the gateway, the drive's communication port, or firmware, not the cabling. Have the exception string history and your parameter records ready.