Ladder-view Find and cross-reference do not index address-like text inside PRINT parameters, MATH* IBox expressions or EMAIL message text, so a real address can hide from both tools. Switch to the mnemonic view and search the address there, or export the listing and search the file. Filter the lines that contain PRINT and the result is a memory inventory no rung-by-rung scan can match.
Search the mnemonic view. Ladder-view Find and cross-reference do not index address-like text inside PRINT parameters, so a real address can sit in the program and still draw the message "Could not find the given item". The same gap covers MATH* IBox expression text and EMAIL IBox message text, because EMAIL is built on the PRINT instruction. Switch the project to the mnemonic view and search the address there, or export the listing to a text file and search the file. Filter the exported lines for PRINT and you have the memory list that a manual read of hundreds of rungs would take an afternoon to produce.
Why Find and cross-reference skip these addresses
Find and cross-reference are operand tools. They match what the editor treats as a memory reference: contacts, coils, comparison nodes, the operands of a box instruction. A PRINT parameter is a string. The editor stores it as characters, and the CPU sends those characters out a communications port when the rung executes. The D2-260 and D2-262 CPUs support ASCII instructions that move strings in and out of their ports, which is why PRINT-heavy programs are common on them. Characters inside the string never register as references, so both tools come back empty for an address that is plainly in the listing. A program with a 2,900-line listing and 41 PRINT commands can hide a used word address from both tools at once, and the rung-by-rung read that finds it by hand takes hours.
| Tool | What it reads | Address inside PRINT text |
|---|---|---|
| Ladder-view Find | Operands | Missed |
| Cross-reference | Operand references | Missed |
| Mnemonic view search | Every instruction line with its parameter text | Found |
Three parameter families carry address-like text this way: PRINT strings, MATH* IBox expression text, and EMAIL IBox message text. Search all three as text and the gap closes.
Symptoms and what each one points to
- Ladder-view Find returns "Could not find the given item" for an address you can read inside the PRINT string. The token sits in parameter text, and Find reads operands. Retyping the search with different spacing or casing changes nothing.
- Cross-reference returns 0 rows for the address. Same cause. It lists operand references, and the PRINT occurrence is outside its index.
- The address does appear in cross-reference elsewhere in the program. Both kinds of reference coexist. The rows you see are real; the string occurrence is still missing from them.
- The strings were written from an HMI project. The mnemonic listing shows what the CPU holds. Text assembled on the HMI side lives in the HMI project, so search that project for the same address when the string is built there.
- An EMAIL message or a MATH expression hides an address from the same searches.* Same cause, same fix: search them as text in the mnemonic listing.
Search the mnemonic view
- Open the project you are auditing and switch to the mnemonic view. The programming software shows the four project views together: ladder, usage, mnemonic and XRef.
- Search for the address in the mnemonic view. Word addresses appear there in full, inside the PRINT parameter text.
- If the in-editor search will not reach parameter text, copy or export the mnemonic listing to a text file and search the file in any text editor. A 2,900-line export searches in about 1 second.
- Record each hit with its rung context so a real reference stays distinguishable from a coincidental character run.
- For a program-wide list, filter the exported file for lines that contain PRINT and read the address tokens out of each parameter.
Searching the instruction listing is a general technique, and finding an instruction by tag in the mnemonic listing shows the same move in a different editor.
Example: tracing V2000 through a D2-260 program full of PRINT strings
Inputs:
- CPU: a D2-260, with 15.8k words of ladder memory at its published capacity.
- Program: 412 rungs, most of them PRINT commands sending strings out the port. That is the typical shape of this problem.
- Address under investigation: V2000, a word address, standing in for the one you are tracing.
- Findings so far: ladder-view Find for V2000 answers "Could not find the given item", and cross-reference has 0 rows for it.
Rule in words: Find and cross-reference index operands. The mnemonic listing prints every instruction with its full parameter text, so a plain text search over that listing reaches tokens that sit inside strings.
Arithmetic: the exported listing runs 2,900 lines. A search for "V2000" across the file returns 5 hits. Checking those 5 against cross-reference shows 2 of them are ordinary operands, a comparison and a load, that cross-reference already lists. That leaves 5 - 2 = 3 hits inside PRINT parameter text, out of the 41 lines the filter keeps when you select every line containing PRINT.
Result: 3 of the 41 PRINT commands carry V2000 in their strings, and none of those 3 appears in any indexed tool. The other 38 PRINT lines hold the rest of the program's string-borne addresses, which is the inventory.
Decision: any hit count above zero inside PRINT text marks the address as in use. V2000 is in use, so it is not free for reuse and not safe to clear, and a rename has to change all 3 string occurrences together with the 2 operand references.
Turn the filtered lines into a memory inventory
Filtering does the work that reading rungs does, at the speed of a text editor. Deduplicate the address tokens from the PRINT lines, then add two more lists: the cross-reference output for operand references, and the same text search over the MATH* expression lines and EMAIL message lines. The union of the three is the honest memory map of the program.
If that map feeds a reservation plan, reserving PLC memory for an HMI text panel map without collisions shows how to place the map so new code never lands on a used range. A CPU swap that changes the addressing is exactly when you need the full list, and mapping Click DS addresses to DL06 V-memory after a PLC swap covers that move. The PRINT strings themselves leave through the communications ports, and if the program needs another one, adding a serial COM port to a DL205 D2-260 is the companion job.
The D2-260 was retired as of 07/2021, so the units still running are the whole population. Keep the exported listing with the project documentation.
Confirm each hit before you edit
A hit tells you where the characters sit. Read the rung around it before you decide what it does: the input conditions decide when the string goes out the port, and an HMI that writes the strings can change the text between visits. Compare the token against the address you meant, since V2000 and V2001 are one word apart and both can appear in the same string.
This procedure searches and documents; it changes no logic. Make any program edit with the machine stopped or in a state where a wrong string out of the port cannot command anything.
The decision for each case
Tracing one address. Run cross-reference and the mnemonic text search together. Hits in the listing with no cross-reference row are string occurrences; hits in both are operand occurrences. All of them count as use.
Clearing memory. Clearing a V-memory range with the FILL instruction is safe once the inventory says nothing outside the range references it, in strings or in operands.
Reusing code. A snippet is safe to drop in once you know every address its strings mention, and reusing DirectSOFT ladder snippets without address conflicts walks that check.
Recommendation: any time a program uses PRINT, MATH* expressions or EMAIL messages, run the memory audit in two passes: cross-reference for operands, then a text search of the exported mnemonic listing for the address. Declare an address free only when both passes, plus the HMI project when it writes the strings, come back clean.
Questions
Why does ladder Find say "Could not find the given item" for an address I can see in the string?
Because Find reads operands. The characters inside a PRINT parameter are stored as text, and text never enters the search index, so the tool reports nothing even though the address is on the screen in front of you. The mnemonic view prints that same parameter as a searchable line, which is why the two views disagree.
How do I list every address the PRINT commands use?
Export or copy the mnemonic listing to a text file, filter the lines that contain PRINT, and read the address tokens out of each parameter. Run the same filter over MATH* expression lines and EMAIL message lines. Sorting the tokens numerically makes duplicates obvious and gives you a clean column for the project documentation.
Can I call an address free after an empty cross-reference?
No. Cross-reference covers operand references only. Call an address free after three clean results: the cross-reference, a text search of the exported mnemonic listing, and a search of the HMI project when the HMI writes the strings. An address that clears all three is a candidate for reuse; clear two of the three and the audit is unfinished.
Do EMAIL and MATH* parameters hide addresses the same way?
Yes. EMAIL is built on the PRINT instruction and its message text is skipped by Find and cross-reference exactly like PRINT text. MATH* IBox expression text is skipped too. One search of the mnemonic export reaches all three, because every instruction line prints with its full parameter text.
The CPU is retired; does that change the search?
The D2-260 was retired as of 07/2021, and the search method is unchanged on the units still running. After any write to the PLC, use the read-project function so the saved file carries all memory, and keep that copy plus the exported listing together. They become the reference set for the next audit.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.