Ambiguous resource closing and examples do not close after completion.

[JollyWizard]

After calling PLC.connect, when the promises have completed, the application stays open.

The Readme doesn't indicate to expect this behavior, nor does it seem to indicate how to properly close open connections.

I tried PLC.destroy, PLC.destroySoon, PLC.end, and PLC.close. I either got errors (no function or promise rejection), or the API continues to run in the background. I tried methods inside the callback and in .finally(()=.{})

I looked through the source file for controller and EINC, I could not see a standout example of explicitly closing a socket, and recommendations for TCP sockets didn't seem to work either.

Current Behavior

When running the info or read examples from the Readme, the console does not return to prompt when all code is complete.

Expected Behavior

The connection should close when the callback is complete, or the method for properly closing a connection should be explicitly documented.

Possible Solution (Optional)

• Document the correct procedure and considerations for shutting down the Controller.
• Have a PLC.once(addr, socket, callback) method, which closes after the callback is executed.
• Have a PLC.close() method that properly shuts down the scanner, workers, tcp, etc from inside and outside the callback, allowing the application to complete after the callback returns, without triggering any errors.

Context

I'm trying to bypass the vendor locked in applications we currently rely on to generate some time-series logs of important metrics. I'm in the stage of subscribing to the proper tags, and streaming the information to the console, in order to verify it before forwarding it to some sort of datastore. Noticed this issue immediately, and am concerned about the proper way to handle in order to prevent resource leaks on production machines.

Your Environment

• Package version 1.2.3
• Node Version 10.16.0
• Operating System and version: Win 7 x64
• Controller Type (eg 1756-L83E/B): 1769-L24ER-QBFC1B/A LOGIX5324ER
• Controller Firmware (eg 30.11): 26.13

[kyle-github]

If this is a connected session, then the PLC will terminate the connection on its end after some period of inactivity. In my own library, this is set to about 5 seconds in the set up for ForwardOpen. I have done tests and that timeout is pretty accurate. If you try to use the PLC TCP connection again after that, you will not be able to.

If this is an unconnected (UCMM) session, then I am not sure what will drive the timeout on the PLC side, but there will be one.

I ended up just terminating the connection internally in my library after about 5 seconds of inactivity and closing everything down. If a tag is read again, I reopen the connection transparently (somewhat transparently, as the delay is seen by the client).

This behavior of transparent reconnection solved a lot of weird complaints people had. So I suspect that the PLC disconnecting was a much bigger problem than I saw in my own testing. I have since added several tests that intentionally wait 30 seconds or more between tag requests.

I hope this helps!