The pattern: a Productivity3000 (P3000) CPU runs motion controller reads and writes in under 3 ms on a quiet network. Then HMIs and a SQL logging client go onto the same Ethernet port, and motion communication times climb. Everyone shares one CPU port. The fix is to reduce what that port has to service, separate traffic that should never have met, and move eligible devices off the primary port. The legacy information below dates from 2013, so check the current AutomationDirect catalog for any Ethernet expansion modules released since then.
Inventory What Each CPU Port Actually Does
Start with what the hardware gives you:
| CPU | Ethernet ports | Role of each port |
|---|---|---|
P3-350 |
One | Programming, HMI, SCADA, Modbus/TCP, peer traffic: everything |
| Two | Primary port: same as above. Second port: Remote I/O and GS-Drives only |
The second port on the has a TCP/IP stack. It talks to GS-Drives on TCP 502, the Modbus/TCP port. In the firmware covered by this evidence, that port does not accept programming connections or general client traffic, and you cannot reassign it between Remote I/O and Modbus duty. It is not a second general-purpose NIC.
List every device that opens a connection to the CPU. Record the protocol, the direction (who is client and who is server), and the poll rate or trigger:
- Motion controller(s): read/write cycle, target time
- Each HMI: tags per screen, update rate
- SQL logger or data collector: tag count, logging interval, whether it runs on a trigger
- VFDs and other field devices on Ethernet
- SCADA, historian, and the programming PC if it stays connected
Check: every connection on the primary port is on the list, with a rate next to it. If you cannot account for a device, find it before changing anything.
Skip the Extra Switch as the Fix
The usual first response is to add a switch. A switch solves a shortage of physical jacks. It does nothing for a port that is out of capacity. All traffic still arrives at the same CPU port and the same communication processor, and that processor services every request. Adding switch ports only makes it easier to attach more clients to an already busy CPU.
A managed switch with QoS has the same limit. QoS can prioritise frames across a congested switch link, but the bottleneck here is usually the CPU working through its request queue, not the wire. A 100 Mbit link carrying a few HMIs is rarely full. The processor answering them is.
How the load builds:
- Each HMI polls on its own schedule, so request load scales with the number of panels, not with the amount of useful data.
- SQL logging tends to arrive in bursts: a large block of reads at each interval or trigger.
- The motion controller's request waits in the same queue as those bursts, so its worst-case response time follows the busiest moment on the network, not the average.
Check: run the motion link alone, then with all other clients connected. If the response time only degrades with the other clients present, you have a load problem. More switch ports will not help.
Baseline the Motion Link Before Touching Anything
You need a number to prove the fix. Measure round-trip time for the motion controller read/write in one of these ways:
- In ladder: start a timer or capture a timestamp when the communication request is issued, then stop it on the done or success status. Keep a running maximum, not just the last value.
- On the wire: mirror the CPU's switch port to a laptop running a packet capture. Measure the time from request to response for the motion controller's IP. You need a managed switch that supports port mirroring.
- From the motion controller side, if it reports communication cycle time or timeout counters.
Record three conditions:
- Motion only
- Motion plus all HMIs on their heaviest screens
- Motion plus HMIs plus a SQL logging event
Check: the motion-only figure meets target (under 3 ms in the reference installation). If it does not, the problem is not contention. Stop here and look at the motion controller configuration, cabling, and duplex settings first.
Cut HMI and SQL Load on the Primary Port
This gets production running tonight with parts you already have.
| Symptom | Likely cause | Action |
|---|---|---|
| Motion time jumps when an operator changes HMI screen | Screen with a large tag count polling at a fast rate | Slow that screen's update rate; drop tags that do not need live updates |
| Periodic spikes on a fixed interval | SQL logger doing a large block read | Lengthen the interval, trigger on change or event, or log from a buffer the PLC builds |
| Degradation grows with each HMI added | Independent polling from every panel | Match update rates across panels; take shared data from one source where the HMI supports it |
| Spikes with no clear schedule | Programming PC or ad-hoc client left connected | Disconnect monitoring sessions during production |
Practical steps:
- Group SQL tags into contiguous address blocks so the logger issues a few large reads instead of many small ones.
- Have the PLC stage logging data in a buffer and set a flag when it is ready. The logger reads only when the flag is set.
- Set HMI alarm and status polling slower than process display polling. Operators rarely need sub-second alarm banners.
- Remove unused tags from HMI projects. Hidden objects and unused screens often keep polling.
Check: repeat the three baseline runs. The worst-case motion time with all clients active should now be close to the motion-only figure. If it is still well above it, go to isolation.
Split the Machine LAN from the SCADA Side
Keep machine devices (VFDs, motion, I/O) on a different LAN from SCADA and plant traffic. That keeps plant broadcasts, scans, and unrelated chatter away from time-critical devices. With a single general-purpose CPU port you can only partly achieve this:
- The primary port sits in one subnet. The CPU cannot be a native member of two separate LANs through one port.
- VLANs on a managed switch separate broadcast domains for the other devices. Traffic to the CPU still goes through its one port, and crossing VLANs needs a router or Layer 3 switch.
- A NAT router or industrial firewall between the plant network and the machine network keeps plant traffic off the machine LAN and exposes only the CPU's address upstream.
Do this:
- Put the CPU, motion controller, and machine HMIs on the machine subnet.
- Put SCADA, SQL server, and office clients on the plant side of a router or NAT device.
- Allow only the required connections to the CPU through that device.
Check: run a packet capture on the machine LAN. You should see no plant broadcast traffic, and only the SCADA/SQL requests you permitted. Isolation reduces noise. It does not reduce the requests the CPU must answer, so the load cuts from the previous section still apply.
If the CPU is a , the second port is real extra capacity, but only for the traffic it accepts.
- Move GS-Drives off the primary port and onto the Remote/GS-Drives port on its own switch.
- Put Ethernet remote I/O on the same second-port network.
- Leave the motion controller, HMIs, and SQL on the primary port, since the second port will not accept them.
The wrong fix here is to put an HMI or the motion controller on the second port expecting it to answer. It will not accept those connections.
Check: drives and remote I/O report healthy on the second port, and the primary-port capture no longer shows drive traffic. Rerun the baseline and compare.
Decide When One Port Will Not Do
At the time of this evidence, AutomationDirect listed additional Ethernet port modules for the P3000 as a planned enhancement with no release date. The hard case: a project that needs remote I/O and at least two separate general-purpose Ethernet networks. On a , remote I/O takes the second port, which leaves one port for everything else. Letting that port switch between Remote I/O and Modbus would not help either, because remote I/O would still occupy it.
Options, in order of preference:
- Check the current AutomationDirect catalog and firmware release notes for Ethernet expansion modules or changes to second-port capability released since 2013.
- Put a separate device (a small PLC or protocol gateway) on the plant network to collect HMI and SQL data, and give it one controlled connection to the P3000.
- Choose a controller with multiple independent Ethernet interfaces for that project.
Check: write the network architecture on one page, with each CPU port, its subnet, and every client on it. If any port carries both time-critical motion traffic and uncontrolled client traffic, the design is not finished.
Run the End-to-End Verification
- Put every HMI on its heaviest screen at the same time.
- Force a SQL logging event, or wait for the longest scheduled one.
- Connect SCADA and let it run its normal poll.
- Record maximum motion read/write time over a full production cycle, including startup and recipe changes.
- Check the motion controller and CPU for communication timeouts or retry counts.
- Unplug and reconnect an HMI while motion runs. Reconnection bursts are a common hidden spike.
Pass criteria: worst-case motion time meets target under full load, with zero communication timeouts over the test period. Save the capture and the timing log. They become the baseline for the next person who adds a client to this network.
FAQ
Why does adding a switch not fix slow P3000 Ethernet communication?
A switch adds physical connections, not CPU capacity. Every client still reaches the same single port and communication processor on the CPU. If that processor's request queue is the bottleneck, more switch ports just let more clients into the queue.
Why does motion controller response time spike when HMIs are connected to the same PLC?
The motion controller's requests wait in the same queue as every HMI and SQL request. Worst-case latency therefore follows the busiest moment on the network. Slow HMI update rates, block the SQL reads, and measure maximum rather than average round-trip time.
In the firmware covered here, no. The second port serves Remote I/O and GS-Drives only, communicating with GS-Drives on TCP 502. Check current AutomationDirect firmware release notes for any change to that port's capability.
Why does separating VFDs from SCADA on a VLAN not reduce PLC load?
VLANs keep broadcasts and unrelated traffic apart, but every request aimed at the CPU still arrives through its one primary port. Isolation lowers noise on the machine network. Reducing polling is what lowers the number of requests the CPU must answer.
Why does SQL logging cause periodic communication timeouts on a PLC?
Loggers often issue many reads at once on each interval or trigger, producing a burst that delays other clients. Stage the data in a contiguous PLC buffer, read it in a few block reads, and trigger the logger with a ready flag instead of a fast fixed poll.
Stop and contact AutomationDirect technical support if motion times fail the motion-only baseline with no other clients connected, or if you need remote I/O plus two independent general-purpose Ethernet networks on one P3000. Ask them for the current Ethernet expansion options and the second-port capabilities for your CPU firmware before you commit the architecture.