QT 5.7 Serial Port reads very slow - c++

I am very new to programming and I am teaching myself. I wrote a application to poll a number of requests from a control unit . I basically continuously send various read commands to the Control unit and read back the response .My program works and i successfully send commands and receive answers . But the reading is very slow ( i have a 100 ms timeout in my code to ensure i get the complete reply )
I have a program for the same control unit that was written by a professional coder in C++ , in his program he polls every 30 ms and i always receive the complete answer in that time frame . I have the same settings 57K baud 8 bits 1 stop bit and no parity . However my QT code takes almost 100 ms to receive the answer.
In my code i read the first 2 bytes ( first byte is the message identifier and second byte is the remainder of the message length) then i read in a loop until the total message length is equal to the message length byte +1 (the +1 is there to include the first byte ) . I am a wits end as to why my code is so slow in QT when i know its know the Hardware that's the limiting factor . The requests are always 3 bytes and the reply varies from 3 to 61 bytes . Please help me to point me to my error. If i remove the timeout i always have short reads . So far i also tried read(all) but with the same result .
Below is the extract from my code where i read the response . The full code is at https://github.com/MarkusIppy/PowerTune
//Error handling
QTime startTime = QTime::currentTime();
int timeOut = 100; // timeout in milisec.
QByteArray recvData = m_serialport->read(2); // reading first two bytes of received message to determine lenght of ecpected message
int msgLen = recvData[1]; //Total message Lenght excluding the first byte
while ( recvData.size() <= (msgLen+1) )
{
if ( startTime.msecsTo(QTime::currentTime()) > timeOut ) break;
recvData += m_serialport->read(msgLen+1-recvData.size());
}
if (msgLen +1 == recvData.length()) //if the received data lenght equals the message lenght from lenght byte + identifier byte (correct message lenght received )
{
qDebug() << "Received data OK"<<msgLen +1;
if(requestIndex <= 61){requestIndex++;}
else{requestIndex = 58;}
readData(recvData);
}
else //if the lenght of the received message does not correspond with the expected lenght repeat the request
{
qDebug() << "Received data lenght NIO";
readData(recvData);
qDebug() << "Request Message again"<< requestIndex;
}

I am sorry, I don't have enough time to go through your project and from the code you've provided I cannot be 100% sure what the cause is. My best guess though is that the problem in this case is that you wait explicitly for the data to be received and the events processing is somehow delayed or does not take place at all.
Anyway, here you have a couple of suggestions:
Use QTimer for timeouts instead of QTime.
Learn about the Qt5's signals and slots and use them to read from the serial port asynchronously.
I use the QSerialPort by connecting its bytesWritten(qint64 bytes) and readyRead() signals to slots of my program, let's say on_bytesWritten(qint64 bytes) and on_readyRead(). Then I send request to the target device and in the on_readyRead() slot I process the result. With each send command I start a QTimer with its timeout() signal connected to a on_timeout() slot of my application. This way I could monitor whether the device responds in time or not, as well as to have the data as soon as it comes. You may also use the errorOccurred(QSerialPort::SerialPortError error) signal of the QSerialPort to check if there is a problem with the transmission.

Changed my code slightly again and now it works perfectly on the actual Hardware
Below is my ready to read Slot :
void Serial::readyToRead()
{
qDebug() << "ready read";
if(ecu == 0)
{
m_readData.append(m_serialport->readAll());
Bytesexpected = m_readData[1]+1;
qDebug() << "readdata current" <<m_readData.toHex();
if (Bytesexpected == m_readData.size())
{
m_timer.stop();
if(requestIndex <= 62){requestIndex++;}
else{requestIndex = 59;}
readData(m_readData);
Serial::clear();
m_readData.clear();
Serial::sendRequest(requestIndex);
}
if (Bytesexpected != m_readData.size())
{
qDebug() << "starting timer";
m_timer.start(5000);
}
}

This is what i have so far ( just posting the important parts of my cpp file )
This code works now almost perfectly with my message emulator. It polls now as expected but the timeout gets always triggered after 5 seconds ( i need to change it to only trigger if there is no message comming ) . I will only be able to test it on the actual hardware end of next week .
This is what i have so far :
void Serial::initSerialPort()
{
if (m_serialport)
delete m_serialport;
m_serialport = new SerialPort(this);
connect(this->m_serialport,SIGNAL(readyRead()),this,SLOT(readyToRead()));
connect(m_serialport, static_cast<void (QSerialPort::*) (QSerialPort::SerialPortError)>(&QSerialPort::error),
this, &Serial::handleError);
connect(&m_timer, &QTimer::timeout, this, &Serial::handleTimeout);
m_timer.start(5000);
}
void Serial::readyToRead()
{
if(ecu == 0)
{
m_readData.append(m_serialport->readAll());
Bytesexpected = m_readData[1]+1;
if (Bytesexpected == m_readData.size())
{
if(requestIndex <= 62){requestIndex++;}
else{requestIndex = 59;}
readData(m_readData); // message for processing
Serial::clear();
m_readData.clear();
}
//Timeout
if (!m_timer.isActive())
m_timer.start(5000);
}
}
void Serial::handleTimeout()
{
qDebug() << "Timeout";
//request Data Again
QString fileName = "Errors.txt";
QFile mFile(fileName);
if(!mFile.open(QFile::Append | QFile::Text)){
qDebug() << "Could not open file for writing";
}
QTextStream out(&mFile);
out << "Timeout Request Index " << int(requestIndex)<< " lenght received "<< int(m_readData.length())<< " Bytes "<< " Expected Bytes "<< int(Bytesexpected)<< " bytes " <<" Message "<< QByteArray(m_readData.toHex()) <<endl;
mFile.close();
Serial::clear();
m_readData.clear();
Serial::sendRequest(requestIndex);
}
void Serial::handleError(QSerialPort::SerialPortError serialPortError)
{
if (serialPortError == QSerialPort::ReadError) {
QString fileName = "Errors.txt";
QFile mFile(fileName);
if(!mFile.open(QFile::Append | QFile::Text)){
qDebug() << "Could not open file for writing";
}
QTextStream out(&mFile);
out << "Serial Error " << (m_serialport->errorString()) <<endl;
mFile.close();
qDebug() <<"Serialport Error" <<(m_serialport->errorString());
}
}

Related

Avoiding Timeout on QSerialPort when handling high speed data

I'm working on a windows application that receives data from a sensor at 600Hz. In two out of five cases, my IO thread reads the 4 bytes of data from the sensor successfully and passes it on to the GUI thread.
The problem is three out of five times, QSerialPort has inexplicable timeouts where QSerialPort's waitForReadyRead() returns false and serial.errorString() has a timeout error. In which case it will never read data. If I read from the serial port despite the timeout error I will read 2000+ bytes of data in the next waitForReadyRead which will be delivered in chunks which renders the realtime data reception aspect of my application obsolete.
I've tried using the readyRead() signal of the serial port but it exhibits the same behaviour ie. if the timeout error appears, no readyRead() signal is ever fired.
UPDATE: I am able to reproduce the issue with Qt's terminal example ([QT_INSTALL_EXAMPLES]/serialport/terminal) which uses a non-blocking read. The frequency of the bug is considerably less but it's definitely still there.
UPDATE: Using Serial Port Monitor, I can see that when it gets stuck, the Qt Terminal Example gets stuck on IOCTL_SERIAL_WAIT_ON_MASK, my example gets stuck on IRP_MJ_WRITE DOWN just after the IOCT_SERIAL_WAIT_ON_MASK. This never happens with other terminal softwares leading me to think the problem is definitely with Qt.
Pastebin of Serial Port Monitor Output
void IOThread::run(){
QSerialPort serial;
serial.setPortName(portname)
serial.setBaudRage(QSerialPort::Baud115200);
serial.setStopBits(QSerialPort::OneStop)
serial.setParity(QSerialPort::NoParity);
serial.setDataBits(QSerialPort::Data8);
serial.setFlowControl(QSerialPort::NoFlowControl);
if(!serial.open(QIODevice::ReadWrite)
{
qDebug() << "Error Opening Port";
return;
}
else
{
qDebug() << "Error Message: " << serial.errorString() // prints "Unknown Error"
}
while(true)
{
if(serial.waitForReadyRead(1000))
{
qDebug() << "Normal read";
reception_buffer = serial.readAll();
}
else
{
qDebug() << "Timeout";
/* serial.readAll() here will read nothing but force next read to read huge chunk of data */
continue;
}
}
// Process data...
}
Try if this makes any difference:
while (true) {
QByteArray reception_buffer;
if (serial.waitForReadyRead(1000)) {
reception_buffer = serial.readAll();
while (serial.waitForReadyRead(10)) {
reception_buffer += serial.readAll();
}
qDebug() << "reception_buffer ready";
}
else {
qDebug() << "Timeout";
}
}
If you want to prevent from timeouting from waitForReadyRead you can set:
if(serial.waitForReadyRead(-1))
bool QSerialPort::waitForReadyRead(int msecs = 30000) will timeout after msecs milliseconds; the default timeout is 30000 milliseconds. If msecs is -1, the function will not time out.
gets stuck on IOCTL_SERIAL_WAIT_ON_MASK
Most likelly a problem is in your HW or driver. QSP use asynchronous notification, based on WaitCommEvent. If WaitCommEvent get stuck - then a problem is in your device or driver (most likelly).
Thanks to the guys at QSerialPort, this bug in Qt 5.10.1 is solved by applying this patch: https://codereview.qt-project.org/#/c/225277/
"QSP may ignore all the read events when the data comes to the device
within opening. In this case, even re-opening of a device does not
help. Reason is that the QWinOverlappedIoNotifier is enabled after
than the startAsyncCommunication() called, that probably, leads to
ignoring for all EV_RXCHAR events. A workaround is to enable the
notifier before than any of I/O operation called." - Denis Shienkov, QSerialPort Maintainer

How to read data from the serial port in QT?

I am creating a script in QT for reading the format packages (AA), (BB), etc from serial port. I open the serial port, but when I go to check inside the QByteArray values, comes back that I could not read any value.
This is my code
...
QSerialPort *serialPort = new QSerialPort();
serialPort->setPortName("ttyUSB0");
serialPort->setParity(QSerialPort::NoParity);
serialPort->setBaudRate(QSerialPort::Baud9600, QSerialPort::AllDirections);
serialPort->setStopBits(QSerialPort::OneStop);
serialPort->setFlowControl(QSerialPort::NoFlowControl);
serialPort->open(QIODevice::ReadOnly);
if (serialPort->isOpen()) {
qDebug() << "Serial port is open...";
QByteArray datas = serialPort->readAll();
if (datas.size() == 0) {
qDebug() << "Arrived data: 0";
} else {
for (int i = 0; i < datas.size(); i++){
if (datas.at(i)) {
qDebug() << datas[i];
}
}
}
} else {
qDebug() << "OPEN ERROR: " << serialPort->errorString();
}
serialPort->close();
qDebug() << "...serial port is closed!";
return 0;
...
You called readAll() immediately after open(). It probably took the computer a few nanoseconds to get from one to the other.
At 9600 baud, each byte of data takes slightly more than one millisecond to transfer. It would be absolutely impossible for any data to have arrived in that short an interval, so that's why you got no data.
Serial ports don't begin buffering incoming data until you open them (how could they, what baud rate and other settings would be used for receiving and buffering when no program has the port open?)
Use either a blocking read function of some sort (such as readLine()) or an event loop that reacts to data when it arrives.

how to control the flow of signals in signal slot mechanism?

I am trying to make a neural network using signal and slot mechanism.
my neural network is not layered so I have a block of hidden neurons that are connected randomly. so I probably have loops in the structure which i like to have them.
the question is when I start to emit signals from my input neurons, the first input neuron sends the signal to first hidden neuron and then i would rather want my program send the second signal to the second hidden neuron. but instead the first hidden neuron which has received its signal starts to emit its own signals and so on. when the first path reaches to the end (output neuron) then first input neuron emits the second signal to its second hidden neuron. this causes a problem which information flow partially. i.e. before a certain neuron recieves all its inputs it sends a signal only based on one input that it recieved. I tried to solve it by adding a counter that let the signal be emitted after all expected signals are recieved which in the case of the loops that I have in the structure it doesn't work. two neurons are waiting for the other one to send its signal then they have the full set of signals.
even i tried to let an empty signal ( valued 0 ) to be passed before all the signals are recieved and have the complete signal be passed after all signals are recieved. this one doesn't work since empty signals are accumulating the counter and it goes out of control.
void Neuron::receiveOutput(const int &senderIndex, const double &senderOutput)
{
this->m_sumOfSignals += m_indexedWeights[senderIndex] * senderOutput;
m_receivedSignals.push_back(senderIndex);
qDebug() << "I am neuron " << this->index() << " and I received a signal from neuron "
<< senderIndex << " valued " << senderOutput;
if(m_receivedSignals.size() == m_indexedWeights.size())
{
m_output = this->activate();
qDebug() << "I have receieved all " << m_receivedSignals.size() << " signals so I send my output as "
<< m_output;
m_sumOfSignals = 0.0;
emit sendOutput(m_index, m_output);
}
if(m_receivedSignals.size() < m_indexedWeights.size())
{
m_output = this->activate();
qDebug() << "so far I have receieved " << m_receivedSignals.size() << " signals so I send my output as "
<< m_output;
emit sendOutput(m_index, 0.0);
}
if(m_receivedSignals.size() > m_indexedWeights.size())
{
qDebug() << "I have receieved " << m_receivedSignals.size() << " signals so I stoped sending signals";
return;
}
}
so my question is how can I control the signals flowing in the network?

Qt Serial Port communication

I am writing a Qt application to communicate with another computer over a serial port. I have 2 real issues.
1.
I can send and receive data fine, but sometimes the serial port "eats" part of my input.
For example if I send:
cd /application/bin
sometimes (not always) it will only receive:
cd /applica
(Since it's a terminal it echoes the input back. Also my prompt tells me I'm clearly in the wrong spot.)
2.
Also, sometimes the Qt slot which fires when there is data available doesn't fire even though I know that there's data I can receive. If I send another \r\n down the port the slot will fire.
For example sometimes I'll ls something, and the command name will be read back from the port, but the contents of the folder sit there in limbo until I hit return again. Then I get the listing of the directory and two prompts.
Here's my code:
void Logic::onReadyRead(){
QByteArray incomingData;
incomingData = port->readAll();
QString s(incomingData);
emit dataAvailable(s);// this is a Qt slot if you don't know what it is.
qDebug() << "in:"<< s.toLatin1();
}
void Logic::writeToTerminal(QString string )
{
string.append( "\r\n");
port->write((char*)string.data(), string.length());
if ( port->bytesToWrite() > 0){
port->flush();
}
qDebug() << "out:" << string.toLatin1();
}
I found the solution, and I suspect it was an encoding error, but I'm not sure. Instead of sending a QString down the serial port, sending a QByteArray fixed both problems. I changed the writeToTerminal() method:
void Logic::writeToTerminal(QString string )
{
string.append( "\r");
QByteArray ba = string.toAscii();
port->write(ba);
}
From this forum, it appears that sometimes not all the data gets sent, and whatever does gets sent has a '\0' appended to it. So if
cd /applica'\0'
got sent, then the port->readAll() would stop there, because it thinks it has read everything.
One suggested answer on that forum was to read line by line, which your code almost does. So I think in your case, you can change your code to:
void Logic::onReadyRead(){
QByteArray incomingData;
if(port->canReadLine()) {
incomingData = port->readLine();
QString s(incomingData);
emit dataAvailable(s);// this is a Qt slot if you don't know what it is.
qDebug() << "in:"<< s.toLatin1();
}
}
void Logic::writeToTerminal(QString string )
{
string.append( "\r\n");
port->write((char*)string.data(), string.length());
if ( port->bytesToWrite() > 0){
port->flush();
}
qDebug() << "out:" << string.toLatin1();
}

Flush queued GPIB responses

Architecture ->GBIP from external interface is connected to target ( linux) system via gpib bus.
Inside Linux box , there is ethernet cable from GPIB to motherboard.
The PIC_GPIB card on external interface is IEEE 488.2
I am sending a query from external interface to linux box.
Few scenarios
1) If I send a query which does not expect a response back , then next query send will work.
2) If I send a query which expect response back , and when I have received the response and read it and then fire next query it works fine.
3) BUT if I send a query from external interface and got response back and I ignore to read the response , then Next query fails.
I am requesting help for scenario 3.
The coding is done on linux side and its a socket programming , which uses linux inbuilt function from unistd.h for read and write.
My investigation : I have found there is a internal memory on gbib card on external interface which stores the value of previous response until we have the read. Generally I use IEEE string utility software to write commands that goes to linux box and read reposne via read button .
Could someone please direct me how to clean input buffer or memory which stores value so that write from external command contiunues without bothering to read it.
My code on linux side has been developed in C++ and socket programming. I have used in bulit write and read function to write and read to the gpib and to json server.
Sample code is shown below
bool GpibClass::ReadWriteFromGPIB()
{
bool check = true;
int n = 0;
char buffer[BUFFER_SIZE];
fd_set read_set;
struct timeval lTimeOut;
// Reset the read mask for the select
FD_ZERO(&read_set);
FD_SET(mGpibFd, &read_set);
FD_SET(mdiffFd, &read_set);
// Set Timeout to check the status of the connection
// when no data is being received
lTimeOut.tv_sec = CONNECTION_STATUS_CHECK_TIMEOUT_SECONDS;
lTimeOut.tv_usec = 0;
cout << "Entered into this function" << endl;
// Look for sockets with available data
if (-1 == select(FD_SETSIZE, &read_set, NULL, NULL, &lTimeOut))
{
cout << "Select failed" << endl;
// We don't know the cause of select's failure.
// Close everything and start from scratch:
CloseConnection(mGpibFd);
CloseConnection(mdifferntServer); // this is different server
check = false;
}
// Check if data is available from GPIB server,
// and if any read and push it to gpib
if(true == check)
{
cout << "Check data from GPIB after select" << endl;
if (FD_ISSET(mGpibFd, &read_set))
{
n = read(mGpibFd, buffer, BUFFER_SIZE);
cout << "Read from GPIB" << n << " bytes" << endl;
if(0 < n)
{
// write it to different server and check if we get response from it
}
else
{
// Something failed on socket read - most likely
// connection dropped. Close socket and retry later
CloseConnection(mGpibFd);
check = false;
}
}
}
// Check if data is available from different server,
// and if any read and push it to gpib
if(true == check)
{
cout << "Check data from diff server after select" << endl;
if (FD_ISSET(mdiffFd, &read_set))
{
n = read(mdiffFd, buffer, BUFFER_SIZE);
cout << "Read from diff servewr " << n << " bytes" << endl;
if (0 < n)
{
// Append, just in case - makes sure data is sent.
// Extra cr/lf shouldn't cause any problem if the json
// server has already added them
strcpy(buffer + n, "\r\n");
write(mGpibFd, buffer, n + 2);
std::cout <<" the buffer sixze = " << buffer << std::endl;
}
else
{
// Something failed on socket read - most likely
// connection dropped. Close socket and retry later
CloseConnection(mdiffFd);
check = false;
}
}
}
return check;
}
You should ordinarily be reading responses after any operation which could generate them.
If you fail to do that, an easy solution would be to read responses in a loop until you have drained the queue to empty.
You can reset the instrument (probably *RST), but you would probably loose other state as well. You will have to check it's documentation to see if there is a command to reset only the response queue. Checking the documentation is always a good idea, because the number of instruments which precisely comply with the spec is dwarfed by the number which augment or omit parts in unique ways.