Do-more Designer: Configuring Documentation Record Ranges

Do-more Designer keeps the Documentation Editor sparse: it displays elements already documented and elements referenced by the program instead of pre-creating every possible address and cast. To prefill a sequential block, enter the first element in Add Documentation Record and press Enter repeatedly; each entry is created and the address increments automatically. A ranged Add Empty Record mode was also specified for ranges such as C0-C100, but no release version was identified, so confirm whether that option exists in the installed build.

Why the Documentation Editor uses sparse records

A fixed, fully populated address table is practical when a controller has a comparatively small and rigid memory map. It becomes unwieldy when the address space is larger and one storage element can be represented through multiple casts or fields.

For example, one D0 element can expose the following documented forms:

• Bits D0:0 through D0:31: 32 entries
• Bytes D0:B0 through D0:B3: 4 entries
• Words D0:W0 and D0:W1: 2 entries
• The base element D0: 1 entry

That produces 39 possible entries for one element before considering every other element or the fields of structures. Pre-populating every permutation would enlarge the table and make relevant records harder to find. Do-more Designer therefore builds the visible list from actual documentation records and program references.

Real records versus virtual records

The Documentation Editor presents two record states that look similar but serve different purposes. Distinguishing them prevents an engineer from mistaking an address reference for saved documentation.

Editor entry	How it appears	Database state	Required action
Documented element	The element and its entered documentation appear in the list	A documentation record exists	Edit the existing record as needed
Used but undocumented element	The element appears with an asterisk (*)	It is a virtual record generated from program usage	Add documentation if the element needs a stored description
Unused and undocumented element	It normally does not appear	No record exists and no program reference caused a virtual entry	Create a record before documenting it

The asterisk is the key diagnostic. It means the editor knows that the program uses the element, but an actual documentation record has not yet been created for it. Conversely, an address that is neither used nor documented may not be found by an editor search because there is no visible real or virtual record to locate.

Prefill a sequential range with repeated Enter

The single-record dialog supports rapid keyboard entry without reopening the dialog for every address. Use this method when the installed build does not expose a ranged command or when only a short sequence is required.

1. Open the Documentation Editor.
2. Open Add Documentation Record.
3. Enter the first element, such as D0.
4. Press Enter to add its empty documentation record.
5. Continue pressing Enter. The dialog automatically advances from D0 to D1 and then through the following sequential elements.
6. Stop at the last required element and exit the dialog.
7. Edit the resulting records in the Documentation Editor, including any planned copy-and-paste operations.

Verify the result before entering descriptions: confirm that the first and last intended addresses are present, the sequence contains the expected addresses, and no unintended element type was selected. This workflow separates record creation from description entry, making advance documentation practical even before the elements are used in ladder logic.

Use ranged Add Empty Record when available

The ranged workflow was defined as a second mode alongside the existing single-record behavior. Its purpose is to accept an element range such as C0-C100 and create empty documentation records across that range in one operation.

The required collision behavior is preservation, not replacement. If C5 is already documented as George, adding C0-C100 should create empty records for C0 through C4 and C6 through C100, while retaining the existing contents of C5. This makes the operation suitable for expanding a prepared documentation block without erasing completed work.

1. Open Add Documentation Record and check for a ranged or Add Empty Record mode.
2. Specify the required start and end elements, for example C0-C100.
3. Execute the add operation.
4. Inspect a previously documented address inside the range and confirm that its text remains unchanged.
5. Check an unused address near each boundary to confirm that new empty records were created.

No software version or release date was attached to this mode. If the installed interface offers only single-record entry, use the repeated-Enter method rather than relying on a menu item that may not exist in that build.

Diagnose search and data-view documentation failures

A failed search does not necessarily indicate an invalid PLC address. In a sparse editor, it often means that the target is unused and has no documentation record. The search has no displayed object to select.

Symptom	Likely mechanism	Corrective action	Verification
Search reports that an element cannot be found	The address is unused and has no real or virtual documentation entry	Add a documentation record for the exact element	Repeat the search and confirm that it selects the new record
An element appears with *	The program references it, but no stored documentation record exists	Create or edit its documentation record	Confirm that the description is retained and the entry is no longer merely virtual
Documenting from a data view requires remembering the address	The workflow is not positioned on a pre-created row	Record the exact element form, then add it explicitly in the Documentation Editor	Confirm that the base address, cast, or structure field matches the data-view item
Bulk preparation requires excessive dialog operations	Only single-record creation is being used	Use automatic increment with repeated Enter, or ranged addition when present	Check the complete start-to-end sequence before adding text
A range operation encounters existing documentation	Some addresses already have real records	Preserve those records and create only missing empty entries	Compare representative existing descriptions before and after the operation

Address form matters during diagnosis. D0, D0:0, D0:B0, and D0:W0 are distinct documentation targets. If a search finds the base element but not a cast, confirm that the exact cast is used, documented, or explicitly added.

Assign work variables by nickname

Bulk address documentation is not always the most efficient workflow. For working values that do not require a predetermined hard address, enter a nickname in the applicable field. Do-more Designer can assign the next free item of the selected element type and create its documentation record using that nickname.

Use explicit addresses where the physical or external mapping must remain known, such as I/O. Use automatic assignment for internal working values when program meaning is carried by the nickname and no integration requirement depends on a fixed address. This reduces address bookkeeping and creates documentation at the point of use.

1. Decide whether another system, physical connection, or maintenance convention requires a fixed address.
2. If it does, select the required address and document that exact element.
3. If it does not, enter a descriptive nickname and select the appropriate element type.
4. Allow the software to allocate the next free item and create the documentation record.
5. Verify the assigned element and search for the nickname before using it elsewhere.

Do not use automatic allocation where a hard address is part of an external interface unless the resulting assignment is captured and controlled. The decision is architectural: fixed mappings favor explicit addresses, while internal temporary values favor nicknames and automatic allocation.

Use named constants for configuration values

A named constant handles a different problem from a documented memory element. It represents a program-time value that cannot change at runtime and does not consume data memory in the same way as a stored variable. Its behavior is comparable to a C #DEFINE.

For an elevator program that supports buildings from 2 to 10 floors, define TopFloor and assign the installation value, such as 4. Use TopFloor everywhere the program needs the limit. For another installation, change the definition to 6 rather than locating and editing multiple numeric literals.

This approach prevents missed occurrences and protects the value from runtime writes. Verify the change by searching for the constant name, confirming that dependent logic references the name rather than duplicated literals, and checking the configured value before transferring the program.

Verification checklist

1. Search for an unused element before adding it and note whether the editor reports that it cannot be found.
2. Add the exact base element, cast, or structure field required by the design.
3. Repeat the search and confirm that the editor now locates the record.
4. For program-used elements, identify entries marked with * and replace virtual entries with stored documentation where needed.
5. After bulk creation, inspect the first element, last element, and several interior elements.
6. If existing descriptions fall inside the range, confirm that their text was not cleared or replaced.
7. For automatically allocated work variables, record and verify the assigned element type and address.
8. For named constants, confirm that the program references the constant name and that the configured value matches the installation.

Frequently Asked Questions