AdsNotification cycle time deviation

[captain-yoshi]

This is similar to #215. I need to get a reliable stream of data (304 Bytes) at 1kHz using the AdsNotification approach. I get inconsistent timing (see timing below). This can be due to:

• TCP
• The task settings on TwinCAT side
• The number of CPU ressources available at the receiving end (callback, OS, I/O's)
• Other reasons...

For the benchmark below, I have reduce my Twincat program to be as fast as possible and the callback on linux does nothing.

Is there a way to have a better timing tolerance between each packets received. Could the server side use a pool of threads or something else entirely to improve this behavior ?

route_notification_ = std::make_shared<AdsDevice>(
    remoteIpV4_, remoteNetId_, AMSPORT_R0_PLC_TC3);

// Get handle for command and state variables
handle_command_ = std::make_unique<AdsHandle>(
    ads_devices_[0]->GetHandle(adsBufferCommandName_));

// create notification callback for state
Callback<void(const AmsAddr *pAddr,
              const AdsNotificationHeader *pNotification,
              uint32_t hUser)>::func =
    std::bind(&RosTwincatBridge::NotifyCallback, this,
              std::placeholders::_1, std::placeholders::_2,
              std::placeholders::_3);
callback_t func = static_cast<callback_t>(
    Callback<void(const AmsAddr *pAddr,
                  const AdsNotificationHeader *pNotification,
                  uint32_t hUser)>::callback);

// Each server cycle @ 1kHz
AdsNotificationAttrib attrib = {
    DATA_STATE_SIZE, ADSTRANS_SERVERCYCLE, 0, {10000}};

notification_state_ = std::make_unique<AdsNotification>(
    *route_notification_, adsBufferStateName_, attrib, func, 2);

# Elapsed time between previous and current callback (1kHz -> 0.001 seconds)
AdNotification= 0.00117044 seconds
AdNotification= 0.00093865 seconds
AdNotification= 0.000897969 seconds
AdNotification= 0.0010241 seconds
AdNotification= 0.000986944 seconds
AdNotification= 0.00182602 seconds
AdNotification= 0.000157791 seconds
AdNotification= 0.00118531 seconds
AdNotification= 0.000804247 seconds
AdNotification= 0.000995989 seconds
AdNotification= 0.00100133 seconds
AdNotification= 0.00100328 seconds
AdNotification= 0.00103729 seconds
AdNotification= 0.00104816 seconds
AdNotification= 0.000939896 seconds

[pbruenn]

Your first bullet point is the culprit. Remove TwinCAT and ADS from your benchmark and run it on a bare TCP connection. You will see most of your Jitter is systematic to TCP/IP.

[soberschmidt]

ADS is not a fieldbus and was designed for acyclic communication. ADS notifications provide the option to collect data from every PLC cycle and you will not miss a value (cmp. to polling) of your 1Khz signal. But TCP/IP (even if UDP is used) as already mentioned and the OS (UM/RT context switching) will cause a jitter, even if your ADS client and PLC runs on the same system.

For deterministic TCP communication with TwinCAT systems you can use network variables (TwinCAT 2), EAP (TwinCAT 3) or TwinCAT 3 TCP/UDP RT function.