@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

Maybe you can override QModbusServer::processRequest() and do all work there.

@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