Check P2K Capacity Before a Full P3K System Migration

Brian Holt9 min read
Application NoteAutomationDirectPLC Hardware
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

A P2K-based duplicate can meet the stated duty only after each station's analog scan, 120-second history, and its master's 16-station data path pass a measured capacity test. Keep the proven P3K design as the baseline and qualify the replacement against the same physical envelope, I/O workload, operator interfaces, and recovery requirements.

Freeze the station workload before choosing the rack

Write one station's acceptance requirements before selecting a CPU, rack, or module mix. The stated load is two 0-10 V analog inputs at each of 100 positions, or 200 analog values per station, plus 100 or more digital outputs. Each station must sample those analog inputs twice per second, calculate part status, and retain about 240 contiguous snapshots.

Multiply the station requirement across the system before comparing hardware. Each system has one master and 16 stations; there are two systems. The master may also handle a barcode reader, retrieve data from a PC-based database, and communicate with the stations. Database writes and motion are possibilities in the requirement, not settled scope. Mark each as required, deferred, or excluded for the first acceptance run.

Keep the physical limits visible in the design record: the duplicate must fit the original footprint and volume envelope. The specified operator panels are C-More 15-inch units at the masters and 12-inch units at the stations. Check panel cutouts, door clearance, rack dimensions, wiring space, heat dissipation, and access for module removal against the actual selected hardware drawings.

Check: every station and master function has an owner, a count, and a pass condition, and the proposed hardware drawings fit the available enclosure volume.

Calculate the buffer and network load

At two complete snapshots per second, each station produces 400 analog sample values per second: 200 channels multiplied by 2 samples per second. A 240-snapshot history holds 48,000 values per station. These are value counts, not memory bytes; the actual memory requirement also depends on the stored data type, timestamps, status bits, indexing, and whether calculations or metadata are retained with each snapshot.

For 16 stations, one master system handles a nominal 6,400 analog values per second. Across both 16-station systems, the nominal total is 12,800 values per second. Those rates assume all stations sample all 200 channels at 2 Hz. Include digital status, barcode events, protocol overhead, diagnostic traffic, and any database transfer in the actual communications test. Do not size a link from analog payload alone.

Define what a contiguous snapshot means. If a station misses a capture or loses communications, decide whether it records a gap, marks the snapshot invalid, or retries data later. A 240-entry circular buffer can preserve the most recent 240 records, but missing or delayed records change the time span represented. Keep a sequence number or timestamp with records if the receiving system needs to detect gaps and order data.

Check: demonstrate the 200-channel, 2 Hz acquisition and a full 240-snapshot buffer while recording scan overruns, lost samples, and communication delays. Compare measured headroom with the application's approved limits.

Prove the station I/O and rack fit

Build a channel-by-channel I/O schedule for one station. Match every sensor signal to an input type, range, common/reference arrangement, isolation requirement, and termination method from the selected module documentation. The stated 0-10 V signal range does not identify sensor accuracy, wiring length, grounding, or noise tolerance; those determine whether the measured values can support part-status calculations.

Confirm the selected rack, power supply, CPU, and modules against manufacturer documentation. Verify available slots, module power consumption, supported combinations, terminal wiring, environmental ratings, and required accessories. Check every proposed P2K device against the exact SKU and CPU configuration. A note that “P2-xxND3” has issues gives no failure condition to test; record the exact device, symptom, operating conditions, and diagnostic indication before deciding whether that device is acceptable.

Do not use module feel as a compatibility test. A concern about loose or sloppy module seating needs an inspection of the actual rack and module retention, followed by a check for stable electrical contact and any documented installation requirements. The source provides no dimensional or retention specification for comparison, so use the selected rack and module drawings and an installed inspection.

Grounding deserves an explicit test because a separate P2K installation reported a grounding issue across heated zones and used one P2-08THM per zone as a simplification. That report does not specify the grounding fault or establish that the same layout fits this analog-input application. Inspect the sensor and cabinet grounding scheme, isolate noise sources where the module design requires it, and compare representative readings with an independent meter at known process conditions. Apply the project's accuracy and noise limits; do not invent a tolerance.

A separate installation reported 14 heated zones with dedicated P2-08THM modules, a P2-RS on a 7-slot rack, a P2-04AD for a 0-10 V pump-speed signal, and a P2-16TD1P sink-output module driving solid-state relays. It reported no vibration, a cabinet above 100 degrees F, and more than eight months of service. Treat those details as a field example only: they do not verify the ratings or fit of the proposed station rack.

Check: inspect an assembled station rack, verify each I/O point against the schedule, and exercise all analog channels under realistic wiring and grounding conditions before duplicating the panel.

Separate sampling from history and calculations

Make the acquisition task produce a consistent set of 200 channel values before calculating part status or publishing the snapshot. Keep the calculation from reading a mixture of old and new channel values.

Store the 240 snapshots in a bounded history structure with a clear oldest-to-newest order. Test wraparound: after the buffer fills, verify that a new snapshot replaces the oldest record and that the retained sequence remains contiguous. If the station sends data to a master, decide whether the station retains records until the master acknowledges them or whether the master owns the durable copy. That choice determines how a temporary communications outage affects data loss.

Exercise boundary values and invalid-input behavior for the part-status calculations. Compare calculated status with the expected result for representative parts, and retain enough channel and time information to diagnose an incorrect decision. Keep the calculation thresholds in an approved recipe or documented logic rather than burying unexplained constants in code.

Check: capture more than 240 snapshots, confirm ordering and wraparound, then force a missed or invalid channel and verify the resulting status and record are clearly marked.

Qualify the 16-station master path

Test the master with all 16 stations active at the required sample rate. The proposed Ethernet/IP network is a design consideration, not proof that the selected P2K CPUs, modules, or software support the required roles. Confirm the exact supported devices, connection limits, data sizes, and configuration method from the applicable product documentation before committing to the topology.

Define the station-to-master data contract: station identity, snapshot sequence or timestamp, analog values, calculated status, digital states, and quality indicators. Measure end-to-end update time and queue growth with all stations active. If the master polls stations, observe the full cycle under load. If stations publish data, check how the master detects missing or repeated records. Do not infer acceptable update timing from a test with only one station.

A prior P3K installation was reported to have remote I/O dropouts at three of five remote locations. The P2K CPU-only alternative was considered to avoid remote adapters, but had not been used in that report. A local CPU at every station changes the architecture and fault boundary; it does not by itself prove that communication will remain available. Test the chosen topology with a station disconnected and restored, and confirm which data is buffered, lost, or flagged.

Check: run all 16 stations, verify that the master receives every expected sequence, disconnect and restore one station, and confirm that the alarm, recovery, and data-gap behavior match the acceptance plan.

Defer database and motion work until the data path passes

The existing master retrieves data from a PC-based database using DataWorx P3K, while the proposed data destination and software arrangement remain undecided. Specify which device owns each record, how the PC database is queried, and what the system does during a database outage. Test retry behavior, duplicate prevention, and recovery of queued data before treating the PC connection as production-ready. The stated dissatisfaction with DataWorx/Bizware is a reason to define the required data handling clearly, not a specification for a replacement.

The master may also control one Z axis and one Y/Z axis for loading or unloading a 2-by-6-bay oven. Keep that motion work out of the first migration gate unless it is required for startup. Motion acceptance needs the actual drive, feedback, travel, load, and safety design; those details are not included in the stated scope. A working data concentrator does not prove the motion application.

Check: accept the station-to-master records first, then run a separate database outage/recovery test and a separately approved motion test if those functions are included in the final scope.

Commission a reversible cutover

Keep the original P3K configuration as the reference for the duplicate. Compare the new bill of materials against the original by function, I/O point, enclosure space, service access, and required interfaces. Mixed P2K and P3K components may reduce the redesign or BOM, but qualify every boundary: electrical levels, communications, data ownership, configuration tools, and replacement procedures. Do not assume mixed components interoperate because they fit in the same panel.

Commission one representative station before building out all 32 stations. Record the exact CPU, rack, module SKUs, firmware and software versions, wiring revisions, and tested configuration. Repeat the workload test with the intended master and panel. For a production cutover, retain a known-good rollback configuration and define the pass/fail criteria before moving the process over. If the test fails, restore the last proven configuration while the incompatibility is isolated; do not combine a hardware swap, program change, and network redesign in one troubleshooting step.

Check: sign off the station and 16-node master acceptance records, verify the HMI display and alarm path, and complete the rollback rehearsal before releasing the duplicate for production.

FAQ: Qualify a P2K migration

What happens if a station falls behind the 2 Hz sample rate?

Record a missed-scan indicator and preserve sequence or timestamp information so the 240-snapshot history shows the gap. Check the scan time and processing load before changing the sampling period.

What happens if one of the 16 stations loses communication?

Verify whether that station buffers records, whether the master marks missing sequences, and how recovery avoids silent gaps or duplicates. The reported P3K remote I/O dropouts do not prove that a P2K CPU-per-station topology will solve the problem.

What happens if a P2K module or network feature remains uncertain?

Stop the cutover and identify the exact SKU, CPU configuration, symptom, and diagnostic data. Check the official product documentation or contact AutomationDirect support before releasing the affected configuration.

Back to blog