Happy you got it working. I’m curious about the explanation though. I think it may not be an issue with the commands, but rather how the DNP3 charts are using them.
Can you post what they had you change to get it working?
-442 is the normal response for Accept Incoming Communication. I have some TCP server logic that allows multiple clients to connect and I use that status in my chart, it is used in 9.x versions, and I tested it on 10.x and still works the same. If you were getting -442, that simply means no clients were trying to connect (at least as far as the strategy is concerned)
-47 is telling you the comm handle is already open, which basically means Accept Incoming Communication was called on an comm handle that is already in use. If the comm handles were being managed well by the logic, you shouldn’t get that. In the DNP3 chart, it is a side effect of how the chart is written. I can assure you that the chart is returning both -47 and -442 depending if there is a client connected to the comm handle. These are the likely responses:
-47: someone is already using the comm handle, move along
-442: this comm handle has waited for 10 seconds for a client to connect and nobody did, just letting you know, call me again to keep waiting
0: We got a new client connected, lets listen to them
I looked at the DNP3 chart and it handles Accept Incoming Communication in a way that is strange to me (looking in the Outstation protocol chart). It is a complicated chart, so I could be total wrong on this, but it looks like this protocol is setup so a client connects, get what it needs and disconnects. If the clients keep the connection open, then I suspect they would get frequent timeouts while the chart is sitting waiting for Accept Incoming Communication. Maybe that works for this specific protocol, however, I use the below pattern for a server in a PAC Control strategy.
PAC Strategy TCP server pattern
For those who are interested in this. Let me know if you see any issues.
Accept Incoming Communication is a blocking command and will wait 10 seconds for a client to connect and if not, returns -442. The response to a -442 status would be to call Accept Incoming Communication and wait again. This makes it unsuitable to be called in the same chart that your client processing logic is. Therefore, this command should be in a server listener chart and the client processing should be handled in a separate chart. If Accept Incoming Communication returns 0, we have a client, anything else, then there is an issue and we go back and call Listen for Incoming Communication again on that comm handle. Your comm handle pool will need as many comm handles as you expect clients and logic to handle pool exhaustion (delay until a comm handle comes available).
When a client connects, the server listener chart will hand the client off to another chart to handle the client(s), then rotate to the next available comm handle in your pool and call Accept Incoming Communication and wait for the next client. The client chart would return the comm handle to the available pool when the client disconnects.
This allows the strategy to serve multiple clients simultaneously.
See HTTP Interfacing and ports - #9 by philip for which order the commands should be called in for a TCP server.