Inconsistent behavior of QSerialPort on Debian

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?

SGaist

And if you build it with Problematic(this) ?

When you don't pass it a parent, do you delete it in the destructor of your MainWindow ?

Hjunior

@SGaist Hi.

I am tried with Problematic(this) no change. In case of no parent arg i tried with delete, but nothing changed.

I tried making it static as
MainWindow.h

static Problematic* notWorksSo;

MainWindow.cpp

Problematic* MainWindow::notWorksSo = 0;

then in constructor

notWorksSo = new Problematic(this);

NOTHING CHANGED.

Any ideas?

SGaist

Without seeing the implementation of these classes I can't tell.