Cause
Many people fail to realise, that communications take time. So, in your case, you open the device and immediatelly initiate a read request, which fails, because the device is not open yet (because it takes time, as everithing else).
Solution
In a GUI application, it is probably the best, when the code reacts to events, instead of trying to execute everything lineary. This is where signals and slots come into play.
Consider the following workflow:
when you create the QModbusDevice, you also connect its signals (e.g. stateChanged and errorOccurred) to slots in your code (e.g. MainWindow::onModbusStateChanged, or MainWindow::onModbusErrorOccurred). Those should be considered as callback functions, which are executed when the corresponding event occurs: the connection state changes, the data is received, the data is sent, an error occurs.
In this manner you would know exactly when to do what.
Example
Here is an example code I have prepared for you to show you how the problem could be approached:
in MainWindow.h
...
private:
QModbusClient *m_modbus;
...
private slots:
void onModbusStateChanged(QModbusDevice::State state);
...
in MainWindow.cpp
MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
m_modbus(new QModbusClient(this))
{
...
connect(m_modbus, &QModbusClient::stateChanged, this, MainWindow::onModbusStateChanged);
...
}
To read the data as soon as the device is connected, the slot might look like this:
void MainWindow::onModbusStateChanged(QModbusDevice::State state)
{
switch (state) {
...
case QModbusDevice::ConnectedState:
m_modbus->read(QModbusDataUnit::HoldingRegisters, 0, 10);
break;
...
}
}
It remains to initiate the connection on a click of a button. In your case:
void MainWindow::on_button_clicked()
{
m_modbus->connectDevice();
}