Recurring UDP packets from an operator panel to a PLC are ordinary polling. Filter a capture to the two device addresses, set the poll time to 200 ms, and remeasure: if the interval follows the setting the traffic is healthy, and a module crash every 2 to 3 days needs its own failure-time log.
Recurring UDP packets from an operator panel to a PLC are normal polling: the panel rereads the registers behind its screen so the displayed values stay current. That stream is working communication, so treat the suspicion around it as a measurement job. Filter a capture to the two device addresses, slow the poll time, and read the interval back out of the capture. If the interval follows the setting, the traffic is healthy and a module crash every 2 to 3 days is a separate fault, one you log at the moment it happens. This page gives the filter, the arithmetic, what each symptom points to, and the slowest poll rate the screen can carry.
Is recurring UDP traffic from the panel to the PLC normal?
Yes. An operator panel rereads the PLC registers behind its screen as fast as its poll time allows, and a request every 10 to 200 ms is ordinary refresh traffic, not a fault.
On this class of link the reads travel as UDP datagrams: short request, short reply, no session state to keep. A poll time of 0 ms tells the panel to run flat out, one read after the next; a nonzero number spaces them. The capture looking like your online-programming traffic is expected, because the programming session speaks the same protocol and a single packet carries no label of its purpose. Separate the streams by address pair and by what changes when you close the programming software.
Why didn't changing the poll time from 0 ms slow the traffic?
Two testable reasons cover it: the new value never reached the running configuration, or the packets you counted belong to a different exchange than the one that setting governs.
When the setting is live, the captured interval tracks it; on a healthy panel and module the measured interval sits on the configured value within about a millisecond. So an unchanged rate after the change is diagnostic information, not noise. Match your symptom:
- You moved the setting off 0 ms and the interval stayed put. The setting is inactive in the running project, or the stream you are counting is another exchange: a second client, a status protocol, a programming session left open.
- The traffic drops when you close the programming laptop. That stream was the online session. The panel's polling continues underneath it.
- The module crashes every 2 to 3 days while the packet rate holds steady. Steady routine traffic with a crash that lands days apart points to an intermittent hardware or network fault; the polling is background.
- A button press takes more than 2 s to reach the PLC. Field practice on push-button response treats anything above 2 s for one press as polling delay or link impairment, so slow response under a fast poll rate points at the link, not the panel.
How do I filter a capture down to the two devices?
Filter on both addresses and UDP, for example ip.addr == 10.1.50.23 && ip.addr == 10.1.50.10 && udp, with your own panel and module addresses in the two slots; ip.addr matches source and destination, so one pair catches both directions of the conversation.
Write down the panel address, the module address and the active poll setting before you start, so every capture carries its label. Capture where the conversation is visible: mirror the switch port the module hangs on, or capture on a segment the traffic crosses. Then read direction from the packets: panel to module is the request, module to panel is the reply. Count only the requests when you compute the interval.
How do I read the poll interval out of the numbers?
Divide the capture length by the request count: 300 requests in a 60-second capture gives 60 / 300 = 0.2 s, a 200 ms interval that matches a working setting.
You can also read the timestamps of consecutive requests and take the delta; the count method over 60 s averages out jitter. Expect the measured interval to sit at or a few milliseconds above the configured figure: each group of addresses the panel polls adds a turnaround delay between the reply and the next request, and more groups push the number up. That margin is the exchange's rhythm. A measured interval of 10 ms against a configured 0.2 s is the opposite case: the setting is not governing the stream you captured.
What does a working poll-time change look like in an example?
Before the change, a 60-second capture shows 6,000 requests from the panel: 6,000 / 60 = 100 requests per second, one every 10 ms, the flat-out rate a 0 ms poll time produces.
Run it end to end:
- Baseline. Poll time 0 ms. 60-second capture, 6,000 requests. 6,000 / 60 = 100 requests per second, so the interval is 1 / 100 = 0.010 s = 10 ms. Over a day that is 100 x 86,400 = 8,640,000 reads.
- Apply the setting. Set the poll time to 200 ms and confirm the panel took it. Some panels hold this setting in the project file, so the project has to go back down to the panel before the rate changes.
- Remeasure. 60-second capture, 300 requests. 300 / 60 = 5 requests per second; the interval is 60 / 300 = 0.2 s = 200 ms. Daily reads fall to 5 x 86,400 = 432,000. The stream is now 300 / 6,000 = 5% of its old size, a 95% cut.
- The failing variant. After the change the count is still 6,000 in 60 s. Restore the known-good configuration and identify which exchange you are seeing before touching another setting.
Could the polling still be crashing the module?
Keep them as two problems until a failure-time record links them: a module that crashes every 2 to 3 days while the packet rate holds steady is failing for reasons outside that stream, and the stream will look the same right through the fault.
The crash investigation runs on what the module was doing when it died. Named suspects, each with a check:
- Unrelated network load. Broadcast or multicast flooding from other devices lands on the module too. Read the switch's port statistics for the module's port and compare error and broadcast counters with a quiet port on the same switch.
- A low-grade or failing switch. Port counters showing CRC or FCS errors, or drops on the module's port, put the fault on the link. Move the module to another port and watch the counters.
- Grounding. Measure between the panel chassis and the PLC cabinet ground: a fraction of a volt is normal, volts mean a bonding fault that puts current on the cable shield.
Intermittent communication faults reward the same patience in every panel job; the pattern in why an HMI shows an intermittent PLC communication timeout is this one: capture the fault instead of guessing at it.
What do I record when the module actually fails?
Four things, at the moment of failure: the module's indicator LEDs, whether the PLC logic is still running, the exact time, and what the panel shows; save all of it before you reset or power-cycle anything.
Add the switch port counters from that hour and the poll setting then active, so the record and the captures line up. Then let it run to a second failure: at one failure every 3 days, two failures take 6 days of records, and two recorded failures define the pattern. A reset with no record sends you back to the start. What the machine does while the link is down is its own question, covered in fix an HMI communication timeout when outputs hold state. When the module fails with the poll rate slowed and the traffic measured healthy, hand the captures, the failure log and the switch counters to the module maker as a hardware or network fault.
How slow can I set the poll time before the screen suffers?
Set 200 ms for fast-moving values, 500 ms to 1 s for counts and statuses that change over minutes, and treat a button press that needs more than 2 s to reach the PLC as a sign the path is slow, whatever the poll rate.
Polling load scales with how much data each read moves and how often you read it, so group the registers and slow the groups nothing reacts to. The 100 ms figure from the original question is a middle setting: 10 requests a second, double the load of the 0.2 s setting, with no reading benefit the operator can see. One panel polling one PLC at 5 reads per second is a light load. Several panels on one PLC is where the arithmetic starts to matter, and the layout for that case is in connecting many operator panels to one PLC without slow updates.
Recommendation: filter a capture to the panel and module addresses, set the poll time to 200 ms, and remeasure over 60 seconds. If the interval follows the setting, leave the panel at that value, log the next two module failures, and chase the crash as a hardware or network fault. If the interval stays near 10 ms, restore the known-good configuration and identify the exchange you are seeing before changing another setting.
Questions
Does a poll time of 0 ms stop the polling?
No. Zero is a request for the maximum rate: the panel issues the next read as soon as the reply lands, so the interval collapses to the turnaround delays between request and reply. That is why the heaviest stream in the example, 100 requests per second, arrived on the 0 ms setting. If you want quiet, set a number; zero means flat out.
Why does the measured interval sit a few milliseconds above the poll time I set?
Each group of addresses the panel polls adds a turnaround delay between the reply and the next request. Set a poll time of 200 ms across 7 groups at, say, 2 ms each and the capture reads about 214 ms: 200 ms + (7 x 2 ms). The setting is working; the extra milliseconds are the exchange's own rhythm.
Can I stop the traffic by blocking UDP to the module?
You can, and you will break the screen. The displayed values arrive through that exchange, so a blocked port leaves the operator reading stale numbers under a communication error, and the crash question stays open. Slow the poll rate instead, and treat the crash as its own fault with its own failure log.
What do I send the module maker when I escalate?
Both captures with the poll setting that was active for each, the failure log with timestamps and LED states, the switch model with its port counters, and the module's firmware version readout. Ask for the documented meaning of the LED pattern you recorded; that interpretation belongs in the maker's documentation.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.