0

I'm useing QTcpSocket class to communicate between my QT-UI and my PLC.

Recently I changed my protocols, so that I can send large coherent chunks of data. The goal is to send string-data via TCP-protocol.

On the PLC-Side I delay the sending of the response by about 30 msec. Thats the time the PLC needs to process the string. The response is send, and I know on the UI-side to send the next one. The Problem now is, the 30ms seem to be to long. A QTcpSocket::disconnected signal is emitted before the QTcpSocket::ReadyRead signal.

Is there a way to modify when QTcpSocket::disconnected is emitted? To set the timeout to 40 msec for example.

I tried tcpSocket->waitForReadyRead(100) which also results in the disconnected signal beeing emitted.

tcpSocket->setSocketOption(QAbstractSocket::KeepAliveOption, 1); had no result either.

The only way I can think of right now would be, to send the response immediately and implement a custom wait function, until the next string is to be send.

void WaitMS(int DurationMS)
{
    QTime tWait;
    tWait.start();

    while(true){
        QCoreApplication::processEvents();
        if(tWait.elapsed()> DurationMS)
            break;
    }
}

This is an option, but it's a crude method.

Any help is appreciated.

J.Hilk
  • 1
  • 3
  • the signal is not emitted due to timeout, you can keep a `QTcpSocket` open without sending any data for far longer than 30ms. I think that your PLC is closing the connection, use a packet sniffer like wireshark to make sure this is the case. . . – Mike Jul 22 '16 at 20:06
  • Hi, first thanks for the answer. I can say with 95% certainty say, that the problem is not with the PLC. Couple of reasons. 1: The connection timeout is disabled on the PLC, no monitoring of the connection status from that side. 2: I have a small test-programm written with Embarcadero RAD Studio (in Pascal if I remember correctly) and this one communicates without problems with the PLC. The Problem ought to be with QT :( . – J.Hilk Jul 25 '16 at 07:39
  • please provide the code you are using (there may be a problem there), no need for any custom options or flags. Also, please confirm which side is initiating the disconnection, using a packet sniffer like wireshark. . . – Mike Jul 25 '16 at 07:44
  • Sry for the delay, was a busy week. Sadly I can't post the code here. With how much I would have to post for anyone to make sense of it, I would open the possibility for outside programs to mess with our machines. I'll stick with the wait-function. Not the best solution, but I'm on a deadline here :( – J.Hilk Aug 02 '16 at 07:05

0 Answers0