Troubleshooting Clipper Ethernet Response Latency Issues

After separating PLC update time from Ethernet transaction time, the 1.5 ms delay can be assigned to the correct subsystem and the acquisition path can be changed if necessary. A real-time host operating system alone cannot make a request/reply transaction complete in less than 50 µs; that target must be verified against the controller’s documented cyclic, binary, or shared-memory interfaces.

Latency Target and Measurement Boundary

Before anything else, confirm what the timer measures. Sending a request for P101 and stopping the timer when its value returns normally measures a complete request/reply transaction, not the age of the angle value or one-way network delay.

If the requirement means a new sample every 50 µs, the implied update rate is 1 / 50 µs = 20,000 samples/s. If it means only transport latency, sample rate and latency remain separate acceptance criteria. Record which definition applies before selecting an interface.

PLC Source-Freshness Check

1. Add or select a controller-side value that changes on every execution of the logic that calculates the arc-second angle and writes P101. Use an existing documented counter or timestamp if one is available; do not add logic that materially changes the task being measured.
2. Read the marker with P101. Confirm whether consecutive replies contain a new marker value.
3. If several replies return the same marker, measure the interval between marker changes. Do not move on until that interval is below the required data-update interval.
4. If the marker changes promptly but the host receives it late, retain the controller timestamp or counter for the remaining tests. It distinguishes old data delivered quickly from fresh data delivered slowly.

The PLC calculation, write to P101, communications service, and host request are asynchronous unless the controller documentation defines synchronization between them. A request can arrive just after the PLC task has executed and return the previous sample. Faster Ethernet polling does not correct a slow or phase-misaligned producer.

Ethernet Transaction-Path Check

1. Timestamp immediately before the host submits the request and immediately after the complete reply becomes available. Exclude angle conversion, logging, display updates, and unrelated application work.
2. Run a series of transactions and retain minimum, typical, maximum, and outlier latency rather than one average. The minimum approximates the unloaded path; the spread exposes scheduling and buffering.
3. Capture traffic at the host interface. Compare request transmission time with response arrival time. A prompt response at the interface followed by a late application timestamp points to host scheduling or receive processing.
4. Repeat the test with only one outstanding read. Then test any documented block-read operation that can return all required feedback in one transaction. Multiple serialized requests multiply protocol and scheduling overhead.
5. Check for retries, reconnects, malformed replies, and queued requests. Correct those conditions before comparing interface architectures.

An application-level read includes host API processing, protocol framing, operating-system networking, frame transmission, controller communications scheduling, variable lookup, reply construction, receive processing, and application wake-up. A real-time operating system can bound selected host tasks, but it does not remove controller service time or turn an unspecified request/reply protocol into a deterministic feedback channel.

Host and Controller Scheduling Branch

1. Give the acquisition task an appropriate real-time priority and keep blocking file, display, and logging operations out of its timed path.
2. Confirm that the client does not open a connection for every read. Use a persistent connection when the controller protocol documents that operating mode.
3. Check whether the controller processes Ethernet commands in a periodic communications task. Read its configured rate or diagnostic timing from the controller, rather than inferring it from the host timer.
4. Do not move on until packet timing identifies whether the dominant delay occurs before the request leaves, between request and reply, or after the reply arrives.

Acquisition-Architecture Decision

The existing design uses the PLC to calculate an angle in arc-seconds, stores it in P101, and has the host repeatedly request that variable. This is suitable only if the worst-case age and request latency satisfy the motion application.

1. If P101 is stale, shorten or relocate its calculation using documented PLC task controls, or acquire the native feedback value through a documented interface and perform the arc-second conversion at the consumer.
2. If P101 is fresh but individual reads remain too slow, look in the Clipper/PMAC communications documentation for a cyclic, unsolicited, binary, block-transfer, or direct feedback mechanism. Use only a mode explicitly supported by the installed hardware and software.
3. If no Ethernet mode provides a documented worst-case bound below 50 µs, Ethernet request/reply polling does not meet the requirement. Select a documented deterministic interface. The uninstalled DPRAM option cannot be treated as available, and its performance must be read from the applicable hardware documentation before selection.
4. If only average latency matters, optimize the documented Ethernet path and validate its distribution. If the motion function requires a hard deadline, base acceptance on maximum observed latency plus the interface’s documented bounds, not the average.

Resolution and Verification Procedure

1. Define acceptance limits for sample age, transaction latency, update interval, and permitted missed samples. Record whether 50 µs applies to one-way delivery, round-trip response, or sample period.
2. Instrument the PLC-produced value with a controller-side counter or timestamp and instrument the host at request submission and complete-reply receipt.
3. Measure the current P101 path under representative controller, network, and host load. Save minimum, maximum, distribution, stale-sample count, and retry count.
4. Apply the resolving branch: correct the PLC update path when data is stale; remove serialized reads through a documented block or cyclic mode when transaction overhead dominates; or move to a documented deterministic interface when Ethernet cannot satisfy the deadline.
5. Repeat the same loaded test without changing timestamp boundaries. Do not accept the change merely because the average is lower.
6. Pass the design only when every measured sample satisfies the defined age and latency limits for the complete test interval and controller diagnostics show no retries, overruns, or missed updates.

Frequently Asked Questions