Reuse DirectSOFT ladder snippets without address conflicts

What you need

• The rungs you want to reuse, as one self-contained block. Every contact and coil the block depends on lives inside the block.
• DirectSOFT. The vendor documents the nickname workflow in the DirectSOFT6 Programming Software User Manual, 2nd edition, 265 pages: it lets you build an entire program with nicknames and assign none of them until the code is where you want it. Get the manual from the vendor's own documentation site.
• A copy of the target project. Keep the master untouched; the master-copy habit for panel projects applies to PLC work too.
• The built-in I/O cross reference and element usage windows, which keep track of the addresses your program uses.
• DirectSOFT Rel 5 or later, if the snippet involves communications. Check the release the same way you would check a panel's firmware revision before a project transfer.
• Programming a Koyo SZ-4 CPU? The DirectSOFT walkthrough for that CPU covers the connection and setup this article skips.

Why pasted rungs collide

A ladder program links its logic to its data through addresses alone. Two programs that use the same C bit for two different jobs cannot be merged by pasting, because the address is the only thing the logic sees.

The paste is also legal: a PLC accepts two coils on one address, and on every scan the last rung to write wins. The rung you meant to keep loses without a message. The scan behavior behind that is explained in why PLC rungs must scan every cycle.

Unassigned nicknames break that link on purpose. A snippet can carry its names and no addresses, and you choose the addresses when the snippet lands in your project. That is the whole trick.

Export the rungs with nicknames left unassigned

Do this on the source project, or ask whoever keeps it to do it.

1. Isolate the block you want to share. Trim it until it is self-contained.
2. Open the documentation menu and follow the path the vendor's FAQ prints: select Document a project, then Assign Nicknames, then Export/Import - Adding unassigned nicknames to element documentation.
3. Export the block as mnemonic text. The file is plain text you can open in any editor, and it is long: a few rungs become many lines. Leave every nickname unassigned, so the text carries names and no fixed addresses.
4. Add a header at the top: what the logic does, what inputs it expects, what outputs it drives.
5. Save it under a name that says what the code does, so the file identifies itself in a library folder.

Import the text and assign addresses

1. Open the copy of your project. The master stays closed.
2. Import or insert the generic mnemonic code.
3. Run Tools->Assign Nicknames. This resolves each unassigned nickname to your specific C, X, Y, V or other location, and you choose which.
4. Accept only addresses the cross-reference and element usage windows show as free. Press F9 to open the Element Browser and pick documented elements one at a time.
5. Stop the moment the assignment list contains a nickname you do not recognize. Find what it does before you accept an address for it.
6. Compile the merged project and clear every error and warning before the program goes near the machine.

Example: one export, four address families, four cross-reference passes

The case: a library snippet of 3 start, stop and seal-in rungs arrives as one mnemonic export with 8 unassigned nicknames, and you are folding it into a running line's program.

Inputs:

• 1 export file, plain text, 8 nicknames unassigned. That is the file the export step above produces.
• 4 address families in play: C, X, Y and V, the families the assignment step names. The 8 nicknames split 2 C, 3 X, 2 Y and 1 V.
• The cross-reference and element usage windows, which the vendor documents as keeping track of addresses used.

Rule: a nickname takes an address only where the cross-reference shows that address unused, and every output coil appears exactly once in the merged program.

Arithmetic: one pass per family, so 4 families x 1 pass each = 4 cross-reference passes, all run before you accept the first assignment. Each pass checks only that family's addresses: the C pass covers 2 nicknames, the X pass 3, the Y pass 2 and the V pass 1, so 2 + 3 + 2 + 1 = 8 nicknames bound in total. Then, on the assignment list: nicknames carried - nicknames recognized = unrecognized nicknames, here 8 - 8 = 0. The merge stops at any result above 0. Budget roughly 10 minutes for the 8 assignments at about 1 minute per nickname, more if a family's pass shows an address in use.

Result: all four passes come back clean and the subtraction lands on 0, so Tools->Assign Nicknames binds every name to an address you chose, and the cross-reference shows each output coil once.

Decision: compile, then bench-test with outputs disabled before the program downloads to the machine. If any family's pass shows the address in use, pick a different address in that family and rerun that family's pass. If the subtraction leaves 1 or more unrecognized names, stop and identify them first.

When the code arrives with fixed addresses: Search and Replace

Unassigned nicknames are one route; Search and Replace is the other, and it is the fallback when a snippet landed with its original addresses baked in.

The cost is that you find every operand yourself. Work in a copy, replace each old address with one your cross-reference shows free, then run the cross-reference again and confirm no old address remains anywhere in the project. For a 2-rung block that is quick. For anything bigger, say 20 rungs or more, the nickname route does the same job with the tool keeping the list for you.

Replace old communications samples with Rel 5 IBoxes

Many old sample programs exist to do a job the software now does for you. Rel 5 added built-in IBoxes for communications:

• NETRX and NETWX carry built-in interlocking.
• The ECOM100 ECxxxx IBoxes sequence transfers with no shift registers or counters.

The old samples needed the extra logic because the underlying network instructions run asynchronously and report busy and error conditions. The IBoxes handle that ordering and those bits, and the vendor's ECOM communications manual documents the ECOM100 IBox.

If you inherit a program that still sequences communications with shift registers, read it before you delete it. Compare it against the IBox on a bench PLC, forcing both a busy and an error condition, and remove the old rungs only once the IBox behaves the same way.

Share snippets the next person can reuse

• One self-contained block per file, header at the top.
• Plain-text mnemonic files travel better than binary project files when logic is all you need.
• Zip the file for sharing, and scan every archive you receive before you open it. A snippet that will run a machine deserves the same screening as any other download.

How to check the merge before it runs

1. Compile with no errors and no warnings.
2. Run the cross-reference on every newly assigned address. Each output coil appears once, and each address serves one purpose.
3. Compare the nickname list before and after the import. The only differences should be the new entries.
4. Bench-test on a PLC with outputs disabled, or watch the imported rungs in status view while you force inputs. Run this test before the merged program reaches the machine: a coil collision that passed compile shows up as motion, not as a message.
5. For a communications merge, force a busy and an error condition and confirm the IBox does what the old logic did.
6. Keep the pre-merge backup until the machine has run a full production cycle.

Recommendation: Share and reuse rungs as mnemonic text with unassigned nicknames whenever the block spans more than one or two addresses. Import into a copy, run Tools->Assign Nicknames, and accept only addresses the cross-reference shows free. Keep Search and Replace for small blocks that arrive with fixed addresses, and hold the pre-merge backup until the machine has run a full production cycle.

Questions