|
Название: Как сделать вторичный поток с постоянный жизненным циклом и управлением из главн Отправлено: Alexey_Golubev_92 от Ноябрь 24, 2019, 14:55 Имеется объект, который живёт в другом потоке и выполняет различные задачи по запросам или выполняет повторяющиеся задачи.
Более приземленное описание. Через протокол modbus RTU опрашиваются датчики. Датчиков 247 штук. Используются 3 команды, чтение регистров, запись регистров, чтение ID. Управление датчиками может быть ручное или автоматическое. При ручном режиме принимаем данные из главного потока и передаем на датчик, после ответа датчика передаем данные в главный поток для записи в usb устройство и отображение на экране. При автоматическом режиме управляем датчиками по заданному алгоритму и отсылаем ответы датчиков в главный поток для записи на usb устройство и отображения данных. Вот не знаю как лучше реализовать это. Название: Re: Как сделать вторичный поток с постоянный жизненным циклом и управлением из главн Отправлено: RedDog от Ноябрь 24, 2019, 16:15 При создании главного создается фоновый и запускается.
Управление фоновому из главного передается сигналами из первого. Так же главный сигналами из фонового получает информацию. При завершении приложения вместе с главным убивается и фоновый. Название: Re: Как сделать вторичный поток с постоянный жизненным циклом и управлением из главн Отправлено: sergek от Ноябрь 24, 2019, 20:14 Через протокол modbus RTU опрашиваются датчики. Датчиков 247 штук. Опрос устройств на одной шине по modbus выполняется последовательно. Пока не получите ответ или ошибку, следующий запрос отправлять нельзя. Поэтому, на мой взгляд, наилучшим решением является организация очереди запросов. Очередь должна отслеживать получение ответов из шины (или таймаутов при отсутствии ответов) и отправлять следующий запрос. Т.е. очередь работает с устройствами синхронно - продвижение запросов инициируется ответами или таймаутами (если не задавать таймауты ожидания, то очередь может застопориться). Сразу предусмотрите возможность установки настраиваемой паузы между получением ответа и отправкой запроса -пригодится при плохих линиях. Мне иногда приходится ставить паузу до 20 мс (шина RS485 длиной 50-60 м, два "уса" в разные стороны от одного порта - вот так проложили..). Поэтому, сочувствую - две с половиной сотни даже при шустрых устройствах (15-20 мс), это несколько секунд. А устройства иногда отказывают...Вот не знаю как лучше реализовать это. Таким образом, клиентская часть будет работать не напрямую с устройствами, а с очередью - ставит запрос в нее и забывает. Обратный поток данных организовать уже просто - сигнал с данными и идентификатором устройства. Так что организация отдельного потока для опроса, на мой взгляд, нормальная идея. |