GX Developer 7 List of Used Devices: Complete Search Guide

GX Developer 7 List of Used Devices: Complete Search Guide

The List of Used Devices function in GX Developer Version 7 (SH-080166) is the direct equivalent of the Used List that Medoc users relied on for two decades. It scans an entire GX Developer project (ladder, SFC, ST, and structured text bodies) and returns every device address that the compiled program actually touches. This article is a field-ready technical reference: it documents the two menu paths, the supported device name syntax, the wildcards, the export options, the differences between the A-series and Q-series search scope, the indexed-addressing patterns that motivated the original question, and the migration path to GX Works 2 / GX Works 3.

1. Overview: Why the List of Used Devices Matters

When a Mitsubishi MELSEC program is downloaded from a controller, the offline .GP7 file is the only authoritative source of the original design intent. GX Developer Version 7 Operating Manual (Start-Up) (SH-080165) documents how GX Developer builds an internal cross-reference table while the project is compiled. The List of Used Devices is the user-facing window onto that table.

Three engineering tasks depend on the function:

1. Pre-modification audit. Before adding logic that writes to a register, the engineer must know whether another step already writes to it. Indexed addressing (D0Z0, M0Z0) hides the actual address from the human reader, so a wildcard search is the only safe way to enumerate touched devices.
2. I/O validation. The function proves which physical X and Y points are wired in software. A point that exists in the hardware list but is missing from the used list indicates a module slot change since the program was last saved.
3. Documentation refresh. A pre-migration export to CSV provides the seed list for the GX Works 2 / GX Works 3 Device List and for the customer's EOL documentation pack.

2. Prerequisites

Before invoking the function, confirm the following:

• GX Developer Version 7 (any service pack) is installed; SW7D5C-GXDEV-E or the Japanese equivalent SW7D5C-GPPW-E. The function does not exist in GPPQ (Q-series dedicated) versions older than 7.0.
• The project is open and the Main, Initial, Scan, and any SFC / ST program bodies are present in the project tree.
• The project has been compiled at least once since the last edit (use Convert → Convert/Compile or F4). An unconverted project returns a stale or empty used list.
• File registers (R, ZR, D with battery-backed extension) are mapped if the program references them. A blocked file-register range hides devices from the search.

3. Accessing the List of Used Devices

There are two equivalent menu paths. Both produce the same result set because they call the same internal scan routine described in SH-080166, Section 7 — Find/Replace.

3.1 Method A — Right-click context menu

1. Open the ladder (or SFC body) that contains the program you want to audit.
2. Right-click anywhere inside the ladder grid. The context menu opens.
3. Scroll to the bottom of the context menu and click List of used Devices.

This path is the most common because most engineers keep a hand on the mouse while reading rungs.

3.2 Method B — Find/Replace menu

1. Click the Find/Replace menu from the main menu bar.
2. Click the very last entry on the menu: List of used Devices.

This path is the documented path. The reason it is at the bottom of the menu is that the developers grouped every cross-reference tool under one heading, separating it from the Find String and Replace String routines higher up.

4. The List of Used Devices Dialog Box

Once the dialog opens, GX Developer presents the following controls:

Click Execute to populate the result grid. The grid columns are:

• Device — the absolute address.
• Program — the program body that contains the reference (e.g. MAIN, SCAN, INIT).
• Step / Instruction — the step number and the mnemonic that touches the device (e.g. 00124 LD X0).
• R/W — read or write classification; write hits are flagged with a red icon.
• Comment — first-line device comment when Include comments is checked.

5. Search Field Syntax and Wildcards

The Find Device field accepts more than a single address. The supported patterns are:

The * and ? wildcards apply to the numeric portion only — the device letter prefix is fixed. To scan both M and L in one pass, run the search twice with the appropriate letter.

6. Device Range Reference Tables

The device ranges supported by the function depend on the PLC type declared in the project header. The two common platforms are summarised below.

6.1 MELSEC-A series (AnS, AnN, AnA, AnU)

6.2 MELSEC-Q series (Q00–Q25, Universal model)

The ranges above are the default user ranges. Project memory parameters (PLC Parameter → Device tab) can shrink or expand them. The List of Used Devices always honours the project-specific range; addresses that lie outside the parameterised range are silently ignored.

7. Reading and Interpreting the Result Grid

Each row in the result grid corresponds to a single mnemonic reference. The same device may appear many times if it is read in several rungs.

To interpret the grid efficiently:

1. Sort by Device (click the column header) to group all references to a single address.
2. Filter on R/W = W to isolate write hits. Compare them with the original specification — a missing write is a common bug after a copy-paste refactor.
3. Sort by Program to verify that every declared program body in the project tree (e.g. SCAN, FAULT, INIT) has at least one device in use. A program body with zero hits is either unused or misnamed.
4. Double-click any row to Jump the ladder cursor to the referenced step. The ladder view scrolls and centres on the line.

8. Exporting and Printing the Used Device List

For documentation, the CSV Export button writes a UTF-8 (or Shift-JIS, depending on the OS locale) file. The default fields written are:

Device,Program,Step,Instruction,R/W,Comment
D200,MAIN,00042,DMOV D200 D201,W,production counter
D200,MAIN,00124,LD>= D200 K100,R,limit reached
M0,SCAN,00003,LD M0,R,start request
Y10,MAIN,00210,OUT Y10,W,motor contactor

Use the export to seed the customer's EOL register map. Typical workflow:

1. Export the full device list with * as the search pattern.
2. Open the CSV in Excel and add a Description column populated from the device comments.
3. Sort and de-duplicate on the Device column to produce a one-line-per-address register map.

For a hard-copy deliverable, use File → Print Preview while the result grid has focus. The grid is printable on A4 / Letter with a header that names the project, the search pattern, and the timestamp.

9. Indexed Addressing and the Implicit Search Use Case

The original question that motivated this guide concerned a program dense with indexed addressing. The List of Used Devices does not symbolically resolve D0Z0 to D0..D±n, but the following procedure enumerates the touched range reliably.

1. Use Find String (Ctrl+F) for the literal pattern D0Z to find every base address used with an index register.
2. For each base address, identify the index register letter (Z0 through Z19 on a Universal Q, or Z, Z1..Z6 on an AnS).
3. Find the rung that bounds the index register — typically a + or - instruction. Example: + Z0 K1 Z0 inside a FOR/NEXT loop bounds the index between 0 and n.
4. Run the used list with the wildcard D0* to retrieve every absolute address that the program reads or writes. The set is a superset of the runtime targets.
5. Manually annotate the subset that is reachable through indexing.

This procedure produces a worst-case map. For a tighter map, add a temporary BMOV K0 D9000 K1 probe on each candidate address, go online, and observe D9000 while the program runs. The addresses that actually change are the live targets.

10. Used List vs Cross-Reference Window

GX Developer 7 has a second, related tool: the Cross-Reference Window (opened from the ladder by Shift+F7 or via the View menu). The two are not interchangeable.

Use the List of Used Devices for the big picture. Use the Cross-Reference Window when you already know the address of interest and need to walk every reference to it in a single program.

11. Working with Mixed A-Series and Q-Series Projects

When a single project contains both A- and Q-series code (a common situation during staged migrations), the device ranges from the two series coexist. The List of Used Devices respects the active project header, but engineers should keep the following rules in mind:

• The search always uses the destination project header, not the source. If you copied A-series logic into a Q-series project, the device letters are unchanged (M, D, X), but the available range and the ZR continuous file-register namespace expand.
• For an A→Q migration, the file-register translation is the most error-prone step. Use the used list with the pattern R* on the A-series side and ZR* on the Q-series side. The two result sets must be reconciled manually.
• The Include SFC checkbox is required whenever the program contains SFC. An SFC body that is excluded still appears in the project tree but contributes zero hits.

12. Migrating Projects to GX Works 2 / GX Works 3

GX Developer 7 is the last release line of the older MELSEC programming environment. New deployments use GX Works 2 (SW1DNC-GXW2-E) for Q/L-series and GX Works 3 (SW1DND-GXW3-E) for iQ-R/iQ-F. The List of Used Devices survives the migration as the Device List in the newer tools.

When you convert a .GP7 project to a .gxw project, the device list migrates as plain numeric addresses. Run the same List of Used Devices in GX Works 2/3 immediately after the conversion and compare the result against the GX Developer 7 export. The two must match to the last row, otherwise a parameter did not convert cleanly.

13. Verification and Field-Proven Checks

After running the search, perform these checks before committing the modification:

1. Cross-check against the I/O assignment table. Open PLC Parameter → I/O Assignment. Every used X and Y in the result grid must map to a slot. An address that exists in the used list but not in the I/O assignment indicates that a module has been moved or replaced since the program was last saved.
2. Cross-check the live image. Go online, open Monitor → Device Memory, and dump the relevant range. Compare the live register count to the used list count. A divergence suggests an unconverted program or a parameter mismatch.
3. Watch the cross-reference update. After any edit, the result grid must be re-run. There is no automatic refresh of the previously displayed result.
4. Confirm comment retention. Toggle Include comments off, then on. A comment that disappears is missing from the project's .txt comment file and must be restored from the EOL pack.
5. Print to PDF for audit trail. Use a virtual printer to write the result grid to a dated PDF. The file is the evidence that the audit was performed.

14. Troubleshooting Matrix

15. Related Tools and Edge Cases

• Device Initial Value: the Device Initial Value window is the write-only companion of the used list. Compare it with the used list to verify that every device with a non-zero initial value is also referenced in the program; an orphaned initial value is dead data.
• Device Comment Utility: the Device Comment Utility reads comments from the project's .txt file. The Include comments checkbox in the used list reads the same file; both must be in sync.
• Global Device Comment / Local Device Comment: Q-series projects can have two comment files. The used list shows comments from both, in that order. The Jump routine follows the global comment first.
• Function Block (FB) library: used devices inside an FB are listed against the FB's local name, not against the call site. To audit the actual call sites, search the calling program body separately.
• Macro instruction: a macro (MC/MCR) is a label, not a device, and does not appear in the used list. Verify macro usage with Search → Jump → Label.

16. Quick-Reference Procedure Card

Goal: enumerate every device touched by the current project

1.  Project → Compile (F4)        # ensure the scan table is fresh
2.  Open MAIN, SCAN, INIT, ...       # all program bodies
3.  Right-click in ladder            # or: Find/Replace → bottom item
4.  Click 'List of used Devices'
5.  Type the pattern:                # e.g. M*, X*, D100..D1FF
6.  Check 'Include SFC' / 'Include ST'
7.  Check 'Include comments'         # for the documentation export
8.  Click 'Execute'
9.  Sort by Device, filter on W      # isolate write hits
10. Click 'CSV Export'               # write to the project audit folder
11. Jump to each row that requires a code change

Print the card above and pin it next to the engineering workstation. The total elapsed time for a 30 K-step project on a typical Windows 10 PC is under 12 seconds.