We’re experiencing intermittent OPC UA connection timeout errors when FactoryTalk MES v10.0 attempts to download work orders to our shop-floor PLCs. The errors occur during peak production hours (2-3 times per shift) causing 15-20 minute delays while operators wait for work order data.
Our MES client configuration shows default timeout settings, and I’m wondering if we’re hitting OPC UA session or subscription limits. We have 12 PLCs connected with approximately 40-50 active subscriptions per PLC. Network traffic analysis shows occasional spikes during work order transfers.
OPC UA Error: Session timeout after 30000ms
Endpoint: opc.tcp://plc-station-05:4840
Status: BadTimeout (0x800A0000)
Has anyone dealt with similar timeout issues? Should we focus on adjusting MES client timeouts, reviewing OPC UA session limits, or implementing network QoS for MES traffic prioritization?
The staggered download approach is smart. Also check your MES client’s RequestedPublishingInterval and MaxNotificationsPerPublish settings. If these are set too aggressively, you’ll flood the network during work order transfers. We found that increasing RequestedPublishingInterval from 500ms to 1000ms and capping MaxNotificationsPerPublish at 50 reduced our timeout incidents by about 70%. The slight delay is negligible for work order data that doesn’t require millisecond updates.
From the network side, implementing QoS for MES traffic definitely helps, but it’s more of a band-aid if your OPC UA configuration isn’t optimized. We use DSCP marking (EF for critical MES data) with strict priority queuing on our industrial switches. However, you should first address the session/subscription limits mentioned above. One thing that helped us was staggering work order downloads across PLCs rather than broadcasting simultaneously - reduces that traffic spike you’re seeing.
Let me address all three focus areas systematically since you’re dealing with a multi-faceted issue:
OPC UA Session/Subscription Limits:
Your L32E controllers have a MaxSubscriptionCount of 32 by default - you’re exceeding this with 40-50 subscriptions per PLC. You need to either reduce subscriptions or upgrade firmware (if possible) to increase limits. Check each PLC’s session count:
ServerDiagnostics.SessionDiagnosticsArray
CurrentSessionCount vs MaxSessionCount
CurrentSubscriptionCount vs MaxSubscriptionCount
MES Client Timeout Configuration:
Increase these parameters in your FactoryTalk MES OPC UA client settings:
SessionTimeout: 60000ms (from default 30000ms)
RequestTimeout: 45000ms
KeepAliveInterval: 5000ms (ensures session stays alive during congestion)
Network Prioritization:
Implement QoS as your secondary defense:
Apply DSCP EF (Expedited Forwarding) marking to MES traffic on ports 4840 (OPC UA)
Configure strict priority queuing on industrial switches
Set bandwidth reservation of 20-30% for MES traffic
Enable flow control on switch ports connected to PLCs
Additional Recommendations:
Implement staggered work order downloads with 2-3 second delays between PLCs
Reduce MaxNotificationsPerPublish to 50 in MES client
Increase RequestedPublishingInterval to 1000ms for work order data (not time-critical)
Monitor with OPC UA diagnostics to track SessionAbortCount and RejectedRequestsCount
Consider upgrading the 4 L32E controllers if budget allows - newer firmware supports higher limits
The combination of adjusting subscription counts, increasing timeouts, and implementing network QoS should eliminate your timeout errors. Start with the configuration changes first, then add QoS if needed. The staggered download approach alone typically reduces peak network load by 40-50%.
We had similar production delays last year. Quick question - are all 12 PLCs experiencing timeouts or just specific ones? In our case, it was concentrated on 3 older controllers that had lower MaxSubscriptionCount limits (32 vs 100 on newer models). We had to redistribute some subscriptions and increase the session timeout to 60000ms in the MES client configuration.