Configuring Yaskawa DX-100 PROFINET Group Running Status Bit

Overview

Yaskawa Motoman DX-100 and DX-200 controllers can be ordered with an integrated PROFINET slave option that exposes a fixed cyclic I/O image to the cell PLC. The DX-200 firmware publishes a status byte called Control group running in that image, where bit 0 reflects R1, bit 1 reflects R2, bit 2 reflects R3, and so on. The DX-100 firmware does not pre-populate that byte, which means a cell that was originally integrated against a DX-200 and is later migrated to a DX-100 loses the per-task motion-status bit the PLC was reading. This article documents the field-proven workaround: use the DX-100 Concurrent I/O subsystem together with a GRP block and a system job to republish the R1 group-running bit into a free PROFINET output bit, with no PLC program change required.

The technique is fully software-defined, survives power cycles, and is self-healing if an operator edits the PROFINET mapping from the pendant. It is intended for status signaling only and must not be used for any safety-relevant interlock.

Background: DX-100 vs DX-200 PROFINET Image

Both controllers map a fixed set of bytes to the PROFINET cyclic data. The slot layout is defined by the Yaskawa PROFINET GSD file. On the DX-200 the GSD publishes a slot that contains the Control group running byte populated by the firmware. On the DX-100 the equivalent slot is reserved but left to the integrator; the firmware writes the per-group running bits to an internal system status word, but it does not copy them into the PROFINET image automatically.

The reserved byte is reachable through the controller's I/O monitor and can be written to from a user program. That single fact is what makes the workaround possible: the integrator is expected to populate the reserved area through Concurrent I/O and a binding construct (the GRP block).

Architecture of the Workaround

The end-to-end data flow is:

1. The DX-100 firmware maintains a system status word that already carries the per-group running information. In the reference implementation this is read from system address #50440.
2. Concurrent I/O copies that system status into an internal memory location (#76670) on every controller scan.
3. A GRP block (PROFINET group binding) attaches that internal location to a free PROFINET output bit in the reserved area, identified by PROFINET group parameter #30730. Because the group is byte-wide by default, the integrator must ungroup the byte to expose individual bits.
4. A system job executes the GRP instruction in a continuous loop so the binding survives job changes, pendant edits, and power cycles.

The result is a single PROFINET output bit that mirrors the DX-100 R1 running status, byte-and-bit-compatible with the DX-200 cell the PLC was originally written for.

Prerequisites and System Variable Reference

• Yaskawa Motoman DX-100 controller with the PROFINET slave option installed and commissioned. Confirm the controller part number on the nameplate.
• The Yaskawa PROFINET GSD loaded into the PLC engineering tool and a cyclic PROFINET connection established end-to-end.
• Programming pendant access at Maintenance or higher security level.
• Familiarity with the DX-100 Concurrent I/O and system job features. Refer to the official Yaskawa Motoman DX-100 Operator's Manual and the DX-100 PROFINET Option Manual for the firmware revision installed on the controller.
• A PROFINET analyzer (TIA Portal trace, Wireshark with PROFINET dissector, or commercial PROFINET diagnostic) for verification.

Concurrent I/O Allocation Procedure

Concurrent I/O on the DX-100 runs in parallel with the main job with a typical update period in the single-digit millisecond range. It is the only path on the DX-100 that lets a system status word reach a PROFINET slot without writing job code. The allocation window is opened from the programming pendant under In/Out > Concurrent I/O.

1. Navigate to In/Out > Concurrent I/O > Allocate.
2. Add a new entry with the following parameters:
   • Source: #50440 (group running status word)
   • Destination: #76670 (internal memory area)
   • Width: 1 byte (B)
   • Direction: System → Internal
3. Enable the allocation and save the configuration to flash.

After this step, on every scan the bit pattern of #50440 is copied verbatim to #76670. Bit 0 of #76670 now mirrors the R1 running state. Bits 1 to 7 mirror R2 through R8 (and S1 through B1 if those groups are configured on the controller).

GRP Block Configuration

Yaskawa's PROFINET reserved area is exposed as 8-bit groups. Each GRP block binds one internal byte to one PROFINET slot. To expose a single bit you must first ungroup (split) the byte so the controller treats it as eight individual bit-level signals instead of one byte-level signal.

1. Open In/Out > PROFINET > GRP Block (the path varies by firmware; in older revisions look under System > I/O > PROFINET Mapping).
2. Select the reserved output byte identified by parameter #30730.
3. Set the GRP block source address to #76670.
4. Choose Ungroup to expose the eight individual bits rather than the byte as a single PROFINET word.
5. Bind bit 0 of #76670 to the first free PROFINET output bit in the cell's reserved area. This is the bit the PLC will read as the R1 running status.
6. Save the configuration and cycle PROFINET communication from the pendant (In/Out > PROFINET > Restart) so the new binding is published.

After this step, the PROFINET image contains the R1 running bit at the same offset the PLC was previously reading from the DX-200. The PLC application does not need to know that the bit is now synthesized by Concurrent I/O rather than published by the firmware.

System Job Implementation

The GRP binding is volatile: it is re-applied only when the controller boots or when the system job runs. Implement a small system job that executes the GRP setup unconditionally and then loops forever. A minimal job body, adaptable to the controller's exact job syntax, is shown below.

// Job: PROFINET_GROUP_RUNNING_SETUP
// Purpose: bind #76670 to PROFINET output group #30730
//          and re-establish binding on every controller scan.
DO
    GRP #30730, #76670
    // Optional: monitor the binding status and raise an alarm
    // if the PROFINET link is down.
LOOP

Notes on the body:

• The GRP instruction writes the same binding that the pendant's GRP block UI writes. Running it from a system job is functionally equivalent to clicking Apply in the UI on every scan.
• The DO/LOOP pair makes the binding self-healing: if an operator edits the PROFINET mapping from the pendant, the next scan of the system job restores the application binding.
• If you prefer a one-shot behavior (set once at boot, never re-applied), replace DO/LOOP with a flat sequence. The trade-off is that any manual change to the PROFINET mapping will persist until the next power cycle.

Loop Semantics: One-Shot vs Continuous

Two valid execution models exist for the system job. Choose based on the operator workflow on the cell.

PLC-Side PROFINET Integration

On the PLC side (Siemens S7-1500/S7-1200, Allen-Bradley CompactLogix/ControlLogix with a PROFINET scanner or EtherNet/IP-to-PROFINET gateway, Beckhoff CX, etc.) the integration is identical to the DX-200 cell:

1. Load the Yaskawa PROFINET GSD into the PLC engineering tool.
2. Map the slot that contains the reserved output byte to a tag or DB. In TIA Portal this is a Word or Byte tag inside the I/O data of the Yaskawa device; in Studio 5000 it is a tag inside the input assembly of the PROFINET device.
3. Alias the R1 running bit to the application tag. For Siemens this is typically "Yaskawa_Inputs".R1_Running : BOOL with an AT view on byte 0 bit 0; for Allen-Bradley it is a BOOL member of the input tag with the bit number set in the tag properties.
4. Use the tag in the same way the original DX-200 cell used it. No PLC program change is required.

For cross-vendor PROFINET conformance, refer to the PROFINET installation guidance from PROFIBUS & PROFINET International (PI). The binding is plain PROFINET and does not require any vendor-specific function block on the PLC side.

Verification and Commissioning

1. From the pendant, navigate to In/Out > Concurrent I/O > Monitor and confirm that #76670 tracks #50440 bit-for-bit. Force a group start from the pendant and watch the bits toggle.
2. Open In/Out > PROFINET > Status and verify that the reserved byte at #30730 shows the running pattern.
3. On the PLC side, place a watch on the R1 running tag and jog the robot. The bit must assert on the rising edge of motion and clear on the falling edge, with a latency in the single-digit millisecond range.
4. Capture a PROFINET frame trace and confirm that the bit toggles in the cyclic image. Verify the slot direction in your GSD before relying on the trace — the bit is an input from robot to PLC in the standard DX-200 layout.
5. Power-cycle the DX-100 and confirm that the binding is re-established automatically by the system job, without operator intervention.
6. Edit the PROFINET mapping manually from the pendant and confirm that the continuous-loop system job restores the application binding within one scan.

Troubleshooting Matrix

Limitations and Field-Proven Caveats

• This workaround is firmware-version sensitive. Yaskawa has changed the PROFINET reserved area address between major DX-100 firmware revisions. Always confirm #30730 against the I/O map printed by the controller for the firmware you have installed.
• The Concurrent I/O update period is not deterministic in the strict sense. For safety-rated signals (e.g., safe motion stopped) use the DX-100 safety PROFINET module or hardwired safety circuits — never the Concurrent I/O group running bit.
• Do not use the R1 running bit as the only criterion for safety interlocking. The bit reflects command state, not actual mechanical state. For safety, read the encoder-based position or use the controller's safety outputs.
• If the cell uses more than one group (R1, R2, S1, B1, etc.), the same technique can be repeated for the other bits in #76670 by ungrouping the byte and binding each bit to a separate PROFINET output.
• The DO/LOOP system job survives manual pendant edits only if the system job priority is set correctly. Refer to the DX-100 Operator's Manual section on system job priority for the correct value on your firmware.
• Concurrent I/O is consumed at boot time and is not affected by mode changes. It is, however, cleared by a controller cold start, so the system job must run early in the boot sequence — typically it is selected as the default job.