Inconsistent behavior of QSerialPort on Debian

Hjunior

I want to communicate with Epson TM-H6000iii via EscPos by using QSerialPort 5.5. It cancels printing on serial.close. When I debugged it can't catch the reason. After spending days I found this case:

Reboot machine
Run the application. (Printer cancels printing)
Debug the application and put breakpoint on serial.close(); (Printer behaves as expected)
Now run the application again. (Printer will NEVER STOP PRINTING again on serial.close)
To sum up: if I debug serial.close line once then no problem at all.

Any idea?

Also i posted this at
http://stackoverflow.com/questions/34994668/inconsistent-behavior-of-qserialport-on-debian
I use Debian based Lubuntu 14.04

SGaist

Hi and welcome to devnet,

You should also add which parameters you use for your serial port.

Hjunior

Hello.

These are the parameters:

    serial = new QSerialPort(this);
    serial->setPortName(portName);
    serial->setBaudRate(QSerialPort::Baud19200);
    serial->setDataBits(QSerialPort::Data8);
    serial->setParity(QSerialPort::NoParity);
    serial->setStopBits(QSerialPort::OneStop);
    serial->setFlowControl(QSerialPort::HardwareControl);

And i write the bytes to serial port by using:

bool SerialUtil::writeWait(QByteArray request, const QString name){
    if (serial->write(request)<request.length())
        return false;
    return serial->waitForBytesWritten(3000);
}

SGaist

What device do you use to connect to the RS232 port of the printer ?

Hjunior

@SGaist As i said My printer is Epson TM-H6000III (M147G) and it is connected to my PC (Intel Atom CPU, 32bit, 4GB Ram) with 9pin to 25pin cable. Im using ttyS4 port which is recognized by lubuntu 14.04 as UART16550. The setup works if i put breakpoint on serial.close and start a debug session once. Then regardless of running or debugging the application it works fine. After rebooting the PC everything is reset. It doesnt work until i debug it. Cant understand whats going on.

SGaist

That I understood, what I was asking was about what you had between your printer and computer. You could be using an USB to Serial Port converter but from your description it seems to be an integrated serial port, correct ?

Do you have any other program that you can use to communicate with your printer ? To see if they also suffer from that strange behavior.

Hjunior

@SGaist Yes im using PC's serial port thats correct, no usb in the setup. No there is no any other program working other than QtCreator. Im sure.

Is QSerialPort extended from QextSerialPort. Are they same? Shall i try it? I must solve this problem. Or any other idea?

mrdebug

Can you try serial->setFlowControl(); none?
I'm using QSerialPort intensively in Debian and I assure it's working perfectly.

SGaist

No QSerialPort and QextSerialPort are two different things.

My question wasn't about having two applications running at the same time. Just if you had the possibility to test the communication with your printer with another application to ensure that the port parameters are correct and the port is working correctly.

Hjunior

Hmm, I see. Since it is a RS232 based printer i have no other program by this way. But it has linux driver to work with CUPS. I can test with it tomorrow and will post the results.

Actually, i want to ask you about my design. I have a BaseSerialDevice class and QSerialPort is a private pointer stored in BaseSerialDevice.h and created in createPort@BaseSerialDevice.cpp.
Then I have an EscPos class which extends BaseSerialDevice and calls createPort in constructor. I have 2 more classes extending the same BaseSerialDevice as same as EscPos. They working without any issue. At a time all of the 3 ports must be open and work. The other 2 has no problem. I checked the IRQs and tried several things but nothing changed. One more idea is they are all attached to MainWindow so they are in same thread. May this be the issue? Or is the setup issue? Or has QSerialPort a hidden bug?

SGaist

From your description, are you opening the same port 3 times ?

Hjunior

No friend they use base same class. The instances are set to use DIFFERENT PORTS as ttyS1,ttyS4,ttyS6

SGaist

All of them physical ports of your computer or converter like usb to serial ?

Hjunior

@SGaist Yes all of them are phsical ports of my computer. NO usb to serial.

SGaist

Does it also happen if you change devices e.g. exchange the devices from ttyS1 and ttyS6.

Hjunior

@SGaist No difference.

SGaist

Does the devies need the DTR to be set ?

Hjunior

@SGaist Yes the device uses Hardware flow control and in the technical manual says it uses DTR/DSR.

SGaist

Silly question but, did you set DTR in your application ?

Hjunior

Hello again,

I finally figured out how this occurs.

BaseSerialDevice.cpp

class BaseSerialDevice : public QObject
{
    Q_OBJECT
....
protected:
    QSerialPort *serial;
....

Problematic.cpp

class Problematic : public BaseSerialDevice
{
    Q_OBJECT
...

MainWindow.h

...
private:
    Problematic worksLikeACharm;

Everything works as expected if defined as a NON-POINTER but if;
MainWindow.h

...
private:
    Problematic* notWorksSo;

then in MainWindow.cpp's constructor:

notWorksSo = new Problematic(parent()); 
or 
notWorksSo = new Problematic(NULL); 
or 
notWorksSo = new Problematic;

the problem occurs as defined at the start of this topic. And same situation occurs if we use QSocket as same architecture.

I tested it from scratch at least 6 times. Im sure of that case.

And Cant believe and cant understand why?