We have 4 Pronto 9400s running 2 GC-100 boxes and several RS232 servers. We have developed a state machine piece of code which manages the button presses and gives us control over the data flow in and out of the pronto. All seems fine, but we are finding that the pronto/GC100 drops its TCP/IP connection for some unknown reason, especially if it gets many button presses close together, but its fairly random. The Pronto opens the socket, sends the IR command to the GC, then drops its connection; the state machine then goes busy whilst it continues to wait for the GC reply (we have set 5 second timeout). The pronto often recovers after 3 seconds and gets the reply from the GC, its very consistent with this time so I am sure this is a massive clue.

Latest firmware etc installed in Prontos etc...

Any ideas, thanks,

Dupe...

You should atleast post your basic communication. Do keep the socket open all the time? Are you re-using sockets? Do you use many sockets? Does the GC-100 support multiple sockets?

I'm working with the OP and wrote the ProntoScript for this project so it's probably easier for me to add some more detail.

The GC-100 is being used to send IR commands to various source boxes (SkyHd, Blu-Ray player, etc).  It uses a single TCP socket for communicating with all 6 IR outputs.  This may be accessed from any of the Prontos at any time as it is a multi-user system.  Because of this, the socket must be closed by the Pronto after each command group is sent.  The GC-100 responds to a command with either a success or error message; once this is received by the Pronto, the socket is closed.  The Pronto socket is asynchronous, and the closing occurs in the onData function.

An outline of the code is below.  This sits at the activity level.  The variable avSource is an activity-level object which contains IP address, TCP port, etc.  The function avSourceSendData is called from the main state machine loop when conditions allow.  The loop runs every 100 ms and is driven by the page script.  When the machine enters the BUSY state and sends an IR command, a timer is started.  If this gets to 5000 ms with no response being received, it is assumed that the connection to the GC-100 has been lost and an error is generated.

The behaviour we are seeing is intermittent as described above.  Much of the time, the IR command sends successfully within a single machine loop and occasionally a timeout error occurs.  However, it is more common for nothing to happen until the BUSY timer passes 3000 ms at which point a response is recevied and normal service resumed - this is the 3 second delay referred to by the OP.

I believe that the delay occurs during the initialisation and connection of the TCP sockets and am investigating that further.  However, if this is a phenomenon that anyone else has encountered I'd be keen to hear about it (and how you got round it).

Many thanks,

Andy

// Begin code
function avSourceOnConnect() {
    if (avSource.command !== null) {
        avSourceSendData();
    }
}
function avSourceOnData() {
    try {
        if (avSource.socket.read(30) != avSource.response) {
            generateError("Unexpected AV source return value");
        } else {
            System.print(avSource.response);
        }
    }
    catch(e) {
        generateError("Unable to read from AV source");
    }
    finally {
        avSource.socket.close();
        avSource.socket = null;
        iState = "IDLE";
    }
}
function avSourceInitSocket() {
    try {
        if (avSource.socket) {
            avSource.socket.close();
        }
        avSource.socket = new TCPSocket(false);
        avSource.socket.onConnect = avSourceOnConnect;
        avSource.socket.onData = avSourceOnData;
        avSource.socket.onClose = avSourceOnClose;
        avSource.socket.onIOError = avSourceOnIOError;

        avSource.socket.connect(avSource.ipaddress, avSource.tcpport, 2000);
    }
    catch(e) {
        generateError("Unable to initialise AV source socket");
    }
}
function avSourceSendData() {
    if (avSource.socket && avSource.socket.connected) {
        try {
            avSource.socket.write(avSource.command);
        }
        catch(e) {
            generateError("Unable to send IR command to AV source");
        }
    } else {
        avSourceInitSocket();
    }
}
// End code


The only strange thing I can find is that when you send data and if the socket isn't available you only init the socket but do not send the data.

If you want to know where the 3 sec delay is add System.print(new Date()) a couple of times (or deduct them before System.print).

Thanks for your comments, sWORDs.

In avSourceSendData() if the socket isn't created and connected, avSourceInitSocket() is called which defines the onConnect function. When (or if) the socket is connected successfully, avSourceSendData is called again: this time the command should be written to the socket.

Further investigation suggests the delay is occurring as the socket tries to connect. This occurs in a stripped-down system with 1 Pronto and nothing else trying to tie up the port on the GC-100. I'm going to look at enforcing a delay between the various TCP socket commands.

Andy

Also have a look at that busy timer, maybe there a bug in that. Also make sure that you catch onWake, it takes a few secs before wireless is successfully restored.

I use a GC100 indirectly from a Pronto. That is, The pronto talks to a PC program and the PC talks to the GC-100. I did this because the PC maintains the IR libraries. Between the PC and the GC-100 there is no delay, in fact from a pronto users standpoint the IR goes out and is acted on by the component before your finger gets off the Pronto button.

I suggest there is a code problem somewhere.

Thanks for your comments, Barry and sWORDs.

For the most part, the GC-100 response is near instantaneous. It's just occasionally the pause happens. Not generally when waking from the sleep state either.

As I understand it, the Pronto sends the asynchronous socket connect command then continues with any remaining code without checking for a connection - this is dealt with by onConnect. The delay therefore seems to be in making the connection or in sending the write command once connected.

I'm getting closer, but still not there!

Andy

I believe your understanding of the connection is correct. One of three things should happen

OnConnect event handler should fire
OnIOError event handler should fire
Nothing should happen and somehow you would ned to do a "no response" detection. Since you are running in a loop as a finite state machine and have a tcpip busy state (I assume it is busy when you initiate a connection) you can just count loop cycles to see if you should invoke "connection attempt timeout processing". I prefer that to another timer and its associated code, but either method should provide recovery. That is basically what I do for all TCPIP work on the Pronto.