Map Click DS addresses to DL06 V-memory after a PLC swap

Is there a formula that converts Click DS addresses to DL06 V-memory?

No: there is no conversion table, offset or prefix rule that turns a Click DS number into a safe DL06 V address. The two PLCs number their memory differently, and a DS number says nothing about purpose, width or format.

DS is the Click's 16-bit data-register memory. V is how the DL06 writes word memory. The numbers overlap by accident: DS101 and V101 have no relationship, and the same number sits in a different place with a different meaning in each PLC. A prefix swap produces addresses that look finished, which is exactly why they get released and cause trouble on the floor.

Click's own documentation shows how self-contained its numbering is. The Click help page on pointer addressing gives the example DS1 = 100, where DD[DS1] means DD100, and lists pointer addressing across the C, DS, DD, DH, DF, XD, YD, TD, CTD and TXT memory types. A scheme that indexes its own memory types has nothing to say about where a DL06 keeps its data.

So the deliverable is a map, one row per tag. The map comes from the machine's behavior, not from the old numbers. The rest of this article builds that map and proves it.

What do you need in hand before you edit the panel project?

You need four things in hand: the panel project as a file on your PC, the DL06 program with its source, the DL06 manual pages on V-memory, and a written inventory of every tag the project carries.

• The panel project as a file on your PC. If the only copy lives in the panel, read it out first; the article on reading an HMI project from the panel before editing covers the safe sequence.
• A backup of that project and of the DL06 program, saved before the first edit and left untouched. The backup-and-restore procedure for HMI projects shows what a safe copy pair looks like.
• The DL06 manual. Its contents list a System V-memory section and a table of default data locations; those pages print the reserved areas you must stay clear of.
• A written inventory of every tag in the project. Search for DS references everywhere: screens, alarms, recipes, data logging and copied screens all carry them.

A conversion built on a partial inventory is the usual way stale Click references survive the swap.

How do you prove the panel will talk to a DL06?

Select the DirectLogic driver in the panel project's PLC or device settings and prove it with one test read before you convert a single tag. A project that cannot open the driver cannot reach V-memory at all.

In the project's PLC or device configuration, choose the DirectLogic driver. Set the port, station address and baud rate to match the DL06's wiring and setup. The panel manufacturer publishes a getting-started application note for this panel family talking to DirectLogic PLCs; follow it for the connection settings. Then send one test read to any V address and watch it arrive in the DL06 programming software before you convert anything.

Two signs tell you the driver is wrong for the job. If the driver list has no DirectLogic-family entry, stop: no address edit fixes a missing driver, and the project software question goes back to the panel supplier. If V addresses throw an invalid-address error, the syntax or memory type is off; the article on fixing HMI invalid address errors when tagging PLC memory walks that diagnosis.

How do you build the DS-to-V map tag by tag?

Build the map on paper before you open the editor. For every tag, write its purpose, width, number format, access direction and the V address it will use. Treat a row with a blank column as unfinished.

Width and format decide the mapping more than any other column. A 16-bit setpoint occupies one V word. A 32-bit value occupies two consecutive words in a double register, and the DL06 documentation shows the V codes for binary, BCD and double forms. Get the format wrong and the number on the screen is garbage: a panel that shows nonsense numbers from a PLC BCD analog register is almost always this mismatch, and that article shows how to tell the formats apart.

Record access direction with the same care. A setpoint the panel writes needs a register the DL06 logic picks up where the process needs it. A status the panel only reads needs a register the logic refreshes every scan. Do not allocate anything until every row has all five columns filled.

How do you allocate V-memory without collisions in the DL06?

Reserve one contiguous block of user V words inside the DL06 program for the panel data. Keep it clear of the built-in I/O and system ranges. Make the DL06 logic the only thing that decides what those words mean.

1. Count the words the block needs: one V word per 16-bit tag, two per 32-bit tag, one word per group of up to 16 status bits.
2. Pick the start address inside free user memory. The DL06 manual's CPU chapter prints, bit by bit, the V-memory address of each of the 20 built-in input points, and the System V-memory and default-data-locations pages print the reserved system ranges. Choose a start clear of all of them.
3. Add the rungs that move panel-written values into the process logic and copy status values into the panel block every scan.
4. Document the block: start, length and the meaning of every address. The DL06 program and the panel project must agree on it from now on.

Keep the block dense and contiguous; the article on grouping HMI screen addresses into dense ranges explains why contiguous ranges also update faster under the panel's polling. The allocation discipline, including how to keep the map free of collisions, is the same one described for text panels in the article on reserving PLC memory for an HMI text panel.

What does a finished map look like in a worked example?

In this example a panel project with 12 Click tags becomes 10 DL06 V words in one block: five 16-bit setpoints take five words, two 32-bit accumulators take four words and five status lamps pack into one word, so the block runs from V2000 to V2009.

The machine is a small oven line. Count the words: five setpoints at one word each take 5 words, two accumulators at two words each take 4 words, five lamps fit in one word because a V word holds 16 bits, and 5 + 4 + 1 = 10 words.

V2000 is where this example's DL06 program happened to have room; treat it as an example input and take your own start address from your program's free area and the CPU chapter's map. The DL06 logic copies the real lamp bits into V2009 every scan and reads the setpoint words where the process needs them. For the two doubles, confirm the word order the driver expects for 32-bit values against the panel's documentation before you trust the first read.

How do you enter the new V addresses in the panel project?

Enter each mapped V address in the tag's address field. Set the tag's memory type and number format to match what the DL06 logic writes, because the panel's own help file states that the memory type must match the PLC data type.

1. Replace each tag's Click reference with its mapped V address, typed exactly as the driver's syntax wants it.
2. Set the memory type and number format to match the DL06 side. The panel help page on entering PLC addresses documents the pairing: the exact address goes in the address field, and the memory type must match the PLC data type. That page shows a Do-more PLC, and the same two fields carry DirectLogic V addresses.
3. Search the finished project for any DS reference left behind. Alarms, recipes, data logs and copied screens are where they hide. Replace them from the map, one by one; a global change of DS to V has no way to know what each address means.
4. Save the converted project as a new file and leave the rollback copies from the start of the job untouched.

If a converted tag then ignores a value the DL06 writes to it, the symptom has its own write-up in the article on fixing an imported HMI tag that ignores PLC register writes.

How do you test reads and writes with the machine safe?

Test with the machine's outputs inhibited. Watch each mapped V address in the DL06 programming software while you operate the panel. Accept a mapping only when the PLC value, the screen value and the machine logic all agree.

Keep the outputs inhibited for the whole test session: a setpoint landing in the wrong register can energize an output or start motion with nobody expecting it. That is the one rule that makes everything below safe to try.

1. Write test. Enter 250 for setpoint 3, which lives at V2002. Confirm V2002 changes to 250 in the DL06 programming software and that nothing else in the block moves.
2. Read test. Change V2004 to 30 in the PLC software and confirm the alarm-delay field on the panel reads 30 seconds.
3. Bit test. Set bit 2 of V2009 in the PLC software and confirm the third lamp lights; clear it and confirm the lamp drops out.
4. Format test. Enter 450 for setpoint 1 and confirm V2000 reads 450 and not 1104, which is what a BCD-encoded 450 looks like when a binary tag reads it. This one entry rules out a BCD, signed or decimal-point mismatch.
5. Direction test. Confirm the read-only lamps cannot be changed from the panel and that each panel write moves only its mapped address.

A screen that shows a plausible number is not proof of a correct mapping; the wrong register often holds a plausible value. The DL06 programming software watching each address is the referee, and the screen is the suspect.

When can you hand the machine back to production?

Hand the machine back when every tag in the project points at a mapped V address, every tested value matches the DL06 logic, and the old Click references are gone from screens, alarms, recipes and data logs alike.

Run the final check in this order: search the project one last time for DS references, confirm that alarms, recipes and data logs fire on the mapped addresses, power-cycle the panel and the DL06 together, and repeat one write and one read from each data class before the outputs are released. Save the converted project and the DL06 program as the machine's pair of record, and keep the rollback copies until the machine has run a full shift on the new project. Recheck the map after any later edit, because a screen copied from an old project can carry a stale Click reference back in.

Recommendation: convert in this order: back up both devices, prove the DirectLogic driver with one test read, write the full tag map on paper, allocate one V block the DL06 program owns, enter the addresses with matching memory types, and keep the outputs inhibited until every write, read, bit and format test has passed. If the driver list has no DirectLogic-family entry, resolve the panel project's driver question first, because no address substitution replaces the driver.

Questions