Multiple ReadAsync requests

[johnvarney612]

I am using multiple ReadAsync requests with a Task.WaitAll.
For one task array of 7 tags I see several requests sent to the PLC when viewed with WireShark. For example, one for all 7 tasks, one for the first task, one for another task ...
Is this behavior expected?
When testing with a unit test the read never fails. When testing in the application, the initial read task fails with a timeout error but the remaining 6 complete successfully. Using WireShark, the first one fails with a connection failure. Any ideas?

[timyhac]

Sorry @johnvarney612 - not sure what is going on there. Are you able to provide a code repro, debug logs, wireshark logs etc.

[johnvarney612]

[johnvarney612]

[johnvarney612]

[johnvarney612]

[johnvarney612]

The last image shows the tags in the PLC.
The first image shows the code and the task array with the first task failing.
The second and third image shows wireshark logs of the first tag having a connection failure and the rest successfully read.
Any insight would be helpful. Thanks

[kyle-github]

This is all a guess, but it looks like the following might be happening:

• The connection gets set up. This is above the screen shot of the Wireshark capture.
• Some of the tags are attempted to be read. At least the BOOL one. The very top two lines of the Wireshark capture show the request going to the PLC and the TCP stack in the PLC sending back an ACK to the PC. However, there is no data sent back to the PC from the PLC.
• After about 2 (4.55 secs to 6.35 secs) seconds, something on the PC side gives up and tries to kill off the connection. That's the source of the ForwardClose.
• But, to make this more complicated, the PLC responds to that with an error as if the connection is bad or already closed (that's the part where I would like to see the actual error code).
• The core DLL waits for 5 seconds to try again because it thinks the connection was bad. That's the gap between ~6 seconds and ~11 seconds.

What timeouts are you using? Does ~2 seconds sound right? Hmm, actually that might be in the core DLL. I'll need to check as I thought I removed all that code a while ago.

[kyle-github]

If you can capture the debug output from the core library that would really help.

[johnvarney612]

Thanks for the quick response.
I'll try to get some debug logs.
Any idea why it tries the first tag on its own and not the multiple service packet with all seven tags?

[kyle-github]

It may just be a timing issue. The core DLL does not set up a connection to a PLC until there is a tag for it. The first tag out of the gate triggers this process and if the other tags are somehow slightly delayed in starting their creation, the library may only find one fully ready request in the queue.

Hopefully the logs will shed some light on why this is happening consistently in this case.

[johnvarney612]

Debug logs.txt
The attached file has debug logs at the info level

[kyle-github]

Thanks. Unfortunately, this dump starts just as the ForwardClose is being sent. Can you please gather logs from the time the app starts and with log level 4 (Detail)?

The error returned from the PLC is:

TARGET CONNECTION NOT FOUND
This extended status code shall be returned in response to the Forward_Close
request, when the connection that is to be closed is not found at the target node. Routers shall not generate this extended status code. If the specified connection is not found at the router, the close request shall still be forwarded using the path specified in the Forward_Close request.

So the connection ID is not found on the PLC. We really need to see what happened well before this to figure out what is happening.

[timyhac]

Hi @johnvarney612 - were you able to gather the additional logs that kyle requested?