@J-Hilk , wow! Huge thanks for sharing your code! I reached out to our MCU department for source code of CRC they're using. Looks really similar to your solution: const unsigned char auchCRCHi[] = { 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40} ; const unsigned char auchCRCLo[] = { 0x00, 0xC0, 0xC1, 0x01, 0xC3, 0x03, 0x02, 0xC2, 0xC6, 0x06, 0x07, 0xC7, 0x05, 0xC5, 0xC4, 0x04, 0xCC, 0x0C, 0x0D, 0xCD, 0x0F, 0xCF, 0xCE, 0x0E, 0x0A, 0xCA, 0xCB, 0x0B, 0xC9, 0x09, 0x08, 0xC8, 0xD8, 0x18, 0x19, 0xD9, 0x1B, 0xDB, 0xDA, 0x1A, 0x1E, 0xDE, 0xDF, 0x1F, 0xDD, 0x1D, 0x1C, 0xDC, 0x14, 0xD4, 0xD5, 0x15, 0xD7, 0x17, 0x16, 0xD6, 0xD2, 0x12, 0x13, 0xD3, 0x11, 0xD1, 0xD0, 0x10, 0xF0, 0x30, 0x31, 0xF1, 0x33, 0xF3, 0xF2, 0x32, 0x36, 0xF6, 0xF7, 0x37, 0xF5, 0x35, 0x34, 0xF4, 0x3C, 0xFC, 0xFD, 0x3D, 0xFF, 0x3F, 0x3E, 0xFE, 0xFA, 0x3A, 0x3B, 0xFB, 0x39, 0xF9, 0xF8, 0x38, 0x28, 0xE8, 0xE9, 0x29, 0xEB, 0x2B, 0x2A, 0xEA, 0xEE, 0x2E, 0x2F, 0xEF, 0x2D, 0xED, 0xEC, 0x2C, 0xE4, 0x24, 0x25, 0xE5, 0x27, 0xE7, 0xE6, 0x26, 0x22, 0xE2, 0xE3, 0x23, 0xE1, 0x21, 0x20, 0xE0, 0xA0, 0x60, 0x61, 0xA1, 0x63, 0xA3, 0xA2, 0x62, 0x66, 0xA6, 0xA7, 0x67, 0xA5, 0x65, 0x64, 0xA4, 0x6C, 0xAC, 0xAD, 0x6D, 0xAF, 0x6F, 0x6E, 0xAE, 0xAA, 0x6A, 0x6B, 0xAB, 0x69, 0xA9, 0xA8, 0x68, 0x78, 0xB8, 0xB9, 0x79, 0xBB, 0x7B, 0x7A, 0xBA, 0xBE, 0x7E, 0x7F, 0xBF, 0x7D, 0xBD, 0xBC, 0x7C, 0xB4, 0x74, 0x75, 0xB5, 0x77, 0xB7, 0xB6, 0x76, 0x72, 0xB2, 0xB3, 0x73, 0xB1, 0x71, 0x70, 0xB0, 0x50, 0x90, 0x91, 0x51, 0x93, 0x53, 0x52, 0x92, 0x96, 0x56, 0x57, 0x97, 0x55, 0x95, 0x94, 0x54, 0x9C, 0x5C, 0x5D, 0x9D, 0x5F, 0x9F, 0x9E, 0x5E, 0x5A, 0x9A, 0x9B, 0x5B, 0x99, 0x59, 0x58, 0x98, 0x88, 0x48, 0x49, 0x89, 0x4B, 0x8B, 0x8A, 0x4A, 0x4E, 0x8E, 0x8F, 0x4F, 0x8D, 0x4D, 0x4C, 0x8C, 0x44, 0x84, 0x85, 0x45, 0x87, 0x47, 0x46, 0x86, 0x82, 0x42, 0x43, 0x83, 0x41, 0x81, 0x80, 0x40}; unsigned short CRC16 (unsigned char *puchMsg, unsigned char usDataLen ) { unsigned char uchCRCHi = 0xFF ; /* high byte of CRC initialized */ unsigned char uchCRCLo = 0xFF ; /* low byte of CRC initialized */ unsigned short uIndex ; /* will index into CRC lookup table */ while (usDataLen--) /* pass through message buffer */ { uIndex = uchCRCLo ^ *puchMsg++ ; /* calculate the CRC */ uchCRCLo = uchCRCHi ^ auchCRCHi[uIndex] ; uchCRCHi = auchCRCLo[uIndex] ; } return (uchCRCHi | uchCRCLo << 8) ; } And a small header: #ifndef __CRC16_H__ #define __CRC16_H__ 1 unsigned short CRC16 (unsigned char *puchMsg, unsigned char usDataLen ); #endif //#ifndef __UART_H__ After a first glance, you can spot the similarities. Huge thanks for help!

Hi, @J-Hilk! Looks like i found desired method in QModbusDataUnit class docs. Don't know how i missed it being mentioned in List of All Members for QModbusRtuSerialMaster. I guess digging into Qt docs about Modbus was a proper way to solve this :) QModbusDataUnit::QModbusDataUnit(QModbusDataUnit::RegisterType type, int address, const QVector<quint16> &data) In my case this will be: QModbusDataUnit input(QModbusDataUnit::InputRegisters, 3001, data); Thanks for joining my journey!

Thank you @jsulm & @KroMignon !! :) Ports 0-1024 are "protected" for "known" services and By "protected", they must be used by system daemons. Thus, a regular user cannot start them. Solution 1: Run application using terminal: sudo \path\to\app Solution 2: Use a port above 1024 So i changed port from 502 to 1502: const QUrl url = QUrl::fromUserInput("127.0.0.1:1502"); Working now!! <3 Qt

Hi @Chai18 Did you find any solution ? I have a similar issue but in the client side (QModbusClient) , this is my function to write data to the holding registers , but I'm all the time getting the response timeout, and master is actually handling incoming requests and send appropriate responses automatically. void Serial::writeData(int start, const QList<quint16> &holdingRegisters) { if (!modbusDevice) return; startAddress = start; numberOfEntries = holdingRegisters.size(); // Switch to Transmit Mode switchGPIO->setValue(true); // enables TX QModbusDataUnit writeUnit = writeRequest(); QModbusDataUnit::RegisterType table = writeUnit.registerType(); for (qsizetype i = 0, total = writeUnit.valueCount(); i < total; ++i) { const auto addr = i + writeUnit.startAddress(); if (table == QModbusDataUnit::Coils) writeUnit.setValue(i, m_coils[addr]); else writeUnit.setValue(i, holdingRegisters[addr]); } if (auto *reply = modbusDevice->sendWriteRequest(writeUnit, serverAddress)) { if (!reply->isFinished()) { QModbusDevice::connect( reply, &QModbusReply::finished, this, [this, reply]() { // Switch back to Receive Mode usleep(1000); // Small delay before switching switchGPIO->setValue(false); // Enable RX mode const auto error = reply->error(); if (error == QModbusDevice::ProtocolError) { qDebug() << "Write response error:" << reply->errorString() << "(Modbus exception:" << reply->rawResult().exceptionCode() << ")"; } else if (error != QModbusDevice::NoError) { qDebug() << "Write response error:" << reply->errorString() << "(code: 0x" << QString::number(error, 16) << ")"; } reply->deleteLater(); }); } else { qDebug() << "Write error: " << reply->errorString(); reply->deleteLater(); } } else { qDebug() << "Write error: " << modbusDevice->errorString(); switchGPIO->setValue(false); // Ensure RX mode is enabled on failure } } Thanks in advance

@imhs I figured it out! The problem was in the read function function where I call it every time toggling the run switch. Inside that function there is a timer which aims to read the registers and update the UI. Every time I call that function a new timer was generated. Therefore after sometime many timers was running in parallel which caused the problem. Take care about timers!

@J-Hilk A colleague of mine tried the 5.12.4, but the error is still there. I'll try with the QQuickPaintedItem or I'll switch to the 5.14. Thanks for your time.

To be continued at bugreports.qt.io https://bugreports.qt.io/browse/QTBUG-73965

I think a tracker has been raised from long time for the same https://bugreports.qt.io/browse/QTBUG-51751 and this is still in unresolved state.

Yes, of course may be a problem in the code that accidentaly worked with previous Qt version. I knew that bug, but is not related to my issue, since I'm using a longer timeout in this case.

@SGaist said in Infinite update data over modbus protocol: I haven't used that module yet but are you sure you are not spamming your devices or triggering network congestion ? Hi, I'm thinking that I do...

Thanks for the answers, I found the connection problem. I added the part: void MainWindow::on_connectType_currentIndexChanged(int index) { if (modbusDevice) { modbusDevice->disconnectDevice(); delete modbusDevice; modbusDevice = nullptr; } auto type = static_cast<ModbusConnection> (index); if (type == Serial) { modbusDevice = new QModbusRtuSerialMaster(this); } else if (type == Tcp) { modbusDevice = new QModbusTcpClient(this); if (ui->portEdit->text().isEmpty()) ui->portEdit->setText(QLatin1Literal("127.0.0.1:502")); } connect(modbusDevice, &QModbusClient::errorOccurred, [this](QModbusDevice::Error) { statusBar()->showMessage(modbusDevice->errorString(), 5000); }); if (!modbusDevice) { ui->connectButton->setDisabled(true); if (type == Serial) statusBar()->showMessage(tr("Could not create Modbus master."), 5000); else statusBar()->showMessage(tr("Could not create Modbus client."), 5000); } else { connect(modbusDevice, &QModbusClient::stateChanged, this, &MainWindow::onStateChanged); } } And now I can make a connection. Now I have to test it on the device, but i can't access it for a while, to be continued

@Yunus said in About QModbus usage(How to read coils at a fixed frequecy?): What can cause that ? It's not start but https://doc.qt.io/qt-6/qeventloop.html#exec ...

@beecksche Hi,I have to say you're right,however,it didn't mean my code couldn't run--because in my code. once you use connectDevice command,it did change the state from "Unconnected"to "Connected"(Your code discuss the problem it could trigger during the connectDevice() progress,it's necessary in practice,in my case I have checked the parameters like IP,Port Address etc,so it didn't show error when I compile the file).

Depending on what you would like to bring as points, there are several possibilities: The mod bus component on the bug report system Interest mailing list