Isconnected issue

[albasha007]

When I run myPlc1500.Open(); myPlc1500.IsConnected();

then i run myPlc1500.IsConnected();

it always reports True even though the PLC is disconnected.

i want a way to check the plc if still available or not any one can help me please

[xxxxiaohuiiii]

I'd like to know what to do too. I have the same problem.

[mycroes]

I think this has been pointed out before, but I'll repeat it here.

You can't rely on connection state. The Plc.IsConnected property directly returns the TcpClient.IsConnected property. This property only reflects if the last TCP message has been delivered successfully. The shortcoming to this approach is that the TCP connection might still be active while the PLC won't actually accept any messages, but in general I think the PLC closes the connection when it reaches the point it won't perform any further communication (for instance when TSAP identifiers don't match).

If you want to know if the PLC responds, just perform the action you wanted to do (i.e., perform the read you intended to do). That of course might result in exceptions as well (i.e. reading an invalid address), but checking the connection state first and then invoking whatever method you wanted to invoke will yield the same result.

If the above isn't suitable (i.e., your application relies on user actions and you want to check if the connection is OK on an interval) you can call Plc.ReadStatusAsync() or Plc.ReadStatus(), I guess these should always work without exceptions as long as the connection is OK. On the other hand, if they don't work, I can't imagine that reading or writing data is a possibility either. Then again, I guess getting a status back also doens't guarantee you can successfully perform reads or writes.

[xxxxiaohuiiii]

I think this has been pointed out before, but I'll repeat it here.

You can't rely on connection state. The Plc.IsConnected property directly returns the TcpClient.IsConnected property. This property only reflects if the last TCP message has been delivered successfully. The shortcoming to this approach is that the TCP connection might still be active while the PLC won't actually accept any messages, but in general I think the PLC closes the connection when it reaches the point it won't perform any further communication (for instance when TSAP identifiers don't match).

If you want to know if the PLC responds, just perform the action you wanted to do (i.e., perform the read you intended to do). That of course might result in exceptions as well (i.e. reading an invalid address), but checking the connection state first and then invoking whatever method you wanted to invoke will yield the same result.

If the above isn't suitable (i.e., your application relies on user actions and you want to check if the connection is OK on an interval) you can call Plc.ReadStatusAsync() or Plc.ReadStatus(), I guess these should always work without exceptions as long as the connection is OK. On the other hand, if they don't work, I can't imagine that reading or writing data is a possibility either. Then again, I guess getting a status back also doens't guarantee you can successfully perform reads or writes.

Understood, thanks for the introduction. That's why the heartbeat signal was introduced