Inconsistent behavior of QSerialPort on Debian

[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.