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. Modbus RTU: readyRead() not called
Forum Updated to NodeBB v4.3 + New Features

Modbus RTU: readyRead() not called

Scheduled Pinned Locked Moved Unsolved General and Desktop
20 Posts 5 Posters 3.6k Views 2 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 aha_1980
    26 Mar 2019, 08:34

    @Mark81

    The documentation also states: https://doc.qt.io/qt-5/qmodbusreply.html#errorOccurred

    The finished() signal will probably follow.

    So it might nevertheless be a good idea to connect to errorOccurred.

    M Offline
    M Offline
    Mark81
    wrote on 26 Mar 2019, 08:36 last edited by Mark81
    #8

    @aha_1980 yes, as reported in the previous reply I added such a connection but it doesn't print anything, so it seems no errors are thrown. Still I can't receive replies in my slot.

    By the way, to me both sentences are in contradiction but perhaps is my poor English that suggests that:

    This signal is emitted when the reply has finished processing. The reply may still have returned with an error.

    The finished() signal will probably follow.

    A 1 Reply Last reply 26 Mar 2019, 08:48
    0
    • M Mark81
      26 Mar 2019, 08:36

      @aha_1980 yes, as reported in the previous reply I added such a connection but it doesn't print anything, so it seems no errors are thrown. Still I can't receive replies in my slot.

      By the way, to me both sentences are in contradiction but perhaps is my poor English that suggests that:

      This signal is emitted when the reply has finished processing. The reply may still have returned with an error.

      The finished() signal will probably follow.

      A Offline
      A Offline
      aha_1980
      Lifetime Qt Champion
      wrote on 26 Mar 2019, 08:48 last edited by
      #9

      @Mark81 I fully agree that "may still have" and "will probably follow" are very poor documentation statements - and can most likely be improved.

      But for now,that just means you should check every error source you can, if you encounter problems.

      Qt has to stay free or it will die.

      1 Reply Last reply
      0
      • M Mark81
        25 Mar 2019, 21:37

        I'm trying to "port" the example of Modbus master to my application.
        Here some relevant code:

        QModbusClient *_modbus;
        
        bool ModbusMaster::open(QString port)
        {
            _modbus = new QModbusRtuSerialMaster(this);
        
            _modbus->setConnectionParameter(QModbusDevice::SerialPortNameParameter, port);
            _modbus->setConnectionParameter(QModbusDevice::SerialParityParameter, QSerialPort::NoParity);
            _modbus->setConnectionParameter(QModbusDevice::SerialBaudRateParameter, QSerialPort::Baud57600);
            _modbus->setConnectionParameter(QModbusDevice::SerialDataBitsParameter, QSerialPort::Data8);
            _modbus->setConnectionParameter(QModbusDevice::SerialStopBitsParameter, QSerialPort::OneStop);
        
            _modbus->setTimeout(2000);
            _modbus->setNumberOfRetries(3);
        
            return _modbus->connectDevice();
        }
        
        bool ModbusMaster::read(QModbusDataUnit::RegisterType type, int startAddress, quint16 count)
        {
            if (!_modbus) return false;
            if (_modbus->state() != QModbusDevice::ConnectedState) return false;
        
            qDebug() << "Read" << startAddress;
        
            QModbusDataUnit req(type, startAddress, count);    
            if (auto *reply = _modbus->sendReadRequest(req, 1))
            {
                qDebug() << reply->isFinished();
                if (!reply->isFinished()) connect(reply, &QModbusReply::finished, this, &ModbusMaster::readyRead);
                else readReady();
                return true;
            }
            return false;
        }
        
        void ModbusMaster::readyRead ()
        {
            qDebug() << "readyRead executed!";
            auto reply = qobject_cast<QModbusReply *>(sender());
            if (!reply) return;
            reply->deleteLater();
        
            if (reply->error() == QModbusDevice::NoError)
            {
                const QModbusDataUnit unit = reply->result();
                // do something
            }
            else if (reply->error() == QModbusDevice::ProtocolError)  qDebug() << reply->errorString();
            else qDebug() << reply->errorString();
        
            // call next reading
            emit readFinished();
        }
        

        but it seems even if received data readyRead() is not called, example:

        Debug: read 495
        Debug: false 
        Debug: (RTU client) Sent Serial PDU: 0x0301ef0001
        Debug: (RTU client) Sent Serial ADU: 0x010301ef0001b403 
        Debug: (RTU client) Response buffer: "0103020000b844" 
        Debug: (RTU client) Received ADU: "0103020000b844" 
        Debug: (RTU client) Send successful: 0x0301ef0001 
        

        after few seconds I got a timeout from my timer. As far as I understand the response is actually received, but the readyRead() slot is not called.

        Is there something obvious I'm missing?

        J Online
        J Online
        J.Hilk
        Moderators
        wrote on 26 Mar 2019, 08:48 last edited by
        #10

        @Mark81

        the QModbusRtuSerialMaster has also errors that can be emitted. And those differ from the reply, check those also.

        connect(_modbus, & QModbusRtuSerialMaster::errorOccurred, this, [](QModbusDevice::Error error)->void{ qDebug() << error;});
        

        Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


        Q: What's that?
        A: It's blue light.
        Q: What does it do?
        A: It turns blue.

        M 1 Reply Last reply 26 Mar 2019, 08:57
        2
        • J J.Hilk
          26 Mar 2019, 08:48

          @Mark81

          the QModbusRtuSerialMaster has also errors that can be emitted. And those differ from the reply, check those also.

          connect(_modbus, & QModbusRtuSerialMaster::errorOccurred, this, [](QModbusDevice::Error error)->void{ qDebug() << error;});
          
          M Offline
          M Offline
          Mark81
          wrote on 26 Mar 2019, 08:57 last edited by
          #11

          @J.Hilk You're right. Added and tried. Whenever the "hang" happens also this slot shows nothing, unfortunately.

          J 1 Reply Last reply 26 Mar 2019, 10:59
          0
          • M Mark81
            26 Mar 2019, 08:57

            @J.Hilk You're right. Added and tried. Whenever the "hang" happens also this slot shows nothing, unfortunately.

            J Online
            J Online
            J.Hilk
            Moderators
            wrote on 26 Mar 2019, 10:59 last edited by
            #12

            @Mark81 how much time passes between open and the first read request ?

            I noticed, on Windows, that when I call immediately after opening the device the first data , then most of the time nothing happens at all.


            Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


            Q: What's that?
            A: It's blue light.
            Q: What does it do?
            A: It turns blue.

            M 1 Reply Last reply 26 Mar 2019, 18:32
            2
            • J J.Hilk
              26 Mar 2019, 10:59

              @Mark81 how much time passes between open and the first read request ?

              I noticed, on Windows, that when I call immediately after opening the device the first data , then most of the time nothing happens at all.

              M Offline
              M Offline
              Mark81
              wrote on 26 Mar 2019, 18:32 last edited by
              #13

              @J.Hilk adding a small delay seems to drastically improve the situation. Occasionally it still happens that the debug messages show a received answer but the slot is not called. That's weird because I can understand if some reasons the answer cannot be received, but this is not the case...

              1 Reply Last reply
              0
              • M Offline
                M Offline
                Mark81
                wrote on 27 Mar 2019, 04:40 last edited by Mark81
                #14

                UPDATE

                I think (not sure, though) I noticed something interesting.
                When it works, the debug output from qt.modbus is like this:

                qt.modbus: (RTU client) Sent Serial PDU: 0x0304270001
                qt.modbus.lowlevel: (RTU client) Sent Serial ADU: 0x0103042700013531
                qt.modbus: (RTU client) Send successful: 0x0304270001
                qt.modbus.lowlevel: (RTU client) Response buffer: "01030200017984"
                qt.modbus: (RTU client) Received ADU: "01030200017984"
                

                and my slot is correctly called. Instead, when the problem arises the output is like the one reported in the first post or even this one:

                qt.modbus: (RTU client) Sent Serial PDU: 0x0304180002
                qt.modbus.lowlevel: (RTU client) Sent Serial ADU: 0x010304180002453c
                qt.modbus.lowlevel: (RTU client) Response buffer: "01030400004080ca53"
                qt.modbus: (RTU client) Received ADU: "01030400004080ca53"
                qt.modbus: (RTU client) Send successful: 0x0304180002
                qt.modbus: (RTU client) Receive timeout: 0x0304180002
                qt.modbus: (RTU client) Sent Serial PDU: 0x0304180002
                qt.modbus.lowlevel: (RTU client) Sent Serial ADU: 0x010304180002453c
                qt.modbus.lowlevel: (RTU client) Response buffer: "01030400004080ca53"
                qt.modbus: (RTU client) Received ADU: "01030400004080ca53"
                qt.modbus: (RTU client) Send successful: 0x0304180002
                qt.modbus: (RTU client) Receive timeout: 0x0304180002
                

                Here my slot is not called.

                I see that every time this happens the "Response buffer" line comes before the "Send successful" one.
                I'm looking at the code but I don't understand if this might be a problem.

                (Sorry for the outdated link but I have difficult to find the actual source code of Qt5 - btw I'm using Qt5.11.1)

                A 1 Reply Last reply 27 Mar 2019, 07:36
                0
                • M Offline
                  M Offline
                  Mark81
                  wrote on 27 Mar 2019, 04:49 last edited by
                  #15

                  Perhaps I found it here https://code.woboq.org/qt5/qtserialbus/src/serialbus/qmodbusrtuserialmaster_p.h.html#154:

                  if (m_state != State::Receive) {
                      qCDebug(QT_MODBUS) << "(RTU server) Ignoring response due to non receive state";
                      return;
                  }
                  

                  but https://code.woboq.org/qt5/qtserialbus/src/serialbus/qmodbusrtuserialmaster_p.h.html#351:

                  qCDebug(QT_MODBUS) << "(RTU client) Send successful:" << m_current.requestPdu;
                  m_state = Receive;
                  

                  So if the state is not set to Receive it discard the response. Anyway I didn't see the debug output "Ignoring response...".

                  1 Reply Last reply
                  0
                  • M Mark81
                    27 Mar 2019, 04:40

                    UPDATE

                    I think (not sure, though) I noticed something interesting.
                    When it works, the debug output from qt.modbus is like this:

                    qt.modbus: (RTU client) Sent Serial PDU: 0x0304270001
                    qt.modbus.lowlevel: (RTU client) Sent Serial ADU: 0x0103042700013531
                    qt.modbus: (RTU client) Send successful: 0x0304270001
                    qt.modbus.lowlevel: (RTU client) Response buffer: "01030200017984"
                    qt.modbus: (RTU client) Received ADU: "01030200017984"
                    

                    and my slot is correctly called. Instead, when the problem arises the output is like the one reported in the first post or even this one:

                    qt.modbus: (RTU client) Sent Serial PDU: 0x0304180002
                    qt.modbus.lowlevel: (RTU client) Sent Serial ADU: 0x010304180002453c
                    qt.modbus.lowlevel: (RTU client) Response buffer: "01030400004080ca53"
                    qt.modbus: (RTU client) Received ADU: "01030400004080ca53"
                    qt.modbus: (RTU client) Send successful: 0x0304180002
                    qt.modbus: (RTU client) Receive timeout: 0x0304180002
                    qt.modbus: (RTU client) Sent Serial PDU: 0x0304180002
                    qt.modbus.lowlevel: (RTU client) Sent Serial ADU: 0x010304180002453c
                    qt.modbus.lowlevel: (RTU client) Response buffer: "01030400004080ca53"
                    qt.modbus: (RTU client) Received ADU: "01030400004080ca53"
                    qt.modbus: (RTU client) Send successful: 0x0304180002
                    qt.modbus: (RTU client) Receive timeout: 0x0304180002
                    

                    Here my slot is not called.

                    I see that every time this happens the "Response buffer" line comes before the "Send successful" one.
                    I'm looking at the code but I don't understand if this might be a problem.

                    (Sorry for the outdated link but I have difficult to find the actual source code of Qt5 - btw I'm using Qt5.11.1)

                    A Offline
                    A Offline
                    aha_1980
                    Lifetime Qt Champion
                    wrote on 27 Mar 2019, 07:36 last edited by
                    #16

                    @Mark81 said in Modbus RTU: readyRead() not called:

                    (Sorry for the outdated link but I have difficult to find the actual source code of Qt5 - btw I'm using Qt5.11.1)

                    Then you should really test with a recent version 5.12.x. There has been quite some fixes last year.

                    Qt has to stay free or it will die.

                    1 Reply Last reply
                    0
                    • M Offline
                      M Offline
                      Mark81
                      wrote on 27 Mar 2019, 15:11 last edited by
                      #17

                      Update to Qt5.12.2. Now with the very same code and data after a while it crashes with this error:

                      ASSERT failure in processQueue: "response timer active", file qmodbusrtuserialmaster_p.h, line 302

                      What should one do in such a case?

                      J 1 Reply Last reply 27 Mar 2019, 15:22
                      0
                      • M Mark81
                        27 Mar 2019, 15:11

                        Update to Qt5.12.2. Now with the very same code and data after a while it crashes with this error:

                        ASSERT failure in processQueue: "response timer active", file qmodbusrtuserialmaster_p.h, line 302

                        What should one do in such a case?

                        J Online
                        J Online
                        J.Hilk
                        Moderators
                        wrote on 27 Mar 2019, 15:22 last edited by J.Hilk
                        #18

                        @Mark81 vote for the issue and pray, like I did

                        https://bugreports.qt.io/browse/QTBUG-73965

                        also leave a comment, it helps when people state that they have the same issue.


                        Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


                        Q: What's that?
                        A: It's blue light.
                        Q: What does it do?
                        A: It turns blue.

                        M 1 Reply Last reply 27 Mar 2019, 15:36
                        3
                        • J J.Hilk
                          27 Mar 2019, 15:22

                          @Mark81 vote for the issue and pray, like I did

                          https://bugreports.qt.io/browse/QTBUG-73965

                          also leave a comment, it helps when people state that they have the same issue.

                          M Offline
                          M Offline
                          Mark81
                          wrote on 27 Mar 2019, 15:36 last edited by
                          #19

                          @J.Hilk said in Modbus RTU: readyRead() not called:

                          @Mark81 vote for the issue and pray, like I did

                          I'll try to suggest to my customer to pray and wait a fix too.

                          J 1 Reply Last reply 27 Mar 2019, 15:48
                          0
                          • M Mark81
                            27 Mar 2019, 15:36

                            @J.Hilk said in Modbus RTU: readyRead() not called:

                            @Mark81 vote for the issue and pray, like I did

                            I'll try to suggest to my customer to pray and wait a fix too.

                            J Online
                            J Online
                            J.Hilk
                            Moderators
                            wrote on 27 Mar 2019, 15:48 last edited by
                            #20

                            @Mark81
                            you can download the source code and in qmodbusrtumaster comment that line

                            QObject::connect(m_serialPort, &QSerialPort;::bytesWritten, q,
                            [this](qint64 bytes) {
                            m_current.bytesWritten += bytes;
                            if (m_state == Send && (m_current.bytesWritten ==m_current.adu.size()) && !m_current.reply.isNull()) {
                                   // the if conditions above are copied from processQueue()
                                    qCDebug(QT_MODBUS) << "(RTU client) Send successful(quick):" << m_current.requestPdu;
                                    m_state = Receive;
                                    m_sendTimer.stop();
                            //        m_responseTimer.start(m_responseTimeoutDuration); comment this line
                            }
                            });
                            

                            thats the quick and dirty fix I made, fixes the unexpected state issue


                            Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


                            Q: What's that?
                            A: It's blue light.
                            Q: What does it do?
                            A: It turns blue.

                            1 Reply Last reply
                            3

                            17/20

                            27 Mar 2019, 15:11

                            • Login

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