mycroes
commented
1 year ago This is by design:
/// <summary>
/// Gets a value indicating whether a connection to the PLC has been established.
/// </summary>
/// <remarks>
/// The <see cref="IsConnected"/> property gets the connection state of the Client socket as
/// of the last I/O operation. When it returns <c>false</c>, the Client socket was either
/// never connected, or is no longer connected.
///
/// <para>
/// Because the <see cref="IsConnected"/> property only reflects the state of the connection
/// as of the most recent operation, you should attempt to send or receive a message to
/// determine the current state. After the message send fails, this property no longer
/// returns <c>true</c>. Note that this behavior is by design. You cannot reliably test the
/// state of the connection because, in the time between the test and a send/receive, the
/// connection could have been lost. Your code should assume the socket is connected, and
/// gracefully handle failed transmissions.
/// </para>
/// </remarks>
public bool IsConnected => tcpClient?.Connected ?? false;As you can see we're using TcpClient.Connected (Microsoft Docs), you can see a similar remark there.
when i connected a plc ,and executed open() method, the IsConnected==true. while i take off the ethernet line, the IsConnected property is still true! this is a bug, this time it should be false!