When the controlled device network goes offline, the central controller can immediately obtain the c
ttt
Posts: 18
I want to ask amx netlinx how to write fast access to controlled devices network drops? How about knowing within five seconds that a controlled device's network is offline? Or the fastest time to know when a controlled device's network is offline?
This is currently used:
data_event[dv_vc]
{
online:
{
dv_vc_ConnStatus=1
}
offline:
{
dv_vc_ConnStatus=2
}
onerror:
{
dv_vc_ConnStatus=3
}
}
However, the controlled device is offline for 2 or 3 minutes after it is powered off, that is, dv_vc_ConnStatus=3.
0
Comments
State is often dictated by the poll rate to your connected device. If the socket is persistant, you generally receive immediate notification of a socket closure. If there is a scheduled poll interval, you need to wait for failed connection attempts before it will register as offline. Is there a module/driver managing communications with the device? If so, the change in state from online to offline would typically be dictated by that code.
I use a timeline for this that sends a random command every 5 seconds and waits to see if a random response comes back in the buffer within a few seconds. If there is no response (device offline) then I close the port and try to open it again or start the device offline procedure.
This is only applicable if you want to keep the connection open continuously.
Simply repeating an OPEN to the device will either err report "already open" and have no effect if open, or will open the connection if closed. No need to test - wasting time, code, traffic.
If it is a TCP connection, you have to track the connection state. If the connection breaks, e.g. someone simply powered off the remote device, it may take up to 90 seconds, before the TCP protocol identifies this as a network interruption, and so reports an ONERROR. There is no way to speed up this TCP connection handling, you only can try e.g. send a message to the remote device, and if it is not replying with your expected time, you could track it as kind of a "warning" that there may be comm issues. But the final comm ending is when the ONERROR reports.
On a UDP connection, there is no connection handling within the network protocol. Here you only can track connection status to a remote device by manually checking if a message to the remote device gets replied within you expected time. If it does, the remote device is there, if it not replies, it's offline.