У меня было что если соединения нет с серверами телеграмма (прокси умер) то сама телеграмм часть намертво зависала в longpoll. Я в итоге пересобирал саму библиотеку tgbotcpp с включенным curl. Потом уже инициировал бота с кастомным curl http клиентом который бросает исключение на таймауте соединения, я ловлю исключение и перезапускаю бота.
С последними новшествами у меня уже почти каждый день боты по 20-30 минут не могут связаться с тг серверами, потом в логе смотрю. И в v2ray есть галочка запустить локально http прокси, потом запускаю приложение через bat и все работает.
@echo off
set https_proxy=socks5://127.0.0.1:10808
set http_proxy=socks5://127.0.0.1:10808
set all_proxy=socks5://127.0.0.1:10808
start "" "OPCDATgBot.exe"
Бот тг с OPC DA клиентом. Может читать и писать переменные из контроллеров и превращать в сообщения, оповещает о событиях и изменениях значений переменных. Сейчас доделываю поддержку драйверов OPC UA думаю еще добавить модбас, s7 и ватсмайнер апи. Удобно контролировать удаленные объекты.
СБ задает правила. Они не меняются от угла к углу на столе. Не то что номера регистров у кривого прибора без поддержки. Тем более что это не единственный возможный путь, всегда есть старый добрый 485.
Техподдержка производителя не предоставила адреса регистров? В разное время установленных теплосчетчиках разные регистры, и понять где какие нельзя ни по версии прибора ни по прошивке?
Плюс к тому что регистры надо группировать и запрашивать пачками, снижает нагрузку на канал и на устройство.
Отсутствие связи определяется по таймауту? Здесь тоже нужно не повешать обмен пытаясь 50 регистров опросить и в каждом дождаться таймаута.
я для себя также писал телеграмм бота с опросом чего угодно по ОРС. Сделал на DA, сейчас допиливаю UA и в планах еще без орс протоколы s7 и модбас тср допилить.
У меня получилось в итоге что каждый орс клиент это отдельный поток. В основном потоке у меня диспетчер тэгов. В тэги из своих потоков пишутся текущие значения, коды качества. А потребители данных через этот же диспетчер запрашиваю значения или присылают значения для записи.
Кстати модет быть тоже посмотреть в сторону ОРС. OPC UA очень удобная технология и поддерживается много чем. Низкоуровневый обмен уже решен на орс сервере или на уровне библиотеки орс ua.
Следующим шагом станет визуальная конфигурация линии из готовых отлаженных блоков - и ура! вы изобрели CFC + SFC.
Я прекрасно понимаю почему лепили визуализацию на дельфи в 00-х, но в 10-х это уже почти умерло по понятным причинам.
Все круто. Но. Плохо масштабируется, плохо отлаживается, очень плохо дорабатывается старое, и требуется неоправданно высокая квалификация для инженера асутп.
Все логично и гармонично но где то в 2005-2008 вы пропустили переход на обычный промышленный плк.
Вопрос в том что модули ввода вывода овен это Модбас ТСР сервер (слейв в терминологии RTU) и непонятно зачем для него разрабатывать какой то особенный блок. И почему именно для него.
Есть модбас клиент универсальный и будет клиент специальный под овен. В чем идея?
Там в папке bin есть собранный бинарник под x64. Или должно собраться Смаке'ом если есть Qt6.
Сейчас допилю версию с драйверами соединений с железом, причешу репозиторий.
У меня было что если соединения нет с серверами телеграмма (прокси умер) то сама телеграмм часть намертво зависала в longpoll. Я в итоге пересобирал саму библиотеку tgbotcpp с включенным curl. Потом уже инициировал бота с кастомным curl http клиентом который бросает исключение на таймауте соединения, я ловлю исключение и перезапускаю бота.
С последними новшествами у меня уже почти каждый день боты по 20-30 минут не могут связаться с тг серверами, потом в логе смотрю. И в v2ray есть галочка запустить локально http прокси, потом запускаю приложение через bat и все работает.
Мой проектик на tgbot-cpp.
https://github.com/jkapter/OPC_DA_Telegram_bot
Бот тг с OPC DA клиентом. Может читать и писать переменные из контроллеров и превращать в сообщения, оповещает о событиях и изменениях значений переменных. Сейчас доделываю поддержку драйверов OPC UA думаю еще добавить модбас, s7 и ватсмайнер апи. Удобно контролировать удаленные объекты.
Как обходите блокировку тг у бота?
СБ задает правила. Они не меняются от угла к углу на столе. Не то что номера регистров у кривого прибора без поддержки. Тем более что это не единственный возможный путь, всегда есть старый добрый 485.
Техподдержка производителя не предоставила адреса регистров? В разное время установленных теплосчетчиках разные регистры, и понять где какие нельзя ни по версии прибора ни по прошивке?
Не нужны вам такие приборы.
Плюс к тому что регистры надо группировать и запрашивать пачками, снижает нагрузку на канал и на устройство.
Отсутствие связи определяется по таймауту? Здесь тоже нужно не повешать обмен пытаясь 50 регистров опросить и в каждом дождаться таймаута.
я для себя также писал телеграмм бота с опросом чего угодно по ОРС. Сделал на DA, сейчас допиливаю UA и в планах еще без орс протоколы s7 и модбас тср допилить.
У меня получилось в итоге что каждый орс клиент это отдельный поток. В основном потоке у меня диспетчер тэгов. В тэги из своих потоков пишутся текущие значения, коды качества. А потребители данных через этот же диспетчер запрашиваю значения или присылают значения для записи.
Кстати модет быть тоже посмотреть в сторону ОРС. OPC UA очень удобная технология и поддерживается много чем. Низкоуровневый обмен уже решен на орс сервере или на уровне библиотеки орс ua.
Следующим шагом станет визуальная конфигурация линии из готовых отлаженных блоков - и ура! вы изобрели CFC + SFC.
Я прекрасно понимаю почему лепили визуализацию на дельфи в 00-х, но в 10-х это уже почти умерло по понятным причинам.
Все круто. Но. Плохо масштабируется, плохо отлаживается, очень плохо дорабатывается старое, и требуется неоправданно высокая квалификация для инженера асутп.
Все логично и гармонично но где то в 2005-2008 вы пропустили переход на обычный промышленный плк.
А в железе это на чем исполняется? И чем оси крутит? SoftMotion от 3s/codesys не пробовали?
Вопрос в том что модули ввода вывода овен это Модбас ТСР сервер (слейв в терминологии RTU) и непонятно зачем для него разрабатывать какой то особенный блок. И почему именно для него.
Есть модбас клиент универсальный и будет клиент специальный под овен. В чем идея?
Модбаса на борту овена недостаточно? Какая то специальная версия нужна? В чем состоит расширение.