Как сделать вторичный поток с постоянный жизненным циклом и управлением из главного потока

Имеется объект, который живёт в другом потоке и выполняет различные задачи по запросам или выполняет повторяющиеся задачи.

Более приземленное описание. Через протокол modbus RTU опрашиваются датчики. Датчиков 247 штук. Используются 3 команды, чтение регистров, запись регистров, чтение ID. Управление датчиками может быть ручное или автоматическое. При ручном режиме принимаем данные из главного потока и передаем на датчик, после ответа датчика передаем данные в главный поток для записи в usb устройство и отображение на экране. При автоматическом режиме управляем датчиками по заданному алгоритму и отсылаем ответы датчиков в главный поток для записи на usb устройство и отображения данных.

Вот не знаю как лучше реализовать это.

0

Датчики моя разработка как и сборка линукс для тиона. Адрес от 1 до 247.
Опрашиваю с помощью libmodbus.

0

Сообщение от Alex_Golubev Датчики моя разработка

Хорошо. Какие у них еще есть параметры, кроме адреса?

0

Чтение и запись две команды. Точно не помню чтение 0x4 запись 0x10. Полный стандарт модбус

Добавлено через 4 минуты
Использую в qt #include <modbus/modbus.h> подключил в buildroot.

0

Не понимаю, зачем вам отдельный поток в принципе. Обычная программа, нажимаем кнопку "авто" - запускается либо таймер, либо бесконечный цикл - опрашивающий датчики. В цикле стоит проверка флага, если он "авто" цикл выполняется, если "ручная" - цикл останавливается. По нажатию авто флаг включается. По нажатию ручная сбрасывается. Ну и ессно после остановки цикла можно выполнять любые действия.

А вот сброс в файл как раз можно выполнить в отдельном потоке. Я бы сперва сделал, что-бы по нажатию кнопки происходил однократный опрос датчиков - с записью в буфер, и возможно в файл. Затем поставил бы это дело в цикл. а потом можно допиливать и ручной режим - что там нужно, я не знаю, доступ к любому произвольному датчику, чтение, запись, или ещё что?

А вы всё валите в кучу: авто режим, ручной, потоки... так никогда работающую программу не напишешь.

Или вас троллят с помощью 247-ми датчиков!

Добавлено через 1 минуту

Сообщение от Alex_Golubev Чтение и запись две команды. Точно не помню чтение 0x4 запись 0x10. Полный стандарт модбус

Во-во, как раз то, о чём я и говорил. Одновременно с потоками начните ещё и с модбусом разбираться.

0

Если не пользоваться потоками то будут тормаза в главном потоки. На опрос одного датчика уходит время. Если точно скорость 4800, 11 бит, одна посылка 32 байта. Вот и получается что одна посылка занимает 73 мС. приставляете 73 *247 = 18 секунд и это при условии что нет сбоев на шине. А если помехи ? То сами понимаете очень долго. Таймер тоже в главном потоки крутиться.

0

Да какая разница. Сперва нужно сделать, что-бы по нажатию кнопки один раз опрашивала все датчики, пусть и 18 секунд. А потом уже думать, как всё это в поток запихнуть. Она ж не может одновременно и в ручном и в автоматическом режиме работать, поэтому всё равно либо ждать, пока все датчики не отработают, либо прерывать посередине, что, думаю, не айс.

0

Сообщение от alexu_007 раз опрашивала все датчики, пусть и 18 секунд

Это уже все сделал. Программу я уже тестовую написал. Она работает.
Мне сейчас нужно как то разнести ручной авто обновление. и оформить это все красиво.

0

insite2012, Может по простому передавать указатель на поток через конструктор в класс диалогового окна?
И когда надо останавливать вторичный поток.

0

Сообщение от Alex_Golubev Может по простому передавать указатель на поток через конструктор в класс диалогового окна?

Alex_Golubev, я не знаю, как у вас сейчас сделано, но на мой взгляд, вам сейчас надо реализовать в первую очередь класс для работы с датчиками. Он должен:
1. опрашивать один датчик;
2. опрашивать все датчики в цикле;
3. возвращать информацию об опрошенных датчиках посредством сигналов (и только так);
4. иметь свойство, определяющее его статус: остановлен (STOPPED), работает (RUNNING). Их можно оформить как вложенное перечисление, например;
5. также можно сделать и сигнал для отображения прогресса опроса каждого из датчиков (по желанию);

Пока абстрагируйтесь от интерфейса, напишите его в консоли, отладьте, а потом его уже можно применить где угодно.

Далее, что касается отображения данных/записи их на к-либо накопитель. На мой взгляд, таймер тут применить не получится (или это может привести к проблемам). Как я понимаю, время получения данных у вас не строго определено, так что вполне может возникнуть ситуация, когда в обработчике тика таймера вы не успеете обработать все, а произойдет еще один тик. Думаю, тут будет удобнее применить вариацию шаблона Поставщик-Потребитель. Так вы получите максимально возможную скорость обработки данных без лишних простоев.

0

Я об этом думал. Можно в класс добавить поток ?

Добавлено через 6 минут
А как можно добавить в класс бесконечный опрос датчиков ? Мне вот это не совсем понятно.

0

Сообщение от Alex_Golubev Можно в класс добавить поток ?

Зачем??? Вы поймите, не надо мешать мух с котлетами. Класс должен функционировать сам по себе, а уж в потоке или нет-не его дело. В этом и смысл, реализовали класс, проверили в консоли, к примеру, где потоки без надобности, а при его же применении в GUI уже засунули его в поток.

Сообщение от Alex_Golubev как можно добавить в класс бесконечный опрос датчиков ? Мне вот это не совсем понятно.

Да как обычно, бесконечный (условно) цикл. Опрос через что происходит (что используется как оконечное устройство, в смысле железо). Эмулятор ком порта, еще что-то?

0

Сообщение от insite2012 . Эмулятор ком порта, еще что-то

Используется физический RS485. По сути дела это и есть ком порт только с добавлением линии RTS.

0

Сообщение от Alex_Golubev Используется физический RS485. По сути дела это и есть ком порт только с добавлением линии RTS.

Вот, уже хорошо.
Тут можно сделать так:
1. Создаем класс, который абстрагирует в себе работу с физическим интерфейсом (открыть, закрыть, послать данные, считать данные). Это делается для удобства (возможно, в будущем тип интерфейса поменяется, и если сразу его абстрагировать, то потом весь код, его использующий переписывать не придется). Ну и вообще так удобнее, вся низкоуровневая работа с байтами скрыта об более высоких уровней.
2. Создаем класс уже для работы с датчиками (как я писал выше). В параметре конструктора он получает строку-имя устройства (имя порта). Внутри себя он создает, открывает и конфигурирует устройство, и через него работает с датчиками.

0

Все равно не понимаю как сделать бесконечный опрос. На опрос одного датчика уходит 70 мили секунд. Это если он сразу ответил. А может быть помеха. И придется опросить его 3 раза. А это уже 210 мили секунд. Что заметно уже.

0

Сообщение от Alex_Golubev Все равно не понимаю как сделать бесконечный опрос

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

Вложения

untitled1.rar (5.2 Кб, 5 просмотров)

0

Хочу понять логику. Класс IODevice используется только для открытия закрытия порта и настройки скорости четности временных задержек?

0

Сообщение от Alex_Golubev Класс IODevice используется только для открытия закрытия порта и настройки скорости четности временных задержек?

Открыть устройство, закрыть устройство, послать запрос, получить ответ. Это его главные функции. Что это за запрос, что за ответ и как его интерпретировать-не его дело. Это будет происходить уже выше по логике.

0

Вы под устройством понимаете только com-порт ? Отрыть закрыть могу порт.

Добавлено через 15 минут
Внешней датчик открыть закрыть не могу. Там прямой запрос данных или запись данных. Открыл com-порт ---> задал номер датчика ---> отправил команду чтение регистров указав адрес и длину---> получил ответ. Обработал.

0

Сообщение от Alex_Golubev Вы под устройством понимаете только com-порт ?

Именно так.

Сообщение от Alex_Golubev Открыл com-порт ---> задал номер датчика ---> отправил команду чтение регистров указав адрес и длину---> получил ответ. Обработал.

Вооот. Вот эту логику и реализуйте в классе IODevice. Послали команду-> получили ответ->вернули его в класс чтения. Это я там для примера показал возврат строки, вы можете вернуть что-то свое, переделав метод.

0

Хорошо. Буду делать. После покажу что сделал.

Добавлено через 10 минут
А SensorInfo для чего ?

0