Do-more vs Productivity PLC: Stage, Memory, I/O Trade-offs

A Do-more shop that is weighing Productivity usually has a specific reason: a retrofit with a cramped cabinet, a data-heavy application, or a customer standard. The usual reasons for switching fail more often than they work. Get the machine running on the platform you already know, then move to the other platform where it clearly fits the job.

Don't Swap CPU Families to Fix a Cramped Cabinet

A common starting point is an old Siemens S5 machine being retrofitted. The layout is nearly identical, but the cabinet has no spare room for ZIPLink terminal cards and the fine wiring they need. Moving to a Productivity3000 because its footprint matches the old rack looks reasonable. It solves the wrong problem.

Why it fails:

• The pain point is the I/O termination, not the CPU. Changing CPU families to change terminal style adds a new programming environment, a new instruction set and new sequencing methods to a job that has no schedule slack.
• Do-more already has an I/O form factor with front-wired field terminals. Terminator I/O puts the terminals on the module, which removes the ZIPLink layer completely.
• Productivity has smaller families (P1K, P2K) than the P3K. If you do change families for footprint, compare those first. If the logic is simple, a CLICK may handle it.

What works: keep Do-more and change the I/O system. In a like-for-like price comparison of an H2 205-based system against Terminator I/O, the Terminator build came in about $250 more, and the wiring layout was preferred. Get a current quote, because pricing changes.

Check the Terminator communication limit first

Terminator has no communication option modules. The only ports are the ones built into the CPU. Before you commit, list every connection the retrofit needs: HMI, drives, serial devices to replace old S5 CP functions, remote I/O, and a programming port. If that list is longer than what the CPU provides, the 205 rack with communication modules is still the correct choice, even with the extra ZIPLinks.

Don't Paste Stage Logic into a Productivity Project

Stage programming is a Do-more strength. Productivity does not have it. Engineers who build custom serial protocols in Stage feel this most. A protocol that is a short Stage chart in Do-more took much more programming time in Productivity. There is no translation path. You have to rebuild the sequence using a different construct.

Why the quick port fails:

• Stage gives you implicit exclusivity: one stage active per chart, and transitions that automatically turn off the current stage. In plain ladder, you have to build that exclusivity yourself, or steps will overlap.
• Protocol handlers depend on send / wait-for-reply / timeout / retry states. Without an explicit state variable, retry and timeout paths become interlocked bit logic that is hard to debug on a live machine.

What works: build an explicit state machine, either a step integer or one bit per step. Both are covered below. Productivity also has a sequencer function (SEQ/DRUM) and tasks that run only when called. Those are good tools if the code will stay on Productivity.

Don't Nest Subroutine Calls or Assume Ladder-Driven Email and Logging in Productivity

Do-more users are used to certain capabilities that did not carry over to Productivity when these field notes were gathered:

• A subroutine could not call another subroutine.
• There was no email from ladder logic like Do-more has.
• Data logging could not be controlled from the ladder code.

The vendor was working on these at the time. Check the current Productivity Suite release notes before you design around either gap. Until you have confirmed them, plan this way:

1. Flatten the call tree. Call each subroutine from the main task, and pass state through tags instead of chaining calls.
2. Use tasks that run only when called for code that executes on demand.
3. If the application depends on event-driven email or logging that the program starts and stops, prototype that function on the bench before you commit to the platform.

Don't Load a Memory-Bound Data Application onto Do-more

Do-more has enough processing power for heavy applications. The limit is data memory. Two kinds of application reach that limit:

• Analog supervision with proof records. Hundreds of analog values are each checked for positive or negative rate of change against a setpoint, and a fail is declared from those measurements. On top of that, bulk data is kept to prove the machine did what it was supposed to do.
• Scalable recipe/batch systems. An engineer writes recipes (material, temperature, time, operator action), and a technician selects one. The PLC also acts as a semiautomatic batch sheet for process control and documentation. This combination was specified on C-more HMI with a Productivity CPU because it needed more memory than a Do-more could provide.

Why it fails: the logic fits, but the data tables do not. The project runs out of allocatable data space after the logic is written. That is the worst possible time to find out.

What works: before choosing the platform, estimate the data footprint. Count the monitored channels, the history samples kept per channel, the number of recipes, and the fields per recipe. Compare the total against the data memory figures in the CPU datasheet and the project's memory allocation. If the estimate is close to the limit, choose the platform with more memory.

Arrays favor Productivity

Productivity handles 2D arrays well, and its data-handling and array instructions are very strong. If the application is mostly table work (recipe matrices, per-station result grids, per-part histories), that is a legitimate reason to choose Productivity, even for an experienced Do-more programmer.

Don't Strip Platform Features by Reflex

There are two opposite mistakes here:

• Writing everything to the lowest common denominator. If you never use Stage, SEQ/DRUM or platform-specific data instructions, the PLC is just I/O plus a basic program. At that point the brand hardly matters, and you give up the features that made you choose the platform.
• Using every proprietary feature on code that must move. OEMs whose customers require Allen-Bradley have to write new logic so it can be copied into RSLogix easily. For them, Stage or SEQ/DRUM means a rewrite later.

Decide this per project, not by habit:

Situation	Portability need	Coding approach
Fixed-design product, you choose all internals	Low	Use platform features fully (Stage, SEQ/DRUM, array instructions)
One-off integration specified by function	Low to medium	Choose the PLC that fits the job; use its features
Customer specifies brand, or logic must be ported	High	Plain-ladder state machines; avoid proprietary sequencers
Same process scaled across families (for example P3K to CLICK)	High	Plain-ladder state machines that port with minimal edits
Simple relay-replacement job	None	Any capable PLC; a BRX is a good default if nothing is on the shelf

Plain-ladder state machines really do port. A 100-piece capacitor charge/test/discharge process on a P3K was scaled down to a 5-piece process on a CLICK. The power-supply communication sequence and the test sequence stayed nearly identical. Some data handling was lost, and that was accepted from the start.

Pick the Platform on the Constraint That Binds

The platform choice goes wrong when it is made on preference, footprint or price, and then a hard constraint shows up later. Find the constraint that actually limits the project and let that decide.

Binding constraint	Leans toward	Why
Complex sequencing or custom serial protocols	Do-more	Stage programming; faster development of protocol state machines
Email or data logging controlled from ladder	Do-more	Native in Do-more; confirm current Productivity support before relying on it
Nested subroutine structure	Do-more	Productivity did not allow calling a subroutine from inside a subroutine
Large data tables, bulk history, recipe storage	Productivity	More data memory; Do-more runs out of memory before processing power
Heavy 2D array manipulation	Productivity	Strong array and data-handling instructions
Front-wired I/O without ZIPLinks, Do-more program	Do-more on Terminator I/O	Field terminals on the module; only CPU-integrated comm ports
Tight schedule, team already on one platform	The one you know	A new environment on a time-critical retrofit adds risk and gives nothing back
Software maturity is the priority	Do-more	Bugs and glitches in Do-more Designer are rare; long-standing Productivity Suite issues persisted across revisions

For the cramped S5 retrofit, the result is: stay on Do-more, use Terminator I/O if the CPU's ports cover all the communication needs, and try Productivity first on a side project with no deadline. Productivity Suite is not hard to learn and many people like it once they are used to it. The first time you use it should not be on a machine that production is waiting for.

Build a Step-Integer Sequencer Where Stage Is Not Available

This is the simplest replacement for Stage. It comes from multi-axis servo work and it ports to almost any PLC. One integer tag holds the current step. Each step's rungs are gated by an equal-compare against that integer. Since the integer holds only one value at a time, only one step's logic can be true.

1. Create one integer tag per sequence (the example uses SeqStep, an example name).
2. Reserve 0 for idle. Start numbering steps at 10 and go up in steps of 10, so you can insert steps later without renumbering.
3. Gate every rung for a step with an equal-compare on the step integer.
4. At the milestone of each step, write the next step number with a move. Do not use increment if you ever need to branch or skip.
5. Put a fault or abort path on every waiting step that moves the integer to a known fault step.
6. Show the integer on the HMI. It is the step number, with no conversion needed.

// Step-integer sequencer (example tag names)
// Idle -> start
[SeqStep == 0]  [Start]                  MOVE 10 -> SeqStep

// Step 10: open valve, wait for confirmation
[SeqStep == 10]                          ( ValveCmd )
[SeqStep == 10] [ValveOpen]              MOVE 20 -> SeqStep
[SeqStep == 10] [StepTmr.Done]           MOVE 900 -> SeqStep   // timeout -> fault

// Step 20: dwell
[SeqStep == 20]                          TMR DwellTmr
[SeqStep == 20] [DwellTmr.Done]          MOVE 30 -> SeqStep

// Step 900: fault, wait for reset
[SeqStep == 900] [FaultReset]            MOVE 0 -> SeqStep

Pitfall: in tag-based editors such as Productivity Suite, rungs with numeric compares become wide because the tag names are long. If rung width makes the code hard to read on a laptop at the machine, use the bit-per-step form below.

Pitfall: when the rungs are in ascending step order, one scan can pass through several steps if the next step's exit condition is already true. Rung 10 moves to 20, and rung 20 is solved in the same scan. If every step needs at least one full scan (for example, so an output can pulse), arrange the transition rungs in descending order or set a one-scan hold flag.

Build a Bit-per-Step State Machine for Readability and HMI Display

This uses one bit for each state. The rungs are narrow and maintenance technicians generally follow them well enough to troubleshoot. It ports to CLICK, Productivity and Do-more with very few changes. The layout has two sections, and they must stay separate.

1. State machine section: only transitions go here. Each transition rung sets the next state bit and resets the current one. No outputs are driven here.
2. Initialization with re-entry guard. On the trigger, a normally-closed Seq_Init contact sets Seq_Init, clears all state bits, and sets Seq_Step_01. The guard keeps the sequence from restarting while it is running.
3. Transitions. Each state ANDs its own bit with the condition needed to advance.
4. Action section. Outputs are driven from state bits, with one coil per output, so there are no duplicate coils.
5. Spare states. Add about 10 empty states for startup logic that someone asks for later, or a step you missed.

// STATE MACHINE SECTION - no other logic here
// Init: re-entry inhibited by Seq_Init
[Seq_Trig] [/Seq_Init]         (S) Seq_Init
                               clear all Seq_Step bits
                               (S) Seq_Step_01

// Step 01 -> 02: FloodValve ON required to advance
[Seq_Step_01] [FloodValve]     (S) Seq_Step_02
                               (R) Seq_Step_01

// Step 02 -> 03: timer T1 done
[Seq_Step_02] [T1]             (S) Seq_Step_03
                               (R) Seq_Step_02

// Step 03 -> 04: FloodValve OFF
[Seq_Step_03] [/FloodValve]    (S) Seq_Step_04
                               (R) Seq_Step_03

// ACTION SECTION
[Start]  (edge)                reset counter CT to 0
[step_10]                      ( output )

Getting a numeric step for the HMI

If the state bits are in an array and the PLC can index into bit arrays, loop through them to find the active bit and write its index to an integer for the HMI. CLICK cannot loop through bits. On CLICK, either run the step-integer method in parallel, or add one move rung per state that writes the step number when that state's bit is on.

When to use SEQ/DRUM instead

Productivity's SEQ/DRUM instructions are useful and quicker to set up than either hand-built method. They do not port to other platforms. Use them when the code will stay on Productivity. Use the hand-built methods when the same process must also run on CLICK or on a customer-specified brand.

Verify the Sequencer and the Platform Before Commissioning

Sequencer checks (bench or dry-run):

1. Drive each transition condition by hand and confirm that exactly one state bit is on, or that the step integer holds one expected value, after every change.
2. Toggle the trigger while the sequence is running. Seq_Init must block re-entry.
3. Drive every timeout and fault path. The sequence has to go to the fault state, not stay stuck in a wait step.
4. Cycle power in the middle of a sequence and check where it resumes. Decide whether the step tags should be retentive, then set their retention to match.
5. Make the exit conditions of two consecutive steps true together and check whether the scan passes through both. Change the rung order if that is not allowed.
6. Watch every output in the action section. Each one should turn on only in its intended states.

Platform checks:

1. Load the full data structures (all channels, all history, full recipe count), not a reduced test set. Confirm that the project's memory use still has margin.
2. On Terminator, connect every planned communication link at once and confirm they all work from the CPU's built-in ports.
3. On Productivity, confirm that any required logging or email is driven by the program in the software version you actually have installed, not the version described in older notes.
4. Record the software version used to build and download the project. If a problem shows up later, the version number is the first thing needed.

Handle Software Defects Methodically

Some Productivity Suite problems have lasted across many releases, and new ones still turn up. When a function behaves differently from its documentation:

1. Reduce the problem to the smallest project that still shows it.
2. Write down the exact steps to reproduce it.
3. Test on the older and newer software versions you have available, to find which versions are affected.
4. Work around it in logic to get production running, and comment the workaround with the version it was found in.
5. Send the minimal project and the reproduction steps to official support.

Stop here if the defect affects safety interlocks, retained data or motion. Do not ship a workaround for any of those without the manufacturer's confirmation.

FAQ

Stop and contact AutomationDirect technical support if a memory estimate, communication port count, or feature (subroutine nesting, ladder-driven logging, email) decides the platform and the current documentation is unclear. Also call them before shipping any workaround for a reproducible software defect, and send the minimal project and the list of affected software versions with your request.