Productivity PACs Fit When I/O and Integration Drive the Choice

A move from DirectSoft to a Productivity P2000 or P3000 succeeds when the target is selected around the application’s I/O, communications, and programming workflow, then proven with representative logic before release.

Freeze the workload before choosing a controller

Write down the machine’s requirements before weighing software preference. Terms such as “small,” “large,” and “high speed” do not size a controller; the useful inputs are point counts, signal types, program functions, communications, and operator interfaces.

1. Count discrete and analog points separately. Record spare capacity, signal types, and the planned module arrangement.
2. List required drives, serial or Ethernet protocols, remote I/O, SCADA connections, data collection, and the number of HMIs.
3. Mark whether the application needs arrays, repeated process functions, motion control, or substantial data manipulation.
4. Record the current DirectSoft addressing conventions and the work patterns the programming team wants to retain.

For rough screening, the platform comparison treated 32 discrete I/O points as within reach of the candidates under consideration. It also used “hundreds” of discrete points and “several dozen” analog points as high counts; a separate scale called roughly 500–700 or more discrete points and 100–150 or more analog points large. Those are planning bands, not hardware limits. Confirm the exact module count, channel mix, and capacity in the current documentation for each candidate.

Check before proceeding: the requirements sheet has counts and named functions rather than labels such as “medium machine.”

Eliminate candidates that miss the I/O or workload

Do not choose a controller because its interface feels familiar before checking its I/O and workload fit. A CLICK system was considered a reasonable interface choice by one programmer, but the comparison ruled it out for a 32-point analog application expected to do more than basic work. Treat that as a screening warning: verify the exact analog modules, processing needs, and communications for the machine rather than extrapolating from the interface.

For a modest application, CLICK, Do-more, and a Productivity PAC may all remain candidates. As I/O, data handling, communications, or integration needs grow, compare those requirements against the specific CPU and modules instead of assuming that a higher family number automatically solves them.

Check before proceeding: remove any candidate that fails a required I/O, memory, or connectivity item in its current specifications.

Choose PAC or Do-more around integration needs

Use the application’s integration requirements to decide whether a Productivity PAC or Do-more is the better fit. A PAC was favored for projects requiring hot-swappable I/O, SQL/ODBC database connections, Ethernet/IP remote I/O, more communications already on the CPU without consuming a slot, or SCADA work that the team found easier to implement there. Confirm each feature against the exact PAC model and software version under consideration.

Do-more was the frequent choice for other projects, particularly where reuse of existing 205-family I/O mattered. The platform was described as using the same I/O as other 205 systems, which can reduce spare-part variety when that hardware is already stocked. Verify compatibility between the precise CPU and the modules on the shelf before treating existing inventory as usable.

Do-more and the PACs were both treated as viable for many applications, with different strengths. One programmer described Do-more as more granular for some process-control functions, which can help make logic reusable; the PAC approach was described as more monolithic for those functions. Build a small representative function in each candidate if reuse, maintenance, or process-control structure will affect the long-term cost.

Check before proceeding: document why the selected platform meets each required integration function and identify the CPU, modules, and software revision that provide it.

Map DirectSoft habits into the target programming model

DirectSoft experience transfers as PLC knowledge, but the memory and editing model may change. DirectSoft users who organize around V registers should decide how the target will name and group data. Productivity software was valued for named memory locations and readable tag names; Do-more was described as offering both table-oriented and tag or heap-based addressing. Both Do-more and PACs were reported to handle arrays.

Do not preserve every legacy rung or register convention just because it is familiar. Experienced DirectLogic programmers were observed to write more logic than a task required. When porting behavior, first define what the machine must do, then compare the shortest maintainable implementation in the new environment. For repeated functions, check whether a reusable block or array-based design fits the platform’s actual tools.

Programming style also matters during a night-shift fault. Some engineers prefer keyboard-driven ladder entry and troubleshooting; others favor a mouse-oriented workflow. Interface preference is personal, so evaluate it with the actions the team performs most: finding a tag, editing a rung, tracing a condition, and making a controlled online change.

Check before proceeding: a second programmer can find key data and explain the intended logic without relying on undocumented legacy register conventions.

Prototype the logic that carries the application

Opening the software and browsing menus is a useful first pass, but a blank project will not expose the work that makes one platform easier for this machine. Test the routines identified in the requirements, especially analog I/O, communications, and VFD interaction. Add arrays or repeated functions if the application needs them.

1. Create a small project in each viable environment using the intended data names, addressing style, and program organization.
2. Implement one representative analog operation, one communications exchange, and one drive-related routine when those functions are required.
3. Build a representative repeated function or array operation if the machine uses that pattern.
4. Have the maintenance programmer trace and edit the logic using the team’s normal keyboard and mouse workflow.
5. Compare the resulting logic, maintainability, and effort against the application requirements.

Where logic depends on physical I/O or a communications device, verify it with the intended hardware and endpoint. A software-only exercise can demonstrate the editing workflow, but it does not prove the installed module arrangement or communications path.

Check before proceeding: the prototype demonstrates the application’s important functions, not just basic ladder entry.

Size memory and scan behavior on the exact CPU

Use program and data estimates to narrow candidates, then verify limits for the exact model. Historical selection figures listed a 6.4K-word program capacity for CLICK, 192K for Do-more, 50 MB of user memory for P2000, and 50 MB for the P3000 550 CPU or 25 MB for the 530 CPU. These figures are screening references; confirm current capacity definitions, CPU variants, and software limits before design approval.

Do-more project memory was reported as a constraint on a particularly large application. That project was made to fit by moving some work and data to two other H2-DM1E controllers. This is a useful design warning: total memory figures alone do not show how much remains available after system data blocks, user data, and program logic are allocated. Inspect the project’s memory-use view and identify the blocks consuming capacity before splitting logic across controllers.

Scan speed and performance also need a real workload test. Labels such as “fast” are not acceptance criteria. Measure the target application’s scan behavior with its communications and data processing active, then compare it with the machine’s actual response requirements. Read the controller’s diagnostics and project tools for the measured values; do not borrow a timing target from another application.

Check before proceeding: the application fits in the selected CPU with room for expected data and program growth, and its measured execution meets the machine’s response needs.

Prove every communications and data path

Separate the communications checklist from the programming-language decision. A PAC’s integrated communications or remote-I/O support can be a deciding advantage, but only when the selected hardware and project software support the specific network role required. Verify each path independently: controller to drive, controller to remote I/O, controller to database, and controller to SCADA or HMI.

A period comparison identified the H2-DM1E CPU with Ethernet and described access to Dataworx P3K from a P3000 PAC. Treat these as leads for a current compatibility check, not substitutes for the present CPU, software, and licensing documentation. Test the actual connection and data flow before designing the application around it.

1. List the endpoint, protocol, data direction, and required update behavior for every connection.
2. Confirm the exact CPU and software support the endpoint and the required number of connections.
3. Build the connection in the candidate project and verify useful data reaches the intended destination.
4. Test reconnection and diagnostics using the tools available in the selected software.

Check before proceeding: each required endpoint exchanges the intended data through the proposed hardware and project, with a diagnostic path the maintenance team can use.

Commission the project and verify the release path

Keep the reversible evaluation separate from the permanent application release. A successful transfer proves that the programming computer can deliver a project; it does not prove that the logic, I/O, or communications work on the machine. USB program delivery was cited as a practical PAC advantage, so test the actual transfer method with the selected CPU and computer during commissioning.

1. Record the exact CPU, I/O modules, software version, project revision, and configured communications used for the test.
2. Transfer the project using the intended field method and verify that the controller accepts the intended revision.
3. Exercise the machine’s representative inputs, outputs, analog behavior, drive commands, and communications against the requirements sheet.
4. Review diagnostics and measured scan behavior while the required functions are active.
5. Save the verified project and the recovery procedure where the maintenance team can access them.

For a permanent release, close each requirement with a test result and keep the tested project revision tied to the hardware configuration. If the platform is still being evaluated, limit the work to a reversible prototype until the I/O, memory, communications, and maintenance workflow are proven.

Check before proceeding: the exact release project has passed the full end-to-end test and the team can identify the project and hardware configuration to restore.

Answer common DirectSoft and Productivity PAC questions