Beckhoff / TF6000_ADS_DOTNET_V5_Samples

Sample code for the Version 6.X series of the TwinCAT ADS .NET Packages
https://infosys.beckhoff.com/content/1033/tc3_ads.net/9407515403.html?id=6770980177009971601
BSD Zero Clause License
36 stars 15 forks source link

AmsTcpIpRouter delays when using windows containers and NAT network driver #56

Open peer-dellis opened 5 months ago

peer-dellis commented 5 months ago

This is the setup I am using image

The use case for this setup is to be able to preform a hot swap of our software. Container 1 would be running version 1.1 of our software and container 2 startup running version 1.2. Once a handoff is completed container 2 would take over and container 1 would shutdown.

After many trial and error and support from support@beckhoff.com the above setup is working with one quirk, there is a 4000ms delay from when a client sends a request to when the router forwards the request to the PLC.

log example

//AdsClient.ReadAny called
2024-02-13 09:01:38.906 -05:00 [DBG] ReadRequest: Addr:20.0.21.162.1.1:851, InvokeId:14, IG:f005, IO:19000010, Len:2)
2024-02-13 09:01:38.906 -05:00 [VRB] RequestSync: Addr:20.0.21.162.1.1:851, InvokeId:14, serviceId:"Read", Len:0, header:ReadReqHeader(IG:f005,IO:19000010,Len:2, data:
2024-02-13 09:01:38.906 -05:00 [DBG] RequestSync: Addr:20.0.21.162.1.1:851, InvokeId:14, serviceId:"Read", Len:0, header:ReadReqHeader(IG:f005,IO:19000010,Len:2, data: succeeded!

//4 seconds later router sends read request 
2024-02-13 09:01:42.933 dbug: AdsRouter[0] Send: --> Sending AmsSend Command: 20.0.25.68.1.1:32768 --> 20.0.21.162.1.1:851, Cmd:Read REQ, State:MaskAdsRequest, Err:0, User:14, Bytes:12
2024-02-13 09:01:42.933 info: AdsRouter[0] Send: --> Send AmsSend Command: 20.0.25.68.1.1:32768 --> 20.0.21.162.1.1:851, Cmd:Read REQ, State:MaskAdsRequest, Err:0, User:14, Bytes:12

//router recieves response
2024-02-13 09:01:42.936 dbug: AdsRouter[0] Received: 20.0.25.68.1.1:32768 <-- 20.0.21.162.1.1:851, Cmd: Read RES, State:MaskAdsResponse, Err:0, User:14, Bytes:10 (Sender20.0.21.162.1.1:851 (Endpoint: [::ffff:20.0.21.162]:48898), CNT: 1)
2024-02-13 09:01:42.936 info: AdsRouter[0] Received: 20.0.25.68.1.1:32768 <-- 20.0.21.162.1.1:851, Cmd: Read RES, State:MaskAdsResponse, Err:0, User:14, Bytes:10 (Sender:20.0.21.162.1.1:851 (Endpoint: [::ffff:20.0.21.162]:48898), Receiver:20.0.25.68.1.1:32768 (Endpoint: 172.16.238.17:49160), Count:1

//AdsClient receives response
2024-02-13 09:01:42.941 -05:00 [DBG] onConfirmationReadAsync: Addr:20.0.21.162.1.1:851, InvokeId:14, Result:"NoError", Len:2, Data:CE-00
2024-02-13 09:01:42.941 -05:00 [DBG] RequestAndReceiveSync: InvokeID:'14' succeeded!

The router and client console apps are based on the example code Beckhoff provides, I've attached the program.cs file. client and router.zip

I've also attached the docker images docker images.zip

I've tested the same setup with linux containers using the same container host (Win 11).
There is no delay using linux, so I assume the problem is related to using the nat driver as opposed to the bridge driver.

RalfHeitmann commented 5 months ago

Unfortunately I am not an expert in Docker usage so that I cannot answer why windows containers should behave this way.

For reproducing the issue I miss some relevant information in the attached files or there are some inconsistencies to your description.

peer-dellis commented 4 months ago

Sorry for the delay.

To reproduce you only need two containers running, one router and one client. They delay is seen without the 2nd client running. However to reproduce with 2 clients I created a second container with the client-program and used the command line args to give it a different net id.