Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. QSerialPort for serial port printer doesn't execute commands
Forum Updated to NodeBB v4.3 + New Features

QSerialPort for serial port printer doesn't execute commands

Scheduled Pinned Locked Moved General and Desktop
4 Posts 4 Posters 1.6k Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • A Offline
    A Offline
    Abin
    wrote on last edited by
    #1

    Hi,

    I use a serial port printer to print. I send command to printer to cut the paper after printing.

    I close the port immediately after print is completed, as I need printer to be accessed from other machines also.

    The paper cut gets executed only if I close the printer port after a timeout. waitforbyteswriten(-1) and close will not execute the cut.

    The below code doesn't execute paper cut.

    @void SerialPortWriter::write(const QByteArray data)
    {
    m_DataLength = 0;
    m_pByteArray->clear();
    *m_pByteArray = data;
    m_pSerialPort->setPortName("COM3");

    if (m_pSerialPort->open(QIODevice::WriteOnly))
    {
        if (m_pSerialPort->setBaudRate(9200)
                && m_pSerialPort->setDataBits(QSerialPort::Data8)
                && m_pSerialPort->setParity(QSerialPort::NoParity)
                && m_pSerialPort->setStopBits(QSerialPort::OneStop))
        {
            m_pSerialPort->clear();
            m_pSerialPort->write(data);
            m_pSerialPort->write("\n\n\n\n\n\r");
            m_pSerialPort->write("\x1bi");
            m_pSerialPort->waitForBytesWritten(-1);
            m_pSerialPort->close();
        }
    
    }
    else
    {
        qDebug("port not open in write()");
    }
    

    }@

    The below code execute paper cut.
    @void SerialPortWriter::handleTimeout()
    {
    qDebug("handleTimeout() Invoked");
    m_pSerialPort->close();
    }

    void SerialPortWriter::write(const QByteArray data)
    {
    m_DataLength = 0;
    m_pByteArray->clear();
    *m_pByteArray = data;
    m_pSerialPort->setPortName("COM3");

    if (m_pSerialPort->open(QIODevice::WriteOnly))
    {
        if (m_pSerialPort->setBaudRate(9200)
                && m_pSerialPort->setDataBits(QSerialPort::Data8)
                && m_pSerialPort->setParity(QSerialPort::NoParity)
                && m_pSerialPort->setStopBits(QSerialPort::OneStop))
        {
            m_pSerialPort->clear();
            m_pSerialPort->write(data);
            m_pSerialPort->write("\n\n\n\n\n\r");
            m_pSerialPort->write("\x1bi");
            m_pTimer->start(5000);
        }
    
    }
    else
    {
        qDebug("port not open in write()");
    }
    

    }@

    Is there a way to handle without a timer?

    Thanks in advance.

    1 Reply Last reply
    0
    • K Offline
      K Offline
      kuzulis
      Qt Champions 2020
      wrote on last edited by
      #2

      The waitForBytesWritten(-1) does not guarantee that all data were transferred to the physical interface. It is only guarantee that all data were transferred to the low-level device driver. Thus, some data can remain still not transferred from the physical FIFO (or a shift register) of device.

      So, need to wait a some small time after the waitForBytesWritten(-1). If you want, you can use non-blocking waiting, using the bytesWritten(qint64) signal + some additional timeout from the QTimer. In each of bytesWritten(qint64) you should to check (to accumulate) on number of transferred bytes. When accumulated length is equal to your whole message length, then try to startup the QTimer with additional timeout.

      1 Reply Last reply
      0
      • R Offline
        R Offline
        Rondog
        wrote on last edited by
        #3

        I am not sure what you mean by 'other machines'. If this refers to other computers connected to the same printer then closing the port won't make any difference. For other programs running on the same computer closing the port would be prudent as they wouldn't be allowed to access the port until it is released.

        If your setup is to have different machines talk to one computer connected to the printer (where this program is running on the computer connected to the printer) then I don't see the need to close the port right away unless each connection tries to directly access the serial port. You could probably change your program to use only one common serial port object and some sort of queue to get around this problem.

        1 Reply Last reply
        0
        • mrdebugM Offline
          mrdebugM Offline
          mrdebug
          wrote on last edited by
          #4

          9200? I think should be 9600.

          Need programmers to hire?
          www.labcsp.com
          www.denisgottardello.it
          GMT+1
          Skype: mrdebug

          1 Reply Last reply
          0

          • Login

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • Users
          • Groups
          • Search
          • Get Qt Extensions
          • Unsolved