libmodbus icon indicating copy to clipboard operation
libmodbus copied to clipboard

The serial port device isn't released completely in linux.

Open ladmanj opened this issue 5 years ago • 2 comments

I'm developing a embedded slave device and as a tool i wrote simple Qt clickable tester master/client application.

Even there is a preparation for tcp connection, i am only using rtu mode with USB FTDI chip based RS-458 device until now.

Opening and closing of the device is done with this function:

void MainWindow::on_openPushButton_clicked()
{
    if (ctx == NULL) {
        switch(ui->connModeComboBox->currentIndex())
        {
        case 0:
            ctx = modbus_new_rtu(ui->connLineEdit->text().toLocal8Bit(), ui->portBaudspinBox->value(), 'N', 8, 1);
            break;
        case 1:
            ctx = modbus_new_rtu(ui->connLineEdit->text().toLocal8Bit(), ui->portBaudspinBox->value(), 'E', 8, 1);
            break;
        case 2:
            ctx = modbus_new_tcp(ui->connLineEdit->text().toLocal8Bit(), ui->portBaudspinBox->value());
        }
        if(ctx == NULL) qDebug("modbus new failed");
        else
        {
            ui->openPushButton->setText("Close");
            timer->start(500);
        }
    }
    else
    {
        timer->stop();
        modbus_close(ctx);
        modbus_free(ctx);
        ctx = NULL;
        ui->openPushButton->setText("Open");
    }
}

But, if the device is opened, successfully used for communication and then closed, but the application isn't shut down nor the libmodbus.so is unloaded; and then the device is unplugged from USB port and then reconnected again, it never gets the same device node.

It was /dev/ttyUSB0 and then it gets number 1 at the end.

I was stepping through the code and I'm pretty sure that it isn't my fault. It is libmodbus who leaves the port somewhat blocked, so kernel can't associate a new usb device with the same device node.

libmodbus 3.1.6 from source code Linux thinkpad 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

thx

ladmanj avatar Aug 09 '20 19:08 ladmanj

I didn't see such issue before.

The internal code is:

if (ctx->s != -1) {
        tcsetattr(ctx->s, TCSANOW, &ctx_rtu->old_tios);
        close(ctx->s);
        ctx->s = -1;
}

Do you see something missing?

stephane avatar Aug 17 '22 15:08 stephane

Hello @stephane ,

I don't know what additional information can I give to you, unfortunately.

Maybe the condition (ctx->s != -1) is not already met, because the context is freed in advance erroneously.

Please let me know what should I test to give you the information needed.

Thank you

ladmanj avatar Aug 18 '22 11:08 ladmanj

Could you add log traces to in the libmodbus close function to be sure it's called (not early exit in your app) and to see the value of ctx->s?

stephane avatar Nov 28 '22 00:11 stephane

Hi Stephane,I'll do it later. Preferably before end of this week.J.Dne 28. 11. 2022 1:54 napsal uživatel Stéphane Raimbault @.***>: Could you add log traces to in the libmodbus close function to be sure it's called (not early exit in your app) and to see the value of ctx->s?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

ladmanj avatar Nov 28 '22 06:11 ladmanj