ls -l <имя_устройства порта> - покажи вывод этой команды.

Прога на вин7 для девайса ставится.

С этого и нужно было начинать. Драйвер для устройства COM-порта установлен? Оно есть в диспетчере устройств?

И да, не хардкодь ничего никогда. И да, на винфак.

Есть драйвер, порт определяется, я ведь писал, что работает через раз.

Сделай отладочный вывод куда тебе удобно, посмотри, что отвечает тебе программа в случае факапа.

Так я и смотрю через qDebug вывод ошибки, я не понимаю, почему ошибка про права доступа к порту. Порт объявлен внутри класса, объект только один создаю и помещаю в тред. Других прог нету, которые бы могли открыть этот порт. Как поймать причину прав доступа к порту ?

сколько раз или как часто ты его открываешь?

При нажатии на кнопку начинается опрос девайса, если порт открыт, то закрываю, потом происходит открытие, опрос, после опроса порт остается открытым. При повторных опросах иногда случается ошибка при попытке его открыть.

ты уверен что его на каждую «сессию» надо открывать и закрывать?

thread lock thread

Не уверен, так сделали, потому что юзер в настройках может поменять порт, для этого делаем закрытие, применяем порт из настроек и потом снова открываем. Если не делать постоянно закрытие, баг исчезает, но не понятно откуда он берется.

А зачем ? Поток один у меня. Других тредов нету, которые бы открывали этот порт.

у тебя поток занят, а ты его пытаешься некорректно прикончить. так бывает в асинхроньщине, чисти код класса или смотри как в культях принудительно прибить серийник, сам я по культям не спец

Я поток не грохаю, он создается на старте проги, класс movetothread в него, далее поток запускается, управление портом идет через сигналы.

мое дело ткнуть в болячку, твое дело крикнуть или не крикнуть ой

Код в студию.

а почему не сделаться закрытые старого порта и открытие нового при смене порта юзером через сигналы?

Не закрылось с прошлого раза.

У меня проверяется при открытии, открыт ли уже.

Не надо постоянно открывать и закрывать порт. Например, один из местных столкнулся с тем, что даже закрытие порта не закрывает его реально

void Device::open(bool value)
{
    if(value)
    {
	if(!serial->isOpen())
	{
            bool ok = serial->open(QSerialPort::ReadWrite);
            if (!ok)
            {
                qDebug() << "PORT OPEN ERROR" << serial->portName() << serial->errorString();
            }
            else
            {
                qDebug() << "OPENED PORT" << serial->portName();
            }

        }
    }
    else
    {
        qDebug() << "CLOSE SERIAL PORT" << serial->portName();
        if (serial->isOpen())
        {
           qDebug() << "CLOSED";
           serial->close();
        }

    }
}

Вот такая функция открытия-закрытия порта.

movetothread плохая идея

Сам столкнулся с подобный глюками.

QSerialPort, так же как и QTcpSocet создает свой поток. Не надо его двигать в свой через movetothread. Общайся с ним через сигналы. То есть в одном классе создаешь QSerialPort и слот типа writeData, в своем основном классе сигнал типа sendToSerialPort и через него отправляешь уже данные QByteArray. Постоянно порт открывать закрывать не обязательно. Достаточно один раз открыть и перепроверять перед отправкой.

QSerialPort, так же как и QTcpSocet создает свой поток

Зуб даешь? Или ты просто вбрасываешь?

Ну попробуй создай экземпляр класса QSerial в main, а потом поток и дерни метод write из отдельного потока - сам увидишь.

Антивирус?
От какого пользователя запущено?

Поток у тебя один? Ты уверен, что при повторном обращении предыдущее уже закрыло порт?

Да не уверен он

Ты уверен, что при повторном обращении предыдущее уже закрыло порт?

Метод QSerialPort сообщает тебе что закрыт, но на самом деле он может и не закрыт еще. Вообще QT подкупает своей простотой, но на самом деле, на этой библиотеке надо блин жениться, что бы ее эфективно использовать. Я в свое время намучился с этим QSerialPort, что в итоге написал свою имплементацию Uart с мютексами, блекджеком и шлюхами и забыл QSerialPort как страшный сон.

Но потом жизнь заставила опять его использовать в одном проекте. Пришел к выводу что либо QSerialPort надо создавать в потоке из которого потом ведется работа с ним - если что то простое. Либо надо делать интерфейс и работать через сигналы слоты подключенные через QueuedConnection